From nobody Fri Aug 1 04:08:27 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DD41A0A8F for ; Fri, 1 Aug 2014 04:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pS3Ll2-Gbm7F for ; Fri, 1 Aug 2014 04:08:23 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436F91A0A8B for ; Fri, 1 Aug 2014 04:08:23 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so6390078vcb.19 for ; Fri, 01 Aug 2014 04:08:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=FmGpVVvhUTLzh/IOtaAQ8VUtWQvPgoa9JcKR+TK8CPE=; b=aSD0z1zfhWOTXHofmAndv10cLlBSm67Jiw86T099wSaLAkzXQQYUfUEmapqi65Yz9H 9vE9dQ7qq5UDRMTEYsNSQc3yUVZ37YNNcdkAhdWQmUKfODCFR2CGEvbmpEhz3CZXgGAK 2r3zXag/Gtuv0MQCnjq0oknSCBPvXHU8znqfjP6he0hpSMUBay9Vnn8ynBeE7e5WHgdT OhXyZAUZRChYGAMIkGeMskwforPoBR7TtYHID00uzmvNkGVdmr+P5OZkZKZNGTADDmLl Op28uehtAZlHX164P7i/z3ix6lJgK0u8r8oHAAmHsfjIP//2lMCGRfgiXOKODFJSKsLv wRCA== X-Gm-Message-State: ALoCoQkIEReFw5LXQrFic5mi8HWdQQ/h3rD6HGyw0HslB8Y0puWTdVjwouUvT0Y1tjUrbt2JF5n5 X-Received: by 10.52.138.175 with SMTP id qr15mr438929vdb.94.1406891302281; Fri, 01 Aug 2014 04:08:22 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+teJzpmu/1p5HjQlmpE+AU+G6+sg== Date: Fri, 1 Aug 2014 07:08:21 -0400 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/0prZXtqkNgohpDdvaqTFMfrk1H8 Subject: [sipcore] RFC 6665: why only relaxing GRUU mandate from REFER perspective X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 11:08:25 -0000 Hi, RFC 6665 section 4.5.1 appears to mandate GRUU usage for all notifiers. Thus I was wondering, why only desiring to relax the rule from a REFER perspective instead of also relaxing the GRUU mandate for other subscriptions? "Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target. This allows subscribers to explicitly target desired devices." Thanks, Brett From nobody Fri Aug 1 06:17:06 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00901A0B03 for ; Fri, 1 Aug 2014 06:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_HALF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7jiqPYoVtuJ for ; Fri, 1 Aug 2014 06:17:02 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5781A0383 for ; Fri, 1 Aug 2014 06:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=hal.gottfried@verizon.com; q=dns/txt; s=corp; t=1406899022; x=1438435022; h=from:to:date:subject:message-id:mime-version; bh=5w7JghnPWzH3SzUf54tB2KSx5pDn2EXv6SjDdL9LQZs=; b=BqoIJq+Apd5CBpgn+25zsAKi7+C2CHd9UZjIQ3rl5HIVs+s6KN1BOvjx wo2xi9x0wWuFJsV/AkaHL4iYrvfIs8zHoaFfUIgc7t1TdQHiIwk7DNqI5 xeHwhMXyCQXko4Iy9f5ELeo8nkpElL2fZPO/Zhw++0T099nhRXTJgfDpm A=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe03.verizonbusiness.com with ESMTP; 01 Aug 2014 13:17:01 +0000 From: "Gottfried, Hal F" X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208,217";a="786891871" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 01 Aug 2014 13:17:00 +0000 Received: from fhdp1lumxc7v13.us.one.verizon.com ([166.68.59.150]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 1 Aug 2014 09:17:00 -0400 To: "sipcore@ietf.org" Date: Fri, 1 Aug 2014 09:16:59 -0400 Thread-Index: Ac+tiuAWocQv2UOXRaWgtV/2c1PJFg== Message-ID: 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_E8A0C2E2F1560648B0FF20D8B91638C502C59EED69FHDP1LUMXC7V1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/HwhMF1I--upAfI8bieaICH-m5ow Subject: [sipcore] (no subject) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 13:17:03 -0000 --_000_E8A0C2E2F1560648B0FF20D8B91638C502C59EED69FHDP1LUMXC7V1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regards: Hal F. Gottfried / Sr Consultant, Contact Center Consulting & Services hal.gottfried@one.verizon.com Verizon Advanced Services - Consulting & Integration Services (ASCIS) Mobile: 913-217-0994 | Follow Me: 913-815-4889 | From Mobile Device: **VZ= HAL Free and Busy Information: http://www.meetme.so/VZHFG --_000_E8A0C2E2F1560648B0FF20D8B91638C502C59EED69FHDP1LUMXC7V1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

Regards:

Hal F. Gottfried&n= bsp;/ Sr Consultant, Contact Center Consulting & Servi= ces 
hal.gottfried@one.verizon.com

Verizon Advanced Services - Consult= ing & Integration Services (ASCIS)
Mob= ile: 913-217-0994 |  Follow Me: 913-815-4889 |= From Mobile Device:  **VZHAL

Free = and Busy Information: http://www.meetme.so/VZHFG

&nb= sp;

 

 

 

 

 

= --_000_E8A0C2E2F1560648B0FF20D8B91638C502C59EED69FHDP1LUMXC7V1_-- From nobody Wed Aug 6 21:38:20 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243921A0AAE for ; Wed, 6 Aug 2014 21:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv2WxdCHq4qD for ; Wed, 6 Aug 2014 21:38:14 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9186C1A0AA7 for ; Wed, 6 Aug 2014 21:38:14 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so4686553pad.38 for ; Wed, 06 Aug 2014 21:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=Tqhk2j9Q9Fhv7upum7efWqaxdyPG3ClL2YGmoiYdfg8=; b=spUvaVZsCB4pVy5GkMxHAk/0O8gzNV0u/PyZlP8A3jZczQ4soo3RbZ3C7CGamVaq6R qrIxcHWsWaQh53pN7aBR+JbfypcqL7QZRYDAETIHS5rFsPBGpoZtp7sa6zlL9vY6cUwW mRg38gyjr+f36NUiEN7fXj4UtDCJ+jlZ5IS5GkifQQzujAs5LCeFsBlzl6MOy6mKvWSg YHOaxiEyApIIeHJgyDz90Nd6QqSN8AW4+urviK19RmQ25Kp5bZyqIrNjdiEqpfkouaYf xDFWszJ1HgCPEu2tLpqPcR/f8eSBKiPY87lE5tR8CdgWilYDPb/3n2SoJMbuJ1QZfV5q jqeQ== X-Received: by 10.70.124.195 with SMTP id mk3mr15414987pdb.126.1407386294186; Wed, 06 Aug 2014 21:38:14 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id gb1sm2887803pbd.76.2014.08.06.21.38.11 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Aug 2014 21:38:12 -0700 (PDT) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Thu, 07 Aug 2014 13:38:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <53D6CC3D.4000005@nostrum.com> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> Message-Id: Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/W4c3IvKWB6nf7RXUyMjozjjhvrc Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 04:38:17 -0000 Hi, >3. Use of GRUU is mandatory > > Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to > implement and use as the local target in the subscription created by > the REFER request. IIUC, RFC6665 requires only notifiers to implement GRUU. > A user agent constructing any REFER that can result in an implicit > subscription MUST populate its Contact header field with a GRUU. Notifiers populate in Contact header of 2xx response for REFER and NOTIFY request with a GRUU. > As RFC6665 details, this is necessary to ensure that NOTIFY requests > sent in the implicitly created subscription arrive at this user agent > without creating a second usage inside an existing dialog. Using the RFC6665 details, Because GRUUs are guaranteed to route to a specific device, this ensures that the subscription will be routed to the same place as the established dialog. NOTIFY request is sent in dialog, any GRUU is not necessary for a notifier. > "norefersub" option tag [RFC4488] does not change this requirement, > even if used in a "Require" header field. Even if the recipient > supports the "norefersub" mechanism, and accepts the request with the > option tag in the "Require" header field, it is allowed to return a > "Refer-Sub" header field with a value of "true" in the response, and > create an implicit subscription. Because GRUU is used just to receive REFER request, "norefersub" option is irrelevant. > In general, UAs that support receiving REFER requests need to include > a GRUU in the Contact header field of all INVITE requests. This > ensures that out-of-dialog REFER requests corresponding to any > resulting INVITE dialogs are routed to the correct user agent. UAs > that will never create a implicit subscription in response to a REFER > (that is, those that will reject any REFER that might result in an > implicit subscription) are exempted from this behavior. > >4. Dialog reuse is prohibited > > As a direct consequence of requiring the use of GRUU, and the > requirements in section 4.5.2 of RFC6665, sending a REFER that might > result in an additional dialog usage within any existing dialog is > prohibited. But if notifier is not support GRUU, RFC6665 allosws for flexibility. > A user agent constructing a REFER request that could result in an > implicit subscription MUST build it as an out-of-dialog message as > defined in [RFC3261]. Thus, the REFER request will have no tag > parameter in its To: header field. > > A user agent wishing to identify an existing dialog (such as for call > transfer as defined in [RFC5589] MUST use the "Target-Dialog" > extension defined in [RFC4538] to do so. > > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription), the REFER request > MAY be sent within an existing dialog. Such a REFER will be > constructed with its Contact header field populated with the dialog's > Local URI as specified in section 12 of [RFC3261]. A simplest solution I think is to ignore section 4.5.1. There is no problem in backward compatibility. Or someone writes new draft that relaxes the GRUU requirement. Regards, Shinji -------- Original Message -------- > Adam and I spent some time today editing to account for the discussion. >We believe we covered all the concerns raised. > >The sentence in section 3 was getting a bit complex, so we split it up into >several. >Here's what it was before splitting it up: > >A UA that will accept a subscription-creating REFER request needs to include >a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER >requests >related to any dialog created by the INVITE arrive at this UA. > >You can see what it turned into by looking in the draft. > >RjS > > >-------- Original Message -------- Subject: New Version Notification for >draft-sparks-sipcore-refer-clarifications-03.txt > Date: Mon, 28 Jul 2014 15:16:04 -0700 > From: [a:mailto:internet-drafts@ietf.org]internet-drafts@ietf.org > To: Robert Sparks [a:mailto:rjs@nostrum.com], "Adam Roach" >[a:mailto:adam@nostrum.com], Adam Roach [a:mailto: >adam@nostrum.com], "Robert Sparks" [a:mailto:RjS@nostrum. >com] > > >A new version of I-D, draft-sparks-sipcore-refer-clarifications-03.txt >has been successfully submitted by Robert Sparks and posted to the >IETF repository. > >Name: draft-sparks-sipcore-refer-clarifications >Revision: 03 >Title: Clarifications for the use of REFER with RFC6665 >Document date: 2014-07-28 >Group: Individual Submission >Pages: 4 >URL: [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore- >refer-clarifications-03.txt]http://www.ietf.org/internet-drafts/draft-sparks- >sipcore-refer-clarifications-03.txt >Status: [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore- >refer-clarifications/]https://datatracker.ietf.org/doc/draft-sparks-sipcore- >refer-clarifications/ >Htmlized: [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer- >clarifications-03]http://tools.ietf.org/html/draft-sparks-sipcore-refer- >clarifications-03 >Diff: [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore- >refer-clarifications-03]http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore >-refer-clarifications-03 > >Abstract: > An accepted SIP REFER method creates an implicit subscription using > the SIP-Specific Event Notification Framework. That framework was > revised by RFC6665. This document highlights the implications of the > requirement changes in RFC6665, and updates the definition of the > REFER method, RFC3515, to clarify and disambiguate the impact of > those changes. > > > > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat From nobody Thu Aug 7 10:55:06 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240411A01C8 for ; Thu, 7 Aug 2014 10:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SI7W3n2F_X4T for ; Thu, 7 Aug 2014 10:54:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA041A0197 for ; Thu, 7 Aug 2014 10:54:58 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s77HsjwI047591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 7 Aug 2014 12:54:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53E3BD65.5080105@nostrum.com> Date: Thu, 07 Aug 2014 12:54:45 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ivo Sedlacek , Andrew Allen , Adam Roach , "sipcore@ietf.org" References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------030707020507060202010003" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kytSthOm1wWGpcHZxFvg0sBwngc Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 17:55:03 -0000 This is a multi-part message in MIME format. --------------030707020507060202010003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I've spent quite some time trying to understand the push for the proposal below, and I really think there's confusion, so I'm going to try to step up a level and see if we can make progress there. A UA such as your proposed exception clause describes is simply not a compliant 6665 implementation which is what this clarification document is about. If it accepts in-dialog subscription creating REFERs it is following 3265, not 6665 - further it is violating a 6665 requirement. If it accepts no REFERs whatsoever, then it's not affected by this document. If the point of the wordsmithing is to make legacy implementations compliant with 6665, there's no way to succeed - they simply aren't. If that's not the point of the wordsmithing, what is? At the moment, I think what I sent below is still the right path forward. RjS On 8/1/14, 1:44 AM, Ivo Sedlacek wrote: > > Any comments on the proposal below? > > Kind regards > > Ivo Sedlacek > > If a REFER request is accepted (that is, a 2xx class response is > > returned), the recipient MUST create a subscription and send > > notifications of the status of the refer as described in Section > > 2.4.4.*From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of > *Ivo Sedlacek > *Sent:* 31. července 2014 9:26 > *To:* Robert Sparks; Andrew Allen; Adam Roach; sipcore@ietf.org > > *Subject:* Re: [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-clarifications-03.txt > > Hello, > > According to the draft, the purpose of GRUU in Contact of INVITE > request to " > ensures that out-of-dialog REFER requests corresponding to any > resulting INVITE dialogs arrive at this UA." > > If a UA rejects any out-of-dialog REFER requests corresponding to any > dialogs related to an INVITE request, then setting up GRUU in Contact > of INVITE does not provide any purpose. > > This is true __regardless__ whether the UA supports and use the > draft-sparks-sipcore-refer-explicitsub. > > See attached mail giving an example of UA having two types of > sessions, Type_A transferrable by REFER, and Type_B not transferrable > by REFER. > > Given that different standardization organization has defined so many > enablers which can run on a single UA, I find it weird that one can > guarantee that the above cannot occur. > > Thus, I hesitate to mandate an unnecessary requirement influencing > possible existing UA implementations and I prefer to be explicit on > the exception for usage of GRUU in Contact of INVITE request: > > > A UA that will accept a REFER request needs to include > a GRUU in the Contact header field of all INVITE requests. This > ensures that out-of-dialog REFER requests corresponding to any > resulting INVITE dialogs arrive at this UA.>>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request > are exempted from including a GRUU in the Contact header field of the INVITE request.<<< > > Kind regards > > Ivo Sedlacek > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 30. července 2014 18:54 > *To:* Andrew Allen; Adam Roach; Ivo Sedlacek; sipcore@ietf.org > > *Subject:* Re: [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-clarifications-03.txt > > On 7/30/14, 10:33 AM, Andrew Allen wrote: > > I have a general concern with the direction this is now going. > > I don't think you have the backwards-compatibility concern quite > right, but I agree that the current wording isn't there yet. > > Are we now saying here that it’s OK for a UA that supports receiving > REFER to arbitrarily reject any REFER that would create a subscription > (i.e be incompatible with RFC 3515 UACs by basically not supporting > RFC 3515 UAS compliant behavior)? > > No, _this_ document is not defining new behavior. It's only clarifying > what's already defined. > > According to RFC 3515 > > 2.4.4 Using SIP Events to Report the Results of the Reference > > The NOTIFY mechanism defined in [2] MUST be used to > inform the agent sending the REFER of the status of the reference. > > Therefore the ability to create an implicit subscription when accepting > > FWIW, Accepting is the key word here. > > a REFER is mandatory behavior in RFC 3515 and is expected to be > supported by all RFC 3515 UACs > > I think before agreeing any wording here we should have a general > discussion on the principle of whether these extensions that allow > UACs to request that no implicit subscription can be effectively > required by REFER UAS to be supported at the UAC. > > This, and what you have below, is a discussion we definitely need to > have as part of the extension document. > It is not necessary to wait for that discussion to complete the > clarifications document that talks about what the specs say _now_. > > My discomfort with the current text is that we've made it complex to > make it so that we don't have to update the document once the proposed > extensions exist. > There are NO currently standardized cases where the exemption in the > current text would be invoked, and I don't think people are trying to > argue there are - I'm hearing that to get there, they expect to invoke > the yet-to-be-defined extension. > > So, lets go back to the slightly longer sentence that led to this: > > A UA that will accept a subscription-creating REFER request needs to > include > a GRUU as the Contact in all INVITE requests to ensure out-of-dialog > REFER requests > related to any dialog created by the INVITE arrive at this UA. > > In an attempt to be future-proof, that's introducing the potential for > confusion about what the current standards define. > Let's remove that confusion. > Here's a proposed replacement, taking Adam's sentence simplification > into account: > > A UA that will accept a REFER request needs to include > a GRUU in the Contact header field of all INVITE requests. This > ensures that out-of-dialog REFER requests corresponding to any > resulting INVITE dialogs arrive at this UA. Future extensions > [draft-sparks-sipcore-refer-explicitsub] might relax this requirement > by defining a REFER request that cannot create an implicit > subscription. > > > Unless I hear objection soon, I'll rev the draft with that content. > > If so then I think we will need a new sip options tag (e.g > REFER-NOSUB) to be used in place of the REFER options tag so that a > RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of > a REFER and that includes an Accept-Contact request to reach a UA that > supports REFER doesn’t end up at a UAS that doesn’t support compliant > RFC 3515 behavior and ends up having its REFER requests rejected. > > My own view is that we should keep with the principle of backward > compatibility and that even when these no automatic subscription > extensions are supported that full support for RFC 3515 behavior is > continued. > > Andrew > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Adam Roach > *Sent:* Tuesday, July 29, 2014 11:19 AM > *To:* Ivo Sedlacek; Robert Sparks; sipcore@ietf.org > > *Subject:* Re: [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-clarifications-03.txt > > On 7/29/14 09:52, Ivo Sedlacek wrote: > > Thus, the text should state: > > In general, UAs that support receiving >>and accepting an > out-of-dialog<< REFER request >>corresponding to a dialog > established by an INVITE request<< need to include > > a GRUU in the Contact header field of >>the<< INVITE request. This > > ensures that out-of-dialog REFER requests corresponding to any > > resulting INVITE dialogs are routed to the correct user agent. UAs > > that will never create a implicit subscription in response to a > REFER > > (that is, those that will reject any REFER that might result in an > > implicit subscription) are exempted from this behavior. > > > I helped with the phrasing here, and one of the goals here was to make > the first sentence cover the vast majority of the cases (hence "in > general"), with the exceptional cases described later. The problem was > that the overall concept was getting lost in a maze of twisty clauses: > the clarification had become worse than the source text; it was > actually more confusing. > > Your proposal returns it to this very confusing state, and is way, way > out into the realm of exceptional cases. > > So I'll counterpropose: > > In general, UAs that support receiving REFER requests need to include > a GRUU in the Contact header field of all INVITE requests. This > ensures that out-of-dialog REFER requests corresponding to any > resulting INVITE dialogs are routed to the correct user agent. UAs > that will not create a implicit subscription in response to a REFER > for the resulting dialog(s) -- that is, those that will reject a > corresponding REFER that might result in an implicit subscription -- > are exempted from this behavior. > > > /a > --------------030707020507060202010003 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I've spent quite some time trying to understand the push for the proposal below, and I really think there's confusion, so I'm going to try to step up a level and see if we can make progress there.

A UA such as your proposed exception clause describes is simply not a compliant 6665 implementation which is what this clarification document is about.
If it accepts in-dialog subscription creating REFERs it is following 3265, not 6665 - further it is violating a 6665 requirement.
If it accepts no REFERs whatsoever, then it's not affected by this document.

If the point of the wordsmithing is to make legacy implementations compliant with 6665, there's no way to succeed - they simply aren't.

If that's not the point of the wordsmithing, what is?

At the moment, I think what I sent below is still the right path forward.

RjS




On 8/1/14, 1:44 AM, Ivo Sedlacek wrote:

Any comments on the proposal below?

 

Kind regards

 

Ivo Sedlacek

 

 

   If a REFER request is accepted (that is, a 2xx class response is

   returned), the recipient MUST create a subscription and send

   notifications of the status of the refer as described in Section

   2.4.4.From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek
Sent: 31. července 2014 9:26
To: Robert Sparks; Andrew Allen; Adam Roach; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

Hello,

 

According to the draft, the purpose of GRUU in Contact of INVITE request to "
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA."

 

If a UA rejects any out-of-dialog REFER requests corresponding to any dialogs related to an INVITE request, then setting up GRUU in Contact of INVITE does not provide any purpose.

 

This is true __regardless__ whether the UA supports and use the draft-sparks-sipcore-refer-explicitsub.

See attached mail giving an example of UA having two types of sessions, Type_A transferrable by REFER, and Type_B not transferrable by REFER.

Given that different standardization organization has defined so many enablers which can run on a single UA, I find it weird that one can guarantee that the above cannot occur.

 

Thus, I hesitate to mandate an unnecessary requirement influencing possible existing UA implementations and I prefer to be explicit on the exception for usage of GRUU in Contact of INVITE request:

 

 
   A UA that will accept a REFER request needs to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA. >>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request
   are exempted from including a GRUU in the Contact header field of the INVITE request.<<<

 

Kind regards

 

Ivo Sedlacek

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 30. července 2014 18:54
To: Andrew Allen; Adam Roach; Ivo Sedlacek; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

 

On 7/30/14, 10:33 AM, Andrew Allen wrote:

I have a general concern with the direction this is now going.

I don't think you have the backwards-compatibility concern quite right, but I agree that the current wording isn't there yet.

 

Are we now saying here that it’s OK for a UA that supports receiving REFER to arbitrarily reject any REFER that would create a subscription (i.e be incompatible with RFC 3515 UACs by basically not supporting RFC 3515 UAS compliant behavior)?

No, _this_ document is not defining new behavior. It's only clarifying what's already defined.

 

According to RFC 3515

 

2.4.4 Using SIP Events to Report the Results of the Reference

 

                The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference.

 

Therefore the ability to create an implicit subscription when accepting

FWIW, Accepting is the key word here.

a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all RFC 3515 UACs

 

I think before agreeing any wording here we should have a general discussion on the principle of whether these extensions that allow UACs to request that no implicit subscription can be effectively required by REFER UAS to be supported at the UAC.

This, and what you have below, is a discussion we definitely need to have as part of the extension document.
It is not necessary to wait for that discussion to complete the clarifications document that talks about what the specs say _now_.

My discomfort with the current text is that we've made it complex to make it so that we don't have to update the document once the proposed extensions exist.
There are NO currently standardized cases where the exemption in the current text would be invoked, and I don't think people are trying to argue there are - I'm hearing that to get there, they expect to invoke the yet-to-be-defined extension.

So, lets go back to the slightly longer sentence that led to this:

A UA that will accept a subscription-creating REFER request needs to include
a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER requests
related to any dialog created by the INVITE arrive at this UA.

In an attempt to be future-proof, that's introducing the potential for confusion about what the current standards define.
Let's remove that confusion.
Here's a proposed replacement, taking Adam's sentence simplification into account:

   A UA that will accept a REFER request needs to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA. Future extensions
   [draft-sparks-sipcore-refer-explicitsub] might relax this requirement
   by defining a REFER request that cannot create an implicit subscription.


Unless I hear objection soon, I'll rev the draft with that content.

 

If so then I think we will need a new sip options tag (e.g REFER-NOSUB) to be used in place of the REFER options tag so that a RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of a REFER and that includes an Accept-Contact request to reach a UA that supports REFER doesn’t end up at a UAS that doesn’t  support compliant RFC 3515 behavior and ends up having its REFER requests rejected.

 

My own view is that we should keep with the principle of backward compatibility and that even when these no automatic subscription extensions are supported that full support for RFC 3515 behavior is continued.

 

Andrew

 

 

 

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Tuesday, July 29, 2014 11:19 AM
To: Ivo Sedlacek; Robert Sparks; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

On 7/29/14 09:52, Ivo Sedlacek wrote:

 

Thus, the text should state:

 

 

   In general, UAs that support receiving >>and accepting an out-of-dialog<< REFER request >>corresponding to a dialog established by an INVITE request<< need to include

   a GRUU in the Contact header field of >>the<< INVITE request.  This

   ensures that out-of-dialog REFER requests corresponding to any

   resulting INVITE dialogs are routed to the correct user agent.  UAs

   that will never create a implicit subscription in response to a REFER

   (that is, those that will reject any REFER that might result in an

   implicit subscription) are exempted from this behavior.


I helped with the phrasing here, and one of the goals here was to make the first sentence cover the vast majority of the cases (hence "in general"), with the exceptional cases described later. The problem was that the overall concept was getting lost in a maze of twisty clauses: the clarification had become worse than the source text; it was actually more confusing.

Your proposal returns it to this very confusing state, and is way, way out into the realm of exceptional cases.

So I'll counterpropose:

   In general, UAs that support receiving REFER requests need to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs are routed to the correct user agent.  UAs
   that will not create a implicit subscription in response to a REFER
   for the resulting dialog(s) -- that is, those that will reject a
   corresponding REFER that might result in an implicit subscription --
   are exempted from this behavior.


/a

 


--------------030707020507060202010003-- From nobody Tue Aug 12 00:24:12 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5461A0768 for ; Tue, 12 Aug 2014 00:24: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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgslgPXkS-ep for ; Tue, 12 Aug 2014 00:24:07 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B061A075F for ; Tue, 12 Aug 2014 00:24:06 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-02-53e9c113795a Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 49.3C.02247.311C9E35; Tue, 12 Aug 2014 09:24:04 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 09:24:03 +0200 From: Ivo Sedlacek To: Robert Sparks , Andrew Allen , Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPsmi0zYBKyCtO/U25PQfJ1Q5YyZvMkedw Date: Tue, 12 Aug 2014 07:24:03 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> In-Reply-To: <53E3BD65.5080105@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112711567ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3Rlfk4MtggyNzOC3uz9vKaLHn7yJ2 i2tzGtksvv7YxObA4jGrYS27x5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CVsXfBccaCBUuY K5Zc+MfewLhiJnMXIyeHhICJxLWG6awQtpjEhXvr2UBsIYGjjBL7l7pC2EsYJab2ZIDYbAJ6 EhO3HAGq5+IQEZjBKPHz/2tGkISwQLbEyg27wGwRgRyJ/s8tbBC2kUTH7BXsXYwcHCwCqhJv un1BwrwCvhKvlnWygcwREpjCInH92nuwIzgFtCX+v1kF1ssoICtx9U8v2ExmAXGJW0/mM0Ec KiCxZM95qAdEJV4+/scKMl9CQEli2tY0iPJ8iSOH17BB7BKUODnzCcsERpFZSCbNQlI2C0nZ LKBJzAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRkV5qUWZycXF+nl5e askmRmDUHdzy22oH48HnjocYBTgYlXh4F7C8DBZiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYz2zmdu7K0V+JX75WjqTL9pDmUyTb6mDG8lTie7+mQK7TrZ c211bGC02/+mhIQ0/XjW82Y/jx8M2xFjunA374zt+ewlzzweudyLdHON40yYWvT/fL+QY3rA VKe49UGLg1s1vx0M+WCsUN6ernxXIdOlrJhXbE+uXvmyvH6DbTyd4ZtWxXfIK7EUZyQaajEX FScCAOFJE2qbAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/rSEEyLd8haCZTqNGHIefHIU_JGE Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 07:24:10 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112711567ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNClRoZXJlIHN0aWxsIHNlZW1zIHRvIGJlIG1pc3VuZGVyc3RhbmRpbmcuIExldCBt ZSBzdGF0ZSBteSBpc3N1ZSBpbiBhIGRpZmZlcmVudCBhbmQgbW9yZSBnZW5lcmFsIHdheToNCg0K SWY6DQotIGEgVUUgc3VwcG9ydHMgcmVjZWl2aW5nIGFuZCBhY2NlcHRpbmcgb2Ygb3V0LW9mLWRp YWxvZyBSRUZFUiByZXF1ZXN0IHJlbGF0ZWQgdG8gZGlhbG9ncyBjcmVhdGVkIGJ5IHNvbWUgKGJ1 dCBub3QgYWxsKSBJTlZJVEUgcmVxdWVzdHM7IGFuZA0KLSBmb3IgYSBwYXJ0aWN1bGFyIElOVklU RSByZXF1ZXN0LCB0aGUgVUEgcmVqZWN0cyBhbnkgb3V0LW9mLWRpYWxvZyBSRUZFUnMgcmVsYXRl ZCB0byBkaWFsb2dzIGNyZWF0ZWQgYnkgdGhlIHBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3Q7DQpz aG91bGQgdGhlIFVFIGJlIHN0aWxsIG1hbmRhdGVkIHRvIHB1dCBHUlVVIGluIHRoZSBDb250YWN0 IG9mIHRoZSBwYXJ0aWN1bGFyIElOVklURSByZXF1ZXN0PyBJZiBzbywgd2hhdCB3aWxsIHRoZSBH UlVVIGJlIHVzZWQgZm9yPw0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBxdWVzdGlvbiBhYm92ZSBm b2N1c2VzIHNvbGVseSBvbiBvdXQtb2YtZGlhbG9nIFJFRkVScy4NCg0KS2luZCByZWdhcmRzDQoN Ckl2byBTZWRsYWNlaw0KDQoNClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdl IG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNl dCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPGh0dHA6Ly93d3cuZXJp Y3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+DQpGcm9tOiBSb2JlcnQgU3BhcmtzIFttYWlsdG86 cmpzcGFya3NAbm9zdHJ1bS5jb21dDQpTZW50OiA3LiBzcnBuYSAyMDE0IDE5OjU1DQpUbzogSXZv IFNlZGxhY2VrOyBBbmRyZXcgQWxsZW47IEFkYW0gUm9hY2g7IHNpcGNvcmVAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dA0KDQpJJ3ZlIHNw ZW50IHF1aXRlIHNvbWUgdGltZSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgcHVzaCBmb3IgdGhl IHByb3Bvc2FsIGJlbG93LCBhbmQgSSByZWFsbHkgdGhpbmsgdGhlcmUncyBjb25mdXNpb24sIHNv IEknbSBnb2luZyB0byB0cnkgdG8gc3RlcCB1cCBhIGxldmVsIGFuZCBzZWUgaWYgd2UgY2FuIG1h a2UgcHJvZ3Jlc3MgdGhlcmUuDQoNCkEgVUEgc3VjaCBhcyB5b3VyIHByb3Bvc2VkIGV4Y2VwdGlv biBjbGF1c2UgZGVzY3JpYmVzIGlzIHNpbXBseSBub3QgYSBjb21wbGlhbnQgNjY2NSBpbXBsZW1l bnRhdGlvbiB3aGljaCBpcyB3aGF0IHRoaXMgY2xhcmlmaWNhdGlvbiBkb2N1bWVudCBpcyBhYm91 dC4NCklmIGl0IGFjY2VwdHMgaW4tZGlhbG9nIHN1YnNjcmlwdGlvbiBjcmVhdGluZyBSRUZFUnMg aXQgaXMgZm9sbG93aW5nIDMyNjUsIG5vdCA2NjY1IC0gZnVydGhlciBpdCBpcyB2aW9sYXRpbmcg YSA2NjY1IHJlcXVpcmVtZW50Lg0KSWYgaXQgYWNjZXB0cyBubyBSRUZFUnMgd2hhdHNvZXZlciwg dGhlbiBpdCdzIG5vdCBhZmZlY3RlZCBieSB0aGlzIGRvY3VtZW50Lg0KDQpJZiB0aGUgcG9pbnQg b2YgdGhlIHdvcmRzbWl0aGluZyBpcyB0byBtYWtlIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbnMgY29t cGxpYW50IHdpdGggNjY2NSwgdGhlcmUncyBubyB3YXkgdG8gc3VjY2VlZCAtIHRoZXkgc2ltcGx5 IGFyZW4ndC4NCg0KSWYgdGhhdCdzIG5vdCB0aGUgcG9pbnQgb2YgdGhlIHdvcmRzbWl0aGluZywg d2hhdCBpcz8NCg0KQXQgdGhlIG1vbWVudCwgSSB0aGluayB3aGF0IEkgc2VudCBiZWxvdyBpcyBz dGlsbCB0aGUgcmlnaHQgcGF0aCBmb3J3YXJkLg0KDQpSalMNCg0KDQoNCk9uIDgvMS8xNCwgMTo0 NCBBTSwgSXZvIFNlZGxhY2VrIHdyb3RlOg0KQW55IGNvbW1lbnRzIG9uIHRoZSBwcm9wb3NhbCBi ZWxvdz8NCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQoNCiAgIElmIGEgUkVGRVIg cmVxdWVzdCBpcyBhY2NlcHRlZCAodGhhdCBpcywgYSAyeHggY2xhc3MgcmVzcG9uc2UgaXMNCiAg IHJldHVybmVkKSwgdGhlIHJlY2lwaWVudCBNVVNUIGNyZWF0ZSBhIHN1YnNjcmlwdGlvbiBhbmQg c2VuZA0KICAgbm90aWZpY2F0aW9ucyBvZiB0aGUgc3RhdHVzIG9mIHRoZSByZWZlciBhcyBkZXNj cmliZWQgaW4gU2VjdGlvbg0KICAgMi40LjQuRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEl2byBTZWRsYWNlaw0KU2VudDogMzEuIMSN ZXJ2ZW5jZSAyMDE0IDk6MjYNClRvOiBSb2JlcnQgU3BhcmtzOyBBbmRyZXcgQWxsZW47IEFkYW0g Um9hY2g7IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1z cGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQNCg0KSGVsbG8sDQoNCkFj Y29yZGluZyB0byB0aGUgZHJhZnQsIHRoZSBwdXJwb3NlIG9mIEdSVVUgaW4gQ29udGFjdCBvZiBJ TlZJVEUgcmVxdWVzdCB0byAiDQogICBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiBy ZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueQ0KICAgcmVzdWx0aW5nIElOVklURSBkaWFsb2dz IGFycml2ZSBhdCB0aGlzIFVBLiINCg0KSWYgYSBVQSByZWplY3RzIGFueSBvdXQtb2YtZGlhbG9n IFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55IGRpYWxvZ3MgcmVsYXRlZCB0byBh biBJTlZJVEUgcmVxdWVzdCwgdGhlbiBzZXR0aW5nIHVwIEdSVVUgaW4gQ29udGFjdCBvZiBJTlZJ VEUgZG9lcyBub3QgcHJvdmlkZSBhbnkgcHVycG9zZS4NCg0KVGhpcyBpcyB0cnVlIF9fcmVnYXJk bGVzc19fIHdoZXRoZXIgdGhlIFVBIHN1cHBvcnRzIGFuZCB1c2UgdGhlIGRyYWZ0LXNwYXJrcy1z aXBjb3JlLXJlZmVyLWV4cGxpY2l0c3ViLg0KU2VlIGF0dGFjaGVkIG1haWwgZ2l2aW5nIGFuIGV4 YW1wbGUgb2YgVUEgaGF2aW5nIHR3byB0eXBlcyBvZiBzZXNzaW9ucywgVHlwZV9BIHRyYW5zZmVy cmFibGUgYnkgUkVGRVIsIGFuZCBUeXBlX0Igbm90IHRyYW5zZmVycmFibGUgYnkgUkVGRVIuDQpH aXZlbiB0aGF0IGRpZmZlcmVudCBzdGFuZGFyZGl6YXRpb24gb3JnYW5pemF0aW9uIGhhcyBkZWZp bmVkIHNvIG1hbnkgZW5hYmxlcnMgd2hpY2ggY2FuIHJ1biBvbiBhIHNpbmdsZSBVQSwgSSBmaW5k IGl0IHdlaXJkIHRoYXQgb25lIGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgYWJvdmUgY2Fubm90IG9j Y3VyLg0KDQpUaHVzLCBJIGhlc2l0YXRlIHRvIG1hbmRhdGUgYW4gdW5uZWNlc3NhcnkgcmVxdWly ZW1lbnQgaW5mbHVlbmNpbmcgcG9zc2libGUgZXhpc3RpbmcgVUEgaW1wbGVtZW50YXRpb25zIGFu ZCBJIHByZWZlciB0byBiZSBleHBsaWNpdCBvbiB0aGUgZXhjZXB0aW9uIGZvciB1c2FnZSBvZiBH UlVVIGluIENvbnRhY3Qgb2YgSU5WSVRFIHJlcXVlc3Q6DQoNCg0KDQoNCiAgIEEgVUEgdGhhdCB3 aWxsIGFjY2VwdCBhIFJFRkVSIHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZQ0KDQogICBhIEdSVVUg aW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mIGFsbCBJTlZJVEUgcmVxdWVzdHMuICBUaGlz DQoNCiAgIGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3Bv bmRpbmcgdG8gYW55DQoNCiAgIHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUgYXQgdGhp cyBVQS4gPj4+VUFzIHRoYXQgd2lsbCBub3QgYWNjZXB0IGFueSBvdXQtb2YtZGlhbG9nIFJFRkVS IHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gZGlhbG9nKHMpIGNyZWF0ZWQgYnkgYW4gSU5WSVRF IHJlcXVlc3QNCg0KICAgYXJlIGV4ZW1wdGVkIGZyb20gaW5jbHVkaW5nIGEgR1JVVSBpbiB0aGUg Q29udGFjdCBoZWFkZXIgZmllbGQgb2YgdGhlIElOVklURSByZXF1ZXN0Ljw8PA0KDQpLaW5kIHJl Z2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoNCg0KRnJvbTogUm9iZXJ0IFNwYXJrcyBbbWFpbHRvOnJq c3BhcmtzQG5vc3RydW0uY29tXQ0KU2VudDogMzAuIMSNZXJ2ZW5jZSAyMDE0IDE4OjU0DQpUbzog QW5kcmV3IEFsbGVuOyBBZGFtIFJvYWNoOyBJdm8gU2VkbGFjZWs7IHNpcGNvcmVAaWV0Zi5vcmc8 bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFy aWZpY2F0aW9ucy0wMy50eHQNCg0KDQpPbiA3LzMwLzE0LCAxMDozMyBBTSwgQW5kcmV3IEFsbGVu IHdyb3RlOg0KSSBoYXZlIGEgZ2VuZXJhbCBjb25jZXJuIHdpdGggdGhlIGRpcmVjdGlvbiB0aGlz IGlzIG5vdyBnb2luZy4NCkkgZG9uJ3QgdGhpbmsgeW91IGhhdmUgdGhlIGJhY2t3YXJkcy1jb21w YXRpYmlsaXR5IGNvbmNlcm4gcXVpdGUgcmlnaHQsIGJ1dCBJIGFncmVlIHRoYXQgdGhlIGN1cnJl bnQgd29yZGluZyBpc24ndCB0aGVyZSB5ZXQuDQoNCkFyZSB3ZSBub3cgc2F5aW5nIGhlcmUgdGhh dCBpdOKAmXMgT0sgZm9yIGEgVUEgdGhhdCBzdXBwb3J0cyByZWNlaXZpbmcgUkVGRVIgdG8gYXJi aXRyYXJpbHkgcmVqZWN0IGFueSBSRUZFUiB0aGF0IHdvdWxkIGNyZWF0ZSBhIHN1YnNjcmlwdGlv biAoaS5lIGJlIGluY29tcGF0aWJsZSB3aXRoIFJGQyAzNTE1IFVBQ3MgYnkgYmFzaWNhbGx5IG5v dCBzdXBwb3J0aW5nIFJGQyAzNTE1IFVBUyBjb21wbGlhbnQgYmVoYXZpb3IpPw0KTm8sIF90aGlz XyBkb2N1bWVudCBpcyBub3QgZGVmaW5pbmcgbmV3IGJlaGF2aW9yLiBJdCdzIG9ubHkgY2xhcmlm eWluZyB3aGF0J3MgYWxyZWFkeSBkZWZpbmVkLg0KDQoNCg0KQWNjb3JkaW5nIHRvIFJGQyAzNTE1 DQoNCjIuNC40IFVzaW5nIFNJUCBFdmVudHMgdG8gUmVwb3J0IHRoZSBSZXN1bHRzIG9mIHRoZSBS ZWZlcmVuY2UNCg0KICAgICAgICAgICAgICAgIFRoZSBOT1RJRlkgbWVjaGFuaXNtIGRlZmluZWQg aW4gWzJdIE1VU1QgYmUgdXNlZCB0byBpbmZvcm0gdGhlIGFnZW50IHNlbmRpbmcgdGhlIFJFRkVS IG9mIHRoZSBzdGF0dXMgb2YgdGhlIHJlZmVyZW5jZS4NCg0KVGhlcmVmb3JlIHRoZSBhYmlsaXR5 IHRvIGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gd2hlbiBhY2NlcHRpbmcNCkZXSVcs IEFjY2VwdGluZyBpcyB0aGUga2V5IHdvcmQgaGVyZS4NCmEgUkVGRVIgaXMgbWFuZGF0b3J5IGJl aGF2aW9yIGluIFJGQyAzNTE1IGFuZCBpcyBleHBlY3RlZCB0byBiZSBzdXBwb3J0ZWQgYnkgYWxs IFJGQyAzNTE1IFVBQ3MNCg0KSSB0aGluayBiZWZvcmUgYWdyZWVpbmcgYW55IHdvcmRpbmcgaGVy ZSB3ZSBzaG91bGQgaGF2ZSBhIGdlbmVyYWwgZGlzY3Vzc2lvbiBvbiB0aGUgcHJpbmNpcGxlIG9m IHdoZXRoZXIgdGhlc2UgZXh0ZW5zaW9ucyB0aGF0IGFsbG93IFVBQ3MgdG8gcmVxdWVzdCB0aGF0 IG5vIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBjYW4gYmUgZWZmZWN0aXZlbHkgcmVxdWlyZWQgYnkg UkVGRVIgVUFTIHRvIGJlIHN1cHBvcnRlZCBhdCB0aGUgVUFDLg0KVGhpcywgYW5kIHdoYXQgeW91 IGhhdmUgYmVsb3csIGlzIGEgZGlzY3Vzc2lvbiB3ZSBkZWZpbml0ZWx5IG5lZWQgdG8gaGF2ZSBh cyBwYXJ0IG9mIHRoZSBleHRlbnNpb24gZG9jdW1lbnQuDQpJdCBpcyBub3QgbmVjZXNzYXJ5IHRv IHdhaXQgZm9yIHRoYXQgZGlzY3Vzc2lvbiB0byBjb21wbGV0ZSB0aGUgY2xhcmlmaWNhdGlvbnMg ZG9jdW1lbnQgdGhhdCB0YWxrcyBhYm91dCB3aGF0IHRoZSBzcGVjcyBzYXkgX25vd18uDQoNCk15 IGRpc2NvbWZvcnQgd2l0aCB0aGUgY3VycmVudCB0ZXh0IGlzIHRoYXQgd2UndmUgbWFkZSBpdCBj b21wbGV4IHRvIG1ha2UgaXQgc28gdGhhdCB3ZSBkb24ndCBoYXZlIHRvIHVwZGF0ZSB0aGUgZG9j dW1lbnQgb25jZSB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9ucyBleGlzdC4NClRoZXJlIGFyZSBOTyBj dXJyZW50bHkgc3RhbmRhcmRpemVkIGNhc2VzIHdoZXJlIHRoZSBleGVtcHRpb24gaW4gdGhlIGN1 cnJlbnQgdGV4dCB3b3VsZCBiZSBpbnZva2VkLCBhbmQgSSBkb24ndCB0aGluayBwZW9wbGUgYXJl IHRyeWluZyB0byBhcmd1ZSB0aGVyZSBhcmUgLSBJJ20gaGVhcmluZyB0aGF0IHRvIGdldCB0aGVy ZSwgdGhleSBleHBlY3QgdG8gaW52b2tlIHRoZSB5ZXQtdG8tYmUtZGVmaW5lZCBleHRlbnNpb24u DQoNClNvLCBsZXRzIGdvIGJhY2sgdG8gdGhlIHNsaWdodGx5IGxvbmdlciBzZW50ZW5jZSB0aGF0 IGxlZCB0byB0aGlzOg0KDQpBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBzdWJzY3JpcHRpb24tY3Jl YXRpbmcgUkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlDQphIEdSVVUgYXMgdGhlIENvbnRh Y3QgaW4gYWxsIElOVklURSByZXF1ZXN0cyB0byBlbnN1cmUgb3V0LW9mLWRpYWxvZyBSRUZFUiBy ZXF1ZXN0cw0KcmVsYXRlZCB0byBhbnkgZGlhbG9nIGNyZWF0ZWQgYnkgdGhlIElOVklURSBhcnJp dmUgYXQgdGhpcyBVQS4NCg0KSW4gYW4gYXR0ZW1wdCB0byBiZSBmdXR1cmUtcHJvb2YsIHRoYXQn cyBpbnRyb2R1Y2luZyB0aGUgcG90ZW50aWFsIGZvciBjb25mdXNpb24gYWJvdXQgd2hhdCB0aGUg Y3VycmVudCBzdGFuZGFyZHMgZGVmaW5lLg0KTGV0J3MgcmVtb3ZlIHRoYXQgY29uZnVzaW9uLg0K SGVyZSdzIGEgcHJvcG9zZWQgcmVwbGFjZW1lbnQsIHRha2luZyBBZGFtJ3Mgc2VudGVuY2Ugc2lt cGxpZmljYXRpb24gaW50byBhY2NvdW50Og0KDQogICBBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBS RUZFUiByZXF1ZXN0IG5lZWRzIHRvIGluY2x1ZGUNCiAgIGEgR1JVVSBpbiB0aGUgQ29udGFjdCBo ZWFkZXIgZmllbGQgb2YgYWxsIElOVklURSByZXF1ZXN0cy4gIFRoaXMNCiAgIGVuc3VyZXMgdGhh dCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55DQogICBy ZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJyaXZlIGF0IHRoaXMgVUEuIEZ1dHVyZSBleHRlbnNp b25zDQogICBbZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItZXhwbGljaXRzdWJdIG1pZ2h0IHJl bGF4IHRoaXMgcmVxdWlyZW1lbnQNCiAgIGJ5IGRlZmluaW5nIGEgUkVGRVIgcmVxdWVzdCB0aGF0 IGNhbm5vdCBjcmVhdGUgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uLg0KDQoNClVubGVzcyBJIGhl YXIgb2JqZWN0aW9uIHNvb24sIEknbGwgcmV2IHRoZSBkcmFmdCB3aXRoIHRoYXQgY29udGVudC4N Cg0KDQoNCklmIHNvIHRoZW4gSSB0aGluayB3ZSB3aWxsIG5lZWQgYSBuZXcgc2lwIG9wdGlvbnMg dGFnIChlLmcgUkVGRVItTk9TVUIpIHRvIGJlIHVzZWQgaW4gcGxhY2Ugb2YgdGhlIFJFRkVSIG9w dGlvbnMgdGFnIHNvIHRoYXQgYSBSRkMgMzUxNSBjb21wbGlhbnQgVUEgdGhhdCBleHBlY3RzIGEg Tk9USUZZIHRvIGJlIHNlbnQgdXBvbiByZWNlaXB0IG9mIGEgUkVGRVIgYW5kIHRoYXQgaW5jbHVk ZXMgYW4gQWNjZXB0LUNvbnRhY3QgcmVxdWVzdCB0byByZWFjaCBhIFVBIHRoYXQgc3VwcG9ydHMg UkVGRVIgZG9lc27igJl0IGVuZCB1cCBhdCBhIFVBUyB0aGF0IGRvZXNu4oCZdCAgc3VwcG9ydCBj b21wbGlhbnQgUkZDIDM1MTUgYmVoYXZpb3IgYW5kIGVuZHMgdXAgaGF2aW5nIGl0cyBSRUZFUiBy ZXF1ZXN0cyByZWplY3RlZC4NCg0KTXkgb3duIHZpZXcgaXMgdGhhdCB3ZSBzaG91bGQga2VlcCB3 aXRoIHRoZSBwcmluY2lwbGUgb2YgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBhbmQgdGhhdCBldmVu IHdoZW4gdGhlc2Ugbm8gYXV0b21hdGljIHN1YnNjcmlwdGlvbiBleHRlbnNpb25zIGFyZSBzdXBw b3J0ZWQgdGhhdCBmdWxsIHN1cHBvcnQgZm9yIFJGQyAzNTE1IGJlaGF2aW9yIGlzIGNvbnRpbnVl ZC4NCg0KQW5kcmV3DQoNCg0KDQoNCg0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNClNlbnQ6IFR1ZXNkYXksIEp1 bHkgMjksIDIwMTQgMTE6MTkgQU0NClRvOiBJdm8gU2VkbGFjZWs7IFJvYmVydCBTcGFya3M7IHNp cGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Np cGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFya3Mtc2lw Y29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQNCg0KT24gNy8yOS8xNCAwOTo1MiwgSXZv IFNlZGxhY2VrIHdyb3RlOg0KDQpUaHVzLCB0aGUgdGV4dCBzaG91bGQgc3RhdGU6DQoNCg0KICAg SW4gZ2VuZXJhbCwgVUFzIHRoYXQgc3VwcG9ydCByZWNlaXZpbmcgPj5hbmQgYWNjZXB0aW5nIGFu IG91dC1vZi1kaWFsb2c8PCBSRUZFUiByZXF1ZXN0ID4+Y29ycmVzcG9uZGluZyB0byBhIGRpYWxv ZyBlc3RhYmxpc2hlZCBieSBhbiBJTlZJVEUgcmVxdWVzdDw8IG5lZWQgdG8gaW5jbHVkZQ0KICAg YSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiA+PnRoZTw8IElOVklURSByZXF1 ZXN0LiAgVGhpcw0KICAgZW5zdXJlcyB0aGF0IG91dC1vZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMg Y29ycmVzcG9uZGluZyB0byBhbnkNCiAgIHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcmUgcm91 dGVkIHRvIHRoZSBjb3JyZWN0IHVzZXIgYWdlbnQuICBVQXMNCiAgIHRoYXQgd2lsbCBuZXZlciBj cmVhdGUgYSBpbXBsaWNpdCBzdWJzY3JpcHRpb24gaW4gcmVzcG9uc2UgdG8gYSBSRUZFUg0KICAg KHRoYXQgaXMsIHRob3NlIHRoYXQgd2lsbCByZWplY3QgYW55IFJFRkVSIHRoYXQgbWlnaHQgcmVz dWx0IGluIGFuDQogICBpbXBsaWNpdCBzdWJzY3JpcHRpb24pIGFyZSBleGVtcHRlZCBmcm9tIHRo aXMgYmVoYXZpb3IuDQoNCkkgaGVscGVkIHdpdGggdGhlIHBocmFzaW5nIGhlcmUsIGFuZCBvbmUg b2YgdGhlIGdvYWxzIGhlcmUgd2FzIHRvIG1ha2UgdGhlIGZpcnN0IHNlbnRlbmNlIGNvdmVyIHRo ZSB2YXN0IG1ham9yaXR5IG9mIHRoZSBjYXNlcyAoaGVuY2UgImluIGdlbmVyYWwiKSwgd2l0aCB0 aGUgZXhjZXB0aW9uYWwgY2FzZXMgZGVzY3JpYmVkIGxhdGVyLiBUaGUgcHJvYmxlbSB3YXMgdGhh dCB0aGUgb3ZlcmFsbCBjb25jZXB0IHdhcyBnZXR0aW5nIGxvc3QgaW4gYSBtYXplIG9mIHR3aXN0 eSBjbGF1c2VzOiB0aGUgY2xhcmlmaWNhdGlvbiBoYWQgYmVjb21lIHdvcnNlIHRoYW4gdGhlIHNv dXJjZSB0ZXh0OyBpdCB3YXMgYWN0dWFsbHkgbW9yZSBjb25mdXNpbmcuDQoNCllvdXIgcHJvcG9z YWwgcmV0dXJucyBpdCB0byB0aGlzIHZlcnkgY29uZnVzaW5nIHN0YXRlLCBhbmQgaXMgd2F5LCB3 YXkgb3V0IGludG8gdGhlIHJlYWxtIG9mIGV4Y2VwdGlvbmFsIGNhc2VzLg0KDQpTbyBJJ2xsIGNv dW50ZXJwcm9wb3NlOg0KDQogICBJbiBnZW5lcmFsLCBVQXMgdGhhdCBzdXBwb3J0IHJlY2Vpdmlu ZyBSRUZFUiByZXF1ZXN0cyBuZWVkIHRvIGluY2x1ZGUNCg0KICAgYSBHUlVVIGluIHRoZSBDb250 YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiAgVGhpcw0KDQogICBlbnN1 cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFu eQ0KDQogICByZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJlIHJvdXRlZCB0byB0aGUgY29ycmVj dCB1c2VyIGFnZW50LiAgVUFzDQoNCiAgIHRoYXQgd2lsbCBub3QgY3JlYXRlIGEgaW1wbGljaXQg c3Vic2NyaXB0aW9uIGluIHJlc3BvbnNlIHRvIGEgUkVGRVINCg0KICAgZm9yIHRoZSByZXN1bHRp bmcgZGlhbG9nKHMpIC0tIHRoYXQgaXMsIHRob3NlIHRoYXQgd2lsbCByZWplY3QgYQ0KDQogICBj b3JyZXNwb25kaW5nIFJFRkVSIHRoYXQgbWlnaHQgcmVzdWx0IGluIGFuIGltcGxpY2l0IHN1YnNj cmlwdGlvbiAtLQ0KDQogICBhcmUgZXhlbXB0ZWQgZnJvbSB0aGlzIGJlaGF2aW9yLg0KDQovYQ0K DQoNCg0K --_000_39B5E4D390E9BD4890E2B3107900610112711567ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiNDMDUwNEQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiNDMDUwNEQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6I0MwNTA0RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj QzA1MDREO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiNDMDUwNEQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojQzA1MDREIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+VGhlcmUgc3RpbGwgc2VlbXMgdG8gYmUg bWlzdW5kZXJzdGFuZGluZy4gTGV0IG1lIHN0YXRlIG15IGlzc3VlIGluIGEgZGlmZmVyZW50IGFu ZCBtb3JlIGdlbmVyYWwgd2F5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5JZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQi Pi0gYSBVRSBzdXBwb3J0cyByZWNlaXZpbmcgYW5kIGFjY2VwdGluZyBvZiBvdXQtb2YtZGlhbG9n IFJFRkVSIHJlcXVlc3QgcmVsYXRlZCB0byBkaWFsb2dzIGNyZWF0ZWQgYnkNCjx1PnNvbWUgKGJ1 dCBub3QgYWxsKTwvdT4gSU5WSVRFIHJlcXVlc3RzOyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiND MDUwNEQiPi0gZm9yDQo8dT5hIHBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3Q8L3U+LCB0aGUgVUEg cmVqZWN0cyBhbnkgb3V0LW9mLWRpYWxvZyBSRUZFUnMgcmVsYXRlZCB0byBkaWFsb2dzIGNyZWF0 ZWQgYnkgdGhlIHBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj QzA1MDREIj5zaG91bGQgdGhlIFVFIGJlIHN0aWxsIG1hbmRhdGVkIHRvIHB1dCBHUlVVIGluIHRo ZSBDb250YWN0IG9mDQo8dT50aGUgcGFydGljdWxhciBJTlZJVEUgcmVxdWVzdDwvdT4/IElmIHNv LCB3aGF0IHdpbGwgdGhlIEdSVVUgYmUgdXNlZCBmb3I/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1 MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPlBsZWFzZSBub3RlIHRoYXQg dGhlIHF1ZXN0aW9uIGFib3ZlIGZvY3VzZXMgc29sZWx5IG9uIG91dC1vZi1kaWFsb2cgUkVGRVJz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj QzA1MDREIj5LaW5kIHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+SXZvIFNlZGxhY2VrPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMzMzMzMzIj5UaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFs LiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt cyBzZXQgb3V0IGF0DQo8YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNj bGFpbWVyIiB0aXRsZT0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciI+ DQp3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8L2E+IDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ IFJvYmVydCBTcGFya3MgW21haWx0bzpyanNwYXJrc0Bub3N0cnVtLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiA3LiBzcnBuYSAyMDE0IDE5OjU1PGJyPg0KPGI+VG86PC9iPiBJdm8gU2VkbGFjZWs7 IEFuZHJldyBBbGxlbjsgQWRhbSBSb2FjaDsgc2lwY29yZUBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPkkndmUgc3BlbnQgcXVpdGUgc29tZSB0aW1lIHRyeWluZyB0byB1bmRlcnN0YW5k IHRoZSBwdXNoIGZvciB0aGUgcHJvcG9zYWwgYmVsb3csIGFuZCBJIHJlYWxseSB0aGluayB0aGVy ZSdzIGNvbmZ1c2lvbiwgc28gSSdtIGdvaW5nIHRvIHRyeSB0byBzdGVwIHVwIGEgbGV2ZWwgYW5k IHNlZSBpZiB3ZSBjYW4gbWFrZSBwcm9ncmVzcyB0aGVyZS48YnI+DQo8YnI+DQpBIFVBIHN1Y2gg YXMgeW91ciBwcm9wb3NlZCBleGNlcHRpb24gY2xhdXNlIGRlc2NyaWJlcyBpcyBzaW1wbHkgbm90 IGEgY29tcGxpYW50IDY2NjUgaW1wbGVtZW50YXRpb24gd2hpY2ggaXMgd2hhdCB0aGlzIGNsYXJp ZmljYXRpb24gZG9jdW1lbnQgaXMgYWJvdXQuPGJyPg0KSWYgaXQgYWNjZXB0cyBpbi1kaWFsb2cg c3Vic2NyaXB0aW9uIGNyZWF0aW5nIFJFRkVScyBpdCBpcyBmb2xsb3dpbmcgMzI2NSwgbm90IDY2 NjUgLSBmdXJ0aGVyIGl0IGlzIHZpb2xhdGluZyBhIDY2NjUgcmVxdWlyZW1lbnQuPGJyPg0KSWYg aXQgYWNjZXB0cyBubyBSRUZFUnMgd2hhdHNvZXZlciwgdGhlbiBpdCdzIG5vdCBhZmZlY3RlZCBi eSB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NCklmIHRoZSBwb2ludCBvZiB0aGUgd29yZHNtaXRo aW5nIGlzIHRvIG1ha2UgbGVnYWN5IGltcGxlbWVudGF0aW9ucyBjb21wbGlhbnQgd2l0aCA2NjY1 LCB0aGVyZSdzIG5vIHdheSB0byBzdWNjZWVkIC0gdGhleSBzaW1wbHkgYXJlbid0Ljxicj4NCjxi cj4NCklmIHRoYXQncyBub3QgdGhlIHBvaW50IG9mIHRoZSB3b3Jkc21pdGhpbmcsIHdoYXQgaXM/ PGJyPg0KPGJyPg0KQXQgdGhlIG1vbWVudCwgSSB0aGluayB3aGF0IEkgc2VudCBiZWxvdyBpcyBz dGlsbCB0aGUgcmlnaHQgcGF0aCBmb3J3YXJkLjxicj4NCjxicj4NClJqUzxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDgvMS8xNCwgMTo0NCBBTSwgSXZvIFNlZGxhY2VrIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6I0MwNTA0RCI+QW55IGNvbW1lbnRzIG9uIHRoZSBwcm9wb3NhbCBiZWxvdz88L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+S2lu ZCByZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiNDMDUwNEQiPkl2byBTZWRsYWNlazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPiZuYnNwOyZuYnNw OyBJZiBhIFJFRkVSIHJlcXVlc3QgaXMgYWNjZXB0ZWQgKHRoYXQgaXMsIGEgMnh4IGNsYXNzIHJl c3BvbnNlIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPiZuYnNwOyZuYnNwOyByZXR1cm5l ZCksIHRoZSByZWNpcGllbnQgTVVTVCBjcmVhdGUgYSBzdWJzY3JpcHRpb24gYW5kIHNlbmQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7Jm5ic3A7IG5vdGlmaWNhdGlvbnMgb2YgdGhl IHN0YXR1cyBvZiB0aGUgcmVmZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb248L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzMzMzMzMyI+Jm5ic3A7Jm5ic3A7IDIuNC40Ljwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+DQogc2lwY29yZSBbPGEgaHJlZj0i bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkl2byBTZWRsYWNlazxicj4NCjxiPlNl bnQ6PC9iPiAzMS4gxI1lcnZlbmNlIDIwMTQgOToyNjxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFNw YXJrczsgQW5kcmV3IEFsbGVuOyBBZGFtIFJvYWNoOyA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBp ZXRmLm9yZyI+DQpzaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFya3Mt c2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiNDMDUwNEQiPkhlbGxvLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojQzA1MDREIj5BY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LCB0aGUgcHVycG9z ZSBvZiBHUlVVIGluIENvbnRhY3Qgb2YgSU5WSVRFIHJlcXVlc3QgdG8gJnF1b3Q7PC9zcGFuPjxi cj4NCiZuYnNwOyZuYnNwOyBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0 cyBjb3JyZXNwb25kaW5nIHRvIGFueTxicj4NCiZuYnNwOyZuYnNwOyByZXN1bHRpbmcgSU5WSVRF IGRpYWxvZ3MgYXJyaXZlIGF0IHRoaXMgVUEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojQzA1MDREIj4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+SWYgYSBVQSByZWplY3RzIGFueSBvdXQtb2YtZGlhbG9n IFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55IGRpYWxvZ3MgcmVsYXRlZCB0byBh biBJTlZJVEUgcmVxdWVzdCwgdGhlbiBzZXR0aW5nIHVwIEdSVVUgaW4gQ29udGFjdCBvZiBJTlZJ VEUgZG9lcyBub3QNCiBwcm92aWRlIGFueSBwdXJwb3NlLiA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiND MDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+VGhpcyBpcyB0cnVlIF9f cmVnYXJkbGVzc19fIHdoZXRoZXIgdGhlIFVBIHN1cHBvcnRzIGFuZCB1c2UgdGhlDQo8L3NwYW4+ ZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItZXhwbGljaXRzdWIuIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1 MDREIj5TZWUgYXR0YWNoZWQgbWFpbCBnaXZpbmcgYW4gZXhhbXBsZSBvZiBVQSBoYXZpbmcgdHdv IHR5cGVzIG9mIHNlc3Npb25zLCBUeXBlX0EgdHJhbnNmZXJyYWJsZSBieSBSRUZFUiwgYW5kIFR5 cGVfQiBub3QgdHJhbnNmZXJyYWJsZSBieSBSRUZFUi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUw NEQiPkdpdmVuIHRoYXQgZGlmZmVyZW50IHN0YW5kYXJkaXphdGlvbiBvcmdhbml6YXRpb24gaGFz IGRlZmluZWQgc28gbWFueSBlbmFibGVycyB3aGljaCBjYW4gcnVuIG9uIGEgc2luZ2xlIFVBLCBJ IGZpbmQgaXQgd2VpcmQgdGhhdCBvbmUgY2FuIGd1YXJhbnRlZSB0aGF0IHRoZSBhYm92ZQ0KIGNh bm5vdCBvY2N1ci4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPlRodXMsIEkgaGVzaXRhdGUgdG8gbWFuZGF0ZSBhbiB1bm5lY2Vz c2FyeSByZXF1aXJlbWVudCBpbmZsdWVuY2luZyBwb3NzaWJsZSBleGlzdGluZyBVQSBpbXBsZW1l bnRhdGlvbnMgYW5kIEkgcHJlZmVyIHRvIGJlIGV4cGxpY2l0IG9uIHRoZSBleGNlcHRpb24gZm9y IHVzYWdlDQogb2YgR1JVVSBpbiBDb250YWN0IG9mIElOVklURSByZXF1ZXN0Ojwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQSBVQSB0aGF0IHdpbGwgYWNj ZXB0IGEgUkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IGEgR1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgYWxs IElOVklURSByZXF1ZXN0cy4mbmJzcDsgVGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNw b25kaW5nIHRvIGFueTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXN1bHRp bmcgSU5WSVRFIGRpYWxvZ3MgYXJyaXZlIGF0IHRoaXMgVUEuIDxzcGFuIHN0eWxlPSJjb2xvcjoj QzA1MDREIj4mZ3Q7Jmd0OyZndDtVQXMgdGhhdCB3aWxsIG5vdCBhY2NlcHQgYW55IG91dC1vZi1k aWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9uZGluZyB0byBkaWFsb2cocykgY3JlYXRlZCBi eSBhbiBJTlZJVEUgcmVxdWVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6I0MwNTA0RCI+Jm5ic3A7Jm5ic3A7IGFyZSBleGVtcHRlZCBmcm9tIGluY2x1 ZGluZyBhIEdSVVUgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mIHRoZSBJTlZJVEUgcmVx dWVzdC4mbHQ7Jmx0OyZsdDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5LaW5kIHJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+SXZvIFNlZGxhY2Vr PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiND MDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFJvYmVydCBTcGFya3MgWzxhIGhyZWY9Im1h aWx0bzpyanNwYXJrc0Bub3N0cnVtLmNvbSI+bWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAzMC4gxI1lcnZlbmNlIDIwMTQgMTg6NTQ8YnI+DQo8Yj5U bzo8L2I+IEFuZHJldyBBbGxlbjsgQWRhbSBSb2FjaDsgSXZvIFNlZGxhY2VrOyA8YSBocmVmPSJt YWlsdG86c2lwY29yZUBpZXRmLm9yZyI+DQpzaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzMwLzE0LCAxMDozMyBBTSwg QW5kcmV3IEFsbGVuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhh dmUgYSBnZW5lcmFsIGNvbmNlcm4gd2l0aCB0aGUgZGlyZWN0aW9uIHRoaXMgaXMgbm93IGdvaW5n Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBkb24ndCB0aGluayB5b3UgaGF2ZSB0 aGUgYmFja3dhcmRzLWNvbXBhdGliaWxpdHkgY29uY2VybiBxdWl0ZSByaWdodCwgYnV0IEkgYWdy ZWUgdGhhdCB0aGUgY3VycmVudCB3b3JkaW5nIGlzbid0IHRoZXJlIHlldC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXJlIHdlIG5v dyBzYXlpbmcgaGVyZSB0aGF0IGl04oCZcyBPSyBmb3IgYSBVQSB0aGF0IHN1cHBvcnRzIHJlY2Vp dmluZyBSRUZFUiB0byBhcmJpdHJhcmlseSByZWplY3QgYW55IFJFRkVSIHRoYXQgd291bGQgY3Jl YXRlIGEgc3Vic2NyaXB0aW9uIChpLmUgYmUgaW5jb21wYXRpYmxlDQogd2l0aCBSRkMgMzUxNSBV QUNzIGJ5IGJhc2ljYWxseSBub3Qgc3VwcG9ydGluZyBSRkMgMzUxNSBVQVMgY29tcGxpYW50IGJl aGF2aW9yKT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk5vLCBfdGhpc18gZG9jdW1lbnQgaXMgbm90IGRlZmlu aW5nIG5ldyBiZWhhdmlvci4gSXQncyBvbmx5IGNsYXJpZnlpbmcgd2hhdCdzIGFscmVhZHkgZGVm aW5lZC48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWNjb3JkaW5nIHRvIFJGQyAzNTE1PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLjQuNCBVc2luZyBTSVAgRXZlbnRzIHRvIFJl cG9ydCB0aGUgUmVzdWx0cyBvZiB0aGUgUmVmZXJlbmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSBOT1RJRlkgbWVjaGFuaXNtIGRlZmluZWQgaW4gWzJdDQo8c3Bh biBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPk1VU1Q8L3Nw YW4+IGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBhZ2VudCBzZW5kaW5nIHRoZSBSRUZFUiBvZiB0aGUg c3RhdHVzIG9mIHRoZSByZWZlcmVuY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZWZvcmUgdGhlIGFiaWxpdHkg dG8gY3JlYXRlIGFuIGltcGxpY2l0IHN1YnNjcmlwdGlvbiB3aGVuIGFjY2VwdGluZzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+RldJVywgQWNjZXB0aW5nIGlzIHRoZSBrZXkgd29yZCBoZXJlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPmEgUkVGRVIgaXMgbWFuZGF0b3J5IGJlaGF2aW9yIGluIFJGQyAzNTE1IGFu ZCBpcyBleHBlY3RlZCB0byBiZSBzdXBwb3J0ZWQgYnkgYWxsIFJGQyAzNTE1IFVBQ3M8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgdGhpbmsgYmVmb3JlIGFncmVlaW5nIGFueSB3b3JkaW5nIGhlcmUgd2Ugc2hvdWxkIGhh dmUgYSBnZW5lcmFsIGRpc2N1c3Npb24gb24gdGhlIHByaW5jaXBsZSBvZiB3aGV0aGVyIHRoZXNl IGV4dGVuc2lvbnMgdGhhdCBhbGxvdyBVQUNzIHRvIHJlcXVlc3QgdGhhdCBubw0KIGltcGxpY2l0 IHN1YnNjcmlwdGlvbiBjYW4gYmUgZWZmZWN0aXZlbHkgcmVxdWlyZWQgYnkgUkVGRVIgVUFTIHRv IGJlIHN1cHBvcnRlZCBhdCB0aGUgVUFDLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGlzLCBhbmQgd2hh dCB5b3UgaGF2ZSBiZWxvdywgaXMgYSBkaXNjdXNzaW9uIHdlIGRlZmluaXRlbHkgbmVlZCB0byBo YXZlIGFzIHBhcnQgb2YgdGhlIGV4dGVuc2lvbiBkb2N1bWVudC48YnI+DQpJdCBpcyBub3QgbmVj ZXNzYXJ5IHRvIHdhaXQgZm9yIHRoYXQgZGlzY3Vzc2lvbiB0byBjb21wbGV0ZSB0aGUgY2xhcmlm aWNhdGlvbnMgZG9jdW1lbnQgdGhhdCB0YWxrcyBhYm91dCB3aGF0IHRoZSBzcGVjcyBzYXkgX25v d18uPGJyPg0KPGJyPg0KTXkgZGlzY29tZm9ydCB3aXRoIHRoZSBjdXJyZW50IHRleHQgaXMgdGhh dCB3ZSd2ZSBtYWRlIGl0IGNvbXBsZXggdG8gbWFrZSBpdCBzbyB0aGF0IHdlIGRvbid0IGhhdmUg dG8gdXBkYXRlIHRoZSBkb2N1bWVudCBvbmNlIHRoZSBwcm9wb3NlZCBleHRlbnNpb25zIGV4aXN0 Ljxicj4NClRoZXJlIGFyZSBOTyBjdXJyZW50bHkgc3RhbmRhcmRpemVkIGNhc2VzIHdoZXJlIHRo ZSBleGVtcHRpb24gaW4gdGhlIGN1cnJlbnQgdGV4dCB3b3VsZCBiZSBpbnZva2VkLCBhbmQgSSBk b24ndCB0aGluayBwZW9wbGUgYXJlIHRyeWluZyB0byBhcmd1ZSB0aGVyZSBhcmUgLSBJJ20gaGVh cmluZyB0aGF0IHRvIGdldCB0aGVyZSwgdGhleSBleHBlY3QgdG8gaW52b2tlIHRoZSB5ZXQtdG8t YmUtZGVmaW5lZCBleHRlbnNpb24uPGJyPg0KPGJyPg0KU28sIGxldHMgZ28gYmFjayB0byB0aGUg c2xpZ2h0bHkgbG9uZ2VyIHNlbnRlbmNlIHRoYXQgbGVkIHRvIHRoaXM6PGJyPg0KPGJyPg0KQSBV QSB0aGF0IHdpbGwgYWNjZXB0IGEgc3Vic2NyaXB0aW9uLWNyZWF0aW5nIFJFRkVSIHJlcXVlc3Qg bmVlZHMgdG8gaW5jbHVkZTxicj4NCmEgR1JVVSBhcyB0aGUgQ29udGFjdCBpbiBhbGwgSU5WSVRF IHJlcXVlc3RzIHRvIGVuc3VyZSBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzPGJyPg0KcmVs YXRlZCB0byBhbnkgZGlhbG9nIGNyZWF0ZWQgYnkgdGhlIElOVklURSBhcnJpdmUgYXQgdGhpcyBV QS48YnI+DQo8YnI+DQpJbiBhbiBhdHRlbXB0IHRvIGJlIGZ1dHVyZS1wcm9vZiwgdGhhdCdzIGlu dHJvZHVjaW5nIHRoZSBwb3RlbnRpYWwgZm9yIGNvbmZ1c2lvbiBhYm91dCB3aGF0IHRoZSBjdXJy ZW50IHN0YW5kYXJkcyBkZWZpbmUuPGJyPg0KTGV0J3MgcmVtb3ZlIHRoYXQgY29uZnVzaW9uLjxi cj4NCkhlcmUncyBhIHByb3Bvc2VkIHJlcGxhY2VtZW50LCB0YWtpbmcgQWRhbSdzIHNlbnRlbmNl IHNpbXBsaWZpY2F0aW9uIGludG8gYWNjb3VudDo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgQSBV QSB0aGF0IHdpbGwgYWNjZXB0IGEgUkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlPGJyPg0K Jm5ic3A7Jm5ic3A7IGEgR1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgYWxsIElO VklURSByZXF1ZXN0cy4mbmJzcDsgVGhpczxicj4NCiZuYnNwOyZuYnNwOyBlbnN1cmVzIHRoYXQg b3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueTxicj4NCiZu YnNwOyZuYnNwOyByZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJyaXZlIGF0IHRoaXMgVUEuIEZ1 dHVyZSBleHRlbnNpb25zIDxicj4NCiZuYnNwOyZuYnNwOyBbZHJhZnQtc3BhcmtzLXNpcGNvcmUt cmVmZXItZXhwbGljaXRzdWJdIG1pZ2h0IHJlbGF4IHRoaXMgcmVxdWlyZW1lbnQgPGJyPg0KJm5i c3A7Jm5ic3A7IGJ5IGRlZmluaW5nIGEgUkVGRVIgcmVxdWVzdCB0aGF0IGNhbm5vdCBjcmVhdGUg YW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uLjxicj4NCjxicj4NCjxicj4NClVubGVzcyBJIGhlYXIg b2JqZWN0aW9uIHNvb24sIEknbGwgcmV2IHRoZSBkcmFmdCB3aXRoIHRoYXQgY29udGVudC48YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SWYgc28gdGhlbiBJIHRoaW5rIHdlIHdpbGwgbmVlZCBhIG5ldyBz aXAgb3B0aW9ucyB0YWcgKGUuZyBSRUZFUi1OT1NVQikgdG8gYmUgdXNlZCBpbiBwbGFjZSBvZiB0 aGUgUkVGRVIgb3B0aW9ucyB0YWcgc28gdGhhdCBhIFJGQyAzNTE1IGNvbXBsaWFudCBVQSB0aGF0 IGV4cGVjdHMNCiBhIE5PVElGWSB0byBiZSBzZW50IHVwb24gcmVjZWlwdCBvZiBhIFJFRkVSIGFu ZCB0aGF0IGluY2x1ZGVzIGFuIEFjY2VwdC1Db250YWN0IHJlcXVlc3QgdG8gcmVhY2ggYSBVQSB0 aGF0IHN1cHBvcnRzIFJFRkVSIGRvZXNu4oCZdCBlbmQgdXAgYXQgYSBVQVMgdGhhdCBkb2VzbuKA mXQgJm5ic3A7c3VwcG9ydCBjb21wbGlhbnQgUkZDIDM1MTUgYmVoYXZpb3IgYW5kIGVuZHMgdXAg aGF2aW5nIGl0cyBSRUZFUiByZXF1ZXN0cyByZWplY3RlZC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IG93biB2aWV3 IGlzIHRoYXQgd2Ugc2hvdWxkIGtlZXAgd2l0aCB0aGUgcHJpbmNpcGxlIG9mIGJhY2t3YXJkIGNv bXBhdGliaWxpdHkgYW5kIHRoYXQgZXZlbiB3aGVuIHRoZXNlIG5vIGF1dG9tYXRpYyBzdWJzY3Jp cHRpb24gZXh0ZW5zaW9ucyBhcmUgc3VwcG9ydGVkDQogdGhhdCBmdWxsIHN1cHBvcnQgZm9yIFJG QyAzNTE1IGJlaGF2aW9yIGlzIGNvbnRpbnVlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHJldzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gc2lwY29yZSBbPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkFkYW0gUm9hY2g8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVs eSAyOSwgMjAxNCAxMToxOSBBTTxicj4NCjxiPlRvOjwvYj4gSXZvIFNlZGxhY2VrOyBSb2JlcnQg U3BhcmtzOyA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlv bnMtMDMudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDcvMjkvMTQgMDk6NTIsIEl2byBTZWRsYWNlayB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5U aHVzLCB0aGUgdGV4dCBzaG91bGQgc3RhdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsgSW4gZ2VuZXJhbCwgVUFzIHRoYXQgc3VwcG9ydCByZWNlaXZpbmcgJmd0OyZn dDthbmQgYWNjZXB0aW5nIGFuIG91dC1vZi1kaWFsb2cmbHQ7Jmx0OyBSRUZFUiByZXF1ZXN0ICZn dDsmZ3Q7Y29ycmVzcG9uZGluZyB0byBhIGRpYWxvZyBlc3RhYmxpc2hlZCBieSBhbiBJTlZJVEUg cmVxdWVzdCZsdDsmbHQ7IG5lZWQgdG8gaW5jbHVkZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJz cDsgYSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiAmZ3Q7Jmd0O3RoZSZsdDsm bHQ7IElOVklURSByZXF1ZXN0LiZuYnNwOyBUaGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNw OyBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5n IHRvIGFueTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcmVzdWx0aW5nIElOVklURSBkaWFs b2dzIGFyZSByb3V0ZWQgdG8gdGhlIGNvcnJlY3QgdXNlciBhZ2VudC4mbmJzcDsgVUFzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGF0IHdpbGwgbmV2ZXIgY3JlYXRlIGEgaW1wbGljaXQg c3Vic2NyaXB0aW9uIGluIHJlc3BvbnNlIHRvIGEgUkVGRVI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 Jm5ic3A7ICh0aGF0IGlzLCB0aG9zZSB0aGF0IHdpbGwgcmVqZWN0IGFueSBSRUZFUiB0aGF0IG1p Z2h0IHJlc3VsdCBpbiBhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW1wbGljaXQgc3Vi c2NyaXB0aW9uKSBhcmUgZXhlbXB0ZWQgZnJvbSB0aGlzIGJlaGF2aW9yLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KSSBoZWxwZWQgd2l0aCB0aGUgcGhyYXNpbmcgaGVyZSwg YW5kIG9uZSBvZiB0aGUgZ29hbHMgaGVyZSB3YXMgdG8gbWFrZSB0aGUgZmlyc3Qgc2VudGVuY2Ug Y292ZXIgdGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlIGNhc2VzIChoZW5jZSAmcXVvdDtpbiBnZW5l cmFsJnF1b3Q7KSwgd2l0aCB0aGUgZXhjZXB0aW9uYWwgY2FzZXMgZGVzY3JpYmVkIGxhdGVyLiBU aGUgcHJvYmxlbSB3YXMgdGhhdCB0aGUgb3ZlcmFsbCBjb25jZXB0IHdhcyBnZXR0aW5nIGxvc3Qg aW4gYSBtYXplDQogb2YgdHdpc3R5IGNsYXVzZXM6IHRoZSBjbGFyaWZpY2F0aW9uIGhhZCBiZWNv bWUgd29yc2UgdGhhbiB0aGUgc291cmNlIHRleHQ7IGl0IHdhcyBhY3R1YWxseSBtb3JlIGNvbmZ1 c2luZy48YnI+DQo8YnI+DQpZb3VyIHByb3Bvc2FsIHJldHVybnMgaXQgdG8gdGhpcyB2ZXJ5IGNv bmZ1c2luZyBzdGF0ZSwgYW5kIGlzIHdheSwgd2F5IG91dCBpbnRvIHRoZSByZWFsbSBvZiBleGNl cHRpb25hbCBjYXNlcy48YnI+DQo8YnI+DQpTbyBJJ2xsIGNvdW50ZXJwcm9wb3NlOjxvOnA+PC9v OnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSW4gZ2VuZXJhbCwgVUFzIHRoYXQgc3VwcG9ydCBy ZWNlaXZpbmcgUkVGRVIgcmVxdWVzdHMgbmVlZCB0byBpbmNsdWRlPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGEgR1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2Yg YWxsIElOVklURSByZXF1ZXN0cy4mbmJzcDsgVGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3Jy ZXNwb25kaW5nIHRvIGFueTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXN1 bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJlIHJvdXRlZCB0byB0aGUgY29ycmVjdCB1c2VyIGFnZW50 LiZuYnNwOyBVQXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhhdCB3aWxs IG5vdCBjcmVhdGUgYSBpbXBsaWNpdCBzdWJzY3JpcHRpb24gaW4gcmVzcG9uc2UgdG8gYSBSRUZF UjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBmb3IgdGhlIHJlc3VsdGluZyBk aWFsb2cocykgLS0gdGhhdCBpcywgdGhvc2UgdGhhdCB3aWxsIHJlamVjdCBhPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvcnJlc3BvbmRpbmcgUkVGRVIgdGhhdCBtaWdodCBy ZXN1bHQgaW4gYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uIC0tPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IGFyZSBleGVtcHRlZCBmcm9tIHRoaXMgYmVoYXZpb3IuPG86cD48L286 cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi9hPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_39B5E4D390E9BD4890E2B3107900610112711567ESESSMB301erics_-- From nobody Tue Aug 12 01:52:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310231A07B3 for ; Tue, 12 Aug 2014 01:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0q8get_GseR for ; Tue, 12 Aug 2014 01:52:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905731A07A2 for ; Tue, 12 Aug 2014 01:52:20 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-5d-53e9d5c269af Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F3.FC.21432.2C5D9E35; Tue, 12 Aug 2014 10:52:18 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 10:52:17 +0200 From: Ivo Sedlacek To: Ivo Sedlacek , Robert Sparks , Andrew Allen , Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPsmi0zYBKyCtO/U25PQfJ1Q5YyZvMkedwgAAX43A= Date: Tue, 12 Aug 2014 08:52:16 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112711708ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3RvfQ1ZfBBj2t4hb3521ltNjzdxG7 xbU5jWwWX39sYnNg8ZjVsJbdY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DKeH7Kt+DTGeaK i/snsDYwfjnA3MXIySEhYCIx++VpKFtM4sK99WwgtpDAUUaJmeeCuhi5gOwljBJnWvezgiTY BPQkJm45wgqSEBE4xCgx+ehGdpCEsEC2xMoNuxhBbBGBHIn+zy1AkziAbCuJs1/5QMIsAqoS hz6dByvhFfCV2D/7JzvEghssEg+n3wGr5xTwk9jbyANSwyggK3H1Ty9YPbOAuMStJ/OZIA4V kFiy5zzU0aISLx//YwVplRBQkpi2NQ2iPF/ixs2XbBCrBCVOznzCMoFRZBaSSbOQlM1CUjYL aBKzgKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxanJSbbmSkl1qUmVxcnJ+nl5da sokRGHMHt/w22MH48rnjIUYBDkYlHt4FLC+DhVgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QD49bV+86xi3/rnvaAJ+p/0g/36g+8Rv/Yj3lcWbr1YdAm1sNr W55+TRG8cNltc+srll9mrHOnBqxpDi4w2rffzPyPmv+XlLcbX1av37X/jMWycs4+x3PrDC3L Mt7XRPtNqLfsa1/z7wOXhm1j6jvBvtzOayEBp+YVmNu4X62Xe3/JaomxFO90HSWW4oxEQy3m ouJEAKLtxVKaAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/0Jf3g5wXNa_rJsGR2_9HRVBKhsg Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 08:52:34 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112711708ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KGV4dGVuZGVkIHdpdGggbXkgYW5zd2VyIG9uIHRoZSBxdWVzdGlvbiBhbmQgdGhlIHByb3Bvc2Vk IGRyYWZ0IHRleHQpDQoNCkhlbGxvLA0KDQpUaGVyZSBzdGlsbCBzZWVtcyB0byBiZSBtaXN1bmRl cnN0YW5kaW5nLiBMZXQgbWUgc3RhdGUgbXkgaXNzdWUgaW4gYSBkaWZmZXJlbnQgYW5kIG1vcmUg Z2VuZXJhbCB3YXk6DQoNCklmOg0KLSBhIFVFIHN1cHBvcnRzIHJlY2VpdmluZyBhbmQgYWNjZXB0 aW5nIG9mIG91dC1vZi1kaWFsb2cgUkVGRVIgcmVxdWVzdCByZWxhdGVkIHRvIGRpYWxvZ3MgY3Jl YXRlZCBieSBzb21lIChidXQgbm90IGFsbCkgSU5WSVRFIHJlcXVlc3RzOyBhbmQNCi0gZm9yIGEg cGFydGljdWxhciBJTlZJVEUgcmVxdWVzdCwgdGhlIFVBIHJlamVjdHMgYW55IG91dC1vZi1kaWFs b2cgUkVGRVJzIHJlbGF0ZWQgdG8gZGlhbG9ncyBjcmVhdGVkIGJ5IHRoZSBwYXJ0aWN1bGFyIElO VklURSByZXF1ZXN0Ow0Kc2hvdWxkIHRoZSBVRSBiZSBzdGlsbCBtYW5kYXRlZCB0byBwdXQgR1JV VSBpbiB0aGUgQ29udGFjdCBvZiB0aGUgcGFydGljdWxhciBJTlZJVEUgcmVxdWVzdD8gSWYgc28s IHdoYXQgd2lsbCB0aGUgR1JVVSBiZSB1c2VkIGZvcj8NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUg cXVlc3Rpb24gYWJvdmUgZm9jdXNlcyBzb2xlbHkgb24gb3V0LW9mLWRpYWxvZyBSRUZFUnMuDQoN Cg0KDQpJTU8sIGFuc3dlciB0byB0aGUgcXVlc3Rpb25zIGFib3ZlIGlzOg0KDQogICAgICAgICAg ICBUaGUgVUUgc2hvdWxkIG5vdCBiZSBtYW5kYXRlZCB0byBwdXQgR1JVVSBpbiBDb250YWN0IG9m IHRoZSBwYXJ0aWN1bGFyIElOVklURSByZXF1ZXN0LCBzaW5jZSBhbnkgb3V0LW9mLWRpYWxvZyBS RUZFUiByZXF1ZXN0IHJlbGF0ZWQgdG8gYW55IGRpYWxvZyBjcmVhdGVkIGJ5IHRoZSBwYXJ0aWN1 bGFyIElOVklURSByZXF1ZXN0IGlzIHJlamVjdGVkLiBUaHVzLCB0aGUgR1JVVSBkb2VzIG5vdCBw cm92aWRlIGFueSB2YWx1ZS4NCg0KVGhlcmVmb3JlLCB0aGUgZHJhZnQgc2hvdWxkIHN0YXRlOg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkEgVUEgdGhhdCB3aWxsIGFjY2VwdCBhIHN1YnNjcmlw dGlvbi1jcmVhdGluZyBSRUZFUiByZXF1ZXN0ID4+cmVsYXRlZCB0byBhIGRpYWxvZyBvZiBhbiBJ TlZJVEUgcmVxdWVzdDw8IG5lZWRzIHRvIGluY2x1ZGUNCmEgR1JVVSBhcyB0aGUgQ29udGFjdCBp biA+PnRoZTw8IElOVklURSByZXF1ZXN0IHRvIGVuc3VyZSBvdXQtb2YtZGlhbG9nIFJFRkVSIHJl cXVlc3RzDQpyZWxhdGVkIHRvIGFueSBkaWFsb2cgY3JlYXRlZCBieSB0aGUgSU5WSVRFID4+cmVx dWVzdDw8IGFycml2ZSBhdCB0aGlzIFVBLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KS2lu ZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQoNCkZyb206IFJvYmVydCBTcGFya3MgW21haWx0 bzpyanNwYXJrc0Bub3N0cnVtLmNvbV0NClNlbnQ6IDcuIHNycG5hIDIwMTQgMTk6NTUNClRvOiBJ dm8gU2VkbGFjZWs7IEFuZHJldyBBbGxlbjsgQWRhbSBSb2FjaDsgc2lwY29yZUBpZXRmLm9yZzxt YWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJp ZmljYXRpb25zLTAzLnR4dA0KDQpJJ3ZlIHNwZW50IHF1aXRlIHNvbWUgdGltZSB0cnlpbmcgdG8g dW5kZXJzdGFuZCB0aGUgcHVzaCBmb3IgdGhlIHByb3Bvc2FsIGJlbG93LCBhbmQgSSByZWFsbHkg dGhpbmsgdGhlcmUncyBjb25mdXNpb24sIHNvIEknbSBnb2luZyB0byB0cnkgdG8gc3RlcCB1cCBh IGxldmVsIGFuZCBzZWUgaWYgd2UgY2FuIG1ha2UgcHJvZ3Jlc3MgdGhlcmUuDQoNCkEgVUEgc3Vj aCBhcyB5b3VyIHByb3Bvc2VkIGV4Y2VwdGlvbiBjbGF1c2UgZGVzY3JpYmVzIGlzIHNpbXBseSBu b3QgYSBjb21wbGlhbnQgNjY2NSBpbXBsZW1lbnRhdGlvbiB3aGljaCBpcyB3aGF0IHRoaXMgY2xh cmlmaWNhdGlvbiBkb2N1bWVudCBpcyBhYm91dC4NCklmIGl0IGFjY2VwdHMgaW4tZGlhbG9nIHN1 YnNjcmlwdGlvbiBjcmVhdGluZyBSRUZFUnMgaXQgaXMgZm9sbG93aW5nIDMyNjUsIG5vdCA2NjY1 IC0gZnVydGhlciBpdCBpcyB2aW9sYXRpbmcgYSA2NjY1IHJlcXVpcmVtZW50Lg0KSWYgaXQgYWNj ZXB0cyBubyBSRUZFUnMgd2hhdHNvZXZlciwgdGhlbiBpdCdzIG5vdCBhZmZlY3RlZCBieSB0aGlz IGRvY3VtZW50Lg0KDQpJZiB0aGUgcG9pbnQgb2YgdGhlIHdvcmRzbWl0aGluZyBpcyB0byBtYWtl IGxlZ2FjeSBpbXBsZW1lbnRhdGlvbnMgY29tcGxpYW50IHdpdGggNjY2NSwgdGhlcmUncyBubyB3 YXkgdG8gc3VjY2VlZCAtIHRoZXkgc2ltcGx5IGFyZW4ndC4NCg0KSWYgdGhhdCdzIG5vdCB0aGUg cG9pbnQgb2YgdGhlIHdvcmRzbWl0aGluZywgd2hhdCBpcz8NCg0KQXQgdGhlIG1vbWVudCwgSSB0 aGluayB3aGF0IEkgc2VudCBiZWxvdyBpcyBzdGlsbCB0aGUgcmlnaHQgcGF0aCBmb3J3YXJkLg0K DQpSalMNCg0KDQpPbiA4LzEvMTQsIDE6NDQgQU0sIEl2byBTZWRsYWNlayB3cm90ZToNCkFueSBj b21tZW50cyBvbiB0aGUgcHJvcG9zYWwgYmVsb3c/DQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2Vk bGFjZWsNCg0KDQogICBJZiBhIFJFRkVSIHJlcXVlc3QgaXMgYWNjZXB0ZWQgKHRoYXQgaXMsIGEg Mnh4IGNsYXNzIHJlc3BvbnNlIGlzDQogICByZXR1cm5lZCksIHRoZSByZWNpcGllbnQgTVVTVCBj cmVhdGUgYSBzdWJzY3JpcHRpb24gYW5kIHNlbmQNCiAgIG5vdGlmaWNhdGlvbnMgb2YgdGhlIHN0 YXR1cyBvZiB0aGUgcmVmZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24NCiAgIDIuNC40LkZyb206 IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJ dm8gU2VkbGFjZWsNClNlbnQ6IDMxLiDEjWVydmVuY2UgMjAxNCA5OjI2DQpUbzogUm9iZXJ0IFNw YXJrczsgQW5kcmV3IEFsbGVuOyBBZGFtIFJvYWNoOyBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpz aXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlv bnMtMDMudHh0DQoNCkhlbGxvLA0KDQpBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LCB0aGUgcHVycG9z ZSBvZiBHUlVVIGluIENvbnRhY3Qgb2YgSU5WSVRFIHJlcXVlc3QgdG8gIg0KICAgZW5zdXJlcyB0 aGF0IG91dC1vZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9uZGluZyB0byBhbnkNCiAg IHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUgYXQgdGhpcyBVQS4iDQoNCklmIGEgVUEg cmVqZWN0cyBhbnkgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRv IGFueSBkaWFsb2dzIHJlbGF0ZWQgdG8gYW4gSU5WSVRFIHJlcXVlc3QsIHRoZW4gc2V0dGluZyB1 cCBHUlVVIGluIENvbnRhY3Qgb2YgSU5WSVRFIGRvZXMgbm90IHByb3ZpZGUgYW55IHB1cnBvc2Uu DQoNClRoaXMgaXMgdHJ1ZSBfX3JlZ2FyZGxlc3NfXyB3aGV0aGVyIHRoZSBVQSBzdXBwb3J0cyBh bmQgdXNlIHRoZSBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdHN1Yi4NClNlZSBh dHRhY2hlZCBtYWlsIGdpdmluZyBhbiBleGFtcGxlIG9mIFVBIGhhdmluZyB0d28gdHlwZXMgb2Yg c2Vzc2lvbnMsIFR5cGVfQSB0cmFuc2ZlcnJhYmxlIGJ5IFJFRkVSLCBhbmQgVHlwZV9CIG5vdCB0 cmFuc2ZlcnJhYmxlIGJ5IFJFRkVSLg0KR2l2ZW4gdGhhdCBkaWZmZXJlbnQgc3RhbmRhcmRpemF0 aW9uIG9yZ2FuaXphdGlvbiBoYXMgZGVmaW5lZCBzbyBtYW55IGVuYWJsZXJzIHdoaWNoIGNhbiBy dW4gb24gYSBzaW5nbGUgVUEsIEkgZmluZCBpdCB3ZWlyZCB0aGF0IG9uZSBjYW4gZ3VhcmFudGVl IHRoYXQgdGhlIGFib3ZlIGNhbm5vdCBvY2N1ci4NCg0KVGh1cywgSSBoZXNpdGF0ZSB0byBtYW5k YXRlIGFuIHVubmVjZXNzYXJ5IHJlcXVpcmVtZW50IGluZmx1ZW5jaW5nIHBvc3NpYmxlIGV4aXN0 aW5nIFVBIGltcGxlbWVudGF0aW9ucyBhbmQgSSBwcmVmZXIgdG8gYmUgZXhwbGljaXQgb24gdGhl IGV4Y2VwdGlvbiBmb3IgdXNhZ2Ugb2YgR1JVVSBpbiBDb250YWN0IG9mIElOVklURSByZXF1ZXN0 Og0KDQoNCg0KDQogICBBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBSRUZFUiByZXF1ZXN0IG5lZWRz IHRvIGluY2x1ZGUNCg0KICAgYSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiBh bGwgSU5WSVRFIHJlcXVlc3RzLiAgVGhpcw0KDQogICBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxv ZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueQ0KDQogICByZXN1bHRpbmcgSU5W SVRFIGRpYWxvZ3MgYXJyaXZlIGF0IHRoaXMgVUEuID4+PlVBcyB0aGF0IHdpbGwgbm90IGFjY2Vw dCBhbnkgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGRpYWxv ZyhzKSBjcmVhdGVkIGJ5IGFuIElOVklURSByZXF1ZXN0DQoNCiAgIGFyZSBleGVtcHRlZCBmcm9t IGluY2x1ZGluZyBhIEdSVVUgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mIHRoZSBJTlZJ VEUgcmVxdWVzdC48PDwNCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQoNCkZyb206 IFJvYmVydCBTcGFya3MgW21haWx0bzpyanNwYXJrc0Bub3N0cnVtLmNvbV0NClNlbnQ6IDMwLiDE jWVydmVuY2UgMjAxNCAxODo1NA0KVG86IEFuZHJldyBBbGxlbjsgQWRhbSBSb2FjaDsgSXZvIFNl ZGxhY2VrOyBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt c3BhcmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0DQoNCg0KT24gNy8zMC8x NCwgMTA6MzMgQU0sIEFuZHJldyBBbGxlbiB3cm90ZToNCkkgaGF2ZSBhIGdlbmVyYWwgY29uY2Vy biB3aXRoIHRoZSBkaXJlY3Rpb24gdGhpcyBpcyBub3cgZ29pbmcuDQpJIGRvbid0IHRoaW5rIHlv dSBoYXZlIHRoZSBiYWNrd2FyZHMtY29tcGF0aWJpbGl0eSBjb25jZXJuIHF1aXRlIHJpZ2h0LCBi dXQgSSBhZ3JlZSB0aGF0IHRoZSBjdXJyZW50IHdvcmRpbmcgaXNuJ3QgdGhlcmUgeWV0Lg0KDQpB cmUgd2Ugbm93IHNheWluZyBoZXJlIHRoYXQgaXTigJlzIE9LIGZvciBhIFVBIHRoYXQgc3VwcG9y dHMgcmVjZWl2aW5nIFJFRkVSIHRvIGFyYml0cmFyaWx5IHJlamVjdCBhbnkgUkVGRVIgdGhhdCB3 b3VsZCBjcmVhdGUgYSBzdWJzY3JpcHRpb24gKGkuZSBiZSBpbmNvbXBhdGlibGUgd2l0aCBSRkMg MzUxNSBVQUNzIGJ5IGJhc2ljYWxseSBub3Qgc3VwcG9ydGluZyBSRkMgMzUxNSBVQVMgY29tcGxp YW50IGJlaGF2aW9yKT8NCk5vLCBfdGhpc18gZG9jdW1lbnQgaXMgbm90IGRlZmluaW5nIG5ldyBi ZWhhdmlvci4gSXQncyBvbmx5IGNsYXJpZnlpbmcgd2hhdCdzIGFscmVhZHkgZGVmaW5lZC4NCg0K DQpBY2NvcmRpbmcgdG8gUkZDIDM1MTUNCg0KMi40LjQgVXNpbmcgU0lQIEV2ZW50cyB0byBSZXBv cnQgdGhlIFJlc3VsdHMgb2YgdGhlIFJlZmVyZW5jZQ0KDQogICAgICAgICAgICAgICAgVGhlIE5P VElGWSBtZWNoYW5pc20gZGVmaW5lZCBpbiBbMl0gTVVTVCBiZSB1c2VkIHRvIGluZm9ybSB0aGUg YWdlbnQgc2VuZGluZyB0aGUgUkVGRVIgb2YgdGhlIHN0YXR1cyBvZiB0aGUgcmVmZXJlbmNlLg0K DQpUaGVyZWZvcmUgdGhlIGFiaWxpdHkgdG8gY3JlYXRlIGFuIGltcGxpY2l0IHN1YnNjcmlwdGlv biB3aGVuIGFjY2VwdGluZw0KRldJVywgQWNjZXB0aW5nIGlzIHRoZSBrZXkgd29yZCBoZXJlLg0K YSBSRUZFUiBpcyBtYW5kYXRvcnkgYmVoYXZpb3IgaW4gUkZDIDM1MTUgYW5kIGlzIGV4cGVjdGVk IHRvIGJlIHN1cHBvcnRlZCBieSBhbGwgUkZDIDM1MTUgVUFDcw0KDQpJIHRoaW5rIGJlZm9yZSBh Z3JlZWluZyBhbnkgd29yZGluZyBoZXJlIHdlIHNob3VsZCBoYXZlIGEgZ2VuZXJhbCBkaXNjdXNz aW9uIG9uIHRoZSBwcmluY2lwbGUgb2Ygd2hldGhlciB0aGVzZSBleHRlbnNpb25zIHRoYXQgYWxs b3cgVUFDcyB0byByZXF1ZXN0IHRoYXQgbm8gaW1wbGljaXQgc3Vic2NyaXB0aW9uIGNhbiBiZSBl ZmZlY3RpdmVseSByZXF1aXJlZCBieSBSRUZFUiBVQVMgdG8gYmUgc3VwcG9ydGVkIGF0IHRoZSBV QUMuDQpUaGlzLCBhbmQgd2hhdCB5b3UgaGF2ZSBiZWxvdywgaXMgYSBkaXNjdXNzaW9uIHdlIGRl ZmluaXRlbHkgbmVlZCB0byBoYXZlIGFzIHBhcnQgb2YgdGhlIGV4dGVuc2lvbiBkb2N1bWVudC4N Ckl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gd2FpdCBmb3IgdGhhdCBkaXNjdXNzaW9uIHRvIGNvbXBs ZXRlIHRoZSBjbGFyaWZpY2F0aW9ucyBkb2N1bWVudCB0aGF0IHRhbGtzIGFib3V0IHdoYXQgdGhl IHNwZWNzIHNheSBfbm93Xy4NCg0KTXkgZGlzY29tZm9ydCB3aXRoIHRoZSBjdXJyZW50IHRleHQg aXMgdGhhdCB3ZSd2ZSBtYWRlIGl0IGNvbXBsZXggdG8gbWFrZSBpdCBzbyB0aGF0IHdlIGRvbid0 IGhhdmUgdG8gdXBkYXRlIHRoZSBkb2N1bWVudCBvbmNlIHRoZSBwcm9wb3NlZCBleHRlbnNpb25z IGV4aXN0Lg0KVGhlcmUgYXJlIE5PIGN1cnJlbnRseSBzdGFuZGFyZGl6ZWQgY2FzZXMgd2hlcmUg dGhlIGV4ZW1wdGlvbiBpbiB0aGUgY3VycmVudCB0ZXh0IHdvdWxkIGJlIGludm9rZWQsIGFuZCBJ IGRvbid0IHRoaW5rIHBlb3BsZSBhcmUgdHJ5aW5nIHRvIGFyZ3VlIHRoZXJlIGFyZSAtIEknbSBo ZWFyaW5nIHRoYXQgdG8gZ2V0IHRoZXJlLCB0aGV5IGV4cGVjdCB0byBpbnZva2UgdGhlIHlldC10 by1iZS1kZWZpbmVkIGV4dGVuc2lvbi4NCg0KU28sIGxldHMgZ28gYmFjayB0byB0aGUgc2xpZ2h0 bHkgbG9uZ2VyIHNlbnRlbmNlIHRoYXQgbGVkIHRvIHRoaXM6DQoNCkEgVUEgdGhhdCB3aWxsIGFj Y2VwdCBhIHN1YnNjcmlwdGlvbi1jcmVhdGluZyBSRUZFUiByZXF1ZXN0IG5lZWRzIHRvIGluY2x1 ZGUNCmEgR1JVVSBhcyB0aGUgQ29udGFjdCBpbiBhbGwgSU5WSVRFIHJlcXVlc3RzIHRvIGVuc3Vy ZSBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzDQpyZWxhdGVkIHRvIGFueSBkaWFsb2cgY3Jl YXRlZCBieSB0aGUgSU5WSVRFIGFycml2ZSBhdCB0aGlzIFVBLg0KDQpJbiBhbiBhdHRlbXB0IHRv IGJlIGZ1dHVyZS1wcm9vZiwgdGhhdCdzIGludHJvZHVjaW5nIHRoZSBwb3RlbnRpYWwgZm9yIGNv bmZ1c2lvbiBhYm91dCB3aGF0IHRoZSBjdXJyZW50IHN0YW5kYXJkcyBkZWZpbmUuDQpMZXQncyBy ZW1vdmUgdGhhdCBjb25mdXNpb24uDQpIZXJlJ3MgYSBwcm9wb3NlZCByZXBsYWNlbWVudCwgdGFr aW5nIEFkYW0ncyBzZW50ZW5jZSBzaW1wbGlmaWNhdGlvbiBpbnRvIGFjY291bnQ6DQoNCiAgIEEg VUEgdGhhdCB3aWxsIGFjY2VwdCBhIFJFRkVSIHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZQ0KICAg YSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3Rz LiAgVGhpcw0KICAgZW5zdXJlcyB0aGF0IG91dC1vZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMgY29y cmVzcG9uZGluZyB0byBhbnkNCiAgIHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUgYXQg dGhpcyBVQS4gRnV0dXJlIGV4dGVuc2lvbnMNCiAgIFtkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZl ci1leHBsaWNpdHN1Yl0gbWlnaHQgcmVsYXggdGhpcyByZXF1aXJlbWVudA0KICAgYnkgZGVmaW5p bmcgYSBSRUZFUiByZXF1ZXN0IHRoYXQgY2Fubm90IGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJzY3Jp cHRpb24uDQoNCg0KVW5sZXNzIEkgaGVhciBvYmplY3Rpb24gc29vbiwgSSdsbCByZXYgdGhlIGRy YWZ0IHdpdGggdGhhdCBjb250ZW50Lg0KDQoNCklmIHNvIHRoZW4gSSB0aGluayB3ZSB3aWxsIG5l ZWQgYSBuZXcgc2lwIG9wdGlvbnMgdGFnIChlLmcgUkVGRVItTk9TVUIpIHRvIGJlIHVzZWQgaW4g cGxhY2Ugb2YgdGhlIFJFRkVSIG9wdGlvbnMgdGFnIHNvIHRoYXQgYSBSRkMgMzUxNSBjb21wbGlh bnQgVUEgdGhhdCBleHBlY3RzIGEgTk9USUZZIHRvIGJlIHNlbnQgdXBvbiByZWNlaXB0IG9mIGEg UkVGRVIgYW5kIHRoYXQgaW5jbHVkZXMgYW4gQWNjZXB0LUNvbnRhY3QgcmVxdWVzdCB0byByZWFj aCBhIFVBIHRoYXQgc3VwcG9ydHMgUkVGRVIgZG9lc27igJl0IGVuZCB1cCBhdCBhIFVBUyB0aGF0 IGRvZXNu4oCZdCAgc3VwcG9ydCBjb21wbGlhbnQgUkZDIDM1MTUgYmVoYXZpb3IgYW5kIGVuZHMg dXAgaGF2aW5nIGl0cyBSRUZFUiByZXF1ZXN0cyByZWplY3RlZC4NCg0KTXkgb3duIHZpZXcgaXMg dGhhdCB3ZSBzaG91bGQga2VlcCB3aXRoIHRoZSBwcmluY2lwbGUgb2YgYmFja3dhcmQgY29tcGF0 aWJpbGl0eSBhbmQgdGhhdCBldmVuIHdoZW4gdGhlc2Ugbm8gYXV0b21hdGljIHN1YnNjcmlwdGlv biBleHRlbnNpb25zIGFyZSBzdXBwb3J0ZWQgdGhhdCBmdWxsIHN1cHBvcnQgZm9yIFJGQyAzNTE1 IGJlaGF2aW9yIGlzIGNvbnRpbnVlZC4NCg0KQW5kcmV3DQoNCg0KDQoNCg0KRnJvbTogc2lwY29y ZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9h Y2gNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjksIDIwMTQgMTE6MTkgQU0NClRvOiBJdm8gU2VkbGFj ZWs7IFJvYmVydCBTcGFya3M7IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQNCg0K T24gNy8yOS8xNCAwOTo1MiwgSXZvIFNlZGxhY2VrIHdyb3RlOg0KDQpUaHVzLCB0aGUgdGV4dCBz aG91bGQgc3RhdGU6DQoNCg0KICAgSW4gZ2VuZXJhbCwgVUFzIHRoYXQgc3VwcG9ydCByZWNlaXZp bmcgPj5hbmQgYWNjZXB0aW5nIGFuIG91dC1vZi1kaWFsb2c8PCBSRUZFUiByZXF1ZXN0ID4+Y29y cmVzcG9uZGluZyB0byBhIGRpYWxvZyBlc3RhYmxpc2hlZCBieSBhbiBJTlZJVEUgcmVxdWVzdDw8 IG5lZWQgdG8gaW5jbHVkZQ0KICAgYSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBv ZiA+PnRoZTw8IElOVklURSByZXF1ZXN0LiAgVGhpcw0KICAgZW5zdXJlcyB0aGF0IG91dC1vZi1k aWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9uZGluZyB0byBhbnkNCiAgIHJlc3VsdGluZyBJ TlZJVEUgZGlhbG9ncyBhcmUgcm91dGVkIHRvIHRoZSBjb3JyZWN0IHVzZXIgYWdlbnQuICBVQXMN CiAgIHRoYXQgd2lsbCBuZXZlciBjcmVhdGUgYSBpbXBsaWNpdCBzdWJzY3JpcHRpb24gaW4gcmVz cG9uc2UgdG8gYSBSRUZFUg0KICAgKHRoYXQgaXMsIHRob3NlIHRoYXQgd2lsbCByZWplY3QgYW55 IFJFRkVSIHRoYXQgbWlnaHQgcmVzdWx0IGluIGFuDQogICBpbXBsaWNpdCBzdWJzY3JpcHRpb24p IGFyZSBleGVtcHRlZCBmcm9tIHRoaXMgYmVoYXZpb3IuDQoNCkkgaGVscGVkIHdpdGggdGhlIHBo cmFzaW5nIGhlcmUsIGFuZCBvbmUgb2YgdGhlIGdvYWxzIGhlcmUgd2FzIHRvIG1ha2UgdGhlIGZp cnN0IHNlbnRlbmNlIGNvdmVyIHRoZSB2YXN0IG1ham9yaXR5IG9mIHRoZSBjYXNlcyAoaGVuY2Ug ImluIGdlbmVyYWwiKSwgd2l0aCB0aGUgZXhjZXB0aW9uYWwgY2FzZXMgZGVzY3JpYmVkIGxhdGVy LiBUaGUgcHJvYmxlbSB3YXMgdGhhdCB0aGUgb3ZlcmFsbCBjb25jZXB0IHdhcyBnZXR0aW5nIGxv c3QgaW4gYSBtYXplIG9mIHR3aXN0eSBjbGF1c2VzOiB0aGUgY2xhcmlmaWNhdGlvbiBoYWQgYmVj b21lIHdvcnNlIHRoYW4gdGhlIHNvdXJjZSB0ZXh0OyBpdCB3YXMgYWN0dWFsbHkgbW9yZSBjb25m dXNpbmcuDQoNCllvdXIgcHJvcG9zYWwgcmV0dXJucyBpdCB0byB0aGlzIHZlcnkgY29uZnVzaW5n IHN0YXRlLCBhbmQgaXMgd2F5LCB3YXkgb3V0IGludG8gdGhlIHJlYWxtIG9mIGV4Y2VwdGlvbmFs IGNhc2VzLg0KDQpTbyBJJ2xsIGNvdW50ZXJwcm9wb3NlOg0KDQogICBJbiBnZW5lcmFsLCBVQXMg dGhhdCBzdXBwb3J0IHJlY2VpdmluZyBSRUZFUiByZXF1ZXN0cyBuZWVkIHRvIGluY2x1ZGUNCg0K ICAgYSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVl c3RzLiAgVGhpcw0KDQogICBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0 cyBjb3JyZXNwb25kaW5nIHRvIGFueQ0KDQogICByZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJl IHJvdXRlZCB0byB0aGUgY29ycmVjdCB1c2VyIGFnZW50LiAgVUFzDQoNCiAgIHRoYXQgd2lsbCBu b3QgY3JlYXRlIGEgaW1wbGljaXQgc3Vic2NyaXB0aW9uIGluIHJlc3BvbnNlIHRvIGEgUkVGRVIN Cg0KICAgZm9yIHRoZSByZXN1bHRpbmcgZGlhbG9nKHMpIC0tIHRoYXQgaXMsIHRob3NlIHRoYXQg d2lsbCByZWplY3QgYQ0KDQogICBjb3JyZXNwb25kaW5nIFJFRkVSIHRoYXQgbWlnaHQgcmVzdWx0 IGluIGFuIGltcGxpY2l0IHN1YnNjcmlwdGlvbiAtLQ0KDQogICBhcmUgZXhlbXB0ZWQgZnJvbSB0 aGlzIGJlaGF2aW9yLg0KDQovYQ0KDQoNCg0K --_000_39B5E4D390E9BD4890E2B3107900610112711708ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiNDMDUwNEQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiNDMDUwNEQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6I0MwNTA0RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj QzA1MDREO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiNDMDUwNEQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6I0MwNTA0RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiND MDUwNEQiPihleHRlbmRlZCB3aXRoIG15IGFuc3dlciBvbiB0aGUgcXVlc3Rpb24gYW5kIHRoZSBw cm9wb3NlZCBkcmFmdCB0ZXh0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUw NEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+VGhlcmUgc3RpbGwgc2VlbXMg dG8gYmUgbWlzdW5kZXJzdGFuZGluZy4gTGV0IG1lIHN0YXRlIG15IGlzc3VlIGluIGEgZGlmZmVy ZW50IGFuZCBtb3JlIGdlbmVyYWwgd2F5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5JZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiND MDUwNEQiPi0gYSBVRSBzdXBwb3J0cyByZWNlaXZpbmcgYW5kIGFjY2VwdGluZyBvZiBvdXQtb2Yt ZGlhbG9nIFJFRkVSIHJlcXVlc3QgcmVsYXRlZCB0byBkaWFsb2dzIGNyZWF0ZWQgYnkNCjx1PnNv bWUgKGJ1dCBub3QgYWxsKTwvdT4gSU5WSVRFIHJlcXVlc3RzOyBhbmQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiNDMDUwNEQiPi0gZm9yDQo8dT5hIHBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3Q8L3U+LCB0 aGUgVUEgcmVqZWN0cyBhbnkgb3V0LW9mLWRpYWxvZyBSRUZFUnMgcmVsYXRlZCB0byBkaWFsb2dz IGNyZWF0ZWQgYnkgdGhlIHBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojQzA1MDREIj5zaG91bGQgdGhlIFVFIGJlIHN0aWxsIG1hbmRhdGVkIHRvIHB1dCBHUlVV IGluIHRoZSBDb250YWN0IG9mDQo8dT50aGUgcGFydGljdWxhciBJTlZJVEUgcmVxdWVzdDwvdT4/ IElmIHNvLCB3aGF0IHdpbGwgdGhlIEdSVVUgYmUgdXNlZCBmb3I/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPlBsZWFzZSBub3Rl IHRoYXQgdGhlIHF1ZXN0aW9uIGFib3ZlIGZvY3VzZXMgc29sZWx5IG9uIG91dC1vZi1kaWFsb2cg UkVGRVJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+SU1PLCBhbnN3ZXIgdG8gdGhlIHF1ZXN0aW9ucyBh Ym92ZSBpczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojQzA1MDREIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIFVFIHNob3VsZCBub3QgYmUgbWFuZGF0ZWQg dG8gcHV0IEdSVVUgaW4gQ29udGFjdCBvZiB0aGUNCjx1PnBhcnRpY3VsYXIgSU5WSVRFIHJlcXVl c3Q8L3U+LCBzaW5jZSBhbnkgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 I0MwNTA0RCI+b3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0IHJlbGF0ZWQgdG8gYW55IGRpYWxv ZyBjcmVhdGVkIGJ5DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1 MDREIj50aGUNCjx1PnBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3Q8L3U+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+IGlzIHJlamVjdGVkPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+LiBUaHVzLCB0aGUgR1JVVSBkb2Vz IG5vdCBwcm92aWRlIGFueSB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+VGhlcmVmb3JlLCB0aGUgZHJhZnQgc2hvdWxk IHN0YXRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkEgVUEgdGhhdCB3aWxsIGFjY2VwdCBhIHN1 YnNjcmlwdGlvbi1jcmVhdGluZyBSRUZFUiByZXF1ZXN0ICZndDsmZ3Q7cmVsYXRlZCB0byBhIGRp YWxvZyBvZiBhbiBJTlZJVEUgcmVxdWVzdCZsdDsmbHQ7IG5lZWRzIHRvIGluY2x1ZGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiNDMDUwNEQiPmEgR1JVVSBhcyB0aGUgQ29udGFjdCBpbiAmZ3Q7Jmd0O3Ro ZSZsdDsmbHQ7IElOVklURSByZXF1ZXN0IHRvIGVuc3VyZSBvdXQtb2YtZGlhbG9nIFJFRkVSIHJl cXVlc3RzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5yZWxhdGVkIHRvIGFueSBkaWFsb2cg Y3JlYXRlZCBieSB0aGUgSU5WSVRFICZndDsmZ3Q7cmVxdWVzdCZsdDsmbHQ7IGFycml2ZSBhdCB0 aGlzIFVBLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 I0MwNTA0RCI+S2luZCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkl2byBTZWRsYWNlazxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2lu ZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPiBSb2JlcnQgU3BhcmtzIFs8YSBocmVmPSJtYWlsdG86cmpzcGFya3NAbm9z dHJ1bS5jb20iPm1haWx0bzpyanNwYXJrc0Bub3N0cnVtLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gNy4gc3JwbmEgMjAxNCAxOTo1NTxicj4NCjxiPlRvOjwvYj4gSXZvIFNlZGxhY2VrOyBB bmRyZXcgQWxsZW47IEFkYW0gUm9hY2g7IDxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3Jn Ij4NCnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29y ZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3Jl LXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBzcGVu dCBxdWl0ZSBzb21lIHRpbWUgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHB1c2ggZm9yIHRoZSBw cm9wb3NhbCBiZWxvdywgYW5kIEkgcmVhbGx5IHRoaW5rIHRoZXJlJ3MgY29uZnVzaW9uLCBzbyBJ J20gZ29pbmcgdG8gdHJ5IHRvIHN0ZXAgdXAgYSBsZXZlbCBhbmQgc2VlIGlmIHdlIGNhbiBtYWtl IHByb2dyZXNzIHRoZXJlLjxicj4NCjxicj4NCkEgVUEgc3VjaCBhcyB5b3VyIHByb3Bvc2VkIGV4 Y2VwdGlvbiBjbGF1c2UgZGVzY3JpYmVzIGlzIHNpbXBseSBub3QgYSBjb21wbGlhbnQgNjY2NSBp bXBsZW1lbnRhdGlvbiB3aGljaCBpcyB3aGF0IHRoaXMgY2xhcmlmaWNhdGlvbiBkb2N1bWVudCBp cyBhYm91dC48YnI+DQpJZiBpdCBhY2NlcHRzIGluLWRpYWxvZyBzdWJzY3JpcHRpb24gY3JlYXRp bmcgUkVGRVJzIGl0IGlzIGZvbGxvd2luZyAzMjY1LCBub3QgNjY2NSAtIGZ1cnRoZXIgaXQgaXMg dmlvbGF0aW5nIGEgNjY2NSByZXF1aXJlbWVudC48YnI+DQpJZiBpdCBhY2NlcHRzIG5vIFJFRkVS cyB3aGF0c29ldmVyLCB0aGVuIGl0J3Mgbm90IGFmZmVjdGVkIGJ5IHRoaXMgZG9jdW1lbnQuPGJy Pg0KPGJyPg0KSWYgdGhlIHBvaW50IG9mIHRoZSB3b3Jkc21pdGhpbmcgaXMgdG8gbWFrZSBsZWdh Y3kgaW1wbGVtZW50YXRpb25zIGNvbXBsaWFudCB3aXRoIDY2NjUsIHRoZXJlJ3Mgbm8gd2F5IHRv IHN1Y2NlZWQgLSB0aGV5IHNpbXBseSBhcmVuJ3QuPGJyPg0KPGJyPg0KSWYgdGhhdCdzIG5vdCB0 aGUgcG9pbnQgb2YgdGhlIHdvcmRzbWl0aGluZywgd2hhdCBpcz88YnI+DQo8YnI+DQpBdCB0aGUg bW9tZW50LCBJIHRoaW5rIHdoYXQgSSBzZW50IGJlbG93IGlzIHN0aWxsIHRoZSByaWdodCBwYXRo IGZvcndhcmQuPGJyPg0KPGJyPg0KUmpTPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOC8xLzE0LCAxOjQ0IEFNLCBJdm8gU2Vk bGFjZWsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5BbnkgY29tbWVudHMg b24gdGhlIHByb3Bvc2FsIGJlbG93Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5LaW5kIHJlZ2FyZHM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+SXZvIFNlZGxh Y2VrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7Jm5ic3A7IElmIGEgUkVGRVIgcmVxdWVzdCBpcyBh Y2NlcHRlZCAodGhhdCBpcywgYSAyeHggY2xhc3MgcmVzcG9uc2UgaXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzMzMzMzMyI+Jm5ic3A7Jm5ic3A7IHJldHVybmVkKSwgdGhlIHJlY2lwaWVudCBNVVNUIGNy ZWF0ZSBhIHN1YnNjcmlwdGlvbiBhbmQgc2VuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzMzMzIj4m bmJzcDsmbmJzcDsgbm90aWZpY2F0aW9ucyBvZiB0aGUgc3RhdHVzIG9mIHRoZSByZWZlciBhcyBk ZXNjcmliZWQgaW4gU2VjdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzMzMzIj4mbmJzcDsmbmJz cDsgMi40LjQuPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4NCiBzaXBjb3JlIFs8YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGll dGYub3JnIj5tYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+SXZvIFNlZGxhY2VrPGJyPg0KPGI+U2VudDo8L2I+IDMxLiDEjWVydmVuY2UgMjAx NCA5OjI2PGJyPg0KPGI+VG86PC9iPiBSb2JlcnQgU3BhcmtzOyBBbmRyZXcgQWxsZW47IEFkYW0g Um9hY2g7IDxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj4NCnNpcGNvcmVAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRp b25zLTAzLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+SGVsbG8sPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkFj Y29yZGluZyB0byB0aGUgZHJhZnQsIHRoZSBwdXJwb3NlIG9mIEdSVVUgaW4gQ29udGFjdCBvZiBJ TlZJVEUgcmVxdWVzdCB0byAmcXVvdDs8L3NwYW4+PGJyPg0KJm5ic3A7Jm5ic3A7IGVuc3VyZXMg dGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55PGJy Pg0KJm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUgYXQgdGhpcyBV QS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZxdW90Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5J ZiBhIFVBIHJlamVjdHMgYW55IG91dC1vZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9u ZGluZyB0byBhbnkgZGlhbG9ncyByZWxhdGVkIHRvIGFuIElOVklURSByZXF1ZXN0LCB0aGVuIHNl dHRpbmcgdXAgR1JVVSBpbiBDb250YWN0IG9mIElOVklURSBkb2VzIG5vdA0KIHByb3ZpZGUgYW55 IHB1cnBvc2UuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojQzA1MDREIj5UaGlzIGlzIHRydWUgX19yZWdhcmRsZXNzX18gd2hldGhlciB0aGUg VUEgc3VwcG9ydHMgYW5kIHVzZSB0aGUNCjwvc3Bhbj5kcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZl ci1leHBsaWNpdHN1Yi4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPlNlZSBhdHRhY2hlZCBtYWlsIGdp dmluZyBhbiBleGFtcGxlIG9mIFVBIGhhdmluZyB0d28gdHlwZXMgb2Ygc2Vzc2lvbnMsIFR5cGVf QSB0cmFuc2ZlcnJhYmxlIGJ5IFJFRkVSLCBhbmQgVHlwZV9CIG5vdCB0cmFuc2ZlcnJhYmxlIGJ5 IFJFRkVSLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+R2l2ZW4gdGhhdCBkaWZmZXJlbnQg c3RhbmRhcmRpemF0aW9uIG9yZ2FuaXphdGlvbiBoYXMgZGVmaW5lZCBzbyBtYW55IGVuYWJsZXJz IHdoaWNoIGNhbiBydW4gb24gYSBzaW5nbGUgVUEsIEkgZmluZCBpdCB3ZWlyZCB0aGF0IG9uZSBj YW4gZ3VhcmFudGVlIHRoYXQgdGhlIGFib3ZlDQogY2Fubm90IG9jY3VyLiA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+VGh1cywg SSBoZXNpdGF0ZSB0byBtYW5kYXRlIGFuIHVubmVjZXNzYXJ5IHJlcXVpcmVtZW50IGluZmx1ZW5j aW5nIHBvc3NpYmxlIGV4aXN0aW5nIFVBIGltcGxlbWVudGF0aW9ucyBhbmQgSSBwcmVmZXIgdG8g YmUgZXhwbGljaXQgb24gdGhlIGV4Y2VwdGlvbiBmb3IgdXNhZ2UNCiBvZiBHUlVVIGluIENvbnRh Y3Qgb2YgSU5WSVRFIHJlcXVlc3Q6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBSRUZFUiByZXF1ZXN0IG5lZWRz IHRvIGluY2x1ZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYSBHUlVVIGlu IHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiZuYnNwOyBU aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQt b2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUg YXQgdGhpcyBVQS4gPHNwYW4gc3R5bGU9ImNvbG9yOiNDMDUwNEQiPiZndDsmZ3Q7Jmd0O1VBcyB0 aGF0IHdpbGwgbm90IGFjY2VwdCBhbnkgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3Jy ZXNwb25kaW5nIHRvIGRpYWxvZyhzKSBjcmVhdGVkIGJ5IGFuIElOVklURSByZXF1ZXN0PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojQzA1MDREIj4mbmJz cDsmbmJzcDsgYXJlIGV4ZW1wdGVkIGZyb20gaW5jbHVkaW5nIGEgR1JVVSBpbiB0aGUgQ29udGFj dCBoZWFkZXIgZmllbGQgb2YgdGhlIElOVklURSByZXF1ZXN0LiZsdDsmbHQ7Jmx0Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQi PktpbmQgcmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojQzA1MDREIj5Jdm8gU2VkbGFjZWs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUw NEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0 ZXh0Ij4gUm9iZXJ0IFNwYXJrcyBbPGEgaHJlZj0ibWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29t Ij5tYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDMw LiDEjWVydmVuY2UgMjAxNCAxODo1NDxicj4NCjxiPlRvOjwvYj4gQW5kcmV3IEFsbGVuOyBBZGFt IFJvYWNoOyBJdm8gU2VkbGFjZWs7IDxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj4N CnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJl ZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDcvMzAvMTQsIDEwOjMzIEFNLCBBbmRyZXcgQWxsZW4gd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBhIGdlbmVyYWwgY29uY2VybiB3aXRo IHRoZSBkaXJlY3Rpb24gdGhpcyBpcyBub3cgZ29pbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5JIGRvbid0IHRoaW5rIHlvdSBoYXZlIHRoZSBiYWNrd2FyZHMtY29tcGF0aWJpbGl0 eSBjb25jZXJuIHF1aXRlIHJpZ2h0LCBidXQgSSBhZ3JlZSB0aGF0IHRoZSBjdXJyZW50IHdvcmRp bmcgaXNuJ3QgdGhlcmUgeWV0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcmUgd2Ugbm93IHNheWluZyBoZXJlIHRoYXQgaXTigJlz IE9LIGZvciBhIFVBIHRoYXQgc3VwcG9ydHMgcmVjZWl2aW5nIFJFRkVSIHRvIGFyYml0cmFyaWx5 IHJlamVjdCBhbnkgUkVGRVIgdGhhdCB3b3VsZCBjcmVhdGUgYSBzdWJzY3JpcHRpb24gKGkuZSBi ZSBpbmNvbXBhdGlibGUNCiB3aXRoIFJGQyAzNTE1IFVBQ3MgYnkgYmFzaWNhbGx5IG5vdCBzdXBw b3J0aW5nIFJGQyAzNTE1IFVBUyBjb21wbGlhbnQgYmVoYXZpb3IpPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ Tm8sIF90aGlzXyBkb2N1bWVudCBpcyBub3QgZGVmaW5pbmcgbmV3IGJlaGF2aW9yLiBJdCdzIG9u bHkgY2xhcmlmeWluZyB3aGF0J3MgYWxyZWFkeSBkZWZpbmVkLjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BY2Nv cmRpbmcgdG8gUkZDIDM1MTU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjIu NC40IFVzaW5nIFNJUCBFdmVudHMgdG8gUmVwb3J0IHRoZSBSZXN1bHRzIG9mIHRoZSBSZWZlcmVu Y2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIE5PVElGWSBtZWNo YW5pc20gZGVmaW5lZCBpbiBbMl0NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28t aGlnaGxpZ2h0OnllbGxvdyI+TVVTVDwvc3Bhbj4gYmUgdXNlZCB0byBpbmZvcm0gdGhlIGFnZW50 IHNlbmRpbmcgdGhlIFJFRkVSIG9mIHRoZSBzdGF0dXMgb2YgdGhlIHJlZmVyZW5jZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZXJlZm9yZSB0aGUgYWJpbGl0eSB0byBjcmVhdGUgYW4gaW1wbGljaXQgc3Vic2NyaXB0 aW9uIHdoZW4gYWNjZXB0aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5GV0lXLCBBY2NlcHRpbmcgaXMgdGhl IGtleSB3b3JkIGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YSBSRUZFUiBpcyBtYW5kYXRv cnkgYmVoYXZpb3IgaW4gUkZDIDM1MTUgYW5kIGlzIGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBi eSBhbGwgUkZDIDM1MTUgVUFDczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBiZWZvcmUgYWdyZWVpbmcgYW55 IHdvcmRpbmcgaGVyZSB3ZSBzaG91bGQgaGF2ZSBhIGdlbmVyYWwgZGlzY3Vzc2lvbiBvbiB0aGUg cHJpbmNpcGxlIG9mIHdoZXRoZXIgdGhlc2UgZXh0ZW5zaW9ucyB0aGF0IGFsbG93IFVBQ3MgdG8g cmVxdWVzdCB0aGF0IG5vDQogaW1wbGljaXQgc3Vic2NyaXB0aW9uIGNhbiBiZSBlZmZlY3RpdmVs eSByZXF1aXJlZCBieSBSRUZFUiBVQVMgdG8gYmUgc3VwcG9ydGVkIGF0IHRoZSBVQUMuDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPlRoaXMsIGFuZCB3aGF0IHlvdSBoYXZlIGJlbG93LCBpcyBhIGRpc2N1c3Np b24gd2UgZGVmaW5pdGVseSBuZWVkIHRvIGhhdmUgYXMgcGFydCBvZiB0aGUgZXh0ZW5zaW9uIGRv Y3VtZW50Ljxicj4NCkl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gd2FpdCBmb3IgdGhhdCBkaXNjdXNz aW9uIHRvIGNvbXBsZXRlIHRoZSBjbGFyaWZpY2F0aW9ucyBkb2N1bWVudCB0aGF0IHRhbGtzIGFi b3V0IHdoYXQgdGhlIHNwZWNzIHNheSBfbm93Xy48YnI+DQo8YnI+DQpNeSBkaXNjb21mb3J0IHdp dGggdGhlIGN1cnJlbnQgdGV4dCBpcyB0aGF0IHdlJ3ZlIG1hZGUgaXQgY29tcGxleCB0byBtYWtl IGl0IHNvIHRoYXQgd2UgZG9uJ3QgaGF2ZSB0byB1cGRhdGUgdGhlIGRvY3VtZW50IG9uY2UgdGhl IHByb3Bvc2VkIGV4dGVuc2lvbnMgZXhpc3QuPGJyPg0KVGhlcmUgYXJlIE5PIGN1cnJlbnRseSBz dGFuZGFyZGl6ZWQgY2FzZXMgd2hlcmUgdGhlIGV4ZW1wdGlvbiBpbiB0aGUgY3VycmVudCB0ZXh0 IHdvdWxkIGJlIGludm9rZWQsIGFuZCBJIGRvbid0IHRoaW5rIHBlb3BsZSBhcmUgdHJ5aW5nIHRv IGFyZ3VlIHRoZXJlIGFyZSAtIEknbSBoZWFyaW5nIHRoYXQgdG8gZ2V0IHRoZXJlLCB0aGV5IGV4 cGVjdCB0byBpbnZva2UgdGhlIHlldC10by1iZS1kZWZpbmVkIGV4dGVuc2lvbi48YnI+DQo8YnI+ DQpTbywgbGV0cyBnbyBiYWNrIHRvIHRoZSBzbGlnaHRseSBsb25nZXIgc2VudGVuY2UgdGhhdCBs ZWQgdG8gdGhpczo8YnI+DQo8YnI+DQpBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBzdWJzY3JpcHRp b24tY3JlYXRpbmcgUkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlPGJyPg0KYSBHUlVVIGFz IHRoZSBDb250YWN0IGluIGFsbCBJTlZJVEUgcmVxdWVzdHMgdG8gZW5zdXJlIG91dC1vZi1kaWFs b2cgUkVGRVIgcmVxdWVzdHM8YnI+DQpyZWxhdGVkIHRvIGFueSBkaWFsb2cgY3JlYXRlZCBieSB0 aGUgSU5WSVRFIGFycml2ZSBhdCB0aGlzIFVBLjxicj4NCjxicj4NCkluIGFuIGF0dGVtcHQgdG8g YmUgZnV0dXJlLXByb29mLCB0aGF0J3MgaW50cm9kdWNpbmcgdGhlIHBvdGVudGlhbCBmb3IgY29u ZnVzaW9uIGFib3V0IHdoYXQgdGhlIGN1cnJlbnQgc3RhbmRhcmRzIGRlZmluZS48YnI+DQpMZXQn cyByZW1vdmUgdGhhdCBjb25mdXNpb24uPGJyPg0KSGVyZSdzIGEgcHJvcG9zZWQgcmVwbGFjZW1l bnQsIHRha2luZyBBZGFtJ3Mgc2VudGVuY2Ugc2ltcGxpZmljYXRpb24gaW50byBhY2NvdW50Ojxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyBBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBSRUZFUiByZXF1 ZXN0IG5lZWRzIHRvIGluY2x1ZGU8YnI+DQombmJzcDsmbmJzcDsgYSBHUlVVIGluIHRoZSBDb250 YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiZuYnNwOyBUaGlzPGJyPg0K Jm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNv cnJlc3BvbmRpbmcgdG8gYW55PGJyPg0KJm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUgZGlh bG9ncyBhcnJpdmUgYXQgdGhpcyBVQS4gRnV0dXJlIGV4dGVuc2lvbnMgPGJyPg0KJm5ic3A7Jm5i c3A7IFtkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdHN1Yl0gbWlnaHQgcmVsYXgg dGhpcyByZXF1aXJlbWVudCA8YnI+DQombmJzcDsmbmJzcDsgYnkgZGVmaW5pbmcgYSBSRUZFUiBy ZXF1ZXN0IHRoYXQgY2Fubm90IGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24uPGJyPg0K PGJyPg0KPGJyPg0KVW5sZXNzIEkgaGVhciBvYmplY3Rpb24gc29vbiwgSSdsbCByZXYgdGhlIGRy YWZ0IHdpdGggdGhhdCBjb250ZW50Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBzbyB0aGVuIEkgdGhpbmsg d2Ugd2lsbCBuZWVkIGEgbmV3IHNpcCBvcHRpb25zIHRhZyAoZS5nIFJFRkVSLU5PU1VCKSB0byBi ZSB1c2VkIGluIHBsYWNlIG9mIHRoZSBSRUZFUiBvcHRpb25zIHRhZyBzbyB0aGF0IGEgUkZDIDM1 MTUgY29tcGxpYW50IFVBIHRoYXQgZXhwZWN0cw0KIGEgTk9USUZZIHRvIGJlIHNlbnQgdXBvbiBy ZWNlaXB0IG9mIGEgUkVGRVIgYW5kIHRoYXQgaW5jbHVkZXMgYW4gQWNjZXB0LUNvbnRhY3QgcmVx dWVzdCB0byByZWFjaCBhIFVBIHRoYXQgc3VwcG9ydHMgUkVGRVIgZG9lc27igJl0IGVuZCB1cCBh dCBhIFVBUyB0aGF0IGRvZXNu4oCZdCAmbmJzcDtzdXBwb3J0IGNvbXBsaWFudCBSRkMgMzUxNSBi ZWhhdmlvciBhbmQgZW5kcyB1cCBoYXZpbmcgaXRzIFJFRkVSIHJlcXVlc3RzIHJlamVjdGVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TXkgb3duIHZpZXcgaXMgdGhhdCB3ZSBzaG91bGQga2VlcCB3aXRoIHRoZSBwcmlu Y2lwbGUgb2YgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBhbmQgdGhhdCBldmVuIHdoZW4gdGhlc2Ug bm8gYXV0b21hdGljIHN1YnNjcmlwdGlvbiBleHRlbnNpb25zIGFyZSBzdXBwb3J0ZWQNCiB0aGF0 IGZ1bGwgc3VwcG9ydCBmb3IgUkZDIDM1MTUgYmVoYXZpb3IgaXMgY29udGludWVkLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QW5kcmV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBzaXBjb3JlIFs8YSBocmVm PSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2lwY29yZS1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWRhbSBSb2FjaDxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDExOjE5IEFNPGJyPg0KPGI+VG86PC9iPiBJ dm8gU2VkbGFjZWs7IFJvYmVydCBTcGFya3M7IDxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYu b3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNv cmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFya3Mtc2lwY29y ZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNy8yOS8xNCAwOTo1MiwgSXZvIFNlZGxhY2Vr IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPlRodXMsIHRoZSB0ZXh0IHNob3VsZCBzdGF0ZTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBJbiBnZW5lcmFsLCBVQXMgdGhhdCBzdXBw b3J0IHJlY2VpdmluZyAmZ3Q7Jmd0O2FuZCBhY2NlcHRpbmcgYW4gb3V0LW9mLWRpYWxvZyZsdDsm bHQ7IFJFRkVSIHJlcXVlc3QgJmd0OyZndDtjb3JyZXNwb25kaW5nIHRvIGEgZGlhbG9nIGVzdGFi bGlzaGVkIGJ5IGFuIElOVklURSByZXF1ZXN0Jmx0OyZsdDsgbmVlZCB0byBpbmNsdWRlPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBhIEdSVVUgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxk IG9mICZndDsmZ3Q7dGhlJmx0OyZsdDsgSU5WSVRFIHJlcXVlc3QuJm5ic3A7IFRoaXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJl cXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBy ZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJlIHJvdXRlZCB0byB0aGUgY29ycmVjdCB1c2VyIGFn ZW50LiZuYnNwOyBVQXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoYXQgd2lsbCBuZXZl ciBjcmVhdGUgYSBpbXBsaWNpdCBzdWJzY3JpcHRpb24gaW4gcmVzcG9uc2UgdG8gYSBSRUZFUjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgKHRoYXQgaXMsIHRob3NlIHRoYXQgd2lsbCByZWpl Y3QgYW55IFJFRkVSIHRoYXQgbWlnaHQgcmVzdWx0IGluIGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyBpbXBsaWNpdCBzdWJzY3JpcHRpb24pIGFyZSBleGVtcHRlZCBmcm9tIHRoaXMgYmVo YXZpb3IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpJIGhlbHBlZCB3aXRo IHRoZSBwaHJhc2luZyBoZXJlLCBhbmQgb25lIG9mIHRoZSBnb2FscyBoZXJlIHdhcyB0byBtYWtl IHRoZSBmaXJzdCBzZW50ZW5jZSBjb3ZlciB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgY2FzZXMg KGhlbmNlICZxdW90O2luIGdlbmVyYWwmcXVvdDspLCB3aXRoIHRoZSBleGNlcHRpb25hbCBjYXNl cyBkZXNjcmliZWQgbGF0ZXIuIFRoZSBwcm9ibGVtIHdhcyB0aGF0IHRoZSBvdmVyYWxsIGNvbmNl cHQgd2FzIGdldHRpbmcgbG9zdCBpbiBhIG1hemUNCiBvZiB0d2lzdHkgY2xhdXNlczogdGhlIGNs YXJpZmljYXRpb24gaGFkIGJlY29tZSB3b3JzZSB0aGFuIHRoZSBzb3VyY2UgdGV4dDsgaXQgd2Fz IGFjdHVhbGx5IG1vcmUgY29uZnVzaW5nLjxicj4NCjxicj4NCllvdXIgcHJvcG9zYWwgcmV0dXJu cyBpdCB0byB0aGlzIHZlcnkgY29uZnVzaW5nIHN0YXRlLCBhbmQgaXMgd2F5LCB3YXkgb3V0IGlu dG8gdGhlIHJlYWxtIG9mIGV4Y2VwdGlvbmFsIGNhc2VzLjxicj4NCjxicj4NClNvIEknbGwgY291 bnRlcnByb3Bvc2U6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBJbiBnZW5lcmFs LCBVQXMgdGhhdCBzdXBwb3J0IHJlY2VpdmluZyBSRUZFUiByZXF1ZXN0cyBuZWVkIHRvIGluY2x1 ZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYSBHUlVVIGluIHRoZSBDb250 YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiZuYnNwOyBUaGlzPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9n IFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcmUgcm91dGVkIHRvIHRo ZSBjb3JyZWN0IHVzZXIgYWdlbnQuJm5ic3A7IFVBczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyB0aGF0IHdpbGwgbm90IGNyZWF0ZSBhIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBp biByZXNwb25zZSB0byBhIFJFRkVSPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGZvciB0aGUgcmVzdWx0aW5nIGRpYWxvZyhzKSAtLSB0aGF0IGlzLCB0aG9zZSB0aGF0IHdpbGwg cmVqZWN0IGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY29ycmVzcG9uZGlu ZyBSRUZFUiB0aGF0IG1pZ2h0IHJlc3VsdCBpbiBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gLS08 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXJlIGV4ZW1wdGVkIGZyb20gdGhp cyBiZWhhdmlvci48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K L2E8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiNDMDUwNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_39B5E4D390E9BD4890E2B3107900610112711708ESESSMB301erics_-- From nobody Tue Aug 12 05:48:32 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3788E1A0862 for ; Tue, 12 Aug 2014 05:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAdCMEitAjLT for ; Tue, 12 Aug 2014 05:48:26 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 365171A0842 for ; Tue, 12 Aug 2014 05:48:25 -0700 (PDT) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Aug 2014 08:48:25 -0400 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 12 Aug 2014 08:48:24 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 08:48:24 -0400 From: Andrew Allen To: Robert Sparks , Adam Roach , "Ivo Sedlacek" , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPqrHlmnmUsyWPWkiMyO8iEueSdZu3Zw8AgAAHa4CAAU4pgIAAXqcAgBPlYaA= Date: Tue, 12 Aug 2014 12:48:24 +0000 Message-ID: References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> In-Reply-To: <53D92314.6040607@nostrum.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233991B539XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kmNHGznJDQs9nceJ-pHblmXUn-c Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 12:48:29 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233991B539XMB122CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpSZS1lbmdhZ2luZyBpbiB0aGlzIHRocmVhZCBhZnRlciAgdGFraW5nIHNvbWUgdmFjYXRpb24g dGltZS4NCg0KSW4gbXkgdmlldyBpZiB3ZSBhY2NlcHQgdGhlIGNvbmNlcHQgIHRoYXQgYSBVQVMg aGFzIGEgcG9saWN5IG5vdCB0byBhY2NlcHQgYW55IFJFRkVSIHRoYXQgd291bGQgY3JlYXRlIGFu IGltcGxpY2l0IHN1YnNjcmlwdGlvbiB0aGF0IG1lYW5zIHdlIGFjY2VwdCB0aGUgY29uY2VwdCB0 aGF0IFVBUyB0aGF0IHN1cHBvcnQgUkVGRVIgbWV0aG9kICBkb27igJl0IGludGVyb3BlcmF0ZSAo YW5kIHRoZXJlZm9yZSBhcmUgbm90IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGgpIGJhc2ljIFJG QyAzNTE1IFVBQ3MgdGhhdCBkb27igJl0IHN1cHBvcnQgdGhlIG5ldyBleHRlbnNpb25zLiBJTUhP IHRoYXQgaXMgbm90IGEgcm9hZCB3ZSBvdWdodCB0byBnbyBkb3duLg0KDQpBbmRyZXcNCg0KRnJv bTogUm9iZXJ0IFNwYXJrcyBbbWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29tXQ0KU2VudDogV2Vk bmVzZGF5LCBKdWx5IDMwLCAyMDE0IDEyOjU0IFBNDQpUbzogQW5kcmV3IEFsbGVuOyBBZGFtIFJv YWNoOyBJdm8gU2VkbGFjZWs7IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29y ZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3Jl LXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dA0KDQoNCk9uIDcvMzAvMTQsIDEwOjMzIEFNLCBB bmRyZXcgQWxsZW4gd3JvdGU6DQpJIGhhdmUgYSBnZW5lcmFsIGNvbmNlcm4gd2l0aCB0aGUgZGly ZWN0aW9uIHRoaXMgaXMgbm93IGdvaW5nLg0KSSBkb24ndCB0aGluayB5b3UgaGF2ZSB0aGUgYmFj a3dhcmRzLWNvbXBhdGliaWxpdHkgY29uY2VybiBxdWl0ZSByaWdodCwgYnV0IEkgYWdyZWUgdGhh dCB0aGUgY3VycmVudCB3b3JkaW5nIGlzbid0IHRoZXJlIHlldC4NCg0KDQpBcmUgd2Ugbm93IHNh eWluZyBoZXJlIHRoYXQgaXTigJlzIE9LIGZvciBhIFVBIHRoYXQgc3VwcG9ydHMgcmVjZWl2aW5n IFJFRkVSIHRvIGFyYml0cmFyaWx5IHJlamVjdCBhbnkgUkVGRVIgdGhhdCB3b3VsZCBjcmVhdGUg YSBzdWJzY3JpcHRpb24gKGkuZSBiZSBpbmNvbXBhdGlibGUgd2l0aCBSRkMgMzUxNSBVQUNzIGJ5 IGJhc2ljYWxseSBub3Qgc3VwcG9ydGluZyBSRkMgMzUxNSBVQVMgY29tcGxpYW50IGJlaGF2aW9y KT8NCk5vLCBfdGhpc18gZG9jdW1lbnQgaXMgbm90IGRlZmluaW5nIG5ldyBiZWhhdmlvci4gSXQn cyBvbmx5IGNsYXJpZnlpbmcgd2hhdCdzIGFscmVhZHkgZGVmaW5lZC4NCg0KDQoNCg0KQWNjb3Jk aW5nIHRvIFJGQyAzNTE1DQoNCjIuNC40IFVzaW5nIFNJUCBFdmVudHMgdG8gUmVwb3J0IHRoZSBS ZXN1bHRzIG9mIHRoZSBSZWZlcmVuY2UNCg0KICAgICAgICAgICAgICAgIFRoZSBOT1RJRlkgbWVj aGFuaXNtIGRlZmluZWQgaW4gWzJdIE1VU1QgYmUgdXNlZCB0byBpbmZvcm0gdGhlIGFnZW50IHNl bmRpbmcgdGhlIFJFRkVSIG9mIHRoZSBzdGF0dXMgb2YgdGhlIHJlZmVyZW5jZS4NCg0KVGhlcmVm b3JlIHRoZSBhYmlsaXR5IHRvIGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gd2hlbiBh Y2NlcHRpbmcNCkZXSVcsIEFjY2VwdGluZyBpcyB0aGUga2V5IHdvcmQgaGVyZS4NCg0KYSBSRUZF UiBpcyBtYW5kYXRvcnkgYmVoYXZpb3IgaW4gUkZDIDM1MTUgYW5kIGlzIGV4cGVjdGVkIHRvIGJl IHN1cHBvcnRlZCBieSBhbGwgUkZDIDM1MTUgVUFDcw0KDQpJIHRoaW5rIGJlZm9yZSBhZ3JlZWlu ZyBhbnkgd29yZGluZyBoZXJlIHdlIHNob3VsZCBoYXZlIGEgZ2VuZXJhbCBkaXNjdXNzaW9uIG9u IHRoZSBwcmluY2lwbGUgb2Ygd2hldGhlciB0aGVzZSBleHRlbnNpb25zIHRoYXQgYWxsb3cgVUFD cyB0byByZXF1ZXN0IHRoYXQgbm8gaW1wbGljaXQgc3Vic2NyaXB0aW9uIGNhbiBiZSBlZmZlY3Rp dmVseSByZXF1aXJlZCBieSBSRUZFUiBVQVMgdG8gYmUgc3VwcG9ydGVkIGF0IHRoZSBVQUMuDQpU aGlzLCBhbmQgd2hhdCB5b3UgaGF2ZSBiZWxvdywgaXMgYSBkaXNjdXNzaW9uIHdlIGRlZmluaXRl bHkgbmVlZCB0byBoYXZlIGFzIHBhcnQgb2YgdGhlIGV4dGVuc2lvbiBkb2N1bWVudC4NCkl0IGlz IG5vdCBuZWNlc3NhcnkgdG8gd2FpdCBmb3IgdGhhdCBkaXNjdXNzaW9uIHRvIGNvbXBsZXRlIHRo ZSBjbGFyaWZpY2F0aW9ucyBkb2N1bWVudCB0aGF0IHRhbGtzIGFib3V0IHdoYXQgdGhlIHNwZWNz IHNheSBfbm93Xy4NCg0KTXkgZGlzY29tZm9ydCB3aXRoIHRoZSBjdXJyZW50IHRleHQgaXMgdGhh dCB3ZSd2ZSBtYWRlIGl0IGNvbXBsZXggdG8gbWFrZSBpdCBzbyB0aGF0IHdlIGRvbid0IGhhdmUg dG8gdXBkYXRlIHRoZSBkb2N1bWVudCBvbmNlIHRoZSBwcm9wb3NlZCBleHRlbnNpb25zIGV4aXN0 Lg0KVGhlcmUgYXJlIE5PIGN1cnJlbnRseSBzdGFuZGFyZGl6ZWQgY2FzZXMgd2hlcmUgdGhlIGV4 ZW1wdGlvbiBpbiB0aGUgY3VycmVudCB0ZXh0IHdvdWxkIGJlIGludm9rZWQsIGFuZCBJIGRvbid0 IHRoaW5rIHBlb3BsZSBhcmUgdHJ5aW5nIHRvIGFyZ3VlIHRoZXJlIGFyZSAtIEknbSBoZWFyaW5n IHRoYXQgdG8gZ2V0IHRoZXJlLCB0aGV5IGV4cGVjdCB0byBpbnZva2UgdGhlIHlldC10by1iZS1k ZWZpbmVkIGV4dGVuc2lvbi4NCg0KU28sIGxldHMgZ28gYmFjayB0byB0aGUgc2xpZ2h0bHkgbG9u Z2VyIHNlbnRlbmNlIHRoYXQgbGVkIHRvIHRoaXM6DQoNCkEgVUEgdGhhdCB3aWxsIGFjY2VwdCBh IHN1YnNjcmlwdGlvbi1jcmVhdGluZyBSRUZFUiByZXF1ZXN0IG5lZWRzIHRvIGluY2x1ZGUNCmEg R1JVVSBhcyB0aGUgQ29udGFjdCBpbiBhbGwgSU5WSVRFIHJlcXVlc3RzIHRvIGVuc3VyZSBvdXQt b2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzDQpyZWxhdGVkIHRvIGFueSBkaWFsb2cgY3JlYXRlZCBi eSB0aGUgSU5WSVRFIGFycml2ZSBhdCB0aGlzIFVBLg0KDQpJbiBhbiBhdHRlbXB0IHRvIGJlIGZ1 dHVyZS1wcm9vZiwgdGhhdCdzIGludHJvZHVjaW5nIHRoZSBwb3RlbnRpYWwgZm9yIGNvbmZ1c2lv biBhYm91dCB3aGF0IHRoZSBjdXJyZW50IHN0YW5kYXJkcyBkZWZpbmUuDQpMZXQncyByZW1vdmUg dGhhdCBjb25mdXNpb24uDQpIZXJlJ3MgYSBwcm9wb3NlZCByZXBsYWNlbWVudCwgdGFraW5nIEFk YW0ncyBzZW50ZW5jZSBzaW1wbGlmaWNhdGlvbiBpbnRvIGFjY291bnQ6DQoNCiAgIEEgVUEgdGhh dCB3aWxsIGFjY2VwdCBhIFJFRkVSIHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZQ0KICAgYSBHUlVV IGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiAgVGhp cw0KICAgZW5zdXJlcyB0aGF0IG91dC1vZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9u ZGluZyB0byBhbnkNCiAgIHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUgYXQgdGhpcyBV QS4gRnV0dXJlIGV4dGVuc2lvbnMNCiAgIFtkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBs aWNpdHN1Yl0gbWlnaHQgcmVsYXggdGhpcyByZXF1aXJlbWVudA0KICAgYnkgZGVmaW5pbmcgYSBS RUZFUiByZXF1ZXN0IHRoYXQgY2Fubm90IGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24u DQoNCg0KVW5sZXNzIEkgaGVhciBvYmplY3Rpb24gc29vbiwgSSdsbCByZXYgdGhlIGRyYWZ0IHdp dGggdGhhdCBjb250ZW50Lg0KDQoNCg0KDQpJZiBzbyB0aGVuIEkgdGhpbmsgd2Ugd2lsbCBuZWVk IGEgbmV3IHNpcCBvcHRpb25zIHRhZyAoZS5nIFJFRkVSLU5PU1VCKSB0byBiZSB1c2VkIGluIHBs YWNlIG9mIHRoZSBSRUZFUiBvcHRpb25zIHRhZyBzbyB0aGF0IGEgUkZDIDM1MTUgY29tcGxpYW50 IFVBIHRoYXQgZXhwZWN0cyBhIE5PVElGWSB0byBiZSBzZW50IHVwb24gcmVjZWlwdCBvZiBhIFJF RkVSIGFuZCB0aGF0IGluY2x1ZGVzIGFuIEFjY2VwdC1Db250YWN0IHJlcXVlc3QgdG8gcmVhY2gg YSBVQSB0aGF0IHN1cHBvcnRzIFJFRkVSIGRvZXNu4oCZdCBlbmQgdXAgYXQgYSBVQVMgdGhhdCBk b2VzbuKAmXQgIHN1cHBvcnQgY29tcGxpYW50IFJGQyAzNTE1IGJlaGF2aW9yIGFuZCBlbmRzIHVw IGhhdmluZyBpdHMgUkVGRVIgcmVxdWVzdHMgcmVqZWN0ZWQuDQoNCk15IG93biB2aWV3IGlzIHRo YXQgd2Ugc2hvdWxkIGtlZXAgd2l0aCB0aGUgcHJpbmNpcGxlIG9mIGJhY2t3YXJkIGNvbXBhdGli aWxpdHkgYW5kIHRoYXQgZXZlbiB3aGVuIHRoZXNlIG5vIGF1dG9tYXRpYyBzdWJzY3JpcHRpb24g ZXh0ZW5zaW9ucyBhcmUgc3VwcG9ydGVkIHRoYXQgZnVsbCBzdXBwb3J0IGZvciBSRkMgMzUxNSBi ZWhhdmlvciBpcyBjb250aW51ZWQuDQoNCkFuZHJldw0KDQoNCg0KDQoNCkZyb206IHNpcGNvcmUg W21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFJvYWNo DQpTZW50OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDExOjE5IEFNDQpUbzogSXZvIFNlZGxhY2Vr OyBSb2JlcnQgU3BhcmtzOyBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0DQoNCk9u IDcvMjkvMTQgMDk6NTIsIEl2byBTZWRsYWNlayB3cm90ZToNCg0KVGh1cywgdGhlIHRleHQgc2hv dWxkIHN0YXRlOg0KDQoNCiAgIEluIGdlbmVyYWwsIFVBcyB0aGF0IHN1cHBvcnQgcmVjZWl2aW5n ID4+YW5kIGFjY2VwdGluZyBhbiBvdXQtb2YtZGlhbG9nPDwgUkVGRVIgcmVxdWVzdCA+PmNvcnJl c3BvbmRpbmcgdG8gYSBkaWFsb2cgZXN0YWJsaXNoZWQgYnkgYW4gSU5WSVRFIHJlcXVlc3Q8PCBu ZWVkIHRvIGluY2x1ZGUNCiAgIGEgR1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2Yg Pj50aGU8PCBJTlZJVEUgcmVxdWVzdC4gIFRoaXMNCiAgIGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlh bG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55DQogICByZXN1bHRpbmcgSU5W SVRFIGRpYWxvZ3MgYXJlIHJvdXRlZCB0byB0aGUgY29ycmVjdCB1c2VyIGFnZW50LiAgVUFzDQog ICB0aGF0IHdpbGwgbmV2ZXIgY3JlYXRlIGEgaW1wbGljaXQgc3Vic2NyaXB0aW9uIGluIHJlc3Bv bnNlIHRvIGEgUkVGRVINCiAgICh0aGF0IGlzLCB0aG9zZSB0aGF0IHdpbGwgcmVqZWN0IGFueSBS RUZFUiB0aGF0IG1pZ2h0IHJlc3VsdCBpbiBhbg0KICAgaW1wbGljaXQgc3Vic2NyaXB0aW9uKSBh cmUgZXhlbXB0ZWQgZnJvbSB0aGlzIGJlaGF2aW9yLg0KDQpJIGhlbHBlZCB3aXRoIHRoZSBwaHJh c2luZyBoZXJlLCBhbmQgb25lIG9mIHRoZSBnb2FscyBoZXJlIHdhcyB0byBtYWtlIHRoZSBmaXJz dCBzZW50ZW5jZSBjb3ZlciB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgY2FzZXMgKGhlbmNlICJp biBnZW5lcmFsIiksIHdpdGggdGhlIGV4Y2VwdGlvbmFsIGNhc2VzIGRlc2NyaWJlZCBsYXRlci4g VGhlIHByb2JsZW0gd2FzIHRoYXQgdGhlIG92ZXJhbGwgY29uY2VwdCB3YXMgZ2V0dGluZyBsb3N0 IGluIGEgbWF6ZSBvZiB0d2lzdHkgY2xhdXNlczogdGhlIGNsYXJpZmljYXRpb24gaGFkIGJlY29t ZSB3b3JzZSB0aGFuIHRoZSBzb3VyY2UgdGV4dDsgaXQgd2FzIGFjdHVhbGx5IG1vcmUgY29uZnVz aW5nLg0KDQpZb3VyIHByb3Bvc2FsIHJldHVybnMgaXQgdG8gdGhpcyB2ZXJ5IGNvbmZ1c2luZyBz dGF0ZSwgYW5kIGlzIHdheSwgd2F5IG91dCBpbnRvIHRoZSByZWFsbSBvZiBleGNlcHRpb25hbCBj YXNlcy4NCg0KU28gSSdsbCBjb3VudGVycHJvcG9zZToNCg0KICAgSW4gZ2VuZXJhbCwgVUFzIHRo YXQgc3VwcG9ydCByZWNlaXZpbmcgUkVGRVIgcmVxdWVzdHMgbmVlZCB0byBpbmNsdWRlDQoNCiAg IGEgR1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgYWxsIElOVklURSByZXF1ZXN0 cy4gIFRoaXMNCg0KICAgZW5zdXJlcyB0aGF0IG91dC1vZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMg Y29ycmVzcG9uZGluZyB0byBhbnkNCg0KICAgcmVzdWx0aW5nIElOVklURSBkaWFsb2dzIGFyZSBy b3V0ZWQgdG8gdGhlIGNvcnJlY3QgdXNlciBhZ2VudC4gIFVBcw0KDQogICB0aGF0IHdpbGwgbm90 IGNyZWF0ZSBhIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBpbiByZXNwb25zZSB0byBhIFJFRkVSDQoN CiAgIGZvciB0aGUgcmVzdWx0aW5nIGRpYWxvZyhzKSAtLSB0aGF0IGlzLCB0aG9zZSB0aGF0IHdp bGwgcmVqZWN0IGENCg0KICAgY29ycmVzcG9uZGluZyBSRUZFUiB0aGF0IG1pZ2h0IHJlc3VsdCBp biBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gLS0NCg0KICAgYXJlIGV4ZW1wdGVkIGZyb20gdGhp cyBiZWhhdmlvci4NCg0KL2ENCg0K --_000_BBF5DDFE515C3946BC18D733B20DAD233991B539XMB122CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiNDMDUwNEQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUy Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlLWVuZ2FnaW5nIGluIHRoaXMgdGhyZWFkIGFm dGVyJm5ic3A7IHRha2luZyBzb21lIHZhY2F0aW9uIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBteSB2aWV3 IGlmIHdlIGFjY2VwdCB0aGUgY29uY2VwdCAmbmJzcDt0aGF0IGEgVUFTIGhhcyBhIHBvbGljeSBu b3QgdG8gYWNjZXB0IGFueSBSRUZFUiB0aGF0IHdvdWxkIGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJz Y3JpcHRpb24gdGhhdCBtZWFucyB3ZSBhY2NlcHQgdGhlIGNvbmNlcHQNCiB0aGF0IFVBUyB0aGF0 IHN1cHBvcnQgUkVGRVIgbWV0aG9kJm5ic3A7IGRvbuKAmXQgaW50ZXJvcGVyYXRlIChhbmQgdGhl cmVmb3JlIGFyZSBub3QgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCkgYmFzaWMgUkZDIDM1MTUg VUFDcyB0aGF0IGRvbuKAmXQgc3VwcG9ydCB0aGUgbmV3IGV4dGVuc2lvbnMuIElNSE8gdGhhdCBp cyBub3QgYSByb2FkIHdlIG91Z2h0IHRvIGdvIGRvd24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHJldzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBSb2JlcnQg U3BhcmtzIFttYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBKdWx5IDMwLCAyMDE0IDEyOjU0IFBNPGJyPg0KPGI+VG86PC9iPiBBbmRyZXcg QWxsZW47IEFkYW0gUm9hY2g7IEl2byBTZWRsYWNlazsgc2lwY29yZUBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzMwLzE0LCAxMDozMyBB TSwgQW5kcmV3IEFsbGVuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGhhdmUgYSBnZW5lcmFsIGNvbmNlcm4gd2l0aCB0aGUgZGlyZWN0aW9uIHRoaXMgaXMgbm93IGdv aW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgZG9uJ3QgdGhpbmsgeW91IGhhdmUgdGhlIGJhY2t3YXJkcy1jb21wYXRpYmlsaXR5 IGNvbmNlcm4gcXVpdGUgcmlnaHQsIGJ1dCBJIGFncmVlIHRoYXQgdGhlIGN1cnJlbnQgd29yZGlu ZyBpc24ndCB0aGVyZSB5ZXQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFyZSB3ZSBub3cgc2F5aW5nIGhlcmUg dGhhdCBpdOKAmXMgT0sgZm9yIGEgVUEgdGhhdCBzdXBwb3J0cyByZWNlaXZpbmcgUkVGRVIgdG8g YXJiaXRyYXJpbHkgcmVqZWN0IGFueSBSRUZFUiB0aGF0IHdvdWxkIGNyZWF0ZSBhIHN1YnNjcmlw dGlvbiAoaS5lIGJlIGluY29tcGF0aWJsZQ0KIHdpdGggUkZDIDM1MTUgVUFDcyBieSBiYXNpY2Fs bHkgbm90IHN1cHBvcnRpbmcgUkZDIDM1MTUgVUFTIGNvbXBsaWFudCBiZWhhdmlvcik/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8sIF90aGlzXyBkb2N1bWVu dCBpcyBub3QgZGVmaW5pbmcgbmV3IGJlaGF2aW9yLiBJdCdzIG9ubHkgY2xhcmlmeWluZyB3aGF0 J3MgYWxyZWFkeSBkZWZpbmVkLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BY2NvcmRpbmcg dG8gUkZDIDM1MTU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLjQuNCBVc2lu ZyBTSVAgRXZlbnRzIHRvIFJlcG9ydCB0aGUgUmVzdWx0cyBvZiB0aGUgUmVmZXJlbmNlPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBOT1RJRlkgbWVjaGFuaXNtIGRl ZmluZWQgaW4gWzJdDQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdo dDp5ZWxsb3ciPk1VU1Q8L3NwYW4+IGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBhZ2VudCBzZW5kaW5n IHRoZSBSRUZFUiBvZiB0aGUgc3RhdHVzIG9mIHRoZSByZWZlcmVuY2UuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVy ZWZvcmUgdGhlIGFiaWxpdHkgdG8gY3JlYXRlIGFuIGltcGxpY2l0IHN1YnNjcmlwdGlvbiB3aGVu IGFjY2VwdGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZX SVcsIEFjY2VwdGluZyBpcyB0aGUga2V5IHdvcmQgaGVyZS48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5hIFJFRkVSIGlzIG1hbmRhdG9yeSBiZWhhdmlvciBpbiBSRkMgMzUxNSBh bmQgaXMgZXhwZWN0ZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IGFsbCBSRkMgMzUxNSBVQUNzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIHRoaW5rIGJlZm9yZSBhZ3JlZWluZyBhbnkgd29yZGluZyBoZXJlIHdlIHNob3VsZCBo YXZlIGEgZ2VuZXJhbCBkaXNjdXNzaW9uIG9uIHRoZSBwcmluY2lwbGUgb2Ygd2hldGhlciB0aGVz ZSBleHRlbnNpb25zIHRoYXQgYWxsb3cgVUFDcyB0byByZXF1ZXN0IHRoYXQgbm8NCiBpbXBsaWNp dCBzdWJzY3JpcHRpb24gY2FuIGJlIGVmZmVjdGl2ZWx5IHJlcXVpcmVkIGJ5IFJFRkVSIFVBUyB0 byBiZSBzdXBwb3J0ZWQgYXQgdGhlIFVBQy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMsIGFuZCB3aGF0IHlvdSBoYXZlIGJlbG93LCBpcyBhIGRpc2N1 c3Npb24gd2UgZGVmaW5pdGVseSBuZWVkIHRvIGhhdmUgYXMgcGFydCBvZiB0aGUgZXh0ZW5zaW9u IGRvY3VtZW50Ljxicj4NCkl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gd2FpdCBmb3IgdGhhdCBkaXNj dXNzaW9uIHRvIGNvbXBsZXRlIHRoZSBjbGFyaWZpY2F0aW9ucyBkb2N1bWVudCB0aGF0IHRhbGtz IGFib3V0IHdoYXQgdGhlIHNwZWNzIHNheSBfbm93Xy48YnI+DQo8YnI+DQpNeSBkaXNjb21mb3J0 IHdpdGggdGhlIGN1cnJlbnQgdGV4dCBpcyB0aGF0IHdlJ3ZlIG1hZGUgaXQgY29tcGxleCB0byBt YWtlIGl0IHNvIHRoYXQgd2UgZG9uJ3QgaGF2ZSB0byB1cGRhdGUgdGhlIGRvY3VtZW50IG9uY2Ug dGhlIHByb3Bvc2VkIGV4dGVuc2lvbnMgZXhpc3QuPGJyPg0KVGhlcmUgYXJlIE5PIGN1cnJlbnRs eSBzdGFuZGFyZGl6ZWQgY2FzZXMgd2hlcmUgdGhlIGV4ZW1wdGlvbiBpbiB0aGUgY3VycmVudCB0 ZXh0IHdvdWxkIGJlIGludm9rZWQsIGFuZCBJIGRvbid0IHRoaW5rIHBlb3BsZSBhcmUgdHJ5aW5n IHRvIGFyZ3VlIHRoZXJlIGFyZSAtIEknbSBoZWFyaW5nIHRoYXQgdG8gZ2V0IHRoZXJlLCB0aGV5 IGV4cGVjdCB0byBpbnZva2UgdGhlIHlldC10by1iZS1kZWZpbmVkIGV4dGVuc2lvbi48YnI+DQo8 YnI+DQpTbywgbGV0cyBnbyBiYWNrIHRvIHRoZSBzbGlnaHRseSBsb25nZXIgc2VudGVuY2UgdGhh dCBsZWQgdG8gdGhpczo8YnI+DQo8YnI+DQpBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBzdWJzY3Jp cHRpb24tY3JlYXRpbmcgUkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlPGJyPg0KYSBHUlVV IGFzIHRoZSBDb250YWN0IGluIGFsbCBJTlZJVEUgcmVxdWVzdHMgdG8gZW5zdXJlIG91dC1vZi1k aWFsb2cgUkVGRVIgcmVxdWVzdHM8YnI+DQpyZWxhdGVkIHRvIGFueSBkaWFsb2cgY3JlYXRlZCBi eSB0aGUgSU5WSVRFIGFycml2ZSBhdCB0aGlzIFVBLjxicj4NCjxicj4NCkluIGFuIGF0dGVtcHQg dG8gYmUgZnV0dXJlLXByb29mLCB0aGF0J3MgaW50cm9kdWNpbmcgdGhlIHBvdGVudGlhbCBmb3Ig Y29uZnVzaW9uIGFib3V0IHdoYXQgdGhlIGN1cnJlbnQgc3RhbmRhcmRzIGRlZmluZS48YnI+DQpM ZXQncyByZW1vdmUgdGhhdCBjb25mdXNpb24uPGJyPg0KSGVyZSdzIGEgcHJvcG9zZWQgcmVwbGFj ZW1lbnQsIHRha2luZyBBZGFtJ3Mgc2VudGVuY2Ugc2ltcGxpZmljYXRpb24gaW50byBhY2NvdW50 Ojxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBSRUZFUiBy ZXF1ZXN0IG5lZWRzIHRvIGluY2x1ZGU8YnI+DQombmJzcDsmbmJzcDsgYSBHUlVVIGluIHRoZSBD b250YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiZuYnNwOyBUaGlzPGJy Pg0KJm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3Rz IGNvcnJlc3BvbmRpbmcgdG8gYW55PGJyPg0KJm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUg ZGlhbG9ncyBhcnJpdmUgYXQgdGhpcyBVQS4gRnV0dXJlIGV4dGVuc2lvbnMgPGJyPg0KJm5ic3A7 Jm5ic3A7IFtkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdHN1Yl0gbWlnaHQgcmVs YXggdGhpcyByZXF1aXJlbWVudCA8YnI+DQombmJzcDsmbmJzcDsgYnkgZGVmaW5pbmcgYSBSRUZF UiByZXF1ZXN0IHRoYXQgY2Fubm90IGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24uPGJy Pg0KPGJyPg0KPGJyPg0KVW5sZXNzIEkgaGVhciBvYmplY3Rpb24gc29vbiwgSSdsbCByZXYgdGhl IGRyYWZ0IHdpdGggdGhhdCBjb250ZW50Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBz byB0aGVuIEkgdGhpbmsgd2Ugd2lsbCBuZWVkIGEgbmV3IHNpcCBvcHRpb25zIHRhZyAoZS5nIFJF RkVSLU5PU1VCKSB0byBiZSB1c2VkIGluIHBsYWNlIG9mIHRoZSBSRUZFUiBvcHRpb25zIHRhZyBz byB0aGF0IGEgUkZDIDM1MTUgY29tcGxpYW50IFVBIHRoYXQgZXhwZWN0cw0KIGEgTk9USUZZIHRv IGJlIHNlbnQgdXBvbiByZWNlaXB0IG9mIGEgUkVGRVIgYW5kIHRoYXQgaW5jbHVkZXMgYW4gQWNj ZXB0LUNvbnRhY3QgcmVxdWVzdCB0byByZWFjaCBhIFVBIHRoYXQgc3VwcG9ydHMgUkVGRVIgZG9l c27igJl0IGVuZCB1cCBhdCBhIFVBUyB0aGF0IGRvZXNu4oCZdCAmbmJzcDtzdXBwb3J0IGNvbXBs aWFudCBSRkMgMzUxNSBiZWhhdmlvciBhbmQgZW5kcyB1cCBoYXZpbmcgaXRzIFJFRkVSIHJlcXVl c3RzIHJlamVjdGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgb3duIHZpZXcgaXMgdGhhdCB3ZSBzaG91bGQga2Vl cCB3aXRoIHRoZSBwcmluY2lwbGUgb2YgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBhbmQgdGhhdCBl dmVuIHdoZW4gdGhlc2Ugbm8gYXV0b21hdGljIHN1YnNjcmlwdGlvbiBleHRlbnNpb25zIGFyZSBz dXBwb3J0ZWQNCiB0aGF0IGZ1bGwgc3VwcG9ydCBmb3IgUkZDIDM1MTUgYmVoYXZpb3IgaXMgY29u dGludWVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QW5kcmV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBz aXBjb3JlIFs8YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWRhbSBS b2FjaDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDExOjE5IEFNPGJy Pg0KPGI+VG86PC9iPiBJdm8gU2VkbGFjZWs7IFJvYmVydCBTcGFya3M7IDxhIGhyZWY9Im1haWx0 bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNy8yOS8xNCAwOTo1 MiwgSXZvIFNlZGxhY2VrIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5i c3A7PC9zcGFuPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPlRodXMsIHRoZSB0ZXh0IHNob3VsZCBz dGF0ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJbiBnZW5lcmFsLCBVQXMgdGhhdCBzdXBwb3J0 IHJlY2VpdmluZyAmZ3Q7Jmd0O2FuZCBhY2NlcHRpbmcgYW4gb3V0LW9mLWRpYWxvZyZsdDsmbHQ7 IFJFRkVSIHJlcXVlc3QgJmd0OyZndDtjb3JyZXNwb25kaW5nIHRvIGEgZGlhbG9nIGVzdGFibGlz aGVkIGJ5IGFuIElOVklURSByZXF1ZXN0Jmx0OyZsdDsgbmVlZCB0byBpbmNsdWRlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBhIEdSVVUgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mICZndDsmZ3Q7dGhlJmx0OyZs dDsgSU5WSVRFIHJlcXVlc3QuJm5ic3A7IFRoaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQt b2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBy ZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJlIHJvdXRlZCB0byB0aGUgY29ycmVjdCB1c2VyIGFn ZW50LiZuYnNwOyBVQXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoYXQgd2lsbCBuZXZlciBjcmVhdGUgYSBpbXBsaWNp dCBzdWJzY3JpcHRpb24gaW4gcmVzcG9uc2UgdG8gYSBSRUZFUjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgKHRoYXQgaXMs IHRob3NlIHRoYXQgd2lsbCByZWplY3QgYW55IFJFRkVSIHRoYXQgbWlnaHQgcmVzdWx0IGluIGFu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBpbXBsaWNpdCBzdWJzY3JpcHRpb24pIGFyZSBleGVtcHRlZCBmcm9tIHRoaXMg YmVoYXZpb3IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpJIGhlbHBlZCB3 aXRoIHRoZSBwaHJhc2luZyBoZXJlLCBhbmQgb25lIG9mIHRoZSBnb2FscyBoZXJlIHdhcyB0byBt YWtlIHRoZSBmaXJzdCBzZW50ZW5jZSBjb3ZlciB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgY2Fz ZXMgKGhlbmNlICZxdW90O2luIGdlbmVyYWwmcXVvdDspLCB3aXRoIHRoZSBleGNlcHRpb25hbCBj YXNlcyBkZXNjcmliZWQgbGF0ZXIuIFRoZSBwcm9ibGVtIHdhcyB0aGF0IHRoZSBvdmVyYWxsIGNv bmNlcHQgd2FzIGdldHRpbmcgbG9zdCBpbiBhIG1hemUNCiBvZiB0d2lzdHkgY2xhdXNlczogdGhl IGNsYXJpZmljYXRpb24gaGFkIGJlY29tZSB3b3JzZSB0aGFuIHRoZSBzb3VyY2UgdGV4dDsgaXQg d2FzIGFjdHVhbGx5IG1vcmUgY29uZnVzaW5nLjxicj4NCjxicj4NCllvdXIgcHJvcG9zYWwgcmV0 dXJucyBpdCB0byB0aGlzIHZlcnkgY29uZnVzaW5nIHN0YXRlLCBhbmQgaXMgd2F5LCB3YXkgb3V0 IGludG8gdGhlIHJlYWxtIG9mIGV4Y2VwdGlvbmFsIGNhc2VzLjxicj4NCjxicj4NClNvIEknbGwg Y291bnRlcnByb3Bvc2U6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBJbiBnZW5l cmFsLCBVQXMgdGhhdCBzdXBwb3J0IHJlY2VpdmluZyBSRUZFUiByZXF1ZXN0cyBuZWVkIHRvIGlu Y2x1ZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYSBHUlVVIGluIHRoZSBD b250YWN0IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiZuYnNwOyBUaGlzPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlh bG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcmUgcm91dGVkIHRv IHRoZSBjb3JyZWN0IHVzZXIgYWdlbnQuJm5ic3A7IFVBczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyB0aGF0IHdpbGwgbm90IGNyZWF0ZSBhIGltcGxpY2l0IHN1YnNjcmlwdGlv biBpbiByZXNwb25zZSB0byBhIFJFRkVSPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IGZvciB0aGUgcmVzdWx0aW5nIGRpYWxvZyhzKSAtLSB0aGF0IGlzLCB0aG9zZSB0aGF0IHdp bGwgcmVqZWN0IGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY29ycmVzcG9u ZGluZyBSRUZFUiB0aGF0IG1pZ2h0IHJlc3VsdCBpbiBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24g LS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXJlIGV4ZW1wdGVkIGZyb20g dGhpcyBiZWhhdmlvci48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KL2E8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BBF5DDFE515C3946BC18D733B20DAD233991B539XMB122CNCrimnet_-- From nobody Tue Aug 12 05:53:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D41B1A08A2 for ; Tue, 12 Aug 2014 05:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTICaSiKt83Z for ; Tue, 12 Aug 2014 05:52:59 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4831A089B for ; Tue, 12 Aug 2014 05:52:59 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Aug 2014 08:52:58 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 08:52:58 -0400 From: Andrew Allen To: Ivo Sedlacek , Robert Sparks , Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPqrHlmnmUsyWPWkiMyO8iEueSdZu3Zw8AgAAHa4CAAU4pgP//+hIAgAEMFKCAAAnd8IABhX7wgAps3oCABytxgIAAGBhg Date: Tue, 12 Aug 2014 12:52:57 +0000 Message-ID: References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233991B55AXMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/tFcR0Us2ogiwDCBxXm-VxXo9OM8 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 12:53:08 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233991B55AXMB122CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCByZWFzb24gd291bGQgYSBVQUMgaGF2ZSBzdWNoIGEgcmVzdHJpY3Rpb24gZm9yIHNvbWUg YW5kIG5vdCBvdGhlcnM/DQoNCldoeSB3b3VsZCBpdCBiZSBhZHZhbnRhZ2VvdXMgdG8gIGRlY3Jl YXNlIGludGVyb3BlcmFiaWxpdHkgaW4gc3VjaCBzaXR1YXRpb25zPw0KDQpXaGV0aGVyIHRoZSBS RUZFUiByZXF1ZXN0IGlzIHNlbnQgd2l0aGluIG9yIG91dHNpZGUgdGhlIGRpYWxvZyBzaG91bGQg YmUgYSBVQUMgZGVjaXNpb24gKGlmIGl0cyBSRkMgMzUxNSBvbmx5IGNvbXBsaWFudCkgYW5kIG91 dHNpZGUgdGhlIGRpYWxvZyBpZiBpcyBhbHNvIFJGQyA2NjY1IGNvbXBsaWFudC4NCg0KQW5kcmV3 DQoNCkZyb206IEl2byBTZWRsYWNlayBbbWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb21d DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTIsIDIwMTQgMzoyNCBBTQ0KVG86IFJvYmVydCBTcGFy a3M7IEFuZHJldyBBbGxlbjsgQWRhbSBSb2FjaDsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDog UkU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3Bh cmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0DQoNCkhlbGxvLA0KDQpUaGVy ZSBzdGlsbCBzZWVtcyB0byBiZSBtaXN1bmRlcnN0YW5kaW5nLiBMZXQgbWUgc3RhdGUgbXkgaXNz dWUgaW4gYSBkaWZmZXJlbnQgYW5kIG1vcmUgZ2VuZXJhbCB3YXk6DQoNCklmOg0KLSBhIFVFIHN1 cHBvcnRzIHJlY2VpdmluZyBhbmQgYWNjZXB0aW5nIG9mIG91dC1vZi1kaWFsb2cgUkVGRVIgcmVx dWVzdCByZWxhdGVkIHRvIGRpYWxvZ3MgY3JlYXRlZCBieSBzb21lIChidXQgbm90IGFsbCkgSU5W SVRFIHJlcXVlc3RzOyBhbmQNCi0gZm9yIGEgcGFydGljdWxhciBJTlZJVEUgcmVxdWVzdCwgdGhl IFVBIHJlamVjdHMgYW55IG91dC1vZi1kaWFsb2cgUkVGRVJzIHJlbGF0ZWQgdG8gZGlhbG9ncyBj cmVhdGVkIGJ5IHRoZSBwYXJ0aWN1bGFyIElOVklURSByZXF1ZXN0Ow0Kc2hvdWxkIHRoZSBVRSBi ZSBzdGlsbCBtYW5kYXRlZCB0byBwdXQgR1JVVSBpbiB0aGUgQ29udGFjdCBvZiB0aGUgcGFydGlj dWxhciBJTlZJVEUgcmVxdWVzdD8gSWYgc28sIHdoYXQgd2lsbCB0aGUgR1JVVSBiZSB1c2VkIGZv cj8NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgcXVlc3Rpb24gYWJvdmUgZm9jdXNlcyBzb2xlbHkg b24gb3V0LW9mLWRpYWxvZyBSRUZFUnMuDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsN Cg0KDQpUaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5k IHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0IHd3dy5l cmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcjxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFp bF9kaXNjbGFpbWVyPg0KRnJvbTogUm9iZXJ0IFNwYXJrcyBbbWFpbHRvOnJqc3BhcmtzQG5vc3Ry dW0uY29tXQ0KU2VudDogNy4gc3JwbmEgMjAxNCAxOTo1NQ0KVG86IEl2byBTZWRsYWNlazsgQW5k cmV3IEFsbGVuOyBBZGFtIFJvYWNoOyBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0 DQoNCkkndmUgc3BlbnQgcXVpdGUgc29tZSB0aW1lIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBw dXNoIGZvciB0aGUgcHJvcG9zYWwgYmVsb3csIGFuZCBJIHJlYWxseSB0aGluayB0aGVyZSdzIGNv bmZ1c2lvbiwgc28gSSdtIGdvaW5nIHRvIHRyeSB0byBzdGVwIHVwIGEgbGV2ZWwgYW5kIHNlZSBp ZiB3ZSBjYW4gbWFrZSBwcm9ncmVzcyB0aGVyZS4NCg0KQSBVQSBzdWNoIGFzIHlvdXIgcHJvcG9z ZWQgZXhjZXB0aW9uIGNsYXVzZSBkZXNjcmliZXMgaXMgc2ltcGx5IG5vdCBhIGNvbXBsaWFudCA2 NjY1IGltcGxlbWVudGF0aW9uIHdoaWNoIGlzIHdoYXQgdGhpcyBjbGFyaWZpY2F0aW9uIGRvY3Vt ZW50IGlzIGFib3V0Lg0KSWYgaXQgYWNjZXB0cyBpbi1kaWFsb2cgc3Vic2NyaXB0aW9uIGNyZWF0 aW5nIFJFRkVScyBpdCBpcyBmb2xsb3dpbmcgMzI2NSwgbm90IDY2NjUgLSBmdXJ0aGVyIGl0IGlz IHZpb2xhdGluZyBhIDY2NjUgcmVxdWlyZW1lbnQuDQpJZiBpdCBhY2NlcHRzIG5vIFJFRkVScyB3 aGF0c29ldmVyLCB0aGVuIGl0J3Mgbm90IGFmZmVjdGVkIGJ5IHRoaXMgZG9jdW1lbnQuDQoNCklm IHRoZSBwb2ludCBvZiB0aGUgd29yZHNtaXRoaW5nIGlzIHRvIG1ha2UgbGVnYWN5IGltcGxlbWVu dGF0aW9ucyBjb21wbGlhbnQgd2l0aCA2NjY1LCB0aGVyZSdzIG5vIHdheSB0byBzdWNjZWVkIC0g dGhleSBzaW1wbHkgYXJlbid0Lg0KDQpJZiB0aGF0J3Mgbm90IHRoZSBwb2ludCBvZiB0aGUgd29y ZHNtaXRoaW5nLCB3aGF0IGlzPw0KDQpBdCB0aGUgbW9tZW50LCBJIHRoaW5rIHdoYXQgSSBzZW50 IGJlbG93IGlzIHN0aWxsIHRoZSByaWdodCBwYXRoIGZvcndhcmQuDQoNClJqUw0KDQoNCk9uIDgv MS8xNCwgMTo0NCBBTSwgSXZvIFNlZGxhY2VrIHdyb3RlOg0KQW55IGNvbW1lbnRzIG9uIHRoZSBw cm9wb3NhbCBiZWxvdz8NCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQoNCiAgIElm IGEgUkVGRVIgcmVxdWVzdCBpcyBhY2NlcHRlZCAodGhhdCBpcywgYSAyeHggY2xhc3MgcmVzcG9u c2UgaXMNCiAgIHJldHVybmVkKSwgdGhlIHJlY2lwaWVudCBNVVNUIGNyZWF0ZSBhIHN1YnNjcmlw dGlvbiBhbmQgc2VuZA0KICAgbm90aWZpY2F0aW9ucyBvZiB0aGUgc3RhdHVzIG9mIHRoZSByZWZl ciBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbg0KICAgMi40LjQuRnJvbTogc2lwY29yZSBbbWFpbHRv OnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEl2byBTZWRsYWNlaw0KU2Vu dDogMzEuIMSNZXJ2ZW5jZSAyMDE0IDk6MjYNClRvOiBSb2JlcnQgU3BhcmtzOyBBbmRyZXcgQWxs ZW47IEFkYW0gUm9hY2g7IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQNCg0KSGVs bG8sDQoNCkFjY29yZGluZyB0byB0aGUgZHJhZnQsIHRoZSBwdXJwb3NlIG9mIEdSVVUgaW4gQ29u dGFjdCBvZiBJTlZJVEUgcmVxdWVzdCB0byAiDQogICBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxv ZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueQ0KICAgcmVzdWx0aW5nIElOVklU RSBkaWFsb2dzIGFycml2ZSBhdCB0aGlzIFVBLiINCg0KSWYgYSBVQSByZWplY3RzIGFueSBvdXQt b2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55IGRpYWxvZ3MgcmVs YXRlZCB0byBhbiBJTlZJVEUgcmVxdWVzdCwgdGhlbiBzZXR0aW5nIHVwIEdSVVUgaW4gQ29udGFj dCBvZiBJTlZJVEUgZG9lcyBub3QgcHJvdmlkZSBhbnkgcHVycG9zZS4NCg0KVGhpcyBpcyB0cnVl IF9fcmVnYXJkbGVzc19fIHdoZXRoZXIgdGhlIFVBIHN1cHBvcnRzIGFuZCB1c2UgdGhlIGRyYWZ0 LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0c3ViLg0KU2VlIGF0dGFjaGVkIG1haWwgZ2l2 aW5nIGFuIGV4YW1wbGUgb2YgVUEgaGF2aW5nIHR3byB0eXBlcyBvZiBzZXNzaW9ucywgVHlwZV9B IHRyYW5zZmVycmFibGUgYnkgUkVGRVIsIGFuZCBUeXBlX0Igbm90IHRyYW5zZmVycmFibGUgYnkg UkVGRVIuDQpHaXZlbiB0aGF0IGRpZmZlcmVudCBzdGFuZGFyZGl6YXRpb24gb3JnYW5pemF0aW9u IGhhcyBkZWZpbmVkIHNvIG1hbnkgZW5hYmxlcnMgd2hpY2ggY2FuIHJ1biBvbiBhIHNpbmdsZSBV QSwgSSBmaW5kIGl0IHdlaXJkIHRoYXQgb25lIGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgYWJvdmUg Y2Fubm90IG9jY3VyLg0KDQpUaHVzLCBJIGhlc2l0YXRlIHRvIG1hbmRhdGUgYW4gdW5uZWNlc3Nh cnkgcmVxdWlyZW1lbnQgaW5mbHVlbmNpbmcgcG9zc2libGUgZXhpc3RpbmcgVUEgaW1wbGVtZW50 YXRpb25zIGFuZCBJIHByZWZlciB0byBiZSBleHBsaWNpdCBvbiB0aGUgZXhjZXB0aW9uIGZvciB1 c2FnZSBvZiBHUlVVIGluIENvbnRhY3Qgb2YgSU5WSVRFIHJlcXVlc3Q6DQoNCg0KDQoNCiAgIEEg VUEgdGhhdCB3aWxsIGFjY2VwdCBhIFJFRkVSIHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZQ0KDQog ICBhIEdSVVUgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mIGFsbCBJTlZJVEUgcmVxdWVz dHMuICBUaGlzDQoNCiAgIGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3Rz IGNvcnJlc3BvbmRpbmcgdG8gYW55DQoNCiAgIHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJp dmUgYXQgdGhpcyBVQS4gPj4+VUFzIHRoYXQgd2lsbCBub3QgYWNjZXB0IGFueSBvdXQtb2YtZGlh bG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gZGlhbG9nKHMpIGNyZWF0ZWQgYnkg YW4gSU5WSVRFIHJlcXVlc3QNCg0KICAgYXJlIGV4ZW1wdGVkIGZyb20gaW5jbHVkaW5nIGEgR1JV VSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgdGhlIElOVklURSByZXF1ZXN0Ljw8PA0K DQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoNCg0KRnJvbTogUm9iZXJ0IFNwYXJrcyBb bWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29tXQ0KU2VudDogMzAuIMSNZXJ2ZW5jZSAyMDE0IDE4 OjU0DQpUbzogQW5kcmV3IEFsbGVuOyBBZGFtIFJvYWNoOyBJdm8gU2VkbGFjZWs7IHNpcGNvcmVA aWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVd IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFya3Mtc2lwY29yZS1y ZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQNCg0KDQpPbiA3LzMwLzE0LCAxMDozMyBBTSwgQW5k cmV3IEFsbGVuIHdyb3RlOg0KSSBoYXZlIGEgZ2VuZXJhbCBjb25jZXJuIHdpdGggdGhlIGRpcmVj dGlvbiB0aGlzIGlzIG5vdyBnb2luZy4NCkkgZG9uJ3QgdGhpbmsgeW91IGhhdmUgdGhlIGJhY2t3 YXJkcy1jb21wYXRpYmlsaXR5IGNvbmNlcm4gcXVpdGUgcmlnaHQsIGJ1dCBJIGFncmVlIHRoYXQg dGhlIGN1cnJlbnQgd29yZGluZyBpc24ndCB0aGVyZSB5ZXQuDQoNCkFyZSB3ZSBub3cgc2F5aW5n IGhlcmUgdGhhdCBpdOKAmXMgT0sgZm9yIGEgVUEgdGhhdCBzdXBwb3J0cyByZWNlaXZpbmcgUkVG RVIgdG8gYXJiaXRyYXJpbHkgcmVqZWN0IGFueSBSRUZFUiB0aGF0IHdvdWxkIGNyZWF0ZSBhIHN1 YnNjcmlwdGlvbiAoaS5lIGJlIGluY29tcGF0aWJsZSB3aXRoIFJGQyAzNTE1IFVBQ3MgYnkgYmFz aWNhbGx5IG5vdCBzdXBwb3J0aW5nIFJGQyAzNTE1IFVBUyBjb21wbGlhbnQgYmVoYXZpb3IpPw0K Tm8sIF90aGlzXyBkb2N1bWVudCBpcyBub3QgZGVmaW5pbmcgbmV3IGJlaGF2aW9yLiBJdCdzIG9u bHkgY2xhcmlmeWluZyB3aGF0J3MgYWxyZWFkeSBkZWZpbmVkLg0KDQoNCkFjY29yZGluZyB0byBS RkMgMzUxNQ0KDQoyLjQuNCBVc2luZyBTSVAgRXZlbnRzIHRvIFJlcG9ydCB0aGUgUmVzdWx0cyBv ZiB0aGUgUmVmZXJlbmNlDQoNCiAgICAgICAgICAgICAgICBUaGUgTk9USUZZIG1lY2hhbmlzbSBk ZWZpbmVkIGluIFsyXSBNVVNUIGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBhZ2VudCBzZW5kaW5nIHRo ZSBSRUZFUiBvZiB0aGUgc3RhdHVzIG9mIHRoZSByZWZlcmVuY2UuDQoNClRoZXJlZm9yZSB0aGUg YWJpbGl0eSB0byBjcmVhdGUgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uIHdoZW4gYWNjZXB0aW5n DQpGV0lXLCBBY2NlcHRpbmcgaXMgdGhlIGtleSB3b3JkIGhlcmUuDQphIFJFRkVSIGlzIG1hbmRh dG9yeSBiZWhhdmlvciBpbiBSRkMgMzUxNSBhbmQgaXMgZXhwZWN0ZWQgdG8gYmUgc3VwcG9ydGVk IGJ5IGFsbCBSRkMgMzUxNSBVQUNzDQoNCkkgdGhpbmsgYmVmb3JlIGFncmVlaW5nIGFueSB3b3Jk aW5nIGhlcmUgd2Ugc2hvdWxkIGhhdmUgYSBnZW5lcmFsIGRpc2N1c3Npb24gb24gdGhlIHByaW5j aXBsZSBvZiB3aGV0aGVyIHRoZXNlIGV4dGVuc2lvbnMgdGhhdCBhbGxvdyBVQUNzIHRvIHJlcXVl c3QgdGhhdCBubyBpbXBsaWNpdCBzdWJzY3JpcHRpb24gY2FuIGJlIGVmZmVjdGl2ZWx5IHJlcXVp cmVkIGJ5IFJFRkVSIFVBUyB0byBiZSBzdXBwb3J0ZWQgYXQgdGhlIFVBQy4NClRoaXMsIGFuZCB3 aGF0IHlvdSBoYXZlIGJlbG93LCBpcyBhIGRpc2N1c3Npb24gd2UgZGVmaW5pdGVseSBuZWVkIHRv IGhhdmUgYXMgcGFydCBvZiB0aGUgZXh0ZW5zaW9uIGRvY3VtZW50Lg0KSXQgaXMgbm90IG5lY2Vz c2FyeSB0byB3YWl0IGZvciB0aGF0IGRpc2N1c3Npb24gdG8gY29tcGxldGUgdGhlIGNsYXJpZmlj YXRpb25zIGRvY3VtZW50IHRoYXQgdGFsa3MgYWJvdXQgd2hhdCB0aGUgc3BlY3Mgc2F5IF9ub3df Lg0KDQpNeSBkaXNjb21mb3J0IHdpdGggdGhlIGN1cnJlbnQgdGV4dCBpcyB0aGF0IHdlJ3ZlIG1h ZGUgaXQgY29tcGxleCB0byBtYWtlIGl0IHNvIHRoYXQgd2UgZG9uJ3QgaGF2ZSB0byB1cGRhdGUg dGhlIGRvY3VtZW50IG9uY2UgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbnMgZXhpc3QuDQpUaGVyZSBh cmUgTk8gY3VycmVudGx5IHN0YW5kYXJkaXplZCBjYXNlcyB3aGVyZSB0aGUgZXhlbXB0aW9uIGlu IHRoZSBjdXJyZW50IHRleHQgd291bGQgYmUgaW52b2tlZCwgYW5kIEkgZG9uJ3QgdGhpbmsgcGVv cGxlIGFyZSB0cnlpbmcgdG8gYXJndWUgdGhlcmUgYXJlIC0gSSdtIGhlYXJpbmcgdGhhdCB0byBn ZXQgdGhlcmUsIHRoZXkgZXhwZWN0IHRvIGludm9rZSB0aGUgeWV0LXRvLWJlLWRlZmluZWQgZXh0 ZW5zaW9uLg0KDQpTbywgbGV0cyBnbyBiYWNrIHRvIHRoZSBzbGlnaHRseSBsb25nZXIgc2VudGVu Y2UgdGhhdCBsZWQgdG8gdGhpczoNCg0KQSBVQSB0aGF0IHdpbGwgYWNjZXB0IGEgc3Vic2NyaXB0 aW9uLWNyZWF0aW5nIFJFRkVSIHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZQ0KYSBHUlVVIGFzIHRo ZSBDb250YWN0IGluIGFsbCBJTlZJVEUgcmVxdWVzdHMgdG8gZW5zdXJlIG91dC1vZi1kaWFsb2cg UkVGRVIgcmVxdWVzdHMNCnJlbGF0ZWQgdG8gYW55IGRpYWxvZyBjcmVhdGVkIGJ5IHRoZSBJTlZJ VEUgYXJyaXZlIGF0IHRoaXMgVUEuDQoNCkluIGFuIGF0dGVtcHQgdG8gYmUgZnV0dXJlLXByb29m LCB0aGF0J3MgaW50cm9kdWNpbmcgdGhlIHBvdGVudGlhbCBmb3IgY29uZnVzaW9uIGFib3V0IHdo YXQgdGhlIGN1cnJlbnQgc3RhbmRhcmRzIGRlZmluZS4NCkxldCdzIHJlbW92ZSB0aGF0IGNvbmZ1 c2lvbi4NCkhlcmUncyBhIHByb3Bvc2VkIHJlcGxhY2VtZW50LCB0YWtpbmcgQWRhbSdzIHNlbnRl bmNlIHNpbXBsaWZpY2F0aW9uIGludG8gYWNjb3VudDoNCg0KICAgQSBVQSB0aGF0IHdpbGwgYWNj ZXB0IGEgUkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlDQogICBhIEdSVVUgaW4gdGhlIENv bnRhY3QgaGVhZGVyIGZpZWxkIG9mIGFsbCBJTlZJVEUgcmVxdWVzdHMuICBUaGlzDQogICBlbnN1 cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFu eQ0KICAgcmVzdWx0aW5nIElOVklURSBkaWFsb2dzIGFycml2ZSBhdCB0aGlzIFVBLiBGdXR1cmUg ZXh0ZW5zaW9ucw0KICAgW2RyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0c3ViXSBt aWdodCByZWxheCB0aGlzIHJlcXVpcmVtZW50DQogICBieSBkZWZpbmluZyBhIFJFRkVSIHJlcXVl c3QgdGhhdCBjYW5ub3QgY3JlYXRlIGFuIGltcGxpY2l0IHN1YnNjcmlwdGlvbi4NCg0KDQpVbmxl c3MgSSBoZWFyIG9iamVjdGlvbiBzb29uLCBJJ2xsIHJldiB0aGUgZHJhZnQgd2l0aCB0aGF0IGNv bnRlbnQuDQoNCg0KSWYgc28gdGhlbiBJIHRoaW5rIHdlIHdpbGwgbmVlZCBhIG5ldyBzaXAgb3B0 aW9ucyB0YWcgKGUuZyBSRUZFUi1OT1NVQikgdG8gYmUgdXNlZCBpbiBwbGFjZSBvZiB0aGUgUkVG RVIgb3B0aW9ucyB0YWcgc28gdGhhdCBhIFJGQyAzNTE1IGNvbXBsaWFudCBVQSB0aGF0IGV4cGVj dHMgYSBOT1RJRlkgdG8gYmUgc2VudCB1cG9uIHJlY2VpcHQgb2YgYSBSRUZFUiBhbmQgdGhhdCBp bmNsdWRlcyBhbiBBY2NlcHQtQ29udGFjdCByZXF1ZXN0IHRvIHJlYWNoIGEgVUEgdGhhdCBzdXBw b3J0cyBSRUZFUiBkb2VzbuKAmXQgZW5kIHVwIGF0IGEgVUFTIHRoYXQgZG9lc27igJl0ICBzdXBw b3J0IGNvbXBsaWFudCBSRkMgMzUxNSBiZWhhdmlvciBhbmQgZW5kcyB1cCBoYXZpbmcgaXRzIFJF RkVSIHJlcXVlc3RzIHJlamVjdGVkLg0KDQpNeSBvd24gdmlldyBpcyB0aGF0IHdlIHNob3VsZCBr ZWVwIHdpdGggdGhlIHByaW5jaXBsZSBvZiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGFuZCB0aGF0 IGV2ZW4gd2hlbiB0aGVzZSBubyBhdXRvbWF0aWMgc3Vic2NyaXB0aW9uIGV4dGVuc2lvbnMgYXJl IHN1cHBvcnRlZCB0aGF0IGZ1bGwgc3VwcG9ydCBmb3IgUkZDIDM1MTUgYmVoYXZpb3IgaXMgY29u dGludWVkLg0KDQpBbmRyZXcNCg0KDQoNCg0KDQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRhbSBSb2FjaA0KU2VudDogVHVlc2Rh eSwgSnVseSAyOSwgMjAxNCAxMToxOSBBTQ0KVG86IEl2byBTZWRsYWNlazsgUm9iZXJ0IFNwYXJr czsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJr cy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dA0KDQpPbiA3LzI5LzE0IDA5OjUy LCBJdm8gU2VkbGFjZWsgd3JvdGU6DQoNClRodXMsIHRoZSB0ZXh0IHNob3VsZCBzdGF0ZToNCg0K DQogICBJbiBnZW5lcmFsLCBVQXMgdGhhdCBzdXBwb3J0IHJlY2VpdmluZyA+PmFuZCBhY2NlcHRp bmcgYW4gb3V0LW9mLWRpYWxvZzw8IFJFRkVSIHJlcXVlc3QgPj5jb3JyZXNwb25kaW5nIHRvIGEg ZGlhbG9nIGVzdGFibGlzaGVkIGJ5IGFuIElOVklURSByZXF1ZXN0PDwgbmVlZCB0byBpbmNsdWRl DQogICBhIEdSVVUgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mID4+dGhlPDwgSU5WSVRF IHJlcXVlc3QuICBUaGlzDQogICBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1 ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueQ0KICAgcmVzdWx0aW5nIElOVklURSBkaWFsb2dzIGFy ZSByb3V0ZWQgdG8gdGhlIGNvcnJlY3QgdXNlciBhZ2VudC4gIFVBcw0KICAgdGhhdCB3aWxsIG5l dmVyIGNyZWF0ZSBhIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBpbiByZXNwb25zZSB0byBhIFJFRkVS DQogICAodGhhdCBpcywgdGhvc2UgdGhhdCB3aWxsIHJlamVjdCBhbnkgUkVGRVIgdGhhdCBtaWdo dCByZXN1bHQgaW4gYW4NCiAgIGltcGxpY2l0IHN1YnNjcmlwdGlvbikgYXJlIGV4ZW1wdGVkIGZy b20gdGhpcyBiZWhhdmlvci4NCg0KSSBoZWxwZWQgd2l0aCB0aGUgcGhyYXNpbmcgaGVyZSwgYW5k IG9uZSBvZiB0aGUgZ29hbHMgaGVyZSB3YXMgdG8gbWFrZSB0aGUgZmlyc3Qgc2VudGVuY2UgY292 ZXIgdGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlIGNhc2VzIChoZW5jZSAiaW4gZ2VuZXJhbCIpLCB3 aXRoIHRoZSBleGNlcHRpb25hbCBjYXNlcyBkZXNjcmliZWQgbGF0ZXIuIFRoZSBwcm9ibGVtIHdh cyB0aGF0IHRoZSBvdmVyYWxsIGNvbmNlcHQgd2FzIGdldHRpbmcgbG9zdCBpbiBhIG1hemUgb2Yg dHdpc3R5IGNsYXVzZXM6IHRoZSBjbGFyaWZpY2F0aW9uIGhhZCBiZWNvbWUgd29yc2UgdGhhbiB0 aGUgc291cmNlIHRleHQ7IGl0IHdhcyBhY3R1YWxseSBtb3JlIGNvbmZ1c2luZy4NCg0KWW91ciBw cm9wb3NhbCByZXR1cm5zIGl0IHRvIHRoaXMgdmVyeSBjb25mdXNpbmcgc3RhdGUsIGFuZCBpcyB3 YXksIHdheSBvdXQgaW50byB0aGUgcmVhbG0gb2YgZXhjZXB0aW9uYWwgY2FzZXMuDQoNClNvIEkn bGwgY291bnRlcnByb3Bvc2U6DQoNCiAgIEluIGdlbmVyYWwsIFVBcyB0aGF0IHN1cHBvcnQgcmVj ZWl2aW5nIFJFRkVSIHJlcXVlc3RzIG5lZWQgdG8gaW5jbHVkZQ0KDQogICBhIEdSVVUgaW4gdGhl IENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mIGFsbCBJTlZJVEUgcmVxdWVzdHMuICBUaGlzDQoNCiAg IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcg dG8gYW55DQoNCiAgIHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcmUgcm91dGVkIHRvIHRoZSBj b3JyZWN0IHVzZXIgYWdlbnQuICBVQXMNCg0KICAgdGhhdCB3aWxsIG5vdCBjcmVhdGUgYSBpbXBs aWNpdCBzdWJzY3JpcHRpb24gaW4gcmVzcG9uc2UgdG8gYSBSRUZFUg0KDQogICBmb3IgdGhlIHJl c3VsdGluZyBkaWFsb2cocykgLS0gdGhhdCBpcywgdGhvc2UgdGhhdCB3aWxsIHJlamVjdCBhDQoN CiAgIGNvcnJlc3BvbmRpbmcgUkVGRVIgdGhhdCBtaWdodCByZXN1bHQgaW4gYW4gaW1wbGljaXQg c3Vic2NyaXB0aW9uIC0tDQoNCiAgIGFyZSBleGVtcHRlZCBmcm9tIHRoaXMgYmVoYXZpb3IuDQoN Ci9hDQoNCg0KDQo= --_000_BBF5DDFE515C3946BC18D733B20DAD233991B55AXMB122CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpi bGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojQzA1MDREO30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojQzA1MDREO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiNDMDUwNEQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6I0MwNTA0RDt9 DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojQzA1MDREO30NCnNwYW4uRW1haWxT dHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0 IHJlYXNvbiB3b3VsZCBhIFVBQyBoYXZlIHN1Y2ggYSByZXN0cmljdGlvbiBmb3Igc29tZSBhbmQg bm90IG90aGVycz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2h5IHdvdWxkIGl0IGJlIGFkdmFudGFnZW91cyB0byAm bmJzcDtkZWNyZWFzZSBpbnRlcm9wZXJhYmlsaXR5IGluIHN1Y2ggc2l0dWF0aW9ucz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPldoZXRoZXIgdGhlIFJFRkVSIHJlcXVlc3QgaXMgc2VudCB3aXRoaW4gb3Igb3V0c2lkZSB0 aGUgZGlhbG9nIHNob3VsZCBiZSBhIFVBQyBkZWNpc2lvbiAoaWYgaXRzIFJGQyAzNTE1IG9ubHkg Y29tcGxpYW50KSBhbmQgb3V0c2lkZSB0aGUgZGlhbG9nIGlmIGlzIGFsc28gUkZDDQogNjY2NSBj b21wbGlhbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gSXZvIFNlZGxhY2VrIFttYWlsdG86aXZvLnNlZGxhY2Vr QGVyaWNzc29uLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTIsIDIw MTQgMzoyNCBBTTxicj4NCjxiPlRvOjwvYj4gUm9iZXJ0IFNwYXJrczsgQW5kcmV3IEFsbGVuOyBB ZGFtIFJvYWNoOyBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc2lw Y29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBj b3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0Mw NTA0RCI+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPlRoZXJlIHN0aWxsIHNlZW1zIHRvIGJlIG1pc3VuZGVyc3RhbmRp bmcuIExldCBtZSBzdGF0ZSBteSBpc3N1ZSBpbiBhIGRpZmZlcmVudCBhbmQgbW9yZSBnZW5lcmFs IHdheTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6I0MwNTA0RCI+SWY6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4tIGEgVUUgc3VwcG9y dHMgcmVjZWl2aW5nIGFuZCBhY2NlcHRpbmcgb2Ygb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0 IHJlbGF0ZWQgdG8gZGlhbG9ncyBjcmVhdGVkIGJ5DQo8dT5zb21lIChidXQgbm90IGFsbCk8L3U+ IElOVklURSByZXF1ZXN0czsgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4tIGZvcg0K PHU+YSBwYXJ0aWN1bGFyIElOVklURSByZXF1ZXN0PC91PiwgdGhlIFVBIHJlamVjdHMgYW55IG91 dC1vZi1kaWFsb2cgUkVGRVJzIHJlbGF0ZWQgdG8gZGlhbG9ncyBjcmVhdGVkIGJ5IHRoZSBwYXJ0 aWN1bGFyIElOVklURSByZXF1ZXN0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+c2hvdWxk IHRoZSBVRSBiZSBzdGlsbCBtYW5kYXRlZCB0byBwdXQgR1JVVSBpbiB0aGUgQ29udGFjdCBvZg0K PHU+dGhlIHBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3Q8L3U+PyBJZiBzbywgd2hhdCB3aWxsIHRo ZSBHUlVVIGJlIHVzZWQgZm9yPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5QbGVhc2Ugbm90ZSB0aGF0IHRoZSBxdWVzdGlvbiBh Ym92ZSBmb2N1c2VzIHNvbGVseSBvbiBvdXQtb2YtZGlhbG9nIFJFRkVScy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+S2luZCBy ZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiNDMDUwNEQiPkl2byBTZWRsYWNlazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzMzMzMzMyI+VGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5k IGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdA0K PGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciIgdGl0bGU9 Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiPg0Kd3d3LmVyaWNzc29u LmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9hPiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBSb2JlcnQgU3Bhcmtz IFs8YSBocmVmPSJtYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb20iPm1haWx0bzpyanNwYXJrc0Bu b3N0cnVtLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gNy4gc3JwbmEgMjAxNCAxOTo1NTxi cj4NCjxiPlRvOjwvYj4gSXZvIFNlZGxhY2VrOyBBbmRyZXcgQWxsZW47IEFkYW0gUm9hY2g7IDxh IGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj4NCnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBzcGVudCBxdWl0ZSBzb21lIHRpbWUgdHJ5aW5nIHRv IHVuZGVyc3RhbmQgdGhlIHB1c2ggZm9yIHRoZSBwcm9wb3NhbCBiZWxvdywgYW5kIEkgcmVhbGx5 IHRoaW5rIHRoZXJlJ3MgY29uZnVzaW9uLCBzbyBJJ20gZ29pbmcgdG8gdHJ5IHRvIHN0ZXAgdXAg YSBsZXZlbCBhbmQgc2VlIGlmIHdlIGNhbiBtYWtlIHByb2dyZXNzIHRoZXJlLjxicj4NCjxicj4N CkEgVUEgc3VjaCBhcyB5b3VyIHByb3Bvc2VkIGV4Y2VwdGlvbiBjbGF1c2UgZGVzY3JpYmVzIGlz IHNpbXBseSBub3QgYSBjb21wbGlhbnQgNjY2NSBpbXBsZW1lbnRhdGlvbiB3aGljaCBpcyB3aGF0 IHRoaXMgY2xhcmlmaWNhdGlvbiBkb2N1bWVudCBpcyBhYm91dC48YnI+DQpJZiBpdCBhY2NlcHRz IGluLWRpYWxvZyBzdWJzY3JpcHRpb24gY3JlYXRpbmcgUkVGRVJzIGl0IGlzIGZvbGxvd2luZyAz MjY1LCBub3QgNjY2NSAtIGZ1cnRoZXIgaXQgaXMgdmlvbGF0aW5nIGEgNjY2NSByZXF1aXJlbWVu dC48YnI+DQpJZiBpdCBhY2NlcHRzIG5vIFJFRkVScyB3aGF0c29ldmVyLCB0aGVuIGl0J3Mgbm90 IGFmZmVjdGVkIGJ5IHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KSWYgdGhlIHBvaW50IG9mIHRo ZSB3b3Jkc21pdGhpbmcgaXMgdG8gbWFrZSBsZWdhY3kgaW1wbGVtZW50YXRpb25zIGNvbXBsaWFu dCB3aXRoIDY2NjUsIHRoZXJlJ3Mgbm8gd2F5IHRvIHN1Y2NlZWQgLSB0aGV5IHNpbXBseSBhcmVu J3QuPGJyPg0KPGJyPg0KSWYgdGhhdCdzIG5vdCB0aGUgcG9pbnQgb2YgdGhlIHdvcmRzbWl0aGlu Zywgd2hhdCBpcz88YnI+DQo8YnI+DQpBdCB0aGUgbW9tZW50LCBJIHRoaW5rIHdoYXQgSSBzZW50 IGJlbG93IGlzIHN0aWxsIHRoZSByaWdodCBwYXRoIGZvcndhcmQuPGJyPg0KPGJyPg0KUmpTPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gOC8xLzE0LCAxOjQ0IEFNLCBJdm8gU2VkbGFjZWsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojQzA1MDREIj5BbnkgY29tbWVudHMgb24gdGhlIHByb3Bvc2FsIGJlbG93Pzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDRE Ij5LaW5kIHJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6I0MwNTA0RCI+SXZvIFNlZGxhY2VrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1 MDREIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7 Jm5ic3A7IElmIGEgUkVGRVIgcmVxdWVzdCBpcyBhY2NlcHRlZCAodGhhdCBpcywgYSAyeHggY2xh c3MgcmVzcG9uc2UgaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7Jm5ic3A7IHJl dHVybmVkKSwgdGhlIHJlY2lwaWVudCBNVVNUIGNyZWF0ZSBhIHN1YnNjcmlwdGlvbiBhbmQgc2Vu ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMzMzMzMzIj4mbmJzcDsmbmJzcDsgbm90aWZpY2F0aW9ucyBv ZiB0aGUgc3RhdHVzIG9mIHRoZSByZWZlciBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMzMzMzMzIj4mbmJzcDsmbmJzcDsgMi40LjQuPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4NCiBzaXBjb3JlIFs8YSBo cmVmPSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SXZvIFNlZGxhY2VrPGJyPg0K PGI+U2VudDo8L2I+IDMxLiDEjWVydmVuY2UgMjAxNCA5OjI2PGJyPg0KPGI+VG86PC9iPiBSb2Jl cnQgU3BhcmtzOyBBbmRyZXcgQWxsZW47IEFkYW0gUm9hY2g7IDxhIGhyZWY9Im1haWx0bzpzaXBj b3JlQGlldGYub3JnIj4NCnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNw YXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6I0MwNTA0RCI+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkFjY29yZGluZyB0byB0aGUgZHJhZnQsIHRoZSBw dXJwb3NlIG9mIEdSVVUgaW4gQ29udGFjdCBvZiBJTlZJVEUgcmVxdWVzdCB0byAmcXVvdDs8L3Nw YW4+PGJyPg0KJm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJl cXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55PGJyPg0KJm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJ TlZJVEUgZGlhbG9ncyBhcnJpdmUgYXQgdGhpcyBVQS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiNDMDUwNEQiPiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5JZiBhIFVBIHJlamVjdHMgYW55IG91dC1vZi1k aWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9uZGluZyB0byBhbnkgZGlhbG9ncyByZWxhdGVk IHRvIGFuIElOVklURSByZXF1ZXN0LCB0aGVuIHNldHRpbmcgdXAgR1JVVSBpbiBDb250YWN0IG9m IElOVklURSBkb2VzIG5vdA0KIHByb3ZpZGUgYW55IHB1cnBvc2UuIDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5UaGlzIGlzIHRy dWUgX19yZWdhcmRsZXNzX18gd2hldGhlciB0aGUgVUEgc3VwcG9ydHMgYW5kIHVzZSB0aGUNCjwv c3Bhbj5kcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdHN1Yi4gPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiNDMDUwNEQiPlNlZSBhdHRhY2hlZCBtYWlsIGdpdmluZyBhbiBleGFtcGxlIG9mIFVBIGhhdmlu ZyB0d28gdHlwZXMgb2Ygc2Vzc2lvbnMsIFR5cGVfQSB0cmFuc2ZlcnJhYmxlIGJ5IFJFRkVSLCBh bmQgVHlwZV9CIG5vdCB0cmFuc2ZlcnJhYmxlIGJ5IFJFRkVSLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 I0MwNTA0RCI+R2l2ZW4gdGhhdCBkaWZmZXJlbnQgc3RhbmRhcmRpemF0aW9uIG9yZ2FuaXphdGlv biBoYXMgZGVmaW5lZCBzbyBtYW55IGVuYWJsZXJzIHdoaWNoIGNhbiBydW4gb24gYSBzaW5nbGUg VUEsIEkgZmluZCBpdCB3ZWlyZCB0aGF0IG9uZSBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIGFib3Zl DQogY2Fubm90IG9jY3VyLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+VGh1cywgSSBoZXNpdGF0ZSB0byBtYW5kYXRlIGFuIHVu bmVjZXNzYXJ5IHJlcXVpcmVtZW50IGluZmx1ZW5jaW5nIHBvc3NpYmxlIGV4aXN0aW5nIFVBIGlt cGxlbWVudGF0aW9ucyBhbmQgSSBwcmVmZXIgdG8gYmUgZXhwbGljaXQgb24gdGhlIGV4Y2VwdGlv biBmb3IgdXNhZ2UNCiBvZiBHUlVVIGluIENvbnRhY3Qgb2YgSU5WSVRFIHJlcXVlc3Q6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBBIFVBIHRoYXQgd2ls bCBhY2NlcHQgYSBSRUZFUiByZXF1ZXN0IG5lZWRzIHRvIGluY2x1ZGU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgYSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBv ZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiZuYnNwOyBUaGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNv cnJlc3BvbmRpbmcgdG8gYW55PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHJl c3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUgYXQgdGhpcyBVQS4gPHNwYW4gc3R5bGU9ImNv bG9yOiNDMDUwNEQiPiZndDsmZ3Q7Jmd0O1VBcyB0aGF0IHdpbGwgbm90IGFjY2VwdCBhbnkgb3V0 LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGRpYWxvZyhzKSBjcmVh dGVkIGJ5IGFuIElOVklURSByZXF1ZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjojQzA1MDREIj4mbmJzcDsmbmJzcDsgYXJlIGV4ZW1wdGVkIGZyb20g aW5jbHVkaW5nIGEgR1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgdGhlIElOVklU RSByZXF1ZXN0LiZsdDsmbHQ7Jmx0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPktpbmQgcmVnYXJkczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5Jdm8gU2Vk bGFjZWs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6I0MwNTA0RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gUm9iZXJ0IFNwYXJrcyBbPGEgaHJl Zj0ibWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29tIj5tYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDMwLiDEjWVydmVuY2UgMjAxNCAxODo1NDxicj4N CjxiPlRvOjwvYj4gQW5kcmV3IEFsbGVuOyBBZGFtIFJvYWNoOyBJdm8gU2VkbGFjZWs7IDxhIGhy ZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj4NCnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDcvMzAvMTQsIDEwOjMz IEFNLCBBbmRyZXcgQWxsZW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgaGF2ZSBhIGdlbmVyYWwgY29uY2VybiB3aXRoIHRoZSBkaXJlY3Rpb24gdGhpcyBpcyBub3cg Z29pbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGRvbid0IHRoaW5rIHlvdSBo YXZlIHRoZSBiYWNrd2FyZHMtY29tcGF0aWJpbGl0eSBjb25jZXJuIHF1aXRlIHJpZ2h0LCBidXQg SSBhZ3JlZSB0aGF0IHRoZSBjdXJyZW50IHdvcmRpbmcgaXNuJ3QgdGhlcmUgeWV0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcmUg d2Ugbm93IHNheWluZyBoZXJlIHRoYXQgaXTigJlzIE9LIGZvciBhIFVBIHRoYXQgc3VwcG9ydHMg cmVjZWl2aW5nIFJFRkVSIHRvIGFyYml0cmFyaWx5IHJlamVjdCBhbnkgUkVGRVIgdGhhdCB3b3Vs ZCBjcmVhdGUgYSBzdWJzY3JpcHRpb24gKGkuZSBiZSBpbmNvbXBhdGlibGUNCiB3aXRoIFJGQyAz NTE1IFVBQ3MgYnkgYmFzaWNhbGx5IG5vdCBzdXBwb3J0aW5nIFJGQyAzNTE1IFVBUyBjb21wbGlh bnQgYmVoYXZpb3IpPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Tm8sIF90aGlzXyBkb2N1bWVudCBpcyBub3Qg ZGVmaW5pbmcgbmV3IGJlaGF2aW9yLiBJdCdzIG9ubHkgY2xhcmlmeWluZyB3aGF0J3MgYWxyZWFk eSBkZWZpbmVkLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BY2NvcmRpbmcgdG8gUkZDIDM1MTU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLjQuNCBVc2luZyBTSVAgRXZlbnRzIHRvIFJlcG9y dCB0aGUgUmVzdWx0cyBvZiB0aGUgUmVmZXJlbmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoZSBOT1RJRlkgbWVjaGFuaXNtIGRlZmluZWQgaW4gWzJdDQo8c3BhbiBz dHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPk1VU1Q8L3NwYW4+ IGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBhZ2VudCBzZW5kaW5nIHRoZSBSRUZFUiBvZiB0aGUgc3Rh dHVzIG9mIHRoZSByZWZlcmVuY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZWZvcmUgdGhlIGFiaWxpdHkgdG8g Y3JlYXRlIGFuIGltcGxpY2l0IHN1YnNjcmlwdGlvbiB3aGVuIGFjY2VwdGluZzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+RldJVywgQWNjZXB0aW5nIGlzIHRoZSBrZXkgd29yZCBoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPmEgUkVGRVIgaXMgbWFuZGF0b3J5IGJlaGF2aW9yIGluIFJGQyAzNTE1IGFuZCBp cyBleHBlY3RlZCB0byBiZSBzdXBwb3J0ZWQgYnkgYWxsIFJGQyAzNTE1IFVBQ3M8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgdGhpbmsgYmVmb3JlIGFncmVlaW5nIGFueSB3b3JkaW5nIGhlcmUgd2Ugc2hvdWxkIGhhdmUg YSBnZW5lcmFsIGRpc2N1c3Npb24gb24gdGhlIHByaW5jaXBsZSBvZiB3aGV0aGVyIHRoZXNlIGV4 dGVuc2lvbnMgdGhhdCBhbGxvdyBVQUNzIHRvIHJlcXVlc3QgdGhhdCBubw0KIGltcGxpY2l0IHN1 YnNjcmlwdGlvbiBjYW4gYmUgZWZmZWN0aXZlbHkgcmVxdWlyZWQgYnkgUkVGRVIgVUFTIHRvIGJl IHN1cHBvcnRlZCBhdCB0aGUgVUFDLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGlzLCBhbmQgd2hhdCB5 b3UgaGF2ZSBiZWxvdywgaXMgYSBkaXNjdXNzaW9uIHdlIGRlZmluaXRlbHkgbmVlZCB0byBoYXZl IGFzIHBhcnQgb2YgdGhlIGV4dGVuc2lvbiBkb2N1bWVudC48YnI+DQpJdCBpcyBub3QgbmVjZXNz YXJ5IHRvIHdhaXQgZm9yIHRoYXQgZGlzY3Vzc2lvbiB0byBjb21wbGV0ZSB0aGUgY2xhcmlmaWNh dGlvbnMgZG9jdW1lbnQgdGhhdCB0YWxrcyBhYm91dCB3aGF0IHRoZSBzcGVjcyBzYXkgX25vd18u PGJyPg0KPGJyPg0KTXkgZGlzY29tZm9ydCB3aXRoIHRoZSBjdXJyZW50IHRleHQgaXMgdGhhdCB3 ZSd2ZSBtYWRlIGl0IGNvbXBsZXggdG8gbWFrZSBpdCBzbyB0aGF0IHdlIGRvbid0IGhhdmUgdG8g dXBkYXRlIHRoZSBkb2N1bWVudCBvbmNlIHRoZSBwcm9wb3NlZCBleHRlbnNpb25zIGV4aXN0Ljxi cj4NClRoZXJlIGFyZSBOTyBjdXJyZW50bHkgc3RhbmRhcmRpemVkIGNhc2VzIHdoZXJlIHRoZSBl eGVtcHRpb24gaW4gdGhlIGN1cnJlbnQgdGV4dCB3b3VsZCBiZSBpbnZva2VkLCBhbmQgSSBkb24n dCB0aGluayBwZW9wbGUgYXJlIHRyeWluZyB0byBhcmd1ZSB0aGVyZSBhcmUgLSBJJ20gaGVhcmlu ZyB0aGF0IHRvIGdldCB0aGVyZSwgdGhleSBleHBlY3QgdG8gaW52b2tlIHRoZSB5ZXQtdG8tYmUt ZGVmaW5lZCBleHRlbnNpb24uPGJyPg0KPGJyPg0KU28sIGxldHMgZ28gYmFjayB0byB0aGUgc2xp Z2h0bHkgbG9uZ2VyIHNlbnRlbmNlIHRoYXQgbGVkIHRvIHRoaXM6PGJyPg0KPGJyPg0KQSBVQSB0 aGF0IHdpbGwgYWNjZXB0IGEgc3Vic2NyaXB0aW9uLWNyZWF0aW5nIFJFRkVSIHJlcXVlc3QgbmVl ZHMgdG8gaW5jbHVkZTxicj4NCmEgR1JVVSBhcyB0aGUgQ29udGFjdCBpbiBhbGwgSU5WSVRFIHJl cXVlc3RzIHRvIGVuc3VyZSBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzPGJyPg0KcmVsYXRl ZCB0byBhbnkgZGlhbG9nIGNyZWF0ZWQgYnkgdGhlIElOVklURSBhcnJpdmUgYXQgdGhpcyBVQS48 YnI+DQo8YnI+DQpJbiBhbiBhdHRlbXB0IHRvIGJlIGZ1dHVyZS1wcm9vZiwgdGhhdCdzIGludHJv ZHVjaW5nIHRoZSBwb3RlbnRpYWwgZm9yIGNvbmZ1c2lvbiBhYm91dCB3aGF0IHRoZSBjdXJyZW50 IHN0YW5kYXJkcyBkZWZpbmUuPGJyPg0KTGV0J3MgcmVtb3ZlIHRoYXQgY29uZnVzaW9uLjxicj4N CkhlcmUncyBhIHByb3Bvc2VkIHJlcGxhY2VtZW50LCB0YWtpbmcgQWRhbSdzIHNlbnRlbmNlIHNp bXBsaWZpY2F0aW9uIGludG8gYWNjb3VudDo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgQSBVQSB0 aGF0IHdpbGwgYWNjZXB0IGEgUkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlPGJyPg0KJm5i c3A7Jm5ic3A7IGEgR1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgYWxsIElOVklU RSByZXF1ZXN0cy4mbmJzcDsgVGhpczxicj4NCiZuYnNwOyZuYnNwOyBlbnN1cmVzIHRoYXQgb3V0 LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueTxicj4NCiZuYnNw OyZuYnNwOyByZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJyaXZlIGF0IHRoaXMgVUEuIEZ1dHVy ZSBleHRlbnNpb25zIDxicj4NCiZuYnNwOyZuYnNwOyBbZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVm ZXItZXhwbGljaXRzdWJdIG1pZ2h0IHJlbGF4IHRoaXMgcmVxdWlyZW1lbnQgPGJyPg0KJm5ic3A7 Jm5ic3A7IGJ5IGRlZmluaW5nIGEgUkVGRVIgcmVxdWVzdCB0aGF0IGNhbm5vdCBjcmVhdGUgYW4g aW1wbGljaXQgc3Vic2NyaXB0aW9uLjxicj4NCjxicj4NCjxicj4NClVubGVzcyBJIGhlYXIgb2Jq ZWN0aW9uIHNvb24sIEknbGwgcmV2IHRoZSBkcmFmdCB3aXRoIHRoYXQgY29udGVudC48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SWYgc28gdGhlbiBJIHRoaW5rIHdlIHdpbGwgbmVlZCBhIG5ldyBzaXAgb3B0aW9u cyB0YWcgKGUuZyBSRUZFUi1OT1NVQikgdG8gYmUgdXNlZCBpbiBwbGFjZSBvZiB0aGUgUkVGRVIg b3B0aW9ucyB0YWcgc28gdGhhdCBhIFJGQyAzNTE1IGNvbXBsaWFudCBVQSB0aGF0IGV4cGVjdHMN CiBhIE5PVElGWSB0byBiZSBzZW50IHVwb24gcmVjZWlwdCBvZiBhIFJFRkVSIGFuZCB0aGF0IGlu Y2x1ZGVzIGFuIEFjY2VwdC1Db250YWN0IHJlcXVlc3QgdG8gcmVhY2ggYSBVQSB0aGF0IHN1cHBv cnRzIFJFRkVSIGRvZXNu4oCZdCBlbmQgdXAgYXQgYSBVQVMgdGhhdCBkb2VzbuKAmXQgJm5ic3A7 c3VwcG9ydCBjb21wbGlhbnQgUkZDIDM1MTUgYmVoYXZpb3IgYW5kIGVuZHMgdXAgaGF2aW5nIGl0 cyBSRUZFUiByZXF1ZXN0cyByZWplY3RlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IG93biB2aWV3IGlzIHRoYXQg d2Ugc2hvdWxkIGtlZXAgd2l0aCB0aGUgcHJpbmNpcGxlIG9mIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgYW5kIHRoYXQgZXZlbiB3aGVuIHRoZXNlIG5vIGF1dG9tYXRpYyBzdWJzY3JpcHRpb24gZXh0 ZW5zaW9ucyBhcmUgc3VwcG9ydGVkDQogdGhhdCBmdWxsIHN1cHBvcnQgZm9yIFJGQyAzNTE1IGJl aGF2aW9yIGlzIGNvbnRpbnVlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHJldzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij4gc2lwY29yZSBbPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkFkYW0gUm9hY2g8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyOSwgMjAx NCAxMToxOSBBTTxicj4NCjxiPlRvOjwvYj4gSXZvIFNlZGxhY2VrOyBSb2JlcnQgU3BhcmtzOyA8 YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDcvMjkvMTQgMDk6NTIsIEl2byBTZWRsYWNlayB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5UaHVzLCB0aGUg dGV4dCBzaG91bGQgc3RhdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgSW4gZ2VuZXJhbCwgVUFz IHRoYXQgc3VwcG9ydCByZWNlaXZpbmcgJmd0OyZndDthbmQgYWNjZXB0aW5nIGFuIG91dC1vZi1k aWFsb2cmbHQ7Jmx0OyBSRUZFUiByZXF1ZXN0ICZndDsmZ3Q7Y29ycmVzcG9uZGluZyB0byBhIGRp YWxvZyBlc3RhYmxpc2hlZCBieSBhbiBJTlZJVEUgcmVxdWVzdCZsdDsmbHQ7IG5lZWQgdG8gaW5j bHVkZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgYSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiAmZ3Q7 Jmd0O3RoZSZsdDsmbHQ7IElOVklURSByZXF1ZXN0LiZuYnNwOyBUaGlzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBlbnN1 cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFu eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgcmVzdWx0aW5nIElOVklURSBkaWFsb2dzIGFyZSByb3V0ZWQgdG8gdGhlIGNv cnJlY3QgdXNlciBhZ2VudC4mbmJzcDsgVUFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGF0IHdpbGwgbmV2ZXIgY3Jl YXRlIGEgaW1wbGljaXQgc3Vic2NyaXB0aW9uIGluIHJlc3BvbnNlIHRvIGEgUkVGRVI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7ICh0aGF0IGlzLCB0aG9zZSB0aGF0IHdpbGwgcmVqZWN0IGFueSBSRUZFUiB0aGF0IG1pZ2h0 IHJlc3VsdCBpbiBhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW1wbGljaXQgc3Vic2NyaXB0aW9uKSBhcmUgZXhlbXB0 ZWQgZnJvbSB0aGlzIGJlaGF2aW9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KSSBoZWxwZWQgd2l0aCB0aGUgcGhyYXNpbmcgaGVyZSwgYW5kIG9uZSBvZiB0aGUgZ29hbHMg aGVyZSB3YXMgdG8gbWFrZSB0aGUgZmlyc3Qgc2VudGVuY2UgY292ZXIgdGhlIHZhc3QgbWFqb3Jp dHkgb2YgdGhlIGNhc2VzIChoZW5jZSAmcXVvdDtpbiBnZW5lcmFsJnF1b3Q7KSwgd2l0aCB0aGUg ZXhjZXB0aW9uYWwgY2FzZXMgZGVzY3JpYmVkIGxhdGVyLiBUaGUgcHJvYmxlbSB3YXMgdGhhdCB0 aGUgb3ZlcmFsbCBjb25jZXB0IHdhcyBnZXR0aW5nIGxvc3QgaW4gYSBtYXplDQogb2YgdHdpc3R5 IGNsYXVzZXM6IHRoZSBjbGFyaWZpY2F0aW9uIGhhZCBiZWNvbWUgd29yc2UgdGhhbiB0aGUgc291 cmNlIHRleHQ7IGl0IHdhcyBhY3R1YWxseSBtb3JlIGNvbmZ1c2luZy48YnI+DQo8YnI+DQpZb3Vy IHByb3Bvc2FsIHJldHVybnMgaXQgdG8gdGhpcyB2ZXJ5IGNvbmZ1c2luZyBzdGF0ZSwgYW5kIGlz IHdheSwgd2F5IG91dCBpbnRvIHRoZSByZWFsbSBvZiBleGNlcHRpb25hbCBjYXNlcy48YnI+DQo8 YnI+DQpTbyBJJ2xsIGNvdW50ZXJwcm9wb3NlOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsm bmJzcDsgSW4gZ2VuZXJhbCwgVUFzIHRoYXQgc3VwcG9ydCByZWNlaXZpbmcgUkVGRVIgcmVxdWVz dHMgbmVlZCB0byBpbmNsdWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGEg R1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgYWxsIElOVklURSByZXF1ZXN0cy4m bmJzcDsgVGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBlbnN1cmVzIHRo YXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3Mg YXJlIHJvdXRlZCB0byB0aGUgY29ycmVjdCB1c2VyIGFnZW50LiZuYnNwOyBVQXM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhhdCB3aWxsIG5vdCBjcmVhdGUgYSBpbXBsaWNp dCBzdWJzY3JpcHRpb24gaW4gcmVzcG9uc2UgdG8gYSBSRUZFUjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBmb3IgdGhlIHJlc3VsdGluZyBkaWFsb2cocykgLS0gdGhhdCBpcywg dGhvc2UgdGhhdCB3aWxsIHJlamVjdCBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IGNvcnJlc3BvbmRpbmcgUkVGRVIgdGhhdCBtaWdodCByZXN1bHQgaW4gYW4gaW1wbGljaXQg c3Vic2NyaXB0aW9uIC0tPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFyZSBl eGVtcHRlZCBmcm9tIHRoaXMgYmVoYXZpb3IuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCi9hPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD233991B55AXMB122CNCrimnet_-- From nobody Tue Aug 12 06:05:36 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C724F1A06EC for ; Tue, 12 Aug 2014 06:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_51=0.6, MANGLED_HALF=2.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Ww0RIRc9hg for ; Tue, 12 Aug 2014 06:05:31 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833221A065D for ; Tue, 12 Aug 2014 06:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=hal.gottfried@verizon.com; q=dns/txt; s=corp; t=1407848730; x=1439384730; h=from:to:date:subject:message-id:references:in-reply-to: mime-version; bh=RQnhWtklwV65Cz25u/LhoLNPYEiWvcyXOi0lbnFwBQ4=; b=soCqAaqY652ORIzl9y0rtiiwXronlwXP8xZCAeciCS9mXd2/u47pvQWb 6BzfdVde4aE8pmOcdsGzxfwaTrEQqa5Z63D4FLRHkkJfH7oPuADPStXud KaLdqXmlJ8Qw8ZMrpOi7SL/HMyoIj/JdhVMP9Xx4JT0KI9LUpx24A4YlN Y=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe03.verizon.com with ESMTP; 12 Aug 2014 13:05:07 +0000 From: "Gottfried, Hal F" X-IronPort-AV: E=Sophos;i="5.01,849,1400025600"; d="scan'208,217";a="793805957" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi02.verizon.com with ESMTP; 12 Aug 2014 13:05:07 +0000 Received: from fhdp1lumxc7v13.us.one.verizon.com ([166.68.59.150]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Tue, 12 Aug 2014 09:05:06 -0400 To: "'sipcore@ietf.org'" Date: Tue, 12 Aug 2014 09:05:05 -0400 Thread-Topic: sipcore Digest, Vol 65, Issue 6 Thread-Index: Ac+2LGYxt8mtVwmXRda709CmI9gYGgAAaNqn Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E8A0C2E2F1560648B0FF20D8B91638C502C74C8132FHDP1LUMXC7V1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/2NcQ6f55W8kl3URTAkNu5e-VgA8 Subject: Re: [sipcore] sipcore Digest, Vol 65, Issue 6 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 13:05:35 -0000 --_000_E8A0C2E2F1560648B0FF20D8B91638C502C74C8132FHDP1LUMXC7V1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5zdWJzY3JpYmUNCg0KDQpSZWdhcmRzOg0KDQpIYWwgRi4gR290dGZyaWVkIC8gU3IgQ29uc3Vs dGFudCwgQ29udGFjdCBDZW50ZXIgQ29uc3VsdGluZyAmIFNlcnZpY2VzDQpWZXJpem9uIEFkdmFu Y2VkIFNlcnZpY2VzIC0gQ29uc3VsdGluZyAmIEludGVncmF0aW9uIFNlcnZpY2VzIChBU0NJUykN Ck1vYmlsZTogOTEzLTIxNy0wOTk0DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHNpcGNvcmUtcmVxdWVzdEBpZXRmLm9yZyBbc2lwY29yZS1yZXF1ZXN0QGlldGYub3JnPG1h aWx0bzpzaXBjb3JlLXJlcXVlc3RAaWV0Zi5vcmc+XQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDEy LCAyMDE0IDA4OjUzIEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IHNpcGNvcmVAaWV0Zi5v cmcNClN1YmplY3Q6IHNpcGNvcmUgRGlnZXN0LCBWb2wgNjUsIElzc3VlIDYNCg0KDQpTZW5kIHNp cGNvcmUgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQogICAgICAgIHNpcGNvcmVAaWV0Zi5v cmcNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIs IHZpc2l0DQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw Y29yZQ0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkg J2hlbHAnIHRvDQogICAgICAgIHNpcGNvcmUtcmVxdWVzdEBpZXRmLm9yZw0KDQpZb3UgY2FuIHJl YWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCiAgICAgICAgc2lwY29yZS1vd25l ckBpZXRmLm9yZw0KDQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGlu ZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVudHMgb2Ygc2lwY29yZSBk aWdlc3QuLi4iDQoNCg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgIDEuIFJlOiBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCiAgICAgIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNs YXJpZmljYXRpb25zLTAzLnR4dCAoQW5kcmV3IEFsbGVuKQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K TWVzc2FnZTogMQ0KRGF0ZTogVHVlLCAxMiBBdWcgMjAxNCAxMjo1Mjo1NyArMDAwMA0KRnJvbTog QW5kcmV3IEFsbGVuIDxhYWxsZW5AYmxhY2tiZXJyeS5jb20+DQpUbzogSXZvIFNlZGxhY2VrIDxp dm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPiwgUm9iZXJ0IFNwYXJrcw0KICAgICAgICA8cmpzcGFy a3NAbm9zdHJ1bS5jb20+LCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiwNCiAgICAgICAg InNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBj b3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCiAgICAgICAgZHJhZnQtc3Bh cmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0DQpNZXNzYWdlLUlEOg0KICAg ICAgICA8QkJGNURERkU1MTVDMzk0NkJDMThENzMzQjIwREFEMjMzOTkxQjU1QUBYTUIxMjJDTkMu cmltLm5ldD4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiDQoNCldo YXQgcmVhc29uIHdvdWxkIGEgVUFDIGhhdmUgc3VjaCBhIHJlc3RyaWN0aW9uIGZvciBzb21lIGFu ZCBub3Qgb3RoZXJzPw0KDQpXaHkgd291bGQgaXQgYmUgYWR2YW50YWdlb3VzIHRvICBkZWNyZWFz ZSBpbnRlcm9wZXJhYmlsaXR5IGluIHN1Y2ggc2l0dWF0aW9ucz8NCg0KV2hldGhlciB0aGUgUkVG RVIgcmVxdWVzdCBpcyBzZW50IHdpdGhpbiBvciBvdXRzaWRlIHRoZSBkaWFsb2cgc2hvdWxkIGJl IGEgVUFDIGRlY2lzaW9uIChpZiBpdHMgUkZDIDM1MTUgb25seSBjb21wbGlhbnQpIGFuZCBvdXRz aWRlIHRoZSBkaWFsb2cgaWYgaXMgYWxzbyBSRkMgNjY2NSBjb21wbGlhbnQuDQoNCkFuZHJldw0K DQpGcm9tOiBJdm8gU2VkbGFjZWsgW21haWx0bzppdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tXQ0K U2VudDogVHVlc2RheSwgQXVndXN0IDEyLCAyMDE0IDM6MjQgQU0NClRvOiBSb2JlcnQgU3Bhcmtz OyBBbmRyZXcgQWxsZW47IEFkYW0gUm9hY2g7IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJr cy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dA0KDQpIZWxsbywNCg0KVGhlcmUg c3RpbGwgc2VlbXMgdG8gYmUgbWlzdW5kZXJzdGFuZGluZy4gTGV0IG1lIHN0YXRlIG15IGlzc3Vl IGluIGEgZGlmZmVyZW50IGFuZCBtb3JlIGdlbmVyYWwgd2F5Og0KDQpJZjoNCi0gYSBVRSBzdXBw b3J0cyByZWNlaXZpbmcgYW5kIGFjY2VwdGluZyBvZiBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVl c3QgcmVsYXRlZCB0byBkaWFsb2dzIGNyZWF0ZWQgYnkgc29tZSAoYnV0IG5vdCBhbGwpIElOVklU RSByZXF1ZXN0czsgYW5kDQotIGZvciBhIHBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3QsIHRoZSBV QSByZWplY3RzIGFueSBvdXQtb2YtZGlhbG9nIFJFRkVScyByZWxhdGVkIHRvIGRpYWxvZ3MgY3Jl YXRlZCBieSB0aGUgcGFydGljdWxhciBJTlZJVEUgcmVxdWVzdDsNCnNob3VsZCB0aGUgVUUgYmUg c3RpbGwgbWFuZGF0ZWQgdG8gcHV0IEdSVVUgaW4gdGhlIENvbnRhY3Qgb2YgdGhlIHBhcnRpY3Vs YXIgSU5WSVRFIHJlcXVlc3Q/IElmIHNvLCB3aGF0IHdpbGwgdGhlIEdSVVUgYmUgdXNlZCBmb3I/ DQoNClBsZWFzZSBub3RlIHRoYXQgdGhlIHF1ZXN0aW9uIGFib3ZlIGZvY3VzZXMgc29sZWx5IG9u IG91dC1vZi1kaWFsb2cgUkVGRVJzLg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoN Cg0KVGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCBy ZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJp Y3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxf ZGlzY2xhaW1lcj4NCkZyb206IFJvYmVydCBTcGFya3MgW21haWx0bzpyanNwYXJrc0Bub3N0cnVt LmNvbV0NClNlbnQ6IDcuIHNycG5hIDIwMTQgMTk6NTUNClRvOiBJdm8gU2VkbGFjZWs7IEFuZHJl dyBBbGxlbjsgQWRhbSBSb2FjaDsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dA0K DQpJJ3ZlIHNwZW50IHF1aXRlIHNvbWUgdGltZSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgcHVz aCBmb3IgdGhlIHByb3Bvc2FsIGJlbG93LCBhbmQgSSByZWFsbHkgdGhpbmsgdGhlcmUncyBjb25m dXNpb24sIHNvIEknbSBnb2luZyB0byB0cnkgdG8gc3RlcCB1cCBhIGxldmVsIGFuZCBzZWUgaWYg d2UgY2FuIG1ha2UgcHJvZ3Jlc3MgdGhlcmUuDQoNCkEgVUEgc3VjaCBhcyB5b3VyIHByb3Bvc2Vk IGV4Y2VwdGlvbiBjbGF1c2UgZGVzY3JpYmVzIGlzIHNpbXBseSBub3QgYSBjb21wbGlhbnQgNjY2 NSBpbXBsZW1lbnRhdGlvbiB3aGljaCBpcyB3aGF0IHRoaXMgY2xhcmlmaWNhdGlvbiBkb2N1bWVu dCBpcyBhYm91dC4NCklmIGl0IGFjY2VwdHMgaW4tZGlhbG9nIHN1YnNjcmlwdGlvbiBjcmVhdGlu ZyBSRUZFUnMgaXQgaXMgZm9sbG93aW5nIDMyNjUsIG5vdCA2NjY1IC0gZnVydGhlciBpdCBpcyB2 aW9sYXRpbmcgYSA2NjY1IHJlcXVpcmVtZW50Lg0KSWYgaXQgYWNjZXB0cyBubyBSRUZFUnMgd2hh dHNvZXZlciwgdGhlbiBpdCdzIG5vdCBhZmZlY3RlZCBieSB0aGlzIGRvY3VtZW50Lg0KDQpJZiB0 aGUgcG9pbnQgb2YgdGhlIHdvcmRzbWl0aGluZyBpcyB0byBtYWtlIGxlZ2FjeSBpbXBsZW1lbnRh dGlvbnMgY29tcGxpYW50IHdpdGggNjY2NSwgdGhlcmUncyBubyB3YXkgdG8gc3VjY2VlZCAtIHRo ZXkgc2ltcGx5IGFyZW4ndC4NCg0KSWYgdGhhdCdzIG5vdCB0aGUgcG9pbnQgb2YgdGhlIHdvcmRz bWl0aGluZywgd2hhdCBpcz8NCg0KQXQgdGhlIG1vbWVudCwgSSB0aGluayB3aGF0IEkgc2VudCBi ZWxvdyBpcyBzdGlsbCB0aGUgcmlnaHQgcGF0aCBmb3J3YXJkLg0KDQpSalMNCg0KDQpPbiA4LzEv MTQsIDE6NDQgQU0sIEl2byBTZWRsYWNlayB3cm90ZToNCkFueSBjb21tZW50cyBvbiB0aGUgcHJv cG9zYWwgYmVsb3c/DQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KDQogICBJZiBh IFJFRkVSIHJlcXVlc3QgaXMgYWNjZXB0ZWQgKHRoYXQgaXMsIGEgMnh4IGNsYXNzIHJlc3BvbnNl IGlzDQogICByZXR1cm5lZCksIHRoZSByZWNpcGllbnQgTVVTVCBjcmVhdGUgYSBzdWJzY3JpcHRp b24gYW5kIHNlbmQNCiAgIG5vdGlmaWNhdGlvbnMgb2YgdGhlIHN0YXR1cyBvZiB0aGUgcmVmZXIg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24NCiAgIDIuNC40LkZyb206IHNpcGNvcmUgW21haWx0bzpz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJdm8gU2VkbGFjZWsNClNlbnQ6 IDMxLiA/ZXJ2ZW5jZSAyMDE0IDk6MjYNClRvOiBSb2JlcnQgU3BhcmtzOyBBbmRyZXcgQWxsZW47 IEFkYW0gUm9hY2g7IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQNCg0KSGVsbG8s DQoNCkFjY29yZGluZyB0byB0aGUgZHJhZnQsIHRoZSBwdXJwb3NlIG9mIEdSVVUgaW4gQ29udGFj dCBvZiBJTlZJVEUgcmVxdWVzdCB0byAiDQogICBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBS RUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueQ0KICAgcmVzdWx0aW5nIElOVklURSBk aWFsb2dzIGFycml2ZSBhdCB0aGlzIFVBLiINCg0KSWYgYSBVQSByZWplY3RzIGFueSBvdXQtb2Yt ZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55IGRpYWxvZ3MgcmVsYXRl ZCB0byBhbiBJTlZJVEUgcmVxdWVzdCwgdGhlbiBzZXR0aW5nIHVwIEdSVVUgaW4gQ29udGFjdCBv ZiBJTlZJVEUgZG9lcyBub3QgcHJvdmlkZSBhbnkgcHVycG9zZS4NCg0KVGhpcyBpcyB0cnVlIF9f cmVnYXJkbGVzc19fIHdoZXRoZXIgdGhlIFVBIHN1cHBvcnRzIGFuZCB1c2UgdGhlIGRyYWZ0LXNw YXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0c3ViLg0KU2VlIGF0dGFjaGVkIG1haWwgZ2l2aW5n IGFuIGV4YW1wbGUgb2YgVUEgaGF2aW5nIHR3byB0eXBlcyBvZiBzZXNzaW9ucywgVHlwZV9BIHRy YW5zZmVycmFibGUgYnkgUkVGRVIsIGFuZCBUeXBlX0Igbm90IHRyYW5zZmVycmFibGUgYnkgUkVG RVIuDQpHaXZlbiB0aGF0IGRpZmZlcmVudCBzdGFuZGFyZGl6YXRpb24gb3JnYW5pemF0aW9uIGhh cyBkZWZpbmVkIHNvIG1hbnkgZW5hYmxlcnMgd2hpY2ggY2FuIHJ1biBvbiBhIHNpbmdsZSBVQSwg SSBmaW5kIGl0IHdlaXJkIHRoYXQgb25lIGNhbiBndWFyYW50ZWUgdGhhdCB0aGUgYWJvdmUgY2Fu bm90IG9jY3VyLg0KDQpUaHVzLCBJIGhlc2l0YXRlIHRvIG1hbmRhdGUgYW4gdW5uZWNlc3Nhcnkg cmVxdWlyZW1lbnQgaW5mbHVlbmNpbmcgcG9zc2libGUgZXhpc3RpbmcgVUEgaW1wbGVtZW50YXRp b25zIGFuZCBJIHByZWZlciB0byBiZSBleHBsaWNpdCBvbiB0aGUgZXhjZXB0aW9uIGZvciB1c2Fn ZSBvZiBHUlVVIGluIENvbnRhY3Qgb2YgSU5WSVRFIHJlcXVlc3Q6DQoNCg0KDQoNCiAgIEEgVUEg dGhhdCB3aWxsIGFjY2VwdCBhIFJFRkVSIHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZQ0KDQogICBh IEdSVVUgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mIGFsbCBJTlZJVEUgcmVxdWVzdHMu ICBUaGlzDQoNCiAgIGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNv cnJlc3BvbmRpbmcgdG8gYW55DQoNCiAgIHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUg YXQgdGhpcyBVQS4gPj4+VUFzIHRoYXQgd2lsbCBub3QgYWNjZXB0IGFueSBvdXQtb2YtZGlhbG9n IFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gZGlhbG9nKHMpIGNyZWF0ZWQgYnkgYW4g SU5WSVRFIHJlcXVlc3QNCg0KICAgYXJlIGV4ZW1wdGVkIGZyb20gaW5jbHVkaW5nIGEgR1JVVSBp biB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgdGhlIElOVklURSByZXF1ZXN0Ljw8PA0KDQpL aW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoNCg0KRnJvbTogUm9iZXJ0IFNwYXJrcyBbbWFp bHRvOnJqc3BhcmtzQG5vc3RydW0uY29tXQ0KU2VudDogMzAuID9lcnZlbmNlIDIwMTQgMTg6NTQN ClRvOiBBbmRyZXcgQWxsZW47IEFkYW0gUm9hY2g7IEl2byBTZWRsYWNlazsgc2lwY29yZUBpZXRm Lm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVy LWNsYXJpZmljYXRpb25zLTAzLnR4dA0KDQoNCk9uIDcvMzAvMTQsIDEwOjMzIEFNLCBBbmRyZXcg QWxsZW4gd3JvdGU6DQpJIGhhdmUgYSBnZW5lcmFsIGNvbmNlcm4gd2l0aCB0aGUgZGlyZWN0aW9u IHRoaXMgaXMgbm93IGdvaW5nLg0KSSBkb24ndCB0aGluayB5b3UgaGF2ZSB0aGUgYmFja3dhcmRz LWNvbXBhdGliaWxpdHkgY29uY2VybiBxdWl0ZSByaWdodCwgYnV0IEkgYWdyZWUgdGhhdCB0aGUg Y3VycmVudCB3b3JkaW5nIGlzbid0IHRoZXJlIHlldC4NCg0KQXJlIHdlIG5vdyBzYXlpbmcgaGVy ZSB0aGF0IGl0P3MgT0sgZm9yIGEgVUEgdGhhdCBzdXBwb3J0cyByZWNlaXZpbmcgUkVGRVIgdG8g YXJiaXRyYXJpbHkgcmVqZWN0IGFueSBSRUZFUiB0aGF0IHdvdWxkIGNyZWF0ZSBhIHN1YnNjcmlw dGlvbiAoaS5lIGJlIGluY29tcGF0aWJsZSB3aXRoIFJGQyAzNTE1IFVBQ3MgYnkgYmFzaWNhbGx5 IG5vdCBzdXBwb3J0aW5nIFJGQyAzNTE1IFVBUyBjb21wbGlhbnQgYmVoYXZpb3IpPw0KTm8sIF90 aGlzXyBkb2N1bWVudCBpcyBub3QgZGVmaW5pbmcgbmV3IGJlaGF2aW9yLiBJdCdzIG9ubHkgY2xh cmlmeWluZyB3aGF0J3MgYWxyZWFkeSBkZWZpbmVkLg0KDQoNCkFjY29yZGluZyB0byBSRkMgMzUx NQ0KDQoyLjQuNCBVc2luZyBTSVAgRXZlbnRzIHRvIFJlcG9ydCB0aGUgUmVzdWx0cyBvZiB0aGUg UmVmZXJlbmNlDQoNCiAgICAgICAgICAgICAgICBUaGUgTk9USUZZIG1lY2hhbmlzbSBkZWZpbmVk IGluIFsyXSBNVVNUIGJlIHVzZWQgdG8gaW5mb3JtIHRoZSBhZ2VudCBzZW5kaW5nIHRoZSBSRUZF UiBvZiB0aGUgc3RhdHVzIG9mIHRoZSByZWZlcmVuY2UuDQoNClRoZXJlZm9yZSB0aGUgYWJpbGl0 eSB0byBjcmVhdGUgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uIHdoZW4gYWNjZXB0aW5nDQpGV0lX LCBBY2NlcHRpbmcgaXMgdGhlIGtleSB3b3JkIGhlcmUuDQphIFJFRkVSIGlzIG1hbmRhdG9yeSBi ZWhhdmlvciBpbiBSRkMgMzUxNSBhbmQgaXMgZXhwZWN0ZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IGFs bCBSRkMgMzUxNSBVQUNzDQoNCkkgdGhpbmsgYmVmb3JlIGFncmVlaW5nIGFueSB3b3JkaW5nIGhl cmUgd2Ugc2hvdWxkIGhhdmUgYSBnZW5lcmFsIGRpc2N1c3Npb24gb24gdGhlIHByaW5jaXBsZSBv ZiB3aGV0aGVyIHRoZXNlIGV4dGVuc2lvbnMgdGhhdCBhbGxvdyBVQUNzIHRvIHJlcXVlc3QgdGhh dCBubyBpbXBsaWNpdCBzdWJzY3JpcHRpb24gY2FuIGJlIGVmZmVjdGl2ZWx5IHJlcXVpcmVkIGJ5 IFJFRkVSIFVBUyB0byBiZSBzdXBwb3J0ZWQgYXQgdGhlIFVBQy4NClRoaXMsIGFuZCB3aGF0IHlv dSBoYXZlIGJlbG93LCBpcyBhIGRpc2N1c3Npb24gd2UgZGVmaW5pdGVseSBuZWVkIHRvIGhhdmUg YXMgcGFydCBvZiB0aGUgZXh0ZW5zaW9uIGRvY3VtZW50Lg0KSXQgaXMgbm90IG5lY2Vzc2FyeSB0 byB3YWl0IGZvciB0aGF0IGRpc2N1c3Npb24gdG8gY29tcGxldGUgdGhlIGNsYXJpZmljYXRpb25z IGRvY3VtZW50IHRoYXQgdGFsa3MgYWJvdXQgd2hhdCB0aGUgc3BlY3Mgc2F5IF9ub3dfLg0KDQpN eSBkaXNjb21mb3J0IHdpdGggdGhlIGN1cnJlbnQgdGV4dCBpcyB0aGF0IHdlJ3ZlIG1hZGUgaXQg Y29tcGxleCB0byBtYWtlIGl0IHNvIHRoYXQgd2UgZG9uJ3QgaGF2ZSB0byB1cGRhdGUgdGhlIGRv Y3VtZW50IG9uY2UgdGhlIHByb3Bvc2VkIGV4dGVuc2lvbnMgZXhpc3QuDQpUaGVyZSBhcmUgTk8g Y3VycmVudGx5IHN0YW5kYXJkaXplZCBjYXNlcyB3aGVyZSB0aGUgZXhlbXB0aW9uIGluIHRoZSBj dXJyZW50IHRleHQgd291bGQgYmUgaW52b2tlZCwgYW5kIEkgZG9uJ3QgdGhpbmsgcGVvcGxlIGFy ZSB0cnlpbmcgdG8gYXJndWUgdGhlcmUgYXJlIC0gSSdtIGhlYXJpbmcgdGhhdCB0byBnZXQgdGhl cmUsIHRoZXkgZXhwZWN0IHRvIGludm9rZSB0aGUgeWV0LXRvLWJlLWRlZmluZWQgZXh0ZW5zaW9u Lg0KDQpTbywgbGV0cyBnbyBiYWNrIHRvIHRoZSBzbGlnaHRseSBsb25nZXIgc2VudGVuY2UgdGhh dCBsZWQgdG8gdGhpczoNCg0KQSBVQSB0aGF0IHdpbGwgYWNjZXB0IGEgc3Vic2NyaXB0aW9uLWNy ZWF0aW5nIFJFRkVSIHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZQ0KYSBHUlVVIGFzIHRoZSBDb250 YWN0IGluIGFsbCBJTlZJVEUgcmVxdWVzdHMgdG8gZW5zdXJlIG91dC1vZi1kaWFsb2cgUkVGRVIg cmVxdWVzdHMNCnJlbGF0ZWQgdG8gYW55IGRpYWxvZyBjcmVhdGVkIGJ5IHRoZSBJTlZJVEUgYXJy aXZlIGF0IHRoaXMgVUEuDQoNCkluIGFuIGF0dGVtcHQgdG8gYmUgZnV0dXJlLXByb29mLCB0aGF0 J3MgaW50cm9kdWNpbmcgdGhlIHBvdGVudGlhbCBmb3IgY29uZnVzaW9uIGFib3V0IHdoYXQgdGhl IGN1cnJlbnQgc3RhbmRhcmRzIGRlZmluZS4NCkxldCdzIHJlbW92ZSB0aGF0IGNvbmZ1c2lvbi4N CkhlcmUncyBhIHByb3Bvc2VkIHJlcGxhY2VtZW50LCB0YWtpbmcgQWRhbSdzIHNlbnRlbmNlIHNp bXBsaWZpY2F0aW9uIGludG8gYWNjb3VudDoNCg0KICAgQSBVQSB0aGF0IHdpbGwgYWNjZXB0IGEg UkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlDQogICBhIEdSVVUgaW4gdGhlIENvbnRhY3Qg aGVhZGVyIGZpZWxkIG9mIGFsbCBJTlZJVEUgcmVxdWVzdHMuICBUaGlzDQogICBlbnN1cmVzIHRo YXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueQ0KICAg cmVzdWx0aW5nIElOVklURSBkaWFsb2dzIGFycml2ZSBhdCB0aGlzIFVBLiBGdXR1cmUgZXh0ZW5z aW9ucw0KICAgW2RyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0c3ViXSBtaWdodCBy ZWxheCB0aGlzIHJlcXVpcmVtZW50DQogICBieSBkZWZpbmluZyBhIFJFRkVSIHJlcXVlc3QgdGhh dCBjYW5ub3QgY3JlYXRlIGFuIGltcGxpY2l0IHN1YnNjcmlwdGlvbi4NCg0KDQpVbmxlc3MgSSBo ZWFyIG9iamVjdGlvbiBzb29uLCBJJ2xsIHJldiB0aGUgZHJhZnQgd2l0aCB0aGF0IGNvbnRlbnQu DQoNCg0KSWYgc28gdGhlbiBJIHRoaW5rIHdlIHdpbGwgbmVlZCBhIG5ldyBzaXAgb3B0aW9ucyB0 YWcgKGUuZyBSRUZFUi1OT1NVQikgdG8gYmUgdXNlZCBpbiBwbGFjZSBvZiB0aGUgUkVGRVIgb3B0 aW9ucyB0YWcgc28gdGhhdCBhIFJGQyAzNTE1IGNvbXBsaWFudCBVQSB0aGF0IGV4cGVjdHMgYSBO T1RJRlkgdG8gYmUgc2VudCB1cG9uIHJlY2VpcHQgb2YgYSBSRUZFUiBhbmQgdGhhdCBpbmNsdWRl cyBhbiBBY2NlcHQtQ29udGFjdCByZXF1ZXN0IHRvIHJlYWNoIGEgVUEgdGhhdCBzdXBwb3J0cyBS RUZFUiBkb2Vzbj90IGVuZCB1cCBhdCBhIFVBUyB0aGF0IGRvZXNuP3QgIHN1cHBvcnQgY29tcGxp YW50IFJGQyAzNTE1IGJlaGF2aW9yIGFuZCBlbmRzIHVwIGhhdmluZyBpdHMgUkVGRVIgcmVxdWVz dHMgcmVqZWN0ZWQuDQoNCk15IG93biB2aWV3IGlzIHRoYXQgd2Ugc2hvdWxkIGtlZXAgd2l0aCB0 aGUgcHJpbmNpcGxlIG9mIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgYW5kIHRoYXQgZXZlbiB3aGVu IHRoZXNlIG5vIGF1dG9tYXRpYyBzdWJzY3JpcHRpb24gZXh0ZW5zaW9ucyBhcmUgc3VwcG9ydGVk IHRoYXQgZnVsbCBzdXBwb3J0IGZvciBSRkMgMzUxNSBiZWhhdmlvciBpcyBjb250aW51ZWQuDQoN CkFuZHJldw0KDQoNCg0KDQoNCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFJvYWNoDQpTZW50OiBUdWVzZGF5LCBKdWx5IDI5 LCAyMDE0IDExOjE5IEFNDQpUbzogSXZvIFNlZGxhY2VrOyBSb2JlcnQgU3BhcmtzOyBzaXBjb3Jl QGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3Jl XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BhcmtzLXNpcGNvcmUt cmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0DQoNCk9uIDcvMjkvMTQgMDk6NTIsIEl2byBTZWRs YWNlayB3cm90ZToNCg0KVGh1cywgdGhlIHRleHQgc2hvdWxkIHN0YXRlOg0KDQoNCiAgIEluIGdl bmVyYWwsIFVBcyB0aGF0IHN1cHBvcnQgcmVjZWl2aW5nID4+YW5kIGFjY2VwdGluZyBhbiBvdXQt b2YtZGlhbG9nPDwgUkVGRVIgcmVxdWVzdCA+PmNvcnJlc3BvbmRpbmcgdG8gYSBkaWFsb2cgZXN0 YWJsaXNoZWQgYnkgYW4gSU5WSVRFIHJlcXVlc3Q8PCBuZWVkIHRvIGluY2x1ZGUNCiAgIGEgR1JV VSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgPj50aGU8PCBJTlZJVEUgcmVxdWVzdC4g IFRoaXMNCiAgIGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJl c3BvbmRpbmcgdG8gYW55DQogICByZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJlIHJvdXRlZCB0 byB0aGUgY29ycmVjdCB1c2VyIGFnZW50LiAgVUFzDQogICB0aGF0IHdpbGwgbmV2ZXIgY3JlYXRl IGEgaW1wbGljaXQgc3Vic2NyaXB0aW9uIGluIHJlc3BvbnNlIHRvIGEgUkVGRVINCiAgICh0aGF0 IGlzLCB0aG9zZSB0aGF0IHdpbGwgcmVqZWN0IGFueSBSRUZFUiB0aGF0IG1pZ2h0IHJlc3VsdCBp biBhbg0KICAgaW1wbGljaXQgc3Vic2NyaXB0aW9uKSBhcmUgZXhlbXB0ZWQgZnJvbSB0aGlzIGJl aGF2aW9yLg0KDQpJIGhlbHBlZCB3aXRoIHRoZSBwaHJhc2luZyBoZXJlLCBhbmQgb25lIG9mIHRo ZSBnb2FscyBoZXJlIHdhcyB0byBtYWtlIHRoZSBmaXJzdCBzZW50ZW5jZSBjb3ZlciB0aGUgdmFz dCBtYWpvcml0eSBvZiB0aGUgY2FzZXMgKGhlbmNlICJpbiBnZW5lcmFsIiksIHdpdGggdGhlIGV4 Y2VwdGlvbmFsIGNhc2VzIGRlc2NyaWJlZCBsYXRlci4gVGhlIHByb2JsZW0gd2FzIHRoYXQgdGhl IG92ZXJhbGwgY29uY2VwdCB3YXMgZ2V0dGluZyBsb3N0IGluIGEgbWF6ZSBvZiB0d2lzdHkgY2xh dXNlczogdGhlIGNsYXJpZmljYXRpb24gaGFkIGJlY29tZSB3b3JzZSB0aGFuIHRoZSBzb3VyY2Ug dGV4dDsgaXQgd2FzIGFjdHVhbGx5IG1vcmUgY29uZnVzaW5nLg0KDQpZb3VyIHByb3Bvc2FsIHJl dHVybnMgaXQgdG8gdGhpcyB2ZXJ5IGNvbmZ1c2luZyBzdGF0ZSwgYW5kIGlzIHdheSwgd2F5IG91 dCBpbnRvIHRoZSByZWFsbSBvZiBleGNlcHRpb25hbCBjYXNlcy4NCg0KU28gSSdsbCBjb3VudGVy cHJvcG9zZToNCg0KICAgSW4gZ2VuZXJhbCwgVUFzIHRoYXQgc3VwcG9ydCByZWNlaXZpbmcgUkVG RVIgcmVxdWVzdHMgbmVlZCB0byBpbmNsdWRlDQoNCiAgIGEgR1JVVSBpbiB0aGUgQ29udGFjdCBo ZWFkZXIgZmllbGQgb2YgYWxsIElOVklURSByZXF1ZXN0cy4gIFRoaXMNCg0KICAgZW5zdXJlcyB0 aGF0IG91dC1vZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9uZGluZyB0byBhbnkNCg0K ICAgcmVzdWx0aW5nIElOVklURSBkaWFsb2dzIGFyZSByb3V0ZWQgdG8gdGhlIGNvcnJlY3QgdXNl ciBhZ2VudC4gIFVBcw0KDQogICB0aGF0IHdpbGwgbm90IGNyZWF0ZSBhIGltcGxpY2l0IHN1YnNj cmlwdGlvbiBpbiByZXNwb25zZSB0byBhIFJFRkVSDQoNCiAgIGZvciB0aGUgcmVzdWx0aW5nIGRp YWxvZyhzKSAtLSB0aGF0IGlzLCB0aG9zZSB0aGF0IHdpbGwgcmVqZWN0IGENCg0KICAgY29ycmVz cG9uZGluZyBSRUZFUiB0aGF0IG1pZ2h0IHJlc3VsdCBpbiBhbiBpbXBsaWNpdCBzdWJzY3JpcHRp b24gLS0NCg0KICAgYXJlIGV4ZW1wdGVkIGZyb20gdGhpcyBiZWhhdmlvci4NCg0KL2ENCg0KDQoN Ci0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQ0KQW4gSFRNTCBhdHRhY2ht ZW50IHdhcyBzY3J1YmJlZC4uLg0KVVJMOiA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NpcGNvcmUvYXR0YWNobWVudHMvMjAxNDA4MTIvODQ2NTlhMTAvYXR0YWNobWVudC5o dG1sPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU3ViamVjdDogRGlnZXN0 IEZvb3Rlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQpFbmQgb2Ygc2lwY29yZSBEaWdlc3QsIFZvbCA2NSwgSXNzdWUgNg0KKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg== --_000_E8A0C2E2F1560648B0FF20D8B91638C502C74C8132FHDP1LUMXC7V1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRNTCBUaWR5IGZvciBX aW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDA4LjAzLjAzMzAuMDAwIj4NCjx0aXRsZT5zaXBjb3JlIERpZ2VzdCwgVm9sIDY1LCBJc3N1 ZSA2PC90aXRsZT4NCjwvaGVhZD4NCjxib2R5Pg0KVW5zdWJzY3JpYmU8YnI+DQo8YnI+DQo8YnI+ DQpSZWdhcmRzOjxicj4NCjxicj4NCkhhbCBGLiBHb3R0ZnJpZWQgLyBTciBDb25zdWx0YW50LCBD b250YWN0IENlbnRlciBDb25zdWx0aW5nICZhbXA7IFNlcnZpY2VzPGJyPg0KVmVyaXpvbiBBZHZh bmNlZCBTZXJ2aWNlcyAtIENvbnN1bHRpbmcgJmFtcDsgSW50ZWdyYXRpb24gU2VydmljZXMgKEFT Q0lTKTxicj4NCk1vYmlsZTogOTEzLTIxNy0wOTk0PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQo8Yj5Gcm9tOiZuYnNwOzwvYj5zaXBjb3JlLXJlcXVlc3RA aWV0Zi5vcmcgWzxhIGhyZWY9Im1haWx0bzpzaXBjb3JlLXJlcXVlc3RAaWV0Zi5vcmciPnNpcGNv cmUtcmVxdWVzdEBpZXRmLm9yZzwvYT5dPGJyPg0KPGI+U2VudDombmJzcDs8L2I+VHVlc2RheSwg QXVndXN0IDEyLCAyMDE0IDA4OjUzIEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZTxicj4NCjxiPlRv OiZuYnNwOzwvYj5zaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDombmJzcDs8L2I+c2lw Y29yZSBEaWdlc3QsIFZvbCA2NSwgSXNzdWUgNjxicj4NCjxicj4NCjwhLS0gQ29udmVydGVkIGZy b20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQo8cD48Zm9udCBzaXplPSIyIj5TZW5kIHNpcGNvcmUg bWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8YnI+DQpUbyBzdWJzY3Jp YmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQ8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+PGJyPg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBh IG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpcGNvcmUtcmVxdWVzdEBpZXRmLm9yZzxi cj4NCjxicj4NCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdDxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaXBjb3JlLW93 bmVyQGlldGYub3JnPGJyPg0KPGJyPg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBT dWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYzxicj4NCnRoYW4gIlJlOiBDb250ZW50 cyBvZiBzaXBjb3JlIGRpZ2VzdC4uLiI8YnI+DQo8YnI+DQo8YnI+DQpUb2RheSdzIFRvcGljczo8 YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgMS4gUmU6IEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1zcGFya3Mt c2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQgKEFuZHJldyBBbGxlbik8YnI+DQo8 YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KTWVzc2FnZTogMTxicj4NCkRhdGU6 IFR1ZSwgMTIgQXVnIDIwMTQgMTI6NTI6NTcgKzAwMDA8YnI+DQpGcm9tOiBBbmRyZXcgQWxsZW4g Jmx0O2FhbGxlbkBibGFja2JlcnJ5LmNvbSZndDs8YnI+DQpUbzogSXZvIFNlZGxhY2VrICZsdDtp dm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tJmd0OywgUm9iZXJ0IFNwYXJrczxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7cmpzcGFya3NAbm9zdHJ1bS5j b20mZ3Q7LCBBZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0Oyw8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInNpcGNvcmVAaWV0Zi5vcmciICZs dDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRp b25zLTAzLnR4dDxicj4NCk1lc3NhZ2UtSUQ6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtCQkY1RERGRTUxNUMzOTQ2QkMxOEQ3MzNCMjBEQUQyMzM5 OTFCNTVBQFhNQjEyMkNOQy5yaW0ubmV0Jmd0Ozxicj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD0idXRmLTgiPGJyPg0KPGJyPg0KV2hhdCByZWFzb24gd291bGQgYSBVQUMgaGF2 ZSBzdWNoIGEgcmVzdHJpY3Rpb24gZm9yIHNvbWUgYW5kIG5vdCBvdGhlcnM/PGJyPg0KPGJyPg0K V2h5IHdvdWxkIGl0IGJlIGFkdmFudGFnZW91cyB0byZuYnNwOyBkZWNyZWFzZSBpbnRlcm9wZXJh YmlsaXR5IGluIHN1Y2ggc2l0dWF0aW9ucz88YnI+DQo8YnI+DQpXaGV0aGVyIHRoZSBSRUZFUiBy ZXF1ZXN0IGlzIHNlbnQgd2l0aGluIG9yIG91dHNpZGUgdGhlIGRpYWxvZyBzaG91bGQgYmUgYSBV QUMgZGVjaXNpb24gKGlmIGl0cyBSRkMgMzUxNSBvbmx5IGNvbXBsaWFudCkgYW5kIG91dHNpZGUg dGhlIGRpYWxvZyBpZiBpcyBhbHNvIFJGQyA2NjY1IGNvbXBsaWFudC48YnI+DQo8YnI+DQpBbmRy ZXc8YnI+DQo8YnI+DQpGcm9tOiBJdm8gU2VkbGFjZWsgWzxhIGhyZWY9Im1haWx0bzppdm8uc2Vk bGFjZWtAZXJpY3Nzb24uY29tIj5tYWlsdG86aXZvLnNlZGxhY2VrQGVyaWNzc29uLmNvbTwvYT5d PGJyPg0KU2VudDogVHVlc2RheSwgQXVndXN0IDEyLCAyMDE0IDM6MjQgQU08YnI+DQpUbzogUm9i ZXJ0IFNwYXJrczsgQW5kcmV3IEFsbGVuOyBBZGFtIFJvYWNoOyBzaXBjb3JlQGlldGYub3JnPGJy Pg0KU3ViamVjdDogUkU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0PGJyPg0K PGJyPg0KSGVsbG8sPGJyPg0KPGJyPg0KVGhlcmUgc3RpbGwgc2VlbXMgdG8gYmUgbWlzdW5kZXJz dGFuZGluZy4gTGV0IG1lIHN0YXRlIG15IGlzc3VlIGluIGEgZGlmZmVyZW50IGFuZCBtb3JlIGdl bmVyYWwgd2F5Ojxicj4NCjxicj4NCklmOjxicj4NCi0gYSBVRSBzdXBwb3J0cyByZWNlaXZpbmcg YW5kIGFjY2VwdGluZyBvZiBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3QgcmVsYXRlZCB0byBk aWFsb2dzIGNyZWF0ZWQgYnkgc29tZSAoYnV0IG5vdCBhbGwpIElOVklURSByZXF1ZXN0czsgYW5k PGJyPg0KLSBmb3IgYSBwYXJ0aWN1bGFyIElOVklURSByZXF1ZXN0LCB0aGUgVUEgcmVqZWN0cyBh bnkgb3V0LW9mLWRpYWxvZyBSRUZFUnMgcmVsYXRlZCB0byBkaWFsb2dzIGNyZWF0ZWQgYnkgdGhl IHBhcnRpY3VsYXIgSU5WSVRFIHJlcXVlc3Q7PGJyPg0Kc2hvdWxkIHRoZSBVRSBiZSBzdGlsbCBt YW5kYXRlZCB0byBwdXQgR1JVVSBpbiB0aGUgQ29udGFjdCBvZiB0aGUgcGFydGljdWxhciBJTlZJ VEUgcmVxdWVzdD8gSWYgc28sIHdoYXQgd2lsbCB0aGUgR1JVVSBiZSB1c2VkIGZvcj88YnI+DQo8 YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBxdWVzdGlvbiBhYm92ZSBmb2N1c2VzIHNvbGVseSBv biBvdXQtb2YtZGlhbG9nIFJFRkVScy48YnI+DQo8YnI+DQpLaW5kIHJlZ2FyZHM8YnI+DQo8YnI+ DQpJdm8gU2VkbGFjZWs8YnI+DQo8YnI+DQo8YnI+DQpUaGlzIENvbW11bmljYXRpb24gaXMgQ29u ZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9m IHRoZSB0ZXJtcyBzZXQgb3V0IGF0IHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciZs dDs8YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIj5odHRw Oi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9hPiZndDs8YnI+DQpGcm9tOiBS b2JlcnQgU3BhcmtzIFs8YSBocmVmPSJtYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb20iPm1haWx0 bzpyanNwYXJrc0Bub3N0cnVtLmNvbTwvYT5dPGJyPg0KU2VudDogNy4gc3JwbmEgMjAxNCAxOTo1 NTxicj4NClRvOiBJdm8gU2VkbGFjZWs7IEFuZHJldyBBbGxlbjsgQWRhbSBSb2FjaDsgc2lwY29y ZUBpZXRmLm9yZyZsdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+bWFpbHRvOnNp cGNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNs YXJpZmljYXRpb25zLTAzLnR4dDxicj4NCjxicj4NCkkndmUgc3BlbnQgcXVpdGUgc29tZSB0aW1l IHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBwdXNoIGZvciB0aGUgcHJvcG9zYWwgYmVsb3csIGFu ZCBJIHJlYWxseSB0aGluayB0aGVyZSdzIGNvbmZ1c2lvbiwgc28gSSdtIGdvaW5nIHRvIHRyeSB0 byBzdGVwIHVwIGEgbGV2ZWwgYW5kIHNlZSBpZiB3ZSBjYW4gbWFrZSBwcm9ncmVzcyB0aGVyZS48 YnI+DQo8YnI+DQpBIFVBIHN1Y2ggYXMgeW91ciBwcm9wb3NlZCBleGNlcHRpb24gY2xhdXNlIGRl c2NyaWJlcyBpcyBzaW1wbHkgbm90IGEgY29tcGxpYW50IDY2NjUgaW1wbGVtZW50YXRpb24gd2hp Y2ggaXMgd2hhdCB0aGlzIGNsYXJpZmljYXRpb24gZG9jdW1lbnQgaXMgYWJvdXQuPGJyPg0KSWYg aXQgYWNjZXB0cyBpbi1kaWFsb2cgc3Vic2NyaXB0aW9uIGNyZWF0aW5nIFJFRkVScyBpdCBpcyBm b2xsb3dpbmcgMzI2NSwgbm90IDY2NjUgLSBmdXJ0aGVyIGl0IGlzIHZpb2xhdGluZyBhIDY2NjUg cmVxdWlyZW1lbnQuPGJyPg0KSWYgaXQgYWNjZXB0cyBubyBSRUZFUnMgd2hhdHNvZXZlciwgdGhl biBpdCdzIG5vdCBhZmZlY3RlZCBieSB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NCklmIHRoZSBw b2ludCBvZiB0aGUgd29yZHNtaXRoaW5nIGlzIHRvIG1ha2UgbGVnYWN5IGltcGxlbWVudGF0aW9u cyBjb21wbGlhbnQgd2l0aCA2NjY1LCB0aGVyZSdzIG5vIHdheSB0byBzdWNjZWVkIC0gdGhleSBz aW1wbHkgYXJlbid0Ljxicj4NCjxicj4NCklmIHRoYXQncyBub3QgdGhlIHBvaW50IG9mIHRoZSB3 b3Jkc21pdGhpbmcsIHdoYXQgaXM/PGJyPg0KPGJyPg0KQXQgdGhlIG1vbWVudCwgSSB0aGluayB3 aGF0IEkgc2VudCBiZWxvdyBpcyBzdGlsbCB0aGUgcmlnaHQgcGF0aCBmb3J3YXJkLjxicj4NCjxi cj4NClJqUzxicj4NCjxicj4NCjxicj4NCk9uIDgvMS8xNCwgMTo0NCBBTSwgSXZvIFNlZGxhY2Vr IHdyb3RlOjxicj4NCkFueSBjb21tZW50cyBvbiB0aGUgcHJvcG9zYWwgYmVsb3c/PGJyPg0KPGJy Pg0KS2luZCByZWdhcmRzPGJyPg0KPGJyPg0KSXZvIFNlZGxhY2VrPGJyPg0KPGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7IElmIGEgUkVGRVIgcmVxdWVzdCBpcyBhY2NlcHRlZCAodGhhdCBpcywgYSAy eHggY2xhc3MgcmVzcG9uc2UgaXM8YnI+DQombmJzcDsmbmJzcDsgcmV0dXJuZWQpLCB0aGUgcmVj aXBpZW50IE1VU1QgY3JlYXRlIGEgc3Vic2NyaXB0aW9uIGFuZCBzZW5kPGJyPg0KJm5ic3A7Jm5i c3A7IG5vdGlmaWNhdGlvbnMgb2YgdGhlIHN0YXR1cyBvZiB0aGUgcmVmZXIgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb248YnI+DQombmJzcDsmbmJzcDsgMi40LjQuRnJvbTogc2lwY29yZSBbPGEgaHJl Zj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNpcGNvcmUtYm91bmNl c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBJdm8gU2VkbGFjZWs8YnI+DQpTZW50OiAzMS4g P2VydmVuY2UgMjAxNCA5OjI2PGJyPg0KVG86IFJvYmVydCBTcGFya3M7IEFuZHJldyBBbGxlbjsg QWRhbSBSb2FjaDsgc2lwY29yZUBpZXRmLm9yZyZsdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBp ZXRmLm9yZyI+bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJl OiBbc2lwY29yZV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJr cy1zaXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTAzLnR4dDxicj4NCjxicj4NCkhlbGxvLDxi cj4NCjxicj4NCkFjY29yZGluZyB0byB0aGUgZHJhZnQsIHRoZSBwdXJwb3NlIG9mIEdSVVUgaW4g Q29udGFjdCBvZiBJTlZJVEUgcmVxdWVzdCB0byAiPGJyPg0KJm5ic3A7Jm5ic3A7IGVuc3VyZXMg dGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55PGJy Pg0KJm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBhcnJpdmUgYXQgdGhpcyBV QS4iPGJyPg0KPGJyPg0KSWYgYSBVQSByZWplY3RzIGFueSBvdXQtb2YtZGlhbG9nIFJFRkVSIHJl cXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55IGRpYWxvZ3MgcmVsYXRlZCB0byBhbiBJTlZJVEUg cmVxdWVzdCwgdGhlbiBzZXR0aW5nIHVwIEdSVVUgaW4gQ29udGFjdCBvZiBJTlZJVEUgZG9lcyBu b3QgcHJvdmlkZSBhbnkgcHVycG9zZS48YnI+DQo8YnI+DQpUaGlzIGlzIHRydWUgX19yZWdhcmRs ZXNzX18gd2hldGhlciB0aGUgVUEgc3VwcG9ydHMgYW5kIHVzZSB0aGUgZHJhZnQtc3BhcmtzLXNp cGNvcmUtcmVmZXItZXhwbGljaXRzdWIuPGJyPg0KU2VlIGF0dGFjaGVkIG1haWwgZ2l2aW5nIGFu IGV4YW1wbGUgb2YgVUEgaGF2aW5nIHR3byB0eXBlcyBvZiBzZXNzaW9ucywgVHlwZV9BIHRyYW5z ZmVycmFibGUgYnkgUkVGRVIsIGFuZCBUeXBlX0Igbm90IHRyYW5zZmVycmFibGUgYnkgUkVGRVIu PGJyPg0KR2l2ZW4gdGhhdCBkaWZmZXJlbnQgc3RhbmRhcmRpemF0aW9uIG9yZ2FuaXphdGlvbiBo YXMgZGVmaW5lZCBzbyBtYW55IGVuYWJsZXJzIHdoaWNoIGNhbiBydW4gb24gYSBzaW5nbGUgVUEs IEkgZmluZCBpdCB3ZWlyZCB0aGF0IG9uZSBjYW4gZ3VhcmFudGVlIHRoYXQgdGhlIGFib3ZlIGNh bm5vdCBvY2N1ci48YnI+DQo8YnI+DQpUaHVzLCBJIGhlc2l0YXRlIHRvIG1hbmRhdGUgYW4gdW5u ZWNlc3NhcnkgcmVxdWlyZW1lbnQgaW5mbHVlbmNpbmcgcG9zc2libGUgZXhpc3RpbmcgVUEgaW1w bGVtZW50YXRpb25zIGFuZCBJIHByZWZlciB0byBiZSBleHBsaWNpdCBvbiB0aGUgZXhjZXB0aW9u IGZvciB1c2FnZSBvZiBHUlVVIGluIENvbnRhY3Qgb2YgSU5WSVRFIHJlcXVlc3Q6PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IEEgVUEgdGhhdCB3aWxsIGFjY2VwdCBh IFJFRkVSIHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZTxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBh IEdSVVUgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mIGFsbCBJTlZJVEUgcmVxdWVzdHMu Jm5ic3A7IFRoaXM8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgZW5zdXJlcyB0aGF0IG91dC1vZi1k aWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9uZGluZyB0byBhbnk8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsgcmVzdWx0aW5nIElOVklURSBkaWFsb2dzIGFycml2ZSBhdCB0aGlzIFVBLiAmZ3Q7 Jmd0OyZndDtVQXMgdGhhdCB3aWxsIG5vdCBhY2NlcHQgYW55IG91dC1vZi1kaWFsb2cgUkVGRVIg cmVxdWVzdHMgY29ycmVzcG9uZGluZyB0byBkaWFsb2cocykgY3JlYXRlZCBieSBhbiBJTlZJVEUg cmVxdWVzdDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBhcmUgZXhlbXB0ZWQgZnJvbSBpbmNsdWRp bmcgYSBHUlVVIGluIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBvZiB0aGUgSU5WSVRFIHJlcXVl c3QuJmx0OyZsdDsmbHQ7PGJyPg0KPGJyPg0KS2luZCByZWdhcmRzPGJyPg0KPGJyPg0KSXZvIFNl ZGxhY2VrPGJyPg0KPGJyPg0KPGJyPg0KRnJvbTogUm9iZXJ0IFNwYXJrcyBbPGEgaHJlZj0ibWFp bHRvOnJqc3BhcmtzQG5vc3RydW0uY29tIj5tYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb208L2E+ XTxicj4NClNlbnQ6IDMwLiA/ZXJ2ZW5jZSAyMDE0IDE4OjU0PGJyPg0KVG86IEFuZHJldyBBbGxl bjsgQWRhbSBSb2FjaDsgSXZvIFNlZGxhY2VrOyBzaXBjb3JlQGlldGYub3JnJmx0OzxhIGhyZWY9 Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5tYWlsdG86c2lwY29yZUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItY2xhcmlmaWNhdGlvbnMtMDMudHh0PGJy Pg0KPGJyPg0KPGJyPg0KT24gNy8zMC8xNCwgMTA6MzMgQU0sIEFuZHJldyBBbGxlbiB3cm90ZTo8 YnI+DQpJIGhhdmUgYSBnZW5lcmFsIGNvbmNlcm4gd2l0aCB0aGUgZGlyZWN0aW9uIHRoaXMgaXMg bm93IGdvaW5nLjxicj4NCkkgZG9uJ3QgdGhpbmsgeW91IGhhdmUgdGhlIGJhY2t3YXJkcy1jb21w YXRpYmlsaXR5IGNvbmNlcm4gcXVpdGUgcmlnaHQsIGJ1dCBJIGFncmVlIHRoYXQgdGhlIGN1cnJl bnQgd29yZGluZyBpc24ndCB0aGVyZSB5ZXQuPGJyPg0KPGJyPg0KQXJlIHdlIG5vdyBzYXlpbmcg aGVyZSB0aGF0IGl0P3MgT0sgZm9yIGEgVUEgdGhhdCBzdXBwb3J0cyByZWNlaXZpbmcgUkVGRVIg dG8gYXJiaXRyYXJpbHkgcmVqZWN0IGFueSBSRUZFUiB0aGF0IHdvdWxkIGNyZWF0ZSBhIHN1YnNj cmlwdGlvbiAoaS5lIGJlIGluY29tcGF0aWJsZSB3aXRoIFJGQyAzNTE1IFVBQ3MgYnkgYmFzaWNh bGx5IG5vdCBzdXBwb3J0aW5nIFJGQyAzNTE1IFVBUyBjb21wbGlhbnQgYmVoYXZpb3IpPzxicj4N Ck5vLCBfdGhpc18gZG9jdW1lbnQgaXMgbm90IGRlZmluaW5nIG5ldyBiZWhhdmlvci4gSXQncyBv bmx5IGNsYXJpZnlpbmcgd2hhdCdzIGFscmVhZHkgZGVmaW5lZC48YnI+DQo8YnI+DQo8YnI+DQpB Y2NvcmRpbmcgdG8gUkZDIDM1MTU8YnI+DQo8YnI+DQoyLjQuNCBVc2luZyBTSVAgRXZlbnRzIHRv IFJlcG9ydCB0aGUgUmVzdWx0cyBvZiB0aGUgUmVmZXJlbmNlPGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBOT1RJRlkgbWVjaGFuaXNtIGRlZmluZWQgaW4g WzJdIE1VU1QgYmUgdXNlZCB0byBpbmZvcm0gdGhlIGFnZW50IHNlbmRpbmcgdGhlIFJFRkVSIG9m IHRoZSBzdGF0dXMgb2YgdGhlIHJlZmVyZW5jZS48YnI+DQo8YnI+DQpUaGVyZWZvcmUgdGhlIGFi aWxpdHkgdG8gY3JlYXRlIGFuIGltcGxpY2l0IHN1YnNjcmlwdGlvbiB3aGVuIGFjY2VwdGluZzxi cj4NCkZXSVcsIEFjY2VwdGluZyBpcyB0aGUga2V5IHdvcmQgaGVyZS48YnI+DQphIFJFRkVSIGlz IG1hbmRhdG9yeSBiZWhhdmlvciBpbiBSRkMgMzUxNSBhbmQgaXMgZXhwZWN0ZWQgdG8gYmUgc3Vw cG9ydGVkIGJ5IGFsbCBSRkMgMzUxNSBVQUNzPGJyPg0KPGJyPg0KSSB0aGluayBiZWZvcmUgYWdy ZWVpbmcgYW55IHdvcmRpbmcgaGVyZSB3ZSBzaG91bGQgaGF2ZSBhIGdlbmVyYWwgZGlzY3Vzc2lv biBvbiB0aGUgcHJpbmNpcGxlIG9mIHdoZXRoZXIgdGhlc2UgZXh0ZW5zaW9ucyB0aGF0IGFsbG93 IFVBQ3MgdG8gcmVxdWVzdCB0aGF0IG5vIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBjYW4gYmUgZWZm ZWN0aXZlbHkgcmVxdWlyZWQgYnkgUkVGRVIgVUFTIHRvIGJlIHN1cHBvcnRlZCBhdCB0aGUgVUFD Ljxicj4NClRoaXMsIGFuZCB3aGF0IHlvdSBoYXZlIGJlbG93LCBpcyBhIGRpc2N1c3Npb24gd2Ug ZGVmaW5pdGVseSBuZWVkIHRvIGhhdmUgYXMgcGFydCBvZiB0aGUgZXh0ZW5zaW9uIGRvY3VtZW50 Ljxicj4NCkl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gd2FpdCBmb3IgdGhhdCBkaXNjdXNzaW9uIHRv IGNvbXBsZXRlIHRoZSBjbGFyaWZpY2F0aW9ucyBkb2N1bWVudCB0aGF0IHRhbGtzIGFib3V0IHdo YXQgdGhlIHNwZWNzIHNheSBfbm93Xy48YnI+DQo8YnI+DQpNeSBkaXNjb21mb3J0IHdpdGggdGhl IGN1cnJlbnQgdGV4dCBpcyB0aGF0IHdlJ3ZlIG1hZGUgaXQgY29tcGxleCB0byBtYWtlIGl0IHNv IHRoYXQgd2UgZG9uJ3QgaGF2ZSB0byB1cGRhdGUgdGhlIGRvY3VtZW50IG9uY2UgdGhlIHByb3Bv c2VkIGV4dGVuc2lvbnMgZXhpc3QuPGJyPg0KVGhlcmUgYXJlIE5PIGN1cnJlbnRseSBzdGFuZGFy ZGl6ZWQgY2FzZXMgd2hlcmUgdGhlIGV4ZW1wdGlvbiBpbiB0aGUgY3VycmVudCB0ZXh0IHdvdWxk IGJlIGludm9rZWQsIGFuZCBJIGRvbid0IHRoaW5rIHBlb3BsZSBhcmUgdHJ5aW5nIHRvIGFyZ3Vl IHRoZXJlIGFyZSAtIEknbSBoZWFyaW5nIHRoYXQgdG8gZ2V0IHRoZXJlLCB0aGV5IGV4cGVjdCB0 byBpbnZva2UgdGhlIHlldC10by1iZS1kZWZpbmVkIGV4dGVuc2lvbi48YnI+DQo8YnI+DQpTbywg bGV0cyBnbyBiYWNrIHRvIHRoZSBzbGlnaHRseSBsb25nZXIgc2VudGVuY2UgdGhhdCBsZWQgdG8g dGhpczo8YnI+DQo8YnI+DQpBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBzdWJzY3JpcHRpb24tY3Jl YXRpbmcgUkVGRVIgcmVxdWVzdCBuZWVkcyB0byBpbmNsdWRlPGJyPg0KYSBHUlVVIGFzIHRoZSBD b250YWN0IGluIGFsbCBJTlZJVEUgcmVxdWVzdHMgdG8gZW5zdXJlIG91dC1vZi1kaWFsb2cgUkVG RVIgcmVxdWVzdHM8YnI+DQpyZWxhdGVkIHRvIGFueSBkaWFsb2cgY3JlYXRlZCBieSB0aGUgSU5W SVRFIGFycml2ZSBhdCB0aGlzIFVBLjxicj4NCjxicj4NCkluIGFuIGF0dGVtcHQgdG8gYmUgZnV0 dXJlLXByb29mLCB0aGF0J3MgaW50cm9kdWNpbmcgdGhlIHBvdGVudGlhbCBmb3IgY29uZnVzaW9u IGFib3V0IHdoYXQgdGhlIGN1cnJlbnQgc3RhbmRhcmRzIGRlZmluZS48YnI+DQpMZXQncyByZW1v dmUgdGhhdCBjb25mdXNpb24uPGJyPg0KSGVyZSdzIGEgcHJvcG9zZWQgcmVwbGFjZW1lbnQsIHRh a2luZyBBZGFtJ3Mgc2VudGVuY2Ugc2ltcGxpZmljYXRpb24gaW50byBhY2NvdW50Ojxicj4NCjxi cj4NCiZuYnNwOyZuYnNwOyBBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBSRUZFUiByZXF1ZXN0IG5l ZWRzIHRvIGluY2x1ZGU8YnI+DQombmJzcDsmbmJzcDsgYSBHUlVVIGluIHRoZSBDb250YWN0IGhl YWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiZuYnNwOyBUaGlzPGJyPg0KJm5ic3A7 Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3Bv bmRpbmcgdG8gYW55PGJyPg0KJm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUgZGlhbG9ncyBh cnJpdmUgYXQgdGhpcyBVQS4gRnV0dXJlIGV4dGVuc2lvbnM8YnI+DQombmJzcDsmbmJzcDsgW2Ry YWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0c3ViXSBtaWdodCByZWxheCB0aGlzIHJl cXVpcmVtZW50PGJyPg0KJm5ic3A7Jm5ic3A7IGJ5IGRlZmluaW5nIGEgUkVGRVIgcmVxdWVzdCB0 aGF0IGNhbm5vdCBjcmVhdGUgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uLjxicj4NCjxicj4NCjxi cj4NClVubGVzcyBJIGhlYXIgb2JqZWN0aW9uIHNvb24sIEknbGwgcmV2IHRoZSBkcmFmdCB3aXRo IHRoYXQgY29udGVudC48YnI+DQo8YnI+DQo8YnI+DQpJZiBzbyB0aGVuIEkgdGhpbmsgd2Ugd2ls bCBuZWVkIGEgbmV3IHNpcCBvcHRpb25zIHRhZyAoZS5nIFJFRkVSLU5PU1VCKSB0byBiZSB1c2Vk IGluIHBsYWNlIG9mIHRoZSBSRUZFUiBvcHRpb25zIHRhZyBzbyB0aGF0IGEgUkZDIDM1MTUgY29t cGxpYW50IFVBIHRoYXQgZXhwZWN0cyBhIE5PVElGWSB0byBiZSBzZW50IHVwb24gcmVjZWlwdCBv ZiBhIFJFRkVSIGFuZCB0aGF0IGluY2x1ZGVzIGFuIEFjY2VwdC1Db250YWN0IHJlcXVlc3QgdG8g cmVhY2ggYSBVQSB0aGF0IHN1cHBvcnRzIFJFRkVSIGRvZXNuP3QgZW5kIHVwIGF0IGEgVUFTIHRo YXQgZG9lc24/dCZuYnNwOyBzdXBwb3J0IGNvbXBsaWFudCBSRkMgMzUxNSBiZWhhdmlvciBhbmQg ZW5kcyB1cCBoYXZpbmcgaXRzIFJFRkVSIHJlcXVlc3RzIHJlamVjdGVkLjxicj4NCjxicj4NCk15 IG93biB2aWV3IGlzIHRoYXQgd2Ugc2hvdWxkIGtlZXAgd2l0aCB0aGUgcHJpbmNpcGxlIG9mIGJh Y2t3YXJkIGNvbXBhdGliaWxpdHkgYW5kIHRoYXQgZXZlbiB3aGVuIHRoZXNlIG5vIGF1dG9tYXRp YyBzdWJzY3JpcHRpb24gZXh0ZW5zaW9ucyBhcmUgc3VwcG9ydGVkIHRoYXQgZnVsbCBzdXBwb3J0 IGZvciBSRkMgMzUxNSBiZWhhdmlvciBpcyBjb250aW51ZWQuPGJyPg0KPGJyPg0KQW5kcmV3PGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KRnJvbTogc2lwY29yZSBbPGEgaHJlZj0i bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBBZGFtIFJvYWNoPGJyPg0KU2VudDogVHVlc2RheSwg SnVseSAyOSwgMjAxNCAxMToxOSBBTTxicj4NClRvOiBJdm8gU2VkbGFjZWs7IFJvYmVydCBTcGFy a3M7IHNpcGNvcmVAaWV0Zi5vcmcmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmci Pm1haWx0bzpzaXBjb3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTogW3NpcGNv cmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFya3Mtc2lwY29y ZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wMy50eHQ8YnI+DQo8YnI+DQpPbiA3LzI5LzE0IDA5OjUy LCBJdm8gU2VkbGFjZWsgd3JvdGU6PGJyPg0KPGJyPg0KVGh1cywgdGhlIHRleHQgc2hvdWxkIHN0 YXRlOjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBJbiBnZW5lcmFsLCBVQXMgdGhhdCBz dXBwb3J0IHJlY2VpdmluZyAmZ3Q7Jmd0O2FuZCBhY2NlcHRpbmcgYW4gb3V0LW9mLWRpYWxvZyZs dDsmbHQ7IFJFRkVSIHJlcXVlc3QgJmd0OyZndDtjb3JyZXNwb25kaW5nIHRvIGEgZGlhbG9nIGVz dGFibGlzaGVkIGJ5IGFuIElOVklURSByZXF1ZXN0Jmx0OyZsdDsgbmVlZCB0byBpbmNsdWRlPGJy Pg0KJm5ic3A7Jm5ic3A7IGEgR1JVVSBpbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQgb2YgJmd0 OyZndDt0aGUmbHQ7Jmx0OyBJTlZJVEUgcmVxdWVzdC4mbmJzcDsgVGhpczxicj4NCiZuYnNwOyZu YnNwOyBlbnN1cmVzIHRoYXQgb3V0LW9mLWRpYWxvZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25k aW5nIHRvIGFueTxicj4NCiZuYnNwOyZuYnNwOyByZXN1bHRpbmcgSU5WSVRFIGRpYWxvZ3MgYXJl IHJvdXRlZCB0byB0aGUgY29ycmVjdCB1c2VyIGFnZW50LiZuYnNwOyBVQXM8YnI+DQombmJzcDsm bmJzcDsgdGhhdCB3aWxsIG5ldmVyIGNyZWF0ZSBhIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBpbiBy ZXNwb25zZSB0byBhIFJFRkVSPGJyPg0KJm5ic3A7Jm5ic3A7ICh0aGF0IGlzLCB0aG9zZSB0aGF0 IHdpbGwgcmVqZWN0IGFueSBSRUZFUiB0aGF0IG1pZ2h0IHJlc3VsdCBpbiBhbjxicj4NCiZuYnNw OyZuYnNwOyBpbXBsaWNpdCBzdWJzY3JpcHRpb24pIGFyZSBleGVtcHRlZCBmcm9tIHRoaXMgYmVo YXZpb3IuPGJyPg0KPGJyPg0KSSBoZWxwZWQgd2l0aCB0aGUgcGhyYXNpbmcgaGVyZSwgYW5kIG9u ZSBvZiB0aGUgZ29hbHMgaGVyZSB3YXMgdG8gbWFrZSB0aGUgZmlyc3Qgc2VudGVuY2UgY292ZXIg dGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlIGNhc2VzIChoZW5jZSAiaW4gZ2VuZXJhbCIpLCB3aXRo IHRoZSBleGNlcHRpb25hbCBjYXNlcyBkZXNjcmliZWQgbGF0ZXIuIFRoZSBwcm9ibGVtIHdhcyB0 aGF0IHRoZSBvdmVyYWxsIGNvbmNlcHQgd2FzIGdldHRpbmcgbG9zdCBpbiBhIG1hemUgb2YgdHdp c3R5IGNsYXVzZXM6IHRoZSBjbGFyaWZpY2F0aW9uIGhhZCBiZWNvbWUgd29yc2UgdGhhbiB0aGUg c291cmNlIHRleHQ7IGl0IHdhcyBhY3R1YWxseSBtb3JlIGNvbmZ1c2luZy48YnI+DQo8YnI+DQpZ b3VyIHByb3Bvc2FsIHJldHVybnMgaXQgdG8gdGhpcyB2ZXJ5IGNvbmZ1c2luZyBzdGF0ZSwgYW5k IGlzIHdheSwgd2F5IG91dCBpbnRvIHRoZSByZWFsbSBvZiBleGNlcHRpb25hbCBjYXNlcy48YnI+ DQo8YnI+DQpTbyBJJ2xsIGNvdW50ZXJwcm9wb3NlOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBJ biBnZW5lcmFsLCBVQXMgdGhhdCBzdXBwb3J0IHJlY2VpdmluZyBSRUZFUiByZXF1ZXN0cyBuZWVk IHRvIGluY2x1ZGU8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgYSBHUlVVIGluIHRoZSBDb250YWN0 IGhlYWRlciBmaWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiZuYnNwOyBUaGlzPGJyPg0KPGJy Pg0KJm5ic3A7Jm5ic3A7IGVuc3VyZXMgdGhhdCBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3Rz IGNvcnJlc3BvbmRpbmcgdG8gYW55PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJ TlZJVEUgZGlhbG9ncyBhcmUgcm91dGVkIHRvIHRoZSBjb3JyZWN0IHVzZXIgYWdlbnQuJm5ic3A7 IFVBczxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyB0aGF0IHdpbGwgbm90IGNyZWF0ZSBhIGltcGxp Y2l0IHN1YnNjcmlwdGlvbiBpbiByZXNwb25zZSB0byBhIFJFRkVSPGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7IGZvciB0aGUgcmVzdWx0aW5nIGRpYWxvZyhzKSAtLSB0aGF0IGlzLCB0aG9zZSB0aGF0 IHdpbGwgcmVqZWN0IGE8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgY29ycmVzcG9uZGluZyBSRUZF UiB0aGF0IG1pZ2h0IHJlc3VsdCBpbiBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gLS08YnI+DQo8 YnI+DQombmJzcDsmbmJzcDsgYXJlIGV4ZW1wdGVkIGZyb20gdGhpcyBiZWhhdmlvci48YnI+DQo8 YnI+DQovYTxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAt LS0tLS0tLS0tLS0tLTxicj4NCkFuIEhUTUwgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi48YnI+ DQpVUkw6ICZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv c2lwY29yZS9hdHRhY2htZW50cy8yMDE0MDgxMi84NDY1OWExMC9hdHRhY2htZW50Lmh0bWwiPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3JlL2F0dGFjaG1lbnRzLzIw MTQwODEyLzg0NjU5YTEwL2F0dGFjaG1lbnQuaHRtbDwvYT4mZ3Q7PGJyPg0KPGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KU3ViamVjdDogRGlnZXN0IEZvb3Rl cjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+PGJyPg0KPGJy Pg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KRW5kIG9m IHNpcGNvcmUgRGlnZXN0LCBWb2wgNjUsIElzc3VlIDY8YnI+DQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKjxicj48L2ZvbnQ+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E8A0C2E2F1560648B0FF20D8B91638C502C74C8132FHDP1LUMXC7V1_-- From nobody Tue Aug 12 07:38:50 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0261F1A08F3 for ; Tue, 12 Aug 2014 07:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1da9CjkWdCHn for ; Tue, 12 Aug 2014 07:38:46 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B68A1A08F1 for ; Tue, 12 Aug 2014 07:38:46 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so12703392pde.37 for ; Tue, 12 Aug 2014 07:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=pWCF6ox5F2qasMduU5RP0yx188weOLnZyY4klIsutRs=; b=V44a1ObEvXh1KK5w7OiEpHlSbjr0JIWDHoliqQWgGzJxExZxIa3rFB00Jdo0qr95dj X3yOuLnByOAr9gikY7MpkuljZW19Q7QX0ZKgKGrnQy8o4lK/vITMcgFms8h1KfyYCn4e nzv8WT0YDuWcA6sbKl+vvV7IxoreBBs6OvT+hINvGYhwDFh3ClrvYdxrkpZzd5puDPty 9xMcmKMNP3H1uTgUO15BswBWi0Mh01XnSYQmYT/jVIXMss16JDwOeHs/iOtOEgyxrxAl zXguoHnmUEkEUJaCWyXiU4xSYUJUYKRWLfvh/HuyCDvKFx9AtekVfG+4v7/qVxWmsKZX EBew== X-Received: by 10.66.246.229 with SMTP id xz5mr4681520pac.119.1407854326176; Tue, 12 Aug 2014 07:38:46 -0700 (PDT) Received: from gmail.com (softbank126001169004.bbtec.net. [126.1.169.4]) by mx.google.com with ESMTPSA id uw4sm13626790pab.40.2014.08.12.07.38.44 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Aug 2014 07:38:45 -0700 (PDT) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Tue, 12 Aug 2014 23:38:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.24 (WinNT,601) In-Reply-To: <53D6CC3D.4000005@nostrum.com> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> Message-Id: <47CFB63B20505Cietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/CKsV-ygKv6mpe6jFBkb20Qq08gg Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 14:38:48 -0000 Hi, I have another question. If 6665 compliant UAS receives a REFER request within an existing dialog that would create an implicit subscription, how should the UAS handle the REFER request? Regards, Shinji > Adam and I spent some time today editing to account for the discussion. >We believe we covered all the concerns raised. > >The sentence in section 3 was getting a bit complex, so we split it up into >several. >Here's what it was before splitting it up: > >A UA that will accept a subscription-creating REFER request needs to include >a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER >requests >related to any dialog created by the INVITE arrive at this UA. > >You can see what it turned into by looking in the draft. > >RjS > > >-------- Original Message -------- Subject: New Version Notification for >draft-sparks-sipcore-refer-clarifications-03.txt > Date: Mon, 28 Jul 2014 15:16:04 -0700 > From: [a:mailto:internet-drafts@ietf.org]internet-drafts@ietf.org > To: Robert Sparks [a:mailto:rjs@nostrum.com], "Adam Roach" >[a:mailto:adam@nostrum.com], Adam Roach [a:mailto: >adam@nostrum.com], "Robert Sparks" [a:mailto:RjS@nostrum. >com] > > >A new version of I-D, draft-sparks-sipcore-refer-clarifications-03.txt >has been successfully submitted by Robert Sparks and posted to the >IETF repository. > >Name: draft-sparks-sipcore-refer-clarifications >Revision: 03 >Title: Clarifications for the use of REFER with RFC6665 >Document date: 2014-07-28 >Group: Individual Submission >Pages: 4 >URL: [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-03.txt]http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-clarifications-03.txt >Status: [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/]https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/ >Htmlized: [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-03]http://tools.ietf.org/html/draft-sparks-sipcore-refer-clarifications-03 >Diff: [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-03]http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-clarifications-03 > >Abstract: > An accepted SIP REFER method creates an implicit subscription using > the SIP-Specific Event Notification Framework. That framework was > revised by RFC6665. This document highlights the implications of the > requirement changes in RFC6665, and updates the definition of the > REFER method, RFC3515, to clarify and disambiguate the impact of > those changes. > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat From nobody Tue Aug 12 07:59:39 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681C91A0917 for ; Tue, 12 Aug 2014 07:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF2V6nlHFD_Z for ; Tue, 12 Aug 2014 07:59:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96141A0914 for ; Tue, 12 Aug 2014 07:59:32 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7CExOp1089230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Tue, 12 Aug 2014 09:59:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53EA2BCC.2080306@nostrum.com> Date: Tue, 12 Aug 2014 09:59:24 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ivo Sedlacek , Andrew Allen , Adam Roach , "sipcore@ietf.org" References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------060902000507080802010908" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/R5CE2ADRl4Sir0ohS2XxZfFbj7Y Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 14:59:36 -0000 This is a multi-part message in MIME format. --------------060902000507080802010908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit So, I think we're getting closer to the disconnect. Your posited UA is going to reject out-of-dialog refers (at least in the context of a given dialog). Is it going to reject all refers? If so, 3515 (updated by 6665) doesn't apply to its behavior during this dialog. So, I'm assuming you are specifically interested in the case where it accepts in-dialog refers. If your UA provided a GRUU when it started the dialog, and the far end is satisfying the requirements of 6665, it would not send you an in-dialog REFER. It would be violating a MUST NOT to do so. If your UA did not provide a GRUU, it is (in the context of this dialog) not satisfying the requirements of 6665. It's acting like a pre-6665 implementation, at least in the context of that dialog. If the far end is 6665 compliant, it has the option (as specified in 6665 section 4.5.2) to fall back to dialog-reuse. I think this, perhaps, is what you're trying to get the text to reflect. If the far end is not 6665 compliant, it's effectively two old implementations talking to each other and this document doesn't apply. The text you're proposing (if I've got it right) is trying to say "this UA is not using 6665 in the context of this dialog". As long as it is behaving that way, this document does not apply, and the tension comes from trying to talk about such things in this document. I also don't think you're really concerned about UAs that will decide, when sending an INVITE request, that they're going to be 6665 compliant on some and not some others. Let me know if I'm wrong - we need to have a different conversation than what's below. Rather, I suspect you're concerned about a population of pre-6665 UAs that always won't. The more interesting question is what 6665 capable UAs do when _accepting_ offered INVITE dialogs where the peer has not provided a GRUU. If they are 6665 compliant, they have the fallbacks available to them from section 4.5.2 on accepting in dialog subscriptions, but 6665 should discuss whether they should provide a GRUU for their local contact in response to the INVITE, and it should explicitly talk about all subscriptions in either direction falling under 5.4.2. That's a job for the update to RFC 6665 that Adam has signed up for, not this document. What this document _can_ do is speak more concretely and correctly in terms of things that the document applies to. The changes will touch a couple of the paragraphs in section 4, and I think trying to follow the diffs in email is going to get dicey, so I'll drop a revision of the draft with them so rfcdiff can help. RjS On 8/12/14, 3:52 AM, Ivo Sedlacek wrote: > > (extended with my answer on the question and the proposed draft text) > > Hello, > > There still seems to be misunderstanding. Let me state my issue in a > different and more general way: > > If: > > - a UE supports receiving and accepting of out-of-dialog REFER request > related to dialogs created by _some (but not all)_ INVITE requests; and > > - for _a particular INVITE request_, the UA rejects any out-of-dialog > REFERs related to dialogs created by the particular INVITE request; > > should the UE be still mandated to put GRUU in the Contact of _the > particular INVITE request_? If so, what will the GRUU be used for? > > Please note that the question above focuses solely on out-of-dialog > REFERs. > > IMO, answer to the questions above is: > > The UE should not be mandated to put GRUU in Contact of the > _particular INVITE request_, since any out-of-dialog REFER request > related to any dialog created by the _particular INVITE request_is > rejected. Thus, the GRUU does not provide any value. > > Therefore, the draft should state: > > ----------------------- > > A UA that will accept a subscription-creating REFER request >>related > to a dialog of an INVITE request<< needs to include > > a GRUU as the Contact in >>the<< INVITE request to ensure > out-of-dialog REFER requests > > related to any dialog created by the INVITE >>request<< arrive at this UA. > > ----------------------- > > Kind regards > > Ivo Sedlacek > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 7. srpna 2014 19:55 > *To:* Ivo Sedlacek; Andrew Allen; Adam Roach; sipcore@ietf.org > > *Subject:* Re: [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-clarifications-03.txt > > I've spent quite some time trying to understand the push for the > proposal below, and I really think there's confusion, so I'm going to > try to step up a level and see if we can make progress there. > > A UA such as your proposed exception clause describes is simply not a > compliant 6665 implementation which is what this clarification > document is about. > If it accepts in-dialog subscription creating REFERs it is following > 3265, not 6665 - further it is violating a 6665 requirement. > If it accepts no REFERs whatsoever, then it's not affected by this > document. > > If the point of the wordsmithing is to make legacy implementations > compliant with 6665, there's no way to succeed - they simply aren't. > > If that's not the point of the wordsmithing, what is? > > At the moment, I think what I sent below is still the right path forward. > > RjS > > > On 8/1/14, 1:44 AM, Ivo Sedlacek wrote: > > Any comments on the proposal below? > > Kind regards > > Ivo Sedlacek > > If a REFER request is accepted (that is, a 2xx class response is > > returned), the recipient MUST create a subscription and send > > notifications of the status of the refer as described in Section > > 2.4.4.*From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf > Of *Ivo Sedlacek > *Sent:* 31. července 2014 9:26 > *To:* Robert Sparks; Andrew Allen; Adam Roach; sipcore@ietf.org > > *Subject:* Re: [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-clarifications-03.txt > > Hello, > > According to the draft, the purpose of GRUU in Contact of INVITE > request to " > ensures that out-of-dialog REFER requests corresponding to any > resulting INVITE dialogs arrive at this UA." > > If a UA rejects any out-of-dialog REFER requests corresponding to > any dialogs related to an INVITE request, then setting up GRUU in > Contact of INVITE does not provide any purpose. > > This is true __regardless__ whether the UA supports and use the > draft-sparks-sipcore-refer-explicitsub. > > See attached mail giving an example of UA having two types of > sessions, Type_A transferrable by REFER, and Type_B not > transferrable by REFER. > > Given that different standardization organization has defined so > many enablers which can run on a single UA, I find it weird that > one can guarantee that the above cannot occur. > > Thus, I hesitate to mandate an unnecessary requirement influencing > possible existing UA implementations and I prefer to be explicit > on the exception for usage of GRUU in Contact of INVITE request: > > > > A UA that will accept a REFER request needs to include > > a GRUU in the Contact header field of all INVITE requests. This > > ensures that out-of-dialog REFER requests corresponding to any > > resulting INVITE dialogs arrive at this UA.>>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request > > are exempted from including a GRUU in the Contact header field of the INVITE request.<<< > > Kind regards > > Ivo Sedlacek > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 30. července 2014 18:54 > *To:* Andrew Allen; Adam Roach; Ivo Sedlacek; sipcore@ietf.org > > *Subject:* Re: [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-clarifications-03.txt > > On 7/30/14, 10:33 AM, Andrew Allen wrote: > > I have a general concern with the direction this is now going. > > I don't think you have the backwards-compatibility concern quite > right, but I agree that the current wording isn't there yet. > > Are we now saying here that it’s OK for a UA that supports > receiving REFER to arbitrarily reject any REFER that would create > a subscription (i.e be incompatible with RFC 3515 UACs by > basically not supporting RFC 3515 UAS compliant behavior)? > > No, _this_ document is not defining new behavior. It's only > clarifying what's already defined. > > According to RFC 3515 > > 2.4.4 Using SIP Events to Report the Results of the Reference > > The NOTIFY mechanism defined in [2] MUST be used to > inform the agent sending the REFER of the status of the reference. > > Therefore the ability to create an implicit subscription when > accepting > > FWIW, Accepting is the key word here. > > a REFER is mandatory behavior in RFC 3515 and is expected to be > supported by all RFC 3515 UACs > > I think before agreeing any wording here we should have a general > discussion on the principle of whether these extensions that allow > UACs to request that no implicit subscription can be effectively > required by REFER UAS to be supported at the UAC. > > This, and what you have below, is a discussion we definitely need > to have as part of the extension document. > It is not necessary to wait for that discussion to complete the > clarifications document that talks about what the specs say _now_. > > My discomfort with the current text is that we've made it complex > to make it so that we don't have to update the document once the > proposed extensions exist. > There are NO currently standardized cases where the exemption in > the current text would be invoked, and I don't think people are > trying to argue there are - I'm hearing that to get there, they > expect to invoke the yet-to-be-defined extension. > > So, lets go back to the slightly longer sentence that led to this: > > A UA that will accept a subscription-creating REFER request needs > to include > a GRUU as the Contact in all INVITE requests to ensure > out-of-dialog REFER requests > related to any dialog created by the INVITE arrive at this UA. > > In an attempt to be future-proof, that's introducing the potential > for confusion about what the current standards define. > Let's remove that confusion. > Here's a proposed replacement, taking Adam's sentence > simplification into account: > > A UA that will accept a REFER request needs to include > a GRUU in the Contact header field of all INVITE requests. This > ensures that out-of-dialog REFER requests corresponding to any > resulting INVITE dialogs arrive at this UA. Future extensions > [draft-sparks-sipcore-refer-explicitsub] might relax this > requirement > by defining a REFER request that cannot create an implicit > subscription. > > > Unless I hear objection soon, I'll rev the draft with that content. > > If so then I think we will need a new sip options tag (e.g > REFER-NOSUB) to be used in place of the REFER options tag so that > a RFC 3515 compliant UA that expects a NOTIFY to be sent upon > receipt of a REFER and that includes an Accept-Contact request to > reach a UA that supports REFER doesn’t end up at a UAS that > doesn’t support compliant RFC 3515 behavior and ends up having > its REFER requests rejected. > > My own view is that we should keep with the principle of backward > compatibility and that even when these no automatic subscription > extensions are supported that full support for RFC 3515 behavior > is continued. > > Andrew > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of > *Adam Roach > *Sent:* Tuesday, July 29, 2014 11:19 AM > *To:* Ivo Sedlacek; Robert Sparks; sipcore@ietf.org > > *Subject:* Re: [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-clarifications-03.txt > > On 7/29/14 09:52, Ivo Sedlacek wrote: > > Thus, the text should state: > > In general, UAs that support receiving >>and accepting an > out-of-dialog<< REFER request >>corresponding to a dialog > established by an INVITE request<< need to include > > a GRUU in the Contact header field of >>the<< INVITE > request. This > > ensures that out-of-dialog REFER requests corresponding to any > > resulting INVITE dialogs are routed to the correct user > agent. UAs > > that will never create a implicit subscription in response > to a REFER > > (that is, those that will reject any REFER that might > result in an > > implicit subscription) are exempted from this behavior. > > > I helped with the phrasing here, and one of the goals here was to > make the first sentence cover the vast majority of the cases > (hence "in general"), with the exceptional cases described later. > The problem was that the overall concept was getting lost in a > maze of twisty clauses: the clarification had become worse than > the source text; it was actually more confusing. > > Your proposal returns it to this very confusing state, and is way, > way out into the realm of exceptional cases. > > So I'll counterpropose: > > In general, UAs that support receiving REFER requests need to include > > a GRUU in the Contact header field of all INVITE requests. This > > ensures that out-of-dialog REFER requests corresponding to any > > resulting INVITE dialogs are routed to the correct user agent. UAs > > that will not create a implicit subscription in response to a REFER > > for the resulting dialog(s) -- that is, those that will reject a > > corresponding REFER that might result in an implicit subscription -- > > are exempted from this behavior. > > > /a > --------------060902000507080802010908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit So, I think we're getting closer to the disconnect.

Your posited UA is going to reject out-of-dialog refers (at least in the context of a given dialog).
Is it going to reject all refers? If so, 3515 (updated by 6665) doesn't apply to its behavior during this dialog.
So, I'm assuming you are specifically interested in the case where it accepts in-dialog refers.

If your UA provided a GRUU when it started the dialog, and the far end is satisfying the requirements of 6665, it would not send you an in-dialog REFER. It would be violating a MUST NOT to do so.

If your UA did not provide a GRUU, it is (in the context of this dialog) not satisfying the requirements of 6665. It's acting like a pre-6665 implementation, at least in the context of that dialog. If the far end is 6665 compliant, it has the option (as specified in 6665 section 4.5.2) to fall back to dialog-reuse. I think this, perhaps, is what you're trying to get the text to reflect.

If the far end is not 6665 compliant, it's effectively two old implementations talking to each other and this document doesn't apply.

The text you're proposing (if I've got it right) is trying to say "this UA is not using 6665 in the context of this dialog".
As long as it is behaving that way, this document does not apply, and the tension comes from trying to talk about such things in this document.

I also don't think you're really concerned about UAs that will decide, when sending an INVITE request, that they're going to be 6665 compliant on some and not some others. Let me know if I'm wrong - we need to have a different conversation than what's below.

Rather, I suspect you're concerned about a population of pre-6665 UAs that always won't. The more interesting question is what 6665 capable UAs do when _accepting_ offered INVITE dialogs where the peer has not provided a GRUU. If they are 6665 compliant, they have the fallbacks available to them from section 4.5.2 on accepting in dialog subscriptions, but 6665 should discuss whether they should provide a GRUU for their local contact in response to the INVITE, and it should explicitly talk about all subscriptions in either direction falling under 5.4.2. That's a job for the update to RFC 6665 that Adam has signed up for, not this document.

What this document _can_ do is speak more concretely and correctly in terms of things that the document applies to. 
The changes will touch a couple of the paragraphs in section 4, and I think trying to follow the diffs in email is going to get dicey, so I'll drop a revision of the draft with them so rfcdiff can help.

RjS

On 8/12/14, 3:52 AM, Ivo Sedlacek wrote:

(extended with my answer on the question and the proposed draft text)

 

Hello,

 

There still seems to be misunderstanding. Let me state my issue in a different and more general way:

 

If:

- a UE supports receiving and accepting of out-of-dialog REFER request related to dialogs created by some (but not all) INVITE requests; and

- for a particular INVITE request, the UA rejects any out-of-dialog REFERs related to dialogs created by the particular INVITE request;

should the UE be still mandated to put GRUU in the Contact of the particular INVITE request? If so, what will the GRUU be used for?

 

Please note that the question above focuses solely on out-of-dialog REFERs.

 

 

 

IMO, answer to the questions above is:

 

            The UE should not be mandated to put GRUU in Contact of the particular INVITE request, since any out-of-dialog REFER request related to any dialog created by the particular INVITE request is rejected. Thus, the GRUU does not provide any value.

 

Therefore, the draft should state:

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

A UA that will accept a subscription-creating REFER request >>related to a dialog of an INVITE request<< needs to include

a GRUU as the Contact in >>the<< INVITE request to ensure out-of-dialog REFER requests

related to any dialog created by the INVITE >>request<< arrive at this UA.

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

 

Kind regards

 

Ivo Sedlacek

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 7. srpna 2014 19:55
To: Ivo Sedlacek; Andrew Allen; Adam Roach; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

I've spent quite some time trying to understand the push for the proposal below, and I really think there's confusion, so I'm going to try to step up a level and see if we can make progress there.

A UA such as your proposed exception clause describes is simply not a compliant 6665 implementation which is what this clarification document is about.
If it accepts in-dialog subscription creating REFERs it is following 3265, not 6665 - further it is violating a 6665 requirement.
If it accepts no REFERs whatsoever, then it's not affected by this document.

If the point of the wordsmithing is to make legacy implementations compliant with 6665, there's no way to succeed - they simply aren't.

If that's not the point of the wordsmithing, what is?

At the moment, I think what I sent below is still the right path forward.

RjS


On 8/1/14, 1:44 AM, Ivo Sedlacek wrote:

Any comments on the proposal below?

 

Kind regards

 

Ivo Sedlacek

 

 

   If a REFER request is accepted (that is, a 2xx class response is

   returned), the recipient MUST create a subscription and send

   notifications of the status of the refer as described in Section

   2.4.4.From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek
Sent: 31. července 2014 9:26
To: Robert Sparks; Andrew Allen; Adam Roach; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

Hello,

 

According to the draft, the purpose of GRUU in Contact of INVITE request to "
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA."

 

If a UA rejects any out-of-dialog REFER requests corresponding to any dialogs related to an INVITE request, then setting up GRUU in Contact of INVITE does not provide any purpose.

 

This is true __regardless__ whether the UA supports and use the draft-sparks-sipcore-refer-explicitsub.

See attached mail giving an example of UA having two types of sessions, Type_A transferrable by REFER, and Type_B not transferrable by REFER.

Given that different standardization organization has defined so many enablers which can run on a single UA, I find it weird that one can guarantee that the above cannot occur.

 

Thus, I hesitate to mandate an unnecessary requirement influencing possible existing UA implementations and I prefer to be explicit on the exception for usage of GRUU in Contact of INVITE request:

 

 
   A UA that will accept a REFER request needs to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA. >>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request
   are exempted from including a GRUU in the Contact header field of the INVITE request.<<<

 

Kind regards

 

Ivo Sedlacek

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 30. července 2014 18:54
To: Andrew Allen; Adam Roach; Ivo Sedlacek; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

 

On 7/30/14, 10:33 AM, Andrew Allen wrote:

I have a general concern with the direction this is now going.

I don't think you have the backwards-compatibility concern quite right, but I agree that the current wording isn't there yet.

 

Are we now saying here that it’s OK for a UA that supports receiving REFER to arbitrarily reject any REFER that would create a subscription (i.e be incompatible with RFC 3515 UACs by basically not supporting RFC 3515 UAS compliant behavior)?

No, _this_ document is not defining new behavior. It's only clarifying what's already defined.

 

According to RFC 3515

 

2.4.4 Using SIP Events to Report the Results of the Reference

 

                The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference.

 

Therefore the ability to create an implicit subscription when accepting

FWIW, Accepting is the key word here.

a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all RFC 3515 UACs

 

I think before agreeing any wording here we should have a general discussion on the principle of whether these extensions that allow UACs to request that no implicit subscription can be effectively required by REFER UAS to be supported at the UAC.

This, and what you have below, is a discussion we definitely need to have as part of the extension document.
It is not necessary to wait for that discussion to complete the clarifications document that talks about what the specs say _now_.

My discomfort with the current text is that we've made it complex to make it so that we don't have to update the document once the proposed extensions exist.
There are NO currently standardized cases where the exemption in the current text would be invoked, and I don't think people are trying to argue there are - I'm hearing that to get there, they expect to invoke the yet-to-be-defined extension.

So, lets go back to the slightly longer sentence that led to this:

A UA that will accept a subscription-creating REFER request needs to include
a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER requests
related to any dialog created by the INVITE arrive at this UA.

In an attempt to be future-proof, that's introducing the potential for confusion about what the current standards define.
Let's remove that confusion.
Here's a proposed replacement, taking Adam's sentence simplification into account:

   A UA that will accept a REFER request needs to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA. Future extensions
   [draft-sparks-sipcore-refer-explicitsub] might relax this requirement
   by defining a REFER request that cannot create an implicit subscription.


Unless I hear objection soon, I'll rev the draft with that content.

 

If so then I think we will need a new sip options tag (e.g REFER-NOSUB) to be used in place of the REFER options tag so that a RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of a REFER and that includes an Accept-Contact request to reach a UA that supports REFER doesn’t end up at a UAS that doesn’t  support compliant RFC 3515 behavior and ends up having its REFER requests rejected.

 

My own view is that we should keep with the principle of backward compatibility and that even when these no automatic subscription extensions are supported that full support for RFC 3515 behavior is continued.

 

Andrew

 

 

 

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Tuesday, July 29, 2014 11:19 AM
To: Ivo Sedlacek; Robert Sparks; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

On 7/29/14 09:52, Ivo Sedlacek wrote:

 

Thus, the text should state:

 

 

   In general, UAs that support receiving >>and accepting an out-of-dialog<< REFER request >>corresponding to a dialog established by an INVITE request<< need to include

   a GRUU in the Contact header field of >>the<< INVITE request.  This

   ensures that out-of-dialog REFER requests corresponding to any

   resulting INVITE dialogs are routed to the correct user agent.  UAs

   that will never create a implicit subscription in response to a REFER

   (that is, those that will reject any REFER that might result in an

   implicit subscription) are exempted from this behavior.


I helped with the phrasing here, and one of the goals here was to make the first sentence cover the vast majority of the cases (hence "in general"), with the exceptional cases described later. The problem was that the overall concept was getting lost in a maze of twisty clauses: the clarification had become worse than the source text; it was actually more confusing.

Your proposal returns it to this very confusing state, and is way, way out into the realm of exceptional cases.

So I'll counterpropose:

   In general, UAs that support receiving REFER requests need to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs are routed to the correct user agent.  UAs
   that will not create a implicit subscription in response to a REFER
   for the resulting dialog(s) -- that is, those that will reject a
   corresponding REFER that might result in an implicit subscription --
   are exempted from this behavior.


/a

 

 

 


--------------060902000507080802010908-- From nobody Tue Aug 12 10:38:43 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4629A1A0368 for ; Tue, 12 Aug 2014 10:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdh7b1nvFJ0A for ; Tue, 12 Aug 2014 10:38:36 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id E0B601A0362 for ; Tue, 12 Aug 2014 10:38:35 -0700 (PDT) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Aug 2014 13:38:33 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 13:38:32 -0400 From: Andrew Allen To: "ietf.shinji@gmail.com" , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPqrHlmnmUsyWPWkiMyO8iEueSdZvNY+mA///vK58= Date: Tue, 12 Aug 2014 17:38:31 +0000 Message-ID: In-Reply-To: <47CFB63B20505Cietf.shinji@gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3nHPOlMCORZJXzO9JDnJEZqAEAI Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 17:38:42 -0000 I think that's clear. The RFC 6665 UAC acts as per RFC 3515. See RFC 6665 = 4.2.1 ----- Original Message ----- From: OKUMURA Shinji [mailto:ietf.shinji@gmail.com] Sent: Tuesday, August 12, 2014 10:38 AM Eastern Standard Time=0A= To: sipcore@ietf.org Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipco= re-refer-clarifications-03.txt Hi, I have another question. If 6665 compliant UAS receives a REFER request within an existing dialog that would create an implicit subscription, how should the UAS handle the REFER request? Regards, Shinji > Adam and I spent some time today editing to account for the discussion. >We believe we covered all the concerns raised. > >The sentence in section 3 was getting a bit complex, so we split it up int= o=20 >several. >Here's what it was before splitting it up: > >A UA that will accept a subscription-creating REFER request needs to inclu= de >a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER= =20 >requests >related to any dialog created by the INVITE arrive at this UA. > >You can see what it turned into by looking in the draft. > >RjS > > >-------- Original Message -------- Subject: New Version Notification for=20 >draft-sparks-sipcore-refer-clarifications-03.txt > Date: Mon, 28 Jul 2014 15:16:04 -0700 > From: [a:mailto:internet-drafts@ietf.org]internet-drafts@ietf.org > To: Robert Sparks [a:mailto:rjs@nostrum.com], "Adam Roac= h"=20 >[a:mailto:adam@nostrum.com], Adam Roach [a:mailto: >adam@nostrum.com], "Robert Sparks" [a:mailto:RjS@nostrum= . >com] > > >A new version of I-D, draft-sparks-sipcore-refer-clarifications-03.txt >has been successfully submitted by Robert Sparks and posted to the >IETF repository. > >Name: draft-sparks-sipcore-refer-clarifications >Revision: 03 >Title: Clarifications for the use of REFER with RFC6665 >Document date: 2014-07-28 >Group: Individual Submission >Pages: 4 >URL: [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcor= e-refer-clarifications-03.txt]http://www.ietf.org/internet-drafts/draft-spa= rks-sipcore-refer-clarifications-03.txt >Status: [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore-r= efer-clarifications/]https://datatracker.ietf.org/doc/draft-sparks-sipcore-= refer-clarifications/ >Htmlized: [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer-c= larifications-03]http://tools.ietf.org/html/draft-sparks-sipcore-refer-clar= ifications-03 >Diff: [a:http://www.ietf.org/rfcdiff?url2=3Ddraft-sparks-sipcore= -refer-clarifications-03]http://www.ietf.org/rfcdiff?url2=3Ddraft-sparks-si= pcore-refer-clarifications-03 > >Abstract: > An accepted SIP REFER method creates an implicit subscription using > the SIP-Specific Event Notification Framework. That framework was > revised by RFC6665. This document highlights the implications of the > requirement changes in RFC6665, and updates the definition of the > REFER method, RFC3515, to clarify and disambiguate the impact of > those changes. > >Please note that it may take a couple of minutes from the time of submissi= on >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Aug 12 10:52:56 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4011A04FA for ; Tue, 12 Aug 2014 10:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88GA0VpL9FrI for ; Tue, 12 Aug 2014 10:52:46 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 90C011A04D2 for ; Tue, 12 Aug 2014 10:52:46 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Aug 2014 13:52:45 -0400 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 12 Aug 2014 13:52:45 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 13:52:45 -0400 From: Andrew Allen To: "ietf.shinji@gmail.com" , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPqrHlmnmUsyWPWkiMyO8iEueSdZvNY+mA///vK5+AAAP5pw== Date: Tue, 12 Aug 2014 17:52:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/VBUDJzCD9zH69FLJY3hEEIEpNr4 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 17:52:49 -0000 I meant UAS not UAC ----- Original Message ----- From: Andrew Allen [mailto:aallen@blackberry.com] Sent: Tuesday, August 12, 2014 01:38 PM Eastern Standard Time=0A= To: ietf.shinji@gmail.com ; sipcore@ietf.org Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipco= re-refer-clarifications-03.txt I think that's clear. The RFC 6665 UAC acts as per RFC 3515. See RFC 6665 = 4.2.1 ----- Original Message ----- From: OKUMURA Shinji [mailto:ietf.shinji@gmail.com] Sent: Tuesday, August 12, 2014 10:38 AM Eastern Standard Time To: sipcore@ietf.org Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipco= re-refer-clarifications-03.txt Hi, I have another question. If 6665 compliant UAS receives a REFER request within an existing dialog that would create an implicit subscription, how should the UAS handle the REFER request? Regards, Shinji > Adam and I spent some time today editing to account for the discussion. >We believe we covered all the concerns raised. > >The sentence in section 3 was getting a bit complex, so we split it up int= o=20 >several. >Here's what it was before splitting it up: > >A UA that will accept a subscription-creating REFER request needs to inclu= de >a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER= =20 >requests >related to any dialog created by the INVITE arrive at this UA. > >You can see what it turned into by looking in the draft. > >RjS > > >-------- Original Message -------- Subject: New Version Notification for=20 >draft-sparks-sipcore-refer-clarifications-03.txt > Date: Mon, 28 Jul 2014 15:16:04 -0700 > From: [a:mailto:internet-drafts@ietf.org]internet-drafts@ietf.org > To: Robert Sparks [a:mailto:rjs@nostrum.com], "Adam Roac= h"=20 >[a:mailto:adam@nostrum.com], Adam Roach [a:mailto: >adam@nostrum.com], "Robert Sparks" [a:mailto:RjS@nostrum= . >com] > > >A new version of I-D, draft-sparks-sipcore-refer-clarifications-03.txt >has been successfully submitted by Robert Sparks and posted to the >IETF repository. > >Name: draft-sparks-sipcore-refer-clarifications >Revision: 03 >Title: Clarifications for the use of REFER with RFC6665 >Document date: 2014-07-28 >Group: Individual Submission >Pages: 4 >URL: [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcor= e-refer-clarifications-03.txt]http://www.ietf.org/internet-drafts/draft-spa= rks-sipcore-refer-clarifications-03.txt >Status: [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore-r= efer-clarifications/]https://datatracker.ietf.org/doc/draft-sparks-sipcore-= refer-clarifications/ >Htmlized: [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer-c= larifications-03]http://tools.ietf.org/html/draft-sparks-sipcore-refer-clar= ifications-03 >Diff: [a:http://www.ietf.org/rfcdiff?url2=3Ddraft-sparks-sipcore= -refer-clarifications-03]http://www.ietf.org/rfcdiff?url2=3Ddraft-sparks-si= pcore-refer-clarifications-03 > >Abstract: > An accepted SIP REFER method creates an implicit subscription using > the SIP-Specific Event Notification Framework. That framework was > revised by RFC6665. This document highlights the implications of the > requirement changes in RFC6665, and updates the definition of the > REFER method, RFC3515, to clarify and disambiguate the impact of > those changes. > >Please note that it may take a couple of minutes from the time of submissi= on >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat _______________________________________________ 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 nobody Tue Aug 12 12:19:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF5B1A06D7 for ; Tue, 12 Aug 2014 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y0Gwx11qvPd for ; Tue, 12 Aug 2014 12:19:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFE81A0661 for ; Tue, 12 Aug 2014 12:19:08 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7CJJ6HT011456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Tue, 12 Aug 2014 14:19:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53EA68AA.7060108@nostrum.com> Date: Tue, 12 Aug 2014 14:19:06 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> In-Reply-To: <53EA2BCC.2080306@nostrum.com> Content-Type: multipart/alternative; boundary="------------020208000603000102080100" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/h4ZquuKNM0P4r4kW125ZyHRUFbc Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 19:19:15 -0000 This is a multi-part message in MIME format. --------------020208000603000102080100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The rev is up, and the diff is available at On 8/12/14, 9:59 AM, Robert Sparks wrote: > So, I think we're getting closer to the disconnect. > > Your posited UA is going to reject out-of-dialog refers (at least in > the context of a given dialog). > Is it going to reject all refers? If so, 3515 (updated by 6665) > doesn't apply to its behavior during this dialog. > So, I'm assuming you are specifically interested in the case where it > accepts in-dialog refers. > > If your UA provided a GRUU when it started the dialog, and the far end > is satisfying the requirements of 6665, it would not send you an > in-dialog REFER. It would be violating a MUST NOT to do so. > > If your UA did not provide a GRUU, it is (in the context of this > dialog) not satisfying the requirements of 6665. It's acting like a > pre-6665 implementation, at least in the context of that dialog. If > the far end is 6665 compliant, it has the option (as specified in 6665 > section 4.5.2) to fall back to dialog-reuse. I think this, perhaps, is > what you're trying to get the text to reflect. > > If the far end is not 6665 compliant, it's effectively two old > implementations talking to each other and this document doesn't apply. > > The text you're proposing (if I've got it right) is trying to say > "this UA is not using 6665 in the context of this dialog". > As long as it is behaving that way, this document does not apply, and > the tension comes from trying to talk about such things in this document. > > I also don't think you're really concerned about UAs that will decide, > when sending an INVITE request, that they're going to be 6665 > compliant on some and not some others. Let me know if I'm wrong - we > need to have a different conversation than what's below. > > Rather, I suspect you're concerned about a population of pre-6665 UAs > that always won't. The more interesting question is what 6665 capable > UAs do when _accepting_ offered INVITE dialogs where the peer has not > provided a GRUU. If they are 6665 compliant, they have the fallbacks > available to them from section 4.5.2 on accepting in dialog > subscriptions, but 6665 should discuss whether they should provide a > GRUU for their local contact in response to the INVITE, and it should > explicitly talk about all subscriptions in either direction falling > under 5.4.2. That's a job for the update to RFC 6665 that Adam has > signed up for, not this document. > > What this document _can_ do is speak more concretely and correctly in > terms of things that the document applies to. > The changes will touch a couple of the paragraphs in section 4, and I > think trying to follow the diffs in email is going to get dicey, so > I'll drop a revision of the draft with them so rfcdiff can help. > > RjS > > On 8/12/14, 3:52 AM, Ivo Sedlacek wrote: >> >> (extended with my answer on the question and the proposed draft text) >> >> Hello, >> >> There still seems to be misunderstanding. Let me state my issue in a >> different and more general way: >> >> If: >> >> - a UE supports receiving and accepting of out-of-dialog REFER >> request related to dialogs created by _some (but not all)_ INVITE >> requests; and >> >> - for _a particular INVITE request_, the UA rejects any out-of-dialog >> REFERs related to dialogs created by the particular INVITE request; >> >> should the UE be still mandated to put GRUU in the Contact of _the >> particular INVITE request_? If so, what will the GRUU be used for? >> >> Please note that the question above focuses solely on out-of-dialog >> REFERs. >> >> IMO, answer to the questions above is: >> >> The UE should not be mandated to put GRUU in Contact of the >> _particular INVITE request_, since any out-of-dialog REFER request >> related to any dialog created by the _particular INVITE request_is >> rejected. Thus, the GRUU does not provide any value. >> >> Therefore, the draft should state: >> >> ----------------------- >> >> A UA that will accept a subscription-creating REFER request >>related >> to a dialog of an INVITE request<< needs to include >> >> a GRUU as the Contact in >>the<< INVITE request to ensure >> out-of-dialog REFER requests >> >> related to any dialog created by the INVITE >>request<< arrive at >> this UA. >> >> ----------------------- >> >> Kind regards >> >> Ivo Sedlacek >> >> *From:*Robert Sparks [mailto:rjsparks@nostrum.com] >> *Sent:* 7. srpna 2014 19:55 >> *To:* Ivo Sedlacek; Andrew Allen; Adam Roach; sipcore@ietf.org >> >> *Subject:* Re: [sipcore] Fwd: New Version Notification for >> draft-sparks-sipcore-refer-clarifications-03.txt >> >> I've spent quite some time trying to understand the push for the >> proposal below, and I really think there's confusion, so I'm going to >> try to step up a level and see if we can make progress there. >> >> A UA such as your proposed exception clause describes is simply not a >> compliant 6665 implementation which is what this clarification >> document is about. >> If it accepts in-dialog subscription creating REFERs it is following >> 3265, not 6665 - further it is violating a 6665 requirement. >> If it accepts no REFERs whatsoever, then it's not affected by this >> document. >> >> If the point of the wordsmithing is to make legacy implementations >> compliant with 6665, there's no way to succeed - they simply aren't. >> >> If that's not the point of the wordsmithing, what is? >> >> At the moment, I think what I sent below is still the right path forward. >> >> RjS >> >> >> On 8/1/14, 1:44 AM, Ivo Sedlacek wrote: >> >> Any comments on the proposal below? >> >> Kind regards >> >> Ivo Sedlacek >> >> If a REFER request is accepted (that is, a 2xx class response is >> >> returned), the recipient MUST create a subscription and send >> >> notifications of the status of the refer as described in Section >> >> 2.4.4.*From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf >> Of *Ivo Sedlacek >> *Sent:* 31. c(ervence 2014 9:26 >> *To:* Robert Sparks; Andrew Allen; Adam Roach; sipcore@ietf.org >> >> *Subject:* Re: [sipcore] Fwd: New Version Notification for >> draft-sparks-sipcore-refer-clarifications-03.txt >> >> Hello, >> >> According to the draft, the purpose of GRUU in Contact of INVITE >> request to " >> ensures that out-of-dialog REFER requests corresponding to any >> resulting INVITE dialogs arrive at this UA." >> >> If a UA rejects any out-of-dialog REFER requests corresponding to >> any dialogs related to an INVITE request, then setting up GRUU in >> Contact of INVITE does not provide any purpose. >> >> This is true __regardless__ whether the UA supports and use the >> draft-sparks-sipcore-refer-explicitsub. >> >> See attached mail giving an example of UA having two types of >> sessions, Type_A transferrable by REFER, and Type_B not >> transferrable by REFER. >> >> Given that different standardization organization has defined so >> many enablers which can run on a single UA, I find it weird that >> one can guarantee that the above cannot occur. >> >> Thus, I hesitate to mandate an unnecessary requirement >> influencing possible existing UA implementations and I prefer to >> be explicit on the exception for usage of GRUU in Contact of >> INVITE request: >> >> >> >> A UA that will accept a REFER request needs to include >> >> a GRUU in the Contact header field of all INVITE requests. This >> >> ensures that out-of-dialog REFER requests corresponding to any >> >> resulting INVITE dialogs arrive at this UA.>>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request >> >> are exempted from including a GRUU in the Contact header field of the INVITE request.<<< >> >> Kind regards >> >> Ivo Sedlacek >> >> *From:*Robert Sparks [mailto:rjsparks@nostrum.com] >> *Sent:* 30. c(ervence 2014 18:54 >> *To:* Andrew Allen; Adam Roach; Ivo Sedlacek; sipcore@ietf.org >> >> *Subject:* Re: [sipcore] Fwd: New Version Notification for >> draft-sparks-sipcore-refer-clarifications-03.txt >> >> On 7/30/14, 10:33 AM, Andrew Allen wrote: >> >> I have a general concern with the direction this is now going. >> >> I don't think you have the backwards-compatibility concern quite >> right, but I agree that the current wording isn't there yet. >> >> Are we now saying here that it's OK for a UA that supports >> receiving REFER to arbitrarily reject any REFER that would create >> a subscription (i.e be incompatible with RFC 3515 UACs by >> basically not supporting RFC 3515 UAS compliant behavior)? >> >> No, _this_ document is not defining new behavior. It's only >> clarifying what's already defined. >> >> According to RFC 3515 >> >> 2.4.4 Using SIP Events to Report the Results of the Reference >> >> The NOTIFY mechanism defined in [2] MUST be used to >> inform the agent sending the REFER of the status of the reference. >> >> Therefore the ability to create an implicit subscription when >> accepting >> >> FWIW, Accepting is the key word here. >> >> a REFER is mandatory behavior in RFC 3515 and is expected to be >> supported by all RFC 3515 UACs >> >> I think before agreeing any wording here we should have a general >> discussion on the principle of whether these extensions that >> allow UACs to request that no implicit subscription can be >> effectively required by REFER UAS to be supported at the UAC. >> >> This, and what you have below, is a discussion we definitely need >> to have as part of the extension document. >> It is not necessary to wait for that discussion to complete the >> clarifications document that talks about what the specs say _now_. >> >> My discomfort with the current text is that we've made it complex >> to make it so that we don't have to update the document once the >> proposed extensions exist. >> There are NO currently standardized cases where the exemption in >> the current text would be invoked, and I don't think people are >> trying to argue there are - I'm hearing that to get there, they >> expect to invoke the yet-to-be-defined extension. >> >> So, lets go back to the slightly longer sentence that led to this: >> >> A UA that will accept a subscription-creating REFER request needs >> to include >> a GRUU as the Contact in all INVITE requests to ensure >> out-of-dialog REFER requests >> related to any dialog created by the INVITE arrive at this UA. >> >> In an attempt to be future-proof, that's introducing the >> potential for confusion about what the current standards define. >> Let's remove that confusion. >> Here's a proposed replacement, taking Adam's sentence >> simplification into account: >> >> A UA that will accept a REFER request needs to include >> a GRUU in the Contact header field of all INVITE requests. This >> ensures that out-of-dialog REFER requests corresponding to any >> resulting INVITE dialogs arrive at this UA. Future extensions >> [draft-sparks-sipcore-refer-explicitsub] might relax this >> requirement >> by defining a REFER request that cannot create an implicit >> subscription. >> >> >> Unless I hear objection soon, I'll rev the draft with that content. >> >> If so then I think we will need a new sip options tag (e.g >> REFER-NOSUB) to be used in place of the REFER options tag so that >> a RFC 3515 compliant UA that expects a NOTIFY to be sent upon >> receipt of a REFER and that includes an Accept-Contact request to >> reach a UA that supports REFER doesn't end up at a UAS that >> doesn't support compliant RFC 3515 behavior and ends up having >> its REFER requests rejected. >> >> My own view is that we should keep with the principle of backward >> compatibility and that even when these no automatic subscription >> extensions are supported that full support for RFC 3515 behavior >> is continued. >> >> Andrew >> >> *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of >> *Adam Roach >> *Sent:* Tuesday, July 29, 2014 11:19 AM >> *To:* Ivo Sedlacek; Robert Sparks; sipcore@ietf.org >> >> *Subject:* Re: [sipcore] Fwd: New Version Notification for >> draft-sparks-sipcore-refer-clarifications-03.txt >> >> On 7/29/14 09:52, Ivo Sedlacek wrote: >> >> Thus, the text should state: >> >> In general, UAs that support receiving >>and accepting an >> out-of-dialog<< REFER request >>corresponding to a dialog >> established by an INVITE request<< need to include >> >> a GRUU in the Contact header field of >>the<< INVITE >> request. This >> >> ensures that out-of-dialog REFER requests corresponding to any >> >> resulting INVITE dialogs are routed to the correct user >> agent. UAs >> >> that will never create a implicit subscription in response >> to a REFER >> >> (that is, those that will reject any REFER that might >> result in an >> >> implicit subscription) are exempted from this behavior. >> >> >> I helped with the phrasing here, and one of the goals here was to >> make the first sentence cover the vast majority of the cases >> (hence "in general"), with the exceptional cases described later. >> The problem was that the overall concept was getting lost in a >> maze of twisty clauses: the clarification had become worse than >> the source text; it was actually more confusing. >> >> Your proposal returns it to this very confusing state, and is >> way, way out into the realm of exceptional cases. >> >> So I'll counterpropose: >> >> In general, UAs that support receiving REFER requests need to include >> >> a GRUU in the Contact header field of all INVITE requests. This >> >> ensures that out-of-dialog REFER requests corresponding to any >> >> resulting INVITE dialogs are routed to the correct user agent. UAs >> >> that will not create a implicit subscription in response to a REFER >> >> for the resulting dialog(s) -- that is, those that will reject a >> >> corresponding REFER that might result in an implicit subscription -- >> >> are exempted from this behavior. >> >> >> /a >> > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------020208000603000102080100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The rev is up, and the diff is available at
<http://www.ietf.org/rfcdiff?url1=draft-sparks-sipcore-refer-clarifications-03&difftype=--html&submit=Go!&url2=draft-sparks-sipcore-refer-clarifications-04>

On 8/12/14, 9:59 AM, Robert Sparks wrote:
So, I think we're getting closer to the disconnect.

Your posited UA is going to reject out-of-dialog refers (at least in the context of a given dialog).
Is it going to reject all refers? If so, 3515 (updated by 6665) doesn't apply to its behavior during this dialog.
So, I'm assuming you are specifically interested in the case where it accepts in-dialog refers.

If your UA provided a GRUU when it started the dialog, and the far end is satisfying the requirements of 6665, it would not send you an in-dialog REFER. It would be violating a MUST NOT to do so.

If your UA did not provide a GRUU, it is (in the context of this dialog) not satisfying the requirements of 6665. It's acting like a pre-6665 implementation, at least in the context of that dialog. If the far end is 6665 compliant, it has the option (as specified in 6665 section 4.5.2) to fall back to dialog-reuse. I think this, perhaps, is what you're trying to get the text to reflect.

If the far end is not 6665 compliant, it's effectively two old implementations talking to each other and this document doesn't apply.

The text you're proposing (if I've got it right) is trying to say "this UA is not using 6665 in the context of this dialog".
As long as it is behaving that way, this document does not apply, and the tension comes from trying to talk about such things in this document.

I also don't think you're really concerned about UAs that will decide, when sending an INVITE request, that they're going to be 6665 compliant on some and not some others. Let me know if I'm wrong - we need to have a different conversation than what's below.

Rather, I suspect you're concerned about a population of pre-6665 UAs that always won't. The more interesting question is what 6665 capable UAs do when _accepting_ offered INVITE dialogs where the peer has not provided a GRUU. If they are 6665 compliant, they have the fallbacks available to them from section 4.5.2 on accepting in dialog subscriptions, but 6665 should discuss whether they should provide a GRUU for their local contact in response to the INVITE, and it should explicitly talk about all subscriptions in either direction falling under 5.4.2. That's a job for the update to RFC 6665 that Adam has signed up for, not this document.

What this document _can_ do is speak more concretely and correctly in terms of things that the document applies to. 
The changes will touch a couple of the paragraphs in section 4, and I think trying to follow the diffs in email is going to get dicey, so I'll drop a revision of the draft with them so rfcdiff can help.

RjS

On 8/12/14, 3:52 AM, Ivo Sedlacek wrote:

(extended with my answer on the question and the proposed draft text)

 

Hello,

 

There still seems to be misunderstanding. Let me state my issue in a different and more general way:

 

If:

- a UE supports receiving and accepting of out-of-dialog REFER request related to dialogs created by some (but not all) INVITE requests; and

- for a particular INVITE request, the UA rejects any out-of-dialog REFERs related to dialogs created by the particular INVITE request;

should the UE be still mandated to put GRUU in the Contact of the particular INVITE request? If so, what will the GRUU be used for?

 

Please note that the question above focuses solely on out-of-dialog REFERs.

 

 

 

IMO, answer to the questions above is:

 

            The UE should not be mandated to put GRUU in Contact of the particular INVITE request, since any out-of-dialog REFER request related to any dialog created by the particular INVITE request is rejected. Thus, the GRUU does not provide any value.

 

Therefore, the draft should state:

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

A UA that will accept a subscription-creating REFER request >>related to a dialog of an INVITE request<< needs to include

a GRUU as the Contact in >>the<< INVITE request to ensure out-of-dialog REFER requests

related to any dialog created by the INVITE >>request<< arrive at this UA.

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

 

Kind regards

 

Ivo Sedlacek

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 7. srpna 2014 19:55
To: Ivo Sedlacek; Andrew Allen; Adam Roach; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

I've spent quite some time trying to understand the push for the proposal below, and I really think there's confusion, so I'm going to try to step up a level and see if we can make progress there.

A UA such as your proposed exception clause describes is simply not a compliant 6665 implementation which is what this clarification document is about.
If it accepts in-dialog subscription creating REFERs it is following 3265, not 6665 - further it is violating a 6665 requirement.
If it accepts no REFERs whatsoever, then it's not affected by this document.

If the point of the wordsmithing is to make legacy implementations compliant with 6665, there's no way to succeed - they simply aren't.

If that's not the point of the wordsmithing, what is?

At the moment, I think what I sent below is still the right path forward.

RjS


On 8/1/14, 1:44 AM, Ivo Sedlacek wrote:

Any comments on the proposal below?

 

Kind regards

 

Ivo Sedlacek

 

 

   If a REFER request is accepted (that is, a 2xx class response is

   returned), the recipient MUST create a subscription and send

   notifications of the status of the refer as described in Section

   2.4.4.From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek
Sent: 31. července 2014 9:26
To: Robert Sparks; Andrew Allen; Adam Roach; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

Hello,

 

According to the draft, the purpose of GRUU in Contact of INVITE request to "
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA."

 

If a UA rejects any out-of-dialog REFER requests corresponding to any dialogs related to an INVITE request, then setting up GRUU in Contact of INVITE does not provide any purpose.

 

This is true __regardless__ whether the UA supports and use the draft-sparks-sipcore-refer-explicitsub.

See attached mail giving an example of UA having two types of sessions, Type_A transferrable by REFER, and Type_B not transferrable by REFER.

Given that different standardization organization has defined so many enablers which can run on a single UA, I find it weird that one can guarantee that the above cannot occur.

 

Thus, I hesitate to mandate an unnecessary requirement influencing possible existing UA implementations and I prefer to be explicit on the exception for usage of GRUU in Contact of INVITE request:

 

 
   A UA that will accept a REFER request needs to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA. >>>UAs that will not accept any out-of-dialog REFER requests corresponding to dialog(s) created by an INVITE request
   are exempted from including a GRUU in the Contact header field of the INVITE request.<<<

 

Kind regards

 

Ivo Sedlacek

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 30. července 2014 18:54
To: Andrew Allen; Adam Roach; Ivo Sedlacek; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

 

On 7/30/14, 10:33 AM, Andrew Allen wrote:

I have a general concern with the direction this is now going.

I don't think you have the backwards-compatibility concern quite right, but I agree that the current wording isn't there yet.

 

Are we now saying here that it’s OK for a UA that supports receiving REFER to arbitrarily reject any REFER that would create a subscription (i.e be incompatible with RFC 3515 UACs by basically not supporting RFC 3515 UAS compliant behavior)?

No, _this_ document is not defining new behavior. It's only clarifying what's already defined.

 

According to RFC 3515

 

2.4.4 Using SIP Events to Report the Results of the Reference

 

                The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference.

 

Therefore the ability to create an implicit subscription when accepting

FWIW, Accepting is the key word here.

a REFER is mandatory behavior in RFC 3515 and is expected to be supported by all RFC 3515 UACs

 

I think before agreeing any wording here we should have a general discussion on the principle of whether these extensions that allow UACs to request that no implicit subscription can be effectively required by REFER UAS to be supported at the UAC.

This, and what you have below, is a discussion we definitely need to have as part of the extension document.
It is not necessary to wait for that discussion to complete the clarifications document that talks about what the specs say _now_.

My discomfort with the current text is that we've made it complex to make it so that we don't have to update the document once the proposed extensions exist.
There are NO currently standardized cases where the exemption in the current text would be invoked, and I don't think people are trying to argue there are - I'm hearing that to get there, they expect to invoke the yet-to-be-defined extension.

So, lets go back to the slightly longer sentence that led to this:

A UA that will accept a subscription-creating REFER request needs to include
a GRUU as the Contact in all INVITE requests to ensure out-of-dialog REFER requests
related to any dialog created by the INVITE arrive at this UA.

In an attempt to be future-proof, that's introducing the potential for confusion about what the current standards define.
Let's remove that confusion.
Here's a proposed replacement, taking Adam's sentence simplification into account:

   A UA that will accept a REFER request needs to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs arrive at this UA. Future extensions
   [draft-sparks-sipcore-refer-explicitsub] might relax this requirement
   by defining a REFER request that cannot create an implicit subscription.


Unless I hear objection soon, I'll rev the draft with that content.

 

If so then I think we will need a new sip options tag (e.g REFER-NOSUB) to be used in place of the REFER options tag so that a RFC 3515 compliant UA that expects a NOTIFY to be sent upon receipt of a REFER and that includes an Accept-Contact request to reach a UA that supports REFER doesn’t end up at a UAS that doesn’t  support compliant RFC 3515 behavior and ends up having its REFER requests rejected.

 

My own view is that we should keep with the principle of backward compatibility and that even when these no automatic subscription extensions are supported that full support for RFC 3515 behavior is continued.

 

Andrew

 

 

 

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Tuesday, July 29, 2014 11:19 AM
To: Ivo Sedlacek; Robert Sparks; sipcore@ietf.org
Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt

 

On 7/29/14 09:52, Ivo Sedlacek wrote:

 

Thus, the text should state:

 

 

   In general, UAs that support receiving >>and accepting an out-of-dialog<< REFER request >>corresponding to a dialog established by an INVITE request<< need to include

   a GRUU in the Contact header field of >>the<< INVITE request.  This

   ensures that out-of-dialog REFER requests corresponding to any

   resulting INVITE dialogs are routed to the correct user agent.  UAs

   that will never create a implicit subscription in response to a REFER

   (that is, those that will reject any REFER that might result in an

   implicit subscription) are exempted from this behavior.


I helped with the phrasing here, and one of the goals here was to make the first sentence cover the vast majority of the cases (hence "in general"), with the exceptional cases described later. The problem was that the overall concept was getting lost in a maze of twisty clauses: the clarification had become worse than the source text; it was actually more confusing.

Your proposal returns it to this very confusing state, and is way, way out into the realm of exceptional cases.

So I'll counterpropose:

   In general, UAs that support receiving REFER requests need to include
   a GRUU in the Contact header field of all INVITE requests.  This
   ensures that out-of-dialog REFER requests corresponding to any
   resulting INVITE dialogs are routed to the correct user agent.  UAs
   that will not create a implicit subscription in response to a REFER
   for the resulting dialog(s) -- that is, those that will reject a
   corresponding REFER that might result in an implicit subscription --
   are exempted from this behavior.


/a

 

 

 




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

--------------020208000603000102080100-- From nobody Wed Aug 13 00:25:39 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5F1A7019 for ; Wed, 13 Aug 2014 00:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-oyesF9atwl for ; Wed, 13 Aug 2014 00:25:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE8E1A7017 for ; Wed, 13 Aug 2014 00:25:33 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-ec-53eb12eb4f44 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.CC.24955.BE21BE35; Wed, 13 Aug 2014 09:25:31 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Wed, 13 Aug 2014 09:25:30 +0200 From: Ivo Sedlacek To: Robert Sparks , Andrew Allen , Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPtj4GgjJ5vLajD0ywdOSMoIRL5JvOHkBA Date: Wed, 13 Aug 2014 07:25:30 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> In-Reply-To: <53EA2BCC.2080306@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvje5rodfBBj3LtS3uz9vKaLHn7yJ2 i2tzGtksvv7YxObA4jGrYS27x5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CV8eHgI8aCN9wV B45MZGpgPMLdxcjJISFgIjFz8TpWCFtM4sK99WxdjFwcQgJHGSUafnQzgSSEBJYwSjzbwQdi swnoSUzccoQVpEhEYAajxM//rxlBEsIC2RIrN+wCs0UEciT6P7ewQdhGEjNat4DFWQRUJZ6e ncgOYvMK+ErceLSUCWLbXlaJM0tXgjVwCmhL3J65EGwzo4CsxNU/vWDNzALiEreezGeCOFVA Ysme88wQtqjEy8f/gC7iALIVJZb3y4GYzAKaEut36UN0KkpM6X4ItVZQ4uTMJywTGEVnIRk6 C6FjFpKOWUg6FjCyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjKGDW36r7mC8/MbxEKMA B6MSD+8D2VfBQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB scVrdVItQ2fzvqmRW3OPHzru4zyvTkd88admE38p+Zd7XTWXNtwIk+SavH6JzZJ7fcKbfK+6 XUx4leXwxHZNPY+h7y6my98O6sftsCyXZFh9LWLd9xlLjNed/x7OuER9wr+LAvOWzQw5tLdi qsZ5FccF047uexN7JOzSkh2LLs9bt7Nu2+Ll3opKLMUZiYZazEXFiQBDrGLHggIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/awLmat_Tkr3zJIEMht6sfv-N_Jk Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 07:25:37 -0000 SGVsbG8sDQoNCj4gWW91ciBwb3NpdGVkIFVBIGlzIGdvaW5nIHRvIHJlamVjdCBvdXQtb2YtZGlh bG9nIHJlZmVycyAoYXQgbGVhc3QgaW4gdGhlIGNvbnRleHQgb2YgYSBnaXZlbiBkaWFsb2cpLg0K PiBJcyBpdCBnb2luZyB0byByZWplY3QgYWxsIHJlZmVycz8gDQoNCklmIHlvdSBtZWFudCBSRUZF UnMgcmVsYXRlZCB0byBkaWFsb2dzIGNyZWF0ZWQgYnkgdGhlIHBhcnRpY3VsYXIgSU5WSVRFIHJl cXVlc3QsIHRoZW46DQotIHRoZSBVQSByZWplY3RzIGFueSBvdXQtb2YtZGlhbG9nIFJFRkVScyBy ZWxhdGVkIHRvIGRpYWxvZ3MgY3JlYXRlZCBieSB0aGUgcGFydGljdWxhciBJTlZJVEUgcmVxdWVz dCBhcyBzdGF0ZWQgaW4gdGhlIHF1ZXN0aW9uIGJlbG93OyBhbmQNCi0gdGhlIFVBIGhhbmRsZXMg YW55IGluLWRpYWxvZyBSRUZFUiByZWNlaXZlZCBpbiBhIGRpYWxvZyBjcmVhdGVkIGJ5IHRoZSBw YXJ0aWN1bGFyIElOVklURSByZXF1ZXN0IGFjY29yZGluZyB0byBSRkM2NjY1LiBUaGUgVUEgcmVq ZWN0cyBhbnkgaW4tZGlhbG9nIFJFRkVSIHJlcXVlc3QgdGhhdCB3b3VsZCByZXN1bHQgaW4gYW4g aW1wbGljaXQgc3Vic2NyaXB0aW9uLg0KDQpJZiB5b3UgYWxzbyBtZWFudCBSRUZFUnMgcmVsYXRl ZCB0byBkaWFsb2dzIGNyZWF0ZWQgYnkgb3RoZXIgSU5WSVRFIHJlcXVlc3QsIHRoZW4gVUEgY2Fu IGFjY2VwdCBvciByZWplY3QgdGhlbSB3aXRoaW4gcnVsZXMgZ2l2ZW4gYnkgUkZDNjY2NS4NCg0K PiBJZiB5b3VyIFVBIGRpZCBub3QgcHJvdmlkZSBhIEdSVVUsIGl0IGlzIChpbiB0aGUgY29udGV4 dCBvZiB0aGlzIGRpYWxvZykgbm90IHNhdGlzZnlpbmcgdGhlIHJlcXVpcmVtZW50cyBvZiA2NjY1 LiANCj4gLi4uDQo+IFRoZSB0ZXh0IHlvdSdyZSBwcm9wb3NpbmcgKGlmIEkndmUgZ290IGl0IHJp Z2h0KSBpcyB0cnlpbmcgdG8gc2F5ICJ0aGlzIFVBIGlzIG5vdCB1c2luZyA2NjY1IGluIHRoZSBj b250ZXh0IG9mIHRoaXMgZGlhbG9nIi4NCg0KQ2FuIHlvdSBwbGVhc2UgcXVvdGUgdGhlIFJGQzY2 NjUgcmVxdWlyZW1lbnQgd2hpY2ggdGhlIFVBIGRvZXMgbm90IHNhdGlzZnk/DQoNCktpbmQgcmVn YXJkcw0KDQpJdm8gU2VkbGFjZWsNCg== From nobody Wed Aug 13 04:09:20 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7B21A0825 for ; Wed, 13 Aug 2014 04:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Jhn_Ukb3ACn for ; Wed, 13 Aug 2014 04:09:15 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58311A0792 for ; Wed, 13 Aug 2014 04:09:14 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-79-53eb4758378a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6D.6A.21334.8574BE35; Wed, 13 Aug 2014 13:09:12 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Wed, 13 Aug 2014 13:09:11 +0200 From: Ivo Sedlacek To: Andrew Allen , Robert Sparks , Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPqrHlmnmUsyWPWkiMyO8iEueSdZu3Zw8AgAAHa4CAAU4pgP//+hIAgAEMFKCAAAnd8IABhX7wgAps3oCABytxgIAAGBhggAFzLsA= Date: Wed, 13 Aug 2014 11:09:10 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112711FA7@ESESSMB301.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvjW6E++tgg/+HdCzuz9vKaLHn7yJ2 i2tzGtksvv7YxObA4jGrYS27x5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CV8b95DVvBNNaK 9ovbmRsYW1i7GDk5JARMJDYe+s4EYYtJXLi3ng3EFhI4yijxoMUawl7CKPG0B6yGTUBPYuKW I0C9XBwiAjMYJd693MQCkhAWyJZYuWEXI4gtIpAj0f+5hQ3CLpP4dfM6M4jNIqAqsXdmC1gN r4CvxNdtN1hABgkJTGeV6Lh5HKyIU8BT4uyVr2DNjAKyElf/9II1MAuIS9x6Mh/qUgGJJXvO M0PYohIvH/+D+kZRov1pA1A9B1C9psT6XfoQrYoSU7ofskPsFZQ4OfMJywRG0VlIps5C6JiF pGMWko4FjCyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQJj6OCW37o7GFe/djzEKMDBqMTD +0D2VbAQa2JZcWXuIUZpDhYlcd5F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDk7Pty ds3DpxIZdlE/1zBf//O6olrg7vSkOxssV32Jlfq2vldfa5r7quysoJCTUZsUp6cfD/S/5BQZ +XZFe2zU5CzlWbOZI6av1kib4/SJ7U2uvDvne8vyrSb/+mobFxs2iOfcq9vFvmbBrGf9bsls UgmK3tXzv/xvMBAOD2bNZIvZHF28q0KJpTgj0VCLuag4EQA0IWgzggIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/4BpZbd7T4IaOpAJXSZZxZzBcCu0 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 11:09:17 -0000 PiBXaGF0IHJlYXNvbiB3b3VsZCBhIFVBQyBoYXZlIHN1Y2ggYSByZXN0cmljdGlvbiBmb3Igc29t ZSBhbmQgbm90IG90aGVycz8gDQoNClRoZXJlIGFyZSBhIGxvdCBvZiBTSVAgZW5hYmxlcnMgZGVm aW5lZCBieSBkaWZmZXJlbnQgU0RPcyB3aGljaCB1c2UgSU5WSVRFIHJlcXVlc3QgYW5kIHdoaWNo IGNhbiBiZSBzdXBwb3J0ZWQgaW4gdGhlIHNhbWUgVUEuIA0KDQpXaHkgc2hvdWxkIHRoZSBVRSBi ZSBtYW5kYXRlZCB0byBhY2NlcHQgYSBSRUZFUiByZWxhdGVkIHRvIGEgc2Vzc2lvbiBvZiBldmVy eSBzaW5nbGUgZW5hYmxlcj8NCg0KPiBXaHkgd291bGQgaXQgYmUgYWR2YW50YWdlb3VzIHRvIMKg ZGVjcmVhc2UgaW50ZXJvcGVyYWJpbGl0eSBpbiBzdWNoIHNpdHVhdGlvbnM/DQoNCkV2ZXJ5dGhp bmcgd29ya3Mgc28gdGhlIGludGVyb3BlcmFiaWxpdHkgaXMgbm90IGRlY3JlYXNlZC4NCg0KS2lu ZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0K From nobody Wed Aug 13 07:26:21 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3D91A03D1 for ; Wed, 13 Aug 2014 07:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2h0vdrKQmJP for ; Wed, 13 Aug 2014 07:26:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4387D1A0373 for ; Wed, 13 Aug 2014 07:26:17 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7DEQ6Nb026837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 13 Aug 2014 09:26:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53EB757E.5000601@nostrum.com> Date: Wed, 13 Aug 2014 09:26:06 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ivo Sedlacek , Andrew Allen , Adam Roach , "sipcore@ietf.org" References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/YKzOsrUoZZ4xaxg9IQVFPfAN6UQ Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 14:26:19 -0000 On 8/13/14, 2:25 AM, Ivo Sedlacek wrote: > Hello, > >> Your posited UA is going to reject out-of-dialog refers (at least in the context of a given dialog). >> Is it going to reject all refers? > If you meant REFERs related to dialogs created by the particular INVITE request, then: > - the UA rejects any out-of-dialog REFERs related to dialogs created by the particular INVITE request as stated in the question below; and > - the UA handles any in-dialog REFER received in a dialog created by the particular INVITE request according to RFC6665. The UA rejects any in-dialog REFER request that would result in an implicit subscription. Is this back to norefersub? Is your argument that you can accept the refer because you're the potential notifier and you know you won't take the path of norefersub that would create a subscription? If so, we may have a box around what we need to cover. If not, say more. > > If you also meant REFERs related to dialogs created by other INVITE request, then UA can accept or reject them within rules given by RFC6665. No, I was talking the the context of a given dialog. > >> If your UA did not provide a GRUU, it is (in the context of this dialog) not satisfying the requirements of 6665. >> ... >> The text you're proposing (if I've got it right) is trying to say "this UA is not using 6665 in the context of this dialog". > Can you please quote the RFC6665 requirement which the UA does not satisfy? The first sentence of 4.5.1. The clarification that Adam has signed up for well shine the light on that. If there is any potential for a UA to become a notifier for _any_ event package (not just refer, but think also dialog), it will need to provide a GRUU for any dialog it tries to enter. > > Kind regards > > Ivo Sedlacek From nobody Wed Aug 13 08:03:25 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615B01A0324 for ; Wed, 13 Aug 2014 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ6xfe4l7R_D for ; Wed, 13 Aug 2014 08:03:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0794D1A0750 for ; Wed, 13 Aug 2014 08:03:20 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-60-53eb7e37725d Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.09.21334.73E7BE35; Wed, 13 Aug 2014 17:03:19 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Wed, 13 Aug 2014 17:03:18 +0200 From: Ivo Sedlacek To: Robert Sparks , Andrew Allen , Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPtwKKcpmVO0fqZ0Se6torAo6gG5vOm0cg Date: Wed, 13 Aug 2014 15:03:18 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> In-Reply-To: <53EB757E.5000601@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvja553etgg0szJSzuz9vKaLHn7yJ2 i2tzGtksvv7YxObA4jGrYS27x5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CV0dhnU3BJsuJp 7xG2BsY/El2MnBwSAiYS01/OZIGwxSQu3FvP1sXIxSEkcJRRYtKziUwQzhJGiWtnfrCBVLEJ 6ElM3HKEFSQhIjCDUeLn/9eMIAlhgWyJlRt2gdkiAjkS/Z9b2CBsI4mTC56ArWARUJW48nsx K4jNK+Ar0fCzlRliwyI2icvn1oElOAW0Jc69nsYEYjMKyEpc/dMLNpRZQFzi1pP5TBC3Ckgs 2XOeGcIWlXj5+B8rhK0o0f60AaieA6heU2L9Ln2IVkWJKd0P2SH2CkqcnPmEZQKj6CwkU2ch dMxC0jELSccCRpZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIFRdHDLb90djKtfOx5iFOBg VOLhPRL9OliINbGsuDL3EKM0B4uSOO+ic/OChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDq HX9y5dvXqV+3+vYn7Hqwce/CRv0/ovZ7DIXdZjk5fnhhGCG0bPWfpdl75k1VvqJ3LUz7gvnv e5s7Sm1nzzq9Iy/V+OimTon/vAnMpyWM38+ZfXHVTo5lm62N9DcUHV/pId7jwTTN76L4zdks z1y6hYKce9g/aEwLO7f0QrqDWYNkwmShG/pNSizFGYmGWsxFxYkAp4KanYMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/9lWffCzXzL78p5Y9L9sk0-p1qHg Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 15:03:23 -0000 SGVsbG8sDQoNCj4gPj4gWW91ciBwb3NpdGVkIFVBIGlzIGdvaW5nIHRvIHJlamVjdCBvdXQtb2Yt ZGlhbG9nIHJlZmVycyAoYXQgbGVhc3QgaW4gdGhlIGNvbnRleHQgb2YgYSBnaXZlbiBkaWFsb2cp Lg0KPiA+PiBJcyBpdCBnb2luZyB0byByZWplY3QgYWxsIHJlZmVycz8NCj4gPiBJZiB5b3UgbWVh bnQgUkVGRVJzIHJlbGF0ZWQgdG8gZGlhbG9ncyBjcmVhdGVkIGJ5IHRoZSBwYXJ0aWN1bGFyIElO VklURSByZXF1ZXN0LCB0aGVuOg0KPiA+IC0gdGhlIFVBIHJlamVjdHMgYW55IG91dC1vZi1kaWFs b2cgUkVGRVJzIHJlbGF0ZWQgdG8gZGlhbG9ncyBjcmVhdGVkIA0KPiA+IGJ5IHRoZSBwYXJ0aWN1 bGFyIElOVklURSByZXF1ZXN0IGFzIHN0YXRlZCBpbiB0aGUgcXVlc3Rpb24gYmVsb3c7IGFuZA0K PiA+IC0gdGhlIFVBIGhhbmRsZXMgYW55IGluLWRpYWxvZyBSRUZFUiByZWNlaXZlZCBpbiBhIGRp YWxvZyBjcmVhdGVkIGJ5IHRoZSBwYXJ0aWN1bGFyIElOVklURSByZXF1ZXN0IGFjY29yZGluZyB0 byBSRkM2NjY1LiBUaGUgVUEgcmVqZWN0cyBhbnkgaW4tZGlhbG9nIFJFRkVSIHJlcXVlc3QgdGhh dCB3b3VsZCByZXN1bHQgaW4gYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uLg0KPiBJcyB0aGlzIGJh Y2sgdG8gbm9yZWZlcnN1Yj8gSXMgeW91ciBhcmd1bWVudCB0aGF0IHlvdSBjYW4gYWNjZXB0IHRo ZSByZWZlciBiZWNhdXNlIHlvdSdyZSB0aGUgcG90ZW50aWFsIG5vdGlmaWVyIGFuZCB5b3Uga25v dyB5b3Ugd29uJ3QgdGFrZSB0aGUgcGF0aCBvZiBub3JlZmVyc3ViIHRoYXQgd291bGQgY3JlYXRl IGEgc3Vic2NyaXB0aW9uPyBJZiBzbywgd2UgbWF5IGhhdmUgYSBib3ggYXJvdW5kIHdoYXQgd2Ug bmVlZCB0byBjb3Zlci4gSWYgbm90LCBzYXkgbW9yZS4NCg0KQ291bGQgd2UgZm9jdXMgb24gdGhl IG5leHQgcXVlc3Rpb24gKHdoaWNoIHNlZW1zIHRvIGJlIHRoZSBLRVkgcXVlc3Rpb24pIGFuZCwg YWZ0ZXIgd2Ugc29sdmVkIGl0LCByZXR1cm4gdG8gdGhpcyBvbmU/DQoNCj4gPiBJZiB5b3UgYWxz byBtZWFudCBSRUZFUnMgcmVsYXRlZCB0byBkaWFsb2dzIGNyZWF0ZWQgYnkgb3RoZXIgSU5WSVRF IHJlcXVlc3QsIHRoZW4gVUEgY2FuIGFjY2VwdCBvciByZWplY3QgdGhlbSB3aXRoaW4gcnVsZXMg Z2l2ZW4gYnkgUkZDNjY2NS4NCj4gTm8sIEkgd2FzIHRhbGtpbmcgdGhlIHRoZSBjb250ZXh0IG9m IGEgZ2l2ZW4gZGlhbG9nLg0KPiA+DQo+ID4+IElmIHlvdXIgVUEgZGlkIG5vdCBwcm92aWRlIGEg R1JVVSwgaXQgaXMgKGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZGlhbG9nKSBub3Qgc2F0aXNmeWlu ZyB0aGUgcmVxdWlyZW1lbnRzIG9mIDY2NjUuDQo+ID4+IC4uLg0KPiA+PiBUaGUgdGV4dCB5b3Un cmUgcHJvcG9zaW5nIChpZiBJJ3ZlIGdvdCBpdCByaWdodCkgaXMgdHJ5aW5nIHRvIHNheSAidGhp cyBVQSBpcyBub3QgdXNpbmcgNjY2NSBpbiB0aGUgY29udGV4dCBvZiB0aGlzIGRpYWxvZyIuDQo+ ID4gQ2FuIHlvdSBwbGVhc2UgcXVvdGUgdGhlIFJGQzY2NjUgcmVxdWlyZW1lbnQgd2hpY2ggdGhl IFVBIGRvZXMgbm90IHNhdGlzZnk/DQo+IFRoZSBmaXJzdCBzZW50ZW5jZSBvZiA0LjUuMS4NCj4g VGhlIGNsYXJpZmljYXRpb24gdGhhdCBBZGFtIGhhcyBzaWduZWQgdXAgZm9yIHdlbGwgc2hpbmUg dGhlIGxpZ2h0IG9uIHRoYXQuDQo+IElmIHRoZXJlIGlzIGFueSBwb3RlbnRpYWwgZm9yIGEgVUEg dG8gYmVjb21lIGEgbm90aWZpZXIgZm9yIF9hbnlfIGV2ZW50IHBhY2thZ2UgKG5vdCBqdXN0IHJl ZmVyLCBidXQgdGhpbmsgYWxzbyBkaWFsb2cpLCBpdCB3aWxsIG5lZWQgdG8gcHJvdmlkZSBhIEdS VVUgZm9yIGFueSBkaWFsb2cgaXQgdHJpZXMgdG8gZW50ZXIuDQoNClJGQzY2NjUsIHNlY3Rpb24g NC41LjEsIDFzdCBzZW50ZW5jZSBzdGF0ZXM6ICAgDQoNCglOb3RpZmllcnMgTVVTVCBpbXBsZW1l bnQgdGhlIEdsb2JhbGx5IFJvdXRhYmxlIFVzZXIgQWdlbnQgVVJJIChHUlVVKSBleHRlbnNpb24g ZGVmaW5lZCBpbiBbUkZDNTYyN10sIGFuZCBNVVNUIHVzZSBhIEdSVVUgYXMgdGhlaXIgbG9jYWwg dGFyZ2V0Lg0KDQpJc24ndCBub3RpZmllciBhIHJvbGUgdGFrZW4gaW4gc3Vic2NyaXB0aW9uLCBh cHBsaWNhYmxlIG9ubHkgZm9yIHRoZSBkaWFsb2cgb2YgdGhlIHN1YnNjcmlwdGlvbj8NClRoZSBV QSBkb2VzIG5vdCBhY3QgYXMgbm90aWZpZXIgaW4gdGhlIGRpYWxvZ3MgY3JlYXRlZCBieSB0aGUg cGFydGljdWxhciBJTlZJVEUgcmVxdWVzdC4gDQpUaHVzLCBpbiBteSByZWFkaW5nLCB0aGUgcmVx dWlyZW1lbnQgZG9lcyBub3QgYXBwbHkgZm9yIHRoZSBwYXJ0aWN1bGFyIElOVklURSByZXF1ZXN0 Lg0KT3IgZG8gSSBtaXNzIGFueXRoaW5nPw0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2Vr DQo= From nobody Wed Aug 13 08:27:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A931A0898 for ; Wed, 13 Aug 2014 08:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcRvJm--AUrH for ; Wed, 13 Aug 2014 08:27:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1E11A0891 for ; Wed, 13 Aug 2014 08:27:07 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7DFQxJc089333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Aug 2014 10:27:00 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <53EB83C3.9040807@nostrum.com> Date: Wed, 13 Aug 2014 10:26:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ivo Sedlacek , Robert Sparks , Andrew Allen , "sipcore@ietf.org" References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/J5VCddYjgr1_byzxgEneBDQoyeg Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 15:27:10 -0000 On 8/13/14 10:03, Ivo Sedlacek wrote: > RFC6665, section 4.5.1, 1st sentence states: > > Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target. > > Isn't notifier a role taken in subscription, applicable only for the dialog of the subscription? > The UA does not act as notifier in the dialogs created by the particular INVITE request. > Thus, in my reading, the requirement does not apply for the particular INVITE request. > Or do I miss anything? This is exactly what the document that I'll be producing is going to clarify. For what it's worth, "notifier" is defined in section 2 of 6665, and it's not a role. To the point of the specific section you quote, let's look at the whole paragraph: Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target. This allows subscribers to explicitly target desired devices. Now, take a moment to think really hard about what the second sentence there means. If it's not nonsense or useless noise -- and I assure you that it is not -- then it must be referring to the ability to subscribe to something on a device that the subscriber already knows exists. In order to make that happen, the subscriber must have learned the GRUU some way. How do subscribers learn about GRUUs? It's right there in the first sentence: Notifiers include GRUUs as their local target. We'll come back to this. The use cases that make this interesting are those that involve subscribing to some information about a dialog that you're already in (or were recently in). In fact, not just *any* dialog, but INVITE dialogs. So how does this happen? As I said above: notifers include GRUUs them as their local target. Every time. Including INVITE dialogs. /a From nobody Wed Aug 13 08:37:49 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2101A0888 for ; Wed, 13 Aug 2014 08:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLfZN5UhiXJe for ; Wed, 13 Aug 2014 08:37:46 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B9C1A03C9 for ; Wed, 13 Aug 2014 08:37:45 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-de-53eb864765fe Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.CF.02247.7468BE35; Wed, 13 Aug 2014 17:37:43 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Wed, 13 Aug 2014 17:37:43 +0200 From: Ivo Sedlacek To: Adam Roach , Robert Sparks , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPtwsL3JlwkIP6hUuX4EPDKhNeHJvOqJzw Date: Wed, 13 Aug 2014 15:37:43 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127122B0@ESESSMB301.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> <53EB83C3.9040807@nostrum.com> In-Reply-To: <53EB83C3.9040807@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvja572+tgg4mzLSzuz9vKaLHn7yJ2 i2tzGtksvv7YxObA4jGrYS27x5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CVMfHGLLaCV8oV Ew4kNjB+Uepi5OSQEDCROHZuLxOELSZx4d56ti5GLg4hgaOMEp92N0M5Sxglvk9eygZSxSag JzFxyxFWkISIwDRGiZMbljCCJIQFsiVWbtgFZosI5Ej0f25hg7CNJC4f2AC2gkVAVeLqqsvs IDavgK/EytbtUBva2SUOt7xlBklwCmhLzO7cDzaIUUBW4uqfXjCbWUBc4taT+VC3Ckgs2XOe GcIWlXj5+B8rhK0o0f60AaieA6heU2L9Ln2IVkWJKd0PofYKSpyc+YRlAqPoLCRTZyF0zELS MQtJxwJGllWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgVF0cMtvqx2MB587HmIU4GBU4uE9 Ev06WIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MKpz3XNo DtzvKMpo4u38xr102ZHj63feU501YeOsz9MqxWQTshJ8zb6wmi+5qP8t98qdlaVukowbyz6V OkRt1HCRn/NZ9oRIS7iVuM0+/4SY4+8ON8/Q+RQ+Y1HwzKLf2nyMx87OOS8ecSw/3ORweapS 3eI+eb7iP4eTjJ7OrRAr7dkZm/7iuhJLcUaioRZzUXEiANHHEsSDAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/_Z-i9ZlVg-7VBe2lWq5Lcrj5Kio Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 15:37:47 -0000 SGVsbG8gQWRhbSwNCg0KSW1hZ2luZSB0aGF0IFVBOg0KLSBzZW50IE5PVElGWSB0byByZWNlaXZl ZCBTVUJTQ1JJQkUgaW4gZGlhbG9nIFgsIHN1YnNjcmlwdGlvbiBzdGlsbCBleGlzdHMNCi0gc2Vu dCBTVUJTQ1JJQkUgYW5kIHJlY2VpdmVkIE5PVElGWSBpbiBkaWFsb2cgWSwgc3Vic2NyaXB0aW9u IHN0aWxsIGV4aXN0cw0KLSBzZW50IElOVklURSBhbmQgcmVjZWl2ZWQgMjAwIE9LIGluIGRpYWxv ZyBaLCBzZXNzaW9uIHN0aWxsIGV4aXN0cw0KDQpBcmUgeW91IHN0YXRpbmcgdGhhdCB0aGUgVUEg cGVyZm9ybXMgc3RhdGVtZW50IG1hbmRhdGVkIGZvciBub3RpZmllciBiZWxvdyBhbHNvIHdoZW4g c2VuZGluZyBtZXNzYWdlcyBpbiBkaWFsb2cgWSBhbmQgZGlhbG9nIFo/IA0KDQogICAgPj5Ob3Rp ZmllcnM8PCBNVVNUIGltcGxlbWVudCB0aGUgR2xvYmFsbHkgUm91dGFibGUgVXNlciBBZ2VudCBV UkkgKEdSVVUpDQogICAgZXh0ZW5zaW9uIGRlZmluZWQgaW4gW1JGQzU2MjddLCBhbmQgPj5NVVNU IHVzZSBhIEdSVVUgYXMgdGhlaXIgbG9jYWwNCiAgICB0YXJnZXQuIDw8IFRoaXMgYWxsb3dzIHN1 YnNjcmliZXJzIHRvIGV4cGxpY2l0bHkgdGFyZ2V0IGRlc2lyZWQNCiAgICBkZXZpY2VzLg0KDQpT ZWVtcyBjb250cmFyeSB0byBSRkM2NjY1IGRlZmluaXRpb24gb2Ygbm90aWZpZXI6DQoNCiAgIE5v dGlmaWVyOiAgQSBub3RpZmllciBpcyBhIHVzZXIgYWdlbnQgdGhhdCA+PmdlbmVyYXRlcyBOT1RJ RlkgcmVxdWVzdHM8PA0KICAgICAgZm9yIHRoZSBwdXJwb3NlIG9mIG5vdGlmeWluZyBzdWJzY3Jp YmVycyBvZiB0aGUgc3RhdGUgb2YgYQ0KICAgICAgcmVzb3VyY2UuICBOb3RpZmllcnMgdHlwaWNh bGx5IGFsc28gYWNjZXB0IFNVQlNDUklCRSByZXF1ZXN0cyB0bw0KICAgICAgY3JlYXRlIHN1YnNj cmlwdGlvbnMuIA0KDQpJIGFncmVlIHRoYXQgdGhlIGlmIHN1YnNjcmlwdGlvbiBpcyBwb3NzaWJs ZSwgc3Vic2NyaWJlciBiZW5lZml0cyBmcm9tIGtub3dpbmcgR1JVVSBvZiB0aGUgVUEgd2hpY2gg d2lsbCBiZWNvbWUgbm90aWZpZXIuIEhvd2V2ZXIsIEkgZG8gbm90IHJlYWQgaXQgZnJvbSB0aGUg UkZDNjY2NSB0ZXh0IGFib3ZlLiBNYXliZSBteSByZWFkaW5nIGlzIHdyb25nLi4uDQoNCktpbmQg cmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXSANClNlbnQ6IDEzLiBzcnBu YSAyMDE0IDE3OjI3DQpUbzogSXZvIFNlZGxhY2VrOyBSb2JlcnQgU3BhcmtzOyBBbmRyZXcgQWxs ZW47IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRndkOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWNsYXJpZmlj YXRpb25zLTAzLnR4dA0KDQpPbiA4LzEzLzE0IDEwOjAzLCBJdm8gU2VkbGFjZWsgd3JvdGU6DQo+ IFJGQzY2NjUsIHNlY3Rpb24gNC41LjEsIDFzdCBzZW50ZW5jZSBzdGF0ZXM6DQo+DQo+IAlOb3Rp ZmllcnMgTVVTVCBpbXBsZW1lbnQgdGhlIEdsb2JhbGx5IFJvdXRhYmxlIFVzZXIgQWdlbnQgVVJJ IChHUlVVKSBleHRlbnNpb24gZGVmaW5lZCBpbiBbUkZDNTYyN10sIGFuZCBNVVNUIHVzZSBhIEdS VVUgYXMgdGhlaXIgbG9jYWwgdGFyZ2V0Lg0KPg0KPiBJc24ndCBub3RpZmllciBhIHJvbGUgdGFr ZW4gaW4gc3Vic2NyaXB0aW9uLCBhcHBsaWNhYmxlIG9ubHkgZm9yIHRoZSBkaWFsb2cgb2YgdGhl IHN1YnNjcmlwdGlvbj8NCj4gVGhlIFVBIGRvZXMgbm90IGFjdCBhcyBub3RpZmllciBpbiB0aGUg ZGlhbG9ncyBjcmVhdGVkIGJ5IHRoZSBwYXJ0aWN1bGFyIElOVklURSByZXF1ZXN0Lg0KPiBUaHVz LCBpbiBteSByZWFkaW5nLCB0aGUgcmVxdWlyZW1lbnQgZG9lcyBub3QgYXBwbHkgZm9yIHRoZSBw YXJ0aWN1bGFyIElOVklURSByZXF1ZXN0Lg0KPiBPciBkbyBJIG1pc3MgYW55dGhpbmc/DQoNClRo aXMgaXMgZXhhY3RseSB3aGF0IHRoZSBkb2N1bWVudCB0aGF0IEknbGwgYmUgcHJvZHVjaW5nIGlz IGdvaW5nIHRvIGNsYXJpZnkuDQoNCkZvciB3aGF0IGl0J3Mgd29ydGgsICJub3RpZmllciIgaXMg ZGVmaW5lZCBpbiBzZWN0aW9uIDIgb2YgNjY2NSwgYW5kIGl0J3Mgbm90IGEgcm9sZS4NCg0KVG8g dGhlIHBvaW50IG9mIHRoZSBzcGVjaWZpYyBzZWN0aW9uIHlvdSBxdW90ZSwgbGV0J3MgbG9vayBh dCB0aGUgd2hvbGUNCnBhcmFncmFwaDoNCg0KICAgIE5vdGlmaWVycyBNVVNUIGltcGxlbWVudCB0 aGUgR2xvYmFsbHkgUm91dGFibGUgVXNlciBBZ2VudCBVUkkgKEdSVVUpDQogICAgZXh0ZW5zaW9u IGRlZmluZWQgaW4gW1JGQzU2MjddLCBhbmQgTVVTVCB1c2UgYSBHUlVVIGFzIHRoZWlyIGxvY2Fs DQogICAgdGFyZ2V0LiAgVGhpcyBhbGxvd3Mgc3Vic2NyaWJlcnMgdG8gZXhwbGljaXRseSB0YXJn ZXQgZGVzaXJlZA0KICAgIGRldmljZXMuDQoNCk5vdywgdGFrZSBhIG1vbWVudCB0byB0aGluayBy ZWFsbHkgaGFyZCBhYm91dCB3aGF0IHRoZSBzZWNvbmQgc2VudGVuY2UgdGhlcmUgbWVhbnMuIElm IGl0J3Mgbm90IG5vbnNlbnNlIG9yIHVzZWxlc3Mgbm9pc2UgLS0gYW5kIEkgYXNzdXJlIHlvdSB0 aGF0IGl0IGlzIG5vdCAtLSB0aGVuIGl0IG11c3QgYmUgcmVmZXJyaW5nIHRvIHRoZSBhYmlsaXR5 IHRvIHN1YnNjcmliZSB0byBzb21ldGhpbmcgb24gYSBkZXZpY2UgdGhhdCB0aGUgc3Vic2NyaWJl ciBhbHJlYWR5IGtub3dzIGV4aXN0cy4gSW4gb3JkZXIgdG8gbWFrZSB0aGF0IGhhcHBlbiwgdGhl IHN1YnNjcmliZXIgbXVzdCBoYXZlIGxlYXJuZWQgdGhlIEdSVVUgc29tZSB3YXkuDQoNCkhvdyBk byBzdWJzY3JpYmVycyBsZWFybiBhYm91dCBHUlVVcz8gSXQncyByaWdodCB0aGVyZSBpbiB0aGUg Zmlyc3QNCnNlbnRlbmNlOiBOb3RpZmllcnMgaW5jbHVkZSBHUlVVcyBhcyB0aGVpciBsb2NhbCB0 YXJnZXQuIFdlJ2xsIGNvbWUgYmFjayB0byB0aGlzLg0KDQpUaGUgdXNlIGNhc2VzIHRoYXQgbWFr ZSB0aGlzIGludGVyZXN0aW5nIGFyZSB0aG9zZSB0aGF0IGludm9sdmUgc3Vic2NyaWJpbmcgdG8g c29tZSBpbmZvcm1hdGlvbiBhYm91dCBhIGRpYWxvZyB0aGF0IHlvdSdyZSBhbHJlYWR5IGluIChv ciB3ZXJlIHJlY2VudGx5IGluKS4gSW4gZmFjdCwgbm90IGp1c3QgKmFueSogZGlhbG9nLCBidXQg SU5WSVRFIGRpYWxvZ3MuIFNvIGhvdyBkb2VzIHRoaXMgaGFwcGVuPw0KDQpBcyBJIHNhaWQgYWJv dmU6IG5vdGlmZXJzIGluY2x1ZGUgR1JVVXMgdGhlbSBhcyB0aGVpciBsb2NhbCB0YXJnZXQuIA0K RXZlcnkgdGltZS4gSW5jbHVkaW5nIElOVklURSBkaWFsb2dzLg0KDQovYQ0K From nobody Wed Aug 13 08:42:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF281A0891 for ; Wed, 13 Aug 2014 08:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvRVZ9A4NPRe for ; Wed, 13 Aug 2014 08:42:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C091A03C9 for ; Wed, 13 Aug 2014 08:42:07 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7DFg1s6086350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 13 Aug 2014 10:42:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53EB8749.5090306@nostrum.com> Date: Wed, 13 Aug 2014 10:42:01 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ivo Sedlacek , Andrew Allen , Adam Roach , "sipcore@ietf.org" References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/KQ590jbZlLkIvK-1sqt7PrkegfQ Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 15:42:08 -0000 On 8/13/14, 10:03 AM, Ivo Sedlacek wrote: > Hello, > >>>> Your posited UA is going to reject out-of-dialog refers (at least in the context of a given dialog). >>>> Is it going to reject all refers? >>> If you meant REFERs related to dialogs created by the particular INVITE request, then: >>> - the UA rejects any out-of-dialog REFERs related to dialogs created >>> by the particular INVITE request as stated in the question below; and >>> - the UA handles any in-dialog REFER received in a dialog created by the particular INVITE request according to RFC6665. The UA rejects any in-dialog REFER request that would result in an implicit subscription. >> Is this back to norefersub? Is your argument that you can accept the refer because you're the potential notifier and you know you won't take the path of norefersub that would create a subscription? If so, we may have a box around what we need to cover. If not, say more. > Could we focus on the next question (which seems to be the KEY question) and, after we solved it, return to this one? I think you'll find they're the same question. > >>> If you also meant REFERs related to dialogs created by other INVITE request, then UA can accept or reject them within rules given by RFC6665. >> No, I was talking the the context of a given dialog. >>>> If your UA did not provide a GRUU, it is (in the context of this dialog) not satisfying the requirements of 6665. >>>> ... >>>> The text you're proposing (if I've got it right) is trying to say "this UA is not using 6665 in the context of this dialog". >>> Can you please quote the RFC6665 requirement which the UA does not satisfy? >> The first sentence of 4.5.1. >> The clarification that Adam has signed up for well shine the light on that. >> If there is any potential for a UA to become a notifier for _any_ event package (not just refer, but think also dialog), it will need to provide a GRUU for any dialog it tries to enter. > RFC6665, section 4.5.1, 1st sentence states: > > Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target. > > Isn't notifier a role taken in subscription, applicable only for the dialog of the subscription? > The UA does not act as notifier in the dialogs created by the particular INVITE request. Specifically the UA is deciding, before it enters a dialog, that it will not use SIP events for _any_ event package related to this dialog, and is deciding to effectively internally fork all messages for this dialog to an implementation that supports neither 3265 nor 6665, right? From a protocol perspective (inspecting the messages on the wire), from the far end, something that does that is indistinguishable from two UAs that have different capabilities and routing across intermediaries landed dialog-creating messages on the different UAs. (Andrew, this is the best model I've found for discussing the interoperability concern you've been expressing.) That UA that doesn't support 3265 or 6665 (specifically, how the UA you posit is behaving for this dialog) is by definition unconcerned with what 3265 and 6665 say. It is effectively out-of-scope for _this_ document, EXCEPT potentially for the one case I ask about above. > > Thus, in my reading, the requirement does not apply for the particular INVITE request. > Or do I miss anything? > > Kind regards > > Ivo Sedlacek From nobody Thu Aug 14 01:49:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D185D1A0987 for ; Thu, 14 Aug 2014 01:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPPH3tUiVrlG for ; Thu, 14 Aug 2014 01:49:04 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9181A0982 for ; Thu, 14 Aug 2014 01:49:03 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-43-53ec77fd1784 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 38.3B.21334.DF77CE35; Thu, 14 Aug 2014 10:49:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Thu, 14 Aug 2014 10:49:01 +0200 From: Christer Holmberg To: Robert Sparks , Ivo Sedlacek , Andrew Allen , Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPqrHlM30uwpOqe0eZb2vEZAWOo5u3AnoAgAAHa4CAAZZfgIAAFnEAgADzywCAAADGAIABhfIAgAopNYCABytxgIAAGKUAgABmlACAARODAIAAdYQAgAAKZQCAAArRgIABNzww Date: Thu, 14 Aug 2014 08:48:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3E97A9@ESESSMB209.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> <53EB8749.5090306@nostrum.com> In-Reply-To: <53EB8749.5090306@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje7f8jfBBvN+yVrcn7eV0WLP30Xs FtfmNLJZfP2xic2BxWNWw1p2jyVLfjJ5zNr5hCWAOYrLJiU1J7MstUjfLoErY93GlUwFjSwV 5+9/YmpgnMXcxcjBISFgIrH1fUEXIyeQKSZx4d56ti5GLg4hgaOMEoeevGeFcBYxSiyYt4od pIFNwEKi+582SFxE4BCjxMp3z5lAuoUFsiVWbtjFCGKLCORI9H9uYYOwpzFKHL3jD2KzCKhK 3Nx5GKyGV8BXYtKqd1Db2tklZty/zQKS4BTQlpj9eR6YzQh00vdTa8AWMAuIS9x6Mp8J4lQB iSV7zjND2KISLx//Y4WwlSQalzxhhajXk7gxdQobhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZ SFpmIWmZhaRlASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAODq45bfuDsbVrx0PMQpw MCrx8B6Jfh0sxJpYVlyZe4hRmoNFSZx30bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY Wc9GyDS2zD/bZZ9g+aXSOKKYK1M5PkGyfX/47fsf1jP5Zvd9UNsnPmXqCddpy7VOXWxmvxN6 KnP+phPLFWVirn5icH1yWuMP673Olht2+WKcE3y/x5R3JsheF2ZekuLMNDfcKLp6VoBLRug7 sUaBpRnTfqycNKn/3CxZj/K/rx1N1gS13HuoxFKckWioxVxUnAgATXebtIQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/eTS9RFkVj3GInhyUTXrvOVYLARs Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 08:49:06 -0000 Hi, I may have missed something, but in general a UA can make *per-dialog decis= ions* (based on configuration, policies, user interaction, use-case etc etc= etc) on what capabilities/features it offers to the remote peer. Why is being a notifier different? If Bob will not accept subscriptions fro= m Alice, why does Bob have to act towards=A0Alice as if he would be willing= to accept subscriptions from Alice, just because Bob may accept subscripti= ons from Lisa?=20 Regards, Christer From nobody Thu Aug 14 04:31:05 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802761A0A8C for ; Thu, 14 Aug 2014 04:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwjr1MhZ9Yj2 for ; Thu, 14 Aug 2014 04:30:57 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56E01A0A89 for ; Thu, 14 Aug 2014 04:30:56 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-19-53ec9deeccdf Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.F4.02247.EED9CE35; Thu, 14 Aug 2014 13:30:54 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Thu, 14 Aug 2014 13:30:54 +0200 From: Christer Holmberg To: Robert Sparks , Ivo Sedlacek , Andrew Allen , Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPqrHlM30uwpOqe0eZb2vEZAWOo5u3AnoAgAAHa4CAAZZfgIAAFnEAgADzywCAAADGAIABhfIAgAopNYCABytxgIAAGKUAgABmlACAARODAIAAdYQAgAAKZQCAAArRgIABarpw Date: Thu, 14 Aug 2014 11:30:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3E99EB@ESESSMB209.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> <53EB8749.5090306@nostrum.com> In-Reply-To: <53EB8749.5090306@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvje67uW+CDY5c0La4P28ro8Wev4vY La7NaWSz+PpjE5sDi8eshrXsHkuW/GTymLXzCUsAcxSXTUpqTmZZapG+XQJXxp4f55kKHrJU XP3/jL2B8SFzFyMnh4SAicTypj4mCFtM4sK99WxdjFwcQgJHGSWWXjjPBOEsYpRYfOkBSxcj BwebgIVE9z9tkLiIwCFGiZXvnoN1CwtkS6zcsIsRxBYRyJHo/9zCBlE0jVGi8eoTdpAEi4Cq xONXl8BW8wr4StxousAMsaGdXWLG/dssIAlOAW2J2Z/ngdmMQDd9P7UGbAOzgLjErSfzoW4V kFiy5zzUD6ISLx//Y4WwlSQalzxhhajXkViw+xMbhK0tsWzha6jFghInZz5hmcAoOgvJ2FlI WmYhaZmFpGUBI8sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMBYOrjlt9UOxoPPHQ8xCnAw KvHwHol+HSzEmlhWXJl7iFGag0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjX CHby3X8hv0EozZlbd750+ZuFM/LXfr0+efoW9ncRT+onT1m/Mp8jIC6zQEzMV4bZ1fibxaYJ a5gNA3imLpmx0qUiNPuTVNLG/Ff/9u1YMv9KYprCz2+rglYmbBD064q4ks/y56zwhH2zgtoU ptUX57BFbw+MmzvhltXOZ6kPZm1T7m6/xm6nxFKckWioxVxUnAgAomUP6IYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/fd_nZvNExwxTEBuLG_zW7NkDifM Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 11:31:01 -0000 Hi Robert, >That UA that doesn't support 3265 or 6665 (specifically, how the UA you po= sit is behaving for this >dialog) is by definition unconcerned with what 32= 65 and 6665 say. It is effectively out-of-scope for >_this_ document, EXCEP= T potentially for the one case I ask about above. The issue, which seems to cause the confusion, is that the UA still impleme= nts 6665 (as it may use it for other dialogs), and the text ssays *ALL* INV= ITEs.=20 It would be more clear if the text talked about INVITEs for dialogs where t= he 6665 functionality is provided. Regards, Christer From nobody Thu Aug 14 13:42:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607C61A8770 for ; Thu, 14 Aug 2014 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyO9sZVhmPVn for ; Thu, 14 Aug 2014 13:42:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FCA1A8777 for ; Thu, 14 Aug 2014 13:42:51 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7EKghoY085270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Aug 2014 15:42:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <53ED1F43.50303@nostrum.com> Date: Thu, 14 Aug 2014 15:42:43 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ivo Sedlacek , Robert Sparks , Andrew Allen , "sipcore@ietf.org" References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> <53EB83C3.9040807@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127122B0@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127122B0@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ne9SZCSQHesaQ3QYMaRXUvuMFv0 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 20:42:55 -0000 On 8/13/14 10:37, Ivo Sedlacek wrote: > Imagine that UA: > - sent NOTIFY to received SUBSCRIBE in dialog X, subscription still exists > - sent SUBSCRIBE and received NOTIFY in dialog Y, subscription still exists > - sent INVITE and received 200 OK in dialog Z, session still exists > > Are you stating that the UA performs statement mandated for notifier below also when sending messages in dialog Y and dialog Z? Yes. /a From nobody Fri Aug 15 01:02:57 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0272E1A6F34 for ; Fri, 15 Aug 2014 01:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL-SG17ob6v3 for ; Fri, 15 Aug 2014 01:02:54 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7128F1A053B for ; Fri, 15 Aug 2014 01:02:53 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-88-53edbeabfc9d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.9F.21334.BAEBDE35; Fri, 15 Aug 2014 10:02:51 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.135]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Fri, 15 Aug 2014 10:02:51 +0200 From: Ivo Sedlacek To: Adam Roach , Robert Sparks , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt Thread-Index: AQHPuABQzYSlmZjBHEyGFi79yfWcfpvRTaeg Date: Fri, 15 Aug 2014 08:02:49 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112712DAC@ESESSMB301.ericsson.se> References: <20140728221604.19558.73431.idtracker@ietfa.amsl.com> <53D6CC3D.4000005@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270A76B@ESESSMB301.ericsson.se> <53D7BB5D.5010402@nostrum.com> <53D92314.6040607@nostrum.com> <39B5E4D390E9BD4890E2B310790061011270B9E1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270BA18@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061011270C376@ESESSMB301.ericsson.se> <53E3BD65.5080105@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711567@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112711708@ESESSMB301.ericsson.se> <53EA2BCC.2080306@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112711DE0@ESESSMB301.ericsson.se> <53EB757E.5000601@nostrum.com> <39B5E4D390E9BD4890E2B310790061011271222B@ESESSMB301.ericsson.se> <53EB83C3.9040807@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127122B0@ESESSMB301.ericsson.se> <53ED1F43.50303@nostrum.com> In-Reply-To: <53ED1F43.50303@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112712DACESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Rnf1vrfBBqu2aVvcn7eV0WLP30Xs FtfmNLJZfP2xic2BxWNWw1p2jyVLfjJ5zNr5hCWAOYrLJiU1J7MstUjfLoErY82dfewFbbYV XTOSGxhXWHcxcnJICJhIbPm/hQXCFpO4cG89WxcjF4eQwFFGic079rNCOEsYJWb8esAGUsUm oCcxccsRsISIwDRGiZMbljCCJIQFsiVWbtgFZosI5Ej0f25hg7CNJJYe7AKLswioSnx60wHU zMHBK+Ar8Xe5KMSCV+wSe7dMZQKp4RTQlNjzewYriM0oICtx9U8vWC+zgLjErSfzmSBOFZBY suc8M4QtKvHy8T9WCFtRYufZdmaQ+cwC+RL/++JBwrwCghInZz5hmcAoMgvJpFkIVbOQVEGE NSXW79KHqFaUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzA iDu45bfuDsbVrx0PMQpwMCrx8D448CZYiDWxrLgy9xCjNAeLkjjvonPzgoUE0hNLUrNTUwtS i+KLSnNSiw8xMnFwSjUwRuzSP1dxbfL++fkKbCsNRa5xzOuSOsJ37qrmZLe21gU6PR7xZTb/ b0y6m9Xa3ff58HUfo+kX2y36ljbyztx/LOvj7T2aeauWBB/6lvqi692RRSlLrNITJCYcXOw7 7/elw0wMAo8fGHcvuFQ90T0o/O65BD23m7m7H/Men/3NLvHMy6VLp515XKXEUpyRaKjFXFSc CACmkCvcmQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3D71rz4hsJZvcZRxsAPkLFuli74 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-clarifications-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 08:02:56 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112712DACESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiA+IEltYWdpbmUgdGhhdCBVQToNCg0KPiA+IC0gc2VudCBOT1RJRlkgdG8gcmVjZWl2ZWQgU1VC U0NSSUJFIGluIGRpYWxvZyBYLCBzdWJzY3JpcHRpb24gc3RpbGwgZXhpc3RzDQoNCj4gPiAtIHNl bnQgU1VCU0NSSUJFIGFuZCByZWNlaXZlZCBOT1RJRlkgaW4gZGlhbG9nIFksIHN1YnNjcmlwdGlv biBzdGlsbCBleGlzdHMNCg0KPiA+IC0gc2VudCBJTlZJVEUgYW5kIHJlY2VpdmVkIDIwMCBPSyBp biBkaWFsb2cgWiwgc2Vzc2lvbiBzdGlsbCBleGlzdHMNCg0KPiA+DQoNCj4gPiBBcmUgeW91IHN0 YXRpbmcgdGhhdCB0aGUgVUEgcGVyZm9ybXMgc3RhdGVtZW50IG1hbmRhdGVkIGZvciBub3RpZmll ciBiZWxvdw0KDQo+IGFsc28gd2hlbiBzZW5kaW5nIG1lc3NhZ2VzIGluIGRpYWxvZyBZIGFuZCBk aWFsb2cgWj8NCg0KPg0KDQo+IFllcy4NCg0KDQoNCkl0IHNlZW1zIGluY29ycmVjdC4NCg0KDQoN CkluIGRpYWxvZyBZLCB0aGUgVUEgc2VudCBTVUJTQ1JJQkUgYW5kIHRodXMgaXMgc3Vic2NyaWJl ci4NCg0KDQoNCiAgIFN1YnNjcmliZXIgICAgICAgICAgTm90aWZpZXINCg0KICAgICAgIHwtLS0t LVNVQlNDUklCRS0tLS0+fCAgICAgUmVxdWVzdCBzdGF0ZSBzdWJzY3JpcHRpb24NCg0KICAgICAg IHw8LS0tLS0tLTIwMC0tLS0tLS0tfCAgICAgQWNrbm93bGVkZ2Ugc3Vic2NyaXB0aW9uDQoNCiAg ICAgICB8PC0tLS0tLU5PVElGWS0tLS0tIHwgICAgIFJldHVybiBjdXJyZW50IHN0YXRlIGluZm9y bWF0aW9uDQoNCiAgICAgICB8LS0tLS0tLS0yMDAtLS0tLS0tPnwNCg0KICAgICAgIHw8LS0tLS0t Tk9USUZZLS0tLS0gfCAgICAgUmV0dXJuIGN1cnJlbnQgc3RhdGUgaW5mb3JtYXRpb24NCg0KICAg ICAgIHwtLS0tLS0tLTIwMC0tLS0tLS0+fA0KDQoNCg0KS2luZCByZWdhcmRzDQoNCg0KDQpJdm8g U2VkbGFjZWsNCg== --_000_39B5E4D390E9BD4890E2B3107900610112712DACESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBJbWFnaW5lIHRoYXQg VUE6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgLSBz ZW50IE5PVElGWSB0byByZWNlaXZlZCBTVUJTQ1JJQkUgaW4gZGlhbG9nIFgsIHN1YnNjcmlwdGlv biBzdGlsbCBleGlzdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyAtIHNlbnQgU1VCU0NSSUJFIGFuZCByZWNlaXZlZCBOT1RJRlkgaW4gZGlhbG9nIFks IHN1YnNjcmlwdGlvbiBzdGlsbCBleGlzdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAtIHNlbnQgSU5WSVRFIGFuZCByZWNlaXZlZCAyMDAgT0sgaW4g ZGlhbG9nIFosIHNlc3Npb24gc3RpbGwgZXhpc3RzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyBBcmUgeW91IHN0YXRpbmcgdGhhdCB0aGUgVUEgcGVyZm9ybXMgc3Rh dGVtZW50IG1hbmRhdGVkIGZvciBub3RpZmllciBiZWxvdw0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFsc28gd2hlbiBzZW5kaW5nIG1lc3NhZ2VzIGluIGRp YWxvZyBZIGFuZCBkaWFsb2cgWj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFll cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SXQgc2VlbXMgaW5jb3JyZWN0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiBkaWFsb2cgWSwgdGhlIFVBIHNlbnQgU1VCU0NS SUJFIGFuZCB0aHVzIGlzIHN1YnNjcmliZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IFN1YnNjcmliZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgTm90aWZpZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8LS0tLS1TVUJTQ1JJ QkUtLS0tJmd0O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVxdWVzdCBzdGF0ZSBzdWJzY3Jp cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jmx0Oy0tLS0tLS0yMDAtLS0tLS0tLXwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQWNrbm93bGVkZ2Ugc3Vic2NyaXB0aW9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZsdDstLS0tLS1OT1RJRlktLS0tLSB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJl dHVybiBjdXJyZW50IHN0YXRlIGluZm9ybWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfC0tLS0t LS0tMjAwLS0tLS0tLSZndDt8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZsdDstLS0tLS1OT1RJRlkt LS0tLSB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJldHVybiBjdXJyZW50IHN0YXRlIGluZm9y bWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfC0tLS0tLS0tMjAwLS0tLS0tLSZndDt8DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPktpbmQgcmVnYXJkczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5Jdm8gU2VkbGFjZWs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_39B5E4D390E9BD4890E2B3107900610112712DACESESSMB301erics_-- From nobody Mon Aug 18 11:19:28 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3EB1A0747 for ; Mon, 18 Aug 2014 11:19:26 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnAauG0gqrFl for ; Mon, 18 Aug 2014 11:19:24 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385831A0718 for ; Mon, 18 Aug 2014 11:19:24 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id b8so4939153lan.19 for ; Mon, 18 Aug 2014 11:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BWPiOXHZ0g4W8dDdP2PzyIsSThvQInRTcf1lKSXGJQE=; b=H5VSTVOLo7ymhwrUrfz8S9aV38n/MBXzmUiIvhdZTAolI4fqeQ8ToafILISmtwpggk LquBGojo8EaFbC+jIG4Cwe4RUpNuz2hLvrKSNZprbYNzjTUacirmD14j8hsZsgnOnq+s z1XWxvkBfmxge31/WmzYgMdhLXM8LGYG0duhIUV7FQFOkl2G/vHocOwXiNoAvOi+CQYL Ib84U9fyCP8Sv7tN5gsaATLRbVD3O8NxJDgMGtDgRX/vYE85dhO9G35cLzg2C1Jx7hjE DLJoapHP0GdFLNL20l/b9gpsTK1xdNBRacpTNb3jANq8qlcN/jamO5jl0NM1X84b+Bnw vRJw== MIME-Version: 1.0 X-Received: by 10.112.156.10 with SMTP id wa10mr20420849lbb.68.1408385962576; Mon, 18 Aug 2014 11:19:22 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Mon, 18 Aug 2014 11:19:22 -0700 (PDT) Date: Mon, 18 Aug 2014 14:19:22 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=089e01160952018fd00500eb69cc Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/hbujVsJpin5CFAQkuRoxKLtRuPg Subject: [sipcore] SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 18:19:26 -0000 --089e01160952018fd00500eb69cc Content-Type: text/plain; charset=ISO-8859-1 Hi, During the discussion of the SIP OAuth proposal in Toronto, it was decided that we need a list of use cases to make it clear what we are trying to solve. The following is some definitions and the use cases that I had in mind when I started working on the SIP OAuth proposal. I know that others had different use cases in mind that they want the new authorization framework to address. Regards, Rifaat Definitions ----------- o Types of SIP services: 1. Basic SIP Services: make/receive call, transfer, call forward, ... 2. Advanced SIP Services: services provided by SIP application servers, e.g. Voice Mail, Conference Services, Video Services, Presence, IM, ... o Single Sign-On (SSO): SSO is a property that allows the user to be authenticated once and as a result have access to multiple services in the system. o Authentication: the process of verifying the identity of a user trying to get access to some network services. o Authorization: the process of controlling a user access to network services and the level of service provided to the user. Enterprise Use Cases -------------------- 1. Corporate-wide SSO An enterprise is interested in providing its users with an SSO capability to the corporate various services. The enterprise has an authorization server for controlling the user access to their network and would like to extend that existing authorization server to control the user access to the various services provided by their SIP network. The user is expected to provide his corporate credentials to login to the corporate network and get different types of services, regardless of the protocol used to provide the service, and without the need to create different accounts for these different types of services. 2. SIP SSO An enterprise is interested in providing its users with an SSO capability to the corporate various SIP services. The enterprise wants to control the services provided to their SIP users and the level of service provided to the user by their SIP application servers without the need to create different accounts for these services. The enterprise wants to utilize an existing authentication mechanism provided by SIP, but would like to be able to control who gets access to what service and when. The user is expected to use his SIP credentials to login to the SIP network and get access to the basic services, and to get access to the services provided by the various SIP application servers without being challenged to provide credentials for each type of service. 3. Edge Authorization An enterprise is interested in authenticating and authorizing a remote user trying to get access to services provided by the corporate SIP network. The enterprise would like to authenticate and authorize the remote user at the edge of the network using a SIP network element that does not have direct access to the SIP user account, e.g. SBC. The enterprise is also interested in providing the user with an SSO capability to the corporate various SIP services. The user is expected to use his SIP credentials to login to the SIP network and get access to the basic services, and to get access to the services provided by the various SIP application servers without being challenged to provide credentials for each type of service. --089e01160952018fd00500eb69cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

During the discussion of the SIP OA= uth proposal in Toronto, it was decided that we need a list of use cases to= make it clear what we are trying to solve.
The following is some= definitions and the use cases that I had in mind when I started working on= the SIP OAuth proposal.

I know that others had different use cases in min= d that they want the new authorization framework to address.

=
Regards,
=A0Rifaat


Definitions
-----------

o Types of SIP services:
  1. Basic SIP Services: make/receive call, transfer, call forward, ...
  2. Advanced SIP Services: services provided by SIP application servers, e=
.g. Voice Mail, Conference Services, Video Services, Presence, IM, ...

o Single Sign-On (SSO): SSO is a property that allows the user to be authen=
ticated once and as a result have access to multiple services in the system=
.

o Authentication: the process of verifying the identity of a user trying to=
 get access to some network services.

o Authorization: the process of controlling a user access to network servic=
es and the level of service provided to the user.



Enterprise Use Cases
--------------------

1. Corporate-wide SSO

An enterprise is interested in providing its users with an SSO capability t=
o
the corporate various services.
The enterprise has an authorization server for controlling the user access
to their network and would like to extend that existing authorization
server to control the user access to the various services provided by
their SIP network.

The user is expected to provide his corporate credentials to login to the
corporate network and get different types of services, regardless of
the protocol used to provide the service, and without the need to
create different accounts for these different types of services.


2. SIP SSO

An enterprise is interested in providing its users with an SSO capability t=
o
the corporate various SIP services.

The enterprise wants to control the services provided to their SIP users an=
d
the level of service provided to the user by their SIP application servers
without the need to create different accounts for these services.

The enterprise wants to utilize an existing authentication mechanism
provided by SIP, but would like to be able to control who gets access to
what service and when.

The user is expected to use his SIP credentials to login to the SIP
network and get access to the basic services, and to get access to the
services provided by the various SIP application servers without being
challenged to provide credentials for each type of service.


3. Edge Authorization

An enterprise is interested in authenticating and authorizing a remote user
trying to get access to services provided by the corporate SIP network.

The enterprise would like to authenticate and authorize the remote user at =
the edge
of the network using a SIP network element that does not have direct access=
 to
the SIP user account, e.g. SBC. The enterprise is also interested in provid=
ing
the user with an SSO capability to the corporate various SIP services.

The user is expected to use his SIP credentials to login to the SIP
network and get access to the basic services, and to get access to the
services provided by the various SIP application servers without being
challenged to provide credentials for each type of service.
--089e01160952018fd00500eb69cc-- From nobody Mon Aug 18 11:40:53 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527951A0ADD for ; Mon, 18 Aug 2014 11:40: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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAVkTV3CECVt for ; Mon, 18 Aug 2014 11:40:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B331A0AD7 for ; Mon, 18 Aug 2014 11:40:46 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-5e-53f248acc766 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 96.65.02247.CA842F35; Mon, 18 Aug 2014 20:40:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Mon, 18 Aug 2014 20:40:44 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP Authorization Framework Use Cases Thread-Index: AQHPuxD19+1dYcx/o0uBGjy6XR2L4ZvWsWMQ Date: Mon, 18 Aug 2014 18:40:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D419CCE@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D419CCEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje4aj0/BBhuPyFrsfNHKZvH1xyY2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj9NbAgn+bGCsu32ljamDsmMnYxcjJISFg IvHx0Gk2CFtM4sK99UA2F4eQwFFGiaMvjjFCOEsYJSYuuA3kcHCwCVhIdP/TBmkQEQiX2LH7 IiuILSxgK/FnymomiLidxNb7D5khbCOJS7ePgNWwCKhKbPv6EWwxr4CvxO3Th8DqhQQCJF7s eg82nlMgUGLPnQKQMCPQPd9PrQErYRYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+xwphK0ksuv0Z qj5fYuK1DSwQqwQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMji CxjZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIExtXBLb+tdjAefO54iFGAg1GJh/cB26dg IdbEsuLK3EOM0hwsSuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAGMJ3nCPg1cLs Ot0D4aJvyo8/uv/IuVApM9V8S8v/ozKPnguHGjatMmbY0LWprje8Xbduz86lku9+fuDs3ZoS JOj1S7NX/O2fNv5ZabsZ615/Fd6y58NE4yXbmqp21MzR9/xWWj19uVdv+HWrBVUHT9jq7g3q u3Ld0/TB6yl3Dt0IWiu/Xe7jdiWW4oxEQy3mouJEAGj04zCMAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Talln0o5uVAZI6_-L4k3xt1Fpvs Subject: Re: [sipcore] SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 18:40:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D419CCEESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rifaat, 3GPP defines the usage of OAuth2 for WebRTC based access to IMS. On a high-level, it is similar to section 5 in the draft, i.e. the UA retri= eves the token using a non-SIP mechanism (HTTP), and then includes it in th= e SIP REGISTER request. 3GPP maps OAuth roles into IMS roles using the table below: IMS role OAuth role IMS subscriber Resource Owner WWSF Client WAF Authorization Server IMS network Resource Server WWSF (WebRTC Web Server Function) - Acts as web server, from where the user downloads the IMS access= application. WAF (WebRTC Authorisation Function) - Acts as the authorization server (the "facebook"), and issues th= e authorization tokens. (The WWSF and WAF can, but does not have to, be located in the same domain = as the IMS provider.) I guess the important thing to note here is that the IMS core network (incl= uding the registrar/S-CSCF and HSS) does not act as Authorization Server, b= ut rather as the Resource Server. In fact, the IMS core network itself does not even need to support OAuth2.0= . Instead the WAF performs mapping and verification between "legacy IMS cre= dentials" and "web credentials" (e.g. OAuth2.0). The detailed procedures fo= r that mapping/verification is not specified in the current 3GPP release. Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Y= usef Sent: 18 August 2014 21:19 To: sipcore@ietf.org Subject: [sipcore] SIP Authorization Framework Use Cases Hi, During the discussion of the SIP OAuth proposal in Toronto, it was decided = that we need a list of use cases to make it clear what we are trying to sol= ve. The following is some definitions and the use cases that I had in mind when= I started working on the SIP OAuth proposal. I know that others had different use cases in mind that they want the new a= uthorization framework to address. Regards, Rifaat Definitions ----------- o Types of SIP services: 1. Basic SIP Services: make/receive call, transfer, call forward, ... 2. Advanced SIP Services: services provided by SIP application servers, e= .g. Voice Mail, Conference Services, Video Services, Presence, IM, ... o Single Sign-On (SSO): SSO is a property that allows the user to be authen= ticated once and as a result have access to multiple services in the system= . o Authentication: the process of verifying the identity of a user trying to= get access to some network services. o Authorization: the process of controlling a user access to network servic= es and the level of service provided to the user. Enterprise Use Cases -------------------- 1. Corporate-wide SSO An enterprise is interested in providing its users with an SSO capability t= o the corporate various services. The enterprise has an authorization server for controlling the user access to their network and would like to extend that existing authorization server to control the user access to the various services provided by their SIP network. The user is expected to provide his corporate credentials to login to the corporate network and get different types of services, regardless of the protocol used to provide the service, and without the need to create different accounts for these different types of services. 2. SIP SSO An enterprise is interested in providing its users with an SSO capability t= o the corporate various SIP services. The enterprise wants to control the services provided to their SIP users an= d the level of service provided to the user by their SIP application servers without the need to create different accounts for these services. The enterprise wants to utilize an existing authentication mechanism provided by SIP, but would like to be able to control who gets access to what service and when. The user is expected to use his SIP credentials to login to the SIP network and get access to the basic services, and to get access to the services provided by the various SIP application servers without being challenged to provide credentials for each type of service. 3. Edge Authorization An enterprise is interested in authenticating and authorizing a remote user trying to get access to services provided by the corporate SIP network. The enterprise would like to authenticate and authorize the remote user at = the edge of the network using a SIP network element that does not have direct access= to the SIP user account, e.g. SBC. The enterprise is also interested in provid= ing the user with an SSO capability to the corporate various SIP services. The user is expected to use his SIP credentials to login to the SIP network and get access to the basic services, and to get access to the services provided by the various SIP application servers without being challenged to provide credentials for each type of service. --_000_7594FB04B1934943A5C02806D1A2204B1D419CCEESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rifaat,

 

3GPP defines the usage of OAuth2 for WebRTC based ac= cess to IMS.

 

On a high-level, it is similar to section 5 in the d= raft, i.e. the UA retrieves the token using a non-SIP mechanism (HTTP), and= then includes it in the SIP REGISTER request.

 

3GPP maps OAuth roles into IMS roles using the table= below:

 

IMS role       = ;            &n= bsp;            = ; OAuth role

 

IMS subscriber      &n= bsp;            &nbs= p;    Resource Owner

WWSF        =             &nb= sp;             = ;  Client

WAF        &= nbsp;           &nbs= p;            &= nbsp;     Authorization Server

IMS network       = ;             &= nbsp;      Resource Server

 

 

WWSF (WebRTC Web Server Function)

-     &= nbsp;    Acts as web server, from where the user downloads t= he IMS access application.

WAF (WebRTC Authorisation Function)

-     &= nbsp;    Acts as the authorization server (the “facebo= ok”), and issues the authorization tokens.

 

(The WWSF and WAF can, but does not have to, be loca= ted in the same domain as the IMS provider.)

 

I guess the important thing to note here is that the= IMS core network (including the registrar/S-CSCF and HSS) does not act as = Authorization Server, but rather as the Resource Server.

 

In fact, the IMS core network itself does not even n= eed to support OAuth2.0. Instead the WAF performs mapping and verification = between “legacy IMS credentials” and “web credentialsR= 21; (e.g. OAuth2.0). The detailed procedures for that mapping/verification is not specified in the current 3GPP release.

 

Regards,

 

Christer

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: 18 August 2014 21:19
To: sipcore@ietf.org
Subject: [sipcore] SIP Authorization Framework Use Cases<= /span>

 

Hi,

 

During the discussion of the SIP OAuth proposal in T= oronto, it was decided that we need a list of use cases to make it clear wh= at we are trying to solve.

The following is some definitions and the use cases = that I had in mind when I started working on the SIP OAuth proposal.

 

I know that others had different use cases in mind t= hat they want the new authorization framework to address.

 

Regards,

 Rifaat

 

 

Definitions
-----------
 
o Types of SIP services:
  1. Basic SIP Services: make/receive call, transfer, call forwar=
d, ...
  2. Advanced SIP Services: services provided by SIP application =
servers, e.g. Voice Mail, Conference Services, Video Services, Presence, IM=
, ...
 
o Single Sign-On (SSO): SSO is a property that allows the user to be a=
uthenticated once and as a result have access to multiple services in the s=
ystem.
 
o Authentication: the process of verifying the identity of a user tryi=
ng to get access to some network services.
 
o Authorization: the process of controlling a user access to network s=
ervices and the level of service provided to the user.
 
 
 
Enterprise Use Cases
--------------------
 
1. Corporate-wide SSO
 
An enterprise is interested in providing its users with an SSO capabil=
ity to
the corporate various services.
The enterprise has an authorization server for controlling the user ac=
cess
to their network and would like to extend that existing authorization<=
o:p>
server to control the user access to the various services provided by<=
o:p>
their SIP network.
 
The user is expected to provide his corporate credentials to login to =
the
corporate network and get different types of services, regardless of
the protocol used to provide the service, and without the need to=

create different accounts for these different types of services.<=
/o:p>
 
 
2. SIP SSO
 
An enterprise is interested in providing its users with an SSO capabil=
ity to
the corporate various SIP services.
 
The enterprise wants to control the services provided to their SIP use=
rs and
the level of service provided to the user by their SIP application ser=
vers
without the need to create different accounts for these services.=

 
The enterprise wants to utilize an existing authentication mechanism
provided by SIP, but would like to be able to control who gets access =
to
what service and when.
 
The user is expected to use his SIP credentials to login to the SIP
network and get access to the basic services, and to get access to the=

services provided by the various SIP application servers without being=

challenged to provide credentials for each type of service.=

 
 
3. Edge Authorization
 
An enterprise is interested in authenticating and authorizing a remote=
 user
trying to get access to services provided by the corporate SIP network=
.
 
The enterprise would like to authenticate and authorize the remote use=
r at the edge
of the network using a SIP network element that does not have direct a=
ccess to
the SIP user account, e.g. SBC. The enterprise is also interested in p=
roviding
the user with an SSO capability to the corporate various SIP services.=

 
The user is expected to use his SIP credentials to login to the SIP
network and get access to the basic services, and to get access to the=

services provided by the various SIP application servers without being=

challenged to provide credentials for each type of service.=
--_000_7594FB04B1934943A5C02806D1A2204B1D419CCEESESSMB209erics_-- From nobody Tue Aug 19 05:02:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0111A88C7 for ; Tue, 19 Aug 2014 05:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7s_bAfwODqB for ; Tue, 19 Aug 2014 05:02:03 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4201A03E1 for ; Tue, 19 Aug 2014 05:02:03 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so9581419pdj.29 for ; Tue, 19 Aug 2014 05:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:message-id; bh=K0p4OMM4cJ6+wl0QSDit6UclVSSql8kniute9AFeY80=; b=lv7PprIikZzQVZHMJokHNwBxa6d6z9l7iRzQmY1D38oiHJ5N0DGVxw78iVa3qJTrNP xT14KOwptBeCD7KI+ojUbUwt2I50T+OR+7s2Mi4itoOA/PoBBt7ZVFAjGxKlQFbkDMG3 qHafr6V3HqdNpqFl/idwWFveGj7rB6GBhIbSotrx/UMApDlUlq3hVVy+4C4Qplu3agJm 04/eroewpEIwUbKPmv6dRJsW83/SUUjr6DQfqzAbRGq2ut74wlEsDQFr9lVWZCmucF1a wezikueww5vvnEjFCRugWX/JuDsuOfkKcVjp5kYmaq3huDPgdK99tTYQm5N1eInd5rfE Cpog== X-Received: by 10.66.193.37 with SMTP id hl5mr43460023pac.135.1408449721268; Tue, 19 Aug 2014 05:02:01 -0700 (PDT) Received: from gmail.com (softbank126001169004.bbtec.net. [126.1.169.4]) by mx.google.com with ESMTPSA id fq4sm29104450pdb.71.2014.08.19.05.01.59 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Aug 2014 05:02:00 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org Date: Tue, 19 Aug 2014 21:01:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.24 (WinNT,601) Message-Id: <78CFBBA55ECDC0ietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/35g6E8E3yk-Am1mMFUKRY6fUGO0 Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:02:05 -0000 Hi, > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/ I have any questions. 1) I think that refer subscription should be created before sending REFER with "explicitsub". If a referee receives SUBSCRIBE after ending of procedure for refer, what does the referee notify? 2) Does SUBSCRIBE contain Target-Dialog(-like) header? Regards, Shinji From nobody Tue Aug 19 05:13:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039E91A88D0 for ; Tue, 19 Aug 2014 05:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4LGhFlm8B44 for ; Tue, 19 Aug 2014 05:13:52 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9678B1A03EC for ; Tue, 19 Aug 2014 05:13:51 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id eu11so9758060pac.3 for ; Tue, 19 Aug 2014 05:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:mime-version:content-type :content-transfer-encoding:message-id; bh=StAMG3jzYTCWagvc+yiGOVzNm02Ssg3Joa3p1um8HhI=; b=yQYy82gO4NaDHqirhIUEDKqCjzAeUNeyt525cjd7bRCkvHB5I09iWuk/P8UdwxApkJ sEM8kPfu0hsavLhDsYX8UjqK2FDRj0cmyeyw+Gk6DtpF34ieZWqIuBJ2bX/CMTiZmmX8 CBEq/ziFwgRFB+Cbw3rkTEwj0LUz6icINH/PiYbLniQ86Ud6iIJZNQ//o2xuVTvAuI7j twWuXrVRWrrMgXgCtKR14LYAkd2oN3g7wl9nQ/JP7ICCvhiEr1hDXIUpNAvDe5CSc1LS bHf1ObVLy4h9gJxmuAlvy1qpIpRd2xeX2ulbvY8Cfe34bELniyGk0bd0Cw5/zGcKRfLZ tvQw== X-Received: by 10.66.100.200 with SMTP id fa8mr43314733pab.23.1408450426824; Tue, 19 Aug 2014 05:13:46 -0700 (PDT) Received: from gmail.com (softbank126001169004.bbtec.net. [126.1.169.4]) by mx.google.com with ESMTPSA id hk7sm29175978pdb.4.2014.08.19.05.13.45 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Aug 2014 05:13:46 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org Date: Tue, 19 Aug 2014 21:13:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.24 (WinNT,601) Message-Id: <7ECFBBA7034CE9ietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/FQ8-M130iR_A5iyLXB-Q1ad6bio Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-clarifications-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:13:55 -0000 Hi, > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-clarifications/ I want this document to clarify the behavior of referer and referee. That is the scope of this document, isn't it? > 3. Use of GRUU is mandatory In this section, I want this document to clarify the behavior of referee that is 6665 compliant UAS. If the 6665 compliant UAS supports REFER, then 1) In a dialog created by INVITE, a local Contact of the UAS MUST be GRUU. 2) If the UAS supports a scenario for a transfer, then it SHOULD support tdialog. 3) When the UAS receives REFER within the dialog, if referer supports tdialog, then the UAS MAY respond by 3xx "Extension Required" with "Required: tdialog" and "Contact: GRUUofReferee", else the UAS MAY accept the REFER. 4) When the UAS receives REFER out of the dialog, UAS MAY accept the REFER. > 4. Dialog reuse is prohibited In this section, I want this document to clarify the behavior of referer that is 6665 compliant UAC. 1) If a UAS's local Contact inside an existing dialog is gruu, then the 6665 compliant UAC MUST use REFER out of dialog. 2) If the UAC supports a scenario for a transfer, then it SHOULD support tdialog. 3) If a UAS does not support both of gruu and tdialog, then the 6665 compliant UAC MAY use REFER within dialog. 4) If a UAC received 3xx "Extension Required" response for REFER that contains "Required: tdialog", then UAS MAY send REFER out of dialog. The REFER request SHOULD contain "Targer-Dialog" header. 3xx "Extension Required" is proceeded as described in RFC3261, the handling needs no extensions. Regards, Shinji From nobody Tue Aug 19 08:05:48 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0751E1A895F for ; Tue, 19 Aug 2014 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBYm8S84UBge for ; Tue, 19 Aug 2014 08:05:18 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 945631A0390 for ; Tue, 19 Aug 2014 08:05:05 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id gc4w1o0040cZkys5Ff55di; Tue, 19 Aug 2014 15:05:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta10.westchester.pa.mail.comcast.net with comcast id gf541o0193Ge9ey3Wf54sE; Tue, 19 Aug 2014 15:05:05 +0000 Message-ID: <53F367A0.1010004@alum.mit.edu> Date: Tue, 19 Aug 2014 11:05:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408460705; bh=WayyDOqJjZ0ClXTaRFugLLTYvaxmdgFQf9a0HzL7t7k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mm28+9wxvo0no2CLmpOWEE9dFMhj87ynQt3n2fC8AUHpwHqzLL7t81JzpgJdBLAzt muGiTGieY7N2XxaN6M3jF2hz4Mj7fdwJ6t/DS/fkKHRr8cL0m4HDx0sFSfu0OTKQEV A6hNz1sN96QLgep4sKUSC5FTgzVC22qvm+LLtFN61PJ2qJTsveziEU7n9uvkOpv+AI AxrDZFaaELXH7L8VqZGm5w5n5Ohob9DC5BujtwSI1fZSdEbohCifVoi6SbNCUbHQ6D Z3sn9rEZs2huB/hR08O+8bnv9GKvhcXYgdmqH6LUk8a2tnJ31XELWWqMqkrA/S/dWt 9ZfSXgMQpjTuQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/R74c-oVDCFg-KIgyOwn4E_OsLs8 Subject: Re: [sipcore] SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:05:21 -0000 Rifaat, [as chair] Thanks for starting this! [as individual] comments inline On 8/18/14 2:19 PM, Rifaat Shekh-Yusef wrote: > Hi, > > During the discussion of the SIP OAuth proposal in Toronto, it was > decided that we need a list of use cases to make it clear what we are > trying to solve. > The following is some definitions and the use cases that I had in mind > when I started working on the SIP OAuth proposal. > > I know that others had different use cases in mind that they want the > new authorization framework to address. > > Regards, > Rifaat > > > Definitions > ----------- > > o Types of SIP services: > 1. Basic SIP Services: make/receive call, transfer, call forward, ... > 2. Advanced SIP Services: services provided by SIP application servers, e.g. > Voice Mail, What is the service that is being authorized? Presumably it is not the capturing of messages, because the entity with the credentials isn't involved in that. Is it the retrieval of messages? > Conference Services, Again, what is the service being authorized? Is it the creation of a scheduled conference? Is it proof of identity as one of the participants the creator of the conference wants to allow? > Video Services, What are video services that are different from conference services or "voice"mail? > Presence, What is being authorized? Is it publication of presence state? Subscription to presence state? (This is actually one of the clearer ones.) > IM, Again, what is the service? Do I need special permissions to set up an MSRP stream, or send a MESSAGE? (That seems odd. Do I need special permission to set up an RTP stream?) Is it access to a store/forward server for IMs? These questions may seem nit-picky, but for me they are needed to understand what sort of credentials are needed, by whom, and to determine if the entity that needs to provide something knows when and what they need to provide. > ... > > o Single Sign-On (SSO): SSO is a property that allows the user to be authenticated once and as a result have access to multiple services in the system. > > o Authentication: the process of verifying the identity of a user trying to get access to some network services. > > o Authorization: the process of controlling a user access to network services and the level of service provided to the user. > > > > Enterprise Use Cases > -------------------- > > 1. Corporate-wide SSO > > An enterprise is interested in providing its users with an SSO capability to > the corporate various services. > The enterprise has an authorization server for controlling the user access > to their network and would like to extend that existing authorization > server to control the user access to the various services provided by > their SIP network. > > The user is expected to provide his corporate credentials to login to the > corporate network and get different types of services, regardless of > the protocol used to provide the service, and without the need to > create different accounts for these different types of services. This one seems relatively clear and reasonable to me. > 2. SIP SSO > > An enterprise is interested in providing its users with an SSO capability to > the corporate various SIP services. > > The enterprise wants to control the services provided to their SIP users and > the level of service provided to the user by their SIP application servers > without the need to create different accounts for these services. > > The enterprise wants to utilize an existing authentication mechanism > provided by SIP, but would like to be able to control who gets access to > what service and when. > > The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the > services provided by the various SIP application servers without being > challenged to provide credentials for each type of service. IIUC, the intent here is that a user/device provides credentials to register, and then is not further involved. Various "services" are provisioned to be available to subsets of the enterprise users. An important consideration here is how those subsets are defined. > 3. Edge Authorization > > An enterprise is interested in authenticating and authorizing a remote user > trying to get access to services provided by the corporate SIP network. > > The enterprise would like to authenticate and authorize the remote user at the edge > of the network using a SIP network element that does not have direct access to > the SIP user account, e.g. SBC. The enterprise is also interested in providing > the user with an SSO capability to the corporate various SIP services. > > The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the > services provided by the various SIP application servers without being > challenged to provide credentials for each type of service. How is this different from (2)? To these I would like to add another: Internet-Wide SSO: A user wants to subscribe to sip services the same way he subscribes to web services - using his identity from one of the popular internet-wide authentication services. (E.g., Google+, Facebook, Disqus.) After that, all that is needed to gain access to those services is to log his device in to the chosen authentication service. Thanks, Paul From nobody Tue Aug 19 09:04:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F071A0444 for ; Tue, 19 Aug 2014 09:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEgAVguThxMD for ; Tue, 19 Aug 2014 09:04:55 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBD11A0432 for ; Tue, 19 Aug 2014 09:04:54 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id e131so4752219oig.40 for ; Tue, 19 Aug 2014 09:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1Kc8Oa8y2KeClNmZOESHtP89EU/GmwjZrY5TuCElTXg=; b=AzluOjwotEhl6GELMEbsZGyayG/ZTEnpQFiqhV27J/RK24TZp03i8kqAtBZgNgrYmp BjGHJxIedlpQ0oYCmNgu6Ri+gytQBRQhblVqFvO2Xsue20Vl1RSQHE5RPY6Tjot4N8fD BfKb4XVHoSMjFcvHKpLBbrNjvdX8m3lHPqbRY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1Kc8Oa8y2KeClNmZOESHtP89EU/GmwjZrY5TuCElTXg=; b=MCdc+nDWTdxywbrlzHbtP6AwuEVRKv7PGfm1+8oLaow9VjqR0kcHBYBkCYEfeR0GTq KS7Q7mvfwVsQPwfxhqDaCA+PFKjJxNzT+gIBGncFBYlNhIBVqiEKOUgp14dxuF7/AGFB 728tg+qW5iEk6kIV9c4nCiokigCxxL9xMzYfM6NbK3CYvXYPMm42kVfzXbNZgiRCa3AL SbaEQ8pi5qAhXa/nzWAtgvXykqu3+YbGOdEd8Nmv8i34yyzfi4hbbZLd1qY/YkOtMjQS fqS0/tr1/fcCrSnC0RNdnXC4l3zxxtnt5EjCDp8snqxhUd0R3tpMb0m2ayjyKVoU01Vq PTaA== X-Gm-Message-State: ALoCoQlw5S/QaZ25W+kddd1TwwOBQFreHpYN69rclvOU+lvPfYYSz1RxyoYUL4iQRltXQHQz7l1O X-Received: by 10.182.245.135 with SMTP id xo7mr44133924obc.23.1408464294206; Tue, 19 Aug 2014 09:04:54 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id d11sm21808160obs.26.2014.08.19.09.04.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 09:04:53 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DA4B4E8E-939C-4423-B24E-6756F892D1EF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Matt Ryan In-Reply-To: Date: Tue, 19 Aug 2014 10:04:51 -0600 Message-Id: References: To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/J-NWyYCRJbq-Vxm7idX5bcgmCmk Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:04:57 -0000 --Apple-Mail=_DA4B4E8E-939C-4423-B24E-6756F892D1EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I have included some comments inline below. On Aug 18, 2014, at 12:19 PM, Rifaat Shekh-Yusef = wrote: > Hi, >=20 > During the discussion of the SIP OAuth proposal in Toronto, it was = decided that we need a list of use cases to make it clear what we are = trying to solve. > The following is some definitions and the use cases that I had in mind = when I started working on the SIP OAuth proposal. >=20 > I know that others had different use cases in mind that they want the = new authorization framework to address. >=20 I was one who volunteered to offer a use case or two. I have been = working on this (amidst summer holidays) and hope to have something to = provide within the next day or so. > Regards, > Rifaat >=20 >=20 > Definitions > ----------- >=20 > o Types of SIP services: > 1. Basic SIP Services: make/receive call, transfer, call forward, = ... > 2. Advanced SIP Services: services provided by SIP application = servers, e.g. Voice Mail, Conference Services, Video Services, Presence, = IM, ... >=20 > o Single Sign-On (SSO): SSO is a property that allows the user to be = authenticated once and as a result have access to multiple services in = the system. >=20 > o Authentication: the process of verifying the identity of a user = trying to get access to some network services. >=20 > o Authorization: the process of controlling a user access to network = services and the level of service provided to the user. >=20 As I=92ve been considering example cases, I came up with five different = tests that I think must apply before any use case can be a valid SIP = OAuth use case. 1. The scenario must be about authorization, not authentication. = Authorization is about determining whether a specific user-agent may = access a resource or perform a function. Authentication is about = determining whether the user of a user-agent is really who the user = claims to be. Authentication is about credentials and identity. = Authorization is about permission and rights. OAuth is for = authorization, not authentication. It is about controlling access to = resources, not about minimizing the number of credentials a user has to = manage (that is e.g. OpenID). 2. There needs to be a protected resource that the end-user owns and = manages, but the client does not normally have access to, and there must = be a real value to the end-user to be able to manage the relationships = separately. "The relationships" here mean the relationship between the = end-user and the client, and the end-user and the server. There needs = to be a reason why there is value to the end-user that these each be = managed separately instead of together. 3. The scenario must be about an end-user granting a client = *restricted* access to the protected resource. If the access to the = protected resource is unlimited, there is no point to OAuth - the = end-user may as well simply provide to the client the end-user's = credentials to access the protected resource. 4. At the time the end-user approves the request the client has made, = or will make, of the server to access the protected resource, the = end-user must be able to be presented with a verifiable conversation = with the server wherein the approval is given. So there are two parts = to this test. The first is that the conversation has to be able to take = place where the server asks the end-user if it is okay that the client = obtain the authorization being requested. The second part is that the = end-user needs to be able to trust that the conversation is between the = end-user and the server, not with the client or a man-in-the-middle or = whatever. 5. Finally, there needs to be a justifiable reason why the client = wishes to communicate with the server via SIP rather than HTTP. = Performing the OAuth negotiation is a solved problem in HTTP, so if that = is a reasonable option the application developer will choose HTTP. The = scenario needs to demonstrate a reason why using SIP is required, or at = least preferred. The first four tests are basic OAuth tests - they must all be relevant = to the use case for OAuth to be justified. The fifth use case is = relevant to SIP OAuth, which is what this draft is about. SSO is just a variant of Authentication. It has to do with allowing a = single credential to authenticate a user to a multitude of services = without requiring the user to remember multiple credentials or reenter = the same credentials all the time. There are a number of SSO solutions = available today, but as I understand it OAuth is not one of them. >=20 >=20 > Enterprise Use Cases > -------------------- >=20 > 1. Corporate-wide SSO >=20 > An enterprise is interested in providing its users with an SSO = capability to > the corporate various services. > The enterprise has an authorization server for controlling the user = access > to their network and would like to extend that existing authorization > server to control the user access to the various services provided by > their SIP network. >=20 > The user is expected to provide his corporate credentials to login to = the > corporate network and get different types of services, regardless of > the protocol used to provide the service, and without the need to > create different accounts for these different types of services. This is an authentication / SSO use case. Can you explain why OAuth is = a solution to this problem? =20 >=20 >=20 > 2. SIP SSO >=20 > An enterprise is interested in providing its users with an SSO = capability to > the corporate various SIP services. >=20 > The enterprise wants to control the services provided to their SIP = users and > the level of service provided to the user by their SIP application = servers > without the need to create different accounts for these services. >=20 > The enterprise wants to utilize an existing authentication mechanism > provided by SIP, but would like to be able to control who gets access = to > what service and when. >=20 > The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the > services provided by the various SIP application servers without being > challenged to provide credentials for each type of service. >=20 Same question - this is an authentication / SSO use case. Can you = explain why OAuth is a solution to this problem? >=20 > 3. Edge Authorization >=20 > An enterprise is interested in authenticating and authorizing a remote = user > trying to get access to services provided by the corporate SIP = network. >=20 > The enterprise would like to authenticate and authorize the remote = user at the edge > of the network using a SIP network element that does not have direct = access to > the SIP user account, e.g. SBC. The enterprise is also interested in = providing > the user with an SSO capability to the corporate various SIP services. >=20 > The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the > services provided by the various SIP application servers without being > challenged to provide credentials for each type of service. This sounds like an authentication issue again, not an authorization = issue. The use case is centered around using a single set of = credentials to obtain access to each service. Additionally, in these use cases all of the resources are controlled by = the same enterprise. The value of OAuth is that it allows a resource = owner to authorize restricted access by a client to a resource managed = by a distinct resource server. This is presumably because the resource = owner has a different level of trust with each entity - otherwise, the = resource owner could grant unrestricted access to the resource. If both = the client and the resource are controlled by the same enterprise, the = resource owner already has a trust relationship with the enterprise, so = implementing OAuth seems unnecessary to me. Can you help me understand why using OAuth is necessary here? Why would = the enterprise not just offer unrestricted access between all of the = services, once the user has authenticated? > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore Matt Ryan Code Slinger | Jive Communications, Inc. Jive.com | 801.762.6281 | mryan at getjive dot com --Apple-Mail=_DA4B4E8E-939C-4423-B24E-6756F892D1EF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT83WjAAoJEPyFiw1u4O0cKI0IAKK9yyhyTAz6fkYsteSD5SBQ xaM1Vk3MBkPJrWpxh1gI7vBITrYRnbtIeT3Jnvu1gXhnaDZMyQ/BYgLwioFf5Kib AmCO8aHvRdJG09zXAs9lgl3yBypevyVxnzk6VV7JA4M2EkKPLRe1Gn/oVT++RK0M QjaYj9KCmJyQZxEAHjY8JwudjX3hbqKG0GnizzXhUz/W36VsP93wFvSMWWJDbJBH 88Ulc4gYfDCa97NRpQtulKYMDSJBWwrtIbnIJafrMflkC8Ysmmm8HVVKWrjAz+sr 7mXsoUTWjkgqTfotM+8o47pjskAjFY82PnkfBIaJK3ZcGRGq5wzgTZx8k0PtWMQ= =g31I -----END PGP SIGNATURE----- --Apple-Mail=_DA4B4E8E-939C-4423-B24E-6756F892D1EF-- From nobody Tue Aug 19 11:33:00 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215691A06A1 for ; Tue, 19 Aug 2014 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 499tmh58GaSu for ; Tue, 19 Aug 2014 11:32:58 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id F36141A0676 for ; Tue, 19 Aug 2014 11:32:57 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta08.westchester.pa.mail.comcast.net with comcast id giXG1o0020mv7h058iYxqw; Tue, 19 Aug 2014 18:32:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta11.westchester.pa.mail.comcast.net with comcast id giYx1o0053Ge9ey3XiYxtB; Tue, 19 Aug 2014 18:32:57 +0000 Message-ID: <53F39858.9000106@alum.mit.edu> Date: Tue, 19 Aug 2014 14:32:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <78CFBBA55ECDC0ietf.shinji@gmail.com> In-Reply-To: <78CFBBA55ECDC0ietf.shinji@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408473177; bh=QQMCbsf4i8RhWW1UhUExt+iSiCFFOBAcN4SWb/0CI44=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J+Y6LuaI6IRQYD0fJmlYQFDOQCCQJSMrOTD2C+RgvmdV9+edkCel+Jh7klc1DyiTy K4nim0GADr/nchTjpluYMn9nl8Xr8rzA1YZ+Wapr4UClt1qWJ0dHuWwAf77hof35BS XSQMxdXLneJ4FvsJ8gqPZT1j/qwQg4d+goeiGD9qsqy+CzdBMSIr0CsJYdll6a0xHz 2k5reg4wEmHzOkvbKOyEOhXx2qDhy/RObyf/F+/I+fY/kL9IQZauNZFCfgvj6uMLm4 sfJX/WmsqUnD0XhDPU+IRYovUc9XD7I8tUqjwFA0R/E5jCM35wvKrgeJqtbd0N/+iV hxxUB2P7o4w4Q== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/9RnChLR1gHFkrUSG9Y_Lg-ZQlkk Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 18:32:59 -0000 Hi Shinji, On 8/19/14 8:01 AM, OKUMURA Shinji wrote: > Hi, > >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/ > > I have any questions. > > 1) > I think that refer subscription should be created before sending REFER with "explicitsub". > If a referee receives SUBSCRIBE after ending of procedure for refer, what does the referee notify? > > 2) > Does SUBSCRIBE contain Target-Dialog(-like) header? I think I see your point, but your suggestion presents some difficulties. What is the target for the subscribe? In Robert's proposal the refer target returns a uri, which in concept identifies the state of the refer. To address your question about this, I guess it just maintain sufficient state about the refer to send notifications once the subscribe arrives. This may require some buffering. With your suggestion I guess the subscribe target must be the same as the target for the REFER. That requires that such a subscription be allowed even though no REFER has been received. And it must be allowed from anyone who would be allowed to send a REFER, not just from the source that actually sent a refer. Both ways have problems. Which are worse? Thanks, Paul From nobody Tue Aug 19 13:05:37 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720951A0AEF for ; Tue, 19 Aug 2014 13:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smDHkunPl7B6 for ; Tue, 19 Aug 2014 13:05:34 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id B2E041A0AD3 for ; Tue, 19 Aug 2014 13:05:33 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta06.westchester.pa.mail.comcast.net with comcast id gh2a1o0011GhbT856k5Zgc; Tue, 19 Aug 2014 20:05:33 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta07.westchester.pa.mail.comcast.net with comcast id gk5Y1o00P1KKtkw3Tk5YQK; Tue, 19 Aug 2014 20:05:33 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s7JK5Vju024049; Tue, 19 Aug 2014 16:05:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s7JK5VOd024048; Tue, 19 Aug 2014 16:05:31 -0400 Date: Tue, 19 Aug 2014 16:05:31 -0400 Message-Id: <201408192005.s7JK5VOd024048@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef In-reply-to: (rifaat.ietf@gmail.com) References: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408478733; bh=zefUWfBsg5AiiNULlzc8tzRKvq+W1zad5hJfxotpdbI=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=lC1NrLd0XiqMQ/4n8Gy7v3A1MCKzXXe9nMAfiNcFejkgFjT3kctOTlqYb3J6Ko/QV bIRgyJ5NJ+xE+kSK5+CWS1miaU7tXLWYbrOyfD3CXk7L0ED9kgXhaotHJ7y6ZkhThs /jdaw5zyLypDzpYGSVWs9keorxTgPvSTbVX6D5UJRr2Mrp0co6Q3D2/fDlcR2XkLKQ qMCFg7LIXNNd2W8O8bPQp6RxF+fdOZlIt5PxaLdD210e3ZI3JJRWOs3KET9PTKNXrm tLodIb3hf3H7AM+fZKDyLevI7bToF21tyCEDeiHPQQ/BbEk9/+Nugk7HBb5uzimmgv CzWY1o78CYWIA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/vc4NylUXsLl_cU8mI7c0zQq25fs Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 20:05:35 -0000 > From: Rifaat Shekh-Yusef > 1. Corporate-wide SSO > > An enterprise is interested in providing its users with an SSO capability to > the corporate various services. > The enterprise has an authorization server for controlling the user access > to their network and would like to extend that existing authorization > server to control the user access to the various services provided by > their SIP network. > > The user is expected to provide his corporate credentials to login to the > corporate network and get different types of services, regardless of > the protocol used to provide the service, and without the need to > create different accounts for these different types of services. In most of your cases, you speak of "services" or "types of services". But I think that a central element of your envisioned use-case is that each *service* is provided by a specific *application server*, that is, a separate processing device. And that many of the issues of authentication have to do with the fact that the application server is not integrated with the rest of the SIP system. E.g., - We don't want to require the application server to have a complete database of all SIP users that are allowed to use the server (with their credentials). - We don't want to require the UA to present its credentials individually to both the SIP system and to every application server involved in a particular call. Otherwise, if a "service" is just some feature of the PBX, there is no interesting authentication problem -- the UA authenticates itself to the PBX, and the PBX knows what services the UA is allowed to use. I think it would help if this assumption was made more explicit. Dale From nobody Tue Aug 19 19:37:03 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6623C1A8766 for ; Tue, 19 Aug 2014 19:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvSWi-Yy281H for ; Tue, 19 Aug 2014 19:37:00 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229C01A04AC for ; Tue, 19 Aug 2014 19:37:00 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so10922092pdb.27 for ; Tue, 19 Aug 2014 19:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=Xof8PcIRwOp2RZz+elw+bZi1sO67KdcHZkVixYnOuIs=; b=mRH4Zh5Jxg8M8yl84ZP+Vn3sdDox54j2vFkOSVvmD78E/U8e04I/3LDvW9zCXTA2a2 W7b4p9XoBkf3xGbRg6yDL0D+ki6rt3HOrrcYqmx3cQKkiKZyNPOXico1u9PhIu6sbJub xcl5xdi1JDsWxnnLhIpVMWVugNYGKGGcf8KjoFL/7byoYmGIu3wXDIDtX8sPgpxpU96u l5sovQp8M2m8/prcMagjyOrYlTWtu1pPT0ivRo1YkLm/RlgseZ/YMjr7u2ZbIbqyg0Te ZBZUOKRclMUWvIhxiBILhC5QnsKpu7f2DCUOF8l2IrausFWUjGCe65XzzAjM8zKF+MCI /xMA== X-Received: by 10.68.223.138 with SMTP id qu10mr48589484pbc.45.1408502219791; Tue, 19 Aug 2014 19:36:59 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id kl1sm20708683pbd.31.2014.08.19.19.36.58 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Aug 2014 19:36:59 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org Date: Wed, 20 Aug 2014 11:36:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <53F39858.9000106@alum.mit.edu> References: <78CFBBA55ECDC0ietf.shinji@gmail.com> <53F39858.9000106@alum.mit.edu> Message-Id: Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Lzt7LA6j5y_KyLGyB43vWljhGGc Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 02:37:01 -0000 Hi Paul, Thanks for your reply. My comment inline. >Hi Shinji, > >On 8/19/14 8:01 AM, OKUMURA Shinji wrote: >> Hi, >> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit- >>> subscription/ >> >> I have any questions. >> >> 1) >> I think that refer subscription should be created before sending REFER with >> "explicitsub". >> If a referee receives SUBSCRIBE after ending of procedure for refer, what >> does the referee notify? >> >> 2) >> Does SUBSCRIBE contain Target-Dialog(-like) header? > >I think I see your point, but your suggestion presents some difficulties. > >What is the target for the subscribe? > >In Robert's proposal the refer target returns a uri, which in concept >identifies the state of the refer. To address your question about this, IIUC you say SUBSCRIBE has an refer-id-token that is issued by a referee(notifier). My cloudy idea is that REFER and SUBSCRIBE have a same subscribe-id-token that is issued by a subscriber or notifier. >I guess it just maintain sufficient state about the refer to send >notifications once the subscribe arrives. This may require some buffering. I've been afraid someone says "buffering". What does the buffering belong to? How long is the life of the buffering? Does the buffering have a state machine? >From a implementation perspective, it seems to be almost a subscription. >With your suggestion I guess the subscribe target must be the same as >the target for the REFER. That requires that such a subscription be >allowed even though no REFER has been received. And it must be allowed >from anyone who would be allowed to send a REFER, not just from the >source that actually sent a refer. I see the need for an authorization. It is one of further considerations. >Both ways have problems. Which are worse? I only wish not to implement the subscription-like buffer. > Thanks, > Paul From nobody Tue Aug 19 19:57:16 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7321A0BEB for ; Tue, 19 Aug 2014 19:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrA0bHjLRHB4 for ; Tue, 19 Aug 2014 19:57:13 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 006911A0B82 for ; Tue, 19 Aug 2014 19:57:12 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so10475583pdj.8 for ; Tue, 19 Aug 2014 19:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=9wr2Hqo2w9cw4pYmDfkPTevWlYb9M34BplUys/wEtVE=; b=S+AF3LmEsOFh15UUisftSF1qn7/pw9xpml1opYU76gNGRsW5H/x9huqDotGao3onfo NYuzTKB8m0lWKCXqxy2doUI0xxb7hxlAHisB+iD8WOeg9XlfUZ1ZKc9Xm7dCslsdPbk/ Xe2J7CIEXa67D2uT8QH2lIhcmVwEgRQGec510GO8/uWTQiP9KykjDSPLRgVzvD5qOeel XVtgqpaf24cB3HBeKuGV4nHX7VzrZ2/UsyJEfOOvF+RdS7wRVg6bkYFqgbdimfo+MNRt WqDJPVlpYGE+lhnI5Dygj0HTpeSRULrT2JBKv6ILvv2CZoEeDkTdkrPsFwlGusi9G10p FAHg== X-Received: by 10.70.134.165 with SMTP id pl5mr54491192pdb.20.1408503428765; Tue, 19 Aug 2014 19:57:08 -0700 (PDT) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id ey1sm75217067pab.19.2014.08.19.19.57.07 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Aug 2014 19:57:08 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org Date: Wed, 20 Aug 2014 11:57:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <53F39858.9000106@alum.mit.edu> References: <78CFBBA55ECDC0ietf.shinji@gmail.com> <53F39858.9000106@alum.mit.edu> Message-Id: Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/IM8ps_uCUP3yUf7M7slAZ89__A4 Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 02:57:14 -0000 Hi Paul, I just come up with another approach. A referrer send REFER within an existing dialog. And a notifier(referee) send NOTIFY within new dialog. Of course Request URI of NOTIFY is a GRUU of a referrer. It seems to be a simple solution for an avoidance of dialog-reuse. I think this option(Required: subscription-newdialog?) is available for not only REFER but also SUBSCRIBE. Regards, Shinji >Hi Shinji, > >On 8/19/14 8:01 AM, OKUMURA Shinji wrote: >> Hi, >> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit- >>> subscription/ >> >> I have any questions. >> >> 1) >> I think that refer subscription should be created before sending REFER with >> "explicitsub". >> If a referee receives SUBSCRIBE after ending of procedure for refer, what >> does the referee notify? >> >> 2) >> Does SUBSCRIBE contain Target-Dialog(-like) header? > >I think I see your point, but your suggestion presents some difficulties. > >What is the target for the subscribe? > >In Robert's proposal the refer target returns a uri, which in concept >identifies the state of the refer. To address your question about this, >I guess it just maintain sufficient state about the refer to send >notifications once the subscribe arrives. This may require some buffering. > >With your suggestion I guess the subscribe target must be the same as >the target for the REFER. That requires that such a subscription be >allowed even though no REFER has been received. And it must be allowed >from anyone who would be allowed to send a REFER, not just from the >source that actually sent a refer. > >Both ways have problems. Which are worse? > > Thanks, > Paul From nobody Fri Aug 22 05:59:56 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D4E1A031B for ; Fri, 22 Aug 2014 05:59:54 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id penU7JyUCPMc for ; Fri, 22 Aug 2014 05:59:51 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6D41A030F for ; Fri, 22 Aug 2014 05:59:50 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so10045292lab.36 for ; Fri, 22 Aug 2014 05:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cc5mDl9mjTWjvHTWomZkJ6dh5igDcL3BB4TbFbpPlq0=; b=SBir3PKPOor27sZj+HePE/gk+2w0M/5ahFqc8NASF7Jv/edZhyURXfZn32wmFBqD4e +TugLs/RdR/74AAtEP24JzYPy+QwqfgfrRSsEnsozKq0n4APKhEsyEzHdLU+sSnl2/js 7TzoA41AdesztdGnH7gYC8f7nf42wTV89FL5IWVjEfUd6hMN32TaYvpw0EerjnZorc4B 4+pqW3uKJSeMsh6hG3kldX5Bm6XulsUtOh065E8opIi89rTPJGPCgIDSaRNvVG+Ne7uE +F7dNMkiq2s4rB7ldHqFy0W/Cw5TWs6Iv7kFehBzmU49BC9xTXq2Yj3W6F7JJ+r6Z6vI JCvw== MIME-Version: 1.0 X-Received: by 10.112.129.228 with SMTP id nz4mr4390678lbb.9.1408712389404; Fri, 22 Aug 2014 05:59:49 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Fri, 22 Aug 2014 05:59:49 -0700 (PDT) In-Reply-To: <53F367A0.1010004@alum.mit.edu> References: <53F367A0.1010004@alum.mit.edu> Date: Fri, 22 Aug 2014 08:59:49 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b3a83ae8fcc1d050137695a Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/qA81TQg26R1U1gCHVLWRKpba0Jo Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 12:59:54 -0000 --047d7b3a83ae8fcc1d050137695a Content-Type: text/plain; charset=ISO-8859-1 Paul, Thanks for your comments. Please, see my reply inline... Regards, Rifaat On Tue, Aug 19, 2014 at 11:05 AM, Paul Kyzivat wrote: > Rifaat, > > [as chair] Thanks for starting this! > > [as individual] comments inline > > > On 8/18/14 2:19 PM, Rifaat Shekh-Yusef wrote: > >> Hi, >> >> During the discussion of the SIP OAuth proposal in Toronto, it was >> decided that we need a list of use cases to make it clear what we are >> trying to solve. >> The following is some definitions and the use cases that I had in mind >> when I started working on the SIP OAuth proposal. >> >> I know that others had different use cases in mind that they want the >> new authorization framework to address. >> >> Regards, >> Rifaat >> >> >> Definitions >> ----------- >> >> o Types of SIP services: >> 1. Basic SIP Services: make/receive call, transfer, call forward, ... >> 2. Advanced SIP Services: services provided by SIP application >> servers, e.g. >> Voice Mail, >> > > What is the service that is being authorized? > Presumably it is not the capturing of messages, because the entity with > the credentials isn't involved in that. > Is it the retrieval of messages? > > Correct. > Conference Services, >> > > Again, what is the service being authorized? > Is it the creation of a scheduled conference? > Is it proof of identity as one of the participants the creator of the > conference wants to allow? > > I was thinking of the creation of a conference. But authenticating the identity of the participant is an interesting one; I need to think about that. > Video Services, >> > > What are video services that are different from conference services or > "voice"mail? > > Yeah, this is related to conference service. > Presence, >> > > What is being authorized? > Is it publication of presence state? > Subscription to presence state? > (This is actually one of the clearer ones.) > > I was thinking mainly about the subscription to presence state of the contacts. > IM, >> > > Again, what is the service? > Do I need special permissions to set up an MSRP stream, > or send a MESSAGE? (That seems odd. Do I need special permission to set up > an RTP stream?) > Is it access to a store/forward server for IMs? > > The level of control can vary, as this is typically not specified in a standard, but left as an implementation detail. The protocol should only provide the framework to enable that control. > These questions may seem nit-picky, but for me they are needed to > understand what sort of credentials are needed, by whom, and to determine > if the entity that needs to provide something knows when and what they need > to provide. > > > ... >> >> o Single Sign-On (SSO): SSO is a property that allows the user to be >> authenticated once and as a result have access to multiple services in the >> system. >> >> o Authentication: the process of verifying the identity of a user trying >> to get access to some network services. >> >> o Authorization: the process of controlling a user access to network >> services and the level of service provided to the user. >> >> >> >> Enterprise Use Cases >> -------------------- >> >> 1. Corporate-wide SSO >> >> An enterprise is interested in providing its users with an SSO capability >> to >> the corporate various services. >> The enterprise has an authorization server for controlling the user access >> to their network and would like to extend that existing authorization >> server to control the user access to the various services provided by >> their SIP network. >> >> The user is expected to provide his corporate credentials to login to the >> corporate network and get different types of services, regardless of >> the protocol used to provide the service, and without the need to >> create different accounts for these different types of services. >> > > This one seems relatively clear and reasonable to me. > > > 2. SIP SSO >> >> An enterprise is interested in providing its users with an SSO capability >> to >> the corporate various SIP services. >> >> The enterprise wants to control the services provided to their SIP users >> and >> the level of service provided to the user by their SIP application servers >> without the need to create different accounts for these services. >> >> The enterprise wants to utilize an existing authentication mechanism >> provided by SIP, but would like to be able to control who gets access to >> what service and when. >> >> The user is expected to use his SIP credentials to login to the SIP >> network and get access to the basic services, and to get access to the >> services provided by the various SIP application servers without being >> challenged to provide credentials for each type of service. >> > > IIUC, the intent here is that a user/device provides credentials to > register, and then is not further involved. I was thinking of a user providing credentials, not device. Do you see a use case where you need a device to provide credentials? > Various "services" are provisioned to be available to subsets of the > enterprise users. > > Yes, the user authenticates once, and gets an access token that is specific for him. The access token has a scope associated with it that controls the services and the level of service provided to that user. > An important consideration here is how those subsets are defined. > > These are typically not specified in the framework, but left to the implementation to decided on the level of control the system needs. > > 3. Edge Authorization >> >> An enterprise is interested in authenticating and authorizing a remote >> user >> trying to get access to services provided by the corporate SIP network. >> >> The enterprise would like to authenticate and authorize the remote user >> at the edge >> of the network using a SIP network element that does not have direct >> access to >> the SIP user account, e.g. SBC. The enterprise is also interested in >> providing >> the user with an SSO capability to the corporate various SIP services. >> >> The user is expected to use his SIP credentials to login to the SIP >> network and get access to the basic services, and to get access to the >> services provided by the various SIP application servers without being >> challenged to provide credentials for each type of service. >> > > How is this different from (2)? > > In (2) the endpoint authenticates directly to the authorization service that has access to the user's credentials. With this use case, the edge device does not have that access, and needs to communicate with the authorization server to authenticate the user. > To these I would like to add another: > > Internet-Wide SSO: > > A user wants to subscribe to sip services the same way he subscribes to > web services - using his identity from one of the popular internet-wide > authentication services. (E.g., Google+, Facebook, Disqus.) > > After that, all that is needed to gain access to those services is to log > his device in to the chosen authentication service. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --047d7b3a83ae8fcc1d050137695a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Paul,

Thanks for your comments.
Please, see my reply inline...

Regards,
=A0Rifaat



On Tue, Aug 19, 2014 at 11:05 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<= /a>> wrote:
Rifaat,

[as chair] Thanks for starting this!

[as individual] comments inline


On 8/18/14 2:19 PM, Rifaat Shekh-Yusef wrote:
Hi,

During the discussion of the SIP OAuth proposal in Toronto, it was
decided that we need a list of use cases to make it clear what we are
trying to solve.
The following is some definitions and the use cases that I had in mind
when I started working on the SIP OAuth proposal.

I know that others had different use cases in mind that they want the
new authorization framework to address.

Regards,
=A0 Rifaat


Definitions
-----------

o Types of SIP services:
=A0 =A01. Basic SIP Services: make/receive call, transfer, call forward, ..= .
=A0 =A02. Advanced SIP Services: services provided by SIP application serve= rs, e.g.
Voice Mail,

What is the service that is being authorized?
Presumably it is not the capturing of messages, because the entity with the= credentials isn't involved in that.
Is it the retrieval of messages?


Correct.

=A0<= /div>
Conference Services,

Again, what is the service being authorized?
Is it the creation of a scheduled conference?
Is it proof of identity as one of the participants the creator of the confe= rence wants to allow?


I was thinking of the creation of a co= nference.
But authenticating the identity of the participant is a= n interesting one; I need to think about that.

=A0
Video Services,

What are video services that are different from conference services or &quo= t;voice"mail?

Yeah, this is related to conference service.

=A0
Presence,

What is being authorized?
Is it publication of presence state?
Subscription to presence state?
(This is actually one of the clearer ones.)


I was thinking mainly about the subscr= iption to presence state of the contacts.

=A0
IM,

Again, what is the service?
Do I need special permissions to set up an MSRP stream,
or send a MESSAGE? (That seems odd. Do I need special permission to set up = an RTP stream?)
Is it access to a store/forward server for IMs?


The level of control can vary, as this= is typically not specified in a standard, but left as an implementation de= tail.
The protocol should only provide the framework to enable th= at control.

=A0
These questions may seem nit-picky, but for me they are needed to understan= d what sort of credentials are needed, by whom, and to determine if the ent= ity that needs to provide something knows when and what they need to provid= e.


...

o Single Sign-On (SSO): SSO is a property that allows the user to be authen= ticated once and as a result have access to multiple services in the system= .

o Authentication: the process of verifying the identity of a user trying to= get access to some network services.

o Authorization: the process of controlling a user access to network servic= es and the level of service provided to the user.



Enterprise Use Cases
--------------------

1. Corporate-wide SSO

An enterprise is interested in providing its users with an SSO capability t= o
the corporate various services.
The enterprise has an authorization server for controlling the user access<= br> to their network and would like to extend that existing authorization
server to control the user access to the various services provided by
their SIP network.

The user is expected to provide his corporate credentials to login to the corporate network and get different types of services, regardless of
the protocol used to provide the service, and without the need to
create different accounts for these different types of services.

This one seems relatively clear and reasonable to me.


2. SIP SSO

An enterprise is interested in providing its users with an SSO capability t= o
the corporate various SIP services.

The enterprise wants to control the services provided to their SIP users an= d
the level of service provided to the user by their SIP application servers<= br> without the need to create different accounts for these services.

The enterprise wants to utilize an existing authentication mechanism
provided by SIP, but would like to be able to control who gets access to what service and when.

The user is expected to use his SIP credentials to login to the SIP
network and get access to the basic services, and to get access to the
services provided by the various SIP application servers without being
challenged to provide credentials for each type of service.

IIUC, the intent here is that a user/device provides credentials to registe= r, and then is not further involved.

I was= thinking of a user providing credentials, not device. Do you see a use cas= e where you need a device to provide credentials?

=A0
Various "services" = are provisioned to be available to subsets of the enterprise users.


Yes, the user authenticates once, and = gets an access token that is specific for him.
The access token h= as a scope associated with it that controls the services and the level of s= ervice provided to that user.

=A0
An important consideration here is how those subsets are defined.

<= /div>

These are typically not specified in = the framework, but left to the implementation to decided on the level of co= ntrol the system needs.

=A0

3. Edge Authorization

An enterprise is interested in authenticating and authorizing a remote user=
trying to get access to services provided by the corporate SIP network.

The enterprise would like to authenticate and authorize the remote user at = the edge
of the network using a SIP network element that does not have direct access= to
the SIP user account, e.g. SBC. The enterprise is also interested in provid= ing
the user with an SSO capability to the corporate various SIP services.

The user is expected to use his SIP credentials to login to the SIP
network and get access to the basic services, and to get access to the
services provided by the various SIP application servers without being
challenged to provide credentials for each type of service.

How is this different from (2)?


In (2) the endpoint authenticates dire= ctly to the authorization service that has access to the user's credent= ials.
With this use case, the edge device does not have that acce= ss, and needs to communicate with the authorization server to authenticate = the user.

=A0
To these I would like to add another:

Internet-Wide SSO:

A user wants to subscribe to sip services the same way he subscribes to web= services - using his identity from one of the popular internet-wide authen= tication services. (E.g., Google+, Facebook, Disqus.)

After that, all that is needed to gain access to those services is to log h= is device in to the chosen authentication service.

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

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

--047d7b3a83ae8fcc1d050137695a-- From nobody Fri Aug 22 06:19:04 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393361A026E for ; Fri, 22 Aug 2014 06:19:01 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyB3GhhfZ8Mi for ; Fri, 22 Aug 2014 06:18:56 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36201A037B for ; Fri, 22 Aug 2014 06:18:55 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id pv20so10067413lab.1 for ; Fri, 22 Aug 2014 06:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OWaBpJ0SB3t/6GwnHsR/HiDiigTGnXWAIsTFZ40ZKvs=; b=pROYLj/gexkpKQP5lQJCSEfmZdRMiZiDSitKTMey+fTZ/9ZRUY/bn1AobmZODQyHK3 Kf8dZkrHDeWFxMkPywTA6HEb/LmGgz7w5vwZuAHb4vh3T56O4fBXWUFwEsIcdYsUZJTi 61HrMLc8sTK+og5QzgnDicSFbQi3GHpMwmfUvlAj12RNEm/w835vdDFGBSPMciD2AK3r M380FKD9+KCK/ZaZrYCkYQHNIg7wwh/9oKAr0a+jD6TNRuWxJ7HOrr2AsnT1wYCPsXf6 aNByMQVT8wHR/mrYt0+wF6dLrPls3GflTNwj6cKzJMlH99qnk4xN75q4BhNGLxZsIKy5 s36g== MIME-Version: 1.0 X-Received: by 10.112.156.10 with SMTP id wa10mr4592770lbb.68.1408713533982; Fri, 22 Aug 2014 06:18:53 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Fri, 22 Aug 2014 06:18:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Aug 2014 09:18:53 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Matt Ryan Content-Type: multipart/alternative; boundary=089e01160952c88d9c050137adac Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/sYaFD2_kNXGqnffJEq3mj4xL-tE Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 13:19:01 -0000 --089e01160952c88d9c050137adac Content-Type: text/plain; charset=ISO-8859-1 Hi Matt, Notice that this thread is not trying to discuss the solution, but to collect use cases. I did not mention SIP OAuth in the definition or the use cases description. But let me try to address some of your comments below. See my reply inline... Regards, Rifaat On Tue, Aug 19, 2014 at 12:04 PM, Matt Ryan wrote: > Hi, > > I have included some comments inline below. > > > On Aug 18, 2014, at 12:19 PM, Rifaat Shekh-Yusef > wrote: > > > Hi, > > > > During the discussion of the SIP OAuth proposal in Toronto, it was > decided that we need a list of use cases to make it clear what we are > trying to solve. > > The following is some definitions and the use cases that I had in mind > when I started working on the SIP OAuth proposal. > > > > I know that others had different use cases in mind that they want the > new authorization framework to address. > > > > > I was one who volunteered to offer a use case or two. I have been working > on this (amidst summer holidays) and hope to have something to provide > within the next day or so. > > > > Regards, > > Rifaat > > > > > > Definitions > > ----------- > > > > o Types of SIP services: > > 1. Basic SIP Services: make/receive call, transfer, call forward, ... > > 2. Advanced SIP Services: services provided by SIP application > servers, e.g. Voice Mail, Conference Services, Video Services, Presence, > IM, ... > > > > o Single Sign-On (SSO): SSO is a property that allows the user to be > authenticated once and as a result have access to multiple services in the > system. > > > > o Authentication: the process of verifying the identity of a user trying > to get access to some network services. > > > > o Authorization: the process of controlling a user access to network > services and the level of service provided to the user. > > > > As I've been considering example cases, I came up with five different > tests that I think must apply before any use case can be a valid SIP OAuth > use case. > > 1. The scenario must be about authorization, not authentication. > Authorization is about determining whether a specific user-agent may access > a resource or perform a function. Authentication is about determining > whether the user of a user-agent is really who the user claims to be. > Authentication is about credentials and identity. Authorization is about > permission and rights. OAuth is for authorization, not authentication. It > is about controlling access to resources, not about minimizing the number > of credentials a user has to manage (that is e.g. OpenID). > Well, I think it is about both: controlling access to resources, and using a single credentials to grant access to different resources. With OAuth 2.0 you could use, for example, your Facebook account to grant access to your resources on different sites, instead of creating different account for each site that provides you with some service. > 2. There needs to be a protected resource that the end-user owns and > manages, but the client does not normally have access to, and there must be > a real value to the end-user to be able to manage the relationships > separately. "The relationships" here mean the relationship between the > end-user and the client, and the end-user and the server. There needs to > be a reason why there is value to the end-user that these each be managed > separately instead of together. > 3. The scenario must be about an end-user granting a client *restricted* > access to the protected resource. If the access to the protected resource > is unlimited, there is no point to OAuth - the end-user may as well simply > provide to the client the end-user's credentials to access the protected > resource. > 4. At the time the end-user approves the request the client has made, or > will make, of the server to access the protected resource, the end-user > must be able to be presented with a verifiable conversation with the server > wherein the approval is given. So there are two parts to this test. The > first is that the conversation has to be able to take place where the > server asks the end-user if it is okay that the client obtain the > authorization being requested. The second part is that the end-user needs > to be able to trust that the conversation is between the end-user and the > server, not with the client or a man-in-the-middle or whatever. > 5. Finally, there needs to be a justifiable reason why the client wishes > to communicate with the server via SIP rather than HTTP. Performing the > OAuth negotiation is a solved problem in HTTP, so if that is a reasonable > option the application developer will choose HTTP. The scenario needs to > demonstrate a reason why using SIP is required, or at least preferred. > > First, the proposal does *not *call for using SIP to authenticate to the Authorization Server, unless it is authenticating to the SIP Registrar. Second, when using Code Grant type, the authentication in OAuth 2.0 is a solved problem for the browser, not for a SIP UA. > The first four tests are basic OAuth tests - they must all be relevant to > the use case for OAuth to be justified. The fifth use case is relevant to > SIP OAuth, which is what this draft is about. > > > SSO is just a variant of Authentication. It has to do with allowing a > single credential to authenticate a user to a multitude of services without > requiring the user to remember multiple credentials or reenter the same > credentials all the time. There are a number of SSO solutions available > today, but as I understand it OAuth is not one of them. > > > > > > > > Enterprise Use Cases > > -------------------- > > > > 1. Corporate-wide SSO > > > > An enterprise is interested in providing its users with an SSO > capability to > > the corporate various services. > > The enterprise has an authorization server for controlling the user > access > > to their network and would like to extend that existing authorization > > server to control the user access to the various services provided by > > their SIP network. > > > > The user is expected to provide his corporate credentials to login to the > > corporate network and get different types of services, regardless of > > the protocol used to provide the service, and without the need to > > create different accounts for these different types of services. > > This is an authentication / SSO use case. Can you explain why OAuth is a > solution to this problem? > > Let's take this use case as an example. The user is provided with corporate credentials to allow him to login to the corporate network and get access to services. The user cannot use the corporate credentials to get access to SIP services, and he is required to use yet another credentials that are specific to the SIP network. With the SIP OAuth proposal, the user is expected to authenticate to the Authorization Server, and as a result will be provided with an access token that controls the user's access to all corporate service, including the SIP services. The access token could also control the level of service provided to the user by a specific application server; for example, a conference server might want to control who could get access to video conference service vs audio service only. To achieve that you need more than just an authentication; there is a need for an authorization framework, which is what OAuth is all about. > > > > > > 2. SIP SSO > > > > An enterprise is interested in providing its users with an SSO > capability to > > the corporate various SIP services. > > > > The enterprise wants to control the services provided to their SIP users > and > > the level of service provided to the user by their SIP application > servers > > without the need to create different accounts for these services. > > > > The enterprise wants to utilize an existing authentication mechanism > > provided by SIP, but would like to be able to control who gets access to > > what service and when. > > > > The user is expected to use his SIP credentials to login to the SIP > > network and get access to the basic services, and to get access to the > > services provided by the various SIP application servers without being > > challenged to provide credentials for each type of service. > > > > Same question - this is an authentication / SSO use case. Can you explain > why OAuth is a solution to this problem? > > > > > 3. Edge Authorization > > > > An enterprise is interested in authenticating and authorizing a remote > user > > trying to get access to services provided by the corporate SIP network. > > > > The enterprise would like to authenticate and authorize the remote user > at the edge > > of the network using a SIP network element that does not have direct > access to > > the SIP user account, e.g. SBC. The enterprise is also interested in > providing > > the user with an SSO capability to the corporate various SIP services. > > > > The user is expected to use his SIP credentials to login to the SIP > > network and get access to the basic services, and to get access to the > > services provided by the various SIP application servers without being > > challenged to provide credentials for each type of service. > > This sounds like an authentication issue again, not an authorization > issue. The use case is centered around using a single set of credentials > to obtain access to each service. > > Additionally, in these use cases all of the resources are controlled by > the same enterprise. The value of OAuth is that it allows a resource owner > to authorize restricted access by a client to a resource managed by a > distinct resource server. This is presumably because the resource owner > has a different level of trust with each entity - otherwise, the resource > owner could grant unrestricted access to the resource. If both the client > and the resource are controlled by the same enterprise, the resource owner > already has a trust relationship with the enterprise, so implementing OAuth > seems unnecessary to me. > > Can you help me understand why using OAuth is necessary here? Why would > the enterprise not just offer unrestricted access between all of the > services, once the user has authenticated? > Why would the enterprise do such a thing? The enterprise might give some users access to video services, but not to others. The enterprise might also want to control when a user can get access to the video service, or even the quality of video provided to the user. Just because a user authenticated to the system, does not mean that the user should get unlimited access to all services provided by the enterprise. > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > Matt Ryan > Code Slinger | Jive Communications, Inc. > Jive.com | 801.762.6281 | mryan at getjive dot com > > > --089e01160952c88d9c050137adac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Matt,

Notice that this thread is not= trying to discuss the solution, but to collect use cases. I did not mentio= n SIP OAuth in the definition or the use cases description.

But let me try to address some of your comments below. See my re= ply inline...

Regards,
 Rifaat



On = Tue, Aug 19, 2014 at 12:04 PM, Matt Ryan <mryan@getjive.com>= wrote:
Hi,

I have included some comments inline below.


On Aug 18, 2014, at 12:19 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

> Hi,
>
> During the discussion of the SIP OAuth proposal in Toronto, it was dec= ided that we need a list of use cases to make it clear what we are trying t= o solve.
> The following is some definitions and the use cases that I had in mind= when I started working on the SIP OAuth proposal.
>
> I know that others had different use cases in mind that they want the = new authorization framework to address.
>


I was one who volunteered to offer a use case or two.  I have be= en working on this (amidst summer holidays) and hope to have something to p= rovide within the next day or so.


> Regards,
>  Rifaat
>
>
> Definitions
> -----------
>
> o Types of SIP services:
>   1. Basic SIP Services: make/receive call, transfer, call f= orward, ...
>   2. Advanced SIP Services: services provided by SIP applica= tion servers, e.g. Voice Mail, Conference Services, Video Services, Presenc= e, IM, ...
>
> o Single Sign-On (SSO): SSO is a property that allows the user to be a= uthenticated once and as a result have access to multiple services in the s= ystem.
>
> o Authentication: the process of verifying the identity of a user tryi= ng to get access to some network services.
>
> o Authorization: the process of controlling a user access to network s= ervices and the level of service provided to the user.
>

As I’ve been considering example cases, I came up with five dif= ferent tests that I think must apply before any use case can be a valid SIP= OAuth use case.

1.  The scenario must be about authorization, not authentication. = ; Authorization is about determining whether a specific user-agent may acce= ss a resource or perform a function.  Authentication is about determin= ing whether the user of a user-agent is really who the user claims to be.&n= bsp; Authentication is about credentials and identity.  Authorization = is about permission and rights.  OAuth is for authorization, not authe= ntication.  It is about controlling access to resources, not about min= imizing the number of credentials a user has to manage (that is e.g. OpenID= ).

Well, I think it is about both: controllin= g access to resources, and using a single credentials to grant access to di= fferent resources.
With OAuth 2.0 you could use, for example, you= r Facebook account to grant access to your resources on different sites, in= stead of creating different account for each site that provides you with so= me service.

 
2.  There needs to be a protected resource that the end-user owns and = manages, but the client does not normally have access to, and there must be= a real value to the end-user to be able to manage the relationships separa= tely.  "The relationships" here mean the relationship betwee= n the end-user and the client, and the end-user and the server.  There= needs to be a reason why there is value to the end-user that these each be= managed separately instead of together.
3.  The scenario must be about an end-user granting a client *restrict= ed* access to the protected resource.  If the access to the protected = resource is unlimited, there is no point to OAuth - the end-user may as wel= l simply provide to the client the end-user's credentials to access the= protected resource.
4.  At the time the end-user approves the request the client has made,= or will make, of the server to access the protected resource, the end-user= must be able to be presented with a verifiable conversation with the serve= r wherein the approval is given.  So there are two parts to this test.=   The first is that the conversation has to be able to take place wher= e the server asks the end-user if it is okay that the client obtain the aut= horization being requested.  The second part is that the end-user need= s to be able to trust that the conversation is between the end-user and the= server, not with the client or a man-in-the-middle or whatever.
5.  Finally, there needs to be a justifiable reason why the client wis= hes to communicate with the server via SIP rather than HTTP.  Performi= ng the OAuth negotiation is a solved problem in HTTP, so if that is a reaso= nable option the application developer will choose HTTP.  The scenario= needs to demonstrate a reason why using SIP is required, or at least prefe= rred.


First, the proposal does not call for using SIP to authenticat= e to the Authorization Server, unless it is authenticating to the SIP Regis= trar.
Second, when using Code Gr= ant type, the authentication in OAuth 2.0 is a solved problem for the brows= er, not for a SIP UA.

 
The first four tests are basic OAuth tests - they must all be relevant to t= he use case for OAuth to be justified.  The fifth use case is relevant= to SIP OAuth, which is what this draft is about.


SSO is just a variant of Authentication.  It has to do with allowing a= single credential to authenticate a user to a multitude of services withou= t requiring the user to remember multiple credentials or reenter the same c= redentials all the time.  There are a number of SSO solutions availabl= e today, but as I understand it OAuth is not one of them.


>
>
> Enterprise Use Cases
> --------------------
>
> 1. Corporate-wide SSO
>
> An enterprise is interested in providing its users with an SSO capabil= ity to
> the corporate various services.
> The enterprise has an authorization server for controlling the user ac= cess
> to their network and would like to extend that existing authorization<= br> > server to control the user access to the various services provided by<= br> > their SIP network.
>
> The user is expected to provide his corporate credentials to login to = the
> corporate network and get different types of services, regardless of > the protocol used to provide the service, and without the need to
> create different accounts for these different types of services.

This is an authentication / SSO use case.  Can you explain why O= Auth is a solution to this problem?


Let's take this use case as an exampl= e.
The user is= provided with corporate credentials to allow him to login to the corporate= network and get access to services.
The user cannot use the co= rporate credentials to get access to SIP services, and he is required to us= e yet another credentials that are specific to the SIP network.

With the SIP OAuth proposal, the us= er is expected to authenticate to the Authorization Server, and as a result= will be provided with an access token that controls the user's access = to all corporate service, including the SIP services.
The access token could als= o control the level of service provided to the user by a specific applicati= on server; for example, a conference server might want to control who could= get access to video conference service vs audio service only.

To achieve that you need more than = just an authentication; there is a need for an authorization framework, whi= ch is what OAuth is all about.

 
>
>
> 2. SIP SSO
>
> An enterprise is interested in providing its users with an SSO capabil= ity to
> the corporate various SIP services.
>
> The enterprise wants to control the services provided to their SIP use= rs and
> the level of service provided to the user by their SIP application ser= vers
> without the need to create different accounts for these services.
>
> The enterprise wants to utilize an existing authentication mechanism > provided by SIP, but would like to be able to control who gets access = to
> what service and when.
>
> The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the=
> services provided by the various SIP application servers without being=
> challenged to provide credentials for each type of service.
>

Same question - this is an authentication / SSO use case.  Can y= ou explain why OAuth is a solution to this problem?

>
> 3. Edge Authorization
>
> An enterprise is interested in authenticating and authorizing a remote= user
> trying to get access to services provided by the corporate SIP network= .
>
> The enterprise would like to authenticate and authorize the remote use= r at the edge
> of the network using a SIP network element that does not have direct a= ccess to
> the SIP user account, e.g. SBC. The enterprise is also interested in p= roviding
> the user with an SSO capability to the corporate various SIP services.=
>
> The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the=
> services provided by the various SIP application servers without being=
> challenged to provide credentials for each type of service.

This sounds like an authentication issue again, not an authorization = issue.  The use case is centered around using a single set of credenti= als to obtain access to each service.

Additionally, in these use cases all of the resources are controlled by the= same enterprise.  The value of OAuth is that it allows a resource own= er to authorize restricted access by a client to a resource managed by a di= stinct resource server.  This is presumably because the resource owner= has a different level of trust with each entity - otherwise, the resource = owner could grant unrestricted access to the resource.  If both the cl= ient and the resource are controlled by the same enterprise, the resource o= wner already has a trust relationship with the enterprise, so implementing = OAuth seems unnecessary to me.

Can you help me understand why using OAuth is necessary here?  Why wou= ld the enterprise not just offer unrestricted access between all of the ser= vices, once the user has authenticated?

Why would the enterprise do suc= h a thing?
The= enterprise might give some users access to video services, but not to othe= rs.
The enterprise might also = want to control when a user can get access to the video service, or even th= e quality of video provided to the user.
Just because a user authenticated to the system,= does not mean that the user should get unlimited access to all services pr= ovided by the enterprise.
 



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

Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  = 801.762.6281 |  mryan at getjive dot com



--089e01160952c88d9c050137adac-- From nobody Fri Aug 22 06:24:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D9F1A03A3 for ; Fri, 22 Aug 2014 06:24:39 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3riT9NpJD-zp for ; Fri, 22 Aug 2014 06:24:37 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777741A037D for ; Fri, 22 Aug 2014 06:24:37 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so9532359lbd.0 for ; Fri, 22 Aug 2014 06:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7ujKg/N1vcd6J2a2oi6OC1zSDkCRG59Kil0pdgYdsUI=; b=MO8T6eZiP2sV+ynR/KuZhkT6FwNy/NjRvqeSnyvsrZtcaTeZ8eDvhPF8wgJDO5oL66 5TPOCfOQk7ZYfOWg54baJwbB7NM3Svwn4cJZ61J3Iy81mthRABDSIeHkGw62pyJtuTFt rEtm0QfuejcQw/k9ijXT8J0KvCwbEYu2ztcYI7qhpT1iFzeu/Mrtpi6oQCwbpq976DGq aB7a7665FIo+xtSaypZwA5LqNUMbfpJXMg2PU0rhRyACMqYISZ/rlcFjYwx+cRQOL5Pw wd8MOeI4AueuLPU+Th3Q96rCkO+3d39No+Fggb4Eks/gmongOfLN3dlmxqRbF//MAtZU tBDg== MIME-Version: 1.0 X-Received: by 10.112.255.36 with SMTP id an4mr4505660lbd.31.1408713875599; Fri, 22 Aug 2014 06:24:35 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Fri, 22 Aug 2014 06:24:35 -0700 (PDT) In-Reply-To: <201408192005.s7JK5VOd024048@hobgoblin.ariadne.com> References: <201408192005.s7JK5VOd024048@hobgoblin.ariadne.com> Date: Fri, 22 Aug 2014 09:24:35 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a1134d43825370c050137c291 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/FIzBIqqI3IDQ6XHH3f2gu87YCnw Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 13:24:39 -0000 --001a1134d43825370c050137c291 Content-Type: text/plain; charset=ISO-8859-1 Hi Dale, Yes, you are correct. Thanks for clearly articulating that in your text. Regards, Rifaat On Tue, Aug 19, 2014 at 4:05 PM, Dale R. Worley wrote: > > From: Rifaat Shekh-Yusef > > > 1. Corporate-wide SSO > > > > An enterprise is interested in providing its users with an SSO > capability to > > the corporate various services. > > The enterprise has an authorization server for controlling the user > access > > to their network and would like to extend that existing authorization > > server to control the user access to the various services provided by > > their SIP network. > > > > The user is expected to provide his corporate credentials to login to the > > corporate network and get different types of services, regardless of > > the protocol used to provide the service, and without the need to > > create different accounts for these different types of services. > > In most of your cases, you speak of "services" or "types of services". > But I think that a central element of your envisioned use-case is that > each *service* is provided by a specific *application server*, that > is, a separate processing device. > > And that many of the issues of authentication have to do with the fact > that the application server is not integrated with the rest of the > SIP system. E.g., > > - We don't want to require the application server to have a complete > database of all SIP users that are allowed to use the server (with > their credentials). > > - We don't want to require the UA to present its credentials > individually to both the SIP system and to every application server > involved in a particular call. > > Otherwise, if a "service" is just some feature of the PBX, there is no > interesting authentication problem -- the UA authenticates itself to > the PBX, and the PBX knows what services the UA is allowed to use. > > I think it would help if this assumption was made more explicit. > > Dale > --001a1134d43825370c050137c291 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dale,

Yes, you are co= rrect.
Thanks for clearly articulating that in your text.

Regards,
=A0Rifaat



O= n Tue, Aug 19, 2014 at 4:05 PM, Dale R. Worley <worley@ariadne.com>= ; wrote:
> From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>

> 1. Corporate-wide SSO
>
> An enterprise is interested in providing its users with an SSO capabil= ity to
> the corporate various services.
> The enterprise has an authorization server for controlling the user ac= cess
> to their network and would like to extend that existing authorization<= br> > server to control the user access to the various services provided by<= br> > their SIP network.
>
> The user is expected to provide his corporate credentials to login to = the
> corporate network and get different types of services, regardless of > the protocol used to provide the service, and without the need to
> create different accounts for these different types of services.

In most of your cases, you speak of "services" or "typ= es of services".
But I think that a central element of your envisioned use-case is that
each *service* is provided by a specific *application server*, that
is, a separate processing device.

And that many of the issues of authentication have to do with the fact
that the application server is not integrated with the rest of the
SIP system.=A0 E.g.,

- We don't want to require the application server to have a complete =A0 database of all SIP users that are allowed to use the server (with
=A0 their credentials).

- We don't want to require the UA to present its credentials
=A0 individually to both the SIP system and to every application server
=A0 involved in a particular call.

Otherwise, if a "service" is just some feature of the PBX, there = is no
interesting authentication problem -- the UA authenticates itself to
the PBX, and the PBX knows what services the UA is allowed to use.

I think it would help if this assumption was made more explicit.

Dale

--001a1134d43825370c050137c291-- From nobody Sat Aug 23 06:05:13 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51D71A8776 for ; Sat, 23 Aug 2014 06:05: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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhNI9G5zwlRJ for ; Sat, 23 Aug 2014 06:05:08 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2051A8772 for ; Sat, 23 Aug 2014 06:05:08 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so17909457pab.0 for ; Sat, 23 Aug 2014 06:05:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=ghIOaMgnfDlXXcwG3NI3CNlx+98yeKOJriZqlegpwbs=; b=TKM33KglZpP9UIHCb+tPyLXgSCrL7CymK1uV61Y/MYZP2pOnB76HJAVx96e9monWgb 1dDoqPgKMmL8RZK0sgCnX4Cq05hHS13ermQloJH92NRp/S/Lqmp6BGq2Ik+bITiehIbK reBQE1H17/Yruw58+xawptVwpJEca3FG1PQNkx3Xu5uAKVfDiXCzKF+0xsPjbU4qD0Vo HuixKdKD9cKleuyFk32uHERheTi5hgAw8r5jYtQyIAx+hqglMUEqRQNy6aICkaiQdSu3 dhS+XrHCyxLbhlR7cRK3TB//nz89N0AqeqqrGDNOdXwuoH6CqeS7Z7tWuCRu/EQKTITY P6dg== X-Gm-Message-State: ALoCoQn5S8Ekm1zPjf5tAy4woXZjXM4Gl2RWTqdc9GYI130vZKj7bZF0uRPbGDclyxUEjYLipyKZ X-Received: by 10.67.4.1 with SMTP id ca1mr13975451pad.50.1408799107844; Sat, 23 Aug 2014 06:05:07 -0700 (PDT) Received: from [192.168.1.120] (202.250.sfcn.org. [160.7.250.202]) by mx.google.com with ESMTPSA id y4sm31721609pbt.60.2014.08.23.06.05.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Aug 2014 06:05:07 -0700 (PDT) From: Matt Ryan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> Date: Sat, 23 Aug 2014 07:05:01 -0600 To: sipcore@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/14aoT7Ol3QE4dyvKZomvvwq1WgQ Subject: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 13:05:11 -0000 Included is the use case I spoke of before. My apologies for the delay. This is written as though it could be included in = [draft-yusef-sipcore-sip-oauth] at section 6. 6. Examples 6.1. Example: Call Recording Service This example illustrates the use of SIP OAuth between three parties: A = hosted VoIP service provider, a Call Recording Service provider, and a = phone system end-user. In this example: - The phone system end-user is a customer of both the hosted VoIP = provider and the Call Recording Service provider - The hosted VoIP service provider is a standard provider of hosted = business-class VoIP telephone service using SIP - The Call Recording Service provider is a distinct entity from the = hosted VoIP provider The Call Recording Service provides to customers both the call recording = abilities and management of call recordings (configuration, sharing and = distribution, retention, etc.). This service can accept and record RTP = traffic, associate all RTP streams with a single call together, and = store and catalog the recorded data for future searching and retrieval. = The service also offers a web interface where customers may view and = retrieve stored calls. Stored calls may range from simple = person-to-person voice calls to multi-party conferences with a multitude = of audio and video streams. In this example, customers are billed based = on the amount of data they store, although other models are certainly = possible. 6.1.1. OAuth 2.0 Roles In this example, each party assumes the following OAuth 2.0 roles as = defined in [RFC6749] Section 1.1: - The end-user assumes the role of resource owner - The hosted VoIP service provider assumes the role of client - The Call Recording Service provider assumes the role of resource = server as well as the role of authorization server 6.1.2. Description There are two parts to the example: Initial configuration and real-time = recording authorization. Each section includes a simplified flow diagram for the purpose of = describing the corresponding portion of the example. For the sake of = brevity, certain parts of the OAuth dialog have been eliminated. = Implements should refer to [RFC6749] for details on OAuth. 6.1.2.1 Initial Configuration +-------------+ +---------------+ +--------------+ | End-User | | VoIP Provider | | CRS Provider | | Web Browser | | Website | | | +-------------+ +---------------+ +--------------+ | | | | HTTP 1 | | | (Configure CRS) | | |------------------->| | | | | | HTTP 2 | | | (OAuth Redirect | | | to CRS Website) | | |<-------------------| | | | | | HTTP 3 | | | (Authorize SIP from VoIP provider | |----------------------------------------->| | | | | HTTP 4 | | | (OAuth Redirect back to VoIP portal) | |<-----------------------------------------| | | | | HTTP 5 | | |------------------->| | | | HTTP 6 | | | (Request Access and | | | refresh tokens) | | |-------------------->| | | | Some time after having signed up for both services, but prior to = attempting to record any calls, the end-user logs into the web portal of = the hosted VoIP provider with a web browser and configures their call = recording service (HTTP 1). This configuration includes providing a URI = where the call recording service may be reached, along with a set of API = credentials, provided by the call recording service, which will allow = the client to initiate an OAuth exchange. The end-user also configures = the conditions under which call recordings should take place. For = example, the end-user may request to record every multi-party = (conference) call, or every call involving a specific set of users. The = end-user may also specify other restrictions, such as restricting codec = negotiation to G.711u for audio and H.264 for video in order to record = the RTP streams. Once the end-user saves the configuration, the hosted VoIP provider web = portal redirects the end-user's web browser to the call recording = service website and a standard HTTP OAuth dialog begins (HTTP 2). The = end-user authorizes the hosted VoIP provider to access (i.e. send SIP = and RTP traffic to) the call recording service, for the purpose of = recording calls, so long as the configured conditions are met (HTTP 3). = The result of this interaction is that the hosted VoIP provider ends up = receiving an OAuth access token and refresh token from the call = recording service (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in = the end-user's hosted VoIP account database. 6.1.2.2 Real-time Recording Authorization +-------------+ +---------------+ +--------------+ | End-User | | VoIP Provider | | CRS Provider | | SIP Phone | | Website | | | +-------------+ +---------------+ +--------------+ | | | | SIP INVITE 1 | | |------------------->| | | | SIP INVITE 2 | | | (with access token) | | |--------------------->| | | | | | SIP 401 Unauthorized | | |<---------------------| | | | | | SIP INVITE 3 | | | (with refresh token) | | |--------------------->| | | | | | SIP 200 1 | | | (new access token) | | |<---------------------| | | | | | SIP INVITE 4 | | | (with access token) | | |--------------------->| | | | | | SIP 200 2 | | |<---------------------| | | | =20 Independently of and after the initial configuration phase, the end-user = makes a telephone call using the hosted VoIP provider (SIP INVITE 1). = When this call takes place, the hosted VoIP provider looks to see = whether it believes this call should be recorded. If so, at this point = it would branch the call session to the call recording service, using = SIP OAuth to pass the previously provided access token for authorization = (SIP INVITE 2). Once the access token is validated by the call = recording service (perhaps after first providing a new access token = based on receipt of a valid refresh token), the call recording service = will check the rights that were previously authorized and examine the = SIP to determine whether it can accept the call. If so, it completes = the establishment of the session and begins receiving and recording the = RTP stream(s) (SIP 200 OK). The call recording service provider could = also deny the request, either because the tokens are invalid or because = the content of the SIP invite does not match the previously authorized = conditions, in which case a SIP 403 would be returned by the call = recording service provider and the call would not be recorded - however, = the initial call branch would continue without interruption. Note: [RFC6749] specifies that when a client uses a refresh token to request a = new access token, the response is HTTP 200 with the new access token and = optionally a new refresh token included in the payload. In this = example, a SIP 200 response (SIP 200 1) is sent which contains the new = token(s). However, this could be confusing as SIP 200 is generally = viewed as the acceptance of the INVITE, which is not what is happening = in this case. Should SIP 200 be used for consistency, or should another = mechanism be used? 6.1.3. Justification 6.1.3.1. Hosted VoIP Service Provider In this example, the hosted VoIP service provider can allow their = customers to enable call recording in their VoIP service by selecting = from any of a number of supported call recording service providers. = This allows the hosted VoIP service provider to offer this feature to = customers without requiring that the hosted VoIP service provider = implement and support this feature themselves. 6.1.3.2. Call Recording Service Provider In this example, the Call Recording Service provider can focus on value = and innovation in the area of recording calls and managing recorded = calls without having to build a full-featured telephony offering. 6.1.3.3. Customer In this example, the customer has more flexibility in choosing a = complete solution that meets all of the customer needs. The customer = does not have to settle for a substandard call recording service = offering in order to obtain other features they seek in a hosted VoIP = provider, and vice versa. 6.1.4. Variants A simple variant of this example is one wherein one of the services = (either the VoIP service or the call recording service) is managed = directly by the end-user, but the other is not. For example, the = end-user may wish to make use of an external hosted VoIP service = provider, but may have business or legal reasons that forbid the = end-user from allowing a third party to store and manage recorded calls. = The end-user could choose to set up their own call recording service as = described in this example, and use SIP OAuth to facilitate interaction = between the hosted VoIP service and the end-user's own call recording = service. 6.2. Other SIP OAuth examples Many other SIP-based services could leverage SIP OAuth to provide = value-added service to an end-user of a hosted VoIP service provider. = Some examples of these types of services are listed below. Voicemail service provider: The end-user configures their hosted VoIP = service provider to manage voicemail through a separate voicemail = service provider, which chooses whether to store voicemail based on = existing quotas, Caller ID, etc. Conferencing service provider: A conferencing service may wish to bill = customers in a more granular fashion, for example, based on the number = of participants and attendees in a conference, the duration of = conference, whether video was also included, which codecs were being = used, etc. instead of a flat monthly rate. SIP OAuth would facilitate = metered authorization for a client's use of the service, instead of = all-or-nothing access. Call center service provider: A third party may provide ring groups or = call queues for a hosted VoIP provider along with detailed reports and = dashboards. The end-user uses OAuth over SIP to control who can log = into which queues or ring groups, etc. =20 -- Matt Ryan code slinger | zoomulus.com ietf at mvryan dot org From nobody Mon Aug 25 08:54:14 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1491A0143 for ; Mon, 25 Aug 2014 08:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU2zWtTNBJLG for ; Mon, 25 Aug 2014 08:54:07 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02B81A0092 for ; Mon, 25 Aug 2014 08:50:25 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id b17so13215310lan.39 for ; Mon, 25 Aug 2014 08:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GYDnoakqTXf2BluqBAWb1K284huNr8YQurJvzhmWVZs=; b=E3Qy5eEdzWjGsA5A8/ifQ/QVyP4IV3DkqZU2k7y/I0fcuWzou9GVGgFm2aust4GaKm AFuLsccZ2eswlonGZNMZzrtPeotU5YYRBDPvpa5756Hixggmv8oaTkVo0bHQAkxc7tz1 1igvK3F/KDJHoQFThZlujeqrKEvUmClVDvIhhQR/0JlSpGTEOpZqwMcsCJNHzp7gvdp/ vzAk8P0AOBGXtQEM8VO4i+PTvpixWh2bJYkXiNpUssFhAHUgTXGYU4iVIRgyusQI83DF BnD1p9H+WY5jHRpmxFDpfM+2IgVwc3DHC5PnwYHgFCZdt2Sxhj9106pGS8RbBJpN+aFR ZJAA== MIME-Version: 1.0 X-Received: by 10.152.245.171 with SMTP id xp11mr22461988lac.61.1408981823995; Mon, 25 Aug 2014 08:50:23 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Mon, 25 Aug 2014 08:50:23 -0700 (PDT) In-Reply-To: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> Date: Mon, 25 Aug 2014 11:50:23 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Matt Ryan Content-Type: multipart/alternative; boundary=001a11345e121d41e905017625b3 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/HsYzDHUmosbaicyNXPHddnQlvSk Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:54:11 -0000 --001a11345e121d41e905017625b3 Content-Type: text/plain; charset=ISO-8859-1 Hi Matt, The use case and the solution provided assumes that the VoIP Provider makes the decision on when and what to record. While this is a valid use case, there are other use cases that allow the user to decide on when and what to record; take a look at RFC6341 for more info. http://datatracker.ietf.org/doc/rfc6341/ For these use cases, where the user is in control, you need to away to authenticate and control which users are allowed to record and the level of service provided for that specific user. This is where the solutions provided in section 3 or section 4 of the SIP OAuth proposal come into play. Obviously, in this case the authorization server is different from authorization server used to establish the trust relationship between the VoIP Provider and the CRS Provider. In this case, the authorization server must authenticate the user and provide his UA with an access token or a code that controls the user's access to the service. Regards, Rifaat On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan wrote: > Included is the use case I spoke of before. My apologies for the delay. > > This is written as though it could be included in > [draft-yusef-sipcore-sip-oauth] at section 6. > > > 6. Examples > > 6.1. Example: Call Recording Service > > This example illustrates the use of SIP OAuth between three parties: A > hosted VoIP service provider, a Call Recording Service provider, and a > phone system end-user. In this example: > - The phone system end-user is a customer of both the hosted VoIP provider > and the Call Recording Service provider > - The hosted VoIP service provider is a standard provider of hosted > business-class VoIP telephone service using SIP > - The Call Recording Service provider is a distinct entity from the hosted > VoIP provider > > The Call Recording Service provides to customers both the call recording > abilities and management of call recordings (configuration, sharing and > distribution, retention, etc.). This service can accept and record RTP > traffic, associate all RTP streams with a single call together, and store > and catalog the recorded data for future searching and retrieval. The > service also offers a web interface where customers may view and retrieve > stored calls. Stored calls may range from simple person-to-person voice > calls to multi-party conferences with a multitude of audio and video > streams. In this example, customers are billed based on the amount of data > they store, although other models are certainly possible. > > 6.1.1. OAuth 2.0 Roles > > In this example, each party assumes the following OAuth 2.0 roles as > defined in [RFC6749] Section 1.1: > - The end-user assumes the role of resource owner > - The hosted VoIP service provider assumes the role of client > - The Call Recording Service provider assumes the role of resource server > as well as the role of authorization server > > 6.1.2. Description > > There are two parts to the example: Initial configuration and real-time > recording authorization. > > Each section includes a simplified flow diagram for the purpose of > describing the corresponding portion of the example. For the sake of > brevity, certain parts of the OAuth dialog have been eliminated. > Implements should refer to [RFC6749] for details on OAuth. > > 6.1.2.1 Initial Configuration > > +-------------+ +---------------+ +--------------+ > | End-User | | VoIP Provider | | CRS Provider | > | Web Browser | | Website | | | > +-------------+ +---------------+ +--------------+ > | | | > | HTTP 1 | | > | (Configure CRS) | | > |------------------->| | > | | | > | HTTP 2 | | > | (OAuth Redirect | | > | to CRS Website) | | > |<-------------------| | > | | | > | HTTP 3 | | > | (Authorize SIP from VoIP provider | > |----------------------------------------->| > | | | > | HTTP 4 | | > | (OAuth Redirect back to VoIP portal) | > |<-----------------------------------------| > | | | > | HTTP 5 | | > |------------------->| | > | | HTTP 6 | > | | (Request Access and | > | | refresh tokens) | > | |-------------------->| > | | | > > Some time after having signed up for both services, but prior to > attempting to record any calls, the end-user logs into the web portal of > the hosted VoIP provider with a web browser and configures their call > recording service (HTTP 1). This configuration includes providing a URI > where the call recording service may be reached, along with a set of API > credentials, provided by the call recording service, which will allow the > client to initiate an OAuth exchange. The end-user also configures the > conditions under which call recordings should take place. For example, the > end-user may request to record every multi-party (conference) call, or > every call involving a specific set of users. The end-user may also > specify other restrictions, such as restricting codec negotiation to G.711u > for audio and H.264 for video in order to record the RTP streams. > Once the end-user saves the configuration, the hosted VoIP provider web > portal redirects the end-user's web browser to the call recording service > website and a standard HTTP OAuth dialog begins (HTTP 2). The end-user > authorizes the hosted VoIP provider to access (i.e. send SIP and RTP > traffic to) the call recording service, for the purpose of recording calls, > so long as the configured conditions are met (HTTP 3). The result of this > interaction is that the hosted VoIP provider ends up receiving an OAuth > access token and refresh token from the call recording service (HTTP 4, > HTTP 5, HTTP 6). These tokens are saved in the end-user's hosted VoIP > account database. > > 6.1.2.2 Real-time Recording Authorization > > +-------------+ +---------------+ +--------------+ > | End-User | | VoIP Provider | | CRS Provider | > | SIP Phone | | Website | | | > +-------------+ +---------------+ +--------------+ > | | | > | SIP INVITE 1 | | > |------------------->| | > | | SIP INVITE 2 | > | | (with access token) | > | |--------------------->| > | | | > | | SIP 401 Unauthorized | > | |<---------------------| > | | | > | | SIP INVITE 3 | > | | (with refresh token) | > | |--------------------->| > | | | > | | SIP 200 1 | > | | (new access token) | > | |<---------------------| > | | | > | | SIP INVITE 4 | > | | (with access token) | > | |--------------------->| > | | | > | | SIP 200 2 | > | |<---------------------| > | | | > > Independently of and after the initial configuration phase, the end-user > makes a telephone call using the hosted VoIP provider (SIP INVITE 1). When > this call takes place, the hosted VoIP provider looks to see whether it > believes this call should be recorded. If so, at this point it would > branch the call session to the call recording service, using SIP OAuth to > pass the previously provided access token for authorization (SIP INVITE > 2). Once the access token is validated by the call recording service > (perhaps after first providing a new access token based on receipt of a > valid refresh token), the call recording service will check the rights that > were previously authorized and examine the SIP to determine whether it can > accept the call. If so, it completes the establishment of the session and > begins receiving and recording the RTP stream(s) (SIP 200 OK). The call > recording service provider could also deny the request, either because the > tokens are invalid or because the content of > the SIP invite does not match the previously authorized conditions, in > which case a SIP 403 would be returned by the call recording service > provider and the call would not be recorded - however, the initial call > branch would continue without interruption. > > Note: > [RFC6749] specifies that when a client uses a refresh token to request a > new access token, the response is HTTP 200 with the new access token and > optionally a new refresh token included in the payload. In this example, a > SIP 200 response (SIP 200 1) is sent which contains the new token(s). > However, this could be confusing as SIP 200 is generally viewed as the > acceptance of the INVITE, which is not what is happening in this case. > Should SIP 200 be used for consistency, or should another mechanism be used? > > 6.1.3. Justification > > 6.1.3.1. Hosted VoIP Service Provider > > In this example, the hosted VoIP service provider can allow their > customers to enable call recording in their VoIP service by selecting from > any of a number of supported call recording service providers. This allows > the hosted VoIP service provider to offer this feature to customers without > requiring that the hosted VoIP service provider implement and support this > feature themselves. > > 6.1.3.2. Call Recording Service Provider > > In this example, the Call Recording Service provider can focus on value > and innovation in the area of recording calls and managing recorded calls > without having to build a full-featured telephony offering. > > 6.1.3.3. Customer > > In this example, the customer has more flexibility in choosing a complete > solution that meets all of the customer needs. The customer does not have > to settle for a substandard call recording service offering in order to > obtain other features they seek in a hosted VoIP provider, and vice versa. > > 6.1.4. Variants > > A simple variant of this example is one wherein one of the services > (either the VoIP service or the call recording service) is managed directly > by the end-user, but the other is not. For example, the end-user may wish > to make use of an external hosted VoIP service provider, but may have > business or legal reasons that forbid the end-user from allowing a third > party to store and manage recorded calls. The end-user could choose to set > up their own call recording service as described in this example, and use > SIP OAuth to facilitate interaction between the hosted VoIP service and the > end-user's own call recording service. > > 6.2. Other SIP OAuth examples > > Many other SIP-based services could leverage SIP OAuth to provide > value-added service to an end-user of a hosted VoIP service provider. Some > examples of these types of services are listed below. > > Voicemail service provider: The end-user configures their hosted VoIP > service provider to manage voicemail through a separate voicemail service > provider, which chooses whether to store voicemail based on existing > quotas, Caller ID, etc. > > Conferencing service provider: A conferencing service may wish to bill > customers in a more granular fashion, for example, based on the number of > participants and attendees in a conference, the duration of conference, > whether video was also included, which codecs were being used, etc. instead > of a flat monthly rate. SIP OAuth would facilitate metered authorization > for a client's use of the service, instead of all-or-nothing access. > > Call center service provider: A third party may provide ring groups or > call queues for a hosted VoIP provider along with detailed reports and > dashboards. The end-user uses OAuth over SIP to control who can log into > which queues or ring groups, etc. > > > > -- > Matt Ryan > code slinger | zoomulus.com > ietf at mvryan dot org > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11345e121d41e905017625b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Matt,

The use case and the solution = provided assumes that the VoIP Provider makes the decision on when and what= to record.
While this is a valid use case, there are other use c= ases that allow the user to decide on when and what to record; take a look = at RFC6341 for more info.

= For these use cases, where the user is in control, you need to away to auth= enticate and control which users are allowed to record and the level of ser= vice provided for that specific user.
This is where the solutions provided in section 3 or section 4 of the = SIP OAuth proposal come into play.
Obviously, in this case the au= thorization server is different from authorization server used to establish= the trust relationship between the VoIP Provider and the CRS Provider.
In this case, the authorization server must authenticate the user and = provide his UA with an access token or a code that controls the user's = access to the service.

Regards,
=A0Rifaat

=


On Sat, Aug 2= 3, 2014 at 9:05 AM, Matt Ryan <ietf@mvryan.org> wrote:
Included is the use case I spoke of before.= =A0 My apologies for the delay.

This is written as though it could be included in [draft-yusef-sipcore-sip-= oauth] at section 6.


6. Examples

6.1. Example: Call Recording Service

This example illustrates the use of SIP OAuth between three parties:=A0 A h= osted VoIP service provider, a Call Recording Service provider, and a phone= system end-user.=A0 In this example:
- The phone system end-user is a customer of both the hosted VoIP provider = and the Call Recording Service provider
- The hosted VoIP service provider is a standard provider of hosted busines= s-class VoIP telephone service using SIP
- The Call Recording Service provider is a distinct entity from the hosted = VoIP provider

The Call Recording Service provides to customers both the call recording ab= ilities and management of call recordings (configuration, sharing and distr= ibution, retention, etc.).=A0 This service can accept and record RTP traffi= c, associate all RTP streams with a single call together, and store and cat= alog the recorded data for future searching and retrieval.=A0 The service a= lso offers a web interface where customers may view and retrieve stored cal= ls.=A0 Stored calls may range from simple person-to-person voice calls to m= ulti-party conferences with a multitude of audio and video streams.=A0 In t= his example, customers are billed based on the amount of data they store, a= lthough other models are certainly possible.

6.1.1. OAuth 2.0 Roles

In this example, each party assumes the following OAuth 2.0 roles as define= d in [RFC6749] Section 1.1:
- The end-user assumes the role of resource owner
- The hosted VoIP service provider assumes the role of client
- The Call Recording Service provider assumes the role of resource server a= s well as the role of authorization server

6.1.2. Description

There are two parts to the example:=A0 Initial configuration and real-time = recording authorization.

Each section includes a simplified flow diagram for the purpose of describi= ng the corresponding portion of the example.=A0 For the sake of brevity, ce= rtain parts of the OAuth dialog have been eliminated.=A0 Implements should = refer to [RFC6749] for details on OAuth.

6.1.2.1 Initial Configuration

=A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 =A0+--------------+<= br> =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |=A0 =A0 =A0| CRS Provi= der |
=A0 | Web Browser |=A0 =A0 =A0|=A0 =A0 Website=A0 =A0 |=A0 =A0 =A0|=A0 =A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 =A0+--------------+<= br> =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| HTTP 1=A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| (Configure CRS)=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| HTTP 2=A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| (OAuth Redirect=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|=A0 to CRS Website)=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|<-------------------|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| HTTP 3=A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| (Authorize SIP from VoIP provider=A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|----------------------------------------->|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| HTTP 4=A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| (OAuth Redirect back to VoIP portal)=A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|<-----------------------------------------|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0| HTTP 5=A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | HTTP 6=A0 =A0= =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (Request Acce= ss and |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 refresh to= kens)=A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |--------------= ------>|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|

Some time after having signed up for both services, but prior to attempting= to record any calls, the end-user logs into the web portal of the hosted V= oIP provider with a web browser and configures their call recording service= (HTTP 1).=A0 This configuration includes providing a URI where the call re= cording service may be reached, along with a set of API credentials, provid= ed by the call recording service, which will allow the client to initiate a= n OAuth exchange.=A0 The end-user also configures the conditions under whic= h call recordings should take place.=A0 For example, the end-user may reque= st to record every multi-party (conference) call, or every call involving a= specific set of users.=A0 The end-user may also specify other restrictions= , such as restricting codec negotiation to G.711u for audio and H.264 for v= ideo in order to record the RTP streams.
Once the end-user saves the configuration, the hosted VoIP provider web por= tal redirects the end-user's web browser to the call recording service = website and a standard HTTP OAuth dialog begins (HTTP 2).=A0 The end-user a= uthorizes the hosted VoIP provider to access (i.e. send SIP and RTP traffic= to) the call recording service, for the purpose of recording calls, so lon= g as the configured conditions are met (HTTP 3).=A0 The result of this inte= raction is that the hosted VoIP provider ends up receiving an OAuth access = token and refresh token from the call recording service (HTTP 4, HTTP 5, HT= TP 6).=A0 These tokens are saved in the end-user's hosted VoIP account = database.

6.1.2.2 Real-time Recording Authorization

=A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 =A0 +--------------+=
=A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |=A0 =A0 =A0 | CRS Prov= ider |
=A0 |=A0 SIP Phone=A0 |=A0 =A0 =A0|=A0 =A0 Website=A0 =A0 |=A0 =A0 =A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 =A0 +--------------+=
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| SIP INVITE 1=A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | SIP INVITE 2= =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (with access = token)=A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |--------------= ------->|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | SIP 401 Unaut= horized |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<----------= -----------|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | SIP INVITE 3= =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (with refresh= token) |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |--------------= ------->|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | SIP 200 1=A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (new access t= oken)=A0 =A0|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<----------= -----------|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | SIP INVITE 4= =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | (with access = token)=A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |--------------= ------->|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | SIP 200 2=A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<----------= -----------|
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |

Independently of and after the initial configuration phase, the end-user ma= kes a telephone call using the hosted VoIP provider (SIP INVITE 1).=A0 When= this call takes place, the hosted VoIP provider looks to see whether it be= lieves this call should be recorded.=A0 If so, at this point it would branc= h the call session to the call recording service, using SIP OAuth to pass t= he previously provided access token for authorization (SIP INVITE 2).=A0 On= ce the access token is validated by the call recording service (perhaps aft= er first providing a new access token based on receipt of a valid refresh t= oken), the call recording service will check the rights that were previousl= y authorized and examine the SIP to determine whether it can accept the cal= l.=A0 If so, it completes the establishment of the session and begins recei= ving and recording the RTP stream(s) (SIP 200 OK).=A0 The call recording se= rvice provider could also deny the request, either because the tokens are i= nvalid or because the content of
=A0the SIP invite does not match the previously authorized conditions, in w= hich case a SIP 403 would be returned by the call recording service provide= r and the call would not be recorded - however, the initial call branch wou= ld continue without interruption.

Note:
[RFC6749] specifies that when a client uses a refresh token to request a ne= w access token, the response is HTTP 200 with the new access token and opti= onally a new refresh token included in the payload.=A0 In this example, a S= IP 200 response (SIP 200 1) is sent which contains the new token(s).=A0 How= ever, this could be confusing as SIP 200 is generally viewed as the accepta= nce of the INVITE, which is not what is happening in this case.=A0 Should S= IP 200 be used for consistency, or should another mechanism be used?

6.1.3. Justification

6.1.3.1. Hosted VoIP Service Provider

In this example, the hosted VoIP service provider can allow their customers= to enable call recording in their VoIP service by selecting from any of a = number of supported call recording service providers.=A0 This allows the ho= sted VoIP service provider to offer this feature to customers without requi= ring that the hosted VoIP service provider implement and support this featu= re themselves.

6.1.3.2. Call Recording Service Provider

In this example, the Call Recording Service provider can focus on value and= innovation in the area of recording calls and managing recorded calls with= out having to build a full-featured telephony offering.

6.1.3.3. Customer

In this example, the customer has more flexibility in choosing a complete s= olution that meets all of the customer needs.=A0 The customer does not have= to settle for a substandard call recording service offering in order to ob= tain other features they seek in a hosted VoIP provider, and vice versa.
6.1.4. Variants

A simple variant of this example is one wherein one of the services (either= the VoIP service or the call recording service) is managed directly by the= end-user, but the other is not.=A0 For example, the end-user may wish to m= ake use of an external hosted VoIP service provider, but may have business = or legal reasons that forbid the end-user from allowing a third party to st= ore and manage recorded calls.=A0 The end-user could choose to set up their= own call recording service as described in this example, and use SIP OAuth= to facilitate interaction between the hosted VoIP service and the end-user= 's own call recording service.

6.2. Other SIP OAuth examples

Many other SIP-based services could leverage SIP OAuth to provide value-add= ed service to an end-user of a hosted VoIP service provider.=A0 Some exampl= es of these types of services are listed below.

Voicemail service provider:=A0 The end-user configures their hosted VoIP se= rvice provider to manage voicemail through a separate voicemail service pro= vider, which chooses whether to store voicemail based on existing quotas, C= aller ID, etc.

Conferencing service provider:=A0 A conferencing service may wish to bill c= ustomers in a more granular fashion, for example, based on the number of pa= rticipants and attendees in a conference, the duration of conference, wheth= er video was also included, which codecs were being used, etc. instead of a= flat monthly rate.=A0 SIP OAuth would facilitate metered authorization for= a client's use of the service, instead of all-or-nothing access.

Call center service provider:=A0 A third party may provide ring groups or c= all queues for a hosted VoIP provider along with detailed reports and dashb= oards.=A0 The end-user uses OAuth over SIP to control who can log into whic= h queues or ring groups, etc.



--
Matt Ryan
code slinger | zoomulus.c= om
ietf at mvryan dot org




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

--001a11345e121d41e905017625b3-- From nobody Mon Aug 25 11:44:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AEC1A0242 for ; Mon, 25 Aug 2014 11:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vz_SeG3KIeZO for ; Mon, 25 Aug 2014 11:44:11 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABC81A02BD for ; Mon, 25 Aug 2014 11:44:11 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id j6Fl1o0021c6gX85F6kACv; Mon, 25 Aug 2014 18:44:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta23.westchester.pa.mail.comcast.net with comcast id j6kA1o00J3Ge9ey3j6kAsg; Mon, 25 Aug 2014 18:44:10 +0000 Message-ID: <53FB83FA.8010101@alum.mit.edu> Date: Mon, 25 Aug 2014 14:44:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408992250; bh=Jk4ONwjf8DEw+y7VpeqYh8A1faP6ZDRweliFuZc4sUc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Lw45sKmTguQLhTkFCa8vYZSZTNUCM9O8WLdEqpko8ImLVReRRHdqpxAg7KuSZonF2 hcie3xBM3a5l5t+F7ilCxrCk2tMbnVgJ1Ofx6F/j8uSkKNUfPVpI1TuppwWWEqYKqs kmBTCSw70nctJiMF33Y/n1zf6ET/KFyAMu/BiyR/U9CQ8EOQe2P+a8bE5GXPLHZ6m8 TW5mGsJeczwdkL1RX45k58k3udbs2Aa0xg9DEyPA5AHTHHAKl+1U4bAxe3s2/zmQq/ kZc1ARXG723/GHmikQKHhJbGoQmabRvTSnXHsNZFEnDtXC77s7jeWpKLfcM3T2hYeB f6r5d7wNS3+0Q== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Er0dXRI2h6jIGbFIJ9lKOCP3-bs Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:44:15 -0000 On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: > Hi Matt, > > The use case and the solution provided assumes that the VoIP Provider > makes the decision on when and what to record. > While this is a valid use case, there are other use cases that allow the > user to decide on when and what to record; take a look at RFC6341 for > more info. > http://datatracker.ietf.org/doc/rfc6341/ SIPREC supports numerous topologies. It would support the one that Matt outlines as well as end-user controlled ones. I found Matt's use case interesting. I think it would be nice if such services were available in that form. But I have difficulty imagining any of the VoIP providers I'm aware of supporting this model. My impression is that this means that they are giving up a value added revenue market, that they are loath to do. The most likely justification I can imagine that they don't want to legal consequences of doing recording. Thanks, Paul > For these use cases, where the user is in control, you need to away to > authenticate and control which users are allowed to record and the level > of service provided for that specific user. > This is where the solutions provided in section 3 or section 4 of the > SIP OAuth proposal come into play. > Obviously, in this case the authorization server is different from > authorization server used to establish the trust relationship between > the VoIP Provider and the CRS Provider. > In this case, the authorization server must authenticate the user and > provide his UA with an access token or a code that controls the user's > access to the service. > > Regards, > Rifaat > > > > On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan > wrote: > > Included is the use case I spoke of before. My apologies for the delay. > > This is written as though it could be included in > [draft-yusef-sipcore-sip-oauth] at section 6. > > > 6. Examples > > 6.1. Example: Call Recording Service > > This example illustrates the use of SIP OAuth between three > parties: A hosted VoIP service provider, a Call Recording Service > provider, and a phone system end-user. In this example: > - The phone system end-user is a customer of both the hosted VoIP > provider and the Call Recording Service provider > - The hosted VoIP service provider is a standard provider of hosted > business-class VoIP telephone service using SIP > - The Call Recording Service provider is a distinct entity from the > hosted VoIP provider > > The Call Recording Service provides to customers both the call > recording abilities and management of call recordings > (configuration, sharing and distribution, retention, etc.). This > service can accept and record RTP traffic, associate all RTP streams > with a single call together, and store and catalog the recorded data > for future searching and retrieval. The service also offers a web > interface where customers may view and retrieve stored calls. > Stored calls may range from simple person-to-person voice calls to > multi-party conferences with a multitude of audio and video > streams. In this example, customers are billed based on the amount > of data they store, although other models are certainly possible. > > 6.1.1. OAuth 2.0 Roles > > In this example, each party assumes the following OAuth 2.0 roles as > defined in [RFC6749] Section 1.1: > - The end-user assumes the role of resource owner > - The hosted VoIP service provider assumes the role of client > - The Call Recording Service provider assumes the role of resource > server as well as the role of authorization server > > 6.1.2. Description > > There are two parts to the example: Initial configuration and > real-time recording authorization. > > Each section includes a simplified flow diagram for the purpose of > describing the corresponding portion of the example. For the sake > of brevity, certain parts of the OAuth dialog have been eliminated. > Implements should refer to [RFC6749] for details on OAuth. > > 6.1.2.1 Initial Configuration > > +-------------+ +---------------+ +--------------+ > | End-User | | VoIP Provider | | CRS Provider | > | Web Browser | | Website | | | > +-------------+ +---------------+ +--------------+ > | | | > | HTTP 1 | | > | (Configure CRS) | | > |------------------->| | > | | | > | HTTP 2 | | > | (OAuth Redirect | | > | to CRS Website) | | > |<-------------------| | > | | | > | HTTP 3 | | > | (Authorize SIP from VoIP provider | > |----------------------------------------->| > | | | > | HTTP 4 | | > | (OAuth Redirect back to VoIP portal) | > |<-----------------------------------------| > | | | > | HTTP 5 | | > |------------------->| | > | | HTTP 6 | > | | (Request Access and | > | | refresh tokens) | > | |-------------------->| > | | | > > Some time after having signed up for both services, but prior to > attempting to record any calls, the end-user logs into the web > portal of the hosted VoIP provider with a web browser and configures > their call recording service (HTTP 1). This configuration includes > providing a URI where the call recording service may be reached, > along with a set of API credentials, provided by the call recording > service, which will allow the client to initiate an OAuth exchange. > The end-user also configures the conditions under which call > recordings should take place. For example, the end-user may request > to record every multi-party (conference) call, or every call > involving a specific set of users. The end-user may also specify > other restrictions, such as restricting codec negotiation to G.711u > for audio and H.264 for video in order to record the RTP streams. > Once the end-user saves the configuration, the hosted VoIP provider > web portal redirects the end-user's web browser to the call > recording service website and a standard HTTP OAuth dialog begins > (HTTP 2). The end-user authorizes the hosted VoIP provider to > access (i.e. send SIP and RTP traffic to) the call recording > service, for the purpose of recording calls, so long as the > configured conditions are met (HTTP 3). The result of this > interaction is that the hosted VoIP provider ends up receiving an > OAuth access token and refresh token from the call recording service > (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the end-user's > hosted VoIP account database. > > 6.1.2.2 Real-time Recording Authorization > > +-------------+ +---------------+ +--------------+ > | End-User | | VoIP Provider | | CRS Provider | > | SIP Phone | | Website | | | > +-------------+ +---------------+ +--------------+ > | | | > | SIP INVITE 1 | | > |------------------->| | > | | SIP INVITE 2 | > | | (with access token) | > | |--------------------->| > | | | > | | SIP 401 Unauthorized | > | |<---------------------| > | | | > | | SIP INVITE 3 | > | | (with refresh token) | > | |--------------------->| > | | | > | | SIP 200 1 | > | | (new access token) | > | |<---------------------| > | | | > | | SIP INVITE 4 | > | | (with access token) | > | |--------------------->| > | | | > | | SIP 200 2 | > | |<---------------------| > | | | > > Independently of and after the initial configuration phase, the > end-user makes a telephone call using the hosted VoIP provider (SIP > INVITE 1). When this call takes place, the hosted VoIP provider > looks to see whether it believes this call should be recorded. If > so, at this point it would branch the call session to the call > recording service, using SIP OAuth to pass the previously provided > access token for authorization (SIP INVITE 2). Once the access > token is validated by the call recording service (perhaps after > first providing a new access token based on receipt of a valid > refresh token), the call recording service will check the rights > that were previously authorized and examine the SIP to determine > whether it can accept the call. If so, it completes the > establishment of the session and begins receiving and recording the > RTP stream(s) (SIP 200 OK). The call recording service provider > could also deny the request, either because the tokens are invalid > or because the content of > the SIP invite does not match the previously authorized > conditions, in which case a SIP 403 would be returned by the call > recording service provider and the call would not be recorded - > however, the initial call branch would continue without interruption. > > Note: > [RFC6749] specifies that when a client uses a refresh token to > request a new access token, the response is HTTP 200 with the new > access token and optionally a new refresh token included in the > payload. In this example, a SIP 200 response (SIP 200 1) is sent > which contains the new token(s). However, this could be confusing > as SIP 200 is generally viewed as the acceptance of the INVITE, > which is not what is happening in this case. Should SIP 200 be used > for consistency, or should another mechanism be used? > > 6.1.3. Justification > > 6.1.3.1. Hosted VoIP Service Provider > > In this example, the hosted VoIP service provider can allow their > customers to enable call recording in their VoIP service by > selecting from any of a number of supported call recording service > providers. This allows the hosted VoIP service provider to offer > this feature to customers without requiring that the hosted VoIP > service provider implement and support this feature themselves. > > 6.1.3.2. Call Recording Service Provider > > In this example, the Call Recording Service provider can focus on > value and innovation in the area of recording calls and managing > recorded calls without having to build a full-featured telephony > offering. > > 6.1.3.3. Customer > > In this example, the customer has more flexibility in choosing a > complete solution that meets all of the customer needs. The > customer does not have to settle for a substandard call recording > service offering in order to obtain other features they seek in a > hosted VoIP provider, and vice versa. > > 6.1.4. Variants > > A simple variant of this example is one wherein one of the services > (either the VoIP service or the call recording service) is managed > directly by the end-user, but the other is not. For example, the > end-user may wish to make use of an external hosted VoIP service > provider, but may have business or legal reasons that forbid the > end-user from allowing a third party to store and manage recorded > calls. The end-user could choose to set up their own call recording > service as described in this example, and use SIP OAuth to > facilitate interaction between the hosted VoIP service and the > end-user's own call recording service. > > 6.2. Other SIP OAuth examples > > Many other SIP-based services could leverage SIP OAuth to provide > value-added service to an end-user of a hosted VoIP service > provider. Some examples of these types of services are listed below. > > Voicemail service provider: The end-user configures their hosted > VoIP service provider to manage voicemail through a separate > voicemail service provider, which chooses whether to store voicemail > based on existing quotas, Caller ID, etc. > > Conferencing service provider: A conferencing service may wish to > bill customers in a more granular fashion, for example, based on the > number of participants and attendees in a conference, the duration > of conference, whether video was also included, which codecs were > being used, etc. instead of a flat monthly rate. SIP OAuth would > facilitate metered authorization for a client's use of the service, > instead of all-or-nothing access. > > Call center service provider: A third party may provide ring groups > or call queues for a hosted VoIP provider along with detailed > reports and dashboards. The end-user uses OAuth over SIP to control > who can log into which queues or ring groups, etc. > > > > -- > Matt Ryan > code slinger | zoomulus.com > ietf at mvryan dot org > > > > > _______________________________________________ > 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 nobody Mon Aug 25 12:22:55 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904121A0298 for ; Mon, 25 Aug 2014 12:22:53 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybz37ZLXyUhT for ; Mon, 25 Aug 2014 12:22:52 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF1A1A028B for ; Mon, 25 Aug 2014 12:22:51 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id w10so20439016pde.18 for ; Mon, 25 Aug 2014 12:22:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JqZmdjpjCvKqTlfFIUIk0MygBF9RWVYBJdMuFPISbPY=; b=U3xk3v08lKgZirIboazGI0WTOyEV4iW3CtLi2pWUBGEt9R8v8P7QwCEh0TsxOlhbjK c/sRoA5q/BOJjj9baajX9mhc37enUAviipTENnATAHlSld/uNc7+QmBhcJFg+FZQb59s FX5h6RkpjOAkbJjIXo+kDAfXXMfqvWbG7rRku49xKp1NP7+ECVUbdpiRdtDio5lxIMSn TNEe1tbBaNanvlV0nZ49gVn6emPShn3sd9atl4idWre4xKJ6PDav1KhcvzsH1K1XJ3Xt NRwzSGTKhCF1nipj6mpMRsxoNEGHYwlHfLrp3iE6zZb5OpxagFCACkOEVbf7wW3e5QD4 oawg== X-Gm-Message-State: ALoCoQmhjPflY3Wj4aXOXD5lpYLog0JXnLUJK5CZ6W6OaYGDUJ5UlCzXP82I8p/xVSUF1wx7Hrv3 X-Received: by 10.68.201.68 with SMTP id jy4mr31411757pbc.64.1408994571486; Mon, 25 Aug 2014 12:22:51 -0700 (PDT) Received: from [192.168.1.120] (202.250.sfcn.org. [160.7.250.202]) by mx.google.com with ESMTPSA id nr2sm606229pbc.37.2014.08.25.12.22.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 12:22:50 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Matt Ryan In-Reply-To: Date: Mon, 25 Aug 2014 13:22:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/XgYkuh8LKyx-Ya3Hn041BvU-lzI Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:22:53 -0000 Comments below On Aug 25, 2014, at 9:50 AM, Rifaat Shekh-Yusef = wrote: > Hi Matt, >=20 > The use case and the solution provided assumes that the VoIP Provider = makes the decision on when and what to record. This is true - and not true. The VoIP provider is making the decision = on what SIP and RTP traffic to send to the call recording service. This = decision is based (presumably) on settings provided to the VoIP provider = by the user. So unless the VoIP provider either has buggy code or is = dishonest, the VoIP provider will make this decision based on the user=92s= preferences. The VoIP provider does NOT decide when and what to record. That = decision is made by the call recording service, based on information = contained within the SIP traffic sent to it by the VoIP provider. This = decision is, again, based upon the user=92s settings that they = themselves have made. So, assuming everyone is writing functional code and is following the = outlined use case, the user controls what gets recorded by how they have = configured both services. > While this is a valid use case, there are other use cases that allow = the user to decide on when and what to record; take a look at RFC6341 = for more info. > http://datatracker.ietf.org/doc/rfc6341/ >=20 > For these use cases, where the user is in control, you need to away to = authenticate and control which users are allowed to record and the level = of service provided for that specific user. > This is where the solutions provided in section 3 or section 4 of the = SIP OAuth proposal come into play. > Obviously, in this case the authorization server is different from = authorization server used to establish the trust relationship between = the VoIP Provider and the CRS Provider. > In this case, the authorization server must authenticate the user and = provide his UA with an access token or a code that controls the user's = access to the service. No, the authorization server does not need to authenticate the user. It = simply needs to validate the access token or refresh token sent to it by = the client. -- Matt Ryan code slinger | zoomulus.com ietf at mvryan dot org From nobody Mon Aug 25 12:28:06 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF9A1A02F3 for ; Mon, 25 Aug 2014 12:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ue3BlnOS36j for ; Mon, 25 Aug 2014 12:28:02 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2B61A0262 for ; Mon, 25 Aug 2014 12:28:02 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so21787005pad.38 for ; Mon, 25 Aug 2014 12:28:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=V6qdhbBhpJ6HyjPuqdl7it0yRe4Zvc2bYmZoEBJgCDE=; b=lIQc2s/TQimYyJfgEdVRzWs0QOimeSmV7enXuL/yQVPse8bf/rG5hZzisRvPPoZdqL xiB8GPaIKzXMh3T0DeWIyZGIs5hDHCBvGUgLMV7DehgXE4+tPNEP94yFDH/mjpWzTKQR DQ3Htx0Cpb3Ys4n4G8PvBWa+E9/Lk0qMevbqE1Yqz2Py99PyhG0QoSUoZ+2JcuCmMAlH Q5q1FQ30KEiTpSr384kFQO5muRTo42Sr9cv77PUh7DR+24eE2dNJlY11Ubr5GSsNs+Ua w5xbuGYYouydmFyYOU83tWcggMce/gSZpjevgZSBNS7qhVkC67Vagl7NGFWZhzgGASpQ +TJw== X-Gm-Message-State: ALoCoQkpovPFVxns6E0bfr10FYTzOfdoBiXo1MXtR4qq0j57hEhmM2/pilU3iO4YnYt8BcEtXXCY X-Received: by 10.68.175.161 with SMTP id cb1mr30822152pbc.91.1408994882337; Mon, 25 Aug 2014 12:28:02 -0700 (PDT) Received: from [192.168.1.120] (202.250.sfcn.org. [160.7.250.202]) by mx.google.com with ESMTPSA id hc11sm572879pbd.70.2014.08.25.12.28.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 12:28:01 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Matt Ryan In-Reply-To: <53FB83FA.8010101@alum.mit.edu> Date: Mon, 25 Aug 2014 13:27:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7D663BFD-B799-49FD-82F6-F864813391A4@mvryan.org> References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/HFqlUmg6UsVqBHsBaco0woig2Jg Cc: sipcore@ietf.org Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:28:04 -0000 On Aug 25, 2014, at 12:44 PM, Paul Kyzivat = wrote: > On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >> Hi Matt, >>=20 >> The use case and the solution provided assumes that the VoIP Provider >> makes the decision on when and what to record. >> While this is a valid use case, there are other use cases that allow = the >> user to decide on when and what to record; take a look at RFC6341 for >> more info. >> http://datatracker.ietf.org/doc/rfc6341/ >=20 > SIPREC supports numerous topologies. > It would support the one that Matt outlines as well as end-user = controlled ones. >=20 > I found Matt's use case interesting. I think it would be nice if such = services were available in that form. But I have difficulty imagining = any of the VoIP providers I'm aware of supporting this model. My = impression is that this means that they are giving up a value added = revenue market, that they are loath to do. The most likely justification = I can imagine that they don't want to legal consequences of doing = recording. I think it depends on the VoIP provider=92s strategy, whether they view = integration with other offerings as a plus or a minus. One example that comes readily to mind for this specific use case is a = health care provider - say, a clinic in a small town. The clinic might = need 20 or 30 phones, making them an ideal candidate for hosted service. = They may also wish to record calls, but perhaps HIPAA (I=92m no HIPAA = expert) would not allow them to store recorded calls outside of their = own management. A solution like this would allow them to bring the call = recording into their own control without having to manage the whole = telephony system. -- Matt Ryan code slinger | zoomulus.com ietf at mvryan dot org From nobody Mon Aug 25 12:39:30 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056251A02EB for ; Mon, 25 Aug 2014 12:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hAW05aKW0Hi for ; Mon, 25 Aug 2014 12:39:27 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 401101A02F3 for ; Mon, 25 Aug 2014 12:39:27 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta08.westchester.pa.mail.comcast.net with comcast id j1MA1o0031ap0As587fSVW; Mon, 25 Aug 2014 19:39:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta22.westchester.pa.mail.comcast.net with comcast id j7fS1o00q3Ge9ey3i7fSMq; Mon, 25 Aug 2014 19:39:26 +0000 Message-ID: <53FB90EE.2020909@alum.mit.edu> Date: Mon, 25 Aug 2014 15:39:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Matt Ryan References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> <7D663BFD-B799-49FD-82F6-F864813391A4@mvryan.org> In-Reply-To: <7D663BFD-B799-49FD-82F6-F864813391A4@mvryan.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408995566; bh=MenPcszqCwduVPHJnD9AiPsUvuY8CdSekHW3D/A1dGo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qFmejZUj+inzgxtLZl9IkmuqBWJq18YvbH1CmLd91ja2MCy1EON3R2VFTmiD9onaP 3uKkYG9Rn2p4Hy0stgDRaf7yulkQqna2NE1fe/9sBeLmlxvrTCoo4zcBoo/yLt9lUU OoERb/3CFwQgpkGbYwj4dSQTacfaBfuzsbsR42YPDdpsjKETa+AdkeLmZO3dwfxqQy U7KfE6vU4QoU4mPYR1RgAHLCL5mk+yNpSNqYxb3wQBtI9Wd3BrvSAgcV8D0CUUXZzu jaYiOehPQJLLFhxyW80zy4177A7iCNdos8n7+cK2h0ZAxhm9JJUBK9f5m/ODqP5i4c BGPeOrJ7bdO/g== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/-2ev4bw_TTEv20TPkdYPKKUyLUw Cc: sipcore@ietf.org Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:39:29 -0000 On 8/25/14 3:27 PM, Matt Ryan wrote: > > On Aug 25, 2014, at 12:44 PM, Paul Kyzivat wrote: > >> On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >>> Hi Matt, >>> >>> The use case and the solution provided assumes that the VoIP Provider >>> makes the decision on when and what to record. >>> While this is a valid use case, there are other use cases that allow the >>> user to decide on when and what to record; take a look at RFC6341 for >>> more info. >>> http://datatracker.ietf.org/doc/rfc6341/ >> >> SIPREC supports numerous topologies. >> It would support the one that Matt outlines as well as end-user controlled ones. >> >> I found Matt's use case interesting. I think it would be nice if such services were available in that form. But I have difficulty imagining any of the VoIP providers I'm aware of supporting this model. My impression is that this means that they are giving up a value added revenue market, that they are loath to do. The most likely justification I can imagine that they don't want to legal consequences of doing recording. > > I think it depends on the VoIP providers strategy, whether they view integration with other offerings as a plus or a minus. > > One example that comes readily to mind for this specific use case is a health care provider - say, a clinic in a small town. The clinic might need 20 or 30 phones, making them an ideal candidate for hosted service. They may also wish to record calls, but perhaps HIPAA (Im no HIPAA expert) would not allow them to store recorded calls outside of their own management. A solution like this would allow them to bring the call recording into their own control without having to manage the whole telephony system. That is a good example. It is a case where the provider is probably legally unable to provide the service. (Or at least unwilling to jump through the hoops necessary.) And yet the provider may well be motivated to allow the outsourcing of this feature in order to get the rest of the business. Thanks, Paul From nobody Mon Aug 25 12:53:50 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338731A030C for ; Mon, 25 Aug 2014 12:53:49 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LX6C23F0-YHU for ; Mon, 25 Aug 2014 12:53:47 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9253E1A02EB for ; Mon, 25 Aug 2014 12:53:46 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id n15so212952lbi.41 for ; Mon, 25 Aug 2014 12:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yi4XJpxe9bAoIrPKZ6p3YuMGlZbeAt4Fs0pV7NX7L4U=; b=0w5ANR+lKtUB9oz1U1pPoOVWqUyij6A/HnpJ7c+n5HhbfNZljWYp569KksSdIM9zw0 4ThL0ZAYK8tWuys0y/uLzPS9cXXaewrmfdAdI+zVwpCxJDyFBqw0GUYga+V+8S+nQ05/ lbogYw3RtwhtVcubhpO6pH+uWGwZIhJPKY+GIED6GordYQGtPNW/WdCNoQY86nHvp6kn ohsmwpLRdUNoy1SagoXuk7gO+G3fyJmda2BchMltNNBt8gqgEB5oK9mDN5b2eNA+MQBn mJw/plPARPKMmNeePReSK0YuUP3r5XotjxGPJW4vA/rkkVJaHso365QvMn2tgCUgirxd 5EqA== MIME-Version: 1.0 X-Received: by 10.152.45.8 with SMTP id i8mr23320085lam.3.1408996424892; Mon, 25 Aug 2014 12:53:44 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Mon, 25 Aug 2014 12:53:44 -0700 (PDT) In-Reply-To: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> Date: Mon, 25 Aug 2014 15:53:44 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Matt Ryan Content-Type: multipart/alternative; boundary=001a11c1ba206545c90501798b55 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/mNyAKm-BRLZikGkpkMC5nlIxcUo Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:53:49 -0000 --001a11c1ba206545c90501798b55 Content-Type: text/plain; charset=ISO-8859-1 Inline... On Mon, Aug 25, 2014 at 3:22 PM, Matt Ryan wrote: > Comments below > > > On Aug 25, 2014, at 9:50 AM, Rifaat Shekh-Yusef > wrote: > > > Hi Matt, > > > > The use case and the solution provided assumes that the VoIP Provider > makes the decision on when and what to record. > > This is true - and not true. The VoIP provider is making the decision on > what SIP and RTP traffic to send to the call recording service. This > decision is based (presumably) on settings provided to the VoIP provider by > the user. So unless the VoIP provider either has buggy code or is > dishonest, the VoIP provider will make this decision based on the user's > preferences. > The VoIP provider does NOT decide when and what to record. That decision > is made by the call recording service, based on information contained > within the SIP traffic sent to it by the VoIP provider. This decision is, > again, based upon the user's settings that they themselves have made. > > So, assuming everyone is writing functional code and is following the > outlined use case, the user controls what gets recorded by how they have > configured both services. > > Some use cases cannot be addressed by some user preferences set by the user. One of the use cases allows the user to start a call, and then start and stop recording based on a command from the user. > > > While this is a valid use case, there are other use cases that allow the > user to decide on when and what to record; take a look at RFC6341 for more > info. > > http://datatracker.ietf.org/doc/rfc6341/ > > > > For these use cases, where the user is in control, you need to away to > authenticate and control which users are allowed to record and the level of > service provided for that specific user. > > This is where the solutions provided in section 3 or section 4 of the > SIP OAuth proposal come into play. > > Obviously, in this case the authorization server is different from > authorization server used to establish the trust relationship between the > VoIP Provider and the CRS Provider. > > In this case, the authorization server must authenticate the user and > provide his UA with an access token or a code that controls the user's > access to the service. > > No, the authorization server does not need to authenticate the user. It > simply needs to validate the access token or refresh token sent to it by > the client. > > Well, you need to authenticate the user at least once to get access and refresh tokens. Regards, Rifaat > -- > Matt Ryan > code slinger | zoomulus.com > ietf at mvryan dot org > > > > > --001a11c1ba206545c90501798b55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...


On Mon, Aug 25, 2014 at 3:22 PM, Matt Ryan &= lt;ietf@mvryan.org= > wrote:
Comments below


On Aug 25, 2014, at 9:50 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

> Hi Matt,
>
> The use case and the solution provided assumes that the VoIP Provider = makes the decision on when and what to record.

This is true - and not true.  The VoIP provider is making the de= cision on what SIP and RTP traffic to send to the call recording service.&n= bsp; This decision is based (presumably) on settings provided to the VoIP p= rovider by the user.  So unless the VoIP provider either has buggy cod= e or is dishonest, the VoIP provider will make this decision based on the u= ser’s preferences.
The VoIP provider does NOT decide when and what to record.  That decis= ion is made by the call recording service, based on information contained w= ithin the SIP traffic sent to it by the VoIP provider.  This decision = is, again, based upon the user’s settings that they themselves have m= ade.

So, assuming everyone is writing functional code and is following the outli= ned use case, the user controls what gets recorded by how they have configu= red both services.


Some use cases c= annot be addressed by some user preferences set by the user.
One = of the use cases allows the user to start a call, and then start and stop r= ecording based on a command from the user.

 

> While this is a valid use case, there are other use cases that allow t= he user to decide on when and what to record; take a look at RFC6341 for mo= re info.
> http://datatracker.ietf.org/doc/rfc6341/
>
> For these use cases, where the user is in control, you need to away to= authenticate and control which users are allowed to record and the level o= f service provided for that specific user.
> This is where the solutions provided in section 3 or section 4 of the = SIP OAuth proposal come into play.
> Obviously, in this case the authorization server is different from aut= horization server used to establish the trust relationship between the VoIP= Provider and the CRS Provider.
> In this case, the authorization server must authenticate the user and = provide his UA with an access token or a code that controls the user's = access to the service.

No, the authorization server does not need to authenticate the user.&= nbsp; It simply needs to validate the access token or refresh token sent to= it by the client.

<= br>
Well, you need to authenticate the user at least once to get = access and refresh tokens.


Regards,=
 Rifaat



--
Matt Ryan
code slinger | zoomulus.c= om
ietf at mvryan dot org





--001a11c1ba206545c90501798b55-- From nobody Mon Aug 25 13:02:36 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D320C1A0303 for ; Mon, 25 Aug 2014 13:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.223 X-Spam-Level: * X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cK27O5Rj9ysI for ; Mon, 25 Aug 2014 13:02:28 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4155E1A02FE for ; Mon, 25 Aug 2014 13:02:28 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so15895402vcb.33 for ; Mon, 25 Aug 2014 13:02:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WrDBpaYQlOxewzIQFjgVMlp52Y9VnZE0YR93MNFldvQ=; b=D6+hki13LnSMyyOeehbDSLwEsvTtQ8BR5ZBJkD2Hyh8taHputP+jMNj3VczzIwYrAW WZEGWI4VZEshDMUgSRbIt5LaSleIUkvstChj+CEpJAKZxyqortRchtSV7DzCUx87iC8+ V3AJs7W32Ij98/UDn5fVzXjLMzpxAJza4SxNJJ6tBwA6gDNfCauyGjCPOkm1DzmC4TQ0 i9wmt4Y8Y5layjtSqygMMscZDmNPiVmWWQ2lV6opd4t6X6m1SEe0YApGHWq3hBdhzoP6 aCMiE6sLZwVGnFOuTOlB6JMEjUbMEKKpCrnkLkXqKrVcvSJ/gYfqAlMKmPDF9UWLybr1 4l3g== X-Gm-Message-State: ALoCoQmRJZJAPYINcg+wNU+UZiLeuAdft03zD4cbm8fwEnQsAKyTWTkVlU+50oAzWuFdwqmh7wIA MIME-Version: 1.0 X-Received: by 10.220.116.196 with SMTP id n4mr20326386vcq.6.1408996947256; Mon, 25 Aug 2014 13:02:27 -0700 (PDT) Received: by 10.220.84.5 with HTTP; Mon, 25 Aug 2014 13:02:26 -0700 (PDT) X-Originating-IP: [160.7.250.202] In-Reply-To: References: Date: Mon, 25 Aug 2014 14:02:26 -0600 Message-ID: From: Matt Ryan To: sipcore@ietf.org Content-Type: multipart/mixed; boundary=047d7b34354c8815dd050179aa3c Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/AR8c6r76SVzyEhqAOYgUCqn1evA Subject: [sipcore] Fwd: SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 20:02:34 -0000 --047d7b34354c8815dd050179aa3c Content-Type: multipart/alternative; boundary=047d7b34354c8815d4050179aa3a --047d7b34354c8815d4050179aa3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some comments to Rifaat's response. Sorry for the bad formatting (GMail is being a challenge). Notice that this thread is not trying to discuss the solution, but to collect use cases. I did not mention SIP OAuth in the definition or the use cases description. [MR] - Sorry, I misread. But let me try to address some of your comments below. See my reply inline... > Regards, > Rifaat > > > Definitions > ----------- > > o Types of SIP services: > 1. Basic SIP Services: make/receive call, transfer, call forward, ... > 2. Advanced SIP Services: services provided by SIP application servers, e.g. Voice Mail, Conference Services, Video Services, Presence, IM, ... > > o Single Sign-On (SSO): SSO is a property that allows the user to be authenticated once and as a result have access to multiple services in the system. > > o Authentication: the process of verifying the identity of a user trying to get access to some network services. > > o Authorization: the process of controlling a user access to network services and the level of service provided to the user. > As I=E2=80=99ve been considering example cases, I came up with five differe= nt tests that I think must apply before any use case can be a valid SIP OAuth use case. 1. The scenario must be about authorization, not authentication. Authorization is about determining whether a specific user-agent may access a resource or perform a function. Authentication is about determining whether the user of a user-agent is really who the user claims to be. Authentication is about credentials and identity. Authorization is about permission and rights. OAuth is for authorization, not authentication. It is about controlling access to resources, not about minimizing the number of credentials a user has to manage (that is e.g. OpenID). Well, I think it is about both: controlling access to resources, and using a single credentials to grant access to different resources. With OAuth 2.0 you could use, for example, your Facebook account to grant access to your resources on different sites, instead of creating different account for each site that provides you with some service. [MR] It sounds like you are stating that an example of OAuth is to use your Facebook login to access resources on different websites, instead of having to create an account on each site. Sorry, no. This is not what OAuth does. You must have an existing relationship with all the sites in order for OAuth to work. OAuth is about you, the user, allowing one web service to have *restricted* access (time-based, number or type of resources, etc.) to your resources under control by another web service. OAuth allows you to do grant the first web service this ability without requiring you to provide to the first service your login credentials to the second service. OAuth does not facilitate you sharing credentials between both services. There are other technologies that do this but OAuth is not one. If you still disagree I recommend re-reading the RFC. I will too - perhaps I have misread it. But allowing me to avoid "creating different accounts for each site" is an authentication issue, which is not what OAuth is about IIUC. (snip) > > > Enterprise Use Cases > -------------------- > > 1. Corporate-wide SSO > > An enterprise is interested in providing its users with an SSO capability to > the corporate various services. > The enterprise has an authorization server for controlling the user acces= s > to their network and would like to extend that existing authorization > server to control the user access to the various services provided by > their SIP network. > > The user is expected to provide his corporate credentials to login to the > corporate network and get different types of services, regardless of > the protocol used to provide the service, and without the need to > create different accounts for these different types of services. This is an authentication / SSO use case. Can you explain why OAuth is a solution to this problem? Let's take this use case as an example. The user is provided with corporate credentials to allow him to login to the corporate network and get access to services. The user cannot use the corporate credentials to get access to SIP services, and he is required to use yet another credentials that are specific to the SIP network. [MR] Using another set of credentials =3D authentication problem, not authorization, therefore not OAuth. With the SIP OAuth proposal, the user is expected to authenticate to the Authorization Server, [MR] You are mixing terms here. Are we talking about authentication or authorization? and as a result will be provided with an access token that controls the user's access to all corporate service, including the SIP services. [MR] In OAuth, the user does not request or obtain access tokens - ever. The client service requests the access tokens. It does this based on having some predefined API key, not shared credentials. The access token could also control the level of service provided to the user by a specific application server; for example, a conference server might want to control who could get access to video conference service vs audio service only. [MR] Fine - but if both services are in the same enterprise why is OAuth required? That's just extra work for no benefit. OAuth is about enabling restricted access to shared resources between two parties. This makes the assumption that the relationship the user has with each party is not necessarily the same. If the relationship *is* the same (it is the same business entity), what is the value? To achieve that you need more than just an authentication; there is a need for an authorization framework, which is what OAuth is all about. [MR] I disagree that an authorization framework is needed. All that is needed here is to share credentials. Both services are controlled by the same business entity. (snip) > > 3. Edge Authorization > > An enterprise is interested in authenticating and authorizing a remote user > trying to get access to services provided by the corporate SIP network. > > The enterprise would like to authenticate and authorize the remote user at the edge > of the network using a SIP network element that does not have direct access to > the SIP user account, e.g. SBC. The enterprise is also interested in providing > the user with an SSO capability to the corporate various SIP services. > > The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the > services provided by the various SIP application servers without being > challenged to provide credentials for each type of service. This sounds like an authentication issue again, not an authorization issue. The use case is centered around using a single set of credentials to obtain access to each service. Additionally, in these use cases all of the resources are controlled by the same enterprise. The value of OAuth is that it allows a resource owner to authorize restricted access by a client to a resource managed by a distinct resource server. This is presumably because the resource owner has a different level of trust with each entity - otherwise, the resource owner could grant unrestricted access to the resource. If both the client and the resource are controlled by the same enterprise, the resource owner already has a trust relationship with the enterprise, so implementing OAuth seems unnecessary to me. Can you help me understand why using OAuth is necessary here? Why would the enterprise not just offer unrestricted access between all of the services, once the user has authenticated? Why would the enterprise do such a thing? The enterprise might give some users access to video services, but not to others. The enterprise might also want to control when a user can get access to the video service, or even the quality of video provided to the user. Just because a user authenticated to the system, does not mean that the user should get unlimited access to all services provided by the enterprise= . [MR] The enterprise can *easily* do all of these things without OAuth - probably easier, in fact, without OAuth than to do it with OAuth. The enterprise can easily do this because it controls all of the services. Once the user has logged in, the enterprise can determine from the user's credential which of all these services they can access. OAuth is just a harder way to solve this problem. OAuth becomes interesting when the services are NOT all controlled by the same enterprise. -- Matt Ryan --047d7b34354c8815d4050179aa3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some comments to Rifaat's response. =C2=A0Sorry for th= e bad formatting (GMail is being a challenge).



Notice that this thread is not trying to discuss the solution, but to colle= ct use cases. I did not mention SIP OAuth in the definition or the use case= s description.

[MR] - Sorry, I misread.



But let me try to address some of your comments below. See my reply inline.= ..


> Regards,
>=C2=A0 Rifaat
>
>
> Definitions
> -----------
>
> o Types of SIP services:
>=C2=A0 =C2=A01. Basic SIP Services: make/receive call, transfer, call f= orward, ...
>=C2=A0 =C2=A02. Advanced SIP Services: services provided by SIP applica= tion servers, e.g. Voice Mail, Conference Services, Video Services, Presenc= e, IM, ...
>
> o Single Sign-On (SSO): SSO is a property that allows the user to be a= uthenticated once and as a result have access to multiple services in the s= ystem.
>
> o Authentication: the process of verifying the identity of a user tryi= ng to get access to some network services.
>
> o Authorization: the process of controlling a user access to network s= ervices and the level of service provided to the user.
>

As I=E2=80=99ve been considering example cases, I came up with five differe= nt tests that I think must apply before any use case can be a valid SIP OAu= th use case.

1.=C2=A0 The scenario must be about authorization, not authentication.=C2= =A0 Authorization is about determining whether a specific user-agent may ac= cess a resource or perform a function.=C2=A0 Authentication is about determ= ining whether the user of a user-agent is really who the user claims to be.= =C2=A0 Authentication is about credentials and identity.=C2=A0 Authorizatio= n is about permission and rights.=C2=A0 OAuth is for authorization, not aut= hentication.=C2=A0 It is about controlling access to resources, not about m= inimizing the number of credentials a user has to manage (that is e.g. Open= ID).

Well, I think it is about both: controlling access to resources, and using = a single credentials to grant access to different resources.
With OAuth 2.0 you could use, for example, your Facebook account to grant a= ccess to your resources on different sites, instead of creating different a= ccount for each site that provides you with some service.


<= br>
[MR] =C2=A0It sounds like you are stati= ng that an example of OAuth is to use your Facebook login to access resourc= es on different websites, instead of having to create an account on each si= te.
Sorry, no. =C2=A0This is not what OAuth does. = =C2=A0You must have an existing relationship with all the sites in order fo= r OAuth to work. =C2=A0OAuth is about you, the user, allowing one web servi= ce to have *restricted* access (time-based, number or type of resources, et= c.) to your resources under control by another web service. =C2=A0OAuth all= ows you to do grant the first web service this ability without requiring yo= u to provide to the first service your login credentials to the second serv= ice. =C2=A0OAuth does not facilitate you sharing credentials between both s= ervices. =C2=A0There are other technologies that do this but OAuth is not o= ne.
If you still disagree I recommend re-reading the= RFC. =C2=A0I will too - perhaps I have misread it. =C2=A0But allowing me t= o avoid "creating different accounts for each site" is an authent= ication issue, which is not what OAuth is about IIUC.


<= div class=3D"gmail_quote">(snip)


>
>
> Enterprise Use Cases
> --------------------
>
> 1. Corporate-wide SSO
>
> An enterprise is interested in providing its users with an SSO capabil= ity to
> the corporate various services.
> The enterprise has an authorization server for controlling the user ac= cess
> to their network and would like to extend that existing authorization<= br> > server to control the user access to the various services provided by<= br> > their SIP network.
>
> The user is expected to provide his corporate credentials to login to = the
> corporate network and get different types of services, regardless of > the protocol used to provide the service, and without the need to
> create different accounts for these different types of services.

This is an authentication / SSO use case.=C2=A0 Can you explain why OAuth i= s a solution to this problem?


Let's take this use case as an example.
The user is provided with corporate credentials to allow him to login to th= e corporate network and get access to services.
The user cannot use the corporate credentials to get access to SIP services= , and he is required to use yet another credentials that are specific to th= e SIP network.


[MR] =C2=A0Using another set of creden= tials =3D authentication problem, not authorization, therefore not OAuth.



With the SIP OAuth proposal, the user is expected to authenticate to the Au= thorization Server,


[MR] =C2=A0You are mixin= g terms here. =C2=A0Are we talking about authentication or authorization?


<= div class=3D"gmail_quote">
and as a res= ult will be provided with an access token that controls the user's acce= ss to all corporate service, including the SIP services.


<= div class=3D"gmail_quote">[MR] =C2=A0In OAuth, the user does not request or= obtain access tokens - ever. =C2=A0The client service requests the access = tokens. =C2=A0It does this based on having some predefined API key, not sha= red credentials.


<= div class=3D"gmail_quote">
The access token could also control the level of service provided to the us= er by a specific application server; for example, a conference server might= want to control who could get access to video conference service vs audio = service only.


<= div class=3D"gmail_quote">[MR] =C2=A0Fine - but if both services are in the= same enterprise why is OAuth required? =C2=A0That's just extra work fo= r no benefit. =C2=A0OAuth is about enabling restricted access to shared res= ources between two parties. =C2=A0This makes the assumption that the relati= onship the user has with each party is not necessarily the same. =C2=A0If t= he relationship *is* the same (it is the same business entity), what is the= value?



To achieve that you need more than just an authentication; there is a need = for an authorization framework, which is what OAuth is all about.


[MR] =C2=A0I disagree that an authorization framework is needed. =C2=A0All = that is needed here is to share credentials. =C2=A0Both services are contro= lled by the same business entity.


(snip)

>
> 3. Edge Authorization
>
> An enterprise is interested in authenticating and authorizing a remote= user
> trying to get access to services provided by the corporate SIP network= .
>
> The enterprise would like to authenticate and authorize the remote use= r at the edge
> of the network using a SIP network element that does not have direct a= ccess to
> the SIP user account, e.g. SBC. The enterprise is also interested in p= roviding
> the user with an SSO capability to the corporate various SIP services.=
>
> The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the=
> services provided by the various SIP application servers without being=
> challenged to provide credentials for each type of service.

This sounds like an authentication issue again, not an authorization issue.= =C2=A0 The use case is centered around using a single set of credentials to= obtain access to each service.

Additionally, in these use cases all of the resources are controlled by the= same enterprise.=C2=A0 The value of OAuth is that it allows a resource own= er to authorize restricted access by a client to a resource managed by a di= stinct resource server.=C2=A0 This is presumably because the resource owner= has a different level of trust with each entity - otherwise, the resource = owner could grant unrestricted access to the resource.=C2=A0 If both the cl= ient and the resource are controlled by the same enterprise, the resource o= wner already has a trust relationship with the enterprise, so implementing = OAuth seems unnecessary to me.

Can you help me understand why using OAuth is necessary here?=C2=A0 Why wou= ld the enterprise not just offer unrestricted access between all of the ser= vices, once the user has authenticated?

Why would the enterprise do such a thing?
The enterprise might give some users access to video services, but not to o= thers.
The enterprise might also want to control when a user can get access to the= video service, or even the quality of video provided to the user.
Just because a user authenticated to the system, does not mean that the use= r should get unlimited access to all services provided by the enterprise.



[MR] =C2=A0= The enterprise can *easily* do all of these things without OAuth - probably= easier, in fact, without OAuth than to do it with OAuth. =C2=A0The enterpr= ise can easily do this because it controls all of the services. =C2=A0Once = the user has logged in, the enterprise can determine from the user's cr= edential which of all these services they can access. =C2=A0OAuth is just a= harder way to solve this problem.
OAuth becomes interesting when the services are = NOT all controlled by the same enterprise. =C2=A0


--
Matt Ryan





--047d7b34354c8815d4050179aa3a-- --047d7b34354c8815dd050179aa3c Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 X-Attachment-Id: 23ab1d5707f16927_0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cHM6 Ly9ncGd0b29scy5vcmcNCg0KaVFFY0JBRUJDZ0FHQlFKVCtKS2pBQW9KRUZqNGF6N05kRGZOY1pr SC8wZ0lWTno5MEFndW4rS05rRWptbnFYTw0KeHAyKzJLWWt1MEo0NFNtODVGUFJ1cHBTZkFhUEI4 V1BoS2lUYjRGQUhNeDFCNUpYa05OUXZZQzkyWnovR0lUMQ0KbXRlZ0JVNy95Um9zTXVzZDVsVnZ0 RUFuVEJnSUI5UFBVMVlCa3k3VnhrNkt5OGUrdWw3THREV3BrN2NRY2ZBMw0KOUdxeFNObStBNFov eng3WEJCcFliRGZScFpRbFB3SnVIN3JBLzVmUlpYOXUyYktHOEwwK2hubEwxNm1DVGIycw0KVkJE ZUlIYS9IRklLa2xLQVhiOVJ4RG5HVlg2cHhHbXk5NU52Wlc1SWtnZTVxRmthTGtXKzRTSVJlVDRu cUIwRA0KU1lGSE5PbnJhUm1VRDVnRyt2ZXZ4bVpVaGFGNVFmV3FHYVpocDRXVG1hWkpXVVVpaUZN ZERqbEpycXJHVFZzPQ0KPU92WkgNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K --047d7b34354c8815dd050179aa3c-- From nobody Tue Aug 26 10:45:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3A71A0067 for ; Tue, 26 Aug 2014 10:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK3MhOvyktt5 for ; Tue, 26 Aug 2014 10:45:01 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F64F1A006C for ; Tue, 26 Aug 2014 10:45:01 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id w7so1799439lbi.16 for ; Tue, 26 Aug 2014 10:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YjpXGIp8WbIuu2FV7pWsREUazVsNxuC6i+bk9PpsqWo=; b=XmezyMU5kgmSWzpw+P/P4sKeEN2bEot1pTphU6RbsiAo36PYsHrZAuOjWPyszyQ7lI JM48Y8aKIcVqAB0CHHAhVROzSE97HAbtmSUYZDxHn+YsYwJVuXb3J5/kYyUKmPFPPNZR 6oZVZ6uF/2Oi2UqEsmHX7pr57pFyLobL+ts4GpY4xzvEBKzveSwchClgn3jDNg/Sac+n FjsID+znKAHRWZmT69rP8lJcWbUWNcyUcpp5k1SxvaaD/58TC8vaDKyoyOQszNzj0Xdr UXo3Pui8hmjq2R+2CjCNQGezf8q8b+vaPe7yQMpXzRI3J+7Wbsx8qv8WmaiQVC86EuNh zHKw== MIME-Version: 1.0 X-Received: by 10.152.164.70 with SMTP id yo6mr29143143lab.2.1409075099489; Tue, 26 Aug 2014 10:44:59 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Tue, 26 Aug 2014 10:44:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Aug 2014 13:44:59 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Matt Ryan Content-Type: multipart/alternative; boundary=001a1134d26ec45a6005018bdc0b Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/xYo1YH8TPdOWRJDQ5qLwAmHVxdI Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Fwd: SIP Authorization Framework Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 17:45:05 -0000 --001a1134d26ec45a6005018bdc0b Content-Type: text/plain; charset=ISO-8859-1 Inline... On Mon, Aug 25, 2014 at 4:02 PM, Matt Ryan wrote: > Some comments to Rifaat's response. Sorry for the bad formatting (GMail > is being a challenge). > > > > Notice that this thread is not trying to discuss the solution, but to > collect use cases. I did not mention SIP OAuth in the definition or the use > cases description. > > [MR] - Sorry, I misread. > > > > But let me try to address some of your comments below. See my reply > inline... > > > > Regards, > > Rifaat > > > > > > Definitions > > ----------- > > > > o Types of SIP services: > > 1. Basic SIP Services: make/receive call, transfer, call forward, ... > > 2. Advanced SIP Services: services provided by SIP application > servers, e.g. Voice Mail, Conference Services, Video Services, Presence, > IM, ... > > > > o Single Sign-On (SSO): SSO is a property that allows the user to be > authenticated once and as a result have access to multiple services in the > system. > > > > o Authentication: the process of verifying the identity of a user trying > to get access to some network services. > > > > o Authorization: the process of controlling a user access to network > services and the level of service provided to the user. > > > > As I've been considering example cases, I came up with five different > tests that I think must apply before any use case can be a valid SIP OAuth > use case. > > 1. The scenario must be about authorization, not authentication. > Authorization is about determining whether a specific user-agent may access > a resource or perform a function. Authentication is about determining > whether the user of a user-agent is really who the user claims to be. > Authentication is about credentials and identity. Authorization is about > permission and rights. OAuth is for authorization, not authentication. It > is about controlling access to resources, not about minimizing the number > of credentials a user has to manage (that is e.g. OpenID). > > Well, I think it is about both: controlling access to resources, and using > a single credentials to grant access to different resources. > With OAuth 2.0 you could use, for example, your Facebook account to grant > access to your resources on different sites, instead of creating different > account for each site that provides you with some service. > > > > [MR] It sounds like you are stating that an example of OAuth is to use > your Facebook login to access resources on different websites, instead of > having to create an account on each site. > Sorry, no. This is not what OAuth does. You must have an existing > relationship with all the sites in order for OAuth to work. OAuth is about > you, the user, allowing one web service to have *restricted* access > (time-based, number or type of resources, etc.) to your resources under > control by another web service. OAuth allows you to do grant the first web > service this ability without requiring you to provide to the first service > your login credentials to the second service. OAuth does not facilitate > you sharing credentials between both services. There are other > technologies that do this but OAuth is not one. > If you still disagree I recommend re-reading the RFC. I will too - > perhaps I have misread it. But allowing me to avoid "creating different > accounts for each site" is an authentication issue, which is not what OAuth > is about IIUC. > > Try to login/sign-in with each of the following links and you will see that you will be provided with an option to use your facebook account: https://www.flickr.com/ https://vimeo.com/ http://hockey.fantasysports.yahoo.com/ http://www.forbes.com/ http://oscar.go.com/ > (snip) > > > > > > > > Enterprise Use Cases > > -------------------- > > > > > 1. Corporate-wide SSO > > > > An enterprise is interested in providing its users with an SSO > capability to > > the corporate various services. > > The enterprise has an authorization server for controlling the user > access > > to their network and would like to extend that existing authorization > > server to control the user access to the various services provided by > > their SIP network. > > > > The user is expected to provide his corporate credentials to login to the > > corporate network and get different types of services, regardless of > > the protocol used to provide the service, and without the need to > > create different accounts for these different types of services. > > This is an authentication / SSO use case. Can you explain why OAuth is a > solution to this problem? > > > Let's take this use case as an example. > The user is provided with corporate credentials to allow him to login to > the corporate network and get access to services. > The user cannot use the corporate credentials to get access to SIP > services, and he is required to use yet another credentials that are > specific to the SIP network. > > > [MR] Using another set of credentials = authentication problem, not > authorization, therefore not OAuth. > > As I mentioned before, I was not trying to shoe horn the SIP OAuth proposal to OAuth 2.0 model; all I was trying to do is use the general idea to define a model for SIP. Take a look at the following two examples that define OAuth models for user authentication and authorization: http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-01 http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2 > > > With the SIP OAuth proposal, the user is expected to authenticate to the > Authorization Server, > > > [MR] You are mixing terms here. Are we talking about authentication or > authorization? > > > > and as a result will be provided with an access token that controls the > user's access to all corporate service, including the SIP services. > > > [MR] In OAuth, the user does not request or obtain access tokens - ever. > The client service requests the access tokens. It does this based on > having some predefined API key, not shared credentials. > > > > The access token could also control the level of service provided to the > user by a specific application server; for example, a conference server > might want to control who could get access to video conference service vs > audio service only. > > > [MR] Fine - but if both services are in the same enterprise why is OAuth > required? That's just extra work for no benefit. OAuth is about enabling > restricted access to shared resources between two parties. This makes the > assumption that the relationship the user has with each party is not > necessarily the same. If the relationship *is* the same (it is the same > business entity), what is the value? > > > > To achieve that you need more than just an authentication; there is a need > for an authorization framework, which is what OAuth is all about. > > > [MR] I disagree that an authorization framework is needed. All that is > needed here is to share credentials. Both services are controlled by the > same business entity. > > > (snip) > > > > > > 3. Edge Authorization > > > > An enterprise is interested in authenticating and authorizing a remote > user > > trying to get access to services provided by the corporate SIP network. > > > > The enterprise would like to authenticate and authorize the remote user > at the edge > > of the network using a SIP network element that does not have direct > access to > > the SIP user account, e.g. SBC. The enterprise is also interested in > providing > > the user with an SSO capability to the corporate various SIP services. > > > > The user is expected to use his SIP credentials to login to the SIP > > network and get access to the basic services, and to get access to the > > services provided by the various SIP application servers without being > > challenged to provide credentials for each type of service. > > This sounds like an authentication issue again, not an authorization > issue. The use case is centered around using a single set of credentials > to obtain access to each service. > > Additionally, in these use cases all of the resources are controlled by > the same enterprise. The value of OAuth is that it allows a resource owner > to authorize restricted access by a client to a resource managed by a > distinct resource server. This is presumably because the resource owner > has a different level of trust with each entity - otherwise, the resource > owner could grant unrestricted access to the resource. If both the client > and the resource are controlled by the same enterprise, the resource owner > already has a trust relationship with the enterprise, so implementing OAuth > seems unnecessary to me. > > Can you help me understand why using OAuth is necessary here? Why would > the enterprise not just offer unrestricted access between all of the > services, once the user has authenticated? > > Why would the enterprise do such a thing? > The enterprise might give some users access to video services, but not to > others. > The enterprise might also want to control when a user can get access to > the video service, or even the quality of video provided to the user. > Just because a user authenticated to the system, does not mean that the > user should get unlimited access to all services provided by the enterprise. > > > > [MR] The enterprise can *easily* do all of these things without OAuth - > probably easier, in fact, without OAuth than to do it with OAuth. The > enterprise can easily do this because it controls all of the services. > Once the user has logged in, the enterprise can determine from the user's > credential which of all these services they can access. OAuth is just a > harder way to solve this problem. > OAuth becomes interesting when the services are NOT all controlled by the > same enterprise. > > I am talking about large enterprises with thousands of users, with various systems that are not integrated that most of the time are managed by different IT teams. Tightly integrating these systems together is not an easy task, and might not be desirable. With an OAuth-type of a solution you could loosely tie these together and allow reuse of existing authentication and authorization systems. > > -- > Matt Ryan > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --001a1134d26ec45a6005018bdc0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...


On Mon, Aug 25, 2014 at 4:02 PM, Matt Ryan &= lt;ietf@mvryan.org= > wrote:
Some comments to Rifaat's response. &= nbsp;Sorry for the bad formatting (GMail is being a challenge).



Notice that this thread is not trying to discuss the solution, but to colle= ct use cases. I did not mention SIP OAuth in the definition or the use case= s description.

[MR] - Sorry, I misread.



But let me try to address some of your comments below. See my reply inline.= ..


> Regards,
>  Rifaat
>
>
> Definitions
> -----------
>
> o Types of SIP services:
>   1. Basic SIP Services: make/receive call, transfer, call f= orward, ...
>   2. Advanced SIP Services: services provided by SIP applica= tion servers, e.g. Voice Mail, Conference Services, Video Services, Presenc= e, IM, ...
>
> o Single Sign-On (SSO): SSO is a property that allows the user to be a= uthenticated once and as a result have access to multiple services in the s= ystem.
>
> o Authentication: the process of verifying the identity of a user tryi= ng to get access to some network services.
>
> o Authorization: the process of controlling a user access to network s= ervices and the level of service provided to the user.
>

As I’ve been considering example cases, I came up with five different= tests that I think must apply before any use case can be a valid SIP OAuth= use case.

1.  The scenario must be about authorization, not authentication. = ; Authorization is about determining whether a specific user-agent may acce= ss a resource or perform a function.  Authentication is about determin= ing whether the user of a user-agent is really who the user claims to be.&n= bsp; Authentication is about credentials and identity.  Authorization = is about permission and rights.  OAuth is for authorization, not authe= ntication.  It is about controlling access to resources, not about min= imizing the number of credentials a user has to manage (that is e.g. OpenID= ).

Well, I think it is about both: controlling access to resources, and using = a single credentials to grant access to different resources.
With OAuth 2.0 you could use, for example, your Facebook account to grant a= ccess to your resources on different sites, instead of creating different a= ccount for each site that provides you with some service.


<= br>
[MR]  It sounds like you are stati= ng that an example of OAuth is to use your Facebook login to access resourc= es on different websites, instead of having to create an account on each si= te.
Sorry, no.  This is not what OAuth does. &n= bsp;You must have an existing relationship with all the sites in order for = OAuth to work.  OAuth is about you, the user, allowing one web service= to have *restricted* access (time-based, number or type of resources, etc.= ) to your resources under control by another web service.  OAuth allow= s you to do grant the first web service this ability without requiring you = to provide to the first service your login credentials to the second servic= e.  OAuth does not facilitate you sharing credentials between both ser= vices.  There are other technologies that do this but OAuth is not one= .
If you still disagree I recommend re-reading the= RFC.  I will too - perhaps I have misread it.  But allowing me t= o avoid "creating different accounts for each site" is an authent= ication issue, which is not what OAuth is about IIUC.


Try to login/sign-in with each of the following links and you will s= ee that you will be provided with an option to use your facebook account:
https://vimeo.com/



(snip)


>
>
> Enterprise Use Cases
> --------------------

>
> 1. Corporate-wide SSO
>
> An enterprise is interested in providing its users with an SSO capabil= ity to
> the corporate various services.
> The enterprise has an authorization server for controlling the user ac= cess
> to their network and would like to extend that existing authorization<= br> > server to control the user access to the various services provided by<= br> > their SIP network.
>
> The user is expected to provide his corporate credentials to login to = the
> corporate network and get different types of services, regardless of > the protocol used to provide the service, and without the need to
> create different accounts for these different types of services.

This is an authentication / SSO use case.  Can you explain why OAuth i= s a solution to this problem?


Let's take this use case as an example.
The user is provided with corporate credentials to allow him to login to th= e corporate network and get access to services.
The user cannot use the corporate credentials to get access to SIP services= , and he is required to use yet another credentials that are specific to th= e SIP network.


[MR]  Using another set of creden= tials =3D authentication problem, not authorization, therefore not OAuth.


As I mentioned before, I was not trying to shoe horn th= e SIP OAuth proposal to OAuth 2.0 model; all I was trying to do is use the = general idea to define a model for SIP.
Take a look at the follow= ing two examples that define OAuth models for user authentication and autho= rization:


 


With the SIP OAuth proposal, the user is expected to authenticate to the Au= thorization Server,


[MR]  You are= mixing terms here.  Are we talking about authentication or authorizat= ion?


<= div class=3D"gmail_quote">
and as a res= ult will be provided with an access token that controls the user's acce= ss to all corporate service, including the SIP services.


<= /div>
[MR]  In OAuth, the user does not requ= est or obtain access tokens - ever.  The client service requests the a= ccess tokens.  It does this based on having some predefined API key, n= ot shared credentials.


<= div class=3D"gmail_quote">
The access token could also control the level of service provided to the us= er by a specific application server; for example, a conference server might= want to control who could get access to video conference service vs audio = service only.


<= /div>
[MR]  Fine - but if both services are = in the same enterprise why is OAuth required?  That's just extra w= ork for no benefit.  OAuth is about enabling restricted access to shar= ed resources between two parties.  This makes the assumption that the = relationship the user has with each party is not necessarily the same. &nbs= p;If the relationship *is* the same (it is the same business entity), what = is the value?



To achieve that you need more than just an authentication; there is a need = for an authorization framework, which is what OAuth is all about.


[MR]  I disagree that an authorization framework is needed.  All = that is needed here is to share credentials.  Both services are contro= lled by the same business entity.


(snip)


>
> 3. Edge Authorization
>
> An enterprise is interested in authenticating and authorizing a remote= user
> trying to get access to services provided by the corporate SIP network= .
>
> The enterprise would like to authenticate and authorize the remote use= r at the edge
> of the network using a SIP network element that does not have direct a= ccess to
> the SIP user account, e.g. SBC. The enterprise is also interested in p= roviding
> the user with an SSO capability to the corporate various SIP services.=
>
> The user is expected to use his SIP credentials to login to the SIP > network and get access to the basic services, and to get access to the=
> services provided by the various SIP application servers without being=
> challenged to provide credentials for each type of service.

This sounds like an authentication issue again, not an authorization issue.=   The use case is centered around using a single set of credentials to= obtain access to each service.

Additionally, in these use cases all of the resources are controlled by the= same enterprise.  The value of OAuth is that it allows a resource own= er to authorize restricted access by a client to a resource managed by a di= stinct resource server.  This is presumably because the resource owner= has a different level of trust with each entity - otherwise, the resource = owner could grant unrestricted access to the resource.  If both the cl= ient and the resource are controlled by the same enterprise, the resource o= wner already has a trust relationship with the enterprise, so implementing = OAuth seems unnecessary to me.

Can you help me understand why using OAuth is necessary here?  Why wou= ld the enterprise not just offer unrestricted access between all of the ser= vices, once the user has authenticated?

Why would the enterprise do such a thing?
The enterprise might give some users access to video services, but not to o= thers.
The enterprise might also want to control when a user can get access to the= video service, or even the quality of video provided to the user.
Just because a user authenticated to the system, does not mean that the use= r should get unlimited access to all services provided by the enterprise.



[MR]  = The enterprise can *easily* do all of these things without OAuth - probably= easier, in fact, without OAuth than to do it with OAuth.  The enterpr= ise can easily do this because it controls all of the services.  Once = the user has logged in, the enterprise can determine from the user's cr= edential which of all these services they can access.  OAuth is just a= harder way to solve this problem.
OAuth becomes interesting when the services are = NOT all controlled by the same enterprise.  


I am talking = about large enterprises with thousands of users, with various systems that = are not integrated that most of the time are managed by different IT teams.=
Tightly integrating these systems together is not an easy task, and mi= ght not be desirable. 
With an OAuth-type of a solution you = could loosely tie these together and allow reuse of existing authentication= and authorization systems.

 

--
Matt Ryan






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


--001a1134d26ec45a6005018bdc0b--