From owner-vospace@eso.org Thu Jul 21 18:55:50 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6LGtgcq002116 for ; Thu, 21 Jul 2005 18:55:42 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6LGtgOM002115 for vospace-outgoing; Thu, 21 Jul 2005 18:55:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6LGtccq002110 for ; Thu, 21 Jul 2005 18:55:38 +0200 (MEST) Received: from [134.171.30.64] (nb008739.ads.eso.org [134.171.30.64] (may be forged)) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id j6LGtcE00858 for ; Thu, 21 Jul 2005 18:55:38 +0200 (MEST) Message-ID: <42DFD3A7.3070906@eso.org> Date: Thu, 21 Jul 2005 18:56:07 +0200 From: "Marco C. Leoni" Organization: European Virtual Observatory @ESO User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: list setup Content-Type: multipart/alternative; boundary="------------030108060402060401050808" X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 This is a multi-part message in MIME format. --------------030108060402060401050808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just to initiate&check the list and its archive. Marco ------------------------------------------------------- Marco C. Leoni marco.leoni@eso.org European Virtual Observatory www.euro-vo.org ESO - KarlSchwarzschild Strasse, 2 D-85748 Garching bei Muenchen - Germany phone 0049 (0)89 3200 6560 fax 0049 (0)89 3200 6480 mobile 0049 0172 8904540 --------------030108060402060401050808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just to initiate&check the list and its archive.

Marco
 
-------------------------------------------------------
Marco C. Leoni                     marco.leoni@eso.org
   European Virtual Observatory        www.euro-vo.org
   ESO - KarlSchwarzschild Strasse,  2
   D-85748 Garching bei Muenchen - Germany
   phone  0049 (0)89 3200 6560
   fax    0049 (0)89 3200 6480
   mobile 0049 0172  8904540
--------------030108060402060401050808-- From owner-vospace@eso.org Thu Jul 21 22:44:32 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6LKiFcq004571 for ; Thu, 21 Jul 2005 22:44:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6LKiFbn004570 for vospace-outgoing; Thu, 21 Jul 2005 22:44:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6LKiAcq004556 for ; Thu, 21 Jul 2005 22:44:10 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6LKi7in017322 for ; Thu, 21 Jul 2005 22:44:08 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j6LKhxO03936; Thu, 21 Jul 2005 13:43:59 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Thu, 21 Jul 2005 13:26:05 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Status of VOspace specification Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.21.25 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 I have not seen a note or working draft for the VOSpace specification. Are there general guidelines for what VOSpace will provide? Are the following capabilities intended: - namespace into which images and catalogs may be registered - descriptive attributes for each registered item - administrative attributes (such as location) - authenticity and integrity attributes (desired for preservation) I am interested in seeing if the VOSpace specification can encompass the preservation attributes required for long term storage of images. Can a VOSpace instance be used as the IVOA preservation environment? Thanks, Reagan Moore From owner-vospace@eso.org Fri Jul 22 08:17:23 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6M6HIYG002740 for ; Fri, 22 Jul 2005 08:17:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6M6HI9Q002738 for vospace-outgoing; Fri, 22 Jul 2005 08:17:18 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6M6HEYG002704 for ; Fri, 22 Jul 2005 08:17:14 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6M6HChx006712 for ; Fri, 22 Jul 2005 08:17:12 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:44889) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1DvqqH-0006Pe-PF (Exim 4.51) for vospace@ivoa.net (return-path ); Fri, 22 Jul 2005 07:17:05 +0100 Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j6M6H5Zu002937 for ; Fri, 22 Jul 2005 07:17:05 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3) with ESMTP id j6M6H5gZ025970 for ; Fri, 22 Jul 2005 07:17:05 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j6M6H5DA025967 for ; Fri, 22 Jul 2005 07:17:05 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 22 Jul 2005 07:17:05 +0100 (BST) From: Guy Rixon To: vospace@ivoa.net Subject: Re: Status of VOspace specification In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.21.48 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 On Thu, 21 Jul 2005, Reagan Moore wrote: > I have not seen a note or working draft for the VOSpace > specification. Are there general guidelines for what VOSpace will > provide? Are the following capabilities intended: > > - namespace into which images and catalogs may be registered Yes, definitely. > - descriptive attributes for each registered item Yes, although the scope of the description is up for debate. > - administrative attributes (such as location) Yes. > - authenticity and integrity attributes (desired for preservation) Possibly; seems sensible. This hasn't been discussed on the AstroGrid side. You've summarized these requirements in various talks and papers. For the record, could you mail a reference to this list? > > I am interested in seeing if the VOSpace specification can encompass > the preservation attributes required for long term storage of images. > Can a VOSpace instance be used as the IVOA preservation environment? The AstroGrid view is that VOSpace is a catalogue of data-items on VOStores. Most of the preservation requirements then devolve on the stores, and I expect that some of these will not be suitable; e.g. some may not back up their contents; e.g. some, like the ones that ingest tables into RDBMS, do not preserve the data bit-for-bit. Therefore, the preservation environment would have to be select, through VOSpace, stores with suitable characteristics. We need to decide whether there are multiple VOSpaces or just one. I.e., is there one, global directory tree or is there a separate tree for each VOSpace service? If we support multiple spaces, then the preservation environment could be one such, in which the storage is internal. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Mon Jul 25 21:52:27 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6PJqI87012196 for ; Mon, 25 Jul 2005 21:52:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6PJqHBf012195 for vospace-outgoing; Mon, 25 Jul 2005 21:52:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6PJqD87012188 for ; Mon, 25 Jul 2005 21:52:14 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6PJqBin016354 for ; Mon, 25 Jul 2005 21:52:12 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j6PJq5B03032; Mon, 25 Jul 2005 12:52:05 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jul 2005 12:38:37 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Status of VOspace specification Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.25.24 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 I have not seen a note or working draft for the VOSpace specification. Are there general guidelines for what VOSpace will provide? Are the following capabilities intended: - namespace into which images and catalogs may be registered - descriptive attributes for each registered item - administrative attributes (such as location) - authenticity and integrity attributes (desired for preservation) I am interested in seeing if the VOSpace specification can encompass the preservation attributes required for long term storage of images. Can a VOSpace instance be used as the IVOA preservation environment? Thanks, Reagan Moore From owner-vospace@eso.org Thu Jul 28 19:17:31 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SHFJ7S025464 for ; Thu, 28 Jul 2005 19:15:19 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6SHFJBi025463 for vospace-outgoing; Thu, 28 Jul 2005 19:15:19 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SHFC7S025451 for ; Thu, 28 Jul 2005 19:15:13 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SHFBhx024822 for ; Thu, 28 Jul 2005 19:15:11 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:46239) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1DyByK-0005sA-4E (Exim 4.51) for vospace@ivoa.net (return-path ); Thu, 28 Jul 2005 18:15:04 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j6SHEwZu007729; Thu, 28 Jul 2005 18:14:59 +0100 (BST) Message-ID: <42E91307.4050906@ast.cam.ac.uk> Date: Thu, 28 Jul 2005 18:16:55 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: VoStore current status Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.28.18 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 I have written a wiki page which outlines where I think we are with VoStore, and identified some of the things that I think need addressing. http://wiki.astrogrid.org/bin/view/Astrogrid/VoStoreADASS2005 This is based on the most recent (pre Kyoto) VoStore specification, plus the results of discussions at the Kyoto conference. If this is indeed where we are, then I'll start to fill in some details in the functional definition and the SOAP message schema. If I have missed something out, please let me know. Thanks, Dave From owner-vospace@eso.org Thu Jul 28 19:44:00 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SHho7S000131 for ; Thu, 28 Jul 2005 19:43:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6SHhoaL000130 for vospace-outgoing; Thu, 28 Jul 2005 19:43:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SHhk7S000124 for ; Thu, 28 Jul 2005 19:43:46 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SHhiin029440 for ; Thu, 28 Jul 2005 19:43:44 +0200 (CEST) Received: from [131.215.146.187] ([131.215.146.187]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id j6SHhbgh019835 for ; Thu, 28 Jul 2005 10:43:38 -0700 Message-ID: <42E91949.9060806@cacr.caltech.edu> Date: Thu, 28 Jul 2005 10:43:37 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VoStore current status References: <42E91307.4050906@ast.cam.ac.uk> In-Reply-To: <42E91307.4050906@ast.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.28.18 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Dave Morris wrote: > I have written a wiki page which outlines where I think we are with > VoStore, and identified some of the things that I think need addressing. > http://wiki.astrogrid.org/bin/view/Astrogrid/VoStoreADASS2005 > > This is based on the most recent (pre Kyoto) VoStore specification, > plus the results of discussions at the Kyoto conference. > If this is indeed where we are, then I'll start to fill in some > details in the functional definition and the SOAP message schema. > If I have missed something out, please let me know. > > Thanks, > Dave > Hi Dave, A few things: - firstly, you say that the specification was split into two components: VoSpace and VoSpace - should be VoStore. - "VoStore? services would provide the lower level storage of objects, in a simple flat file space." This sounds like an implementation detail and VoStore is just the API spec - whether the underlying storage technology is a file system or a database does not matter, the outward appearance, however, is as if it is a simple flat file space. - there is also the issue of how VoStore handles structured (tabulated) data: one of the BigIdeas (TM) was that structured and unstructured data objects were both first-level components and that as a minimum, both would be stored as BLOBs but certain VoStore implementations would have the ability to handle structured data objects in a more intuitive manner, e.g. load them into a relational db as tables. - the identifier of an object stored in a VoStore is: # - that way the VoStore can be resolved by looking up its identifier in a registry. - do you mean "xsi:type" instead of "xsd:type" - you might also want to include an implementation section: as previously mentioned, I have a full Java implementation of the spec: it is also fully secure using WS-Security to digitally sign the SOAP messages with the user's certificate. We have also successfully tested this with a Java client against a .Net server implementation and using the NVO SSO prototype. Cheers, Matthew From owner-vospace@eso.org Thu Jul 28 22:28:46 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SKSa7S001974 for ; Thu, 28 Jul 2005 22:28:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6SKSanG001970 for vospace-outgoing; Thu, 28 Jul 2005 22:28:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SKST7S001787 for ; Thu, 28 Jul 2005 22:28:29 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6SKSRhx002653 for ; Thu, 28 Jul 2005 22:28:27 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:54576) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1DyEzM-0001Kd-Oz (Exim 4.51) for vospace@ivoa.net (return-path ); Thu, 28 Jul 2005 21:28:20 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j6SKSEZu011624; Thu, 28 Jul 2005 21:28:15 +0100 (BST) Message-ID: <42E94054.6040002@ast.cam.ac.uk> Date: Thu, 28 Jul 2005 21:30:12 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VoStore current status References: <42E91307.4050906@ast.cam.ac.uk> <42E91949.9060806@cacr.caltech.edu> In-Reply-To: <42E91949.9060806@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.28.24 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Matthew Graham wrote: > Hi Dave, > > A few things: > > - firstly, you say that the specification was split into two > components: VoSpace and VoSpace - should be VoStore. Fixed - my bad, sorry. > - "VoStore? services would provide the lower level storage of objects, > in a simple flat file space." This sounds like an implementation > detail and VoStore is just the API spec - whether the underlying > storage technology is a file system or a database does not matter, the > outward appearance, however, is as if it is a simple flat file space. Yep, text not clear enough, sorry. You are right, the specification applies to the outward appearance of the API only, not the implementation. Different implementations can store the data in files, database tables or anything else they want to. I have updated text to read "The VoSpace service(s) would provide the top level hierarchical view of the users data, VoStore services would provide a flat, non-hierarchical, view of the objects in each individual VoStore" > - there is also the issue of how VoStore handles structured > (tabulated) data: one of the BigIdeas (TM) was that structured and > unstructured data objects were both first-level components and that as > a minimum, both would be stored as BLOBs but certain VoStore > implementations would have the ability to handle structured data > objects in a more intuitive manner, e.g. load them into a relational > db as tables. You are right .... However, I thought that this was to be handled in a separate API, although it could be implemented as an extension of the VoStore service. Reason for this was to make VoStore the basic common API, which all store services must implement. Database based stores could provide additional methods for manipulating database tables - covered in a separate spec. > - the identifier of an object stored in a VoStore is: for VoStore># - that way the > VoStore can be resolved by looking up its identifier in a registry. That works, if the object identifier is a unique identifier generated by the server not the client, which is how the current AstroGrid FileStore works. e.g. #12366A-7563835 However, some of the participants in the discussions leading upto Kyoto wanted the client to be able to access the data in a VoStore using human friendly names, e.g. '/mydata/results.vot', without going via a VoSpace service. e.g. #/mydata/results.vot Which works as long as we only want one user account to accesses objects in the store. If we have more than one user account to access objects in the store, we need some prefix to distinguish between objects with the same name '/mydata/results.vot' for two different accounts 'john' and 'fred'. e.g. #/mydata/results.vot and #/mydata/results.vot In AstroGrid, we use a FileManager (VoSpace) service to handle the mapping between the hierarchical human friendly names e.g. #/mydata/results.vot' and the physical storage identifiers e.g. #12366A-7563835 If the requirement is to be able to use human friendly names _without_ using something like a VoSpace service to handle the mapping, then we need a different solution. > > - do you mean "xsi:type" instead of "xsd:type" My bad - fixed (although technically doesn't it depend on the actual URI for the name space rather than the prefix ?) > - you might also want to include an implementation section: as > previously mentioned, I have a full Java implementation of the spec: > it is also fully secure using WS-Security to digitally sign the SOAP > messages with the user's certificate. We have also successfully tested > this with a Java client against a .Net server implementation and using > the NVO SSO prototype. Excellent news. Can you point me at the details and I'll add it to the page. > > Cheers, > > Matthew Thanks for the comments. Dave From owner-vospace@eso.org Fri Jul 29 10:47:24 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6T8lCOk000442 for ; Fri, 29 Jul 2005 10:47:12 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6T8lCI4000441 for vospace-outgoing; Fri, 29 Jul 2005 10:47:12 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6T8l7Ok000432 for ; Fri, 29 Jul 2005 10:47:08 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6T8l5in024388 for ; Fri, 29 Jul 2005 10:47:05 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:43203) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1DyQW5-0001Vq-TA (Exim 4.51) for vospace@ivoa.net (return-path ); Fri, 29 Jul 2005 09:46:53 +0100 Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j6T8kqZu021645 for ; Fri, 29 Jul 2005 09:46:52 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3) with ESMTP id j6T8kqf6004098 for ; Fri, 29 Jul 2005 09:46:52 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j6T8kqaH004095 for ; Fri, 29 Jul 2005 09:46:52 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 29 Jul 2005 09:46:52 +0100 (BST) From: Guy Rixon To: vospace@ivoa.net Subject: Re: VoStore current status In-Reply-To: <42E94054.6040002@ast.cam.ac.uk> Message-ID: References: <42E91307.4050906@ast.cam.ac.uk> <42E91949.9060806@cacr.caltech.edu> <42E94054.6040002@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.29.0 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 On Thu, 28 Jul 2005, Dave Morris wrote: > Matthew Graham wrote: > > > - "VoStore? services would provide the lower level storage of objects, > > in a simple flat file space." This sounds like an implementation > > detail and VoStore is just the API spec - whether the underlying > > storage technology is a file system or a database does not matter, the > > outward appearance, however, is as if it is a simple flat file space. > > Yep, text not clear enough, sorry. > You are right, the specification applies to the outward appearance of > the API only, not the implementation. > Different implementations can store the data in files, database tables > or anything else they want to. > I have updated text to read > "The VoSpace service(s) would provide the top level hierarchical view of > the users data, VoStore services would provide a flat, non-hierarchical, > view of the objects in each individual VoStore" At some point we must work out what the hiearchy means when the storage is relational. Can we address a DB table with an IVOID or only a DB? > > - there is also the issue of how VoStore handles structured > > (tabulated) data: one of the BigIdeas (TM) was that structured and > > unstructured data objects were both first-level components and that as > > a minimum, both would be stored as BLOBs but certain VoStore > > implementations would have the ability to handle structured data > > objects in a more intuitive manner, e.g. load them into a relational > > db as tables. > > You are right .... However, I thought that this was to be handled in a > separate API, although it could be implemented as an extension of the > VoStore service. > Reason for this was to make VoStore the basic common API, which all > store services must implement. > Database based stores could provide additional methods for manipulating > database tables - covered in a separate spec. Definitely! Any relational stuff has to be via SkyNode et al., otherwise we'll never finish VOStore. However, we need to think a little about how the relational service presents the data loaded into the store. Presumably it can't publish it in the registry as the registry is too slow. Perhaps clients have to call the getRegistration interface to get the details? Or should we be emitting table details in the VOStore interface? > > - the identifier of an object stored in a VoStore is: > for VoStore># - that way the > > VoStore can be resolved by looking up its identifier in a registry. > > That works, if the object identifier is a unique identifier generated by > the server not the client, which is how the current AstroGrid FileStore > works. > e.g. #12366A-7563835 > > However, some of the participants in the discussions leading upto Kyoto > wanted the client to be able to access the data in a VoStore using human > friendly names, e.g. '/mydata/results.vot', > without going via a VoSpace service. > e.g. #/mydata/results.vot > > Which works as long as we only want one user account to accesses objects > in the store. > If we have more than one user account to access objects in the store, we > need some prefix to distinguish between objects with the same name > '/mydata/results.vot' for two different accounts 'john' and 'fred'. > e.g. # john>/mydata/results.vot > and # fred>/mydata/results.vot > > In AstroGrid, we use a FileManager (VoSpace) service to handle the > mapping between the hierarchical human friendly names > e.g. #/mydata/results.vot' > and the physical storage identifiers > e.g. #12366A-7563835 > > If the requirement is to be able to use human friendly names _without_ > using something like a VoSpace service to handle the mapping, then we > need a different solution. It's easier if we let the client pick the path part of the URI, /mydata/results.vot in this example, but not the IVOID part. In fact, the IVOID is presumabkly the IVOID of the store, so clients will never be able to specify that part. The store could then impose a format like this: ivo://some.authority/resource-key-for-store#user-name#/mydata/results.vot where the client chooses the part after the second hash. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Fri Jul 29 18:18:46 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6TGIYOk011867 for ; Fri, 29 Jul 2005 18:18:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6TGIY6Z011864 for vospace-outgoing; Fri, 29 Jul 2005 18:18:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6TGIUOk011791 for ; Fri, 29 Jul 2005 18:18:30 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j6TGIRhx007821 for ; Fri, 29 Jul 2005 18:18:28 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j6TGIKh18459; Fri, 29 Jul 2005 09:18:20 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Fri, 29 Jul 2005 09:18:05 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: VOStore interface Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.29.16 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 The differentiation between the VOStore and VOSpace interfaces is becoming unclear. The latest draft implies that properties that were originally associated with VOSpace would now be supported by VOStore. One way to better understand how VOSpace and VOStore should interact is to define the state information that will be managed by each system, and the set of operations that will change that state information. An example of such a characterization is the Storage Resource Manager (developed at LBNL) which is being used in the EGEE (Enabling Grids for E-Science) and OSG (Open Science Grid) projects. The SRM is also being proposed as a standard data access interface within the Global Grid Forum. The SRM interface is based on support for file access. A second Global Grid Forum effort, OGSA-DAI, is designing a data access interface based on support for database queries. This interface is being extended to support access to files. Both interfaces are implementing WSDL services for supporting data access. Let's look at the current VOStore and VOSpace proposal: VOStore VOSpace Storage of objects management of virtual file system data stored under unspecified ID? no user home directory User home directory directory hierarchy Directory hierarchy Unique file name within storage User-defined file names Mapping VOSpace name to VOStore name List files for user Restrict access by user identity? Identify files with URIs Access controls on local file name Access controls on VOSPace name This characterization mixes name space, mixes access controls, does not provide consistent identity, does not allow consistent management. For instance, if a URI is being provided for file identity within the VOStore interface, then there is no need for user-specified names within VOSTore. A second issue is the assumption that file access can be restricted by user identity. This means that the VOStore must manage the owner for each file, access controls for each file. File systems usually do this by creating accounts for each user name and applying Unix permissions. Is this capability to be provided now by both VOSpace and VOStore? We need a cleaner separation of capabilities. Let's look at the Storage Resource Broker data grid separation of local storage management from the virtual file system management: Local storage system SRB name space Storage of objects management of virtual file system data stored under SRB ID no user home directory User home directory directory indirection structure Directory hierarchy Unique file name within storage User-defined file names Mapping SRB name to local file name List files for user Access through SRB ID, controlled by SRB Identify files by URIs Access controls on SRB name Note the local storage system directory indirection structure is needed to allow users to store 5 million images in a single virtual file system directory. Also, storage of data under an ID corresponding to the virtual file system is needed to assure consistency between the state information managed by the virtual name space and the files in the local storage system. The SRB system allows a user to create files within their own file system under their account ID, then turn on permission for the SRB account to read their files. They can then register their local files into the SRB name space, preserving both the directory structure and local file name within the virtual file system name space. This inverts the problem of managing choice of names for local versus virtual files. The user is able to impose their choice of names at either level, but operations specifying local file names are done independently of the VOStore interface. The set of operations that are performed upon the local storage system can be restricted to Unix file operations, or augmented to include SQL commands for databases. The VOStore interface would then need the ability to map operations from the virtual name space to both types of storage systems. Reagan Moore From owner-vospace@eso.org Wed Aug 3 14:13:14 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j73CCwhp016851 for ; Wed, 3 Aug 2005 14:12:58 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j73CCwqw016850 for vospace-outgoing; Wed, 3 Aug 2005 14:12:58 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j73CCrhp016829 for ; Wed, 3 Aug 2005 14:12:53 +0200 (MEST) Received: from [134.171.40.74] (pc010245.hq.eso.org [134.171.40.74]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id j73CCrE02831 for ; Wed, 3 Aug 2005 14:12:53 +0200 (MEST) Message-ID: <42F0B4C5.4070107@eso.org> Date: Wed, 03 Aug 2005 14:12:53 +0200 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore interface References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Reagan Moore wrote: > The differentiation between the VOStore and VOSpace interfaces is > becoming unclear. The latest draft implies that properties that were > originally associated with VOSpace would now be supported by VOStore. > I have to say that I agree that there seems to be some confusion in this area - with hindsight it was probably a mistake to defer the specification of VOSpace and work on VOStore alone as the "easier" problem - the specifications should be worked in tandem to see where it is most appropriate to place roles and responsibilities for particular use cases, so that a "global" solution is arrived at. I thought that the original separation into VOStore and VOSpace was done so that VOStore could be an essentially "dumb" BLOB repository that did what it was told by the VOStore layer when it comes to issues of file permissions and hierarchical file names. However, because no VOSpace specification was created, these more advanced features have crept into the VOStore layer. > > Let's look at the current VOStore and VOSpace proposal: > > VOStore VOSpace > Storage of objects management of virtual file > system > data stored under unspecified ID? > no user home directory User home directory > directory hierarchy Directory hierarchy > Unique file name within storage User-defined file names > Mapping VOSpace name to > VOStore name > List files for user > Restrict access by user identity? > Identify files with URIs > Access controls on local file name Access controls on VOSPace name > > This characterization mixes name space, mixes access controls, does not > provide consistent identity, does not allow consistent management. For > instance, if a URI is being provided for file identity within the > VOStore interface, then there is no need for user-specified names within > VOSTore. A second issue is the assumption that file access can be > restricted by user identity. This means that the VOStore must manage > the owner for each file, access controls for each file. File systems > usually do this by creating accounts for each user name and applying > Unix permissions. Is this capability to be provided now by both VOSpace > and VOStore? We need a cleaner separation of capabilities. This security aspect is crucial - it is clear that the owners of VOStores would not want to be managing user identity lists of all the VObs users at their stores - the fine grained access controls should be at the VOSpace level. If VOStores only respond to requests from trusted VOSpace services then this is possible, but I think that the perceived requirement for more detailed access control in the VOSpace layer has come about because prototype end-user applications have appeared that talk directly to the VOStore layer - of course, it is not surprising that this has happened because there was no VOSpace definition for the end user applications to talk to. How file/BLOB identity is managed is also crucial to producing a system that offers more than ftp. I thought that one of the fundamental driving use cases for a VOSpace was that the same BLOB could potentially live on serveral VOStores, and that when specifying a resource in VOSpace, in a workflow for instance, the resource could be retrieved from the VOStore that was "closest" on the network to where the resource would be consumed. This sort of use case does require some careful thought about the allocation and management of identifiers, and I think probably means that the VOStore will have to be aware of the VOSpace identifier. I also have an issue with reusing ivo: as the protocol part for the URI of an identifier in this system - ivo: is already well defined and used as the identifer for registry entries, and the "protocol" for accessing the entity associated with the identifier is defined in the registry interface standard. This means that given an identifier of the form ivo://authority.org/something#blah a software agent (or human for that matter) cannot tell by inspection whether the identifier refers to a file in VOSpace or is simply a reference to a registry entry (e.g. for a SkyNode) - this leads to software having to be more complex in order constantly to test for the different possibilities. I think that it would be better to have a URI with a different protocol part, vos: for instance, it would then be immediately apparent that the VOSpace protocol should be used to access the entity referred to by the identifier. > > Let's look at the Storage Resource Broker data grid separation of local > storage management from the virtual file system management: > > Local storage system SRB name space > Storage of objects management of virtual file > system > data stored under SRB ID > no user home directory User home directory > directory indirection structure Directory hierarchy > Unique file name within storage User-defined file names > Mapping SRB name to local > file name > List files for user > Access through SRB ID, controlled by SRB > Identify files by URIs > Access controls on SRB name > I think that as Regan points out the separation of responsibilities that SRB has with the local storage system is pretty much the right model for VOSpace and VOStore - though it means that SRB is pretty much at VOSpace level rather than a VOStore as is suggested in the current VOSpace definition document. -- Paul Harrison ESO Garching www.eso.org From owner-vospace@eso.org Wed Aug 3 20:02:44 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j73I29hp016200 for ; Wed, 3 Aug 2005 20:02:09 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j73I2929016199 for vospace-outgoing; Wed, 3 Aug 2005 20:02:09 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j73I1vhp016164 for ; Wed, 3 Aug 2005 20:01:57 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j73I1shx000472 for ; Wed, 3 Aug 2005 20:01:55 +0200 (CEST) Received: from [192.168.10.30] (vastfire.cacr.caltech.edu [131.215.145.253]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id j73I1lgh005445 for ; Wed, 3 Aug 2005 11:01:48 -0700 Message-ID: <42F10685.6010908@cacr.caltech.edu> Date: Wed, 03 Aug 2005 11:01:41 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore interface References: <42F0B4C5.4070107@eso.org> In-Reply-To: <42F0B4C5.4070107@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.3.20 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Hi, I think that most of what is VOStore and what is VOSpace is clear; however, the two grey areas are access control (authorization) and identifiers and this stems from the use case where the user wants direct access to a VOStore (e.g. a local store) and does not want to go through the VOSpace layer. Here are my suggestions for handling these areas: Access control: ------------------- A VOStore can run in two modes: authorized and unauthorized. An unauthorized VOStore is semantically equivalent to an anonymous ftp site: any authenticated user (we still maintain security) can put something in, move/rename it, get it and delete it. An authorized VOStore will only allow the requested operation if a valid authentication token is included in the request - all the VOStore has to do here is validate the authentication token. The generation of the authentication token is handled by VOSpace: it makes sure that the authenticated user has permission to do what they are requesting and if so, places a valid token in the request down to the VOStore. Identifiers: -------------- The protocol identifier ivo:// identifies a resource that exists in the VO. It does not promise that you can completely resolve a URI beginning ivo:// in a registry, merely that some component of the URI will relate to a resource that has a registry entry, i.e. the bit before the first # can be resolved in a registry. So I can go to a registry and find out where ivo://nvo.caltech/vostores/vostore1 is but I need to go to VOStore interface for this store to resolve ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we need to introduce a second protocol just for VOStore contents. Now resolution of individual VOStore identifiers has to be done at the VOStore level; however, VOSpace gives you the ability to set up a single logical identifier for multiple copies of the same resource so here we might want a separate protocol: vos and resolution of this identifier has to be done at the VOSpace level since VOSpace manages multiple VOStores. Cheers, Matthew Paul Harrison wrote: > Reagan Moore wrote: > >> The differentiation between the VOStore and VOSpace interfaces is >> becoming unclear. The latest draft implies that properties that were >> originally associated with VOSpace would now be supported by VOStore. >> > > I have to say that I agree that there seems to be some confusion in > this area - with hindsight it was probably a mistake to defer the > specification of VOSpace and work on VOStore alone as the "easier" > problem - the specifications should be worked in tandem to see where > it is most appropriate to place roles and responsibilities for > particular use cases, so that a "global" solution is arrived at. > > I thought that the original separation into VOStore and VOSpace was > done so that VOStore could be an essentially "dumb" BLOB repository > that did what it was told by the VOStore layer when it comes to issues > of file permissions and hierarchical file names. However, because no > VOSpace specification was created, these more advanced features have > crept into the VOStore layer. > >> >> Let's look at the current VOStore and VOSpace proposal: >> >> VOStore VOSpace >> Storage of objects management of virtual >> file system >> data stored under unspecified ID? >> no user home directory User home directory >> directory hierarchy Directory hierarchy >> Unique file name within storage User-defined file names >> Mapping VOSpace name to >> VOStore name >> List files for user >> Restrict access by user identity? >> Identify files with URIs >> Access controls on local file name Access controls on >> VOSPace name >> >> This characterization mixes name space, mixes access controls, does >> not provide consistent identity, does not allow consistent >> management. For instance, if a URI is being provided for file >> identity within the VOStore interface, then there is no need for >> user-specified names within VOSTore. A second issue is the >> assumption that file access can be restricted by user identity. This >> means that the VOStore must manage the owner for each file, access >> controls for each file. File systems usually do this by creating >> accounts for each user name and applying Unix permissions. Is this >> capability to be provided now by both VOSpace and VOStore? We need a >> cleaner separation of capabilities. > > > This security aspect is crucial - it is clear that the owners of > VOStores would not want to be managing user identity lists of all the > VObs users at their stores - the fine grained access controls should > be at the VOSpace level. If VOStores only respond to requests from > trusted VOSpace services then this is possible, but I think that the > perceived requirement for more detailed access control in the VOSpace > layer has come about because prototype end-user applications have > appeared that talk directly to the VOStore layer - of course, it is > not surprising that this has happened because there was no VOSpace > definition for the end user applications to talk to. > > How file/BLOB identity is managed is also crucial to producing a > system that offers more than ftp. I thought that one of the > fundamental driving use cases for a VOSpace was that the same BLOB > could potentially live on serveral VOStores, and that when specifying > a resource in VOSpace, in a workflow for instance, the resource could > be retrieved from the VOStore that was "closest" on the network to > where the resource would be consumed. This sort of use case does > require some careful thought about the allocation and management of > identifiers, and I think probably means that the VOStore will have to > be aware of the VOSpace identifier. > > I also have an issue with reusing ivo: as the protocol part for the > URI of an identifier in this system - ivo: is already well defined and > used as the identifer for registry entries, and the "protocol" for > accessing the entity associated with the identifier is defined in the > registry interface standard. This means that given an identifier of > the form ivo://authority.org/something#blah a software agent (or human > for that matter) cannot tell by inspection whether the identifier > refers to a file in VOSpace or is simply a reference to a registry > entry (e.g. for a SkyNode) - this leads to software having to be more > complex in order constantly to test for the different possibilities. I > think that it would be better to have a URI with a different protocol > part, vos: for instance, it would then be immediately apparent that > the VOSpace protocol should be used to access the entity referred to > by the identifier. > >> >> Let's look at the Storage Resource Broker data grid separation of >> local storage management from the virtual file system management: >> >> Local storage system SRB name space >> Storage of objects management of virtual >> file system >> data stored under SRB ID >> no user home directory User home directory >> directory indirection structure Directory hierarchy >> Unique file name within storage User-defined file names >> Mapping SRB name to local >> file name >> List files for user >> Access through SRB ID, controlled by SRB >> Identify files by URIs >> Access controls on SRB name >> > > I think that as Regan points out the separation of responsibilities > that SRB has with the local storage system is pretty much the right > model for VOSpace and VOStore - though it means that SRB is pretty > much at VOSpace level rather than a VOStore as is suggested in the > current VOSpace definition document. > From owner-vospace@eso.org Thu Aug 4 10:48:22 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j748m4Nd018748 for ; Thu, 4 Aug 2005 10:48:04 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j748m4N3018747 for vospace-outgoing; Thu, 4 Aug 2005 10:48:04 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j748m0Nd018717 for ; Thu, 4 Aug 2005 10:48:00 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j748lwhx026677 for ; Thu, 4 Aug 2005 10:47:58 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:56794) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1E0bOG-0002LD-3a (Exim 4.51) for vospace@ivoa.net (return-path ); Thu, 04 Aug 2005 09:47:48 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j748llZu018459 for ; Thu, 4 Aug 2005 09:47:47 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j748llaV026233 for ; Thu, 4 Aug 2005 09:47:47 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.12.10+Sun/8.12.10/Submit) with ESMTP id j748ll5l026229 for ; Thu, 4 Aug 2005 09:47:47 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 4 Aug 2005 09:47:47 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: vospace@ivoa.net Subject: Re: VOStore interface In-Reply-To: <42F10685.6010908@cacr.caltech.edu> Message-ID: References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.4.2 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 On Wed, 3 Aug 2005, Matthew Graham wrote: > A VOStore can run in two modes: authorized and unauthorized. An > unauthorized VOStore is semantically equivalent to an anonymous ftp > site: any authenticated user (we still maintain security) can put > something in, move/rename it, get it and delete it. Yes, and this mode also works as a shared workspace, so may be useful in the longer term. When we work out how to register stores then we should allow this mode to be registered. I suggest that for the ADASS demo we could use the unauthorized mode for "private" data on an honour system. However, there's a third mode: "locally authorized". In this, the store manages its own authorization policy. The simplest policy is that each data item is owned by the account that creates it, as determined in the authentication of the creation request, and the owner has implicit read, write and delete permissions on the owned items. If we allow direct access to stores that are not soley used as shared workspaces, which was implied by the Kyoto discussions, then we need this mode. I expect that AstroGrid will implement this mode, and we may do it in time for ADASS. > An authorized VOStore will only allow the requested operation if a valid > authentication token is included in the request - all the VOStore has to > do here is validate the authentication token. The generation of the > authentication token is handled by VOSpace: it makes sure that the > authenticated user has permission to do what they are requesting and if > so, places a valid token in the request down to the VOStore. Sounds good. One way of doing the "token" would be a service certificate for the VOspace service s.t that service makes requests to the stores in its own name. It would be better to reuse the authentication code that we already have then to introduce a new system. This form for the space-store communication fits with the locally-authorized store. The space is a kind of super-user with full access to all data items, extending slightly the authorization policy of the stores. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Thu Aug 4 11:56:33 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j749uONd027789 for ; Thu, 4 Aug 2005 11:56:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j749uOl8027787 for vospace-outgoing; Thu, 4 Aug 2005 11:56:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j749u9Nd027741 for ; Thu, 4 Aug 2005 11:56:09 +0200 (MEST) Received: from [134.171.40.74] (pc010245.hq.eso.org [134.171.40.74]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id j749u9E09529 for ; Thu, 4 Aug 2005 11:56:09 +0200 (MEST) Message-ID: <42F1E639.7080403@eso.org> Date: Thu, 04 Aug 2005 11:56:09 +0200 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore interface References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> In-Reply-To: <42F10685.6010908@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Matthew Graham wrote: > Hi, > > I think that most of what is VOStore and what is VOSpace is clear; > however, the two grey areas are access control (authorization) and > identifiers and this stems from the use case where the user wants direct > access to a VOStore (e.g. a local store) and does not want to go through > the VOSpace layer. This is is the core issue of the interaction between the layers - if VOSpace is supposed to be effectively a catalogue of what is in VOStore, then altering VOStore contents without informing VOSpace is going to cause problems. > > Access control: > ------------------- > > A VOStore can run in two modes: authorized and unauthorized. An > unauthorized VOStore is semantically equivalent to an anonymous ftp > site: any authenticated user (we still maintain security) can put > something in, move/rename it, get it and delete it. > An authorized VOStore will only allow the requested operation if a valid > authentication token is included in the request - all the VOStore has to > do here is validate the authentication token. The generation of the > authentication token is handled by VOSpace: it makes sure that the > authenticated user has permission to do what they are requesting and if > so, places a valid token in the request down to the VOStore. I think that this is a good scheme - however, is there to be a validation token per file or per VOStore? > > Identifiers: > -------------- > > The protocol identifier ivo:// identifies a resource that exists in the > VO. It does not promise that you can completely resolve a URI beginning > ivo:// in a registry, merely that some component of the URI will relate > to a resource that has a registry entry, i.e. the bit before the first # > can be resolved in a registry. So I can go to a registry and find out > where ivo://nvo.caltech/vostores/vostore1 is > but I need to go to VOStore interface for this store to resolve > ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we need > to introduce a second protocol just for VOStore contents. Introducing a new URI for vostore is not absolutely necessary, as you demonstrate above, you can invent any interpretation of the ivo: URI that you want, however, a separate URI scheme does have the benefits of * reducing complexity of client software that has to interpret VO URIs/URLs - they can make simple decisions based on string syntax rather than having to constantly query registries, which could become a performance issue. * adhereing more closely to established URI/URL manipulation conventions - the # character normally denotes a "fragment" of the referenced resource - it is arguable whether this useage is a fragment. We also need to consider carefully whether it is simply an identifier that is needed, or a locator, and indeed whether there need to be different schemes at the VOStore and VOSpace levels - for VOSpace URIs in particular there are questions which we potentially ignore by insisting that everything is in the ivo: scheme e.g. * do we want a single global authority? * do individual user's homes have separate roots in the namespace or are they just part of the directory hierarchy? * are relative URIs meaningful? Another argument for a new scheme is that it has been suggested that it would be nice to be able to reference fragments of the stored entity - e.g. parts of a VOTable - the ivo: scheme is already rather overburdened to allow this extra level of specification. > > Now resolution of individual VOStore identifiers has to be done at the > VOStore level; however, VOSpace gives you the ability to set up a single > logical identifier for multiple copies of the same resource so here we > might want a separate protocol: vos and resolution of this identifier > has to be done at the VOSpace level since VOSpace manages multiple > VOStores. > I think it is essential at least to have a new scheme at the VOSpace level ;-) -- Paul Harrison ESO Garching www.eso.org From owner-vospace@eso.org Thu Aug 4 19:48:06 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j74HloNd003812 for ; Thu, 4 Aug 2005 19:47:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j74HloN0003811 for vospace-outgoing; Thu, 4 Aug 2005 19:47:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j74HlkNd003807 for ; Thu, 4 Aug 2005 19:47:46 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j74Hlgin026661 for ; Thu, 4 Aug 2005 19:47:44 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j74HlYO24382; Thu, 4 Aug 2005 10:47:34 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42F10685.6010908@cacr.caltech.edu> References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> Date: Thu, 4 Aug 2005 10:01:09 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Re: VOStore interface Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.4.18 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 I would like to propose the following separation of identity and access control management. The issues appear to be how to separate support for local files in a local storage repository from the files that are registered into a shared collection that spans multiple storage repositories. An easy way to make the differentiation is to identify the usage model for each type of data management system. I would like to learn whether this approach would meet all of the IVOA requirements. Local storage repository: This is a storage system that is controlled by local administrators who establish access accounts for the persons who are allowed to use the system. The users can choose their own file names, manipulate the files with the utilities that are available on the local storage, and are authenticated by the local system. If desired, a user could log onto the local storage repository, and use a VO specific interface such as VOStore to access their own personal data. Since VOStore would be run under their account ID to access files that they own, there is no additional required authentication. They could also use other access mechanisms such as perl scripts, or Unix shell commands, C library calls, whatever is supported on the local storage repository. These access mechanisms allow them to access files that they own. A VOStore interface for this usage model would provide: - get file - put file - list files The only advantage is that if the VOStore interface were supported on all local storage repositories, the user would have a standard access mechanism. Shared collection - VOSpace: The purpose of the shared collection is to organize files across multiple storage repositories, provide a way to register files into the shared collection, establish access controls on the shared data, provide standard services for manipulating the files (Cone Search, SIAP, SSAP, Mosaic, ...), support replication, support selection of the closest file. The shared collection provides a global (or logical) name space that can be organized in a directory structure independently of the naming convention and path hierarchy employed at the local storage systems. Thus the VOSpace system must manage the mapping from the logical name space to the naming convention used in the local storage system. An account ID is established under which the shared collection (VOSpace) is able to deposit files in the local storage repository. This means the shared collection owns the data that is stored at the local storage repository. In order to access the data, a user would need to authenticate herself to the shared collection, which in turn authenticates itself to the local storage repository. Whether or not to allow the access is controlled by ACLs managed by VOSpace. This means that the authentication mechanism used by VOSpace is completely independent of the authentication mechanisms used by the local storage systems. In order to handle the fact that local storage systems use a variety of authentication mechanisms (Unix password, PKI certificates, Kerberos certificates, DCE credentials, ...) the VOSpace implementation could use the Generic Security Service API (GSSAPI) to handle the heterogeneity. In addition, an arbitrary authentication mechanism can be chosen for authenticating users to VOSpace. If a VOStore interface is provided by the local storage repository, then VOSpace would be able to invoke the VOStore access mechanism (running under the VOSpace account ID). Note that in this model VOStore does no authentication. All authentication is controlled by a combination of the local storage system and VOSpace. The type of operations that would be required by VOStore, however, are more sophisticated. They include: - get file - put file - list files - register an existing file into VOSpace, while mapping from the local name to the VOSpace preferred name - register an existing directory structure into VOSpace, while setting the VOSpace logical names and VOSpace directory structure to be the same as the local directory structure - register an existing local file into VOSpace as a replica of an existing VOSpace logical file. With the latter three commands, it is possible to meet the specific requirement that users be able to control the names of files both on the local system and in VOSpace. Note that for the user to access the local file system they required an account ID on the local file system. They then stored a local file under their own account ID. They would add read permission for the VOSpace account ID to their local file to permit access by VOSpace. This separates authorization cleanly between the local storage system (which only checks for access by local account IDs) and the VOSpace shared collection (which authorizes all accesses to files owned by VOSpace). This means that VOSpace is managing multiple levels of indirection: - mapping from the global or logical file name space to the local repository name space - mapping from an authenticated user through application of ACLs to decide whether the user can read a VOSpace owned file. - mapping preferred location for accessing replicas (typically pick a file on the file system with the user's IP address, then any other file system, then a tape archive) For completeness, VOStore may need an operation that sets access permission for VOSpace, when VOStore is run under the local user account ID. Reagan Moore > >I think that most of what is VOStore and what is VOSpace is clear; >however, the two grey areas are access control (authorization) and >identifiers and this stems from the use case where the user wants >direct access to a VOStore (e.g. a local store) and does not want to >go through the VOSpace layer. Here are my suggestions for handling >these areas: > >Access control: >------------------- > >A VOStore can run in two modes: authorized and unauthorized. An >unauthorized VOStore is semantically equivalent to an anonymous ftp >site: any authenticated user (we still maintain security) can put >something in, move/rename it, get it and delete it. >An authorized VOStore will only allow the requested operation if a >valid authentication token is included in the request - all the >VOStore has to do here is validate the authentication token. The >generation of the authentication token is handled by VOSpace: it >makes sure that the authenticated user has permission to do what >they are requesting and if so, places a valid token in the request >down to the VOStore. > >Identifiers: >-------------- > >The protocol identifier ivo:// identifies a resource that exists in >the VO. It does not promise that you can completely resolve a URI >beginning ivo:// in a registry, merely that some component of the >URI will relate to a resource that has a registry entry, i.e. the >bit before the first # can be resolved in a registry. So I can go to >a registry and find out where ivo://nvo.caltech/vostores/vostore1 is >but I need to go to VOStore interface for this store to resolve >ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we >need to introduce a second protocol just for VOStore contents. > >Now resolution of individual VOStore identifiers has to be done at >the VOStore level; however, VOSpace gives you the ability to set up >a single logical identifier for multiple copies of the same resource >so here we might want a separate protocol: vos and resolution of >this identifier has to be done at the VOSpace level since VOSpace >manages multiple VOStores. > > Cheers, > > Matthew > > >Paul Harrison wrote: > >>Reagan Moore wrote: >> >>>The differentiation between the VOStore and VOSpace interfaces is >>>becoming unclear. The latest draft implies that properties that >>>were originally associated with VOSpace would now be supported by >>>VOStore. >>> >> >>I have to say that I agree that there seems to be some confusion in >>this area - with hindsight it was probably a mistake to defer the >>specification of VOSpace and work on VOStore alone as the "easier" >>problem - the specifications should be worked in tandem to see >>where it is most appropriate to place roles and responsibilities >>for particular use cases, so that a "global" solution is arrived at. >> >>I thought that the original separation into VOStore and VOSpace was >>done so that VOStore could be an essentially "dumb" BLOB repository >>that did what it was told by the VOStore layer when it comes to >>issues of file permissions and hierarchical file names. However, >>because no VOSpace specification was created, these more advanced >>features have crept into the VOStore layer. >> >>> >>>Let's look at the current VOStore and VOSpace proposal: >>> >>>VOStore VOSpace >>>Storage of objects management of virtual >>>file system >>>data stored under unspecified ID? >>>no user home directory User home directory >>>directory hierarchy Directory hierarchy >>>Unique file name within storage User-defined file names >>> Mapping VOSpace name >>>to VOStore name >>> List files for user >>>Restrict access by user identity? >>>Identify files with URIs >>>Access controls on local file name Access controls on VOSPace name >>> >>>This characterization mixes name space, mixes access controls, >>>does not provide consistent identity, does not allow consistent >>>management. For instance, if a URI is being provided for file >>>identity within the VOStore interface, then there is no need for >>>user-specified names within VOSTore. A second issue is the >>>assumption that file access can be restricted by user identity. >>>This means that the VOStore must manage the owner for each file, >>>access controls for each file. File systems usually do this by >>>creating accounts for each user name and applying Unix >>>permissions. Is this capability to be provided now by both >>>VOSpace and VOStore? We need a cleaner separation of capabilities. >> >> >>This security aspect is crucial - it is clear that the owners of >>VOStores would not want to be managing user identity lists of all >>the VObs users at their stores - the fine grained access controls >>should be at the VOSpace level. If VOStores only respond to >>requests from trusted VOSpace services then this is possible, but I >>think that the perceived requirement for more detailed access >>control in the VOSpace layer has come about because prototype >>end-user applications have appeared that talk directly to the >>VOStore layer - of course, it is not surprising that this has >>happened because there was no VOSpace definition for the end user >>applications to talk to. >> >>How file/BLOB identity is managed is also crucial to producing a >>system that offers more than ftp. I thought that one of the >>fundamental driving use cases for a VOSpace was that the same BLOB >>could potentially live on serveral VOStores, and that when >>specifying a resource in VOSpace, in a workflow for instance, the >>resource could be retrieved from the VOStore that was "closest" on >>the network to where the resource would be consumed. This sort of >>use case does require some careful thought about the allocation and >>management of identifiers, and I think probably means that the >>VOStore will have to be aware of the VOSpace identifier. >> >>I also have an issue with reusing ivo: as the protocol part for the >>URI of an identifier in this system - ivo: is already well defined >>and used as the identifer for registry entries, and the "protocol" >>for accessing the entity associated with the identifier is defined >>in the registry interface standard. This means that given an >>identifier of the form ivo://authority.org/something#blah a >>software agent (or human for that matter) cannot tell by inspection >>whether the identifier refers to a file in VOSpace or is simply a >>reference to a registry entry (e.g. for a SkyNode) - this leads to >>software having to be more complex in order constantly to test for >>the different possibilities. I think that it would be better to >>have a URI with a different protocol part, vos: for instance, it >>would then be immediately apparent that the VOSpace protocol should >>be used to access the entity referred to by the identifier. >> >>> >>>Let's look at the Storage Resource Broker data grid separation of >>>local storage management from the virtual file system management: >>> >>>Local storage system SRB name space >>>Storage of objects management of virtual >>>file system >>>data stored under SRB ID >>>no user home directory User home directory >>>directory indirection structure Directory hierarchy >>>Unique file name within storage User-defined file names >>> Mapping SRB name to >>>local file name >>> List files for user >>>Access through SRB ID, controlled by SRB >>> Identify files by URIs >>> Access controls on SRB name >>> >> >>I think that as Regan points out the separation of responsibilities >>that SRB has with the local storage system is pretty much the >>right model for VOSpace and VOStore - though it means that SRB is >>pretty much at VOSpace level rather than a VOStore as is suggested >>in the current VOSpace definition document. From owner-vospace@eso.org Thu Aug 4 20:57:25 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j74IvFNd012657 for ; Thu, 4 Aug 2005 20:57:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j74IvFRV012655 for vospace-outgoing; Thu, 4 Aug 2005 20:57:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j74IvANd012632 for ; Thu, 4 Aug 2005 20:57:11 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j74Iv7in029166 for ; Thu, 4 Aug 2005 20:57:08 +0200 (CEST) Received: from [192.168.10.30] (vastfire.cacr.caltech.edu [131.215.145.253]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id j74Iv0gh014842 for ; Thu, 4 Aug 2005 11:57:01 -0700 Message-ID: <42F264F6.4090900@cacr.caltech.edu> Date: Thu, 04 Aug 2005 11:56:54 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore interface References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.4.20 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Reagan Moore wrote: > I would like to propose the following separation of identity and > access control management. The issues appear to be how to separate > support for local files in a local storage repository from the files > that are registered into a shared collection that spans multiple > storage repositories. An easy way to make the differentiation is to > identify the usage model for each type of data management system. I > would like to learn whether this approach would meet all of the IVOA > requirements. > > Local storage repository: > > This is a storage system that is controlled by local administrators > who establish access accounts for the persons who are allowed to use > the system. > The users can choose their own file names, manipulate the files with > the utilities that are available on the local storage, and are > authenticated by the local system. If desired, a user could log onto > the local storage repository, and use a VO specific interface such as > VOStore to access their own personal data. Since VOStore would be run > under their account ID to access files that they own, there is no > additional required authentication. They could also use other access > mechanisms such as perl scripts, or Unix shell commands, C library > calls, whatever is supported on the local storage repository. These > access mechanisms allow them to access files that they own. > > A VOStore interface for this usage model would provide: > - get file > - put file > - list files > The only advantage is that if the VOStore interface were supported on > all local storage repositories, the user would have a standard access > mechanism. > > Shared collection - VOSpace: > > The purpose of the shared collection is to organize files across > multiple storage repositories, provide a way to register files into > the shared collection, establish access controls on the shared data, > provide standard services for manipulating the files (Cone Search, > SIAP, SSAP, Mosaic, ...), support replication, support selection of > the closest file. > > The shared collection provides a global (or logical) name space that > can be organized in a directory structure independently of the naming > convention and path hierarchy employed at the local storage systems. > Thus the VOSpace system must manage the mapping from the logical name > space to the naming convention used in the local storage system. > > An account ID is established under which the shared collection > (VOSpace) is able to deposit files in the local storage repository. > This means the shared collection owns the data that is stored at the > local storage repository. In order to access the data, a user would > need to authenticate herself to the shared collection, which in turn > authenticates itself to the local storage repository. Whether or not > to allow the access is controlled by ACLs managed by VOSpace. This > means that the authentication mechanism used by VOSpace is completely > independent of the authentication mechanisms used by the local storage > systems. > > In order to handle the fact that local storage systems use a variety > of authentication mechanisms (Unix password, PKI certificates, > Kerberos certificates, DCE credentials, ...) the VOSpace > implementation could use the Generic Security Service API (GSSAPI) to > handle the heterogeneity. In addition, an arbitrary authentication > mechanism can be chosen for authenticating users to VOSpace. > > If a VOStore interface is provided by the local storage repository, > then VOSpace would be able to invoke the VOStore access mechanism > (running under the VOSpace account ID). Note that in this model > VOStore does no authentication. All authentication is controlled by a > combination of the local storage system and VOSpace. > > The type of operations that would be required by VOStore, however, are > more sophisticated. They include: > - get file > - put file > - list files > - register an existing file into VOSpace, while mapping from the local > name to the VOSpace preferred name > - register an existing directory structure into VOSpace, while setting > the VOSpace logical names and VOSpace directory structure to be the > same as the local directory structure > - register an existing local file into VOSpace as a replica of an > existing VOSpace logical file. > > With the latter three commands, it is possible to meet the specific > requirement that users be able to control the names of files both on > the local system and in VOSpace. Note that for the user to access the > local file system they required an account ID on the local file > system. They then stored a local file under their own account ID. > They would add read permission for the VOSpace account ID to their > local file to permit access by VOSpace. > > This separates authorization cleanly between the local storage system > (which only checks for access by local account IDs) and the VOSpace > shared collection (which authorizes all accesses to files owned by > VOSpace). This means that VOSpace is managing multiple levels of > indirection: > - mapping from the global or logical file name space to the local > repository name space > - mapping from an authenticated user through application of ACLs to > decide whether the user can read a VOSpace owned file. > - mapping preferred location for accessing replicas (typically pick a > file on the file system with the user's IP address, then any other > file system, then a tape archive) > > For completeness, VOStore may need an operation that sets access > permission for VOSpace, when VOStore is run under the local user > account ID. > > > Reagan Moore > > > >> >> I think that most of what is VOStore and what is VOSpace is clear; >> however, the two grey areas are access control (authorization) and >> identifiers and this stems from the use case where the user wants >> direct access to a VOStore (e.g. a local store) and does not want to >> go through the VOSpace layer. Here are my suggestions for handling >> these areas: >> >> Access control: >> ------------------- >> >> A VOStore can run in two modes: authorized and unauthorized. An >> unauthorized VOStore is semantically equivalent to an anonymous ftp >> site: any authenticated user (we still maintain security) can put >> something in, move/rename it, get it and delete it. >> An authorized VOStore will only allow the requested operation if a >> valid authentication token is included in the request - all the >> VOStore has to do here is validate the authentication token. The >> generation of the authentication token is handled by VOSpace: it >> makes sure that the authenticated user has permission to do what they >> are requesting and if so, places a valid token in the request down to >> the VOStore. >> >> Identifiers: >> -------------- >> >> The protocol identifier ivo:// identifies a resource that exists in >> the VO. It does not promise that you can completely resolve a URI >> beginning ivo:// in a registry, merely that some component of the URI >> will relate to a resource that has a registry entry, i.e. the bit >> before the first # can be resolved in a registry. So I can go to a >> registry and find out where ivo://nvo.caltech/vostores/vostore1 is >> but I need to go to VOStore interface for this store to resolve >> ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we >> need to introduce a second protocol just for VOStore contents. >> >> Now resolution of individual VOStore identifiers has to be done at >> the VOStore level; however, VOSpace gives you the ability to set up a >> single logical identifier for multiple copies of the same resource so >> here we might want a separate protocol: vos and resolution of this >> identifier has to be done at the VOSpace level since VOSpace manages >> multiple VOStores. >> >> Cheers, >> >> Matthew >> >> >> Paul Harrison wrote: >> >>> Reagan Moore wrote: >>> >>>> The differentiation between the VOStore and VOSpace interfaces is >>>> becoming unclear. The latest draft implies that properties that >>>> were originally associated with VOSpace would now be supported by >>>> VOStore. >>>> >>> >>> I have to say that I agree that there seems to be some confusion in >>> this area - with hindsight it was probably a mistake to defer the >>> specification of VOSpace and work on VOStore alone as the "easier" >>> problem - the specifications should be worked in tandem to see where >>> it is most appropriate to place roles and responsibilities for >>> particular use cases, so that a "global" solution is arrived at. >>> >>> I thought that the original separation into VOStore and VOSpace was >>> done so that VOStore could be an essentially "dumb" BLOB repository >>> that did what it was told by the VOStore layer when it comes to >>> issues of file permissions and hierarchical file names. However, >>> because no VOSpace specification was created, these more advanced >>> features have crept into the VOStore layer. >>> >>>> >>>> Let's look at the current VOStore and VOSpace proposal: >>>> >>>> VOStore VOSpace >>>> Storage of objects management of virtual >>>> file system >>>> data stored under unspecified ID? >>>> no user home directory User home directory >>>> directory hierarchy Directory hierarchy >>>> Unique file name within storage User-defined file names >>>> Mapping VOSpace name to >>>> VOStore name >>>> List files for user >>>> Restrict access by user identity? >>>> Identify files with URIs >>>> Access controls on local file name Access controls on >>>> VOSPace name >>>> >>>> This characterization mixes name space, mixes access controls, does >>>> not provide consistent identity, does not allow consistent >>>> management. For instance, if a URI is being provided for file >>>> identity within the VOStore interface, then there is no need for >>>> user-specified names within VOSTore. A second issue is the >>>> assumption that file access can be restricted by user identity. >>>> This means that the VOStore must manage the owner for each file, >>>> access controls for each file. File systems usually do this by >>>> creating accounts for each user name and applying Unix >>>> permissions. Is this capability to be provided now by both VOSpace >>>> and VOStore? We need a cleaner separation of capabilities. >>> >>> >>> >>> This security aspect is crucial - it is clear that the owners of >>> VOStores would not want to be managing user identity lists of all >>> the VObs users at their stores - the fine grained access controls >>> should be at the VOSpace level. If VOStores only respond to requests >>> from trusted VOSpace services then this is possible, but I think >>> that the perceived requirement for more detailed access control in >>> the VOSpace layer has come about because prototype end-user >>> applications have appeared that talk directly to the VOStore layer - >>> of course, it is not surprising that this has happened because there >>> was no VOSpace definition for the end user applications to talk to. >>> >>> How file/BLOB identity is managed is also crucial to producing a >>> system that offers more than ftp. I thought that one of the >>> fundamental driving use cases for a VOSpace was that the same BLOB >>> could potentially live on serveral VOStores, and that when >>> specifying a resource in VOSpace, in a workflow for instance, the >>> resource could be retrieved from the VOStore that was "closest" on >>> the network to where the resource would be consumed. This sort of >>> use case does require some careful thought about the allocation and >>> management of identifiers, and I think probably means that the >>> VOStore will have to be aware of the VOSpace identifier. >>> >>> I also have an issue with reusing ivo: as the protocol part for the >>> URI of an identifier in this system - ivo: is already well defined >>> and used as the identifer for registry entries, and the "protocol" >>> for accessing the entity associated with the identifier is defined >>> in the registry interface standard. This means that given an >>> identifier of the form ivo://authority.org/something#blah a software >>> agent (or human for that matter) cannot tell by inspection whether >>> the identifier refers to a file in VOSpace or is simply a reference >>> to a registry entry (e.g. for a SkyNode) - this leads to software >>> having to be more complex in order constantly to test for the >>> different possibilities. I think that it would be better to have a >>> URI with a different protocol part, vos: for instance, it would then >>> be immediately apparent that the VOSpace protocol should be used to >>> access the entity referred to by the identifier. >>> >>>> >>>> Let's look at the Storage Resource Broker data grid separation of >>>> local storage management from the virtual file system management: >>>> >>>> Local storage system SRB name space >>>> Storage of objects management of virtual >>>> file system >>>> data stored under SRB ID >>>> no user home directory User home directory >>>> directory indirection structure Directory hierarchy >>>> Unique file name within storage User-defined file names >>>> Mapping SRB name to >>>> local file name >>>> List files for user >>>> Access through SRB ID, controlled by SRB >>>> Identify files by URIs >>>> Access controls on SRB >>>> name >>>> >>> >>> I think that as Regan points out the separation of responsibilities >>> that SRB has with the local storage system is pretty much the right >>> model for VOSpace and VOStore - though it means that SRB is pretty >>> much at VOSpace level rather than a VOStore as is suggested in the >>> current VOSpace definition document. >> > Hi, If you also allow the possibility that the local storage repository can run in an unauthorized (anonymous access) manner then this is exactly what Guy and I were suggesting. Does that mean that we actually all agree on this :-) Cheers, Matthew From owner-vospace@eso.org Fri Aug 5 19:26:47 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j75HQb0e023250 for ; Fri, 5 Aug 2005 19:26:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j75HQbkD023249 for vospace-outgoing; Fri, 5 Aug 2005 19:26:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j75HQX0e023199 for ; Fri, 5 Aug 2005 19:26:34 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j75HQUin013170 for ; Fri, 5 Aug 2005 19:26:31 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j75HQMN02235; Fri, 5 Aug 2005 10:26:22 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42F264F6.4090900@cacr.caltech.edu> References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> Date: Fri, 5 Aug 2005 10:26:04 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Re: VOStore interface Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.5.11 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Matthew: The expectation is that the VOStore interface does not need to do either authentication or authorization. If a person is working directly with a local storage system, then they are accessing their own personal data while running under their personal account ID. They can execute the VOStore interface as a local application. If VOSpace is accessing the local storage system through VOStore, then VOSpace authenticates its access to the local storage system to read or write files under the VOSpace account ID. Again VOStore is just a local application that VOSpace executes. If the owner of data on the local storage repository chooses to make a file world readable, then VOSpace would be able to access the file through VOStore. Reagan >Reagan Moore wrote: > >>I would like to propose the following separation of identity and >>access control management. The issues appear to be how to separate >>support for local files in a local storage repository from the >>files that are registered into a shared collection that spans >>multiple storage repositories. An easy way to make the >>differentiation is to identify the usage model for each type of >>data management system. I would like to learn whether this >>approach would meet all of the IVOA requirements. >> >>Local storage repository: >> >>This is a storage system that is controlled by local administrators >>who establish access accounts for the persons who are allowed to >>use the system. >>The users can choose their own file names, manipulate the files >>with the utilities that are available on the local storage, and are >>authenticated by the local system. If desired, a user could log >>onto the local storage repository, and use a VO specific interface >>such as VOStore to access their own personal data. Since VOStore >>would be run under their account ID to access files that they own, >>there is no additional required authentication. They could also >>use other access mechanisms such as perl scripts, or Unix shell >>commands, C library calls, whatever is supported on the local >>storage repository. These access mechanisms allow them to access >>files that they own. >> >>A VOStore interface for this usage model would provide: >>- get file >>- put file >>- list files >>The only advantage is that if the VOStore interface were supported >>on all local storage repositories, the user would have a standard >>access mechanism. >> >>Shared collection - VOSpace: >> >>The purpose of the shared collection is to organize files across >>multiple storage repositories, provide a way to register files into >>the shared collection, establish access controls on the shared >>data, provide standard services for manipulating the files (Cone >>Search, SIAP, SSAP, Mosaic, ...), support replication, support >>selection of the closest file. >> >>The shared collection provides a global (or logical) name space >>that can be organized in a directory structure independently of the >>naming convention and path hierarchy employed at the local storage >>systems. Thus the VOSpace system must manage the mapping from the >>logical name space to the naming convention used in the local >>storage system. >> >>An account ID is established under which the shared collection >>(VOSpace) is able to deposit files in the local storage repository. >>This means the shared collection owns the data that is stored at >>the local storage repository. In order to access the data, a user >>would need to authenticate herself to the shared collection, which >>in turn authenticates itself to the local storage repository. >>Whether or not to allow the access is controlled by ACLs managed by >>VOSpace. This means that the authentication mechanism used by >>VOSpace is completely independent of the authentication mechanisms >>used by the local storage systems. >> >>In order to handle the fact that local storage systems use a >>variety of authentication mechanisms (Unix password, PKI >>certificates, Kerberos certificates, DCE credentials, ...) the >>VOSpace implementation could use the Generic Security Service API >>(GSSAPI) to handle the heterogeneity. In addition, an arbitrary >>authentication mechanism can be chosen for authenticating users to >>VOSpace. >> >>If a VOStore interface is provided by the local storage repository, >>then VOSpace would be able to invoke the VOStore access mechanism >>(running under the VOSpace account ID). Note that in this model >>VOStore does no authentication. All authentication is controlled >>by a combination of the local storage system and VOSpace. >> >>The type of operations that would be required by VOStore, however, >>are more sophisticated. They include: >>- get file >>- put file >>- list files >>- register an existing file into VOSpace, while mapping from the >>local name to the VOSpace preferred name >>- register an existing directory structure into VOSpace, while >>setting the VOSpace logical names and VOSpace directory structure >>to be the same as the local directory structure >>- register an existing local file into VOSpace as a replica of an >>existing VOSpace logical file. >> >>With the latter three commands, it is possible to meet the specific >>requirement that users be able to control the names of files both >>on the local system and in VOSpace. Note that for the user to >>access the local file system they required an account ID on the >>local file system. They then stored a local file under their own >>account ID. They would add read permission for the VOSpace account >>ID to their local file to permit access by VOSpace. >> >>This separates authorization cleanly between the local storage >>system (which only checks for access by local account IDs) and the >>VOSpace shared collection (which authorizes all accesses to files >>owned by VOSpace). This means that VOSpace is managing multiple >>levels of indirection: >>- mapping from the global or logical file name space to the local >>repository name space >>- mapping from an authenticated user through application of ACLs to >>decide whether the user can read a VOSpace owned file. >>- mapping preferred location for accessing replicas (typically pick >>a file on the file system with the user's IP address, then any >>other file system, then a tape archive) >> >>For completeness, VOStore may need an operation that sets access >>permission for VOSpace, when VOStore is run under the local user >>account ID. >> >> >>Reagan Moore >> >> >>> >>>I think that most of what is VOStore and what is VOSpace is clear; >>>however, the two grey areas are access control (authorization) and >>>identifiers and this stems from the use case where the user wants >>>direct access to a VOStore (e.g. a local store) and does not want >>>to go through the VOSpace layer. Here are my suggestions for >>>handling these areas: >>> >>>Access control: >>>------------------- >>> >>>A VOStore can run in two modes: authorized and unauthorized. An >>>unauthorized VOStore is semantically equivalent to an anonymous >>>ftp site: any authenticated user (we still maintain security) can >>>put something in, move/rename it, get it and delete it. >>>An authorized VOStore will only allow the requested operation if a >>>valid authentication token is included in the request - all the >>>VOStore has to do here is validate the authentication token. The >>>generation of the authentication token is handled by VOSpace: it >>>makes sure that the authenticated user has permission to do what >>>they are requesting and if so, places a valid token in the request >>>down to the VOStore. >>> >>>Identifiers: >>>-------------- >>> >>>The protocol identifier ivo:// identifies a resource that exists >>>in the VO. It does not promise that you can completely resolve a >>>URI beginning ivo:// in a registry, merely that some component of >>>the URI will relate to a resource that has a registry entry, i.e. >>>the bit before the first # can be resolved in a registry. So I can >>>go to a registry and find out where >>>ivo://nvo.caltech/vostores/vostore1 is >>>but I need to go to VOStore interface for this store to resolve >>>ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we >>>need to introduce a second protocol just for VOStore contents. >>> >>>Now resolution of individual VOStore identifiers has to be done at >>>the VOStore level; however, VOSpace gives you the ability to set >>>up a single logical identifier for multiple copies of the same >>>resource so here we might want a separate protocol: vos and >>>resolution of this identifier has to be done at the VOSpace level >>>since VOSpace manages multiple VOStores. >>> >>> Cheers, >>> >>> Matthew >>> >>> >>>Paul Harrison wrote: >>> >>>>Reagan Moore wrote: >>>> >>>>>The differentiation between the VOStore and VOSpace interfaces >>>>>is becoming unclear. The latest draft implies that properties >>>>>that were originally associated with VOSpace would now be >>>>>supported by VOStore. >>>>> >>>> >>>>I have to say that I agree that there seems to be some confusion >>>>in this area - with hindsight it was probably a mistake to defer >>>>the specification of VOSpace and work on VOStore alone as the >>>>"easier" problem - the specifications should be worked in tandem >>>>to see where it is most appropriate to place roles and >>>>responsibilities for particular use cases, so that a "global" >>>>solution is arrived at. >>>> >>>>I thought that the original separation into VOStore and VOSpace >>>>was done so that VOStore could be an essentially "dumb" BLOB >>>>repository that did what it was told by the VOStore layer when it >>>>comes to issues of file permissions and hierarchical file names. >>>>However, because no VOSpace specification was created, these more >>>>advanced features have crept into the VOStore layer. >>>> >>>>> >>>>>Let's look at the current VOStore and VOSpace proposal: >>>>> >>>>>VOStore VOSpace >>>>>Storage of objects management of >>>>>virtual file system >>>>>data stored under unspecified ID? >>>>>no user home directory User home directory >>>>>directory hierarchy Directory hierarchy >>>>>Unique file name within storage User-defined file names >>>>> Mapping VOSpace name >>>>>to VOStore name >>>>> List files for user >>>>>Restrict access by user identity? >>>>>Identify files with URIs >>>>>Access controls on local file name Access controls on >>>>>VOSPace name >>>>> >>>>>This characterization mixes name space, mixes access controls, >>>>>does not provide consistent identity, does not allow consistent >>>>>management. For instance, if a URI is being provided for file >>>>>identity within the VOStore interface, then there is no need for >>>>>user-specified names within VOSTore. A second issue is the >>>>>assumption that file access can be restricted by user identity. >>>>>This means that the VOStore must manage the owner for each file, >>>>>access controls for each file. File systems usually do this by >>>>>creating accounts for each user name and applying Unix >>>>>permissions. Is this capability to be provided now by both >>>>>VOSpace and VOStore? We need a cleaner separation of >>>>>capabilities. >>>> >>>> >>>> >>>>This security aspect is crucial - it is clear that the owners of >>>>VOStores would not want to be managing user identity lists of all >>>>the VObs users at their stores - the fine grained access controls >>>>should be at the VOSpace level. If VOStores only respond to >>>>requests from trusted VOSpace services then this is possible, but >>>>I think that the perceived requirement for more detailed access >>>>control in the VOSpace layer has come about because prototype >>>>end-user applications have appeared that talk directly to the >>>>VOStore layer - of course, it is not surprising that this has >>>>happened because there was no VOSpace definition for the end user >>>>applications to talk to. >>>> >>>>How file/BLOB identity is managed is also crucial to producing a >>>>system that offers more than ftp. I thought that one of the >>>>fundamental driving use cases for a VOSpace was that the same >>>>BLOB could potentially live on serveral VOStores, and that when >>>>specifying a resource in VOSpace, in a workflow for instance, the >>>>resource could be retrieved from the VOStore that was "closest" >>>>on the network to where the resource would be consumed. This sort >>>>of use case does require some careful thought about the >>>>allocation and management of identifiers, and I think probably >>>>means that the VOStore will have to be aware of the VOSpace >>>>identifier. >>>> >>>>I also have an issue with reusing ivo: as the protocol part for >>>>the URI of an identifier in this system - ivo: is already well >>>>defined and used as the identifer for registry entries, and the >>>>"protocol" for accessing the entity associated with the >>>>identifier is defined in the registry interface standard. This >>>>means that given an identifier of the form >>>>ivo://authority.org/something#blah a software agent (or human for >>>>that matter) cannot tell by inspection whether the identifier >>>>refers to a file in VOSpace or is simply a reference to a >>>>registry entry (e.g. for a SkyNode) - this leads to software >>>>having to be more complex in order constantly to test for the >>>>different possibilities. I think that it would be better to have >>>>a URI with a different protocol part, vos: for instance, it would >>>>then be immediately apparent that the VOSpace protocol should be >>>>used to access the entity referred to by the identifier. >>>> >>>>> >>>>>Let's look at the Storage Resource Broker data grid separation >>>>>of local storage management from the virtual file system >>>>>management: >>>>> >>>>>Local storage system SRB name space >>>>>Storage of objects management of >>>>>virtual file system >>>>>data stored under SRB ID >>>>>no user home directory User home directory >>>>>directory indirection structure Directory hierarchy >>>>>Unique file name within storage User-defined file names >>>>> Mapping SRB name to >>>>>local file name >>>>> List files for user >>>>>Access through SRB ID, controlled by SRB >>>>> Identify files by URIs >>>>> Access controls on SRB name >>>>> >>>> >>>>I think that as Regan points out the separation of >>>>responsibilities that SRB has with the local storage system is >>>>pretty much the right model for VOSpace and VOStore - though it >>>>means that SRB is pretty much at VOSpace level rather than a >>>>VOStore as is suggested in the current VOSpace definition >>>>document. >>> >> >Hi, > >If you also allow the possibility that the local storage repository >can run in an unauthorized (anonymous access) manner then this is >exactly what Guy and I were suggesting. Does that mean that we >actually all agree on this :-) > > Cheers, > > Matthew From owner-vospace@eso.org Fri Aug 5 21:34:18 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j75JY80e007840 for ; Fri, 5 Aug 2005 21:34:09 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j75JY8FF007839 for vospace-outgoing; Fri, 5 Aug 2005 21:34:08 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j75JY40e007833 for ; Fri, 5 Aug 2005 21:34:04 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j75IMxin014774 for ; Fri, 5 Aug 2005 20:23:00 +0200 (CEST) Received: from [192.168.10.30] (vastfire.cacr.caltech.edu [131.215.145.253]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id j75IMrgh021120 for ; Fri, 5 Aug 2005 11:22:53 -0700 Message-ID: <42F3AE77.4020407@cacr.caltech.edu> Date: Fri, 05 Aug 2005 11:22:47 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore interface References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.5.13 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Hi, If the user is accessing the local storage system directly then they can do whatever they want. VOStore, however, is the presentation of that repository to the VO world and does not necessarily interface with a VOSpace layer: this means that the VOStore interface has to be capable of handling the VO authentication mechanism. The authorization story is as we seemed to have agreed. Cheers, Matthew Reagan Moore wrote: > Matthew: > > The expectation is that the VOStore interface does not need to do > either authentication or authorization. If a person is working > directly with a local storage system, then they are accessing their > own personal data while running under their personal account ID. They > can execute the VOStore interface as a local application. > > If VOSpace is accessing the local storage system through VOStore, then > VOSpace authenticates its access to the local storage system to read > or write files under the VOSpace account ID. Again VOStore is just a > local application that VOSpace executes. > > If the owner of data on the local storage repository chooses to make a > file world readable, then VOSpace would be able to access the file > through VOStore. > > Reagan > > > >> Reagan Moore wrote: >> >>> I would like to propose the following separation of identity and >>> access control management. The issues appear to be how to separate >>> support for local files in a local storage repository from the files >>> that are registered into a shared collection that spans multiple >>> storage repositories. An easy way to make the differentiation is to >>> identify the usage model for each type of data management system. I >>> would like to learn whether this approach would meet all of the IVOA >>> requirements. >>> >>> Local storage repository: >>> >>> This is a storage system that is controlled by local administrators >>> who establish access accounts for the persons who are allowed to use >>> the system. >>> The users can choose their own file names, manipulate the files with >>> the utilities that are available on the local storage, and are >>> authenticated by the local system. If desired, a user could log >>> onto the local storage repository, and use a VO specific interface >>> such as VOStore to access their own personal data. Since VOStore >>> would be run under their account ID to access files that they own, >>> there is no additional required authentication. They could also use >>> other access mechanisms such as perl scripts, or Unix shell >>> commands, C library calls, whatever is supported on the local >>> storage repository. These access mechanisms allow them to access >>> files that they own. >>> >>> A VOStore interface for this usage model would provide: >>> - get file >>> - put file >>> - list files >>> The only advantage is that if the VOStore interface were supported >>> on all local storage repositories, the user would have a standard >>> access mechanism. >>> >>> Shared collection - VOSpace: >>> >>> The purpose of the shared collection is to organize files across >>> multiple storage repositories, provide a way to register files into >>> the shared collection, establish access controls on the shared data, >>> provide standard services for manipulating the files (Cone Search, >>> SIAP, SSAP, Mosaic, ...), support replication, support selection of >>> the closest file. >>> >>> The shared collection provides a global (or logical) name space that >>> can be organized in a directory structure independently of the >>> naming convention and path hierarchy employed at the local storage >>> systems. Thus the VOSpace system must manage the mapping from the >>> logical name space to the naming convention used in the local >>> storage system. >>> >>> An account ID is established under which the shared collection >>> (VOSpace) is able to deposit files in the local storage repository. >>> This means the shared collection owns the data that is stored at the >>> local storage repository. In order to access the data, a user would >>> need to authenticate herself to the shared collection, which in turn >>> authenticates itself to the local storage repository. Whether or not >>> to allow the access is controlled by ACLs managed by VOSpace. This >>> means that the authentication mechanism used by VOSpace is >>> completely independent of the authentication mechanisms used by the >>> local storage systems. >>> >>> In order to handle the fact that local storage systems use a variety >>> of authentication mechanisms (Unix password, PKI certificates, >>> Kerberos certificates, DCE credentials, ...) the VOSpace >>> implementation could use the Generic Security Service API (GSSAPI) >>> to handle the heterogeneity. In addition, an arbitrary >>> authentication mechanism can be chosen for authenticating users to >>> VOSpace. >>> >>> If a VOStore interface is provided by the local storage repository, >>> then VOSpace would be able to invoke the VOStore access mechanism >>> (running under the VOSpace account ID). Note that in this model >>> VOStore does no authentication. All authentication is controlled by >>> a combination of the local storage system and VOSpace. >>> >>> The type of operations that would be required by VOStore, however, >>> are more sophisticated. They include: >>> - get file >>> - put file >>> - list files >>> - register an existing file into VOSpace, while mapping from the >>> local name to the VOSpace preferred name >>> - register an existing directory structure into VOSpace, while >>> setting the VOSpace logical names and VOSpace directory structure to >>> be the same as the local directory structure >>> - register an existing local file into VOSpace as a replica of an >>> existing VOSpace logical file. >>> >>> With the latter three commands, it is possible to meet the specific >>> requirement that users be able to control the names of files both on >>> the local system and in VOSpace. Note that for the user to access >>> the local file system they required an account ID on the local file >>> system. They then stored a local file under their own account ID. >>> They would add read permission for the VOSpace account ID to their >>> local file to permit access by VOSpace. >>> >>> This separates authorization cleanly between the local storage >>> system (which only checks for access by local account IDs) and the >>> VOSpace shared collection (which authorizes all accesses to files >>> owned by VOSpace). This means that VOSpace is managing multiple >>> levels of indirection: >>> - mapping from the global or logical file name space to the local >>> repository name space >>> - mapping from an authenticated user through application of ACLs to >>> decide whether the user can read a VOSpace owned file. >>> - mapping preferred location for accessing replicas (typically pick >>> a file on the file system with the user's IP address, then any other >>> file system, then a tape archive) >>> >>> For completeness, VOStore may need an operation that sets access >>> permission for VOSpace, when VOStore is run under the local user >>> account ID. >>> >>> >>> Reagan Moore >>> >>> >>>> >>>> I think that most of what is VOStore and what is VOSpace is clear; >>>> however, the two grey areas are access control (authorization) and >>>> identifiers and this stems from the use case where the user wants >>>> direct access to a VOStore (e.g. a local store) and does not want >>>> to go through the VOSpace layer. Here are my suggestions for >>>> handling these areas: >>>> >>>> Access control: >>>> ------------------- >>>> >>>> A VOStore can run in two modes: authorized and unauthorized. An >>>> unauthorized VOStore is semantically equivalent to an anonymous ftp >>>> site: any authenticated user (we still maintain security) can put >>>> something in, move/rename it, get it and delete it. >>>> An authorized VOStore will only allow the requested operation if a >>>> valid authentication token is included in the request - all the >>>> VOStore has to do here is validate the authentication token. The >>>> generation of the authentication token is handled by VOSpace: it >>>> makes sure that the authenticated user has permission to do what >>>> they are requesting and if so, places a valid token in the request >>>> down to the VOStore. >>>> >>>> Identifiers: >>>> -------------- >>>> >>>> The protocol identifier ivo:// identifies a resource that exists in >>>> the VO. It does not promise that you can completely resolve a URI >>>> beginning ivo:// in a registry, merely that some component of the >>>> URI will relate to a resource that has a registry entry, i.e. the >>>> bit before the first # can be resolved in a registry. So I can go >>>> to a registry and find out where >>>> ivo://nvo.caltech/vostores/vostore1 is >>>> but I need to go to VOStore interface for this store to resolve >>>> ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we >>>> need to introduce a second protocol just for VOStore contents. >>>> >>>> Now resolution of individual VOStore identifiers has to be done at >>>> the VOStore level; however, VOSpace gives you the ability to set up >>>> a single logical identifier for multiple copies of the same >>>> resource so here we might want a separate protocol: vos and >>>> resolution of this identifier has to be done at the VOSpace level >>>> since VOSpace manages multiple VOStores. >>>> >>>> Cheers, >>>> >>>> Matthew >>>> >>>> >>>> Paul Harrison wrote: >>>> >>>>> Reagan Moore wrote: >>>>> >>>>>> The differentiation between the VOStore and VOSpace interfaces is >>>>>> becoming unclear. The latest draft implies that properties that >>>>>> were originally associated with VOSpace would now be supported by >>>>>> VOStore. >>>>>> >>>>> >>>>> I have to say that I agree that there seems to be some confusion >>>>> in this area - with hindsight it was probably a mistake to defer >>>>> the specification of VOSpace and work on VOStore alone as the >>>>> "easier" problem - the specifications should be worked in tandem >>>>> to see where it is most appropriate to place roles and >>>>> responsibilities for particular use cases, so that a "global" >>>>> solution is arrived at. >>>>> >>>>> I thought that the original separation into VOStore and VOSpace >>>>> was done so that VOStore could be an essentially "dumb" BLOB >>>>> repository that did what it was told by the VOStore layer when it >>>>> comes to issues of file permissions and hierarchical file names. >>>>> However, because no VOSpace specification was created, these more >>>>> advanced features have crept into the VOStore layer. >>>>> >>>>>> >>>>>> Let's look at the current VOStore and VOSpace proposal: >>>>>> >>>>>> VOStore VOSpace >>>>>> Storage of objects management of virtual >>>>>> file system >>>>>> data stored under unspecified ID? >>>>>> no user home directory User home directory >>>>>> directory hierarchy Directory hierarchy >>>>>> Unique file name within storage User-defined file names >>>>>> Mapping VOSpace name >>>>>> to VOStore name >>>>>> List files for user >>>>>> Restrict access by user identity? >>>>>> Identify files with URIs >>>>>> Access controls on local file name Access controls on >>>>>> VOSPace name >>>>>> >>>>>> This characterization mixes name space, mixes access controls, >>>>>> does not provide consistent identity, does not allow consistent >>>>>> management. For instance, if a URI is being provided for file >>>>>> identity within the VOStore interface, then there is no need for >>>>>> user-specified names within VOSTore. A second issue is the >>>>>> assumption that file access can be restricted by user identity. >>>>>> This means that the VOStore must manage the owner for each file, >>>>>> access controls for each file. File systems usually do this by >>>>>> creating accounts for each user name and applying Unix >>>>>> permissions. Is this capability to be provided now by both >>>>>> VOSpace and VOStore? We need a cleaner separation of capabilities. >>>>> >>>>> >>>>> >>>>> >>>>> This security aspect is crucial - it is clear that the owners of >>>>> VOStores would not want to be managing user identity lists of all >>>>> the VObs users at their stores - the fine grained access controls >>>>> should be at the VOSpace level. If VOStores only respond to >>>>> requests from trusted VOSpace services then this is possible, but >>>>> I think that the perceived requirement for more detailed access >>>>> control in the VOSpace layer has come about because prototype >>>>> end-user applications have appeared that talk directly to the >>>>> VOStore layer - of course, it is not surprising that this has >>>>> happened because there was no VOSpace definition for the end user >>>>> applications to talk to. >>>>> >>>>> How file/BLOB identity is managed is also crucial to producing a >>>>> system that offers more than ftp. I thought that one of the >>>>> fundamental driving use cases for a VOSpace was that the same >>>>> BLOB could potentially live on serveral VOStores, and that when >>>>> specifying a resource in VOSpace, in a workflow for instance, the >>>>> resource could be retrieved from the VOStore that was "closest" on >>>>> the network to where the resource would be consumed. This sort of >>>>> use case does require some careful thought about the allocation >>>>> and management of identifiers, and I think probably means that the >>>>> VOStore will have to be aware of the VOSpace identifier. >>>>> >>>>> I also have an issue with reusing ivo: as the protocol part for >>>>> the URI of an identifier in this system - ivo: is already well >>>>> defined and used as the identifer for registry entries, and the >>>>> "protocol" for accessing the entity associated with the identifier >>>>> is defined in the registry interface standard. This means that >>>>> given an identifier of the form ivo://authority.org/something#blah >>>>> a software agent (or human for that matter) cannot tell by >>>>> inspection whether the identifier refers to a file in VOSpace or >>>>> is simply a reference to a registry entry (e.g. for a SkyNode) - >>>>> this leads to software having to be more complex in order >>>>> constantly to test for the different possibilities. I think that >>>>> it would be better to have a URI with a different protocol part, >>>>> vos: for instance, it would then be immediately apparent that the >>>>> VOSpace protocol should be used to access the entity referred to >>>>> by the identifier. >>>>> >>>>>> >>>>>> Let's look at the Storage Resource Broker data grid separation of >>>>>> local storage management from the virtual file system management: >>>>>> >>>>>> Local storage system SRB name space >>>>>> Storage of objects management of virtual >>>>>> file system >>>>>> data stored under SRB ID >>>>>> no user home directory User home directory >>>>>> directory indirection structure Directory hierarchy >>>>>> Unique file name within storage User-defined file names >>>>>> Mapping SRB name to >>>>>> local file name >>>>>> List files for user >>>>>> Access through SRB ID, controlled by SRB >>>>>> Identify files by URIs >>>>>> Access controls on >>>>>> SRB name >>>>>> >>>>> >>>>> I think that as Regan points out the separation of >>>>> responsibilities that SRB has with the local storage system is >>>>> pretty much the right model for VOSpace and VOStore - though it >>>>> means that SRB is pretty much at VOSpace level rather than a >>>>> VOStore as is suggested in the current VOSpace definition document. >>>> >>>> >>> >> Hi, >> >> If you also allow the possibility that the local storage repository >> can run in an unauthorized (anonymous access) manner then this is >> exactly what Guy and I were suggesting. Does that mean that we >> actually all agree on this :-) >> >> Cheers, >> >> Matthew > > From owner-vospace@eso.org Sat Aug 6 02:12:36 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j760CLuM002528 for ; Sat, 6 Aug 2005 02:12:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j760CLve002527 for vospace-outgoing; Sat, 6 Aug 2005 02:12:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j760CHuM002520 for ; Sat, 6 Aug 2005 02:12:18 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j760CEin025020 for ; Sat, 6 Aug 2005 02:12:15 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j760C7725318; Fri, 5 Aug 2005 17:12:07 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42F3AE77.4020407@cacr.caltech.edu> References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> Date: Fri, 5 Aug 2005 17:11:56 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Re: VOStore interface Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.5.27 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Matthew: This is where we differ in the specification. Which account does VOStore run under on the local storage system? Reagan >Hi, > >If the user is accessing the local storage system directly then they >can do whatever they want. VOStore, however, is the presentation of >that repository to the VO world and does not necessarily interface >with a VOSpace layer: this means that the VOStore interface has to >be capable of handling the VO authentication mechanism. The >authorization story is as we seemed to have agreed. > > Cheers, > > Matthew > > >Reagan Moore wrote: > >>Matthew: >> >>The expectation is that the VOStore interface does not need to do >>either authentication or authorization. If a person is working >>directly with a local storage system, then they are accessing their >>own personal data while running under their personal account ID. >>They can execute the VOStore interface as a local application. >> >>If VOSpace is accessing the local storage system through VOStore, >>then VOSpace authenticates its access to the local storage system >>to read or write files under the VOSpace account ID. Again VOStore >>is just a local application that VOSpace executes. >> >>If the owner of data on the local storage repository chooses to >>make a file world readable, then VOSpace would be able to access >>the file through VOStore. >> >>Reagan >> >> >>>Reagan Moore wrote: >>> >>>>I would like to propose the following separation of identity and >>>>access control management. The issues appear to be how to >>>>separate support for local files in a local storage repository >>>>from the files that are registered into a shared collection that >>>>spans multiple storage repositories. An easy way to make the >>>>differentiation is to identify the usage model for each type of >>>>data management system. I would like to learn whether this >>>>approach would meet all of the IVOA requirements. >>>> >>>>Local storage repository: >>>> >>>>This is a storage system that is controlled by local >>>>administrators who establish access accounts for the persons who >>>>are allowed to use the system. >>>>The users can choose their own file names, manipulate the files >>>>with the utilities that are available on the local storage, and >>>>are authenticated by the local system. If desired, a user could >>>>log onto the local storage repository, and use a VO specific >>>>interface such as VOStore to access their own personal data. >>>>Since VOStore would be run under their account ID to access files >>>>that they own, there is no additional required authentication. >>>>They could also use other access mechanisms such as perl scripts, >>>>or Unix shell commands, C library calls, whatever is supported on >>>>the local storage repository. These access mechanisms allow them >>>>to access files that they own. >>>> >>>>A VOStore interface for this usage model would provide: >>>>- get file >>>>- put file >>>>- list files >>>>The only advantage is that if the VOStore interface were >>>>supported on all local storage repositories, the user would have >>>>a standard access mechanism. >>>> >>>>Shared collection - VOSpace: >>>> >>>>The purpose of the shared collection is to organize files across >>>>multiple storage repositories, provide a way to register files >>>>into the shared collection, establish access controls on the >>>>shared data, provide standard services for manipulating the files >>>>(Cone Search, SIAP, SSAP, Mosaic, ...), support replication, >>>>support selection of the closest file. >>>> >>>>The shared collection provides a global (or logical) name space >>>>that can be organized in a directory structure independently of >>>>the naming convention and path hierarchy employed at the local >>>>storage systems. Thus the VOSpace system must manage the mapping >>>>from the logical name space to the naming convention used in the >>>>local storage system. >>>> >>>>An account ID is established under which the shared collection >>>>(VOSpace) is able to deposit files in the local storage >>>>repository. This means the shared collection owns the data that >>>>is stored at the local storage repository. In order to access >>>>the data, a user would need to authenticate herself to the shared >>>>collection, which in turn authenticates itself to the local >>>>storage repository. Whether or not to allow the access is >>>>controlled by ACLs managed by VOSpace. This means that the >>>>authentication mechanism used by VOSpace is completely >>>>independent of the authentication mechanisms used by the local >>>>storage systems. >>>> >>>>In order to handle the fact that local storage systems use a >>>>variety of authentication mechanisms (Unix password, PKI >>>>certificates, Kerberos certificates, DCE credentials, ...) the >>>>VOSpace implementation could use the Generic Security Service API >>>>(GSSAPI) to handle the heterogeneity. In addition, an arbitrary >>>>authentication mechanism can be chosen for authenticating users >>>>to VOSpace. >>>> >>>>If a VOStore interface is provided by the local storage >>>>repository, then VOSpace would be able to invoke the VOStore >>>>access mechanism (running under the VOSpace account ID). Note >>>>that in this model VOStore does no authentication. All >>>>authentication is controlled by a combination of the local >>>>storage system and VOSpace. >>>> >>>>The type of operations that would be required by VOStore, >>>>however, are more sophisticated. They include: >>>>- get file >>>>- put file >>>>- list files >>>>- register an existing file into VOSpace, while mapping from the >>>>local name to the VOSpace preferred name >>>>- register an existing directory structure into VOSpace, while >>>>setting the VOSpace logical names and VOSpace directory structure >>>>to be the same as the local directory structure >>>>- register an existing local file into VOSpace as a replica of an >>>>existing VOSpace logical file. >>>> >>>>With the latter three commands, it is possible to meet the >>>>specific requirement that users be able to control the names of >>>>files both on the local system and in VOSpace. Note that for the >>>>user to access the local file system they required an account ID >>>>on the local file system. They then stored a local file under >>>>their own account ID. They would add read permission for the >>>>VOSpace account ID to their local file to permit access by >>>>VOSpace. >>>> >>>>This separates authorization cleanly between the local storage >>>>system (which only checks for access by local account IDs) and >>>>the VOSpace shared collection (which authorizes all accesses to >>>>files owned by VOSpace). This means that VOSpace is managing >>>>multiple levels of indirection: >>>>- mapping from the global or logical file name space to the local >>>>repository name space >>>>- mapping from an authenticated user through application of ACLs >>>>to decide whether the user can read a VOSpace owned file. >>>>- mapping preferred location for accessing replicas (typically >>>>pick a file on the file system with the user's IP address, then >>>>any other file system, then a tape archive) >>>> >>>>For completeness, VOStore may need an operation that sets access >>>>permission for VOSpace, when VOStore is run under the local user >>>>account ID. >>>> >>>> >>>>Reagan Moore >>>> >>>>> >>>>>I think that most of what is VOStore and what is VOSpace is >>>>>clear; however, the two grey areas are access control >>>>>(authorization) and identifiers and this stems from the use case >>>>>where the user wants direct access to a VOStore (e.g. a local >>>>>store) and does not want to go through the VOSpace layer. Here >>>>>are my suggestions for handling these areas: >>>>> >>>>>Access control: >>>>>------------------- >>>>> >>>>>A VOStore can run in two modes: authorized and unauthorized. An >>>>>unauthorized VOStore is semantically equivalent to an anonymous >>>>>ftp site: any authenticated user (we still maintain security) >>>>>can put something in, move/rename it, get it and delete it. >>>>>An authorized VOStore will only allow the requested operation if >>>>>a valid authentication token is included in the request - all >>>>>the VOStore has to do here is validate the authentication token. >>>>>The generation of the authentication token is handled by >>>>>VOSpace: it makes sure that the authenticated user has >>>>>permission to do what they are requesting and if so, places a >>>>>valid token in the request down to the VOStore. >>>>> >>>>>Identifiers: >>>>>-------------- >>>>> >>>>>The protocol identifier ivo:// identifies a resource that exists >>>>>in the VO. It does not promise that you can completely resolve a >>>>>URI beginning ivo:// in a registry, merely that some component >>>>>of the URI will relate to a resource that has a registry entry, >>>>>i.e. the bit before the first # can be resolved in a registry. >>>>>So I can go to a registry and find out where >>>>>ivo://nvo.caltech/vostores/vostore1 is >>>>>but I need to go to VOStore interface for this store to resolve >>>>>ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why >>>>>we need to introduce a second protocol just for VOStore contents. >>>>> >>>>>Now resolution of individual VOStore identifiers has to be done >>>>>at the VOStore level; however, VOSpace gives you the ability to >>>>>set up a single logical identifier for multiple copies of the >>>>>same resource so here we might want a separate protocol: vos and >>>>>resolution of this identifier has to be done at the VOSpace >>>>>level since VOSpace manages multiple VOStores. >>>>> >>>>> Cheers, >>>>> >>>>> Matthew >>>>> >>>>> >>>>>Paul Harrison wrote: >>>>> >>>>>>Reagan Moore wrote: >>>>>> >>>>>>>The differentiation between the VOStore and VOSpace interfaces >>>>>>>is becoming unclear. The latest draft implies that properties >>>>>>>that were originally associated with VOSpace would now be >>>>>>>supported by VOStore. >>>>>>> >>>>>> >>>>>>I have to say that I agree that there seems to be some >>>>>>confusion in this area - with hindsight it was probably a >>>>>>mistake to defer the specification of VOSpace and work on >>>>>>VOStore alone as the "easier" problem - the specifications >>>>>>should be worked in tandem to see where it is most appropriate >>>>>>to place roles and responsibilities for particular use cases, >>>>>>so that a "global" solution is arrived at. >>>>>> >>>>>>I thought that the original separation into VOStore and VOSpace >>>>>>was done so that VOStore could be an essentially "dumb" BLOB >>>>>>repository that did what it was told by the VOStore layer when >>>>>>it comes to issues of file permissions and hierarchical file >>>>>>names. However, because no VOSpace specification was created, >>>>>>these more advanced features have crept into the VOStore layer. >>>>>> >>>>>>> >>>>>>>Let's look at the current VOStore and VOSpace proposal: >>>>>>> >>>>>>>VOStore VOSpace >>>>>>>Storage of objects management of >>>>>>>virtual file system >>>>>>>data stored under unspecified ID? >>>>>>>no user home directory User home directory >>>>>>>directory hierarchy Directory hierarchy >>>>>>>Unique file name within storage User-defined file names >>>>>>> Mapping VOSpace >>>>>>>name to VOStore name >>>>>>> List files for user >>>>>>>Restrict access by user identity? >>>>>>>Identify files with URIs >>>>>>>Access controls on local file name Access controls on >>>>>>>VOSPace name >>>>>>> >>>>>>>This characterization mixes name space, mixes access controls, >>>>>>>does not provide consistent identity, does not allow >>>>>>>consistent management. For instance, if a URI is being >>>>>>>provided for file identity within the VOStore interface, then >>>>>>>there is no need for user-specified names within VOSTore. A >>>>>>>second issue is the assumption that file access can be >>>>>>>restricted by user identity. This means that the VOStore must >>>>>>>manage the owner for each file, access controls for each file. >>>>>>>File systems usually do this by creating accounts for each >>>>>>>user name and applying Unix permissions. Is this capability >>>>>>>to be provided now by both VOSpace and VOStore? We need a >>>>>>>cleaner separation of capabilities. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>This security aspect is crucial - it is clear that the owners >>>>>>of VOStores would not want to be managing user identity lists >>>>>>of all the VObs users at their stores - the fine grained access >>>>>>controls should be at the VOSpace level. If VOStores only >>>>>>respond to requests from trusted VOSpace services then this is >>>>>>possible, but I think that the perceived requirement for more >>>>>>detailed access control in the VOSpace layer has come about >>>>>>because prototype end-user applications have appeared that talk >>>>>>directly to the VOStore layer - of course, it is not surprising >>>>>>that this has happened because there was no VOSpace definition >>>>>>for the end user applications to talk to. >>>>>> >>>>>>How file/BLOB identity is managed is also crucial to producing >>>>>>a system that offers more than ftp. I thought that one of the >>>>>>fundamental driving use cases for a VOSpace was that the same >>>>>>BLOB could potentially live on serveral VOStores, and that when >>>>>>specifying a resource in VOSpace, in a workflow for instance, >>>>>>the resource could be retrieved from the VOStore that was >>>>>>"closest" on the network to where the resource would be >>>>>>consumed. This sort of use case does require some careful >>>>>>thought about the allocation and management of identifiers, and >>>>>>I think probably means that the VOStore will have to be aware >>>>>>of the VOSpace identifier. >>>>>> >>>>>>I also have an issue with reusing ivo: as the protocol part for >>>>>>the URI of an identifier in this system - ivo: is already well >>>>>>defined and used as the identifer for registry entries, and the >>>>>>"protocol" for accessing the entity associated with the >>>>>>identifier is defined in the registry interface standard. This >>>>>>means that given an identifier of the form >>>>>>ivo://authority.org/something#blah a software agent (or human >>>>>>for that matter) cannot tell by inspection whether the >>>>>>identifier refers to a file in VOSpace or is simply a reference >>>>>>to a registry entry (e.g. for a SkyNode) - this leads to >>>>>>software having to be more complex in order constantly to test >>>>>>for the different possibilities. I think that it would be >>>>>>better to have a URI with a different protocol part, vos: for >>>>>>instance, it would then be immediately apparent that the >>>>>>VOSpace protocol should be used to access the entity referred >>>>>>to by the identifier. >>>>>> >>>>>>> >>>>>>>Let's look at the Storage Resource Broker data grid separation >>>>>>>of local storage management from the virtual file system >>>>>>>management: >>>>>>> >>>>>>>Local storage system SRB name space >>>>>>>Storage of objects management of >>>>>>>virtual file system >>>>>>>data stored under SRB ID >>>>>>>no user home directory User home directory >>>>>>>directory indirection structure Directory hierarchy >>>>>>>Unique file name within storage User-defined file names >>>>>>> Mapping SRB name >>>>>>>to local file name >>>>>>> List files for user >>>>>>>Access through SRB ID, controlled by SRB >>>>>>> Identify files by URIs >>>>>>> Access controls on SRB name >>>>>>> >>>>>> >>>>>>I think that as Regan points out the separation of >>>>>>responsibilities that SRB has with the local storage system is >>>>>>pretty much the right model for VOSpace and VOStore - though >>>>>>it means that SRB is pretty much at VOSpace level rather than a >>>>>>VOStore as is suggested in the current VOSpace definition >>>>>>document. >>>>> >>>>> >>>> >>>Hi, >>> >>>If you also allow the possibility that the local storage >>>repository can run in an unauthorized (anonymous access) manner >>>then this is exactly what Guy and I were suggesting. Does that >>>mean that we actually all agree on this :-) >>> >>> Cheers, >>> >>> Matthew From owner-vospace@eso.org Sat Aug 6 02:34:40 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j760YWuM003718 for ; Sat, 6 Aug 2005 02:34:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j760YVG7003717 for vospace-outgoing; Sat, 6 Aug 2005 02:34:31 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j760YRuM003712 for ; Sat, 6 Aug 2005 02:34:28 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j760YOhx020622 for ; Sat, 6 Aug 2005 02:34:25 +0200 (CEST) Received: from [192.168.10.30] (vastfire.cacr.caltech.edu [131.215.145.253]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id j760YHgh016391 for ; Fri, 5 Aug 2005 17:34:18 -0700 Message-ID: <42F40583.5030900@cacr.caltech.edu> Date: Fri, 05 Aug 2005 17:34:11 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore interface References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.5.28 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Hi, I would argue that this is an implementation issue: you have to make sure that VOStore can fulfil what it promises. The required functionality for authentication is just that the VOStore can recognise a valid message, e.g. the certificate used to sign the SOAP message has the NVO CA in its certificate chain. Cheers, Matthew Reagan Moore wrote: > Matthew: > This is where we differ in the specification. > > Which account does VOStore run under on the local storage system? > > Reagan > >> Hi, >> >> If the user is accessing the local storage system directly then they >> can do whatever they want. VOStore, however, is the presentation of >> that repository to the VO world and does not necessarily interface >> with a VOSpace layer: this means that the VOStore interface has to be >> capable of handling the VO authentication mechanism. The >> authorization story is as we seemed to have agreed. >> >> Cheers, >> >> Matthew >> >> >> Reagan Moore wrote: >> >>> Matthew: >>> >>> The expectation is that the VOStore interface does not need to do >>> either authentication or authorization. If a person is working >>> directly with a local storage system, then they are accessing their >>> own personal data while running under their personal account ID. >>> They can execute the VOStore interface as a local application. >>> >>> If VOSpace is accessing the local storage system through VOStore, >>> then VOSpace authenticates its access to the local storage system to >>> read or write files under the VOSpace account ID. Again VOStore is >>> just a local application that VOSpace executes. >>> >>> If the owner of data on the local storage repository chooses to make >>> a file world readable, then VOSpace would be able to access the file >>> through VOStore. >>> >>> Reagan >>> >>> >>>> Reagan Moore wrote: >>>> >>>>> I would like to propose the following separation of identity and >>>>> access control management. The issues appear to be how to >>>>> separate support for local files in a local storage repository >>>>> from the files that are registered into a shared collection that >>>>> spans multiple storage repositories. An easy way to make the >>>>> differentiation is to identify the usage model for each type of >>>>> data management system. I would like to learn whether this >>>>> approach would meet all of the IVOA requirements. >>>>> >>>>> Local storage repository: >>>>> >>>>> This is a storage system that is controlled by local >>>>> administrators who establish access accounts for the persons who >>>>> are allowed to use the system. >>>>> The users can choose their own file names, manipulate the files >>>>> with the utilities that are available on the local storage, and >>>>> are authenticated by the local system. If desired, a user could >>>>> log onto the local storage repository, and use a VO specific >>>>> interface such as VOStore to access their own personal data. Since >>>>> VOStore would be run under their account ID to access files that >>>>> they own, there is no additional required authentication. They >>>>> could also use other access mechanisms such as perl scripts, or >>>>> Unix shell commands, C library calls, whatever is supported on the >>>>> local storage repository. These access mechanisms allow them to >>>>> access files that they own. >>>>> >>>>> A VOStore interface for this usage model would provide: >>>>> - get file >>>>> - put file >>>>> - list files >>>>> The only advantage is that if the VOStore interface were supported >>>>> on all local storage repositories, the user would have a standard >>>>> access mechanism. >>>>> >>>>> Shared collection - VOSpace: >>>>> >>>>> The purpose of the shared collection is to organize files across >>>>> multiple storage repositories, provide a way to register files >>>>> into the shared collection, establish access controls on the >>>>> shared data, provide standard services for manipulating the files >>>>> (Cone Search, SIAP, SSAP, Mosaic, ...), support replication, >>>>> support selection of the closest file. >>>>> >>>>> The shared collection provides a global (or logical) name space >>>>> that can be organized in a directory structure independently of >>>>> the naming convention and path hierarchy employed at the local >>>>> storage systems. Thus the VOSpace system must manage the mapping >>>>> from the logical name space to the naming convention used in the >>>>> local storage system. >>>>> >>>>> An account ID is established under which the shared collection >>>>> (VOSpace) is able to deposit files in the local storage >>>>> repository. This means the shared collection owns the data that is >>>>> stored at the local storage repository. In order to access the >>>>> data, a user would need to authenticate herself to the shared >>>>> collection, which in turn authenticates itself to the local >>>>> storage repository. Whether or not to allow the access is >>>>> controlled by ACLs managed by VOSpace. This means that the >>>>> authentication mechanism used by VOSpace is completely independent >>>>> of the authentication mechanisms used by the local storage systems. >>>>> >>>>> In order to handle the fact that local storage systems use a >>>>> variety of authentication mechanisms (Unix password, PKI >>>>> certificates, Kerberos certificates, DCE credentials, ...) the >>>>> VOSpace implementation could use the Generic Security Service API >>>>> (GSSAPI) to handle the heterogeneity. In addition, an arbitrary >>>>> authentication mechanism can be chosen for authenticating users to >>>>> VOSpace. >>>>> >>>>> If a VOStore interface is provided by the local storage >>>>> repository, then VOSpace would be able to invoke the VOStore >>>>> access mechanism (running under the VOSpace account ID). Note >>>>> that in this model VOStore does no authentication. All >>>>> authentication is controlled by a combination of the local storage >>>>> system and VOSpace. >>>>> >>>>> The type of operations that would be required by VOStore, however, >>>>> are more sophisticated. They include: >>>>> - get file >>>>> - put file >>>>> - list files >>>>> - register an existing file into VOSpace, while mapping from the >>>>> local name to the VOSpace preferred name >>>>> - register an existing directory structure into VOSpace, while >>>>> setting the VOSpace logical names and VOSpace directory structure >>>>> to be the same as the local directory structure >>>>> - register an existing local file into VOSpace as a replica of an >>>>> existing VOSpace logical file. >>>>> >>>>> With the latter three commands, it is possible to meet the >>>>> specific requirement that users be able to control the names of >>>>> files both on the local system and in VOSpace. Note that for the >>>>> user to access the local file system they required an account ID >>>>> on the local file system. They then stored a local file under >>>>> their own account ID. They would add read permission for the >>>>> VOSpace account ID to their local file to permit access by VOSpace. >>>>> >>>>> This separates authorization cleanly between the local storage >>>>> system (which only checks for access by local account IDs) and the >>>>> VOSpace shared collection (which authorizes all accesses to files >>>>> owned by VOSpace). This means that VOSpace is managing multiple >>>>> levels of indirection: >>>>> - mapping from the global or logical file name space to the local >>>>> repository name space >>>>> - mapping from an authenticated user through application of ACLs >>>>> to decide whether the user can read a VOSpace owned file. >>>>> - mapping preferred location for accessing replicas (typically >>>>> pick a file on the file system with the user's IP address, then >>>>> any other file system, then a tape archive) >>>>> >>>>> For completeness, VOStore may need an operation that sets access >>>>> permission for VOSpace, when VOStore is run under the local user >>>>> account ID. >>>>> >>>>> >>>>> Reagan Moore >>>>> >>>>>> >>>>>> I think that most of what is VOStore and what is VOSpace is >>>>>> clear; however, the two grey areas are access control >>>>>> (authorization) and identifiers and this stems from the use case >>>>>> where the user wants direct access to a VOStore (e.g. a local >>>>>> store) and does not want to go through the VOSpace layer. Here >>>>>> are my suggestions for handling these areas: >>>>>> >>>>>> Access control: >>>>>> ------------------- >>>>>> >>>>>> A VOStore can run in two modes: authorized and unauthorized. An >>>>>> unauthorized VOStore is semantically equivalent to an anonymous >>>>>> ftp site: any authenticated user (we still maintain security) can >>>>>> put something in, move/rename it, get it and delete it. >>>>>> An authorized VOStore will only allow the requested operation if >>>>>> a valid authentication token is included in the request - all the >>>>>> VOStore has to do here is validate the authentication token. The >>>>>> generation of the authentication token is handled by VOSpace: it >>>>>> makes sure that the authenticated user has permission to do what >>>>>> they are requesting and if so, places a valid token in the >>>>>> request down to the VOStore. >>>>>> >>>>>> Identifiers: >>>>>> -------------- >>>>>> >>>>>> The protocol identifier ivo:// identifies a resource that exists >>>>>> in the VO. It does not promise that you can completely resolve a >>>>>> URI beginning ivo:// in a registry, merely that some component of >>>>>> the URI will relate to a resource that has a registry entry, i.e. >>>>>> the bit before the first # can be resolved in a registry. So I >>>>>> can go to a registry and find out where >>>>>> ivo://nvo.caltech/vostores/vostore1 is >>>>>> but I need to go to VOStore interface for this store to resolve >>>>>> ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we >>>>>> need to introduce a second protocol just for VOStore contents. >>>>>> >>>>>> Now resolution of individual VOStore identifiers has to be done >>>>>> at the VOStore level; however, VOSpace gives you the ability to >>>>>> set up a single logical identifier for multiple copies of the >>>>>> same resource so here we might want a separate protocol: vos and >>>>>> resolution of this identifier has to be done at the VOSpace level >>>>>> since VOSpace manages multiple VOStores. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Matthew >>>>>> >>>>>> >>>>>> Paul Harrison wrote: >>>>>> >>>>>>> Reagan Moore wrote: >>>>>>> >>>>>>>> The differentiation between the VOStore and VOSpace interfaces >>>>>>>> is becoming unclear. The latest draft implies that properties >>>>>>>> that were originally associated with VOSpace would now be >>>>>>>> supported by VOStore. >>>>>>>> >>>>>>> >>>>>>> I have to say that I agree that there seems to be some confusion >>>>>>> in this area - with hindsight it was probably a mistake to defer >>>>>>> the specification of VOSpace and work on VOStore alone as the >>>>>>> "easier" problem - the specifications should be worked in tandem >>>>>>> to see where it is most appropriate to place roles and >>>>>>> responsibilities for particular use cases, so that a "global" >>>>>>> solution is arrived at. >>>>>>> >>>>>>> I thought that the original separation into VOStore and VOSpace >>>>>>> was done so that VOStore could be an essentially "dumb" BLOB >>>>>>> repository that did what it was told by the VOStore layer when >>>>>>> it comes to issues of file permissions and hierarchical file >>>>>>> names. However, because no VOSpace specification was created, >>>>>>> these more advanced features have crept into the VOStore layer. >>>>>>> >>>>>>>> >>>>>>>> Let's look at the current VOStore and VOSpace proposal: >>>>>>>> >>>>>>>> VOStore VOSpace >>>>>>>> Storage of objects management of >>>>>>>> virtual file system >>>>>>>> data stored under unspecified ID? >>>>>>>> no user home directory User home directory >>>>>>>> directory hierarchy Directory hierarchy >>>>>>>> Unique file name within storage User-defined file >>>>>>>> names >>>>>>>> Mapping VOSpace >>>>>>>> name to VOStore name >>>>>>>> List files for user >>>>>>>> Restrict access by user identity? >>>>>>>> Identify files with URIs >>>>>>>> Access controls on local file name Access controls on >>>>>>>> VOSPace name >>>>>>>> >>>>>>>> This characterization mixes name space, mixes access controls, >>>>>>>> does not provide consistent identity, does not allow consistent >>>>>>>> management. For instance, if a URI is being provided for file >>>>>>>> identity within the VOStore interface, then there is no need >>>>>>>> for user-specified names within VOSTore. A second issue is the >>>>>>>> assumption that file access can be restricted by user identity. >>>>>>>> This means that the VOStore must manage the owner for each >>>>>>>> file, access controls for each file. File systems usually do >>>>>>>> this by creating accounts for each user name and applying Unix >>>>>>>> permissions. Is this capability to be provided now by both >>>>>>>> VOSpace and VOStore? We need a cleaner separation of >>>>>>>> capabilities. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This security aspect is crucial - it is clear that the owners of >>>>>>> VOStores would not want to be managing user identity lists of >>>>>>> all the VObs users at their stores - the fine grained access >>>>>>> controls should be at the VOSpace level. If VOStores only >>>>>>> respond to requests from trusted VOSpace services then this is >>>>>>> possible, but I think that the perceived requirement for more >>>>>>> detailed access control in the VOSpace layer has come about >>>>>>> because prototype end-user applications have appeared that talk >>>>>>> directly to the VOStore layer - of course, it is not surprising >>>>>>> that this has happened because there was no VOSpace definition >>>>>>> for the end user applications to talk to. >>>>>>> >>>>>>> How file/BLOB identity is managed is also crucial to producing a >>>>>>> system that offers more than ftp. I thought that one of the >>>>>>> fundamental driving use cases for a VOSpace was that the same >>>>>>> BLOB could potentially live on serveral VOStores, and that when >>>>>>> specifying a resource in VOSpace, in a workflow for instance, >>>>>>> the resource could be retrieved from the VOStore that was >>>>>>> "closest" on the network to where the resource would be >>>>>>> consumed. This sort of use case does require some careful >>>>>>> thought about the allocation and management of identifiers, and >>>>>>> I think probably means that the VOStore will have to be aware of >>>>>>> the VOSpace identifier. >>>>>>> >>>>>>> I also have an issue with reusing ivo: as the protocol part for >>>>>>> the URI of an identifier in this system - ivo: is already well >>>>>>> defined and used as the identifer for registry entries, and the >>>>>>> "protocol" for accessing the entity associated with the >>>>>>> identifier is defined in the registry interface standard. This >>>>>>> means that given an identifier of the form >>>>>>> ivo://authority.org/something#blah a software agent (or human >>>>>>> for that matter) cannot tell by inspection whether the >>>>>>> identifier refers to a file in VOSpace or is simply a reference >>>>>>> to a registry entry (e.g. for a SkyNode) - this leads to >>>>>>> software having to be more complex in order constantly to test >>>>>>> for the different possibilities. I think that it would be better >>>>>>> to have a URI with a different protocol part, vos: for instance, >>>>>>> it would then be immediately apparent that the VOSpace protocol >>>>>>> should be used to access the entity referred to by the identifier. >>>>>>> >>>>>>>> >>>>>>>> Let's look at the Storage Resource Broker data grid separation >>>>>>>> of local storage management from the virtual file system >>>>>>>> management: >>>>>>>> >>>>>>>> Local storage system SRB name space >>>>>>>> Storage of objects management of >>>>>>>> virtual file system >>>>>>>> data stored under SRB ID >>>>>>>> no user home directory User home directory >>>>>>>> directory indirection structure Directory hierarchy >>>>>>>> Unique file name within storage User-defined file >>>>>>>> names >>>>>>>> Mapping SRB name to >>>>>>>> local file name >>>>>>>> List files for user >>>>>>>> Access through SRB ID, controlled by SRB >>>>>>>> Identify files by URIs >>>>>>>> Access controls on >>>>>>>> SRB name >>>>>>>> >>>>>>> >>>>>>> I think that as Regan points out the separation of >>>>>>> responsibilities that SRB has with the local storage system is >>>>>>> pretty much the right model for VOSpace and VOStore - though it >>>>>>> means that SRB is pretty much at VOSpace level rather than a >>>>>>> VOStore as is suggested in the current VOSpace definition document. >>>>>> >>>>>> >>>>>> >>>>> >>>> Hi, >>>> >>>> If you also allow the possibility that the local storage repository >>>> can run in an unauthorized (anonymous access) manner then this is >>>> exactly what Guy and I were suggesting. Does that mean that we >>>> actually all agree on this :-) >>>> >>>> Cheers, >>>> >>>> Matthew >>> > From owner-vospace@eso.org Mon Aug 8 21:18:24 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j78JIDl4009498 for ; Mon, 8 Aug 2005 21:18:14 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j78JIDVU009497 for vospace-outgoing; Mon, 8 Aug 2005 21:18:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j78JI9l4009492 for ; Mon, 8 Aug 2005 21:18:10 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j78JI6in008197 for ; Mon, 8 Aug 2005 21:18:07 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j78JHxU15383; Mon, 8 Aug 2005 12:17:59 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42F40583.5030900@cacr.caltech.edu> References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> <42F40583.5030900@cacr.caltech.edu> Date: Mon, 8 Aug 2005 12:15:45 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Re: VOStore interface Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.8.22 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Matthew: The account does make a difference when VOStore attempts to access the requested data. If VOStore gets an authenticated request for local data that belongs to another user ID, how does VOStore gain access to the data? The challenge is that VOStore is being used to access both local data owned by an individual, as well as data that is being published into VOSpace. Access to data in VOSpace can be achieved by having VOStore run under the VOSpace account ID. Access to data owned by an individual requires either that VOStore run under the individual's account, or that permission be given by the individual for access by the accoun that VOStore is run under. One way out is to assume VOSTore is run under the account that corresponds to VOSpace. Then VOSpace can manage the authorization independently of VOStore. Reagan >Hi, > >I would argue that this is an implementation issue: you have to make >sure that VOStore can fulfil what it promises. > >The required functionality for authentication is just that the >VOStore can recognise a valid message, e.g. the certificate used to >sign the SOAP message has the NVO CA in its certificate chain. > > Cheers, > > Matthew > >Reagan Moore wrote: > >>Matthew: >>This is where we differ in the specification. >> >>Which account does VOStore run under on the local storage system? >> >>Reagan >> >>>Hi, >>> >>>If the user is accessing the local storage system directly then >>>they can do whatever they want. VOStore, however, is the >>>presentation of that repository to the VO world and does not >>>necessarily interface with a VOSpace layer: this means that the >>>VOStore interface has to be capable of handling the VO >>>authentication mechanism. The authorization story is as we seemed >>>to have agreed. >>> >>> Cheers, >>> >>> Matthew >>> >>> >>>Reagan Moore wrote: >>> >>>>Matthew: >>>> >>>>The expectation is that the VOStore interface does not need to do >>>>either authentication or authorization. If a person is working >>>>directly with a local storage system, then they are accessing >>>>their own personal data while running under their personal >>>>account ID. They can execute the VOStore interface as a local >>>>application. >>>> >>>>If VOSpace is accessing the local storage system through VOStore, >>>>then VOSpace authenticates its access to the local storage system >>>>to read or write files under the VOSpace account ID. Again >>>>VOStore is just a local application that VOSpace executes. >>>> >>>>If the owner of data on the local storage repository chooses to >>>>make a file world readable, then VOSpace would be able to access >>>>the file through VOStore. >>>> >>>>Reagan >>>> >>>>>Reagan Moore wrote: >>>>> >>>>>>I would like to propose the following separation of identity >>>>>>and access control management. The issues appear to be how to >>>>>>separate support for local files in a local storage repository >>>>>>from the files that are registered into a shared collection >>>>>>that spans multiple storage repositories. An easy way to make >>>>>>the differentiation is to identify the usage model for each >>>>>>type of data management system. I would like to learn whether >>>>>>this approach would meet all of the IVOA requirements. >>>>>> >>>>>>Local storage repository: >>>>>> >>>>>>This is a storage system that is controlled by local >>>>>>administrators who establish access accounts for the persons >>>>>>who are allowed to use the system. >>>>>>The users can choose their own file names, manipulate the files >>>>>>with the utilities that are available on the local storage, and >>>>>>are authenticated by the local system. If desired, a user >>>>>>could log onto the local storage repository, and use a VO >>>>>>specific interface such as VOStore to access their own personal >>>>>>data. Since VOStore would be run under their account ID to >>>>>>access files that they own, there is no additional required >>>>>>authentication. They could also use other access mechanisms >>>>>>such as perl scripts, or Unix shell commands, C library calls, >>>>>>whatever is supported on the local storage repository. These >>>>>>access mechanisms allow them to access files that they own. >>>>>> >>>>>>A VOStore interface for this usage model would provide: >>>>>>- get file >>>>>>- put file >>>>>>- list files >>>>>>The only advantage is that if the VOStore interface were >>>>>>supported on all local storage repositories, the user would >>>>>>have a standard access mechanism. >>>>>> >>>>>>Shared collection - VOSpace: >>>>>> >>>>>>The purpose of the shared collection is to organize files >>>>>>across multiple storage repositories, provide a way to register >>>>>>files into the shared collection, establish access controls on >>>>>>the shared data, provide standard services for manipulating the >>>>>>files (Cone Search, SIAP, SSAP, Mosaic, ...), support >>>>>>replication, support selection of the closest file. >>>>>> >>>>>>The shared collection provides a global (or logical) name space >>>>>>that can be organized in a directory structure independently of >>>>>>the naming convention and path hierarchy employed at the local >>>>>>storage systems. Thus the VOSpace system must manage the >>>>>>mapping from the logical name space to the naming convention >>>>>>used in the local storage system. >>>>>> >>>>>>An account ID is established under which the shared collection >>>>>>(VOSpace) is able to deposit files in the local storage >>>>>>repository. This means the shared collection owns the data that >>>>>>is stored at the local storage repository. In order to access >>>>>>the data, a user would need to authenticate herself to the >>>>>>shared collection, which in turn authenticates itself to the >>>>>>local storage repository. Whether or not to allow the access is >>>>>>controlled by ACLs managed by VOSpace. This means that the >>>>>>authentication mechanism used by VOSpace is completely >>>>>>independent of the authentication mechanisms used by the local >>>>>>storage systems. >>>>>> >>>>>>In order to handle the fact that local storage systems use a >>>>>>variety of authentication mechanisms (Unix password, PKI >>>>>>certificates, Kerberos certificates, DCE credentials, ...) the >>>>>>VOSpace implementation could use the Generic Security Service >>>>>>API (GSSAPI) to handle the heterogeneity. In addition, an >>>>>>arbitrary authentication mechanism can be chosen for >>>>>>authenticating users to VOSpace. >>>>>> >>>>>>If a VOStore interface is provided by the local storage >>>>>>repository, then VOSpace would be able to invoke the VOStore >>>>>>access mechanism (running under the VOSpace account ID). Note >>>>>>that in this model VOStore does no authentication. All >>>>>>authentication is controlled by a combination of the local >>>>>>storage system and VOSpace. >>>>>> >>>>>>The type of operations that would be required by VOStore, >>>>>>however, are more sophisticated. They include: >>>>>>- get file >>>>>>- put file >>>>>>- list files >>>>>>- register an existing file into VOSpace, while mapping from >>>>>>the local name to the VOSpace preferred name >>>>>>- register an existing directory structure into VOSpace, while >>>>>>setting the VOSpace logical names and VOSpace directory >>>>>>structure to be the same as the local directory structure >>>>>>- register an existing local file into VOSpace as a replica of >>>>>>an existing VOSpace logical file. >>>>>> >>>>>>With the latter three commands, it is possible to meet the >>>>>>specific requirement that users be able to control the names of >>>>>>files both on the local system and in VOSpace. Note that for >>>>>>the user to access the local file system they required an >>>>>>account ID on the local file system. They then stored a local >>>>>>file under their own account ID. They would add read permission >>>>>>for the VOSpace account ID to their local file to permit access >>>>>>by VOSpace. >>>>>> >>>>>>This separates authorization cleanly between the local storage >>>>>>system (which only checks for access by local account IDs) and >>>>>>the VOSpace shared collection (which authorizes all accesses to >>>>>>files owned by VOSpace). This means that VOSpace is managing >>>>>>multiple levels of indirection: >>>>>>- mapping from the global or logical file name space to the >>>>>>local repository name space >>>>>>- mapping from an authenticated user through application of >>>>>>ACLs to decide whether the user can read a VOSpace owned file. >>>>>>- mapping preferred location for accessing replicas (typically >>>>>>pick a file on the file system with the user's IP address, then >>>>>>any other file system, then a tape archive) >>>>>> >>>>>>For completeness, VOStore may need an operation that sets >>>>>>access permission for VOSpace, when VOStore is run under the >>>>>>local user account ID. >>>>>> >>>>>> >>>>>>Reagan Moore >>>>>> >>>>>>> >>>>>>>I think that most of what is VOStore and what is VOSpace is >>>>>>>clear; however, the two grey areas are access control >>>>>>>(authorization) and identifiers and this stems from the use >>>>>>>case where the user wants direct access to a VOStore (e.g. a >>>>>>>local store) and does not want to go through the VOSpace >>>>>>>layer. Here are my suggestions for handling these areas: >>>>>>> >>>>>>>Access control: >>>>>>>------------------- >>>>>>> >>>>>>>A VOStore can run in two modes: authorized and unauthorized. >>>>>>>An unauthorized VOStore is semantically equivalent to an >>>>>>>anonymous ftp site: any authenticated user (we still maintain >>>>>>>security) can put something in, move/rename it, get it and >>>>>>>delete it. >>>>>>>An authorized VOStore will only allow the requested operation >>>>>>>if a valid authentication token is included in the request - >>>>>>>all the VOStore has to do here is validate the authentication >>>>>>>token. The generation of the authentication token is handled >>>>>>>by VOSpace: it makes sure that the authenticated user has >>>>>>>permission to do what they are requesting and if so, places a >>>>>>>valid token in the request down to the VOStore. >>>>>>> >>>>>>>Identifiers: >>>>>>>-------------- >>>>>>> >>>>>>>The protocol identifier ivo:// identifies a resource that >>>>>>>exists in the VO. It does not promise that you can completely >>>>>>>resolve a URI beginning ivo:// in a registry, merely that some >>>>>>>component of the URI will relate to a resource that has a >>>>>>>registry entry, i.e. the bit before the first # can be >>>>>>>resolved in a registry. So I can go to a registry and find out >>>>>>>where ivo://nvo.caltech/vostores/vostore1 is >>>>>>>but I need to go to VOStore interface for this store to >>>>>>>resolve ivo://nvo.caltech/vostores/vostore1#halibut3. I do not >>>>>>>see why we need to introduce a second protocol just for >>>>>>>VOStore contents. >>>>>>> >>>>>>>Now resolution of individual VOStore identifiers has to be >>>>>>>done at the VOStore level; however, VOSpace gives you the >>>>>>>ability to set up a single logical identifier for multiple >>>>>>>copies of the same resource so here we might want a separate >>>>>>>protocol: vos and resolution of this identifier has to be done >>>>>>>at the VOSpace level since VOSpace manages multiple VOStores. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matthew >>>>>>> >>>>>>> >>>>>>>Paul Harrison wrote: >>>>>>> >>>>>>>>Reagan Moore wrote: >>>>>>>> >>>>>>>>>The differentiation between the VOStore and VOSpace >>>>>>>>>interfaces is becoming unclear. The latest draft implies >>>>>>>>>that properties that were originally associated with VOSpace >>>>>>>>>would now be supported by VOStore. >>>>>>>>> >>>>>>>> >>>>>>>>I have to say that I agree that there seems to be some >>>>>>>>confusion in this area - with hindsight it was probably a >>>>>>>>mistake to defer the specification of VOSpace and work on >>>>>>>>VOStore alone as the "easier" problem - the specifications >>>>>>>>should be worked in tandem to see where it is most >>>>>>>>appropriate to place roles and responsibilities for >>>>>>>>particular use cases, so that a "global" solution is arrived >>>>>>>>at. >>>>>>>> >>>>>>>>I thought that the original separation into VOStore and >>>>>>>>VOSpace was done so that VOStore could be an essentially >>>>>>>>"dumb" BLOB repository that did what it was told by the >>>>>>>>VOStore layer when it comes to issues of file permissions and >>>>>>>>hierarchical file names. However, because no VOSpace >>>>>>>>specification was created, these more advanced features have >>>>>>>>crept into the VOStore layer. >>>>>>>> >>>>>>>>> >>>>>>>>>Let's look at the current VOStore and VOSpace proposal: >>>>>>>>> >>>>>>>>>VOStore VOSpace >>>>>>>>>Storage of objects management of >>>>>>>>>virtual file system >>>>>>>>>data stored under unspecified ID? >>>>>>>>>no user home directory User home directory >>>>>>>>>directory hierarchy Directory hierarchy >>>>>>>>>Unique file name within storage User-defined file names >>>>>>>>> Mapping VOSpace >>>>>>>>>name to VOStore name >>>>>>>>> List files for user >>>>>>>>>Restrict access by user identity? >>>>>>>>>Identify files with URIs >>>>>>>>>Access controls on local file name Access controls >>>>>>>>>on VOSPace name >>>>>>>>> >>>>>>>>>This characterization mixes name space, mixes access >>>>>>>>>controls, does not provide consistent identity, does not >>>>>>>>>allow consistent management. For instance, if a URI is >>>>>>>>>being provided for file identity within the VOStore >>>>>>>>>interface, then there is no need for user-specified names >>>>>>>>>within VOSTore. A second issue is the assumption that file >>>>>>>>>access can be restricted by user identity. This means that >>>>>>>>>the VOStore must manage the owner for each file, access >>>>>>>>>controls for each file. File systems usually do this by >>>>>>>>>creating accounts for each user name and applying Unix >>>>>>>>>permissions. Is this capability to be provided now by both >>>>>>>>>VOSpace and VOStore? We need a cleaner separation of >>>>>>>>>capabilities. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>This security aspect is crucial - it is clear that the owners >>>>>>>>of VOStores would not want to be managing user identity lists >>>>>>>>of all the VObs users at their stores - the fine grained >>>>>>>>access controls should be at the VOSpace level. If VOStores >>>>>>>>only respond to requests from trusted VOSpace services then >>>>>>>>this is possible, but I think that the perceived requirement >>>>>>>>for more detailed access control in the VOSpace layer has >>>>>>>>come about because prototype end-user applications have >>>>>>>>appeared that talk directly to the VOStore layer - of course, >>>>>>>>it is not surprising that this has happened because there was >>>>>>>>no VOSpace definition for the end user applications to talk >>>>>>>>to. >>>>>>>> >>>>>>>>How file/BLOB identity is managed is also crucial to >>>>>>>>producing a system that offers more than ftp. I thought that >>>>>>>>one of the fundamental driving use cases for a VOSpace was >>>>>>>>that the same BLOB could potentially live on serveral >>>>>>>>VOStores, and that when specifying a resource in VOSpace, in >>>>>>>>a workflow for instance, the resource could be retrieved from >>>>>>>>the VOStore that was "closest" on the network to where the >>>>>>>>resource would be consumed. This sort of use case does >>>>>>>>require some careful thought about the allocation and >>>>>>>>management of identifiers, and I think probably means that >>>>>>>>the VOStore will have to be aware of the VOSpace identifier. >>>>>>>> >>>>>>>>I also have an issue with reusing ivo: as the protocol part >>>>>>>>for the URI of an identifier in this system - ivo: is already >>>>>>>>well defined and used as the identifer for registry entries, >>>>>>>>and the "protocol" for accessing the entity associated with >>>>>>>>the identifier is defined in the registry interface standard. >>>>>>>>This means that given an identifier of the form >>>>>>>>ivo://authority.org/something#blah a software agent (or human >>>>>>>>for that matter) cannot tell by inspection whether the >>>>>>>>identifier refers to a file in VOSpace or is simply a >>>>>>>>reference to a registry entry (e.g. for a SkyNode) - this >>>>>>>>leads to software having to be more complex in order >>>>>>>>constantly to test for the different possibilities. I think >>>>>>>>that it would be better to have a URI with a different >>>>>>>>protocol part, vos: for instance, it would then be >>>>>>>>immediately apparent that the VOSpace protocol should be used >>>>>>>>to access the entity referred to by the identifier. >>>>>>>> >>>>>>>>> >>>>>>>>>Let's look at the Storage Resource Broker data grid >>>>>>>>>separation of local storage management from the virtual file >>>>>>>>>system management: >>>>>>>>> >>>>>>>>>Local storage system SRB name space >>>>>>>>>Storage of objects management of >>>>>>>>>virtual file system >>>>>>>>>data stored under SRB ID >>>>>>>>>no user home directory User home directory >>>>>>>>>directory indirection structure Directory hierarchy >>>>>>>>>Unique file name within storage User-defined file names >>>>>>>>> Mapping SRB name >>>>>>>>>to local file name >>>>>>>>> List files for user >>>>>>>>>Access through SRB ID, controlled by SRB >>>>>>>>> Identify files by URIs >>>>>>>>> Access controls >>>>>>>>>on SRB name >>>>>>>>> >>>>>>>> >>>>>>>>I think that as Regan points out the separation of >>>>>>>>responsibilities that SRB has with the local storage system >>>>>>>>is pretty much the right model for VOSpace and VOStore - >>>>>>>>though it means that SRB is pretty much at VOSpace level >>>>>>>>rather than a VOStore as is suggested in the current VOSpace >>>>>>>>definition document. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>Hi, >>>>> >>>>>If you also allow the possibility that the local storage >>>>>repository can run in an unauthorized (anonymous access) manner >>>>>then this is exactly what Guy and I were suggesting. Does that >>>>>mean that we actually all agree on this :-) >>>>> >>>>> Cheers, >>>>> >>>>> Matthew From owner-vospace@eso.org Tue Aug 9 09:50:21 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j797oBSe018238 for ; Tue, 9 Aug 2005 09:50:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j797oB7n018237 for vospace-outgoing; Tue, 9 Aug 2005 09:50:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j797o5Se018211 for ; Tue, 9 Aug 2005 09:50:05 +0200 (MEST) Received: from [134.171.40.74] (pc010245.hq.eso.org [134.171.40.74]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id j797o5n15077 for ; Tue, 9 Aug 2005 09:50:05 +0200 (MEST) Message-ID: <42F8602D.4010207@eso.org> Date: Tue, 09 Aug 2005 09:50:05 +0200 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore interface References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> <42F40583.5030900@cacr.caltech.edu> In-Reply-To: <42F40583.5030900@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Matthew Graham wrote: > Hi, > > I would argue that this is an implementation issue: you have to make > sure that VOStore can fulfil what it promises. > > The required functionality for authentication is just that the VOStore > can recognise a valid message, e.g. the certificate used to sign the > SOAP message has the NVO CA in its certificate chain. > This simple statement does hide some potentially complex implementation issues though... - if the signing certificate is a user certificate, then is the VOStore expected to have a user database to manage the authorization issues (group access for instance)? I thought this was supposed to be delegated to the VOSpace level. - Often the caller of a VOStore will be another service, requesting access on behalf of a user - so VOStore will be dealing with the GSI certificate proxy system at the first level Paul Harrison From owner-vospace@eso.org Tue Aug 9 10:20:02 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j798JnSe022461 for ; Tue, 9 Aug 2005 10:19:49 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j798JnLK022460 for vospace-outgoing; Tue, 9 Aug 2005 10:19:49 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j798JgSe022443 for ; Tue, 9 Aug 2005 10:19:42 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j798Jehx005380 for ; Tue, 9 Aug 2005 10:19:41 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:34072) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1E2PKa-000168-2F (Exim 4.51) for vospace@ivoa.net (return-path ); Tue, 09 Aug 2005 09:19:28 +0100 Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j798JSZu016993 for ; Tue, 9 Aug 2005 09:19:28 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3) with ESMTP id j798JSou017037 for ; Tue, 9 Aug 2005 09:19:28 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j798JSU6017034 for ; Tue, 9 Aug 2005 09:19:28 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 9 Aug 2005 09:19:27 +0100 (BST) From: Guy Rixon To: vospace@ivoa.net Subject: Re: VOStore interface In-Reply-To: <42F8602D.4010207@eso.org> Message-ID: References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> <42F40583.5030900@cacr.caltech.edu> <42F8602D.4010207@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.9.0 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Paul, we agree that access to a VOStore must be controlled, yes? Therefore, we have two possible cases: 1. A store owned by a VOSpace, where the VOSpace agent is the only allowed user and call the store under its own, agent identity. This is the model that Reagan is promoting and which is used in SRB. It's also the model in AstroGrid MySpace to date. 2. A store which accepts access authenticated to more than one identity. Some of these identities could be used by user agents; some could be services with delegated identities; some could be VOSpaces. This is the model promoted by Wil (up to and at Kyoto) and, I think, by others in NVO. If you implement a store only for use from VOSpace then you naturally use the first model and do no per-user authorization. If you allow direct access to stores from DAL, then you have the second model by default and the stores _have_ to deal with file ownership. However, they don't _necessarily_ need tables of authorized users. A minimal multi-user store allows any authenticated user to write data-items and tracks ownership; it has a metadatum stating ownership for each data-item. It doesn't check CRUD permissions; it assumes that the owner has full, implicit permission on all owned items. This is a lot easier than allowing variable permissions. I think Matthew is right. The authorization is an implementation issue. The tricky part is describing the authorization policy in the registration of the stores: something we haven't looked at so far. I suggest strongly that the same authentication system be used for both single-user and multi-user stores even though the authorization is different. This allows multi-user stores to be linked into VOSpace. Cheers, Guy On Tue, 9 Aug 2005, Paul Harrison wrote: > Matthew Graham wrote: > > Hi, > > > > I would argue that this is an implementation issue: you have to make > > sure that VOStore can fulfil what it promises. > > > > The required functionality for authentication is just that the VOStore > > can recognise a valid message, e.g. the certificate used to sign the > > SOAP message has the NVO CA in its certificate chain. > > > > This simple statement does hide some potentially complex implementation > issues though... > > - if the signing certificate is a user certificate, then is the VOStore > expected to have a user database to manage the authorization issues > (group access for instance)? I thought this was supposed to be delegated > to the VOSpace level. > > - Often the caller of a VOStore will be another service, requesting > access on behalf of a user - so VOStore will be dealing with the GSI > certificate proxy system at the first level > > > Paul Harrison > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Tue Aug 9 10:48:05 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j798ltSe025824 for ; Tue, 9 Aug 2005 10:47:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j798ltD4025823 for vospace-outgoing; Tue, 9 Aug 2005 10:47:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j798loSe025816 for ; Tue, 9 Aug 2005 10:47:51 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j798lnin003402 for ; Tue, 9 Aug 2005 10:47:49 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:35704) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1E2Plu-00018A-5l (Exim 4.51) for vospace@ivoa.net (return-path ); Tue, 09 Aug 2005 09:47:42 +0100 Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j798lgZu017841 for ; Tue, 9 Aug 2005 09:47:42 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3) with ESMTP id j798lgd4017074 for ; Tue, 9 Aug 2005 09:47:42 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j798lgOc017071 for ; Tue, 9 Aug 2005 09:47:42 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 9 Aug 2005 09:47:42 +0100 (BST) From: Guy Rixon To: vospace@ivoa.net Subject: VOStore as WS-Resource Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.9.0 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 Hi, following up the discussion of ownership of data-items in VOStores, here's an alternative approach: make the store an ephemeral resource in the style established by WS-RF. Justification: most users will borrow storage supplied by resource providers and access it via VOStores. We need an interface for managing the loan of the storage (quotas, remaining length of lease etc.) WS-RF is an interface for managing leases of resources. Mechanism: "a VOStore" becomes a dynamic resource. An agent creates one on a VOStore server by calling some operation that follows the resource-factory pattern. (This method is outside the scope of the current VOStore interface.) Agents address such a dynamic store using the normal WS-RF mechanism: a SOAP header. All the data-items written to the store are owned by the creator of the store. The space used in the store can be cleared up using the WS-RF interface; if the storage is leased for a certain time, then it can be set to clear itself up. Users could create more than one dynamic store on the same VOStore server; they could create a dynamic store for each project or for each job. Advantages: we get the management interface without having to invent and debate it in IVOA. We get to implement the management interface using WS-RF toolkits if we choose (this is transparent to the clients, so the use of toolkits can vary from store to store). Users of VOStore get to manage data-items in multiple, dynamic stores without going through VOSpace. We may be able to get WS-RF management tools from the grid community. Disadvantages: the implementor of the store has to implement WS-RF or to use a WS-RF toolkit. Clients of the store have to supply the WS-RF header. NB: the WS-RF thing doesn't change the operation signatures of VOStore. We could use a client for a fixed VOStore on a dynamic VOStore by adding a handler (e.g. the Axis or JAX-RPC kind) that adds the WS-RF SOAP header. Cheers, Guy Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Tue Aug 9 14:06:46 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79C6bSe020622 for ; Tue, 9 Aug 2005 14:06:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j79C6b0n020621 for vospace-outgoing; Tue, 9 Aug 2005 14:06:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79C6WSe020606 for ; Tue, 9 Aug 2005 14:06:32 +0200 (MEST) Received: from [134.171.40.74] (pc010245.hq.eso.org [134.171.40.74]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id j79C6Wn21913 for ; Tue, 9 Aug 2005 14:06:32 +0200 (MEST) Message-ID: <42F89C48.8070709@eso.org> Date: Tue, 09 Aug 2005 14:06:32 +0200 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore interface References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> <42F40583.5030900@cacr.caltech.edu> <42F8602D.4010207@eso.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Guy Rixon wrote: > Paul, > > we agree that access to a VOStore must be controlled, yes? Therefore, we have > two possible cases: > > 1. A store owned by a VOSpace, where the VOSpace agent is the only allowed > user and call the store under its own, agent identity. This is the model > that Reagan is promoting and which is used in SRB. It's also the model in > AstroGrid MySpace to date. > > 2. A store which accepts access authenticated to more than one identity. > Some of these identities could be used by user agents; some could be > services with delegated identities; some could be VOSpaces. This is the > model promoted by Wil (up to and at Kyoto) and, I think, by others in NVO. > > If you implement a store only for use from VOSpace then you naturally use > the first model and do no per-user authorization. > > If you allow direct access to stores from DAL, then you have the second model > by default and the stores _have_ to deal with file ownership. However, they > don't _necessarily_ need tables of authorized users. No - probably an easier-to-manage implementation would be to call out to an "authorization" service - though there might be unacceptable performance problems with this. > > A minimal multi-user store allows any authenticated user to write data-items > and tracks ownership; it has a metadatum stating ownership for > each data-item. It doesn't check CRUD permissions; it assumes that the owner > has full, implicit permission on all owned items. This is a lot easier than > allowing variable permissions. OK - that is a feasible plan for a prototype, and I will do it.. > > I think Matthew is right. The authorization is an implementation issue. The > tricky part is describing the authorization policy in the registration of the > stores: something we haven't looked at so far. If it is the simple case of a choice between a) every authenticated user can do anything to any file or b) every authenticated user can do anything to any file that they own then it is not too difficult to describe - however any shades between these two would be difficult. > > I suggest strongly that the same authentication system be used for both > single-user and multi-user stores even though the authorization is different. > This allows multi-user stores to be linked into VOSpace. > I will try to implement a store that can be run in either mode, and it would be a working assumption that the authentication system is the same...;-) Paul. > Cheers, > Guy > > > On Tue, 9 Aug 2005, Paul Harrison wrote: > > >>Matthew Graham wrote: >> >>>Hi, >>> >>>I would argue that this is an implementation issue: you have to make >>>sure that VOStore can fulfil what it promises. >>> >>>The required functionality for authentication is just that the VOStore >>>can recognise a valid message, e.g. the certificate used to sign the >>>SOAP message has the NVO CA in its certificate chain. >>> >> >>This simple statement does hide some potentially complex implementation >>issues though... >> >>- if the signing certificate is a user certificate, then is the VOStore >>expected to have a user database to manage the authorization issues >>(group access for instance)? I thought this was supposed to be delegated >>to the VOSpace level. >> >>- Often the caller of a VOStore will be another service, requesting >>access on behalf of a user - so VOStore will be dealing with the GSI >>certificate proxy system at the first level >> >> >>Paul Harrison >> > > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > -- Paul Harrison ESO Garching www.eso.org From owner-vospace@eso.org Tue Aug 9 14:22:53 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79CMgSe022692 for ; Tue, 9 Aug 2005 14:22:42 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j79CMguf022691 for vospace-outgoing; Tue, 9 Aug 2005 14:22:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79CMbSe022662 for ; Tue, 9 Aug 2005 14:22:37 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79CMZhx012740 for ; Tue, 9 Aug 2005 14:22:36 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:48565) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1E2T7h-0007Lj-2f (Exim 4.51) for vospace@ivoa.net (return-path ); Tue, 09 Aug 2005 13:22:25 +0100 Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j79CMPZu024400 for ; Tue, 9 Aug 2005 13:22:25 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3) with ESMTP id j79CMPlO017349 for ; Tue, 9 Aug 2005 13:22:25 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j79CMPbG017346 for ; Tue, 9 Aug 2005 13:22:25 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 9 Aug 2005 13:22:25 +0100 (BST) From: Guy Rixon To: vospace@ivoa.net Subject: Re: VOStore interface In-Reply-To: <42F89C48.8070709@eso.org> Message-ID: References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> <42F40583.5030900@cacr.caltech.edu> <42F8602D.4010207@eso.org> <42F89C48.8070709@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.9.8 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 On Tue, 9 Aug 2005, Paul Harrison wrote: > If it is the simple case of a choice between > > a) every authenticated user can do anything to any file > or > b) every authenticated user can do anything to any file that they own > > then it is not too difficult to describe - however any shades between > these two would be difficult. Agreed. I suspect that we may well get those shades of meaning. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Tue Aug 9 19:07:53 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79H7S5s003505 for ; Tue, 9 Aug 2005 19:07:28 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j79H7S8Q003504 for vospace-outgoing; Tue, 9 Aug 2005 19:07:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79H7I5s003475 for ; Tue, 9 Aug 2005 19:07:19 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79H7Gin021312 for ; Tue, 9 Aug 2005 19:07:17 +0200 (CEST) Received: from [192.168.10.30] (vastfire.cacr.caltech.edu [131.215.145.253]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id j79H79gh027748 for ; Tue, 9 Aug 2005 10:07:10 -0700 Message-ID: <42F8E2B7.2090902@cacr.caltech.edu> Date: Tue, 09 Aug 2005 10:07:03 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: VOStore as WS-Resource References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.9.17 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Hi, I really like the sound of this idea; however, to sell it we need to hide the WS-RF aspect. It's hard enough to get our users to buy into basic SOAP and I know that there are those who think that anything above and beyond is just a complete waste of time. Cheers, Matthew Guy Rixon wrote: >Hi, > >following up the discussion of ownership of data-items in VOStores, here's an >alternative approach: make the store an ephemeral resource in the style >established by WS-RF. > >Justification: most users will borrow storage supplied by resource providers >and access it via VOStores. We need an interface for managing the loan of the >storage (quotas, remaining length of lease etc.) WS-RF is an interface for >managing leases of resources. > >Mechanism: "a VOStore" becomes a dynamic resource. An agent creates one on >a VOStore server by calling some operation that follows the resource-factory >pattern. (This method is outside the scope of the current VOStore interface.) >Agents address such a dynamic store using the normal WS-RF mechanism: a SOAP >header. All the data-items written to the store are owned by the creator of >the store. The space used in the store can be cleared up using the WS-RF >interface; if the storage is leased for a certain time, then it can be set to >clear itself up. Users could create more than one dynamic store on the same >VOStore server; they could create a dynamic store for each project or for >each job. > >Advantages: we get the management interface without having to invent and >debate it in IVOA. We get to implement the management interface using WS-RF >toolkits if we choose (this is transparent to the clients, so the use of >toolkits can vary from store to store). Users of VOStore get to manage >data-items in multiple, dynamic stores without going through VOSpace. >We may be able to get WS-RF management tools from the grid community. > >Disadvantages: the implementor of the store has to implement WS-RF or to use a >WS-RF toolkit. Clients of the store have to supply the WS-RF header. > >NB: the WS-RF thing doesn't change the operation signatures of VOStore. We >could use a client for a fixed VOStore on a dynamic VOStore by adding a >handler (e.g. the Axis or JAX-RPC kind) that adds the WS-RF SOAP header. > >Cheers, >Guy > >Guy Rixon gtr@ast.cam.ac.uk >Institute of Astronomy Tel: +44-1223-337542 >Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > > From owner-vospace@eso.org Tue Aug 9 20:30:04 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79ITt5s012691 for ; Tue, 9 Aug 2005 20:29:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j79ITtno012690 for vospace-outgoing; Tue, 9 Aug 2005 20:29:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79ITn5s012683 for ; Tue, 9 Aug 2005 20:29:49 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j79ITkin023786 for ; Tue, 9 Aug 2005 20:29:47 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j79ITdk04421; Tue, 9 Aug 2005 11:29:39 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> <42F40583.5030900@cacr.caltech.edu> <42F8602D.4010207@eso.org> Date: Tue, 9 Aug 2005 11:28:16 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Re: VOStore interface Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.9.20 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Guy: I agree that access needs to be authenticated to ensure that restricted operations such as writes are done by recognized users. >Paul, > >we agree that access to a VOStore must be controlled, yes? Therefore, we have >two possible cases: > > 1. A store owned by a VOSpace, where the VOSpace agent is the only allowed > user and call the store under its own, agent identity. This is the model > that Reagan is promoting and which is used in SRB. It's also the model in > AstroGrid MySpace to date. Actually, VOSpace owns the data that is deposited into the store. VOSpace does not own the store. Multiple VOSpace instances can deposit data into the same store under separate account identifiers. The issue of authorization can then be handled separately by each VOSpace. If VOSpace owns the data accessed through VOStore, VOSpace can manage the authorization, create access control lists for each file, and retrieve the data through a VOStore interface. In this situation, VOStore provides a standard access mechanism for getting and putting files. > > 2. A store which accepts access authenticated to more than one identity. > Some of these identities could be used by user agents; some could be > services with delegated identities; some could be VOSpaces. This is the > model promoted by Wil (up to and at Kyoto) and, I think, by others in NVO. This is the model used by the SRB. The local store recognizes multiple accounts, one for each VOSpace instance. The VOSpace instances can be federated to enable sharing of data that is stored under different VOSpace account IDs. > >If you implement a store only for use from VOSpace then you naturally use >the first model and do no per-user authorization. Even if a store is accessed by a single VOSpace instance, VOSpace can still authenticate each user, manage access controls for each file deposited in the store, and do per-user, per-file authorization. > >If you allow direct access to stores from DAL, then you have the second model >by default and the stores _have_ to deal with file ownership. However, they >don't _necessarily_ need tables of authorized users. The standard example is GridFTP. This utility runs at root, uses grid certificates to authenticate access, and then switches the execution of GridFTP to the user's account. The challenge is that each store accessed this way has to have accounts for each user, and they can only see the data they personally own. If they want to share data, the system administrator has to establish an account for the new user, and the owner of the data must set up access permission to the new user. Direct access to stores makes it very difficult to share data. > >A minimal multi-user store allows any authenticated user to write data-items >and tracks ownership; it has a metadatum stating ownership for >each data-item. It doesn't check CRUD permissions; it assumes that the owner >has full, implicit permission on all owned items. This is a lot easier than >allowing variable permissions. The SRB data grid typically gives permissions for all roles (read, write, annotate, create metadata, turn on audit trails) to the owner of the file. Individual permissions can be established for other persons to access the data. > >I think Matthew is right. The authorization is an implementation issue. The >tricky part is describing the authorization policy in the registration of the >stores: something we haven't looked at so far. If VOStore attempts to manage authorization, it will have to implement features similar to VOSpace. VOStore would have to authenticate the user either check an access policy or ACL for each file run as root to switch to the account of the person that owns the file If the authorization is managed by VOSpace, VOStore can run as middleware, and not require root access. I prefer to put the authorization software either in the local store, or in the VOSpace layer to avoid the need for VOStore to run as root. >I suggest strongly that the same authentication system be used for both >single-user and multi-user stores even though the authorization is different. >This allows multi-user stores to be linked into VOSpace. I agree. (However I think of all stores as multi-user). Reagan > >Cheers, >Guy > > >On Tue, 9 Aug 2005, Paul Harrison wrote: > >> Matthew Graham wrote: >> > Hi, >> > >> > I would argue that this is an implementation issue: you have to make >> > sure that VOStore can fulfil what it promises. >> > >> > The required functionality for authentication is just that the VOStore >> > can recognise a valid message, e.g. the certificate used to sign the >> > SOAP message has the NVO CA in its certificate chain. >> > >> >> This simple statement does hide some potentially complex implementation >> issues though... >> >> - if the signing certificate is a user certificate, then is the VOStore >> expected to have a user database to manage the authorization issues >> (group access for instance)? I thought this was supposed to be delegated >> to the VOSpace level. >> >> - Often the caller of a VOStore will be another service, requesting >> access on behalf of a user - so VOStore will be dealing with the GSI >> certificate proxy system at the first level >> >> >> Paul Harrison >> > >Guy Rixon gtr@ast.cam.ac.uk >Institute of Astronomy Tel: +44-1223-337542 >Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Wed Aug 10 10:29:53 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7A8Te0I025257 for ; Wed, 10 Aug 2005 10:29:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j7A8TeNd025256 for vospace-outgoing; Wed, 10 Aug 2005 10:29:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7A8TZ0I025244 for ; Wed, 10 Aug 2005 10:29:36 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7A8TXin019213 for ; Wed, 10 Aug 2005 10:29:34 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:50345) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1E2lxd-000353-NI (Exim 4.51) for vospace@ivoa.net (return-path ); Wed, 10 Aug 2005 09:29:17 +0100 Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j7A8THZu003266 for ; Wed, 10 Aug 2005 09:29:17 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3) with ESMTP id j7A8TGQH018695 for ; Wed, 10 Aug 2005 09:29:16 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j7A8TGka018692 for ; Wed, 10 Aug 2005 09:29:16 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 10 Aug 2005 09:29:16 +0100 (BST) From: Guy Rixon To: vospace@ivoa.net Subject: Re: VOStore interface In-Reply-To: Message-ID: References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> <42F40583.5030900@cacr.caltech.edu> <42F8602D.4010207@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.10.1 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 On Tue, 9 Aug 2005, Reagan Moore wrote: > Actually, VOSpace owns the data that is deposited into the store. > VOSpace does not own the store. Multiple VOSpace instances can > deposit data into the same store under separate account identifiers. > ... > This is the model used by the SRB. The local store recognizes > multiple accounts, one for each VOSpace instance. The VOSpace > instances can be federated to enable sharing of data that is stored > under different VOSpace account IDs. In that case you presumably have authorization in your store such that a VOSpace cannot access (or see) data-items owned by another VOSpace. > The issue of authorization can then be handled separately by each > VOSpace. If VOSpace owns the data accessed through VOStore, VOSpace > can manage the authorization, create access control lists for each > file, and retrieve the data through a VOStore interface. In this > situation, VOStore provides a standard access mechanism for getting > and putting files. Yes, but until VOSpace exists (propably not until the end of 2006), we need a way of using VOStores separately. Thus, we need both authentication and minimal authorization in the stores. I think we all agree that the mechanism needed to authenticate a space to a store will do to authenticate any other agent to the store. My point is that the minimal authorization policy - access by owner only - needed to allow spaces to share a store will also do _in the interim_ to allow other agents to share direct access to a store. I agree that ACLs, user-settable permissions and data-sharing are better done through the VOSpace layer. Therefore, we leave them out of VOStore and specify the minimum that will allow stores to operate without spaces in 2005. > The standard example is GridFTP. This utility runs at root, uses > grid certificates to authenticate access, and then switches the > execution of GridFTP to the user's account. The challenge is that > each store accessed this way has to have accounts for each user, and > they can only see the data they personally own. If they want to > share data, the system administrator has to establish an account for > the new user, and the owner of the data must set up access permission > to the new user. Interesting, but not relevant, IMHO. We don't require users to have individual local accounts on the computers running the VOStores. In fact, we strongly require them _not_ to have such accounts; the management load on the sysadmins would be too high. Therefore, the FTP model does not apply. Instead, we need to track data-ownership in the service implementation, not in the account running the code. > If VOStore attempts to manage authorization, it will have to > implement features similar to VOSpace. VOStore would have to > authenticate the user > either check an access policy or ACL for each file > run as root to switch to the account of the person that owns the file We already agreed that authentication code is needed anyway; it can be the same code whether or not we allow direct access to the store. Your email implies that we also need to enforce data ownership when spaces share a store, therefore we need minimal authorization code whether or not we allow direct access to the store. > If the authorization is managed by VOSpace, VOStore can run as > middleware, and not require root access. It can and it doesn't, regardless of whether VOSpace does the authorization. > I prefer to put the > authorization software either in the local store, or in the VOSpace > layer to avoid the need for VOStore to run as root. As argued above, some of the the permission checking has to happen inside the store, in order to keep multiple clients (spaces) in line. It doesn't matter whether this is done in the VOStore web-service or in the storage code that the web-service calls. You can implement the check in the storage code hidden behind the VOStore facade; another project can implement it in the web service. Remember, I'm not arguing for VOStore to have _permission-setting_ operations. I want the access permissions on stores to be basic, implicit and fixed. I expect all variable permissions, such as "write-protect this file" or "share this file with user-group x" to be handled in VOSpace _exactly as you have been advocating_. Yes, that means permission-checking in two places; no, that need not lead to bad performance; no, it won't be expensive to code. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Wed Aug 10 21:48:28 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7AJmI0I001060 for ; Wed, 10 Aug 2005 21:48:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j7AJmIMs001059 for vospace-outgoing; Wed, 10 Aug 2005 21:48:18 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7AJmD0I001048 for ; Wed, 10 Aug 2005 21:48:14 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7AJmAhx016027 for ; Wed, 10 Aug 2005 21:48:11 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j7AJm3e29302; Wed, 10 Aug 2005 12:48:03 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42F0B4C5.4070107@eso.org> <42F10685.6010908@cacr.caltech.edu> <42F264F6.4090900@cacr.caltech.edu> <42F3AE77.4020407@cacr.caltech.edu> <42F40583.5030900@cacr.caltech.edu> <42F8602D.4010207@eso.org> Date: Wed, 10 Aug 2005 12:41:34 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Re: VOStore interface Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.10.22 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Guy: >On Tue, 9 Aug 2005, Reagan Moore wrote: > >> Actually, VOSpace owns the data that is deposited into the store. >> VOSpace does not own the store. Multiple VOSpace instances can >> deposit data into the same store under separate account identifiers. >> ... >> This is the model used by the SRB. The local store recognizes >> multiple accounts, one for each VOSpace instance. The VOSpace >> instances can be federated to enable sharing of data that is stored >> under different VOSpace account IDs. > >In that case you presumably have authorization in your store such that a >VOSpace cannot access (or see) data-items owned by another VOSpace. Yes. It is possible to authorize access to data-items owned by another VOSpace instance. What actually happens, is that a person with an account in VOSpace-a makes a request to VOSpace-b for access to a file. VOSpace-b asks VOSpace-a to authenticate the user, then VOSpace-b checks its access controls for whether to provide the access, and if allowed retrieves the data on behalf of the user. Both VOSpace-a and VOSpace-b could be using the same store under different account IDs. > >> The issue of authorization can then be handled separately by each >> VOSpace. If VOSpace owns the data accessed through VOStore, VOSpace >> can manage the authorization, create access control lists for each >> file, and retrieve the data through a VOStore interface. In this >> situation, VOStore provides a standard access mechanism for getting >> and putting files. > >Yes, but until VOSpace exists (propably not until the end of 2006), we need a >way of using VOStores separately. Thus, we need both authentication and >minimal authorization in the stores. I think we all agree that the >mechanism needed to authenticate a space to a store will do to authenticate >any other agent to the store. My point is that the minimal authorization >policy - access by owner only - needed to allow spaces to share a store will >also do _in the interim_ to allow other agents to share direct access to a >store. The Storage Resource Broker can be used today as a VOSpace implementation. The SRB provides the authentication, authorization, name space management, replication, required for managing shared collections. I would cast the problem differently, in terms of the usage paradigms. I see a need for only two types of access: - a researcher accesses personally owned data within a store. In this case the store does the authorization. - a researcher accesses data that is being shared through VOSpace. In this case VOSpace does the authorization. I agree that there is no need to support sharing of personally owned data without going through VOSpace. A purpose of VOSpace is to enable sharing of data. > >I agree that ACLs, user-settable permissions and data-sharing are better done >through the VOSpace layer. Therefore, we leave them out of VOStore and specify >the minimum that will allow stores to operate without spaces in 2005. > >> The standard example is GridFTP. This utility runs at root, uses >> grid certificates to authenticate access, and then switches the >> execution of GridFTP to the user's account. The challenge is that >> each store accessed this way has to have accounts for each user, and >> they can only see the data they personally own. If they want to >> share data, the system administrator has to establish an account for >> the new user, and the owner of the data must set up access permission >> to the new user. > >Interesting, but not relevant, IMHO. We don't require users to have individual >local accounts on the computers running the VOStores. In fact, we strongly >require them _not_ to have such accounts; the management load on the sysadmins >would be too high. Therefore, the FTP model does not apply. Instead, we need >to track data-ownership in the service implementation, not in the account >running the code. I am beginning to understand your use case. You want an individual to be able to store data at a remote collection without having an account on the remote system. At the same time, you want the user to be authenticated, such that no-one else is allowed to access their data. This is precisely what VOSpace (and the SRB implementation) provide. The argument against this appears to be that you believe there is no viable implementation of VOSpace capabilities. Please look at the UK e-Science grid use of the SRB as a data grid managing shared collections across stores. The system is in production, with tens of terabytes of data collections being managed. Larger production data grids exist, with collection sizes approaching a PB. > >> If VOStore attempts to manage authorization, it will have to >> implement features similar to VOSpace. VOStore would have to >> authenticate the user >> either check an access policy or ACL for each file >> run as root to switch to the account of the person that owns the file > >We already agreed that authentication code is needed anyway; it can be the >same code whether or not we allow direct access to the store. Your email >implies that we also need to enforce data ownership when spaces share a store, >therefore we need minimal authorization code whether or not we allow direct >access to the store. Data ownership is important for projects that have not publicly released their data. There are multiple levels of ownership: - account under which the data is actually deposited on the local store. This can be a VOSpace account - access controls imposed by VOSpace to decide who is allowed to read the data that is stored in a VOSpace account. In your system, some account is created at the local store to hold the data deposited through VOStore. Authentication is done by VOStore, implying that VOStore has access to a catalog of allowed users. Minimal authorization is done by VOStore such that the user can only see data that they have deposited. This means that VOStore will have to maintain a catalog of all items written to the local store along with the identity of the person who wrote to the store. These two catalogs (user identities, ownership of data) are already maintained by VOSpace. Do you plan that each VOStore implement a separate set of catalogs? You will then need to add VOStore operations to allow a person to check whether they may use a particular VOStore, and to request permission to use a store. What administrative procedures will be supplied with VOStore to manage the requests for permission to use the resource? > >> If the authorization is managed by VOSpace, VOStore can run as >> middleware, and not require root access. > >It can and it doesn't, regardless of whether VOSpace does the authorization. So VOStore actually has an account ID under which it can deposit data, similar to the account ID that VOSpace would use. > >> I prefer to put the >> authorization software either in the local store, or in the VOSpace >> layer to avoid the need for VOStore to run as root. > >As argued above, some of the the permission checking has to happen inside the >store, in order to keep multiple clients (spaces) in line. It doesn't matter >whether this is done in the VOStore web-service or in the storage code that >the web-service calls. You can implement the check in the storage code hidden >behind the VOStore facade; another project can implement it in the web >service. > >Remember, I'm not arguing for VOStore to have _permission-setting_ operations. >I want the access permissions on stores to be basic, implicit and fixed. I >expect all variable permissions, such as "write-protect this file" or "share >this file with user-group x" to be handled in VOSpace _exactly as you have >been advocating_. Yes, that means permission-checking in two places; no, that >need not lead to bad performance; no, it won't be expensive to code. Correct. It means that management of the lists used to check permission will need to be done by both VOStore and VOspace. I would greatly prefer an architecture in which VOSpace manages the lists and VOStore does not. Reagan > >Guy Rixon gtr@ast.cam.ac.uk >Institute of Astronomy Tel: +44-1223-337542 >Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Thu Aug 11 19:41:12 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7BHf1Cs023257 for ; Thu, 11 Aug 2005 19:41:01 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j7BHf1BJ023256 for vospace-outgoing; Thu, 11 Aug 2005 19:41:01 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7BHetCs023245 for ; Thu, 11 Aug 2005 19:40:56 +0200 (MEST) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7BHerin007614 for ; Thu, 11 Aug 2005 19:40:53 +0200 (CEST) Received: from localhost ([146.88.1.247]) by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id j7BHeer16508; Thu, 11 Aug 2005 11:40:40 -0600 Date: Thu, 11 Aug 2005 11:40:35 -0600 From: Doug Tody X-X-Sender: dtody@ender To: Matthew Graham cc: vospace@ivoa.net Subject: Re: VOStore/VOSpace use cases In-Reply-To: <42FB793A.9050309@cacr.caltech.edu> Message-ID: References: <42FB793A.9050309@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.5, required 7, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.50, QUOTED_EMAIL_TEXT -0.48, REFERENCES -0.50, REPLY_WITH_QUOTES -0.50, USER_AGENT_PINE 0.00) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.11.18 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Hi Matthew - On Thu, 11 Aug 2005, Matthew Graham wrote: > Hi Doug, > Guy has mentioned to me that you had some specific VOStore/VOSpace use cases > - are these already documented somewhere or could you provide a short > description of them? Probably this refers to my data access related use-cases. The are three primary cases: 1) Service generates datasets and puts them in a local VOStore. Client picks up the images with a getData request via URL (this is the default and is what we do currently). 2) Client operates a local VOStore. Client issues a staging request to a remote service to generate datasets and deliver them to the Client's VOStore. Service sends a message to the client as each dataset is delivered (or client gets the messages when it polls etc.). In a typical scenario a client may issue many such asynchronous requests which execute concurrently. Support for authorization is needed since the local VOStore is externally writeable, and to support access to proprietary data. This is the scenario I see for VO-Client functionality integrated into a desktop data analysis system. The VO-Client implements the client side of the data access services including support for queries, asynchronous services, authentication/autorization, etc. Data is fetched and placed in a local VOStore in the local VO-Client daemon. Data analysis software can then directly access the files as they would a local file, or we can put an object API in front of the data and the analysis code will see an object API and can completely ignore all the plumbing. In this use-case the client may also function as a service, generating new data products which it exposes to the VO via the local VOStore. 3) As in 2), but the staging request specifies that data is to be delivered to a third VOStore, not co-located with either the controlling client or the service. This permits general grid workflows. The client "application" is generally controlled from one location, but may have components which execute at multiple locations. Note that asynchronous services, VOStore, and security all need to be interoperable to do these things. Ideally we need some mechanism for asynchronous messaging. A polling-based mechanism would be adequate for simple cases but does not scale well. All of these use-cases emphasize dataflow and data caching rather than permanent storage of data. The only exception might be 2) where we might want to keep the data around indefinitely. However, it is still primarily a network data cache mechanism. Another major use case is a user filestore where data is maintained indefinitely, possibly distributed to multiple locations. This is more the VOSpace type of scenario. - Doug From owner-vospace@eso.org Tue Aug 23 11:09:51 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7N99am3029857 for ; Tue, 23 Aug 2005 11:09:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j7N99aAX029855 for vospace-outgoing; Tue, 23 Aug 2005 11:09:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7N99Rm3029836 for ; Tue, 23 Aug 2005 11:09:27 +0200 (MEST) Received: from sol.star.bris.ac.uk (sol.star.bris.ac.uk [137.222.58.39]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j7N99Phx000613 for ; Tue, 23 Aug 2005 11:09:25 +0200 (CEST) Received: from andromeda.star.bris.ac.uk ([137.222.58.155] ident=root) by sol.star.bris.ac.uk with esmtp (Exim 3.35 #1) id 1E7UmW-0003vt-00 for vospace@ivoa.net; Tue, 23 Aug 2005 10:09:20 +0100 Received: from mbt (helo=localhost) by andromeda.star.bris.ac.uk with local-esmtp (Exim 3.36 #1) id 1E7UmW-0000he-00 for vospace@ivoa.net; Tue, 23 Aug 2005 10:09:20 +0100 Date: Tue, 23 Aug 2005 10:09:20 +0100 (BST) From: Mark Taylor X-X-Sender: mbt@andromeda.star.bris.ac.uk To: vospace@ivoa.net Subject: Re: VOStore interface Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.23.2 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Paul Harrison wrote: > Matthew Graham wrote: > > > Identifiers: > > -------------- > > > > The protocol identifier ivo:// identifies a resource that exists in the > > VO. It does not promise that you can completely resolve a URI beginning > > ivo:// in a registry, merely that some component of the URI will relate > > to a resource that has a registry entry, i.e. the bit before the first # > > can be resolved in a registry. So I can go to a registry and find out > > where ivo://nvo.caltech/vostores/vostore1 is > > but I need to go to VOStore interface for this store to resolve > > ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we need > > to introduce a second protocol just for VOStore contents. > > Introducing a new URI for vostore is not absolutely necessary, > as you demonstrate above, you can invent any interpretation of > the ivo: URI that you want, however, a separate URI scheme does > have the benefits of > > * reducing complexity of client software that has to interpret > VO URIs/URLs - they can make simple decisions based on string > syntax rather than having to constantly query registries, > which could become a performance issue. > > * adhereing more closely to established URI/URL manipulation > conventions - the # character normally denotes a "fragment" > of the referenced resource - it is arguable whether this > useage is a fragment. I'd like to make a late addition to this debate by agreeing with Paul here on both his points. With regard to the second one, RFC 2396 (the URI generic syntax definition) says in section 4.1: When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI. ... The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. ... A fragment identifier is only meaningful when a URI reference is intended for retrieval and the result of that retrieval is a document for which the identified fragment is consistently defined. this makes clear that a string like "ivo://nvo.caltech/vostores/vostore1#halibut3" cannot be interpreted as a URI referencing a file on a remote store except in relation to the retrieved content of a document called "ivo://nvo.caltech/vostores/vostore1". Of course we're not obliged to interpret it as a URI, we can just call it an opaque string in the context of VOStore semantics, but (a) it seems unnecessarily confusing to have something which looks like a URI but is not and (b) since the string can effectively be used by client software as a locator for a persistent object, it will probably be useful in some contexts if it can be treated as a URI. Simply using some other character to separate the VOStore ID and the resource location within that store ("?" would seem a good choice, as it has a somewhat similar function in http URLs) would clear this problem up. > Another argument for a new scheme is that it has been suggested > that it would be nice to be able to reference fragments of the > stored entity - e.g. parts of a VOTable - the ivo: scheme is > already rather overburdened to allow this extra level of specification. The URI fragment mechanism would seem to be appropriate for this, but it can only correctly be used if the '#' is not used already within the basic URI. If the '#' is switched for something else as I've suggested above, this facility would not require a new protocol identifier. In fact a new protocol ID is not required for the other point either, as long as there is some syntactic way of determining whether the string refences a file on a VOStore or not. Mark -- Mark Taylor Starlink Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From owner-vospace@eso.org Thu Sep 1 16:44:03 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j81EhlIp010110 for ; Thu, 1 Sep 2005 16:43:47 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j81Ehlio010109 for vospace-outgoing; Thu, 1 Sep 2005 16:43:47 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j81EhgIp010092 for ; Thu, 1 Sep 2005 16:43:43 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j81Ehdhx018329 for ; Thu, 1 Sep 2005 16:43:40 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/71) id j81EhUN21832; Thu, 1 Sep 2005 07:43:30 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42FB793A.9050309@cacr.caltech.edu> Date: Thu, 1 Sep 2005 07:43:06 -0700 To: vospace@ivoa.net From: Reagan Moore Subject: Re: VOStore/VOSpace use cases Cc: Doug Tody Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.9.1.13 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 Matthew: SDSC is supporting similar data access use-cases to those defined by Doug, plus additional data sharing and preservation use cases. They include: - build a private collection. The private collection may be distributed across multiple physical storage systems. We use a logical resource name to represent the set of physical resources where the data may reside. The user writes a file to the logical resource name. The data grid (VOspace) then picks a physical resource based on available space, or disk cache at the same IP address as the user, or disk cache at a remote IP address, or a tape archive. The VOstore interface would provide the standard access mechanism to the storage repository. In our use of the data grid, the user would never talk directly to the VOStore interface in front of the storage system. Instead the VOSpace data grid would interact with VOStore on behalf of the user. In practice, the VOSpace data grid could provide an abstract VOStore interface to the user as a standard access method. The other difference is that the user can associate metadata with each stored file. The metadata could be the parameters in a FITS header, or any other descriptive or provenance attributes of interest. The files may be referenced by a logical file name managed by VOSpace. This logical file name can be mapped to a URL for access through a web browser or WSDL service. The user typically would not know the physical file name at the actual storage resource where the data ends up. - build a local disk cache. This case is the same as the first, with the specification that the storage resource is the local system. Again a VOStore interface is provided to the local storage, but access is through VOSpace. This allows the authentication and authorization to be managed by VOSpace. VOStore only checks authentication related to VOSpace identification. VOSpace checks the user authentication. Multiple types of APIs can be put in front of VOSpace including object, java, perl, python, web, WSDL, ... The storage system does not have to support these interfaces. Instead VOSpace maps from these protocols to the protocol used by VOStore, which in turn maps to the local storage repository protocol. - support for third party transfer is managed by VOSpace. VOSpace has to authenticate itself to each VOStore instance. This means that trust has to be established between all storage providers through the VOStore interface to the VOSpace data grid. Third party transfer is then simply the copying of data between two storage systems, both of which trust the VOSpace data grid. In effect, the VOSpace data grid is a trust virtualization mechanism that enables controlled interactions between storage repositories on their behalf. - replication environments. To support large scale analyses, we have replicated image surveys onto the Teragrid storage systems. This adds the requirement for support of replicas, synchronization of replicas, aggregation of files into containers for interactions with tape archives, parallel I/O support for large transfers, packing of small files before transmission, support for firewalls, and support for GSI authentication. - digital libraries. For small collections, the DSpace and Fedora digital libraries provide mechanisms for assembling, organizing and managing files. Both DSpace and Fedora have now been ported on top of the SRB data grid, making it possible for these digital libraries to manage data that is distributed across multiple storage systems. Reagan >Hi Matthew - > >On Thu, 11 Aug 2005, Matthew Graham wrote: >> Hi Doug, >> Guy has mentioned to me that you had some specific VOStore/VOSpace use cases >> - are these already documented somewhere or could you provide a short >> description of them? > >Probably this refers to my data access related use-cases. The are three >primary cases: > > 1) Service generates datasets and puts them in a local VOStore. > Client picks up the images with a getData request via URL (this > is the default and is what we do currently). > > 2) Client operates a local VOStore. Client issues a staging request > to a remote service to generate datasets and deliver them to > the Client's VOStore. Service sends a message to the client as > each dataset is delivered (or client gets the messages when it > polls etc.). In a typical scenario a client may issue many such > asynchronous requests which execute concurrently. Support for > authorization is needed since the local VOStore is externally > writeable, and to support access to proprietary data. > > This is the scenario I see for VO-Client functionality integrated > into a desktop data analysis system. The VO-Client implements > the client side of the data access services including support for > queries, asynchronous services, authentication/autorization, etc. > Data is fetched and placed in a local VOStore in the local VO-Client > daemon. Data analysis software can then directly access the files > as they would a local file, or we can put an object API in front > of the data and the analysis code will see an object API and can > completely ignore all the plumbing. > > In this use-case the client may also function as a service, > generating new data products which it exposes to the VO via the > local VOStore. > > 3) As in 2), but the staging request specifies that data is to be > delivered to a third VOStore, not co-located with either the > controlling client or the service. This permits general grid > workflows. The client "application" is generally controlled from > one location, but may have components which execute at multiple > locations. > >Note that asynchronous services, VOStore, and security all need to be >interoperable to do these things. Ideally we need some mechanism for >asynchronous messaging. A polling-based mechanism would be adequate for >simple cases but does not scale well. > >All of these use-cases emphasize dataflow and data caching rather than >permanent storage of data. The only exception might be 2) where we might >want to keep the data around indefinitely. However, it is still primarily >a network data cache mechanism. > >Another major use case is a user filestore where data is maintained >indefinitely, possibly distributed to multiple locations. This is more >the VOSpace type of scenario. > > - Doug From owner-vospace@eso.org Fri Nov 4 13:07:54 2005 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id jA4C7gqE015281 for ; Fri, 4 Nov 2005 13:07:42 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id jA4C7gii015280 for vospace-outgoing; Fri, 4 Nov 2005 13:07:42 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id jA4C7cqE015271 for ; Fri, 4 Nov 2005 13:07:38 +0100 (MET) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id jA4C7aZq018223 for ; Fri, 4 Nov 2005 13:07:37 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:34895) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1EY0Lh-0002bN-4h (Exim 4.54) for vospace@ivoa.net (return-path ); Fri, 04 Nov 2005 12:07:13 +0000 Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117]) by cass41.ast.cam.ac.uk (8.13.4+Sun/8.13.4) with ESMTP id jA4C7Dmq021541 for ; Fri, 4 Nov 2005 12:07:13 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.13.4+Sun/8.13.3) with ESMTP id jA4C7D4f012547 for ; Fri, 4 Nov 2005 12:07:13 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.4+Sun/8.13.3/Submit) with ESMTP id jA4C7CeK012544 for ; Fri, 4 Nov 2005 12:07:13 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 4 Nov 2005 12:07:12 +0000 (GMT) From: Guy Rixon To: vospace@ivoa.net Subject: Refactored VOStore document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.11.4.6 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 Hi, following the resolutions in the interop meeting I'm updating the VOStore specification. At this time I'd like to refactor the document: - Make a new document, either a WD or a note that discusses the VOSpace/VOStore concepts. - Reduce the actual VOStore spec to just the normative text and minimal explanation. The reduced spec, which I propose to call VOStore 0.20, will probably come out first. For now, please refer back to VOStore 0.18 for the introductory material. Cheers, Guy Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Mon Nov 7 17:02:29 2005 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id jA7G2Haj000200 for ; Mon, 7 Nov 2005 17:02:17 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id jA7G2Gh3000197 for vospace-outgoing; Mon, 7 Nov 2005 17:02:16 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id jA7G2Aaj000174 for ; Mon, 7 Nov 2005 17:02:10 +0100 (MET) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id jA7G29e4025098 for ; Mon, 7 Nov 2005 17:02:09 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:49275) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1EZ9RX-0008PW-4N (Exim 4.54) for vospace@ivoa.net (return-path ); Mon, 07 Nov 2005 16:01:59 +0000 Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117]) by cass41.ast.cam.ac.uk (8.13.4+Sun/8.13.4) with ESMTP id jA7G1xMx006592 for ; Mon, 7 Nov 2005 16:01:59 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.13.4+Sun/8.13.3) with ESMTP id jA7G1xB6016469 for ; Mon, 7 Nov 2005 16:01:59 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.4+Sun/8.13.3/Submit) with ESMTP id jA7G1wBD016465 for ; Mon, 7 Nov 2005 16:01:58 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 7 Nov 2005 16:01:58 +0000 (GMT) From: Guy Rixon To: vospace@ivoa.net Subject: Re: Refactored VOStore document In-Reply-To: <14CF4CD7-0491-492A-B54B-F39C8F615152@eso.org> Message-ID: References: <14CF4CD7-0491-492A-B54B-F39C8F615152@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.11.7.14 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: vospace@ivoa.net Paul, thanks. It would be helpful if you could comment on the spec document when it comes out. Would you like to re-do some of the sections of the introductory note? Guy On Mon, 7 Nov 2005, Paul Harrison wrote: > Hi Guy, > > I would be happy to contribute to the authorship of either of these > documents - indeed ESO management is expecting me to as part of my > work for the next period following the ADASS interop demo, so I even > have time allocated! > > Cheers, > Paul. > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Tue Apr 25 14:43:39 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3PCdxbC020726 for ; Tue, 25 Apr 2006 14:39:59 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3PCdxZE020725 for vospace-outgoing; Tue, 25 Apr 2006 14:39:59 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3PCdlbC020639 for ; Tue, 25 Apr 2006 14:39:47 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3PCdjxF027538 for ; Tue, 25 Apr 2006 14:39:46 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:38283) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1FYMpH-00084r-4z (Exim 4.54) (return-path ); Tue, 25 Apr 2006 13:39:31 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3PCdThZ017159; Tue, 25 Apr 2006 13:39:29 +0100 (BST) Message-ID: <444E1881.6060709@ast.cam.ac.uk> Date: Tue, 25 Apr 2006 13:39:29 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: Test Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.25.45105 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Test email .... please ignore. Dave From owner-vospace@eso.org Thu Apr 27 17:57:13 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RFuXeP011509 for ; Thu, 27 Apr 2006 17:56:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3RFuXcW011507 for vospace-outgoing; Thu, 27 Apr 2006 17:56:33 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RFtleP011369; Thu, 27 Apr 2006 17:55:48 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RFqYr9007459; Thu, 27 Apr 2006 17:55:44 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:52310) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FZ8n3-0001Ej-Vo (Exim 4.54) (return-path ); Thu, 27 Apr 2006 16:52:25 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3RFqMjL002507; Thu, 27 Apr 2006 16:52:22 +0100 (BST) Message-ID: <4450E8B6.20601@ast.cam.ac.uk> Date: Thu, 27 Apr 2006 16:52:22 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net CC: Guy Rixon , Paul Harrison , Matthew Graham Subject: VoSpace functional spec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.27.83111 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris I have written up some wiki pages that outline the functional specification for VoSpace service methods. http://wiki.astrogrid.org/bin/view/Astrogrid/VoSpace20060426 These pages should form the basis of the VoSpace functional specification. The details of the SOAP/XML representation of the inputs and outputs will be covered in a separate document. Comments/corrections welcome. Many thanks, Dave From owner-vospace@eso.org Thu Apr 27 19:32:51 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RHWgYA024326 for ; Thu, 27 Apr 2006 19:32:42 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3RHWgf0024325 for vospace-outgoing; Thu, 27 Apr 2006 19:32:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RHWfYA024321 for ; Thu, 27 Apr 2006 19:32:41 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RHU9r9012783 for ; Thu, 27 Apr 2006 19:32:40 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:54554) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FZ9AC-0005ir-Uz (Exim 4.54) for vospace@ivoa.net (return-path ); Thu, 27 Apr 2006 17:16:20 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3RGGKHI004709 for ; Thu, 27 Apr 2006 17:16:20 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3RGGKYs001689 for ; Thu, 27 Apr 2006 17:16:20 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k3RGGK35001686 for ; Thu, 27 Apr 2006 17:16:20 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 27 Apr 2006 17:16:20 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: vospace@ivoa.net Subject: VOSpace operation names Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.27.85105 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon It has been suggested a few time over the last year that the current operation names importInit, importData, exportInit, exportData in Dave M.'s spec notes need to be changed to something more descriptive. AFAIK, nobody disputes that, but we've used the old names so far for continuity. Now it's time to choose new names and stick to them. This email thread is to collect the suggestions for new names. My vote: pushDataToVoSpace pullDataToVoSpace pushDataFromVoSpace pulldataFromVoSpace If I need to explain those (to anybody who's read the spec that Dave wrote up), then maybe they're not right. :) Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Thu Apr 27 20:17:51 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RIHeYA029963 for ; Thu, 27 Apr 2006 20:17:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3RIHeWG029962 for vospace-outgoing; Thu, 27 Apr 2006 20:17:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RIHdYA029958 for ; Thu, 27 Apr 2006 20:17:39 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RIFxxF013765 for ; Thu, 27 Apr 2006 20:17:37 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:53421) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FZ8xq-0006Lp-Tu (Exim 4.54) for vospace@ivoa.net (return-path ); Thu, 27 Apr 2006 17:03:34 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3RG3Ypb003645 for ; Thu, 27 Apr 2006 17:03:34 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3RG3XjA001380 for ; Thu, 27 Apr 2006 17:03:34 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k3RG3XqY001377 for ; Thu, 27 Apr 2006 17:03:33 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 27 Apr 2006 17:03:33 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: vospace@ivoa.net Subject: Re: VoSpace progress (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.27.105109 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Dave Morris just posted some spec. material to the list. I made some commments privately on a previous draft of that material (earlier today). Here's a copy of Dave's answers to those points. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 ---------- Forwarded message ---------- Date: Thu, 27 Apr 2006 13:10:19 +0100 From: Dave Morris To: Guy Rixon Subject: Re: VoSpace progress Guy Rixon wrote: >Dave, > >thoughts on the specification. > >1. Where are the syntatic and semantic rules for vos:// URI? > > Paul was pushing for a separate URI space, so I'm hoping he will cover this. >2. As has been discussed before, the names of the operations are unhelpful. > > Ok I've been using them as working names so far because we have been discussing more fundamental things like containers etc. >3. I dislike the argument lists; to much like RPC style, which this isn't. >I'd prefer to define all the structures in a .xsd schema, with identified root >elements. Then, each SOAP message contains a document with one of these root >element. That's true document/literal in the spirit of W3C. However, if the >"parameters" are just the first-level children of the document element then it >comes to the same thing. > > Absolutely. This is looking at the functional side of the service, and the params are just a list of what data the WSDL/schema needs to represent. How these are represented will hopefully be covered by Paul/Matthews WSDL and schema. >4. IVOIDs to identify standards are fine. Using IVOIDs in the >org.astrogrid.vospace namespace is OK for protoyping, but we should not make >these part of the final standard. We should make this clear in the spec. > > The spec. refers to 'registered URI for http protocol'. Ideally, I'd like things like this to registered under a 'net.ivoa' authority. Registering them under org.astrogrid is a way to raise the issue and make it public. Hopefully this will act as a catalyst to start the discussion. >5. Where are the supported node-types enummerated? > > They aren't. I'll add this to the doc. >6. Don't understand what GetData and PutData do if DIME is included in the >other data-access methods. > > Ok, I to explain more. >11. POSIX has the create-but-fail-if-it-already-exists flag (O_EXCL, IIRC). We >probably need this too. > > false >12. Since VOSpace 1.0 only covers flat spaces, do we need MoveNode? Or do we >need it for renaming inside the same directory? > > Yes, move is 'rename' and 'move in tree' combined. >13. There used to be some operations to ask what transfer protocols a space >supported. Is this information now got from the registry? > I was working on one registry entry for each VoSpace service. Protocols listed in the capabilities. > If so, it implies >that an entire space (which is what what gets registered) supports the same >protocols for all nodes. > Yes > If the space is actually built up of a set of stores >of different types, then the capability of the space becomes the >intersection of the capabilities of the stores, which could be awkward. > > Using links to federate spaces means we don't have individual stores - they are all spaces. >I would suggest listing the protocols in return from GetNodeProperties. >However, this means a lot of extra look-ups. Might we make a rule that the >transfer properties of a container node, if present, apply to all the >node's children? > > One set of protocol capabilities for the whole space. >14. For asynchronous transfers, the problem is that we can't push >notifications if the client is on the desktop (i.e. is not itself a SOAP >server). Ask Noel for the reasoning if you're interested. > >Therefore, we have to support polling, so the element has to >contain some unique ID which the client can use in enquiries. > >To support push notification at all, with the limited SOAP tools, the client >has also to be a service and needs to supply a notification endpoint when >invoking the transfer. > > Absolutely. That is why asynch callbacks and status polling are going to be in separate capability (V1.1). Push has been to get the initial V1.0 spec. agreed and then we can move on. >17. We're singling out VOTable as a known format. Do we need to identify other >formats? FITS maybe? > > Yep, will do. It wasn't meant as a definitive list, just examples. >18. Where does the client set or find out the MIME type? > > I'd prefer in a property. >More later... > > Excellent stuff. I'll make a few of the changes, but will leave the rest until after I get this onto the ivoa list. Would you mind re-posting comments to the ivoa list once I get it published. Good way to get the discussion started. Thanks, Dave From owner-vospace@eso.org Thu Apr 27 23:48:46 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RLmdx0027915 for ; Thu, 27 Apr 2006 23:48:39 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3RLmcOf027914 for vospace-outgoing; Thu, 27 Apr 2006 23:48:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RLmcx0027906 for ; Thu, 27 Apr 2006 23:48:38 +0200 (MEST) Received: from lnfm1.sai.msu.ru (lnfm1.sai.msu.ru [195.208.220.1]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3RLmar9027580 for ; Thu, 27 Apr 2006 23:48:36 +0200 (CEST) Received: from lnfm1.sai.msu.ru (localhost.localdomain [127.0.0.1]) by lnfm1.sai.msu.ru (8.12.8/8.12.8) with ESMTP id k3RLmTOL030380; Fri, 28 Apr 2006 01:48:29 +0400 Received: from localhost (iz@localhost) by lnfm1.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id k3RLmTmP030375; Fri, 28 Apr 2006 01:48:29 +0400 X-Authentication-Warning: lnfm1.sai.msu.ru: iz owned process doing -bs Date: Fri, 28 Apr 2006 01:48:29 +0400 (MSD) From: "Ivan Yu. Zolotukhin" To: Guy Rixon cc: vospace@ivoa.net Subject: Re: VOSpace operation names In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.27.135105 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: "Ivan Yu. Zolotukhin" On Thu, 27 Apr 2006, Guy Rixon wrote: > My vote: > > pushDataToVoSpace > pullDataToVoSpace > pushDataFromVoSpace > pulldataFromVoSpace ^ typo obviously? :) > > If I need to explain those (to anybody who's read the spec that Dave wrote > up), then maybe they're not right. :) > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > From owner-vospace@eso.org Fri Apr 28 10:42:25 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3S8gFx0007029 for ; Fri, 28 Apr 2006 10:42:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3S8gFbm007026 for vospace-outgoing; Fri, 28 Apr 2006 10:42:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3S8gEx0007013 for ; Fri, 28 Apr 2006 10:42:14 +0200 (MEST) Received: from sol.star.bris.ac.uk (sol.star.bris.ac.uk [137.222.58.39]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3S8gCxF025466 for ; Fri, 28 Apr 2006 10:42:13 +0200 (CEST) Received: from andromeda.star.bris.ac.uk ([137.222.58.155] ident=root) by sol.star.bris.ac.uk with esmtp (Exim 3.35 #1) id 1FZOYB-0000kB-00 for vospace@ivoa.net; Fri, 28 Apr 2006 09:42:07 +0100 Received: from mbt (helo=localhost) by andromeda.star.bris.ac.uk with local-esmtp (Exim 3.36 #1) id 1FZOY7-0003OK-00 for vospace@ivoa.net; Fri, 28 Apr 2006 09:42:03 +0100 Date: Fri, 28 Apr 2006 09:42:03 +0100 (BST) From: Mark Taylor X-X-Sender: mbt@andromeda.star.bris.ac.uk To: vospace@ivoa.net Subject: Re: VoSpace functional spec In-Reply-To: <4450E8B6.20601@ast.cam.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.28.5104 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Mark Taylor On Thu, 27 Apr 2006, Dave Morris wrote: > I have written up some wiki pages that outline the functional > specification for VoSpace service methods. > > http://wiki.astrogrid.org/bin/view/Astrogrid/VoSpace20060426 > > These pages should form the basis of the VoSpace functional specification. > The details of the SOAP/XML representation of the inputs and outputs > will be covered in a separate document. > > Comments/corrections welcome. Dave et al. I'm total VOSpace newcomer so there's a high probability that some or all of the comments below are ill-informed and/or nonsense, but having taken a quick look I thought I'd send them to the list anyway: CreateNode - what's it for? What is the meaning of an empty node? Can't you just get by with ImportInit? Data formats such as ivo://org.astrogrid.vospace/formats/votable-1.0 - why not use MIME types? - "Should we make the default format binary and allow the element to be optional?" - I'm inclined to answer "yes", but that may be because I don't understand the purpose of them. CopyNode in continuation mode: - Specify the semantics of PageSize more precisely - is this a maximum, or an exact requirement for the server for every page except the final one? ListNodes - is incorrectly titled "CopyNode" - Returns | Properties - In "The set of name value properties for the new node", "new" is presumably a typo Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From owner-vospace@eso.org Fri Apr 28 13:27:47 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SBRdYI027791 for ; Fri, 28 Apr 2006 13:27:39 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3SBRdlc027790 for vospace-outgoing; Fri, 28 Apr 2006 13:27:39 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SBRYYI027785 for ; Fri, 28 Apr 2006 13:27:34 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SBQer9004102 for ; Fri, 28 Apr 2006 13:27:32 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:34959) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FZR7A-0002NW-VM (Exim 4.54) (return-path ); Fri, 28 Apr 2006 12:26:24 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3SBQMq9024787; Fri, 28 Apr 2006 12:26:22 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3SBQMOJ020299; Fri, 28 Apr 2006 12:26:22 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k3SBQM29020296; Fri, 28 Apr 2006 12:26:22 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 28 Apr 2006 12:26:22 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: "Ivan Yu. Zolotukhin" cc: vospace@ivoa.net Subject: Re: VOSpace operation names In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.28.35110 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Yes, a typo. Always one. :) pullDataFromVoSpace And the lower-case o in VoSpace is intentional. On Fri, 28 Apr 2006, Ivan Yu. Zolotukhin wrote: > On Thu, 27 Apr 2006, Guy Rixon wrote: > > > My vote: > > > > pushDataToVoSpace > > pullDataToVoSpace > > pushDataFromVoSpace > > pulldataFromVoSpace > ^ > typo obviously? :) > > > > > If I need to explain those (to anybody who's read the spec that Dave wrote > > up), then maybe they're not right. :) > > > > Guy Rixon gtr@ast.cam.ac.uk > > Institute of Astronomy Tel: +44-1223-337542 > > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Fri Apr 28 13:44:19 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SBi8YI000503 for ; Fri, 28 Apr 2006 13:44:08 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3SBi8Wj000501 for vospace-outgoing; Fri, 28 Apr 2006 13:44:08 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SBi7YI000491 for ; Fri, 28 Apr 2006 13:44:07 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SBdrr9004698 for ; Fri, 28 Apr 2006 13:44:06 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:36197) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FZRK3-0000c3-W4 (Exim 4.54) (return-path ); Fri, 28 Apr 2006 12:39:43 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3SBdhB9025934; Fri, 28 Apr 2006 12:39:43 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3SBdhTw020541; Fri, 28 Apr 2006 12:39:43 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k3SBdhuV020538; Fri, 28 Apr 2006 12:39:43 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 28 Apr 2006 12:39:43 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Mark Taylor cc: vospace@ivoa.net Subject: Re: VoSpace functional spec In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.28.35110 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon On Fri, 28 Apr 2006, Mark Taylor wrote: > CreateNode > - what's it for? What is the meaning of an empty node? Can't you > just get by with ImportInit? It creates container nodes - virtual directories. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Fri Apr 28 14:07:05 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SC6vYI004543 for ; Fri, 28 Apr 2006 14:06:57 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k3SC6vtU004541 for vospace-outgoing; Fri, 28 Apr 2006 14:06:57 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SC6uYI004536 for ; Fri, 28 Apr 2006 14:06:56 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k3SC6sxF007723 for ; Fri, 28 Apr 2006 14:06:54 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:38651) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FZRkB-00072P-W7 (Exim 4.54) (return-path ); Fri, 28 Apr 2006 13:06:44 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k3SC6fMo028504; Fri, 28 Apr 2006 13:06:41 +0100 (BST) Message-ID: <44520551.9070108@ast.cam.ac.uk> Date: Fri, 28 Apr 2006 13:06:41 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Taylor CC: vospace@ivoa.net Subject: Re: VoSpace functional spec References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.28.43110 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Mark Taylor wrote: >Dave et al. > >I'm total VOSpace newcomer so there's a high probability that some or >all of the comments below are ill-informed and/or nonsense > Not at all, you have highlighted some important gaps where I haven't explained in enough detail. > CreateNode > - what's it for? What is the meaning of an empty node? Can't you > just get by with ImportInit? > You are right, the import methods can be used to create new data nodes. However, create node is required to create other types of nodes, such as containers and symbolic links. I've added a line to the create node page 'This is used to create new data nodes, containers and links' > Data formats such as ivo://org.astrogrid.vospace/formats/votable-1.0 > - why not use MIME types? > > In order to exchange information about data formats, we need a common list of formats and protocols that all VO applications use. In the VoSpace specification we have defined and as URIs. Exactly what is in those URIs is open to debate. I used registry URIs, because they can be resolved to a description about the data format. At the moment, I have just created a basic for each, but this should be expanded to include details of the format, it's specification, and details of how it is used in astronomy. If another VO group proposes a new data format, then they can register a document describing how the data format works. If your application received some data in the new format, and you didn't know what was; then you should be able to look up the URI in the registry to find details of what the format is and how to handle it. It also allows us to create more specific sub-types if we want. For example, as I understand it, FITS can contain a wide range of data, from simple tabular data to binary images. A database table based VoSpace might be able to interpret the tabular data, but it might not be able to handle embedded images. In which case, the service would accept 'fits.tabular', but not 'fits.image'. A file based VoSpace that does not interpret the data, would accept any format and store it as a BLOB. We probably could use MIME type for this, but would it be specific enough to distinguish between tabular and binary FITS, or different versions of VoTable ? Also, if we used MIME type to identify data formats, what would we use to identify transport protocols ? Using URIs, preferably registry URIs, means we can use the same system for data formats, transport protocols ... etc. > - "Should we make the default format binary and allow the > element to be optional?" > - I'm inclined to answer "yes", but that may be because I don't > understand the purpose of them. > > We would like to encourage people to add as much metadata as possible when importing data into VoSpace. If the client specifies a data format, then future VoSpace services can decide how to interpret the data based on the format. Always defaulting to 'binary' means we end up with a large pile of 'stuff'. It all depends on how people want to use the system. They may find it tedious to have to specify the format whenever they import data. On the other hand, if they do specify the format, then VoSpace clients could provide a much richer UI showing different icons and options for known data formats. > CopyNode in continuation mode: > - Specify the semantics of PageSize more precisely - is this a maximum, > or an exact requirement for the server for every page except the > final one? > > Good point. I've added this as a question on the page. As a UI developer, which would you prefer ? > ListNodes > - is incorrectly titled "CopyNode" > > Yep, copy/paste error .. page updated. > - Returns | Properties > - In "The set of name value properties for the new node", "new" > is presumably a typo > > Yep, copy/paste error .. page updated. Thanks, Dave From owner-vospace@eso.org Tue May 2 14:10:30 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k42CAKDO027009 for ; Tue, 2 May 2006 14:10:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k42CAK3u027008 for vospace-outgoing; Tue, 2 May 2006 14:10:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k42CAJDO027003 for ; Tue, 2 May 2006 14:10:19 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k42CAJXR022308 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 2 May 2006 14:10:19 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: vospace@ivoa.net From: Paul Harrison Subject: VOSpace URIs Date: Tue, 2 May 2006 14:10:17 +0200 X-Mailer: Apple Mail (2.749.3) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison Early drafts of the VOSpace (or more accurately VOStore) standard proposed defining locators for the space by dereferencing using the "fragment" (#) extension of the IVOA standard identifier scheme ivo: so for example a reference ivo://org.astrogrid/vospace#my/pathto/mydata would point to a particular data holding called mydata in a container called "my/pathto/" on a vospace server the location of which could be found by looking in the registry entry with identifier "ivo:// org.astrogrid/vospace" For the particular case of VOSpace I would like to propose that this practice is not followed. I believe that the because VOSpace is a complete namespace of its own with locator style semantics, it deserves its own URI scheme. There are the following advantages; 1. Client software and humans could immediately recognise that they had been given a VOSpace URI by trivial inspection of the namespace prefix, as opposed to having to do at least one dereferencing operation in the registry to check if the URI does indeed refer to VOSpace. The example given above could refer to a VOEvent for instance if someone had been perverse enough to register a voevent server with an identifier that looked more like a vospace. One of the aims of VOSpace is to make it easy to share data, and so it should also be easy to recognise and manipulate the locators for the data. 2. A VOSpace specific scheme could more closely follow the general URI semantics and syntax as laid down in http://www.ietf.org/rfc/ rfc3986.txt so that they could be manipulated by generic URI parsing software - i.e. a) Use the general form that indicates a "/" to be interpreted as part of a locator hierarchy - it is unfortunate that the ivo: scheme allows the use of "/" in identifiers when there is no implied hierarchy in that scheme. b) Use the "fragment" and "query" parts of the URI directly in a VOSpace scheme rather than these syntactic constructs having to be used simply to delimit what belongs to the ivo: scheme and what it part VOSpace reference. It was an early design aim of VOSpace that it should be possible to reference parts of the the data objects - e.g. columns in a VOTable file, and it would be beneficial if the URI scheme could support this simply and directly. With these advantages it remains only to define the VOSpace URL scheme following the advice in http://www.ietf.org/rfc/rfc2718.txt ; The general idea would be to have a scheme vos: that had similar semantics to the http: scheme with general structure vos://authority/path?query#fragment The authority part is intended to be the ivoa identifier for a VOSpace server so that the registry would play the same name lookup service role that DNS typically does with http URLs. The main problem here is the fact that the IVOA identifiers already use "/" as part of the identifier which make the direct use of the unaltered IVOA identifier impossible, as the "/" that was part of the IVOA identifier would be interpreted as the start of the path part of the vos: scheme. In this case the "/" needs to be replaced by another reserved character - preferably without another common meaning (and in the "discouraged" set of characters in the IVOA identifiers standard - "!" or "$" would be candidates, so that the original example above could be represented as vos://org.astrogrid!vospace/my/pathto/mydata it might even be a good idea to prefix the authority part with a "!" also to make it clear that the authority should not be interpreted as an ordinary IP DNS host name representation. vos://!org.astrogrid!vospace/my/pathto/mydata Paul Harrison From owner-vospace@eso.org Tue May 2 17:31:34 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k42FVGag011992 for ; Tue, 2 May 2006 17:31:16 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k42FVGi9011991 for vospace-outgoing; Tue, 2 May 2006 17:31:16 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k42FVFag011978; Tue, 2 May 2006 17:31:15 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k42FVCxF000434; Tue, 2 May 2006 17:31:13 +0200 (CEST) Received: from [192.168.1.100] (64-30-223-60.dsl.linkline.com [64.30.223.60]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k42FV43H009973 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 2 May 2006 08:31:04 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: multipart/alternative; boundary=Apple-Mail-1-772939400 Message-Id: <0CED72D6-894B-4B82-9CE5-C718F261B474@cacr.caltech.edu> Cc: Roy Williams , vospace@ivoa.net From: Roy Williams Subject: Re: VOSpace URIs Date: Tue, 2 May 2006 08:31:03 -0700 To: Paul Harrison X-Mailer: Apple Mail (2.749.3) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.2.75105 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Roy Williams --Apple-Mail-1-772939400 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On May 2, 2006, at 5:10 AM, Paul Harrison wrote: > Replace this > ivo://org.astrogrid/vospace#my/pathto/mydata > with this > vos://org.astrogrid!vospace/my/pathto/mydata Paul If we add new and subtle semantics to the IVORN syntax, then a lot of documentation will have to be made over the next years explaining vos:// and ivo:// and why there are two and how they are parsed and used. Each VO tutorial for the next 5 years will have to include 15 minutes on ivo and vos. Future IVOA meetings will need extra time for this extra syntax/semantics. People will want their own prefix ("can I use voe:// for VOEvent?"). So this is a big time commitment and you need *very* good reasons for this. Your reasons are good, I am not sure they are good *enough*...... -- In each case you need to use the registry to get an endpoint (from ivo://org.astrogrid/vospace or from vos://org.astrogrid), then you make a service request to that endpoint to get the data. Is that right? -- If you want to put a DNS address in (so you don't need to query the registry), then you could use a normal http prefix without the effort of making new identifier standards: http://astrogrid.org/vospace/my/pathto/mydata -- You can already assign whatever semantics you wish to the fragment part. You can have query!path!tablecolumn if you want without need of building a new identifier syntax. -- I think people already know what these ivorns are supposed to be, they don't need a special prefix. If I made a query for Conesearches and got some ivorns back, then I know what they should be because that come from that query. Hey how about a cos:// prefix for cone searches so I can recognize them? Roy California Institute of Technology 626 395 3670 --Apple-Mail-1-772939400 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On May 2, 2006, at = 5:10 AM, Paul Harrison wrote:
Replace = this
=A0=A0 = =A0ivo://org.astrogrid/vospace#my/pathto/mydata
with = this
=A0=A0 = =A0vos://org.astrogrid!vospace/my/pathto/mydata

Paul

If = we add new and subtle semantics to the IVORN syntax, then a lot of = documentation will have to be made over the next years explaining vos:// = and ivo:// and why there are two and how they are parsed and used. Each = VO tutorial for the next 5 years will have to include 15 minutes on ivo = and vos. Future IVOA meetings will need extra time for this extra = syntax/semantics. People will want their own prefix ("can I use voe:// = for VOEvent?"). So this is a big time commitment and you need *very* = good reasons for this. Your reasons are good, I am not sure they are = good *enough*......

-- In each case you need to = use the registry to get an endpoint (from=A0ivo://org.astrogrid/vospace = or from=A0vos://org.astrogrid), then you make a service request to that = endpoint to get the data. Is that right?

-- If you want to put a DNS = address in (so you don't need to query the registry), then you could use = a normal http prefix without the effort of making new identifier = standards:

-- You can already assign = whatever semantics you wish to the fragment part. You can have = query!path!tablecolumn if you want without need of building a new = identifier syntax.

-- I think people already = know what these ivorns are supposed to be, they don't need a special = prefix. If I made a query for Conesearches and got some ivorns back, = then I know what they should be because that come from that query. Hey = how about a cos:// prefix for cone searches so I can recognize = them?

Roy


California Institute of Technology

626 395 3670

=

= --Apple-Mail-1-772939400-- From owner-vospace@eso.org Wed May 3 11:17:12 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k439H0qu019716 for ; Wed, 3 May 2006 11:17:01 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k439H0I4019713 for vospace-outgoing; Wed, 3 May 2006 11:17:00 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k439Gwqu019701; Wed, 3 May 2006 11:16:58 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k439Gtr9025282; Wed, 3 May 2006 11:16:55 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:45775) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1FbDT5-00064W-NB (Exim 4.54) (return-path ); Wed, 03 May 2006 10:16:23 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k439GMrE011176; Wed, 3 May 2006 10:16:22 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k439GMj6022885; Wed, 3 May 2006 10:16:22 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k439GMG9022882; Wed, 3 May 2006 10:16:22 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 3 May 2006 10:16:22 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Paul Harrison cc: vospace@ivoa.net Subject: Re: VOSpace URIs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.3.13107 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Paul, some thoughts on your proposal, and a counter proposal that preserves the use of the ivo: scheme without messing with the fragment or query parts of the URI. This is a looong email; sorry, but your ideas are deep and I can't make the counter argument shorter. :) Firstly, I'd like to note that when I originally proposed a vos: scheme (http://wiki.astrogrid.org/bin/view/AG2/IvoNamesAndLocators) it had different semantics: _any_ VOSpace node could resolve any VOSpace identifier. Therefore, the vos: URI both named the data item and said how to resolve it; and that resolution was independent of the registry, presuming a client knew of one, "local" VOSpace service. Your proposal isn't independent of the registry. The _client_ has to resolve a vos: URI to an ivo: URI and then find the right VOSpace service in the registry. "Standard URI-parsing software" won't help with this. Secondly, I'm not sure that your vos: really has "locator-style semantics". A vos: URI doesn't point directly to anything concrete that can be downloaded in the manner of a web page, and the VOSpace semantics are quite different to those of HTTP, FTP etc. Thirdly, having re-read RFC3986, I don't see anything illegal in an IVOID's use of the query fragment to represent the path into VOSpace. From the RFC: "3.5. Fragment The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. fragment = *( pchar / "/" / "?" ) The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications. Individual media types may define their own restrictions on or structures within the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. If the primary resource has multiple representations, as is often the case for resources whose representation is selected based on attributes of the retrieval request (a.k.a., content negotiation), then whatever is identified by the fragment should be consistent across all of those representations. Each representation should either define the fragment so that it corresponds to the same secondary resource, regardless of how it is represented, or should leave the fragment undefined (i.e., not found)." The first paragraph sounds very much like what we are about. The last suggests that there is an implied media-type for an entire VOSpace that defines the semantics of a space and the syntax of an IVOID fragment pointing into a space...which is _exactly_ how I see it working. Fourthly, I _do_ use the resource keys in IVOIDs to express hierarchy. The resources in the uk.ac.cam.ast namespace are organized that way. Fifthly, I can see that we might sometimes want to add a fragment or a query to the URI for an item in VOSpace. We can't do this if we've used up those parts of the URI syntax to point the thing itself. This strikes me as the strongest argument for dropping the current use of ivo: in VOSpace. Summary: I don't feel the philosophical or legalistic needs to introduce vos:, but I agree that the proposed use of ivo: won't do. Therefore, I propose a different use of ivo:. ivo://org.astrogrid/path/to/vospace!/path/to/data/node#etc?etc In this, the resource key of the data-node in VOSpace includes the resource key of the space itself and there is a stop character ! marking the end of the latter. The ! is part of the space's resource-key; it's not a separator, it doesn't apply to IVOIDs in general and doesn't have to be written into the IVOID spec. The use of ! and the special semantics of the resource key would be part of the VOSpace specification. Sun did similar in defining URIs for use with .jar files. We could put the ! on the front of the data-node path instead of the back of the space's path. But I suspect it's easier to force all VOSpace registrants to use ! correctly than to exclude it from all node names in VOSpace generated by users. Cheers, Guy On Tue, 2 May 2006, Paul Harrison wrote: > Early drafts of the VOSpace (or more accurately VOStore) standard > proposed defining locators for the space by dereferencing using the > "fragment" (#) extension of the IVOA standard identifier scheme ivo: > so for example a reference > > ivo://org.astrogrid/vospace#my/pathto/mydata > > would point to a particular data holding called mydata in a container > called "my/pathto/" on a vospace server the location of which could > be found by looking in the registry entry with identifier "ivo:// > org.astrogrid/vospace" > > For the particular case of VOSpace I would like to propose that > this practice is not followed. I believe that the because VOSpace is > a complete namespace of its own with locator style semantics, it > deserves its own URI scheme. There are the following advantages; > > 1. Client software and humans could immediately recognise that they > had been given a VOSpace URI by trivial inspection of the namespace > prefix, as opposed to having to do at least one dereferencing > operation in the registry to check if the URI does indeed refer to > VOSpace. The example given above could refer to a VOEvent for > instance if someone had been perverse enough to register a voevent > server with an identifier that looked more like a vospace. One of the > aims of VOSpace is to make it easy to share data, and so it should > also be easy to recognise and manipulate the locators for the data. > > 2. A VOSpace specific scheme could more closely follow the general > URI semantics and syntax as laid down in http://www.ietf.org/rfc/ > rfc3986.txt so that they could be manipulated by generic URI parsing > software - i.e. > a) Use the general form that indicates a "/" to be interpreted as > part of a locator hierarchy - it is unfortunate that the ivo: scheme > allows the use of "/" in identifiers when there is no implied > hierarchy in that scheme. > b) Use the "fragment" and "query" parts of the URI directly in a > VOSpace scheme rather than these syntactic constructs having to be > used simply to delimit what belongs to the ivo: scheme and what it > part VOSpace reference. It was an early design aim of VOSpace that it > should be possible to reference parts of the the data objects - e.g. > columns in a VOTable file, and it would be beneficial if the URI > scheme could support this simply and directly. > > With these advantages it remains only to define the VOSpace URL > scheme following the advice in http://www.ietf.org/rfc/rfc2718.txt ; > The general idea would be to have a scheme vos: that had similar > semantics to the http: scheme with general structure > > vos://authority/path?query#fragment > > The authority part is intended to be the ivoa identifier for a > VOSpace server so that the registry would play the same name lookup > service role that DNS typically does with http URLs. The main problem > here is the fact that the IVOA identifiers already use "/" as part of > the identifier which make the direct use of the unaltered IVOA > identifier impossible, as the "/" that was part of the IVOA > identifier would be interpreted as the start of the path part of the > vos: scheme. In this case the "/" needs to be replaced by another > reserved character - preferably without another common meaning (and > in the "discouraged" set of characters in the IVOA identifiers > standard - "!" or "$" would be candidates, so that the original > example above could be represented as > > vos://org.astrogrid!vospace/my/pathto/mydata > > it might even be a good idea to prefix the authority part with a "!" > also to make it clear that the authority should not be interpreted as > an ordinary IP DNS host name representation. > > vos://!org.astrogrid!vospace/my/pathto/mydata > > > Paul Harrison > > > > > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Wed May 3 13:29:52 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k43BTYSI009144 for ; Wed, 3 May 2006 13:29:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k43BTXPp009143 for vospace-outgoing; Wed, 3 May 2006 13:29:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k43BTQSI009108; Wed, 3 May 2006 13:29:26 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id k43BTQ48018951 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 3 May 2006 13:29:26 +0200 In-Reply-To: <0CED72D6-894B-4B82-9CE5-C718F261B474@cacr.caltech.edu> References: <0CED72D6-894B-4B82-9CE5-C718F261B474@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: multipart/alternative; boundary=Apple-Mail-1-844841259 Message-Id: <2E1C1ABD-3FEF-4FDC-BE42-1AF233F54E54@eso.org> Cc: vospace@ivoa.net From: Paul Harrison Subject: Re: VOSpace URIs Date: Wed, 3 May 2006 13:29:25 +0200 To: Roy Williams X-Mailer: Apple Mail (2.749.3) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison --Apple-Mail-1-844841259 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 02.05.2006, at 17:31, Roy Williams wrote: > On May 2, 2006, at 5:10 AM, Paul Harrison wrote: >> Replace this >> ivo://org.astrogrid/vospace#my/pathto/mydata >> with this >> vos://org.astrogrid!vospace/my/pathto/mydata > This makes it look like a simple substitution of a few characters, but there is a world of difference in semantic meaning. There are clear generic parsing rules laid out in http://www.ietf.org/rfc/ rfc3986.txt that the vos: scheme obeys as the rules for a hierarchical locator namespace where the ivo: scheme itself does not, so for instance relative URLs work in the vos scheme, but do not in the ivo: scheme > Paul > > If we add new and subtle semantics to the IVORN syntax, then a lot > of documentation will have to be made over the next years > explaining vos:// and ivo:// and why there are two and how they are > parsed and used. Each VO tutorial for the next 5 years will have to > include 15 minutes on ivo and vos. Future IVOA meetings will need > extra time for this extra syntax/semantics. People will want their > own prefix ("can I use voe:// for VOEvent?"). So this is a big time > commitment and you need *very* good reasons for this. Your reasons > are good, I am not sure they are good *enough*...... I would contend that because the vos: scheme follows the standards for URIs there is less documentation needed as reference can be made to the standard internet rfc document - Having to specify complex rules for interpretation of the fragment or query parts of ivo: URIs for each protocol that wants to have structure within these parts is thus more burdnesome. In addition conformance with the familiar structure of http: URLs will mean that people will understand more about how a vos: URL works without having to read any documentation... > > -- In each case you need to use the registry to get an endpoint > (from ivo://org.astrogrid/vospace or from vos://org.astrogrid), > then you make a service request to that endpoint to get the data. > Is that right? yes, but you do not need to consult a registry to know that vos: is a reference to a VOSpace location - as we are proposing to allow VOSpace to contain soft links this distinction could be useful in future, as it might be possible to point to the results of an OpenSkyQuery for instance. It would then be possible to do certain types of relative VOSpace reference resolution with purely lexical manipulation of the URL. The relationship between the vos: URLs VOSpace servers and ivo: URIs and the registry is analogous to the relationship between http: URLs, web servers and hostnames and DNS resolvers. In a http: URL the authority part (the part between the // and the first / needs to be looked up in a DNS server to actually contact the web server to obtain the data pointed to by the path part of the URL - in a vos: URL, a registry needs to be contacted to > > -- If you want to put a DNS address in (so you don't need to query > the registry), then you could use a normal http prefix without the > effort of making new identifier standards: > http://astrogrid.org/vospace/my/pathto/mydata > > -- You can already assign whatever semantics you wish to the > fragment part. You can have query!path!tablecolumn if you want > without need of building a new identifier syntax. > > -- I think people already know what these ivorns are supposed to > be, they don't need a special prefix. If I made a query for > Conesearches and got some ivorns back, then I know what they should > be because that come from that query. Hey how about a cos:// prefix > for cone searches so I can recognize them? > I recognise that there is a temptation to want to create new URI schemes for everything, but I believe that VOSpace is a special case, as it is supposed to be the place that a data item can be named in a manner independent of any particular properties of the data - a cone search for instance identifies data by specifying properties about the data - and that space has arbitrary structure all of its own - i.e. hierarchical containers. I believe that these two properties of VOSpace combined with the likely need for humans to have to exchange VOSpace URLs mean that it deserves a first class URL system rather than being a dereferenced ivo: scheme... --Apple-Mail-1-844841259 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 02.05.2006, at = 17:31, Roy Williams wrote:

On= May 2, 2006, at 5:10 AM, Paul Harrison wrote:
Replace = this
=A0=A0 = =A0ivo://org.astrogrid/vospace#my/pathto/mydata
with = this
=A0=A0 = =A0vos://org.astrogrid!vospace/my/pathto/mydata

This makes it look like a simple substitution of a = few characters, but there is a world of difference in semantic meaning. = There are clear generic parsing rules laid out in=A0=A0http://www.ietf.org/rfc/rfc39= 86.txt that the vos: scheme obeys as the rules for a hierarchical = locator namespace where the ivo: scheme itself does not, so for instance = relative URLs work in the vos scheme, but do not in the ivo: = scheme

Paul

If we add new and subtle = semantics to the IVORN syntax, then a lot of documentation will have to = be made over the next years explaining vos:// and ivo:// and why there = are two and how they are parsed and used. Each VO tutorial for the next = 5 years will have to include 15 minutes on ivo and vos. Future IVOA = meetings will need extra time for this extra syntax/semantics. People = will want their own prefix ("can I use voe:// for VOEvent?"). So this is = a big time commitment and you need *very* good reasons for this. Your = reasons are good, I am not sure they are good = *enough*......

I would contend that because the = vos: scheme follows the standards for URIs there is less documentation = needed as reference can be made to the standard internet rfc document - = Having to specify complex rules for interpretation of the fragment or = query parts of ivo: URIs for each protocol that wants to have structure = within these parts is thus more burdnesome.=A0In addition conformance = with the familiar structure of=A0 http: URLs will mean that people will = understand more about how a vos: URL works without having to read any = documentation...

=A0

-- = In each case you need to use the registry to get an endpoint = (from=A0ivo://org.astrogrid/vospace or from=A0vos://org.astrogrid), then = you make a service request to that endpoint to get the data. Is that = right?

yes, but you do not=A0 need to = consult a registry to know that vos: is a reference to a VOSpace = location - as we are proposing to allow VOSpace to contain soft links = this distinction could be useful in future, as it might be possible to = point to the results of an OpenSkyQuery for instance. It would then be = possible to do certain types of relative VOSpace reference resolution = with purely lexical manipulation of the URL.

The relationship between = the vos: URLs VOSpace servers and ivo: URIs and the registry is = analogous to the relationship between http: URLs, web servers and = hostnames and DNS resolvers. In a http: URL the authority part (the part = between the // and the first / needs to be looked up in a DNS server to = actually contact the web server to obtain the data pointed to by the = path part of the URL - in a vos: URL, a registry needs to be contacted = to=A0


-- If you want to put a DNS = address in (so you don't need to query the registry), then you could use = a normal http prefix without the effort of making new identifier = standards:

-- You can already assign = whatever semantics you wish to the fragment part. You can have = query!path!tablecolumn if you want without need of building a new = identifier syntax.

-- I think people already = know what these ivorns are supposed to be, they don't need a special = prefix. If I made a query for Conesearches and got some ivorns back, = then I know what they should be because that come from that query. Hey = how about a cos:// prefix for cone searches so I can recognize = them?

I recognise = that there is a temptation to want to create new URI schemes for = everything, but I believe that VOSpace is a special case, as it is = supposed to be the place that=A0 a data item can be named in a manner = independent of any particular properties of the data - a cone search for = instance identifies data by specifying properties about the data - and = that space has arbitrary structure all of its own - i.e. hierarchical = containers. I believe that these two properties of VOSpace combined with = the likely need for humans to have to exchange VOSpace URLs mean that it = deserves a first class URL system rather than being a dereferenced ivo: = scheme...

= --Apple-Mail-1-844841259-- From owner-vospace@eso.org Thu May 4 11:16:06 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k449FnLc002593 for ; Thu, 4 May 2006 11:15:49 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k449FnOU002591 for vospace-outgoing; Thu, 4 May 2006 11:15:49 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k449FgLc002579; Thu, 4 May 2006 11:15:42 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id k449Ff48020472 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 4 May 2006 11:15:41 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ADC89A3-E9A1-4EC0-8AA9-0243E213E063@eso.org> Cc: vospace@ivoa.net Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: VOSpace URIs Date: Thu, 4 May 2006 11:15:40 +0200 To: Guy Rixon X-Mailer: Apple Mail (2.749.3) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 03.05.2006, at 11:16, Guy Rixon wrote: > > Firstly, I'd like to note that when I originally proposed a vos: > scheme > (http://wiki.astrogrid.org/bin/view/AG2/IvoNamesAndLocators) As I remember that page was prompted by an Astrogrid discussion forum argument (unfortunately the forum server no longer exists to reference the discussion) that was raging at the time because of a failure in various layers of the AG software to agree on how to resolve the various interpretations that needed to be placed on ivo: identifier resolution. This was obviously settled in the software, but it did illustrate the point that having schemes that involved multiple dereferencing just to discover even what type of entity was being referenced lead to complex software, and different software engineers had different "natural" interpretations. > > Your proposal isn't independent of the registry. The _client_ has > to resolve a > vos: URI to an ivo: URI and then find the right VOSpace service in the > registry. "Standard URI-parsing software" won't help with this. it would in the specific case of links and relative references - see the reply to Roy. > > Secondly, I'm not sure that your vos: really has "locator-style > semantics". A > vos: URI doesn't point directly to anything concrete that can be > downloaded in > the manner of a web page, and the VOSpace semantics are quite > different to > those of HTTP, FTP etc. I think that it does have locator style semantics - again see reply to Roy - the registry being analogous to DNS with http: > > Thirdly, having re-read RFC3986, I don't see anything illegal in an > IVOID's > use of the query fragment to represent the path into VOSpace. From > the RFC: > > "3.5. Fragment > > The fragment identifier component of a URI allows indirect > identification of a secondary resource by reference to a primary > resource and additional identifying information. The identified > secondary resource may be some portion or subset of the primary > resource, some view on representations of the primary resource, or > some other resource defined or described by those > representations. A > fragment identifier component is indicated by the presence of a > number sign ("#") character and terminated by the end of the URI. > > fragment = *( pchar / "/" / "?" ) > > The semantics of a fragment identifier are defined by the set of > representations that might result from a retrieval action on the > primary resource. The fragment's format and resolution is > therefore > dependent on the media type [RFC2046] of a potentially retrieved > representation, even though such a retrieval is only performed > if the > URI is dereferenced. If no such representation exists, then the > semantics of the fragment are considered unknown and are > effectively > unconstrained. Fragment identifier semantics are independent of > the > URI scheme and thus cannot be redefined by scheme specifications. > > Individual media types may define their own restrictions on or > structures within the fragment identifier syntax for specifying > different types of subsets, views, or external references that are > identifiable as secondary resources by that media type. If the > primary resource has multiple representations, as is often the case > for resources whose representation is selected based on > attributes of > the retrieval request (a.k.a., content negotiation), then > whatever is > identified by the fragment should be consistent across all of those > representations. Each representation should either define the > fragment so that it corresponds to the same secondary resource, > regardless of how it is represented, or should leave the fragment > undefined (i.e., not found)." > > The first paragraph sounds very much like what we are about. The > last suggests > that there is an implied media-type for an entire VOSpace that > defines the > semantics of a space and the syntax of an IVOID fragment pointing into > a space...which is _exactly_ how I see it working. yes - I agree that this updated URI spec does bless indirect referencing for the fragment part, where the earlier RFC2396 had said that it should be explictly a fragment of the document referred to by the path part of the URL - so the use of the ivo: scheme fragment for the vospace reference is "legal", but not simple, and that is my primary argument for wanting to introduce a vos: scheme > > Fourthly, I _do_ use the resource keys in IVOIDs to express > hierarchy. The > resources in the uk.ac.cam.ast namespace are organized that way. well you are not allowed to attach any meaning that can be interpreted by others according to the IVOA ID Spec "Any meaning that is suggested by the resource key is intended only for human consumption. The character content of a resource key is not semantically machine-interpretable. " Additionally the ivo: scheme is not hierarchical in the sense that there is any containment relationship so that for the URI ivo://org.ivoa/operational/siap the operation "contents of" ivo://org.ivoa/operational has no meaning, whereas the equivalent in the vos: scheme would return the list of child URLs. section 2.1.2 of http://www.ietf.org/rfc/rfc2718.txt warns against improper use of // if the path part does not contain a conformant hierarchical structure, and this is the biggest fault in the IVOA ID specification in my opinion. > > Fifthly, I can see that we might sometimes want to add a fragment > or a query > to the URI for an item in VOSpace. We can't do this if we've used > up those > parts of the URI syntax to point the thing itself. This strikes me > as the > strongest argument for dropping the current use of ivo: in VOSpace. I would probably rate this as top amongst the "practical" arguments... > > Summary: I don't feel the philosophical or legalistic needs to > introduce vos:, > but I agree that the proposed use of ivo: won't do. Therefore, I > propose a > different use of ivo:. > > ivo://org.astrogrid/path/to/vospace!/path/to/data/node#etc?etc > > In this, the resource key of the data-node in VOSpace includes the > resource > key of the space itself and there is a stop character ! marking the > end of the > latter. The ! is part of the space's resource-key; it's not a > separator, it > doesn't apply to IVOIDs in general and doesn't have to be written > into the > IVOID spec. The use of ! and the special semantics of the resource > key would > be part of the VOSpace specification. I cannot see how this could be done without changing the IVOID specification - current practice is everything up to the # or ! is part of the resource key, so clients would try to look up ivo:// org.astrogrid/path/to/vospace!/path/to/data/node in the registry and would fail. We could add this to the specification as being a new sort of marker that indicated an indirection should take place and that the rest of the URI be passed on to the service pointed to by the resource key. This would be a useful general facility and could potentially be used for other services where the primary part of the ivo: uri is used to look up an actual service end point in the registry. Whilst changing the IVOA ID specification I would take the opportunity to also do the following to make it follow URI conventions better 1. remove the use of "/" in the authority and resource key sections of the IVOID so that it did not look like a hierarchical URL, but behaves just as an identifier, which was the original intention - to conform with 2.1.2 of http://www.ietf.org/rfc/rfc2718.txt - the authority and resource part could be separated with another reserved character such as $. 2. ban the use of "." in the authority part of the IVOID so that it does not look syntactically like a internet address - section 3.2.2. of http://www.ietf.org/rfc/rfc3986.txt states that if the authority part looks like an internet address then that should be the primary interpretation. so the example might look more like ivo:astrogrid$path$to$vospace!/apath/to/data/node?query#fragment N.B. the convention is that ?query comes before #fragment as ?query is actioned by the service resolving the uri and #fragment by the client. Having said all this I still think that vospace deserves its own uri scheme because the above still does not conform to the standard URL convention of foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment > > Sun did similar in defining URIs for use with .jar files. > > We could put the ! on the front of the data-node path instead of > the back of > the space's path. But I suspect it's easier to force all VOSpace > registrants > to use ! correctly than to exclude it from all node names in > VOSpace generated > by users. > > Cheers, > Guy > From owner-vospace@eso.org Thu May 4 11:51:37 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k449pKLc008327 for ; Thu, 4 May 2006 11:51:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k449pKPo008326 for vospace-outgoing; Thu, 4 May 2006 11:51:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k449pJLc008320; Thu, 4 May 2006 11:51:19 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k449pGxF001902; Thu, 4 May 2006 11:51:16 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:51975) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FbaUA-0002iR-U9 (Exim 4.54) (return-path ); Thu, 04 May 2006 10:51:02 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k449p2SN025808; Thu, 4 May 2006 10:51:02 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k449p2iU018914; Thu, 4 May 2006 10:51:02 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k449p1cp018911; Thu, 4 May 2006 10:51:01 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 4 May 2006 10:51:01 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Paul Harrison cc: vospace@ivoa.net Subject: Re: VOSpace URIs In-Reply-To: <7ADC89A3-E9A1-4EC0-8AA9-0243E213E063@eso.org> Message-ID: References: <7ADC89A3-E9A1-4EC0-8AA9-0243E213E063@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.4.14236 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Paul, yes, you're right of course that my counter-proposal breaks the IVOID rules as they stand. So it can't work without changes to the IVOID standard. (Saw it myself in a dream this morning; it woke me up at 04:00 :-/) I'm reluctant to change the IVOID rules in a way that isn't backwardly compatible, so deprecating the / separator is tricky. Special meaning for ! may be tricky too; I think there are regular IVOIDs in the wild that include that character. Thinking about it a little more clearly, IVOIDs are really locators for resource documents (of course) so assigning a special, VOSpace meaning to the query string is semantically iffy as the query string ought to be evaluated in the registry service. Assigning a meaning to the fragment is maybe OK, as per the later RFC, but the meaning of the fragment really applies to the space itself, not to its resource document (i.e. you can't find out anything about the data node from the resource document). And I still want queries and fragments associated with the data-node itself. So, yes, I now understand it enough to agree with you that we shouldn't mis-use the ivo: scheme and we do need vos:. I agree that the IVOID for the space service should be used as the authority of the vos: URI. However, there's a problem: the IVOID spec requires a / separating the IVO authority-ID from the resource key. In your example with ! as the separator for the IVOID, do you intend to change the IVOID spec to allow ! as separator or is the client expected to swap ! for / when extracting the IVOID? Are you expecteing ever to support an alternate form where an IP number or DNS name replaces the IVOID as the authority? Cheers, Guy On Thu, 4 May 2006, Paul Harrison wrote: > > On 03.05.2006, at 11:16, Guy Rixon wrote: > > > > Firstly, I'd like to note that when I originally proposed a vos: > > scheme > > (http://wiki.astrogrid.org/bin/view/AG2/IvoNamesAndLocators) > > As I remember that page was prompted by an Astrogrid discussion forum > argument (unfortunately the forum server no longer exists to > reference the discussion) that was raging at the time because of a > failure in various layers of the AG software to agree on how to > resolve the various interpretations that needed to be placed on ivo: > identifier resolution. This was obviously settled in the software, > but it did illustrate the point that having schemes that involved > multiple dereferencing just to discover even what type of entity was > being referenced lead to complex software, and different software > engineers had different "natural" interpretations. > > > > > Your proposal isn't independent of the registry. The _client_ has > > to resolve a > > vos: URI to an ivo: URI and then find the right VOSpace service in the > > registry. "Standard URI-parsing software" won't help with this. > > it would in the specific case of links and relative references - see > the reply to Roy. > > > > > Secondly, I'm not sure that your vos: really has "locator-style > > semantics". A > > vos: URI doesn't point directly to anything concrete that can be > > downloaded in > > the manner of a web page, and the VOSpace semantics are quite > > different to > > those of HTTP, FTP etc. > > I think that it does have locator style semantics - again see reply > to Roy - the registry being analogous to DNS with http: > > > > > > Thirdly, having re-read RFC3986, I don't see anything illegal in an > > IVOID's > > use of the query fragment to represent the path into VOSpace. From > > the RFC: > > > > "3.5. Fragment > > > > The fragment identifier component of a URI allows indirect > > identification of a secondary resource by reference to a primary > > resource and additional identifying information. The identified > > secondary resource may be some portion or subset of the primary > > resource, some view on representations of the primary resource, or > > some other resource defined or described by those > > representations. A > > fragment identifier component is indicated by the presence of a > > number sign ("#") character and terminated by the end of the URI. > > > > fragment = *( pchar / "/" / "?" ) > > > > The semantics of a fragment identifier are defined by the set of > > representations that might result from a retrieval action on the > > primary resource. The fragment's format and resolution is > > therefore > > dependent on the media type [RFC2046] of a potentially retrieved > > representation, even though such a retrieval is only performed > > if the > > URI is dereferenced. If no such representation exists, then the > > semantics of the fragment are considered unknown and are > > effectively > > unconstrained. Fragment identifier semantics are independent of > > the > > URI scheme and thus cannot be redefined by scheme specifications. > > > > Individual media types may define their own restrictions on or > > structures within the fragment identifier syntax for specifying > > different types of subsets, views, or external references that are > > identifiable as secondary resources by that media type. If the > > primary resource has multiple representations, as is often the case > > for resources whose representation is selected based on > > attributes of > > the retrieval request (a.k.a., content negotiation), then > > whatever is > > identified by the fragment should be consistent across all of those > > representations. Each representation should either define the > > fragment so that it corresponds to the same secondary resource, > > regardless of how it is represented, or should leave the fragment > > undefined (i.e., not found)." > > > > The first paragraph sounds very much like what we are about. The > > last suggests > > that there is an implied media-type for an entire VOSpace that > > defines the > > semantics of a space and the syntax of an IVOID fragment pointing into > > a space...which is _exactly_ how I see it working. > > yes - I agree that this updated URI spec does bless indirect > referencing for the fragment part, where the earlier RFC2396 had said > that it should be explictly a fragment of the document referred to by > the path part of the URL - so the use of the ivo: scheme fragment > for the vospace reference is "legal", but not simple, and that is my > primary argument for wanting to introduce a vos: scheme > > > > > Fourthly, I _do_ use the resource keys in IVOIDs to express > > hierarchy. The > > resources in the uk.ac.cam.ast namespace are organized that way. > > well you are not allowed to attach any meaning that can be > interpreted by others according to the IVOA ID Spec > > "Any meaning that is suggested by the resource key is intended only > for human consumption. The character content of a resource key is not > semantically machine-interpretable. " > > Additionally the ivo: scheme is not hierarchical in the sense that > there is any containment relationship so that for the URI > > ivo://org.ivoa/operational/siap > > the operation "contents of" ivo://org.ivoa/operational has no > meaning, whereas the equivalent in the vos: scheme would return the > list of child URLs. > > section 2.1.2 of http://www.ietf.org/rfc/rfc2718.txt warns against > improper use of // if the path part does not contain a conformant > hierarchical structure, and this is the biggest fault in the IVOA ID > specification in my opinion. > > > > > Fifthly, I can see that we might sometimes want to add a fragment > > or a query > > to the URI for an item in VOSpace. We can't do this if we've used > > up those > > parts of the URI syntax to point the thing itself. This strikes me > > as the > > strongest argument for dropping the current use of ivo: in VOSpace. > > I would probably rate this as top amongst the "practical" arguments... > > > > > Summary: I don't feel the philosophical or legalistic needs to > > introduce vos:, > > but I agree that the proposed use of ivo: won't do. Therefore, I > > propose a > > different use of ivo:. > > > > ivo://org.astrogrid/path/to/vospace!/path/to/data/node#etc?etc > > > > In this, the resource key of the data-node in VOSpace includes the > > resource > > key of the space itself and there is a stop character ! marking the > > end of the > > latter. The ! is part of the space's resource-key; it's not a > > separator, it > > doesn't apply to IVOIDs in general and doesn't have to be written > > into the > > IVOID spec. The use of ! and the special semantics of the resource > > key would > > be part of the VOSpace specification. > > I cannot see how this could be done without changing the IVOID > specification - current practice is everything up to the # or ! is > part of the resource key, so clients would try to look up ivo:// > org.astrogrid/path/to/vospace!/path/to/data/node in the registry and > would fail. > > We could add this to the specification as being a new sort of marker > that indicated an indirection should take place and that the rest of > the URI be passed on to the service pointed to by the resource key. > This would be a useful general facility and could potentially be used > for other services where the primary part of the ivo: uri is used to > look up an actual service end point in the registry. > > Whilst changing the IVOA ID specification I would take the > opportunity to also do the following to make it follow URI > conventions better > > 1. remove the use of "/" in the authority and resource key sections > of the IVOID so that it did not look like a hierarchical URL, but > behaves just as an identifier, which was the original intention - to > conform with 2.1.2 of http://www.ietf.org/rfc/rfc2718.txt - the > authority and resource part could be separated with another reserved > character such as $. > 2. ban the use of "." in the authority part of the IVOID so that it > does not look syntactically like a internet address - section 3.2.2. > of http://www.ietf.org/rfc/rfc3986.txt states that if the authority > part looks like an internet address then that should be the primary > interpretation. > > so the example might look more like > > ivo:astrogrid$path$to$vospace!/apath/to/data/node?query#fragment > > N.B. the convention is that ?query comes before #fragment as ?query > is actioned by the service resolving the uri and #fragment by the > client. > > Having said all this I still think that vospace deserves its own uri > scheme because the above still does not conform to the standard URL > convention of > > foo://example.com:8042/over/there?name=ferret#nose > \_/ \______________/\_________/ \_________/ \__/ > | | > | | | > scheme authority path > query fragment > > > > > Sun did similar in defining URIs for use with .jar files. > > > > We could put the ! on the front of the data-node path instead of > > the back of > > the space's path. But I suspect it's easier to force all VOSpace > > registrants > > to use ! correctly than to exclude it from all node names in > > VOSpace generated > > by users. > > > > Cheers, > > Guy > > > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Fri May 19 20:28:40 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k4JISUEd029790 for ; Fri, 19 May 2006 20:28:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k4JISUMj029786 for vospace-outgoing; Fri, 19 May 2006 20:28:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k4JISUEd029781 for ; Fri, 19 May 2006 20:28:30 +0200 (MEST) Received: from katrine.roe.ac.uk (katrine.roe.ac.uk [195.194.120.81]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k4JISSQk003959 for ; Fri, 19 May 2006 20:28:29 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost.localdomain [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 8DFA81859E for ; Fri, 19 May 2006 19:28:23 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 25570; Fri, 19 May 2006 19:28:22 +0100 (BST) Received: from katrine (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4FBFA18136 for ; Fri, 19 May 2006 19:28:22 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Fri, 19 May 2006 19:28:22 +0100 (BST) Received: from [127.0.0.1] (katrine.roe.ac.uk [195.194.120.81]) by katrine.roe.ac.uk (Postfix) with ESMTP id AD40A18136 for ; Fri, 19 May 2006 19:28:21 +0100 (BST) Message-ID: <446E0E46.8080005@roe.ac.uk> Date: Fri, 19 May 2006 19:28:22 +0100 From: John Taylor User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: vospace@ivoa.net Subject: VOSpace users Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.19.103108 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: John Taylor Hi Guy et al, My student working on the gridsphere portal _might_ be considered a client of VOSpace, though we'll probably go through the ASR. John From owner-vospace@eso.org Mon Jun 5 17:35:24 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k55FYRGN028423 for ; Mon, 5 Jun 2006 17:34:27 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k55FYRNc028422 for vospace-outgoing; Mon, 5 Jun 2006 17:34:27 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k55FYLGN028377; Mon, 5 Jun 2006 17:34:21 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k55FYJsR014550; Mon, 5 Jun 2006 17:34:19 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:65193) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FnH5m-0005Kw-U0 (Exim 4.54) (return-path ); Mon, 05 Jun 2006 16:34:11 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k55FY6WT014949; Mon, 5 Jun 2006 16:34:07 +0100 (BST) Message-ID: <44844EEE.9040502@ast.cam.ac.uk> Date: Mon, 05 Jun 2006 16:34:06 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list CC: Guy Rixon , Matthew Graham , Paul Harrison Subject: VoSpace WSDL Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.5.75405 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris A proposal for the VoSpace 1.0 service WSDL and XML schema. http://wiki.astrogrid.org/bin/view/Astrogrid/VoSpace20060605 Only a few of the service methods so far, but I'd be interested to see what people think. I'll update the page as I add more of the service methods. Thanks, Dave From owner-vospace@eso.org Fri Jun 9 12:53:21 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k59Aq9cx017212 for ; Fri, 9 Jun 2006 12:52:10 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k59Aq9MK017211 for vospace-outgoing; Fri, 9 Jun 2006 12:52:09 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k59Aq4cx017202 for ; Fri, 9 Jun 2006 12:52:05 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k59Aq3Qk003476 for ; Fri, 9 Jun 2006 12:52:03 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:47713) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1Foeam-00044T-4O (Exim 4.54) (return-path ); Fri, 09 Jun 2006 11:51:53 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k59Apo8T016872; Fri, 9 Jun 2006 11:51:50 +0100 (BST) Message-ID: <448952C6.9030504@ast.cam.ac.uk> Date: Fri, 09 Jun 2006 11:51:50 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: VoSpace WSDL Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.9.25432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris I think I owe Paul an apology. Mistakes on my part meant that I appeared to be submitting my WSDL/schema as the official version, overriding the versions that Paul has been working on. My versions should be considered as experiments only, and we should concentrate on Paul's version. Paul, can you post your latest version on a Wiki and send an email to the list. Thanks, Dave From owner-vospace@eso.org Tue Jun 13 17:40:02 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5DFdHtu016375 for ; Tue, 13 Jun 2006 17:39:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5DFdHsE016374 for vospace-outgoing; Tue, 13 Jun 2006 17:39:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5DFd9tu016350 for ; Tue, 13 Jun 2006 17:39:10 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5DFd948003074 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 13 Jun 2006 17:39:09 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: vospace@ivoa.net From: Paul Harrison Subject: VOSpace WSDL Date: Tue, 13 Jun 2006 17:39:08 +0200 X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison I have posted VOSpace WSDL 1.0 release candidate 1 to the wiki http:// www.ivoa.net/twiki/bin/view/IVOA/VOSpace10schema for discussion - please do! Paul Harrison ESO From owner-vospace@eso.org Tue Jun 13 18:43:03 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5DGgWtu025645 for ; Tue, 13 Jun 2006 18:42:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5DGgWle025644 for vospace-outgoing; Tue, 13 Jun 2006 18:42:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5DGgOtu025627; Tue, 13 Jun 2006 18:42:24 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5DGgLQk006789; Tue, 13 Jun 2006 18:42:22 +0200 (CEST) Received: from [192.168.1.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k5DGg83G030015; Tue, 13 Jun 2006 09:42:09 -0700 Message-ID: <448EEADC.3090801@cacr.caltech.edu> Date: Tue, 13 Jun 2006 09:42:04 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: vospace@ivoa.net Subject: Re: VOSpace WSDL References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.13.85432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Paul Harrison wrote: > I have posted VOSpace WSDL 1.0 release candidate 1 to the wiki http:// > www.ivoa.net/twiki/bin/view/IVOA/VOSpace10schema > for discussion - please do! > > Paul Harrison > ESO > Hi, I notice that your new name suggestions are not in the WSDL - is this intentional? I also have to say that I find that I have to think slightly longer with your name suggestions about who is doing what than the current names so I would rather stick with the current ones (which also do not make a distinction between client/server). Cheers, Matthew From owner-vospace@eso.org Tue Jun 13 18:45:38 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5DGjBtu026103 for ; Tue, 13 Jun 2006 18:45:12 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5DGjBBl026102 for vospace-outgoing; Tue, 13 Jun 2006 18:45:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5DGiUtu026003; Tue, 13 Jun 2006 18:44:31 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5DGiSQk006932; Tue, 13 Jun 2006 18:44:28 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:58913) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqBzn-0007DI-1E (Exim 4.54) (return-path ); Tue, 13 Jun 2006 17:44:04 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5DGi3YP021902; Tue, 13 Jun 2006 17:44:03 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5DGi2R5012155; Tue, 13 Jun 2006 17:44:03 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5DGi2pU012152; Tue, 13 Jun 2006 17:44:02 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 13 Jun 2006 17:44:02 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Paul Harrison cc: vospace@ivoa.net Subject: Re: VOSpace WSDL In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.13.83432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Paul, here are some thoughts on the RC1 WSDL. 1. We'd best be careful about "using up" the namespace URI for the final release in one of the release candidates. Each time we put a file on the wiki we effectively release it, so best to have different namespace URIs for each release candidate and none of them clashing with the final release. 2. Once we finish the WSDL and .xsd, we don't want to change them at any point in the VOSpace-1 series. We might release v1.1 of the standard text with some clarifications, but I'd really like to freeze the schemata. 3. The point above means that we shouldn't have closed enummerations of things that might be extended later. That means particularly things like data-set format & transport protocol, where implementors are allowed to extend, but in general all ennumerations are dangerous. For example, we may find that we want a DELETE permission that is distinct from WRITE, and we may want to allow extra node types. We discussed using URIs to name these things and validating the names in code, not in the schemata; I'd prefer that. 4. In the WSDL, I see that you prefer global elements with encapsulated types over global types. What's the reasoning here? My impression was that global types worked better in data-binding tools. 5. Would it be feasible to refactor all the types from the WSDL into the .xsd? That would allow implementors the greatest choice of data-binding tool and the greatest flexibility in working the SOAP. SOAP-specific tools like WSDL2java shouldn't notice any difference. I recognize the principal of putting in the WSDL those structures that only occur in SOAP messages, but I wonder if that is a practical benefit. I'd prefer to have the definitions where I can get at them with, e.g., XMLbeans. 6. VOSpaceResponse: where do the message and status elements come from? I can't see them in spec for, e.g., deleteNode, for which the response message is a VOSpaceResponse. If we're going to have a VOSpaceResponse (and I'd prefer a named response message for each operation, for symmetry), then it should be an empty type. 7. Case of identifiers: it's a bit mixed at present. Can we standardize on initial capitals or lack thereof for all elements? Don' mind tweaking the spec document to match if we can be consistent in the schemata. 8. You've got a typo for the name of the transferStatus element: missing its third t. 9. What's VOSpaceDescriptor (as distinct from VOSpaceBaseDescriptor) for in the .xsd? It doesn't seem to be used in the WSDL. 10. VOSpace-1 doesn't specify permissions, so we don't really permissions structures in the current schemata. I realize that they aren't used in the WSDL, but I'd prefer to keep them out of the .xsd as well until we've discussed them more. bear in mind that the .xsd for VOSpace-1 may be a full recommendation before we've had time to validate the permissions stuff. Cheers, Guy Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Wed Jun 14 09:54:56 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5E7sXcb011724 for ; Wed, 14 Jun 2006 09:54:33 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5E7sXo8011723 for vospace-outgoing; Wed, 14 Jun 2006 09:54:33 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5E7sScb011714 for ; Wed, 14 Jun 2006 09:54:29 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5E7sSXR002487 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 14 Jun 2006 09:54:28 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <448EEADC.3090801@cacr.caltech.edu> References: <448EEADC.3090801@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46CF6BE1-A2D3-4DB2-B6CF-E4E0F43F824C@eso.org> Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: VOSpace WSDL Date: Wed, 14 Jun 2006 09:54:24 +0200 To: vospace@ivoa.net X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 13.06.2006, at 18:42, Matthew Graham wrote: > Paul Harrison wrote: > >> I have posted VOSpace WSDL 1.0 release candidate 1 to the wiki >> http:// www.ivoa.net/twiki/bin/view/IVOA/VOSpace10schema >> for discussion - please do! >> >> Paul Harrison >> ESO >> > Hi, > > I notice that your new name suggestions are not in the WSDL - is > this intentional? It was, as we had not discussed the issue... > I also have to say that I find that I have to think slightly longer > with your name suggestions about who is doing what than the current > names so I would rather stick with the current ones (which also do > not make a distinction between client/server). not sure I understand this comment, my new suggestions are clear about which is the active party in the transfer and the current names are not. In making this suggestion I am trying to put myself in the position of a newcomer client software writer (who will only have skimmed the documentation before attempting to write his software) His goal is to write code to put some data into VOSpace, so he will look at the list of operations to see which is suitable. With the current names he has to 1. scan down to find "to" or "from" in the middle of the operation name to select which pair is relevant 2. then work out the difference between push and pull - intuitively they might think that they know how they can "push" data as a client, but they are going to wonder how they can "pull to" - they will read the documentation better and realise that is it is the server that does the pulling... with my suggestions I think that this process is easier because it is 1. much easier to see the verb that describes the overall goal 2. explicit about whether it is client or server that is active. > > Cheers, > > Matthew From owner-vospace@eso.org Wed Jun 14 11:28:22 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5E9S7cb018780 for ; Wed, 14 Jun 2006 11:28:07 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5E9S7bG018779 for vospace-outgoing; Wed, 14 Jun 2006 11:28:07 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5E9Rhcb018681; Wed, 14 Jun 2006 11:27:43 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5E9RgXR004804 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 14 Jun 2006 11:27:42 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> Cc: vospace@ivoa.net Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: VOSpace WSDL Date: Wed, 14 Jun 2006 11:27:41 +0200 To: Guy Rixon X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 13.06.2006, at 18:44, Guy Rixon wrote: > Paul, > > here are some thoughts on the RC1 WSDL. > > 1. We'd best be careful about "using up" the namespace URI for the > final > release in one of the release candidates. Each time we put a file > on the wiki > we effectively release it, so best to have different namespace URIs > for each > release candidate and none of them clashing with the final release. I think that the practical advantages of working in the final namespace at this stage outweigh any theoretical idea that we have published something into the namespace, because we have not actually published until the date that we say that the standard is published, and we make no guarantees of interoperability for software using these schema until after that date. Given that I suspect that we will go through quite a few rapid release candidates in the next few weeks, the practical advantages of sticking to the final namespace are than if you have set up code generation, written clients/server depending on a particular namespace it is a bit of a pain to go through changing all the places that references might occur to that particular namespace > > 2. Once we finish the WSDL and .xsd, we don't want to change them > at any point > in the VOSpace-1 series. We might release v1.1 of the standard text > with some > clarifications, but I'd really like to freeze the schemata. agreed, > > 3. The point above means that we shouldn't have closed > enummerations of things > that might be extended later. That means particularly things like > data-set > format & transport protocol, where implementors are allowed to > extend, but > in general all ennumerations are dangerous. For example, we may > find that we > want a DELETE permission that is distinct from WRITE, and we may > want to allow > extra node types. We discussed using URIs to name these things and > validating > the names in code, not in the schemata; I'd prefer that. I share your reservations about the enumerations (the extensibility of which is only a problem because of the peculiarities of XML schema language), but I am also concerned about not having a mechanism for publishing these enumerations in a fashion that code generation tools can use to aid in interoperability. I am also against the use of URIs in many of these cases as they are pretty unnatural cf WRITE and ivo://ivoa.net/vospace/write - the first has a "natural" interpretation and could even be used directly as the string to present to the user when describing the permission where the URI could not. In addition for things like the transport protocol it is far better to use the common well-known name for the protocol e.g. ftp rather than introducing an indirection layer for the name via a URI, so that people can immediately use their domain knowledge to recognise what is being referred to. One compromise could be to have the enumerated lists published in a different namespace, but not use them as types to restrict the values in the formal WSDL. These enumerations could then be updated for a V1.1 release without directly affecting the WSDL contract > > 4. In the WSDL, I see that you prefer global elements with > encapsulated types > over global types. What's the reasoning here? My impression was > that global > types worked better in data-binding tools. The style of the WSDL comes from the original VOStore WSDL, which I believed (though I might be wrong) was a version of the wrapped literal style that was "favoured" by .Net. A goal of the design of this WSDL should be that it produces "natural" interfaces when using as many different code generation tools as possible. My personal experience is pretty much limited to Apache Axis and as such would welcome feedback from people trying different tools. > > 5. Would it be feasible to refactor all the types from the WSDL > into the .xsd? > That would allow implementors the greatest choice of data-binding > tool and the > greatest flexibility in working the SOAP. SOAP-specific tools like > WSDL2java > shouldn't notice any difference. I recognize the principal of > putting in the > WSDL those structures that only occur in SOAP messages, but I > wonder if that > is a practical benefit. I'd prefer to have the definitions where I > can get at > them with, e.g., XMLbeans. I believe that any tool that would help you in creating the actual SOAP messages would always use the WSDL as source - think that as long as you do not use soap encoding this is also true for XMLBeans. I think that I would prefer to put everything in the WSDL file directly rather than make the split if the SOAP message specific parts go into the split file, as remember in wrapped literal there is a "wrapping" layer that the code generation tools typically deal with themselves and do not present at all in the interface that they give the programmer. > > 6. VOSpaceResponse: where do the message and status elements come > from? I > can't see them in spec for, e.g., deleteNode, for which the > response message is a VOSpaceResponse. If we're going to have a > VOSpaceResponse (and I'd prefer a named response message for each > operation, > for symmetry), then it should be an empty type. A deliberate ploy to provoke such a response - I too think that some sort of status message would be more generally useful in other operations - this sort of thing did exist in VOStore, but then got replaced in many operations by a VOSpaceNode as a return value - so yes I think that both a VOSpaceNode and a VOSpaceResponse would be appropriate in many cases - however, I am unclear about what you mean by an empty type... > > 7. Case of identifiers: it's a bit mixed at present. Can we > standardize on > initial capitals or lack thereof for all elements? Don' mind > tweaking the spec > document to match if we can be consistent in the schemata. > 8. You've got a typo for the name of the transferStatus element: > missing its > third t. mea culpa - my java habit of starting instance variables with lower case - I will make consistent > 9. What's VOSpaceDescriptor (as distinct from > VOSpaceBaseDescriptor) for in > the .xsd? It doesn't seem to be used in the WSDL. again left from some earlier experimentation - I will remove. > > 10. VOSpace-1 doesn't specify permissions, so we don't really > permissions > structures in the current schemata. I realize that they aren't used > in the > WSDL, but I'd prefer to keep them out of the .xsd as well until we've > discussed them more. bear in mind that the .xsd for VOSpace-1 may > be a full > recommendation before we've had time to validate the permissions > stuff. It was left there from some experiments... I will remove... From owner-vospace@eso.org Wed Jun 14 12:15:38 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EAFOcb026169 for ; Wed, 14 Jun 2006 12:15:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EAFOdr026168 for vospace-outgoing; Wed, 14 Jun 2006 12:15:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EAFKcb026151 for ; Wed, 14 Jun 2006 12:15:20 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5EAFKXR006006 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 14 Jun 2006 12:15:20 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: vospace@ivoa.net From: Paul Harrison Subject: 1.0rc1 WSDL issues Date: Wed, 14 Jun 2006 12:15:18 +0200 X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison There are some other issues that the WSDL still contains that I am not sure of the current consensus. 1. Callbacks for the data import/export operations. 2. DataObjectReference type contains the idea of a name (expressed as a string) and a container that the Object lives in - I am not sure that this distinction is still needed now that we have some consensus on the vos: URL scheme, as it has built in semantics for expressing a container. 3. DIME transfers - the 0.21 spec mentions a usage of DIME that implies that there should be a specific operation that the files could be attached to, and by implication this operation should be in the interface definition. This was not how I would have envisaged DIME working if we allow it as a transport, as it loses the principal advantage of attachments anyway, i.e. that the HTTP SOAP call with all the necessary data is atomic and synchronous. Would it not be better to say that if DIME is specified as a transport then the data be attached to the pullDataFromVoSpace or pullDataToVoSpace calls themselves? 4. ChangeOwner operation - is this fundamental enough to deserve inclusion? 5. GetPropertyKeys - not in the spec and an idea that I have had basically because I am still a little worried about interoperability problems with the completely untyped nature of the property-key pairs - particularly as they are expected to carry some fundamental metadata about the data objects in the current implementation. This call would return the complete list of key names that have been used in the VOSpace, which would then allow clients to attempt to be consistent in the use of key names - it is not much but at least it does provide a mechanism to voluntarily avoid complete anarchy. 6. Transports/Formats operations - this information could/should in principal be in the Registry entry for VOSpace (we need a registry extension schema also! and quickly - ideally before the v1.0 rollout this summer). Paul. From owner-vospace@eso.org Wed Jun 14 12:18:28 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EAIGcb026631 for ; Wed, 14 Jun 2006 12:18:16 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EAIGwr026630 for vospace-outgoing; Wed, 14 Jun 2006 12:18:16 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EAIAcb026609; Wed, 14 Jun 2006 12:18:10 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EAI7Qk004224; Wed, 14 Jun 2006 12:18:07 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:39641) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqSRW-0000cB-1m (Exim 4.54) (return-path ); Wed, 14 Jun 2006 11:17:46 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EAHkM8024968; Wed, 14 Jun 2006 11:17:46 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EAHkIG016075; Wed, 14 Jun 2006 11:17:46 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5EAHjY4016072; Wed, 14 Jun 2006 11:17:46 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 14 Jun 2006 11:17:45 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Paul Harrison cc: vospace@ivoa.net Subject: Re: VOSpace WSDL In-Reply-To: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> Message-ID: References: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.25432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon On Wed, 14 Jun 2006, Paul Harrison wrote: > > On 13.06.2006, at 18:44, Guy Rixon wrote: > > > 1. We'd best be careful about "using up" the namespace URI for the > > final > > release in one of the release candidates. Each time we put a file > > on the wiki > > we effectively release it, so best to have different namespace URIs > > for each > > release candidate and none of them clashing with the final release. > > I think that the practical advantages of working in the final > namespace at this stage outweigh any theoretical idea that we have > published something into the namespace, because we have not actually > published until the date that we say that the standard is published, > and we make no guarantees of interoperability for software using > these schema until after that date. > > Given that I suspect that we will go through quite a few rapid > release candidates in the next few weeks, the practical advantages of > sticking to the final namespace are than if you have set up code > generation, written clients/server depending on a particular > namespace it is a bit of a pain to go through changing all the places > that references might occur to that particular namespace I disagree with this most strongly. > > > > > 2. Once we finish the WSDL and .xsd, we don't want to change them > > at any point > > in the VOSpace-1 series. We might release v1.1 of the standard text > > with some > > clarifications, but I'd really like to freeze the schemata. > > agreed, > > > > 3. The point above means that we shouldn't have closed > > enummerations of things > > that might be extended later. That means particularly things like > > data-set > > format & transport protocol, where implementors are allowed to > > extend, but > > in general all ennumerations are dangerous. For example, we may > > find that we > > want a DELETE permission that is distinct from WRITE, and we may > > want to allow > > extra node types. We discussed using URIs to name these things and > > validating > > the names in code, not in the schemata; I'd prefer that. > > I share your reservations about the enumerations (the extensibility > of which is only a problem because of the peculiarities of XML schema > language), but I am also concerned about not having a mechanism for > publishing these enumerations in a fashion that code generation tools > can use to aid in interoperability. > > I am also against the use of URIs in many of these cases as they are > pretty unnatural cf WRITE and ivo://ivoa.net/vospace/write - the > first has a "natural" interpretation and could even be used directly > as the string to present to the user when describing the permission > where the URI could not. In addition for things like the transport > protocol it is far better to use the common well-known name for the > protocol e.g. ftp rather than introducing an indirection layer for > the name via a URI, so that people can immediately use their domain > knowledge to recognise what is being referred to. > > One compromise could be to have the enumerated lists published in a > different namespace, but not use them as types to restrict the values > in the formal WSDL. These enumerations could then be updated for a > V1.1 release without directly affecting the WSDL contract The distinction is between closed lists, which can only be extended by reissuing the spec and schemata, and open lists which can be extended by implementors and/or users. Transport protocol is clearly open; permissions could be closed; the others are less clear. The point is, if we close a list and then extend it, we replace the schema with a new one. That means that _everybody_ then has to support both old and new schemata even if they don't want to support the new feature. Changing schemata is merely annoying when we have to do it in protoypes, but it's disasterous in the wider IVO. > > > > 4. In the WSDL, I see that you prefer global elements with > > encapsulated types > > over global types. What's the reasoning here? My impression was > > that global > > types worked better in data-binding tools. > > The style of the WSDL comes from the original VOStore WSDL, which I > believed (though I might be wrong) was a version of the wrapped > literal style that was "favoured" by .Net. A goal of the design of > this WSDL should be that it produces "natural" interfaces when using > as many different code generation tools as possible. My personal > experience is pretty much limited to Apache Axis and as such would > welcome feedback from people trying different tools. So what are the requirements for "wrapped"? AFAIK, it's only that the SOAP body contain a single child element that is named after the operation. If we do that in WSDL, does it matter whether we use global types or global elements? (Any .NET users care to comment?) > > > > > 5. Would it be feasible to refactor all the types from the WSDL > > into the .xsd? > > That would allow implementors the greatest choice of data-binding > > tool and the > > greatest flexibility in working the SOAP. SOAP-specific tools like > > WSDL2java > > shouldn't notice any difference. I recognize the principal of > > putting in the > > WSDL those structures that only occur in SOAP messages, but I > > wonder if that > > is a practical benefit. I'd prefer to have the definitions where I > > can get at > > them with, e.g., XMLbeans. > > I believe that any tool that would help you in creating the actual > SOAP messages would always use the WSDL as source - think that as > long as you do not use soap encoding this is also true for XMLBeans. > I think that I would prefer to put everything in the WSDL file > directly rather than make the split if the SOAP message specific > parts go into the split file, as remember in wrapped literal there is > a "wrapping" layer that the code generation tools typically deal with > themselves and do not present at all in the interface that they give > the programmer. > > > > > 6. VOSpaceResponse: where do the message and status elements come > > from? I > > can't see them in spec for, e.g., deleteNode, for which the > > response message is a VOSpaceResponse. If we're going to have a > > VOSpaceResponse (and I'd prefer a named response message for each > > operation, > > for symmetry), then it should be an empty type. > A deliberate ploy to provoke such a response - I too think that some > sort of status message would be more generally useful in other > operations - this sort of thing did exist in VOStore, but then got > replaced in many operations by a VOSpaceNode as a return value - so > yes I think that both a VOSpaceNode and a VOSpaceResponse would be > appropriate in many cases - however, I am unclear about what you mean > by an empty type... Empty type instantiated like this and enforced to be that way in schema: written as a xsd:ComplexType with no children IIRC. > > > > 7. Case of identifiers: it's a bit mixed at present. Can we > > standardize on > > initial capitals or lack thereof for all elements? Don' mind > > tweaking the spec > > document to match if we can be consistent in the schemata. > > 8. You've got a typo for the name of the transferStatus element: > > missing its > > third t. > mea culpa - my java habit of starting instance variables with lower > case - I will make consistent > > 9. What's VOSpaceDescriptor (as distinct from > > VOSpaceBaseDescriptor) for in > > the .xsd? It doesn't seem to be used in the WSDL. > again left from some earlier experimentation - I will remove. > > > > 10. VOSpace-1 doesn't specify permissions, so we don't really > > permissions > > structures in the current schemata. I realize that they aren't used > > in the > > WSDL, but I'd prefer to keep them out of the .xsd as well until we've > > discussed them more. bear in mind that the .xsd for VOSpace-1 may > > be a full > > recommendation before we've had time to validate the permissions > > stuff. > > It was left there from some experiments... I will remove... > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Wed Jun 14 12:28:37 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EASOcb028040 for ; Wed, 14 Jun 2006 12:28:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EASOmn028039 for vospace-outgoing; Wed, 14 Jun 2006 12:28:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EASIcb028029; Wed, 14 Jun 2006 12:28:19 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EASGQk004849; Wed, 14 Jun 2006 12:28:16 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:40354) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqSb7-0008If-1J (Exim 4.54) (return-path ); Wed, 14 Jun 2006 11:27:41 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EARfX9025553; Wed, 14 Jun 2006 11:27:41 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EARfp7016126; Wed, 14 Jun 2006 11:27:41 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5EARetx016123; Wed, 14 Jun 2006 11:27:40 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 14 Jun 2006 11:27:40 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Paul Harrison cc: vospace@ivoa.net Subject: Re: 1.0rc1 WSDL issues In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.25432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon On Wed, 14 Jun 2006, Paul Harrison wrote: > There are some other issues that the WSDL still contains that I am > not sure of the current consensus. > > > 1. Callbacks for the data import/export operations. Wasn't this to be deferred until VOSpace-2? > 2. DataObjectReference type contains the idea of a name (expressed as > a string) and a container that the Object lives in - I am not sure > that this distinction is still needed now that we have some consensus > on the vos: URL scheme, as it has built in semantics for expressing a > container. I agree that it's unnecessary structure. Just a vos: URI will do. > 3. DIME transfers - the 0.21 spec mentions a usage of DIME that > implies that there should be a specific operation that the files > could be attached to, and by implication this operation should be in > the interface definition. This was not how I would have envisaged > DIME working if we allow it as a transport, as it loses the principal > advantage of attachments anyway, i.e. that the HTTP SOAP call with > all the necessary data is atomic and synchronous. Would it not be > better to say that if DIME is specified as a transport then the data > be attached to the pullDataFromVoSpace or pullDataToVoSpace calls > themselves? > 4. ChangeOwner operation - is this fundamental enough to deserve > inclusion? Do we really need it for VOSpace-1? > 5. GetPropertyKeys - not in the spec and an idea that I have had > basically because I am still a little worried about interoperability > problems with the completely untyped nature of the property-key pairs > - particularly as they are expected to carry some fundamental > metadata about the data objects in the current implementation. This > call would return the complete list of key names that have been used > in the VOSpace, which would then allow clients to attempt to be > consistent in the use of key names - it is not much but at least it > does provide a mechanism to voluntarily avoid complete anarchy. I'd support this. It's useful for management. > 6. Transports/Formats operations - this information could/should in > principal be in the Registry entry for VOSpace (we need a registry > extension schema also! and quickly - ideally before the v1.0 rollout > this summer). I would be happy for the transports and formats to be listed only in the registration. Will NVO accept this for VOSpace? However, there's a significant distinction lurking: can a space support diffferent transfer protocols for different nodes? If so, then there must be some negotiation operations on the service. E.g., make the requested protocol for a transfer a list of protocols that the client will accept (in order of preference) and let the service fault if it can't do any of them. > Paul. > > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Wed Jun 14 12:37:10 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EAascb029256 for ; Wed, 14 Jun 2006 12:36:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EAarpK029255 for vospace-outgoing; Wed, 14 Jun 2006 12:36:53 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EAamcb029245; Wed, 14 Jun 2006 12:36:48 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EAakQk005411; Wed, 14 Jun 2006 12:36:46 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:40919) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqSj7-0000iD-1c (Exim 4.54) (return-path ); Wed, 14 Jun 2006 11:35:57 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EAZvjG026014; Wed, 14 Jun 2006 11:35:57 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EAZvHZ016246; Wed, 14 Jun 2006 11:35:57 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5EAZvmU016243; Wed, 14 Jun 2006 11:35:57 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 14 Jun 2006 11:35:56 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Paul Harrison cc: vospace@ivoa.net Subject: Re: 1.0rc1 WSDL issues In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.25432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Actually, I suspect that writing the supported protocols in the registry doesn't work cleanly with linked spaces. Suppose I have a reference to vos://foo/a/b/c which is actually a link to vos://bar:/x/y/z. Until I operate on vos://foo/a/c I don't know that it's a link, so I only see properties registered for the foo space. Suppose that foo and bar support different transports: my request to foo for a gsiftp transfer isn't valid on bar and get a fault. However, it gets a fault anyway because of the link and then I have to talk to bar to et at the data. So...if I have to resolve bar's registration to find the data, I can modify my request to use a different protocol, and it works in implementation. But the foo space is effectively lying about the transfer capability of some of its nodes. Does this matter? Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Wed Jun 14 13:37:02 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EBagcb007542 for ; Wed, 14 Jun 2006 13:36:42 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EBagLq007541 for vospace-outgoing; Wed, 14 Jun 2006 13:36:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EBaXcb007522 for ; Wed, 14 Jun 2006 13:36:34 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EBaVQk008987 for ; Wed, 14 Jun 2006 13:36:31 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:45702) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqTf3-0005uE-2h (Exim 4.54) (return-path ); Wed, 14 Jun 2006 12:35:49 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EBZli0029942; Wed, 14 Jun 2006 12:35:47 +0100 (BST) Message-ID: <448FF493.7040402@ast.cam.ac.uk> Date: Wed, 14 Jun 2006 12:35:47 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: VOSpace WSDL References: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> In-Reply-To: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.33432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > I am also against the use of URIs in many of these cases .... for > things like the transport protocol it is far better to use the common > well-known name for the protocol e.g. ftp rather than introducing an > indirection layer for the name via a URI, so that people can > immediately use their domain knowledge to recognise what is being > referred to. The 'http put' transfer is a good example of why the specification uses URI rather than just the 'well-known names' for protocols. There are several ways to send data using HTTP. The two main forms are : http-put http-post Based on our experience with VOStore and AstroGrid MySpace, we also need to distinguish between services that can accept chunked data in a http-put call. A standard http-put call sends the data size in the header, which means that the client has to buffer all of the content to calculate the size before it sends the data. Sending data using http-put in chunked mode does not require the data size in the header field. However, not all server implementations can accept chunked data (even though they claim to implement HTTP-1.1), so we need to be able to distinguish between services that can accept chunked data, which gives us three variants of http-put. http-post http-put http-put (chunked) We may also need to distinguish between services that accept http-put with data compression (zip, gzip etc.) and different forms of authentication. If we used the 'well know name' for protocols, all of the above could be covered by 'http'. DIME and MTOM attachments also have two main variants. The data can be attached to the original VOSpace message, which would not require a separate URL to send the data to. dime-put (this message) Or, it could be sent in a separate SOAP message, which would require information about the target service, the endpoint URL and some form of identifier. dime-put (other) +wsdl, endpoint, ident There may be other forms which 3rd party developers want to add; all based on the core http protocol, but using different data handling and authentication methods. The reason for identifying these using a URI, particularly an ivo://... registry URI is that it gives us somewhere to put a description of the protocol. For example : http://galahad.star.le.ac.uk:8080/astrogrid-registry/viewResourceEntry.jsp?IVORN=ivo%3A%2F%2Forg.astrogrid.vospace%2Fprotocols%2Fhttp-put http://galahad.star.le.ac.uk:8080/astrogrid-registry/viewResourceEntry.jsp?IVORN=ivo%3A%2F%2Forg.astrogrid.vospace%2Fprotocols%2Fhttp-put-chunked I appreciate that using registry resources to describe the protocols is contentious, which is why the specification defines protocol and format parameters as a URI and not an IVOA registry URI. If people don't want to use IVOA registry URIs, then we could use the http URL of the protocol specification. If someone wants to use a different form of DIME web service to receive data, then the URI could point to the service specification or WSDL. The point is that in much the same way as people use namespace URIs in XML schema, the protocol URI is not just a text string, it can be used to point to something that describes the specific protocol. This was discussed both before and during the Canada meeting, and no major objections were raised at the time. Which is why the v0.21 document specifies protocol and format as URI, with examples of IVOA registry URIs. If you want to change this to an enumeration of strings, then we need to go back and modify the document. > One compromise could be to have the enumerated lists published in a > different namespace, but not use them as types to restrict the values > in the formal WSDL. These enumerations could then be updated for a > V1.1 release without directly affecting the WSDL contract I agree, an initial list of the core protocols and formats could be useful. However, the values should be URIs, and the documentation should make it clear that this is not a closed or mandatory list. 3rd party developers should be required to implement all of the protocols in the list. 3rd party developers should be free to add additional transport protocols and data formats without requiring a change to the specification. Which protocols actually go in the initial list is open for discussion .... Dave From owner-vospace@eso.org Wed Jun 14 13:53:18 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EBr1cb010093 for ; Wed, 14 Jun 2006 13:53:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EBr1wC010092 for vospace-outgoing; Wed, 14 Jun 2006 13:53:01 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EBqrcb010075 for ; Wed, 14 Jun 2006 13:52:53 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EBqnQk010001 for ; Wed, 14 Jun 2006 13:52:49 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:47715) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqTvL-00013A-12 (Exim 4.54) (return-path ); Wed, 14 Jun 2006 12:52:39 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EBqbFm001598; Wed, 14 Jun 2006 12:52:37 +0100 (BST) Message-ID: <448FF885.5060901@ast.cam.ac.uk> Date: Wed, 14 Jun 2006 12:52:37 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.35433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > 1. Callbacks for the data import/export operations. Definitely v2.x This implies asynchronous transfers, which we have not defined in enough detail yet. Dave From owner-vospace@eso.org Wed Jun 14 14:02:09 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EC1kcb011534 for ; Wed, 14 Jun 2006 14:01:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EC1k62011533 for vospace-outgoing; Wed, 14 Jun 2006 14:01:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EC1fcb011518 for ; Wed, 14 Jun 2006 14:01:41 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EC1dQk010668 for ; Wed, 14 Jun 2006 14:01:39 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:48395) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqU3n-0000le-1G (Exim 4.54) (return-path ); Wed, 14 Jun 2006 13:01:23 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EC1LEr002185; Wed, 14 Jun 2006 13:01:21 +0100 (BST) Message-ID: <448FFA91.6010703@ast.cam.ac.uk> Date: Wed, 14 Jun 2006 13:01:21 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.43432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > 2. DataObjectReference type contains the idea of a name (expressed as > a string) and a container that the Object lives in - I am not sure > that this distinction is still needed now that we have some consensus > on the vos: URL scheme, as it has built in semantics for expressing a > container. The original definition for a node did have both the name and the URI. The reason was that the URI would be encoded (space = %20 etc.), and the unencoded name was provided to make things easier to display things in a UI. Having talked with UI developers at Canada, it was decided that providing the name as a plain string was duplicating data and wasn't required anyway. So, server responses do not need to include the name, just the URI. However, when creating a new node, it was agreed that the client would supply the name as a plain text string, and the server would convert this into the URI encoded identifier. This means that the server side code does the URI encoding, making it easier to verify that we get it right. The operations that create a new node (CreateNode, PushDataTo and PullDataTo) take the name of the new node, not the identifier. This gives us a way of distinguishing between import into an existing node (node URI) and import into a new node (node name). The distinction still isn't as clear as I would like, but that is what is in the current document. If we want to change this, then we will need to modify the document. Dave From owner-vospace@eso.org Wed Jun 14 14:47:03 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EChvcb018582 for ; Wed, 14 Jun 2006 14:43:57 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EChvEV018579 for vospace-outgoing; Wed, 14 Jun 2006 14:43:57 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EChZcb018523; Wed, 14 Jun 2006 14:43:36 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5EChZ48003420 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 14 Jun 2006 14:43:35 +0200 In-Reply-To: <448FF493.7040402@ast.cam.ac.uk> References: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> <448FF493.7040402@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: VOSpace WSDL Date: Wed, 14 Jun 2006 14:43:31 +0200 To: Dave Morris X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 14.06.2006, at 13:35, Dave Morris wrote: > Paul Harrison wrote: > >> I am also against the use of URIs in many of these cases .... for >> things like the transport protocol it is far better to use the >> common well-known name for the protocol e.g. ftp rather than >> introducing an indirection layer for the name via a URI, so that >> people can immediately use their domain knowledge to recognise >> what is being referred to. > > The 'http put' transfer is a good example of why the specification > uses URI rather than just the 'well-known names' for protocols. > There are several ways to send data using HTTP. > The two main forms are : > > http-put > http-post > > Based on our experience with VOStore and AstroGrid MySpace, we also > need to distinguish between services that can accept chunked data > in a http-put call. > A standard http-put call sends the data size in the header, which > means that the client has to buffer all of the content to calculate > the size before it sends the data. > Sending data using http-put in chunked mode does not require the > data size in the header field. > However, not all server implementations can accept chunked data > (even though they claim to implement HTTP-1.1), so we need to be > able to distinguish between services that can accept chunked data, > which gives us three variants of http-put. > > http-post > http-put > http-put (chunked) > all of these should be supported to qualify for being a http1.1 transport - to my way of thinking unless it supports everything it is not compliant. A web browser talks "http" - it is a client configuration that allows it to try for specialized features and the the protocol itself has flags to say which version is being used. > We may also need to distinguish between services that accept http- > put with data compression (zip, gzip etc.) and different forms of > authentication. > If we used the 'well know name' for protocols, all of the above > could be covered by 'http'. > DIME and MTOM attachments also have two main variants. > The data can be attached to the original VOSpace message, which > would not require a separate URL to send the data to. > > dime-put (this message) > > Or, it could be sent in a separate SOAP message, which would > require information about the target service, the endpoint URL and > some form of identifier. > > dime-put (other) +wsdl, endpoint, ident This second is a web service in itself - it would need an entire IVOA standard to cover it, and what's more I cannot really see a good use case for it. > > There may be other forms which 3rd party developers want to add; > all based on the core http protocol, but using different data > handling and authentication methods. This could go on ad absurdam - each implementor could find a list of areas where his server does not follow the HTTP standards properly, or wants some other variation and invents a new "Transport" and we end up in the situation where VOSpaces cannot transfer data between each other because they have no transports in common - we have to specify a base set. We do not want a situation where the VOSpace 1.0 standard is so open-ended that two people can implement a server that is compliant with the standard, but cannot interoperate. The core of the standard needs to enforce some aspects, as we know from experience with other IVOA standards, that when writing clients that talk to several services, the only practical approach is to rely on only the mandatory parts of the standard, because that is all that the majority of services will have implemented, no matter how appealing/useful some of the optional parts are. > The reason for identifying these using a URI, particularly an > ivo://... registry URI is that it gives us somewhere to put a > description of the protocol. > > For example : > http://galahad.star.le.ac.uk:8080/astrogrid-registry/ > viewResourceEntry.jsp?IVORN=ivo%3A%2F%2Forg.astrogrid.vospace% > 2Fprotocols%2Fhttp-put > http://galahad.star.le.ac.uk:8080/astrogrid-registry/ > viewResourceEntry.jsp?IVORN=ivo%3A%2F%2Forg.astrogrid.vospace% > 2Fprotocols%2Fhttp-put-chunked > > I appreciate that using registry resources to describe the > protocols is contentious, which is why the specification defines > protocol and format parameters as a URI and not an IVOA registry URI. > If people don't want to use IVOA registry URIs, then we could use > the http URL of the protocol specification. > If someone wants to use a different form of DIME web service to > receive data, then the URI could point to the service specification > or WSDL. > The point is that in much the same way as people use namespace URIs > in XML schema, the protocol URI is not just a text string, it can > be used to point to something that describes the specific protocol. well I did not see you rigorously using URIs in your comments about http-put etc. above - it is not natural. In general I am in favour of using registry entries to describe something that could possibly be machine understood and interpreted, so if you can come up with a registry entry that could describe an arbitrary transport protocol I would support mandating that the transport name be a URI, otherwise a simple string name is sufficient. I think that mandating that http be a supported protocol (and defining what exactly we mean by that) would not be too burdensome on implementations. > > This was discussed both before and during the Canada meeting, and > no major objections were raised at the time. In the jabber I had with you before Canada I raised exactly these objections... > Which is why the v0.21 document specifies protocol and format as > URI, with examples of IVOA registry URIs. > If you want to change this to an enumeration of strings, then we > need to go back and modify the document. we have to modify the document anyway - there are lots more issues... From owner-vospace@eso.org Wed Jun 14 14:47:49 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5ECijcb018724 for ; Wed, 14 Jun 2006 14:44:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5ECijGk018721 for vospace-outgoing; Wed, 14 Jun 2006 14:44:45 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5ECiScb018691 for ; Wed, 14 Jun 2006 14:44:29 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5ECiQQk014039 for ; Wed, 14 Jun 2006 14:44:27 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:50953) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1FqUj8-0007bX-5I (Exim 4.54) (return-path ); Wed, 14 Jun 2006 13:44:08 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5ECi4Xc004534; Wed, 14 Jun 2006 13:44:04 +0100 (BST) Message-ID: <44900494.5010405@ast.cam.ac.uk> Date: Wed, 14 Jun 2006 13:44:04 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.45433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > 3. DIME transfers - the 0.21 spec mentions a usage of DIME that > implies that there should be a specific operation that the files > could be attached to, and by implication this operation should be in > the interface definition. This was not how I would have envisaged > DIME working if we allow it as a transport, as it loses the principal > advantage of attachments anyway, i.e. that the HTTP SOAP call with > all the necessary data is atomic and synchronous. Would it not be > better to say that if DIME is specified as a transport then the data > be attached to the pullDataFromVoSpace or pullDataToVoSpace calls > themselves? I agree, we should have both, plus leave it open to include others in the future. Initially, there are two ways that we could use DIME and MTOM attachments. The first is to send the data as an attachment to the VOSpace message or response, as you describe above. The second is to send the data via a separate SOAP message (I know, not optimal, but there may be cases where this makes sense). This requires details of the receiving web service, the WSDL, the endpoint, and possibly some form of service specific identifier. An example of this would be the original VOStore get and put methods we demonstrated at ADASS. We can distinguish between the different forms by defining different a protocol URI for each one. ivo://...../vospace.01.00.dime.put This VOSpace protocol sends the data to the target service as a DIME attachment to the PullDataToVoSpace method. To use this transfer method, the element should be set to this URI, and the element is empty (the data is already attached to the SOAP message). ivo://...../vospace.01.00.dime.get This VOSpace protocol sends the data to the client as a DIME attachment to the PushDataFromVoSpace method. To use this transfer method, the element should be set to this URI, and the element is empty (the data will be attached to the SOAP response). ivo://...../vostore.01.00.dime.get This VOSpace protocol gets the data from a separate web service that supports the original VOStore get method. To use this transfer method, the element should be set to this URI, and the element should be set to the endpoint of the target web service. Note - this may need an additional element in the VOSpace message to supply some form of path or identifier to specify what data to get from the target service. ivo://...../vostore.01.00.dime.put This VOSpace protocol sends the data to a separate web service that supports the original VOStore put method. To use this transfer method, the element should be set to this URI, and the element should be set to the endpoint of the target web service. Note - this may need an additional element in the VOSpace message to supply some form of path or identifier to specify where to put the data within the target service. ivo://...../other.project.dime.get This VOSpace protocol gets the data from a separate web service that supports . To use this transfer method, the element should be set to this URI, and the element should be set to the endpoint of the target web service. Note - this may need an additional element in the VOSpace message to supply some form of identifier. Using a different protocol URI for each of the different forms means that all of these can be listed in the capabilities of the particular VOSpace service. The first two (attaching the data to the VOSpace messages) means we have a simple way to implement DIME get and put for a VOSpace service. However, it does not mandate this as the only way of using DIME and MTOM, leaving things open for others to provide different web service interfaces is they want. If a different Grid project already have their own DIME or MTOM implementation, if they add a new protocol URI that describes their interface, we can create VOSpace clients that can send and receive data from their services too. Note that the indirect forms of DIME get and put may need an additional element in the VOSpace message to supply some form of identifier. Could we handle this by defining the or elements as a ComplexType, and then using xsi:type to replace it with extended forms when the protocol requires it. Another example of this would be FTP or HTTP transfers with unusual authentication methods may need separate name and password elements if they can't be encoded in the URL. A service should only receive messages with the extended type if they have listed that particular protocol in their capabilities. If the protocol isn't listed in the service capabilities, then it should reject the message anyway. Dave From owner-vospace@eso.org Wed Jun 14 15:05:25 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5ED56cb021793 for ; Wed, 14 Jun 2006 15:05:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5ED56im021789 for vospace-outgoing; Wed, 14 Jun 2006 15:05:06 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5ED4vcb021745 for ; Wed, 14 Jun 2006 15:04:58 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5ED4tQk015997 for ; Wed, 14 Jun 2006 15:04:56 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:52365) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1FqV35-0007jp-3Q (Exim 4.54) (return-path ); Wed, 14 Jun 2006 14:04:44 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5ED4fhm005928; Wed, 14 Jun 2006 14:04:41 +0100 (BST) Message-ID: <44900969.3020502@ast.cam.ac.uk> Date: Wed, 14 Jun 2006 14:04:41 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: VOSpace WSDL References: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> <448FF493.7040402@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.53433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > On 14.06.2006, at 13:35, Dave Morris wrote: > >> Based on our experience with VOStore and AstroGrid MySpace, we also >> need to distinguish between services that can accept chunked data in >> a http-put call. >> A standard http-put call sends the data size in the header, which >> means that the client has to buffer all of the content to calculate >> the size before it sends the data. >> Sending data using http-put in chunked mode does not require the >> data size in the header field. >> However, not all server implementations can accept chunked data >> (even though they claim to implement HTTP-1.1), so we need to be >> able to distinguish between services that can accept chunked data, >> which gives us three variants of http-put. > > all of these should be supported to qualify for being a http1.1 > transport - to my way of thinking unless it supports everything it is > not compliant. A web browser talks "http" - it is a client > configuration that allows it to try for specialized features and the > the protocol itself has flags to say which version is being used. The core Java HttpURLConnection in JDK 1.4.x does not support sending chunked data, which is what is causing some of the OutOfMemory errors in the AstroGrid MySpace clients. The client tries to buffer all of the data to calculate the content-size header before it sends anything. Support for chunked data was only added in JDK 1.5. http://java.sun.com/j2se/1.5.0/docs/api/java/net/HttpURLConnection.html#setChunkedStreamingMode(int) From our experience with AstroGrid MySpace, a standard servlet running in Apache Tomcat on JDK-1.4.2 does not accept chunked data properly either. This is why I need to distinguish between them. The problems with HTTP-1.1 and chunked data in Java is only one example of this. There may be others, which is why I'd rather we had a generic solution for specifying the details of the transfer protocol rather than a specific fix for this problem. Dave From owner-vospace@eso.org Wed Jun 14 15:11:11 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EDAocb022883 for ; Wed, 14 Jun 2006 15:10:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5ED8GS4022406 for vospace-outgoing; Wed, 14 Jun 2006 15:08:16 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5ED7Wcb022217 for ; Wed, 14 Jun 2006 15:07:32 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5ED7UQk016343 for ; Wed, 14 Jun 2006 15:07:30 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:52549) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1FqV4r-0000sw-3v (Exim 4.54) (return-path ); Wed, 14 Jun 2006 14:06:33 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5ED6Txo006071; Wed, 14 Jun 2006 14:06:29 +0100 (BST) Message-ID: <449009D5.3050302@ast.cam.ac.uk> Date: Wed, 14 Jun 2006 14:06:29 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: VOSpace WSDL References: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> <448FF493.7040402@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.45433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > On 14.06.2006, at 13:35, Dave Morris wrote: > >> Or, it could be sent in a separate SOAP message, which would require >> information about the target service, the endpoint URL and some form >> of identifier. >> >> dime-put (other) +wsdl, endpoint, ident > > > This second is a web service in itself - it would need an entire IVOA > standard to cover it It would need _a_ specification, not necessarily IVOA. If a 3rd party Grid project already had one defined, then we might want to be able to send and receive data from their services too. > , and what's more I cannot really see a good use case for it. I don't see a good reason for explicitly excluding it. One use case would be for an external service (not part of the VOSpace service itself) that stored sensitive data. DIME or MTOM with XML signatures would work well for authenticating access. Dave From owner-vospace@eso.org Wed Jun 14 15:33:23 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EDX5cb026320 for ; Wed, 14 Jun 2006 15:33:05 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EDX5Zf026318 for vospace-outgoing; Wed, 14 Jun 2006 15:33:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EDWpcb026289 for ; Wed, 14 Jun 2006 15:32:56 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5EDWp48004655 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 14 Jun 2006 15:32:51 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <448FF885.5060901@ast.cam.ac.uk> References: <448FF885.5060901@ast.cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <07415963-4B65-4A24-930B-6D1810C85559@eso.org> Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues Date: Wed, 14 Jun 2006 15:32:49 +0200 To: IVOA mailing list VoSpace X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 14.06.2006, at 13:52, Dave Morris wrote: > Paul Harrison wrote: > >> 1. Callbacks for the data import/export operations. > > Definitely v2.x > This implies asynchronous transfers, which we have not defined in > enough detail yet. > We have asynchronous transfers - are not the push bulk data methods asynchronous, web service call finishes before data has arrived? Certainly pushDataToVoSpace is.... From owner-vospace@eso.org Wed Jun 14 15:43:38 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EDgucb027922 for ; Wed, 14 Jun 2006 15:42:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EDguLb027921 for vospace-outgoing; Wed, 14 Jun 2006 15:42:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EDgYcb027862; Wed, 14 Jun 2006 15:42:35 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5EDgYXR011136 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 14 Jun 2006 15:42:34 +0200 In-Reply-To: <449009D5.3050302@ast.cam.ac.uk> References: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> <448FF493.7040402@ast.cam.ac.uk> <449009D5.3050302@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: VOSpace WSDL Date: Wed, 14 Jun 2006 15:42:32 +0200 To: Dave Morris X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 14.06.2006, at 15:06, Dave Morris wrote: > Paul Harrison wrote: > >> On 14.06.2006, at 13:35, Dave Morris wrote: >> >>> Or, it could be sent in a separate SOAP message, which would >>> require information about the target service, the endpoint URL >>> and some form of identifier. >>> >>> dime-put (other) +wsdl, endpoint, ident >> >> >> This second is a web service in itself - it would need an entire >> IVOA standard to cover it > > It would need _a_ specification, not necessarily IVOA. > If a 3rd party Grid project already had one defined, then we might > want to be able to send and receive data from their services too. > >> , and what's more I cannot really see a good use case for it. > > I don't see a good reason for explicitly excluding it. > One use case would be for an external service (not part of the > VOSpace service itself) that stored sensitive data. > DIME or MTOM with XML signatures would work well for authenticating > access. I am not explicitly excluding it for the future, but the current 0.21 VOSpace document does mention this possibility and I think that if anything is said about DIME at all it should be as the direct attachment to the operations in the VOSpace interface rather than as some underspecified alternative. The direct attachment to the methods in the VOSpace interface also has a resonance with the VOStore spec, which had the same mode of operation. In addition if "dime-put (other) +wsdl, endpoint, ident" transport needs extra metadata to be sent in pushDataFromVoSpace beyond the delivery URI then it cannot be implemented in VOSpace1.0 anyway..... Paul. From owner-vospace@eso.org Wed Jun 14 15:59:52 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EDxTcb000599 for ; Wed, 14 Jun 2006 15:59:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EDxTkm000598 for vospace-outgoing; Wed, 14 Jun 2006 15:59:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EDxOcb000579 for ; Wed, 14 Jun 2006 15:59:24 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5EDx3XS011548 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 14 Jun 2006 15:59:24 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: References: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72C6CF3A-7A6F-4344-A98F-0AD32152CBB0@eso.org> Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: VOSpace WSDL Date: Wed, 14 Jun 2006 15:59:23 +0200 To: IVOA mailing list VoSpace X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 14.06.2006, at 12:17, Guy Rixon wrote: >>> 6. VOSpaceResponse: where do the message and status elements come >>> from? I >>> can't see them in spec for, e.g., deleteNode, for which the >>> response message is a VOSpaceResponse. If we're going to have a >>> VOSpaceResponse (and I'd prefer a named response message for each >>> operation, >>> for symmetry), then it should be an empty type. >> A deliberate ploy to provoke such a response - I too think that some >> sort of status message would be more generally useful in other >> operations - this sort of thing did exist in VOStore, but then got >> replaced in many operations by a VOSpaceNode as a return value - so >> yes I think that both a VOSpaceNode and a VOSpaceResponse would be >> appropriate in many cases - however, I am unclear about what you mean >> by an empty type... > > Empty type instantiated like this and enforced to be > that way > in schema: written as a xsd:ComplexType with no children IIRC. Still confused - if it has no content - what is the purpose? From owner-vospace@eso.org Wed Jun 14 16:20:01 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EEJecb003675 for ; Wed, 14 Jun 2006 16:19:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EEJeiu003674 for vospace-outgoing; Wed, 14 Jun 2006 16:19:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EEJScb003648 for ; Wed, 14 Jun 2006 16:19:29 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5EEJS48005819 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 14 Jun 2006 16:19:28 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <448FFA91.6010703@ast.cam.ac.uk> References: <448FFA91.6010703@ast.cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues Date: Wed, 14 Jun 2006 16:19:26 +0200 To: IVOA list VoSpace mailing X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 14.06.2006, at 14:01, Dave Morris wrote: > Paul Harrison wrote: > >> 2. DataObjectReference type contains the idea of a name (expressed >> as a string) and a container that the Object lives in - I am not >> sure that this distinction is still needed now that we have some >> consensus on the vos: URL scheme, as it has built in semantics >> for expressing a container. > > The original definition for a node did have both the name and the URI. > The reason was that the URI would be encoded (space = %20 etc.), > and the unencoded name was provided to make things easier to > display things in a UI. > Having talked with UI developers at Canada, it was decided that > providing the name as a plain string was duplicating data and > wasn't required anyway. > So, server responses do not need to include the name, just the URI. it is already true in the WSDL that server responses only have the URI - it is only input parameters that use this DataObjectReference > > However, when creating a new node, it was agreed that the client > would supply the name as a plain text string, and the server would > convert this into the URI encoded identifier. > This means that the server side code does the URI encoding, making > it easier to verify that we get it right. > The operations that create a new node (CreateNode, PushDataTo and > PullDataTo) take the name of the new node, not the identifier. > This gives us a way of distinguishing between import into an > existing node (node URI) and import into a new node (node name). > also I think that there was also the idea that the server would generate a name automatically so the URI could point to a container... > The distinction still isn't as clear as I would like, but that is > what is in the current document. > If we want to change this, then we will need to modify the document. I think that the semantics of these operations are not still clear as currently implemented in the WSDL, and do need some work From owner-vospace@eso.org Wed Jun 14 16:32:05 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EEVjcb005363 for ; Wed, 14 Jun 2006 16:31:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EEVj3s005362 for vospace-outgoing; Wed, 14 Jun 2006 16:31:45 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EEVdcb005338 for ; Wed, 14 Jun 2006 16:31:39 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EEVaQk023835 for ; Wed, 14 Jun 2006 16:31:37 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:59286) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1FqWOi-0007s7-Ou (Exim 4.54) (return-path ); Wed, 14 Jun 2006 15:31:08 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EEV6Rt011778; Wed, 14 Jun 2006 15:31:06 +0100 (BST) Message-ID: <44901DAA.40007@ast.cam.ac.uk> Date: Wed, 14 Jun 2006 15:31:06 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: VOSpace WSDL References: <9DA4EA0B-304E-48F6-A387-F042FD94E7E1@eso.org> <448FF493.7040402@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.65433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > well I did not see you rigorously using URIs in your comments about > http-put etc. above - it is not natural. Your are right, in an email to a human, it isn't natural. However, it is useful when you want to be very precise about what you are referring to. In general I am in favour of using registry entries to describe > something that could possibly be machine understood and interpreted, > so if you can come up with a registry entry that could describe an > arbitrary transport protocol I would support mandating that the > transport name be a URI Personally, yes, I would like work towards defining an extension of VoResource for protocols, web service interfaces and data types that would enable us to register them properly. However, I don't think we are quite ready for that yet. > otherwise a simple string name is sufficient. I'm not arguing for full IVOA registry URIs. I know that many people have valid objections to them, not least of which is how and where they are registered. Defining them as xsd:anyURI in the WSDL does not mandate the ivo://..... syntax. We could choose to use a URN syntax for the initial set of core protocols if you want. urn:vospace:protocols:http-1.0-get urn:vospace:protocols:http-1.0-put However, xsd:anyURI leaves it open for us to use the ivo://... syntax to point to a resource document describing the details of the protocol if we want to. It would be useful to be able to distinguish between HTTP get and HTTP put (a service may accept un-authenticated get but require a signed SOAP message for a put). It would be useful to be able to distinguish between HTTP-1.0-put (requires content-size) and HTTP-1.1-put (accepts chunked without content-size). I would need a way of registering the ability to receive chunked data as a specific capability in a VOSpace service registration. It would make sense to use the same URIs or URNs for registering protocol capabilities in the service registration document and the protocol selection in the SOAP messages. > I think that mandating that http be a supported protocol A data center with a large collection of public images would want to use plain http get, and would probably not want to implement DIME or MTOM. A database service that allowed users to upload data directly into their database would probably not accept un-authenticated http-put, and would require a signed SOAP message with the data in a DIME or MTOM attachment. > (and defining what exactly we mean by that) would not be too > burdensome on implementations. A reference to http://www.w3.org/Protocols/rfc2616/rfc2616.html would work. However, based on our experience, a standard servlet in Apache Tomcat on JDK 1.4.x does not support chunked data properly. ------------------ Arguing over the details of HTTP-put is a side issue. I would like to make the specification open enough so that we can define, describe, and use, a new transport protocol (srb://?) without having to change the VOSpace specification. An initial list of core protocols is a good idea. I'm not convinced that they should be mandatory. We do need a precise way of referring to them, not just the common name e.g. 'http', but something that can distinguish between versions and details. URN style names if you want urn:vospace:protocols:http-1.0-get urn:vospace:protocols:http-1.0-put urn:vospace:protocols:http-1.1-get urn:vospace:protocols:http-1.1-put (implies full implementation of the spec. including chunked data) Or, URI/URLs that point to something that describes the details of what each one means. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 or ivo://org.astrogrid.vospace/protocols/http-put-chunked Defining the parameter as xsd:anyURI in the WSDL is a start, then we can argu^^ discuss which ones go in the core list, and which if any are mandatory. Dave From owner-vospace@eso.org Wed Jun 14 16:40:44 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EEeUcb006835 for ; Wed, 14 Jun 2006 16:40:31 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EEeUMl006834 for vospace-outgoing; Wed, 14 Jun 2006 16:40:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EEeOcb006821 for ; Wed, 14 Jun 2006 16:40:25 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EEeMQk024552 for ; Wed, 14 Jun 2006 16:40:23 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:59966) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1FqWXN-00054S-Op (Exim 4.54) (return-path ); Wed, 14 Jun 2006 15:40:05 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5EEe1m5012303; Wed, 14 Jun 2006 15:40:01 +0100 (BST) Message-ID: <44901FC1.30908@ast.cam.ac.uk> Date: Wed, 14 Jun 2006 15:40:01 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> In-Reply-To: <07415963-4B65-4A24-930B-6D1810C85559@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.63432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > On 14.06.2006, at 13:52, Dave Morris wrote: > >> This implies asynchronous transfers, which we have not defined in >> enough detail yet. > > We have asynchronous transfers - are not the push bulk data methods > asynchronous, web service call finishes before data has arrived? > Certainly pushDataToVoSpace is.... Yep, you are right, PushdataToVoSpace is asynchronous. However, the client is controlling the push, so it already knows when it has finished sending the data. We need status callbacks (and status polling) when the server is responsible for doing the transfer itself and the client is not involved (e.g. client asks one service to send to another). I too would like to implement asynchronous transfers properly, with notification callbacks etc. However, I thought that we decided these would go into v2.0 because we hadn't finalized exactly how this would work yet. Getting agreement on v1.0 is proving difficult enough. Lets concentrate on getting v1.0 done and then we can add all the interesting things in v2.x. Dave From owner-vospace@eso.org Wed Jun 14 21:07:35 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EJ7Kcb013157 for ; Wed, 14 Jun 2006 21:07:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5EJ7KJN013155 for vospace-outgoing; Wed, 14 Jun 2006 21:07:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EJ7Fcb013145; Wed, 14 Jun 2006 21:07:15 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5EJ7CQk014366; Wed, 14 Jun 2006 21:07:13 +0200 (CEST) Received: from [192.168.1.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k5EJ6u3G005635; Wed, 14 Jun 2006 12:06:57 -0700 Message-ID: <44905E4B.4070905@cacr.caltech.edu> Date: Wed, 14 Jun 2006 12:06:51 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Morris CC: IVOA VoSpace mailing list , Guy Rixon , Paul Harrison Subject: 1.0rc1 WSDL issues References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> In-Reply-To: <44901FC1.30908@ast.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.105432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, Gosh, you guys have been busy :-) so here are my comments: 1. Operation names: OK, change them if you want. 2. Namespace URIs: I think that if we have multiple release candidates floating around within a short time frame then different namespaces are essential to avoid confusion. 3. Enumeration: I agree with closed enumerations only where absolutely necessary. 4. URIs: I thought that it was agreed by the WG in Victoria that we would use URIs: I certainly am in favour of them. 5. doc/lit wrapped style: The rules are: the input message has a single part; the part is an element; the element has the same name as the operation; and the element's complex type has no attributes. I favour using global types since it promotes reusability. 6. Callbacks: Asynchronous behaviour is a VOSpace-2 feature so these should be removed. 7. ChangeOwner: This is VOSpace-2 functionality and should be removed. 8. GetPropertyKeys: this is a useful suggestion which we should include. 9. Transports/Formats: this information should be in the registry entry but should also be returned from the VOSpace. I know users who will not use the registry but will want to talk to a VOSpace directly. 10. Name vs. identifier: We agreed in Victoria that requests could use both but responses would always just supply the full identifier. 11. Mandatory protocols: We discussed this back in October and could not actually come up with a list so I think that you have to stick with a list of suggested protocols and hope that most implementations cover some. I'm working on an implementation that uses http but also has support for jparss. 12. DIME: In Madrid, we agreed that we would deprecate DIME as it itself has long been deprecated. With the support for MTOM now in Axis 2, WSE, XFire, etc., I would rather that we suggest MTOM as the attachment mechanism. DIME is also incompatible with WS-Security so you cannot include a DIME attachment on a secure SOAP message. Attachments are just another form of transport mechanism and I think we should keep messaging and transport separate so the import and export operations should not accept attachments: there should be separate endpoints for this as suggested in the spec. 13. WSDL vs spec: I worry that we seem to be attempting to define VOSpace from both whereas really the WSDL should just present an XML description of what the spec says. Also this WSDL seems to be quite different from what the spec defines to be the request/responses and the exception names - we really should be working with a version that is as close as possible. Cheers, Matthew From owner-vospace@eso.org Thu Jun 15 02:54:25 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F0sBYG013122 for ; Thu, 15 Jun 2006 02:54:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5F0sBSp013121 for vospace-outgoing; Thu, 15 Jun 2006 02:54:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F0s0YG013108 for ; Thu, 15 Jun 2006 02:54:00 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F0rvQk003593 for ; Thu, 15 Jun 2006 02:53:58 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:59507) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1Fqg7G-00044t-1b (Exim 4.54) (return-path ); Thu, 15 Jun 2006 01:53:46 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F0rhU5010496; Thu, 15 Jun 2006 01:53:43 +0100 (BST) Message-ID: <4490AF97.7090105@ast.cam.ac.uk> Date: Thu, 15 Jun 2006 01:53:43 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (create node params) References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> In-Reply-To: <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.173432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > On 14.06.2006, at 14:01, Dave Morris wrote: > >> However, when creating a new node, it was agreed that the client >> would supply the name as a plain text string, and the server would >> convert this into the URI encoded identifier. >> This means that the server side code does the URI encoding, making >> it easier to verify that we get it right. > >> The operations that create a new node (CreateNode, PushDataTo and >> PullDataTo) take the name of the new node, not the identifier. >> This gives us a way of distinguishing between import into an >> existing node (node URI) and import into a new node (node name). > > also I think that there was also the idea that the server would > generate a name automatically so the URI could point to a container... > >> The distinction still isn't as clear as I would like, but that is >> what is in the current document. >> If we want to change this, then we will need to modify the document. > > I think that the semantics of these operations are not still clear as > currently implemented in the WSDL, and do need some work I too was struggling with how to represent these multiple parameters in the experimental WSDL examples I posted last week. If they are causing problems, do we want to look at these again, and possibly simplify them. ---- Server generated identifiers : The original reason for server generated identifiers dates back to when we had two separate namespaces, VOSpace with user defined names, and VOStore with server generated names. The VOStore service needed to generate the names in order to ensure that they were unique within that service. Now that we have brought everything into one VOSpace namespace, I don't think we need the server generated names any more. In which case, unless anyone has a compelling use case for this, I vote we drop it. ---- Plain string name : I proposed the idea of using the separate name and URI in methods that created nodes, primarily because I wanted to make the server responsible for encoding the URI correctly. The client would just supply the name as a plain text string, and the server would encode it to create the full URI identifier. However, both of us have found problems trying to define a clear and concise WSDL that distinguishes between an import operation that creates a new node and one that imports data into an existing node. In which case, it looks like having the separate name parameter for creating a new node is causing us more problems than it is worth. ---- For VoSpace-1.0 I propose we drop both the server generated names and the separate name as string parameter. 1) CreateNode takes a mandatory target URI of the new node, rather than the optional string name. The target URI cannot be null, and the service does not automatically generate new names. It is up to the client to create and encode the target URI correctly. If the server receives an invalid URI, it throws an Exception. 2) The two import methods also take a single URI parameter to identify the target node. The target URI cannot be null, and the service does not automatically generate new names. It is up to the client to create and encode the target URI correctly. If the server receives an invalid URI, it throws an Exception. If the target node already exists, then its contents will be replaced by the import. If the target node does not exist, then the import methods will create a new node and import the data into that. (this also implies that the flag is no longer needed either) Then, to make things symmetrical : 3) MoveNode takes two URIs, representing the source and destination. The source URI cannot be null and must point to an existing node. The destination URI cannot be null, and must NOT point to an existing node. If a node already exists with the destination URI, then the method throws a DuplicateNodeException. It is up to the client to create and encode the destination URI correctly. If the server receives an invalid URI, it throws an Exception. 4) CopyNode takes two URIs, representing the source and destination. The source URI cannot be null and must point to an existing node. The destination URI cannot be null, and must NOT point to an existing node. If a node already exists with the destination URI, then the method throws a DuplicateNodeException. It is up to the client to create and encode the destination URI correctly. If the server receives an invalid URI, it throws an Exception. To support client encoded URIs : 5) We need to add MalformedIdentifierException to the list of exceptions for all the methods that take URI parameters. Hopefully, this should make the service API and WSDL a lot clearer. One caveat : I would like to re-visit this when we look at v2.x, based on what we find using v1.0 in real applications. ---- Matthew is right when he says that if we have any changes we should be discussing them in the document, and not the WSDL. The WSDL should reflect the specification as defined in the document, presenting it in a machine readable form. So, based on the fact that both Paul and I have both found problems in creating a clear and concise WSDL to represent this part of the specification and that the original use cases for the extra parameters are either no longer valid or not worth the hassle. I propose we make the above changes to the specification document, and then update the WSDL to match. Guy, Matthew, and Paul can you reply with 'accept' or 'reject' for the five changes outlined above. If everyone says yes, then we can update the document tomorrow and publish it as v0.22. I know this is a bit formal and possibly OTT, but I suspect that we will be making quite a few changes like this over the next few days. Making specific requests for individual changes to the document should make it easier to keep track of everything. I know there is at least one case where I found the list of exceptions was wrong on one of the methods, but right now I can't remember where it was. If I find it again I'll post another change request with the details. There are also a couple of questions / suggestions I would like to raise regarding data types and formats. I'll post another change request when I have worked out the details. Thanks, Dave From owner-vospace@eso.org Thu Jun 15 03:28:25 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1SBYG014931 for ; Thu, 15 Jun 2006 03:28:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5F1SBFR014930 for vospace-outgoing; Thu, 15 Jun 2006 03:28:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1S4YG014925 for ; Thu, 15 Jun 2006 03:28:04 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1S2Qk005724 for ; Thu, 15 Jun 2006 03:28:02 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:60675) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqgeI-0005gI-2E (Exim 4.54) (return-path ); Thu, 15 Jun 2006 02:27:54 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F1Rqlo010970; Thu, 15 Jun 2006 02:27:53 +0100 (BST) Message-ID: <4490B798.5050500@ast.cam.ac.uk> Date: Thu, 15 Jun 2006 02:27:52 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (GetPropertyKeys) References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> In-Reply-To: <44905E4B.4070905@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.173432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Matthew Graham wrote: > 8. GetPropertyKeys: this is a useful suggestion which we should include. Yep - I agree. Can someone write a change request outlining the details and we can add it to the document. Dave From owner-vospace@eso.org Thu Jun 15 03:31:34 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1VMYG015121 for ; Thu, 15 Jun 2006 03:31:22 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5F1VM0I015120 for vospace-outgoing; Thu, 15 Jun 2006 03:31:22 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1VHYG015090 for ; Thu, 15 Jun 2006 03:31:17 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1VFQk005834 for ; Thu, 15 Jun 2006 03:31:15 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:60802) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FqghK-0001M1-2l (Exim 4.54) (return-path ); Thu, 15 Jun 2006 02:31:02 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F1V1vw011025; Thu, 15 Jun 2006 02:31:01 +0100 (BST) Message-ID: <4490B855.1030905@ast.cam.ac.uk> Date: Thu, 15 Jun 2006 02:31:01 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (Transports/Formats) References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> In-Reply-To: <44905E4B.4070905@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.175433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Matthew Graham wrote: > 9. Transports/Formats: this information should be in the registry > entry but should also be returned from the VOSpace. I know users who > will not use the registry but will want to talk to a VOSpace directly. Yep - eventually it should be in the registry. However, at the moment we don't have a way of registering it. Certainly for v1.0 it makes sense to have the same data available direct from the service. Can someone write a change request outlining the details of the two methods and we can add it to the document. Note - should we start a new discussion thread on the XML schema for a VOSpace registry entry ? Dave From owner-vospace@eso.org Thu Jun 15 03:57:51 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1vXYG016506 for ; Thu, 15 Jun 2006 03:57:33 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5F1vXd8016505 for vospace-outgoing; Thu, 15 Jun 2006 03:57:33 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1vQYG016497 for ; Thu, 15 Jun 2006 03:57:26 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F1vNQk006938 for ; Thu, 15 Jun 2006 03:57:24 +0200 (CEST) Received: from [172.16.1.35] (adsl-69-234-64-163.dsl.irvnca.pacbell.net [69.234.64.163]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k5F1v73G030236; Wed, 14 Jun 2006 18:57:08 -0700 Message-ID: <4490BE73.2010900@cacr.caltech.edu> Date: Wed, 14 Jun 2006 18:57:07 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Morris CC: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (Transports/Formats) References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> <4490B855.1030905@ast.cam.ac.uk> In-Reply-To: <4490B855.1030905@ast.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.175433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Dave Morris wrote: > Matthew Graham wrote: > >> 9. Transports/Formats: this information should be in the registry >> entry but should also be returned from the VOSpace. I know users who >> will not use the registry but will want to talk to a VOSpace directly. > > > Yep - eventually it should be in the registry. > However, at the moment we don't have a way of registering it. > Certainly for v1.0 it makes sense to have the same data available > direct from the service. > Can someone write a change request outlining the details of the two > methods and we can add it to the document. > > Note - should we start a new discussion thread on the XML schema for a > VOSpace registry entry ? > > Dave > Hi, I think that we can really only discuss the registry resource metadata when the VOSpace spec is pretty near complete. Cheers, Matthew From owner-vospace@eso.org Thu Jun 15 04:13:14 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F2D0YG019400 for ; Thu, 15 Jun 2006 04:13:00 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5F2D0BX019399 for vospace-outgoing; Thu, 15 Jun 2006 04:13:00 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F2CtYG019394 for ; Thu, 15 Jun 2006 04:12:56 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F2CrQk007566 for ; Thu, 15 Jun 2006 04:12:54 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:62107) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1FqhLf-0000MI-OS (Exim 4.54) (return-path ); Thu, 15 Jun 2006 03:12:43 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F2Cfp7011610; Thu, 15 Jun 2006 03:12:41 +0100 (BST) Message-ID: <4490C219.5070007@ast.cam.ac.uk> Date: Thu, 15 Jun 2006 03:12:41 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (DIME and MTOM) References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> In-Reply-To: <44905E4B.4070905@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.185432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Matthew Graham wrote: > 12. DIME: In Madrid, we agreed that we would deprecate DIME as it > itself has long been deprecated. With the support for MTOM now in Axis > 2, WSE, XFire, etc., I would rather that we suggest MTOM as the > attachment mechanism. DIME is also incompatible with WS-Security so > you cannot include a DIME attachment on a secure SOAP message. Yes, we did agree that we would deprecate it, but we didn't set a specific date. I agree that we should use MTOM in preference to DIME, but as the list of protocols is open, I don't see any harm in allowing it. We (AstroGrid) would like to use Axis-2.x or XFire, and we are working on migrating our services away from Axis-1.x. However, at the moment, we are stuck with Axis-1.x, and so MTOM is out of reach, at least for a while. Based on the work we did for ADASS, using DIME attachments would give us a quick win for at least one authenticated secure put method we can all implement fairly quickly. > Attachments are just another form of transport mechanism and I think > we should keep messaging and transport separate so the import and > export operations should not accept attachments: there should be > separate endpoints for this as suggested in the spec. I agree that DIME and MTOM should be treated as just another form of transport mechanism. However, I don't see any harm in allowing the PushDataTo and PushDataFrom methods to accept attachments, as long as it is not part of the main service specification or the WSDL. As far as I know, allowing a DIME or MTOM attachment does not actually change the WSDL ? Guy has suggested that we should define the transport protocols in annexes (is that the right plural?) to the main document, making it clear that it is not a closed or mandatory list. The document already has an annex that defines how to handle DIME attachments. I think we should split this into four annexes, one for each option (see earlier email for details). http://ivoa.net/forum/vospace/0606/0065.htm We can add similar definitions for the equivalent MTOM forms as well. Remember, this is not a mandatory or exclusive list, so having DIME defined in an annex does not mean an implementation _has_ to support it. All it means is that if you want to use DIME, or MTOM, and you want to talk to other VO services, then we recommend you use one of the methods defined in the annexes. Note that calling a separate web service for a DIME or MTOM data transfer means that the element in the WSDL is no longer a simple URL. In order to specify _what_ data object to access in the other service, we would need the service endpoint (URL) plus an additional service specific identifier (string?). This is a good reason for defining everything in the schema as ComplexType(s) rather than just elements, and then using the individual types to build the messages. If we define the or equivalent as a ComplexType that contains a element, then we should be able to define an xsd:extension that adds the additional identifier element for an indirect DIME or MTOM transfer. Services that do support indirect DIME or MTOM should be able to understand the xsd:extension type. Services that don't support it should not receive messages with the xsd:extension type in anyway. Note - has anyone tried using xsi:type on an element to use an xsd:extension type in a SOAP message ? Dave From owner-vospace@eso.org Thu Jun 15 04:43:02 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F2giYG021272 for ; Thu, 15 Jun 2006 04:42:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5F2gik0021271 for vospace-outgoing; Thu, 15 Jun 2006 04:42:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F2gdYG021265 for ; Thu, 15 Jun 2006 04:42:40 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F2gcQk008608 for ; Thu, 15 Jun 2006 04:42:38 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:63228) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FqhoV-0003oW-TB (Exim 4.54) (return-path ); Thu, 15 Jun 2006 03:42:31 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F2gThd012028; Thu, 15 Jun 2006 03:42:29 +0100 (BST) Message-ID: <4490C914.2080302@ast.cam.ac.uk> Date: Thu, 15 Jun 2006 03:42:28 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (change requests) References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> In-Reply-To: <44905E4B.4070905@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.185432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Matthew Graham wrote: > 13. WSDL vs spec: I worry that we seem to be attempting to define > VOSpace from both whereas really the WSDL should just present an XML > description of what the spec says. Yep, good point. In order to help keep track of any changes we want to make, I would like to suggest the following : 1) Any changes to the specification are done with reference to the document not the WSDL. 2) For each change, we send a change request email to the mailing list, detailing exactly what we need to change in the document and why. 3) Everyone gets a chance to accept or reject the change (within a reasonable time limit). 4) If the change is accepted, we update the document, and then modify the WSDL to match. I seem to remember some of the Apache projects had a similar system, where all of the developers on the project mailing list had a +1 (accept) -1 (reject) or 0 (don't care) vote. I don't want to overload us with too much process, but Matthew is right, discussion should be based on the document and not the WSDL. If the specification is wrong, we change it in the document first. Having reached a general agreement for the v0.21 document in Canada, we need to keep the number and scope of the changes as small as possible. Requiring an explicit change request for each modification means we have to be very specific about exactly what we want to change. Having said that, if we find parts of the specification are difficult to represent clearly in the WSDL, then this is a perfectly valid reason for going back to the document and refactoring things. Hope this helps, Dave ps. To start things off, can you all send a +1, 0 or -1 for this. From owner-vospace@eso.org Thu Jun 15 09:05:36 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F75NYG005669 for ; Thu, 15 Jun 2006 09:05:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5F75NS6005668 for vospace-outgoing; Thu, 15 Jun 2006 09:05:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F75HYG005658; Thu, 15 Jun 2006 09:05:17 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F75FQk021049; Thu, 15 Jun 2006 09:05:15 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:39137) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1Fqluc-00031w-VR (Exim 4.54) (return-path ); Thu, 15 Jun 2006 08:05:07 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F754Kw015126; Thu, 15 Jun 2006 08:05:04 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F754DQ021678; Thu, 15 Jun 2006 08:05:04 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5F753L6021675; Thu, 15 Jun 2006 08:05:04 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 15 Jun 2006 08:05:03 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Matthew Graham cc: Dave Morris , IVOA VoSpace mailing list , Paul Harrison Subject: Re: 1.0rc1 WSDL issues In-Reply-To: <44905E4B.4070905@cacr.caltech.edu> Message-ID: References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.225433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon On Wed, 14 Jun 2006, Matthew Graham wrote: > 5. doc/lit wrapped style: The rules are: the input message has a single > part; the part is an element; the element has the same name as the > operation; and the element's complex type has no attributes. I favour > using global types since it promotes reusability. So the answer is to use all global types and global elements only for the top-level messages? This suggests that the .xsd file will be all types and the elements will only be in the schema embedded in the WSDL. > 9. Transports/Formats: this information should be in the registry entry > but should also be returned from the VOSpace. I know users who will not > use the registry but will want to talk to a VOSpace directly. If returned directly from the VOSpace service do the answers apply to all nodes of the service or do they differ from node to node? > 11. Mandatory protocols: We discussed this back in October and could not > actually come up with a list so I think that you have to stick with a > list of suggested protocols and hope that most implementations cover > some. I'm working on an implementation that uses http but also has > support for jparss. > 12. DIME: In Madrid, we agreed that we would deprecate DIME as it itself > has long been deprecated. With the support for MTOM now in Axis 2, WSE, > XFire, etc., I would rather that we suggest MTOM as the attachment > mechanism. DIME is also incompatible with WS-Security so you cannot > include a DIME attachment on a secure SOAP message. Attachments are just > another form of transport mechanism and I think we should keep messaging > and transport separate so the import and export operations should not > accept attachments: there should be separate endpoints for this as > suggested in the spec. I agree with dumping DIME in favour of MTOM. > 13. WSDL vs spec: I worry that we seem to be attempting to define > VOSpace from both whereas really the WSDL should just present an XML > description of what the spec says. Also this WSDL seems to be quite > different from what the spec defines to be the request/responses and the > exception names - we really should be working with a version that is as > close as possible. I don't mind tuning the spec document to match the WSDL if the WSDL exposing things we'd left out. However, we need to expose a matched pair and leave them a few days for comments before going to 1.0. If we really need status messages in the returns I'd rather see their semantics written down before we design the syntax. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Thu Jun 15 09:09:05 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F78pYG005904 for ; Thu, 15 Jun 2006 09:08:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5F78pAf005903 for vospace-outgoing; Thu, 15 Jun 2006 09:08:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F78kYG005897 for ; Thu, 15 Jun 2006 09:08:46 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5F78hQk021236 for ; Thu, 15 Jun 2006 09:08:44 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:39303) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1Fqly0-0005A7-Ve (Exim 4.54) for vospace@ivoa.net (return-path ); Thu, 15 Jun 2006 08:08:36 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F78YOt015187; Thu, 15 Jun 2006 08:08:34 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5F78Y93021696; Thu, 15 Jun 2006 08:08:34 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5F78Ymg021693; Thu, 15 Jun 2006 08:08:34 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 15 Jun 2006 08:08:34 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Dave Morris cc: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (create node params) In-Reply-To: <4490AF97.7090105@ast.cam.ac.uk> Message-ID: References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.14.235436 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Use case for server-generated names: when clients working in the same space want to generate temporary files with unique names. Java File.makeTempFile() and all that. If we support this, it might deserve its own operation with different parameters from createNode. On Thu, 15 Jun 2006, Dave Morris wrote: > Paul Harrison wrote: > > > On 14.06.2006, at 14:01, Dave Morris wrote: > > > >> However, when creating a new node, it was agreed that the client > >> would supply the name as a plain text string, and the server would > >> convert this into the URI encoded identifier. > >> This means that the server side code does the URI encoding, making > >> it easier to verify that we get it right. > > > >> The operations that create a new node (CreateNode, PushDataTo and > >> PullDataTo) take the name of the new node, not the identifier. > >> This gives us a way of distinguishing between import into an > >> existing node (node URI) and import into a new node (node name). > > > > also I think that there was also the idea that the server would > > generate a name automatically so the URI could point to a container... > > > >> The distinction still isn't as clear as I would like, but that is > >> what is in the current document. > >> If we want to change this, then we will need to modify the document. > > > > I think that the semantics of these operations are not still clear as > > currently implemented in the WSDL, and do need some work > > > I too was struggling with how to represent these multiple parameters in > the experimental WSDL examples I posted last week. > If they are causing problems, do we want to look at these again, and > possibly simplify them. > > ---- > > Server generated identifiers : > The original reason for server generated identifiers dates back to when > we had two separate namespaces, VOSpace with user defined names, and > VOStore with server generated names. > The VOStore service needed to generate the names in order to ensure that > they were unique within that service. > > Now that we have brought everything into one VOSpace namespace, I don't > think we need the server generated names any more. > In which case, unless anyone has a compelling use case for this, I vote > we drop it. > > ---- > > Plain string name : > I proposed the idea of using the separate name and URI in methods that > created nodes, primarily because I wanted to make the server responsible > for encoding the URI correctly. > The client would just supply the name as a plain text string, and the > server would encode it to create the full URI identifier. > > However, both of us have found problems trying to define a clear and > concise WSDL that distinguishes between an import operation that creates > a new node and one that imports data into an existing node. In which > case, it looks like having the separate name parameter for creating a > new node is causing us more problems than it is worth. > > ---- > > For VoSpace-1.0 I propose we drop both the server generated names and > the separate name as string parameter. > > 1) CreateNode takes a mandatory target URI of the new node, rather than > the optional string name. > The target URI cannot be null, and the service does not automatically > generate new names. > It is up to the client to create and encode the target URI correctly. > If the server receives an invalid URI, it throws an Exception. > > 2) The two import methods also take a single URI parameter to identify > the target node. > The target URI cannot be null, and the service does not automatically > generate new names. > It is up to the client to create and encode the target URI correctly. > If the server receives an invalid URI, it throws an Exception. > If the target node already exists, then its contents will be replaced by > the import. > If the target node does not exist, then the import methods will create a > new node and import the data into that. > (this also implies that the flag is no longer needed either) > > Then, to make things symmetrical : > > 3) MoveNode takes two URIs, representing the source and destination. > The source URI cannot be null and must point to an existing node. > The destination URI cannot be null, and must NOT point to an existing node. > If a node already exists with the destination URI, then the method > throws a DuplicateNodeException. > It is up to the client to create and encode the destination URI correctly. > If the server receives an invalid URI, it throws an Exception. > > 4) CopyNode takes two URIs, representing the source and destination. > The source URI cannot be null and must point to an existing node. > The destination URI cannot be null, and must NOT point to an existing node. > If a node already exists with the destination URI, then the method > throws a DuplicateNodeException. > It is up to the client to create and encode the destination URI correctly. > If the server receives an invalid URI, it throws an Exception. > > To support client encoded URIs : > > 5) We need to add MalformedIdentifierException to the list of exceptions > for all the methods that take URI parameters. > > Hopefully, this should make the service API and WSDL a lot clearer. > > One caveat : > I would like to re-visit this when we look at v2.x, based on what we > find using v1.0 in real applications. > > ---- > > Matthew is right when he says that if we have any changes we should be > discussing them in the document, and not the WSDL. > The WSDL should reflect the specification as defined in the document, > presenting it in a machine readable form. > > So, based on the fact that both Paul and I have both found problems in > creating a clear and concise WSDL to represent this part of the > specification and that the original use cases for the extra parameters > are either no longer valid or not worth the hassle. > I propose we make the above changes to the specification document, and > then update the WSDL to match. > > Guy, Matthew, and Paul can you reply with 'accept' or 'reject' for the > five changes outlined above. > If everyone says yes, then we can update the document tomorrow and > publish it as v0.22. > > I know this is a bit formal and possibly OTT, but I suspect that we will > be making quite a few changes like this over the next few days. > Making specific requests for individual changes to the document should > make it easier to keep track of everything. > > I know there is at least one case where I found the list of exceptions > was wrong on one of the methods, but right now I can't remember where it > was. > If I find it again I'll post another change request with the details. > > There are also a couple of questions / suggestions I would like to raise > regarding data types and formats. > I'll post another change request when I have worked out the details. > > Thanks, > Dave > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Thu Jun 15 21:24:08 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJNAYG010718 for ; Thu, 15 Jun 2006 21:23:10 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5FJNANu010717 for vospace-outgoing; Thu, 15 Jun 2006 21:23:10 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJN2YG010670 for ; Thu, 15 Jun 2006 21:23:02 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJMwQk006758 for ; Thu, 15 Jun 2006 21:22:59 +0200 (CEST) Received: from [192.168.1.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k5FJMg3G003029; Thu, 15 Jun 2006 12:22:43 -0700 Message-ID: <4491B37D.5030904@cacr.caltech.edu> Date: Thu, 15 Jun 2006 12:22:37 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Dave Morris , IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (create node params) References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.113432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, I accept Dave's suggestions. I also accept Guy's suggestion for a separate operation for creating a temporary node with a server-generated name and propose adding this text to the spec: createTempNode Creates a temporary node in a space. This method is used to create a temporary data node. Parameters: None Returns: A element for the new node. Faults: The service may throw an OperationNotSupported exception if it does not support temporary nodes. The service may throw an InternalFault exception if an operation fails. The service may throw a PermissionDenied exception if the user does not have permissions to perform the operation. Questions: - Should a properties structure be an optional parameter? - A user can always make a temporary node permanent by renaming it to something more meaningful. Cheers, Matthew Guy Rixon wrote: >Use case for server-generated names: when clients working in the same space >want to generate temporary files with unique names. Java File.makeTempFile() >and all that. If we support this, it might deserve its own operation with >different parameters from createNode. > >On Thu, 15 Jun 2006, Dave Morris wrote: > > > >>Paul Harrison wrote: >> >> >> >>>On 14.06.2006, at 14:01, Dave Morris wrote: >>> >>> >>> >>>>However, when creating a new node, it was agreed that the client >>>>would supply the name as a plain text string, and the server would >>>>convert this into the URI encoded identifier. >>>>This means that the server side code does the URI encoding, making >>>>it easier to verify that we get it right. >>>> >>>> >>>>The operations that create a new node (CreateNode, PushDataTo and >>>>PullDataTo) take the name of the new node, not the identifier. >>>>This gives us a way of distinguishing between import into an >>>>existing node (node URI) and import into a new node (node name). >>>> >>>> >>>also I think that there was also the idea that the server would >>>generate a name automatically so the URI could point to a container... >>> >>> >>> >>>>The distinction still isn't as clear as I would like, but that is >>>>what is in the current document. >>>>If we want to change this, then we will need to modify the document. >>>> >>>> >>>I think that the semantics of these operations are not still clear as >>>currently implemented in the WSDL, and do need some work >>> >>> >>I too was struggling with how to represent these multiple parameters in >>the experimental WSDL examples I posted last week. >>If they are causing problems, do we want to look at these again, and >>possibly simplify them. >> >>---- >> >>Server generated identifiers : >>The original reason for server generated identifiers dates back to when >>we had two separate namespaces, VOSpace with user defined names, and >>VOStore with server generated names. >>The VOStore service needed to generate the names in order to ensure that >>they were unique within that service. >> >>Now that we have brought everything into one VOSpace namespace, I don't >>think we need the server generated names any more. >>In which case, unless anyone has a compelling use case for this, I vote >>we drop it. >> >>---- >> >>Plain string name : >>I proposed the idea of using the separate name and URI in methods that >>created nodes, primarily because I wanted to make the server responsible >>for encoding the URI correctly. >>The client would just supply the name as a plain text string, and the >>server would encode it to create the full URI identifier. >> >>However, both of us have found problems trying to define a clear and >>concise WSDL that distinguishes between an import operation that creates >>a new node and one that imports data into an existing node. In which >>case, it looks like having the separate name parameter for creating a >>new node is causing us more problems than it is worth. >> >>---- >> >>For VoSpace-1.0 I propose we drop both the server generated names and >>the separate name as string parameter. >> >>1) CreateNode takes a mandatory target URI of the new node, rather than >>the optional string name. >>The target URI cannot be null, and the service does not automatically >>generate new names. >>It is up to the client to create and encode the target URI correctly. >>If the server receives an invalid URI, it throws an Exception. >> >>2) The two import methods also take a single URI parameter to identify >>the target node. >>The target URI cannot be null, and the service does not automatically >>generate new names. >>It is up to the client to create and encode the target URI correctly. >>If the server receives an invalid URI, it throws an Exception. >>If the target node already exists, then its contents will be replaced by >>the import. >>If the target node does not exist, then the import methods will create a >>new node and import the data into that. >>(this also implies that the flag is no longer needed either) >> >>Then, to make things symmetrical : >> >>3) MoveNode takes two URIs, representing the source and destination. >>The source URI cannot be null and must point to an existing node. >>The destination URI cannot be null, and must NOT point to an existing node. >>If a node already exists with the destination URI, then the method >>throws a DuplicateNodeException. >>It is up to the client to create and encode the destination URI correctly. >>If the server receives an invalid URI, it throws an Exception. >> >>4) CopyNode takes two URIs, representing the source and destination. >>The source URI cannot be null and must point to an existing node. >>The destination URI cannot be null, and must NOT point to an existing node. >>If a node already exists with the destination URI, then the method >>throws a DuplicateNodeException. >>It is up to the client to create and encode the destination URI correctly. >>If the server receives an invalid URI, it throws an Exception. >> >>To support client encoded URIs : >> >>5) We need to add MalformedIdentifierException to the list of exceptions >>for all the methods that take URI parameters. >> >>Hopefully, this should make the service API and WSDL a lot clearer. >> >>One caveat : >>I would like to re-visit this when we look at v2.x, based on what we >>find using v1.0 in real applications. >> >>---- >> >>Matthew is right when he says that if we have any changes we should be >>discussing them in the document, and not the WSDL. >>The WSDL should reflect the specification as defined in the document, >>presenting it in a machine readable form. >> >>So, based on the fact that both Paul and I have both found problems in >>creating a clear and concise WSDL to represent this part of the >>specification and that the original use cases for the extra parameters >>are either no longer valid or not worth the hassle. >>I propose we make the above changes to the specification document, and >>then update the WSDL to match. >> >>Guy, Matthew, and Paul can you reply with 'accept' or 'reject' for the >>five changes outlined above. >>If everyone says yes, then we can update the document tomorrow and >>publish it as v0.22. >> >>I know this is a bit formal and possibly OTT, but I suspect that we will >>be making quite a few changes like this over the next few days. >>Making specific requests for individual changes to the document should >>make it easier to keep track of everything. >> >>I know there is at least one case where I found the list of exceptions >>was wrong on one of the methods, but right now I can't remember where it >>was. >>If I find it again I'll post another change request with the details. >> >>There are also a couple of questions / suggestions I would like to raise >>regarding data types and formats. >>I'll post another change request when I have worked out the details. >> >>Thanks, >>Dave >> >> >> > >Guy Rixon gtr@ast.cam.ac.uk >Institute of Astronomy Tel: +44-1223-337542 >Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > > From owner-vospace@eso.org Thu Jun 15 21:25:27 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJOfYG011035 for ; Thu, 15 Jun 2006 21:24:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5FJOf2b011034 for vospace-outgoing; Thu, 15 Jun 2006 21:24:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJOMYG010982 for ; Thu, 15 Jun 2006 21:24:23 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJOKQk006810 for ; Thu, 15 Jun 2006 21:24:21 +0200 (CEST) Received: from [192.168.1.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k5FJO73G003039; Thu, 15 Jun 2006 12:24:07 -0700 Message-ID: <4491B3D2.9050309@cacr.caltech.edu> Date: Thu, 15 Jun 2006 12:24:02 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Morris CC: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (change requests) References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> <4490C914.2080302@ast.cam.ac.uk> In-Reply-To: <4490C914.2080302@ast.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.113432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, I accept this proposal. Cheers, Matthew Dave Morris wrote: > Matthew Graham wrote: > >> 13. WSDL vs spec: I worry that we seem to be attempting to define >> VOSpace from both whereas really the WSDL should just present an XML >> description of what the spec says. > > > Yep, good point. > In order to help keep track of any changes we want to make, I would > like to suggest the following : > > 1) Any changes to the specification are done with reference to the > document not the WSDL. > 2) For each change, we send a change request email to the mailing > list, detailing exactly what we need to change in the document and why. > 3) Everyone gets a chance to accept or reject the change (within a > reasonable time limit). > 4) If the change is accepted, we update the document, and then modify > the WSDL to match. > > I seem to remember some of the Apache projects had a similar system, > where all of the developers on the project mailing list had a +1 > (accept) -1 (reject) or 0 (don't care) vote. > I don't want to overload us with too much process, but Matthew is > right, discussion should be based on the document and not the WSDL. > If the specification is wrong, we change it in the document first. > > Having reached a general agreement for the v0.21 document in Canada, > we need to keep the number and scope of the changes as small as possible. > Requiring an explicit change request for each modification means we > have to be very specific about exactly what we want to change. > > Having said that, if we find parts of the specification are difficult > to represent clearly in the WSDL, then this is a perfectly valid > reason for going back to the document and refactoring things. > > Hope this helps, > Dave > > ps. > To start things off, can you all send a +1, 0 or -1 for this. > From owner-vospace@eso.org Thu Jun 15 21:38:10 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJbpYG012688 for ; Thu, 15 Jun 2006 21:37:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5FJbp0M012687 for vospace-outgoing; Thu, 15 Jun 2006 21:37:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJbgYG012667; Thu, 15 Jun 2006 21:37:43 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FJbeQk007508; Thu, 15 Jun 2006 21:37:41 +0200 (CEST) Received: from [192.168.1.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k5FJbL3G003189; Thu, 15 Jun 2006 12:37:21 -0700 Message-ID: <4491B6EC.9030001@cacr.caltech.edu> Date: Thu, 15 Jun 2006 12:37:16 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Dave Morris , IVOA VoSpace mailing list , Paul Harrison Subject: Re: 1.0rc1 WSDL issues References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.115432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Guy Rixon wrote: >On Wed, 14 Jun 2006, Matthew Graham wrote: > > > >>5. doc/lit wrapped style: The rules are: the input message has a single >>part; the part is an element; the element has the same name as the >>operation; and the element's complex type has no attributes. I favour >>using global types since it promotes reusability. >> >> > >So the answer is to use all global types and global elements only for the >top-level messages? This suggests that the .xsd file will be all types and the >elements will only be in the schema embedded in the WSDL. > > If we are going to have a separate schema then this makes quite a nice division: it might also provide quite a nice extensibility mechanism since what changes is the type in the schema not anything directly in the WSDL. >>12. DIME: In Madrid, we agreed that we would deprecate DIME as it itself >>has long been deprecated. With the support for MTOM now in Axis 2, WSE, >>XFire, etc., I would rather that we suggest MTOM as the attachment >>mechanism. DIME is also incompatible with WS-Security so you cannot >>include a DIME attachment on a secure SOAP message. Attachments are just >>another form of transport mechanism and I think we should keep messaging >>and transport separate so the import and export operations should not >>accept attachments: there should be separate endpoints for this as >>suggested in the spec. >> >> > >I agree with dumping DIME in favour of MTOM. > > Dave does have a point, however, about MTOM support. I think that we should leave DIME in now but note that it will be deprecated in the next release and also introduce MTOM as the successor. Cheers, Matthew From owner-vospace@eso.org Fri Jun 16 00:12:19 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FMC6pO003891 for ; Fri, 16 Jun 2006 00:12:07 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5FMC64M003890 for vospace-outgoing; Fri, 16 Jun 2006 00:12:06 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FMBopO003815 for ; Fri, 16 Jun 2006 00:11:50 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5FMBlQk017713 for ; Fri, 16 Jun 2006 00:11:47 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:37581) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1Fr03s-0004jy-15 (Exim 4.54) (return-path ); Thu, 15 Jun 2006 23:11:36 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5FMBXJa028262; Thu, 15 Jun 2006 23:11:33 +0100 (BST) Message-ID: <4491DB15.5030401@ast.cam.ac.uk> Date: Thu, 15 Jun 2006 23:11:33 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (create node params) References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> In-Reply-To: <4491B37D.5030904@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.143433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Yes to CreateTempNode() Yes to the optional properties parameter. Thanks, Dave Matthew Graham wrote: > Hi, > > I accept Dave's suggestions. > > I also accept Guy's suggestion for a separate operation for creating a > temporary node with a server-generated name and propose adding this > text to the spec: > > createTempNode > > Creates a temporary node in a space. This method is used to create a > temporary data node. > > Parameters: None > > Returns: A element for the new node. > > Faults: The service may throw an OperationNotSupported exception if > it does not support temporary nodes. > The service may throw an InternalFault exception if an > operation fails. > The service may throw a PermissionDenied exception if the > user does not have permissions to perform the operation. > > Questions: > - Should a properties structure be an optional parameter? > - A user can always make a temporary node permanent by renaming it to > something more meaningful. > > Cheers, > > Matthew > > > > Guy Rixon wrote: > >> Use case for server-generated names: when clients working in the same >> space >> want to generate temporary files with unique names. Java >> File.makeTempFile() >> and all that. If we support this, it might deserve its own operation >> with >> different parameters from createNode. >> >> On Thu, 15 Jun 2006, Dave Morris wrote: >> >> >> >>> Paul Harrison wrote: >>> >>> >>> >>>> On 14.06.2006, at 14:01, Dave Morris wrote: >>>> >>>> >>>> >>>>> However, when creating a new node, it was agreed that the client >>>>> would supply the name as a plain text string, and the server would >>>>> convert this into the URI encoded identifier. >>>>> This means that the server side code does the URI encoding, making >>>>> it easier to verify that we get it right. >>>>> >>>>> The operations that create a new node (CreateNode, PushDataTo and >>>>> PullDataTo) take the name of the new node, not the identifier. >>>>> This gives us a way of distinguishing between import into an >>>>> existing node (node URI) and import into a new node (node name). >>>>> >>>> >>>> also I think that there was also the idea that the server would >>>> generate a name automatically so the URI could point to a container... >>>> >>>> >>>> >>>>> The distinction still isn't as clear as I would like, but that is >>>>> what is in the current document. >>>>> If we want to change this, then we will need to modify the document. >>>>> >>>> >>>> I think that the semantics of these operations are not still clear as >>>> currently implemented in the WSDL, and do need some work >>>> >>> >>> I too was struggling with how to represent these multiple parameters in >>> the experimental WSDL examples I posted last week. >>> If they are causing problems, do we want to look at these again, and >>> possibly simplify them. >>> >>> ---- >>> >>> Server generated identifiers : >>> The original reason for server generated identifiers dates back to when >>> we had two separate namespaces, VOSpace with user defined names, and >>> VOStore with server generated names. >>> The VOStore service needed to generate the names in order to ensure >>> that >>> they were unique within that service. >>> >>> Now that we have brought everything into one VOSpace namespace, I don't >>> think we need the server generated names any more. >>> In which case, unless anyone has a compelling use case for this, I vote >>> we drop it. >>> >>> ---- >>> >>> Plain string name : >>> I proposed the idea of using the separate name and URI in methods that >>> created nodes, primarily because I wanted to make the server >>> responsible >>> for encoding the URI correctly. >>> The client would just supply the name as a plain text string, and the >>> server would encode it to create the full URI identifier. >>> >>> However, both of us have found problems trying to define a clear and >>> concise WSDL that distinguishes between an import operation that >>> creates >>> a new node and one that imports data into an existing node. In which >>> case, it looks like having the separate name parameter for creating a >>> new node is causing us more problems than it is worth. >>> >>> ---- >>> >>> For VoSpace-1.0 I propose we drop both the server generated names and >>> the separate name as string parameter. >>> >>> 1) CreateNode takes a mandatory target URI of the new node, rather than >>> the optional string name. >>> The target URI cannot be null, and the service does not automatically >>> generate new names. >>> It is up to the client to create and encode the target URI correctly. >>> If the server receives an invalid URI, it throws an Exception. >>> >>> 2) The two import methods also take a single URI parameter to identify >>> the target node. >>> The target URI cannot be null, and the service does not automatically >>> generate new names. >>> It is up to the client to create and encode the target URI correctly. >>> If the server receives an invalid URI, it throws an Exception. >>> If the target node already exists, then its contents will be >>> replaced by >>> the import. >>> If the target node does not exist, then the import methods will >>> create a >>> new node and import the data into that. >>> (this also implies that the flag is no longer needed either) >>> >>> Then, to make things symmetrical : >>> >>> 3) MoveNode takes two URIs, representing the source and destination. >>> The source URI cannot be null and must point to an existing node. >>> The destination URI cannot be null, and must NOT point to an >>> existing node. >>> If a node already exists with the destination URI, then the method >>> throws a DuplicateNodeException. >>> It is up to the client to create and encode the destination URI >>> correctly. >>> If the server receives an invalid URI, it throws an Exception. >>> >>> 4) CopyNode takes two URIs, representing the source and destination. >>> The source URI cannot be null and must point to an existing node. >>> The destination URI cannot be null, and must NOT point to an >>> existing node. >>> If a node already exists with the destination URI, then the method >>> throws a DuplicateNodeException. >>> It is up to the client to create and encode the destination URI >>> correctly. >>> If the server receives an invalid URI, it throws an Exception. >>> >>> To support client encoded URIs : >>> >>> 5) We need to add MalformedIdentifierException to the list of >>> exceptions >>> for all the methods that take URI parameters. >>> >>> Hopefully, this should make the service API and WSDL a lot clearer. >>> >>> One caveat : >>> I would like to re-visit this when we look at v2.x, based on what we >>> find using v1.0 in real applications. >>> >>> ---- >>> >>> Matthew is right when he says that if we have any changes we should be >>> discussing them in the document, and not the WSDL. >>> The WSDL should reflect the specification as defined in the document, >>> presenting it in a machine readable form. >>> >>> So, based on the fact that both Paul and I have both found problems in >>> creating a clear and concise WSDL to represent this part of the >>> specification and that the original use cases for the extra parameters >>> are either no longer valid or not worth the hassle. >>> I propose we make the above changes to the specification document, and >>> then update the WSDL to match. >>> >>> Guy, Matthew, and Paul can you reply with 'accept' or 'reject' for the >>> five changes outlined above. >>> If everyone says yes, then we can update the document tomorrow and >>> publish it as v0.22. >>> >>> I know this is a bit formal and possibly OTT, but I suspect that we >>> will >>> be making quite a few changes like this over the next few days. >>> Making specific requests for individual changes to the document should >>> make it easier to keep track of everything. >>> >>> I know there is at least one case where I found the list of exceptions >>> was wrong on one of the methods, but right now I can't remember >>> where it >>> was. >>> If I find it again I'll post another change request with the details. >>> >>> There are also a couple of questions / suggestions I would like to >>> raise >>> regarding data types and formats. >>> I'll post another change request when I have worked out the details. >>> >>> Thanks, >>> Dave >>> >>> >> >> >> Guy Rixon gtr@ast.cam.ac.uk >> Institute of Astronomy Tel: +44-1223-337542 >> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >> >> >> From owner-vospace@eso.org Fri Jun 16 09:44:17 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5G7hvpO005581 for ; Fri, 16 Jun 2006 09:43:57 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5G7hv53005580 for vospace-outgoing; Fri, 16 Jun 2006 09:43:57 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5G7hopO005563 for ; Fri, 16 Jun 2006 09:43:51 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5G7ho48005020 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 16 Jun 2006 09:43:50 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <44905E4B.4070905@cacr.caltech.edu> References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues Date: Fri, 16 Jun 2006 09:43:51 +0200 To: IVOA VoSpace mailing list X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 14.06.2006, at 21:06, Matthew Graham wrote: > 13. WSDL vs spec: I worry that we seem to be attempting to define > VOSpace from both whereas really the WSDL should just present an > XML description of what the spec says. Also this WSDL seems to be > quite different from what the spec defines to be the request/ > responses and the exception names - we really should be working > with a version that is as close as possible. At this stage I think that it is perfectly natural that they are not exactly in line - the WSDL is an attempt to represent what is said in the spec in a more formal language - doing so can expose difficulties in representing concepts in the specification - e.g. server generated data object identifiers., and potential "holes" in the specification. I would anyway expect the WSDL to be finalised *before* the specification, as we are supposed to produce reference implementations when going to PR on the spec, and this process will almost certainly provoke the need to more explanatory text in the specification. Paul. From owner-vospace@eso.org Fri Jun 16 10:15:47 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5G8FXpO011130 for ; Fri, 16 Jun 2006 10:15:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5G8FXjc011129 for vospace-outgoing; Fri, 16 Jun 2006 10:15:33 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5G8FDpO011070; Fri, 16 Jun 2006 10:15:13 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5G8FDXR011973 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 16 Jun 2006 10:15:13 +0200 In-Reply-To: <44905E4B.4070905@cacr.caltech.edu> References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <859AA217-C893-4C60-84F8-AE653F8D1BC4@eso.org> Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues Date: Fri, 16 Jun 2006 10:15:11 +0200 To: Matthew Graham X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 14.06.2006, at 21:06, Matthew Graham wrote: > 11. Mandatory protocols: We discussed this back in October and > could not actually come up with a list so I think that you have to > stick with a list of suggested protocols and hope that most > implementations cover some. I'm working on an implementation that > uses http but also has support for jparss. We cannot use "hope" as the basis for a specification - we have try to ensure that this specification guarantees interoperability as far as possible, or the specification is worthless. As I have already pointed out, with the current state of the specification, I can produce a compliant VOStore implementation and Dave can produce another, but because we have different ideas about the exact forms of transport mechanisms, they would not be able to transfer data between each other! At a minimum we need to mandate one transport mechanism (and describe in detail what we mean by it) to ensure that compliant services can at least perform this rather basic use case. Given that we are defining a web service, http would not be a burdensome requirement for people. I also think that we should define a list of names for other common transport mechanisms - e.g. ftp, gridftp so that if two implementations decide to provide a gridftp transport they can interoperate because they both call it gridftp rather than one calling it something like "globusftp". Paul. From owner-vospace@eso.org Fri Jun 16 12:37:08 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAanpO021776 for ; Fri, 16 Jun 2006 12:36:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5GAanvV021775 for vospace-outgoing; Fri, 16 Jun 2006 12:36:49 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAaipO021771 for ; Fri, 16 Jun 2006 12:36:45 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAagQk002419 for ; Fri, 16 Jun 2006 12:36:43 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:37065) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1FrBgP-0002pH-4S (Exim 4.54) for vospace@ivoa.net (return-path ); Fri, 16 Jun 2006 11:36:10 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GAa7Ga020262; Fri, 16 Jun 2006 11:36:07 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GAa7Ci006019; Fri, 16 Jun 2006 11:36:07 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5GAa6Cl006016; Fri, 16 Jun 2006 11:36:07 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 16 Jun 2006 11:36:06 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Dave Morris cc: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (change requests) In-Reply-To: <4490C914.2080302@ast.cam.ac.uk> Message-ID: References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> <4490C914.2080302@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.16.25432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon OK, I'll go with this. +1 to change control. On Thu, 15 Jun 2006, Dave Morris wrote: > Matthew Graham wrote: > > > 13. WSDL vs spec: I worry that we seem to be attempting to define > > VOSpace from both whereas really the WSDL should just present an XML > > description of what the spec says. > > Yep, good point. > In order to help keep track of any changes we want to make, I would like > to suggest the following : > > 1) Any changes to the specification are done with reference to the > document not the WSDL. > 2) For each change, we send a change request email to the mailing list, > detailing exactly what we need to change in the document and why. > 3) Everyone gets a chance to accept or reject the change (within a > reasonable time limit). > 4) If the change is accepted, we update the document, and then modify > the WSDL to match. > > I seem to remember some of the Apache projects had a similar system, > where all of the developers on the project mailing list had a +1 > (accept) -1 (reject) or 0 (don't care) vote. > I don't want to overload us with too much process, but Matthew is right, > discussion should be based on the document and not the WSDL. > If the specification is wrong, we change it in the document first. > > Having reached a general agreement for the v0.21 document in Canada, we > need to keep the number and scope of the changes as small as possible. > Requiring an explicit change request for each modification means we have > to be very specific about exactly what we want to change. > > Having said that, if we find parts of the specification are difficult to > represent clearly in the WSDL, then this is a perfectly valid reason for > going back to the document and refactoring things. > > Hope this helps, > Dave > > ps. > To start things off, can you all send a +1, 0 or -1 for this. > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Fri Jun 16 12:37:54 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAbdpO021917 for ; Fri, 16 Jun 2006 12:37:39 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5GAbdTj021916 for vospace-outgoing; Fri, 16 Jun 2006 12:37:39 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAbMpO021852; Fri, 16 Jun 2006 12:37:23 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5GAbMXR015518 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 16 Jun 2006 12:37:22 +0200 In-Reply-To: <4490C914.2080302@ast.cam.ac.uk> References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> <4490C914.2080302@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B42AB00-F40F-48AB-98D1-AA1EA7E66DC5@eso.org> Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues (change requests) Date: Fri, 16 Jun 2006 12:37:23 +0200 To: Dave Morris X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 15.06.2006, at 04:42, Dave Morris wrote: > In order to help keep track of any changes we want to make, I would > like to suggest the following : > > 1) Any changes to the specification are done with reference to the > document not the WSDL. there need to be two change request streams, one for specification, one for document - that need of course to be co-ordinated. I do not believe that the information flow is always spec->wsdl - sometimes the WSDL changes inform the spec. > 2) For each change, we send a change request email to the mailing > list, detailing exactly what we need to change in the document and > why. > 3) Everyone gets a chance to accept or reject the change (within a > reasonable time limit). rather than used email, why not post the change request initially to the wiki and everyone vote on it there? - it is difficult to follow the email threads without voting going on in them as well.... I have edited the page for the WSDL/schema (http://www.ivoa.net/twiki/ bin/view/IVOA/VOSpace10schema) to include the list of currently requested changes, and represented your opinions on them where that is obvious (please check!) I have created a similar page for the specification document itself http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace10Spec with an opening change request - more to follow! Paul. > From owner-vospace@eso.org Fri Jun 16 12:42:14 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAg0pO022337 for ; Fri, 16 Jun 2006 12:42:00 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5GAg0Jq022336 for vospace-outgoing; Fri, 16 Jun 2006 12:42:00 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAfspO022326; Fri, 16 Jun 2006 12:41:55 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAfqQk002737; Fri, 16 Jun 2006 12:41:53 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:37483) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1FrBle-0001Cw-52 (Exim 4.54) (return-path ); Fri, 16 Jun 2006 11:41:35 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GAfX2C020757; Fri, 16 Jun 2006 11:41:33 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GAfXpO006052; Fri, 16 Jun 2006 11:41:33 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5GAfWcw006049; Fri, 16 Jun 2006 11:41:33 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 16 Jun 2006 11:41:32 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Matthew Graham cc: Dave Morris , IVOA VoSpace mailing list , Paul Harrison Subject: Re: 1.0rc1 WSDL issues [DIME vs. MTOM] In-Reply-To: <4491B6EC.9030001@cacr.caltech.edu> Message-ID: References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> <44905E4B.4070905@cacr.caltech.edu> <4491B6EC.9030001@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.16.25432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon On Thu, 15 Jun 2006, Matthew Graham wrote: > Guy Rixon wrote: > > >On Wed, 14 Jun 2006, Matthew Graham wrote: > >I agree with dumping DIME in favour of MTOM. > > > Dave does have a point, however, about MTOM support. I think that we > should leave DIME in now but note that it will be deprecated in the next > release and also introduce MTOM as the successor. Let's be a little careful about what we mean by "next release". We have established that VOSpace-1.x and VOSpace-2.x will coexist indefinitely. If we include DIME specifics in VOSpace 1.0 and deprecate DIME in VOSpace 2.0, then presumably we also have to deprcate DIME in VOSpace 1.1. To be clear, I think of VOSpace-1 and VOSpace-2 as two products, "VOSpace level 1 and "VOSpace level 2" rather than just two versions of one product. I vote that we leave out DIME altogether from VOSpace 1.0. We can put it, or MTOM, into VOSpace 1.1 or later when we need it. Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Fri Jun 16 12:51:13 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAotpO023246 for ; Fri, 16 Jun 2006 12:50:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5GAotlL023245 for vospace-outgoing; Fri, 16 Jun 2006 12:50:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAoopO023232 for ; Fri, 16 Jun 2006 12:50:50 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAolQk003133 for ; Fri, 16 Jun 2006 12:50:48 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:38275) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1FrBuL-0001GW-3G (Exim 4.54) (return-path ); Fri, 16 Jun 2006 11:50:33 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GAoUts021563; Fri, 16 Jun 2006 11:50:30 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GAoUbS006194; Fri, 16 Jun 2006 11:50:30 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5GAoUVI006191; Fri, 16 Jun 2006 11:50:30 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 16 Jun 2006 11:50:29 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Matthew Graham cc: Dave Morris , IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (create node params) In-Reply-To: <4491B37D.5030904@cacr.caltech.edu> Message-ID: References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.16.25432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Yes to introducing CreateTempNode as you have written it with these caveats: 1. Is createTempNode the best name? 2. Spec needs language making it clear that the node is created with a guaranteed-unique name. 3. Any other special semantics that we need to write down? 4. Is it a special type of node? (I suggest it can't be, since we only really have data nodes at this stage.) 5. The name parameter on the basic createNode will become mandatory if we make this change. Given that the node is an ordinary data-node and doesn't have any temporary-file semantics (c.f. the POSIX temporary files that disappear when the creating process exists), I suggest that createAndNameNode is a better name than createTempNode. (BTW, when we extend this to VOSpace 2, I hope we'll allow creation of auto-named container-nodes as well. But let's not get side-tracked by that now.) Cheers, Guy On Thu, 15 Jun 2006, Matthew Graham wrote: > Hi, > > I accept Dave's suggestions. > > I also accept Guy's suggestion for a separate operation for creating a > temporary node with a server-generated name and propose adding this text > to the spec: > > createTempNode > > Creates a temporary node in a space. This method is used to create a > temporary data node. > > Parameters: None > > Returns: A element for the new node. > > Faults: The service may throw an OperationNotSupported exception if it > does not support temporary nodes. > The service may throw an InternalFault exception if an > operation fails. > The service may throw a PermissionDenied exception if the > user does not have permissions to perform the operation. > > Questions: > - Should a properties structure be an optional parameter? > - A user can always make a temporary node permanent by renaming it to > something more meaningful. > > Cheers, > > Matthew > > > > Guy Rixon wrote: > > >Use case for server-generated names: when clients working in the same space > >want to generate temporary files with unique names. Java File.makeTempFile() > >and all that. If we support this, it might deserve its own operation with > >different parameters from createNode. > > > >On Thu, 15 Jun 2006, Dave Morris wrote: > > > > > > > >>Paul Harrison wrote: > >> > >> > >> > >>>On 14.06.2006, at 14:01, Dave Morris wrote: > >>> > >>> > >>> > >>>>However, when creating a new node, it was agreed that the client > >>>>would supply the name as a plain text string, and the server would > >>>>convert this into the URI encoded identifier. > >>>>This means that the server side code does the URI encoding, making > >>>>it easier to verify that we get it right. > >>>> > >>>> > >>>>The operations that create a new node (CreateNode, PushDataTo and > >>>>PullDataTo) take the name of the new node, not the identifier. > >>>>This gives us a way of distinguishing between import into an > >>>>existing node (node URI) and import into a new node (node name). > >>>> > >>>> > >>>also I think that there was also the idea that the server would > >>>generate a name automatically so the URI could point to a container... > >>> > >>> > >>> > >>>>The distinction still isn't as clear as I would like, but that is > >>>>what is in the current document. > >>>>If we want to change this, then we will need to modify the document. > >>>> > >>>> > >>>I think that the semantics of these operations are not still clear as > >>>currently implemented in the WSDL, and do need some work > >>> > >>> > >>I too was struggling with how to represent these multiple parameters in > >>the experimental WSDL examples I posted last week. > >>If they are causing problems, do we want to look at these again, and > >>possibly simplify them. > >> > >>---- > >> > >>Server generated identifiers : > >>The original reason for server generated identifiers dates back to when > >>we had two separate namespaces, VOSpace with user defined names, and > >>VOStore with server generated names. > >>The VOStore service needed to generate the names in order to ensure that > >>they were unique within that service. > >> > >>Now that we have brought everything into one VOSpace namespace, I don't > >>think we need the server generated names any more. > >>In which case, unless anyone has a compelling use case for this, I vote > >>we drop it. > >> > >>---- > >> > >>Plain string name : > >>I proposed the idea of using the separate name and URI in methods that > >>created nodes, primarily because I wanted to make the server responsible > >>for encoding the URI correctly. > >>The client would just supply the name as a plain text string, and the > >>server would encode it to create the full URI identifier. > >> > >>However, both of us have found problems trying to define a clear and > >>concise WSDL that distinguishes between an import operation that creates > >>a new node and one that imports data into an existing node. In which > >>case, it looks like having the separate name parameter for creating a > >>new node is causing us more problems than it is worth. > >> > >>---- > >> > >>For VoSpace-1.0 I propose we drop both the server generated names and > >>the separate name as string parameter. > >> > >>1) CreateNode takes a mandatory target URI of the new node, rather than > >>the optional string name. > >>The target URI cannot be null, and the service does not automatically > >>generate new names. > >>It is up to the client to create and encode the target URI correctly. > >>If the server receives an invalid URI, it throws an Exception. > >> > >>2) The two import methods also take a single URI parameter to identify > >>the target node. > >>The target URI cannot be null, and the service does not automatically > >>generate new names. > >>It is up to the client to create and encode the target URI correctly. > >>If the server receives an invalid URI, it throws an Exception. > >>If the target node already exists, then its contents will be replaced by > >>the import. > >>If the target node does not exist, then the import methods will create a > >>new node and import the data into that. > >>(this also implies that the flag is no longer needed either) > >> > >>Then, to make things symmetrical : > >> > >>3) MoveNode takes two URIs, representing the source and destination. > >>The source URI cannot be null and must point to an existing node. > >>The destination URI cannot be null, and must NOT point to an existing node. > >>If a node already exists with the destination URI, then the method > >>throws a DuplicateNodeException. > >>It is up to the client to create and encode the destination URI correctly. > >>If the server receives an invalid URI, it throws an Exception. > >> > >>4) CopyNode takes two URIs, representing the source and destination. > >>The source URI cannot be null and must point to an existing node. > >>The destination URI cannot be null, and must NOT point to an existing node. > >>If a node already exists with the destination URI, then the method > >>throws a DuplicateNodeException. > >>It is up to the client to create and encode the destination URI correctly. > >>If the server receives an invalid URI, it throws an Exception. > >> > >>To support client encoded URIs : > >> > >>5) We need to add MalformedIdentifierException to the list of exceptions > >>for all the methods that take URI parameters. > >> > >>Hopefully, this should make the service API and WSDL a lot clearer. > >> > >>One caveat : > >>I would like to re-visit this when we look at v2.x, based on what we > >>find using v1.0 in real applications. > >> > >>---- > >> > >>Matthew is right when he says that if we have any changes we should be > >>discussing them in the document, and not the WSDL. > >>The WSDL should reflect the specification as defined in the document, > >>presenting it in a machine readable form. > >> > >>So, based on the fact that both Paul and I have both found problems in > >>creating a clear and concise WSDL to represent this part of the > >>specification and that the original use cases for the extra parameters > >>are either no longer valid or not worth the hassle. > >>I propose we make the above changes to the specification document, and > >>then update the WSDL to match. > >> > >>Guy, Matthew, and Paul can you reply with 'accept' or 'reject' for the > >>five changes outlined above. > >>If everyone says yes, then we can update the document tomorrow and > >>publish it as v0.22. > >> > >>I know this is a bit formal and possibly OTT, but I suspect that we will > >>be making quite a few changes like this over the next few days. > >>Making specific requests for individual changes to the document should > >>make it easier to keep track of everything. > >> > >>I know there is at least one case where I found the list of exceptions > >>was wrong on one of the methods, but right now I can't remember where it > >>was. > >>If I find it again I'll post another change request with the details. > >> > >>There are also a couple of questions / suggestions I would like to raise > >>regarding data types and formats. > >>I'll post another change request when I have worked out the details. > >> > >>Thanks, > >>Dave > >> > >> > >> > > > >Guy Rixon gtr@ast.cam.ac.uk > >Institute of Astronomy Tel: +44-1223-337542 > >Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > > > > > > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Fri Jun 16 12:57:51 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAvcpO023929 for ; Fri, 16 Jun 2006 12:57:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5GAvcvf023928 for vospace-outgoing; Fri, 16 Jun 2006 12:57:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GAvRpO023913; Fri, 16 Jun 2006 12:57:27 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5GAvQ48009810 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 16 Jun 2006 12:57:27 +0200 In-Reply-To: <44901FC1.30908@ast.cam.ac.uk> References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues - asynchronous calls Date: Fri, 16 Jun 2006 12:57:26 +0200 To: Dave Morris X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison I am sorry to keep banging on about this, but we cannot brush asynchronicity under the carpet as a "2.0" issue when we still actually have it present in the 1.0 interface... I think that we need to be clear in the specification exactly how we expect this calls to behave - i.e. whether the web service call is expected to complete before the data transfer has taken place - if we say that there is no asynchronicity in 1.0 implementors might take it to mean that pushDataFromVoSpace should not return until the data transfer has taken place - which is probably not the behaviour we want - right? Paul. On 14.06.2006, at 16:40, Dave Morris wrote: > Paul Harrison wrote: > >> On 14.06.2006, at 13:52, Dave Morris wrote: >> >>> This implies asynchronous transfers, which we have not defined >>> in enough detail yet. >> >> We have asynchronous transfers - are not the push bulk data >> methods asynchronous, web service call finishes before data has >> arrived? Certainly pushDataToVoSpace is.... > > Yep, you are right, PushdataToVoSpace is asynchronous. > However, the client is controlling the push, so it already knows > when it has finished sending the data. From owner-vospace@eso.org Fri Jun 16 16:12:18 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEBspO018146 for ; Fri, 16 Jun 2006 16:11:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5GEBsc8018145 for vospace-outgoing; Fri, 16 Jun 2006 16:11:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEBkpO018127 for ; Fri, 16 Jun 2006 16:11:46 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEBiQk017292 for ; Fri, 16 Jun 2006 16:11:44 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:54174) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1FrF2l-0001ah-ON (Exim 4.54) (return-path ); Fri, 16 Jun 2006 15:11:27 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GEBQ0u009808; Fri, 16 Jun 2006 15:11:26 +0100 (BST) Message-ID: <4492BC0E.4020301@ast.cam.ac.uk> Date: Fri, 16 Jun 2006 15:11:26 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues - asynchronous calls References: <448FF885.5060901@ast.cam.ac.uk> <07415963-4B65-4A24-930B-6D1810C85559@eso.org> <44901FC1.30908@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.183432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > I am sorry to keep banging on about this, but we cannot brush > asynchronicity under the carpet as a "2.0" issue when we still > actually have it present in the 1.0 interface... I think that we need > to be clear in the specification exactly how we expect this calls to > behave. Yep - I agree. The fact that questions about this are appearing in emails means that the document isn't clear enough. I'll write a new bit of description for each - being explicit about the sequence. I'll post the new descriptions to the document change wiki page. Dave From owner-vospace@eso.org Fri Jun 16 16:17:45 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEHEpO019143 for ; Fri, 16 Jun 2006 16:17:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5GEHEof019141 for vospace-outgoing; Fri, 16 Jun 2006 16:17:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEGlpO019062 for ; Fri, 16 Jun 2006 16:16:47 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEGiQk017704 for ; Fri, 16 Jun 2006 16:16:45 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:54596) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1FrF7i-00047J-O8 (Exim 4.54) (return-path ); Fri, 16 Jun 2006 15:16:34 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GEGV7D010282; Fri, 16 Jun 2006 15:16:31 +0100 (BST) Message-ID: <4492BD3F.6020804@ast.cam.ac.uk> Date: Fri, 16 Jun 2006 15:16:31 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (create node params) References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.183432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris How about calling it CreateUniqueNode ? Takes optional set of properties and returns a new DataNode with a unique name within the space. We can add a type parameter in VoSpace-2.x to allow this to create other types of node, including containers. Dave Guy Rixon wrote: >Yes to introducing CreateTempNode as you have written it with these caveats: > >1. Is createTempNode the best name? > >2. Spec needs language making it clear that the node is created with a >guaranteed-unique name. > >3. Any other special semantics that we need to write down? > >4. Is it a special type of node? (I suggest it can't be, since we only really >have data nodes at this stage.) > >5. The name parameter on the basic createNode will become mandatory if we make >this change. > >Given that the node is an ordinary data-node and doesn't have any >temporary-file semantics (c.f. the POSIX temporary files that disappear when >the creating process exists), I suggest that createAndNameNode is a better >name than createTempNode. > >(BTW, when we extend this to VOSpace 2, I hope we'll allow creation of >auto-named container-nodes as well. But let's not get side-tracked by that >now.) > >Cheers, >Guy > >On Thu, 15 Jun 2006, Matthew Graham wrote: > > > >>Hi, >> >>I accept Dave's suggestions. >> >>I also accept Guy's suggestion for a separate operation for creating a >>temporary node with a server-generated name and propose adding this text >>to the spec: >> >>createTempNode >> >>Creates a temporary node in a space. This method is used to create a >>temporary data node. >> >>Parameters: None >> >>Returns: A element for the new node. >> >>Faults: The service may throw an OperationNotSupported exception if it >>does not support temporary nodes. >> The service may throw an InternalFault exception if an >>operation fails. >> The service may throw a PermissionDenied exception if the >>user does not have permissions to perform the operation. >> >>Questions: >>- Should a properties structure be an optional parameter? >>- A user can always make a temporary node permanent by renaming it to >>something more meaningful. >> >> Cheers, >> >> Matthew >> >> >> >>Guy Rixon wrote: >> >> >> >>>Use case for server-generated names: when clients working in the same space >>>want to generate temporary files with unique names. Java File.makeTempFile() >>>and all that. If we support this, it might deserve its own operation with >>>different parameters from createNode. >>> >>>On Thu, 15 Jun 2006, Dave Morris wrote: >>> >>> >>> >>> >>> >>>>Paul Harrison wrote: >>>> >>>> >>>> >>>> >>>> >>>>>On 14.06.2006, at 14:01, Dave Morris wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>However, when creating a new node, it was agreed that the client >>>>>>would supply the name as a plain text string, and the server would >>>>>>convert this into the URI encoded identifier. >>>>>>This means that the server side code does the URI encoding, making >>>>>>it easier to verify that we get it right. >>>>>> >>>>>> >>>>>>The operations that create a new node (CreateNode, PushDataTo and >>>>>>PullDataTo) take the name of the new node, not the identifier. >>>>>>This gives us a way of distinguishing between import into an >>>>>>existing node (node URI) and import into a new node (node name). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>also I think that there was also the idea that the server would >>>>>generate a name automatically so the URI could point to a container... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>The distinction still isn't as clear as I would like, but that is >>>>>>what is in the current document. >>>>>>If we want to change this, then we will need to modify the document. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I think that the semantics of these operations are not still clear as >>>>>currently implemented in the WSDL, and do need some work >>>>> >>>>> >>>>> >>>>> >>>>I too was struggling with how to represent these multiple parameters in >>>>the experimental WSDL examples I posted last week. >>>>If they are causing problems, do we want to look at these again, and >>>>possibly simplify them. >>>> >>>>---- >>>> >>>>Server generated identifiers : >>>>The original reason for server generated identifiers dates back to when >>>>we had two separate namespaces, VOSpace with user defined names, and >>>>VOStore with server generated names. >>>>The VOStore service needed to generate the names in order to ensure that >>>>they were unique within that service. >>>> >>>>Now that we have brought everything into one VOSpace namespace, I don't >>>>think we need the server generated names any more. >>>>In which case, unless anyone has a compelling use case for this, I vote >>>>we drop it. >>>> >>>>---- >>>> >>>>Plain string name : >>>>I proposed the idea of using the separate name and URI in methods that >>>>created nodes, primarily because I wanted to make the server responsible >>>>for encoding the URI correctly. >>>>The client would just supply the name as a plain text string, and the >>>>server would encode it to create the full URI identifier. >>>> >>>>However, both of us have found problems trying to define a clear and >>>>concise WSDL that distinguishes between an import operation that creates >>>>a new node and one that imports data into an existing node. In which >>>>case, it looks like having the separate name parameter for creating a >>>>new node is causing us more problems than it is worth. >>>> >>>>---- >>>> >>>>For VoSpace-1.0 I propose we drop both the server generated names and >>>>the separate name as string parameter. >>>> >>>>1) CreateNode takes a mandatory target URI of the new node, rather than >>>>the optional string name. >>>>The target URI cannot be null, and the service does not automatically >>>>generate new names. >>>>It is up to the client to create and encode the target URI correctly. >>>>If the server receives an invalid URI, it throws an Exception. >>>> >>>>2) The two import methods also take a single URI parameter to identify >>>>the target node. >>>>The target URI cannot be null, and the service does not automatically >>>>generate new names. >>>>It is up to the client to create and encode the target URI correctly. >>>>If the server receives an invalid URI, it throws an Exception. >>>>If the target node already exists, then its contents will be replaced by >>>>the import. >>>>If the target node does not exist, then the import methods will create a >>>>new node and import the data into that. >>>>(this also implies that the flag is no longer needed either) >>>> >>>>Then, to make things symmetrical : >>>> >>>>3) MoveNode takes two URIs, representing the source and destination. >>>>The source URI cannot be null and must point to an existing node. >>>>The destination URI cannot be null, and must NOT point to an existing node. >>>>If a node already exists with the destination URI, then the method >>>>throws a DuplicateNodeException. >>>>It is up to the client to create and encode the destination URI correctly. >>>>If the server receives an invalid URI, it throws an Exception. >>>> >>>>4) CopyNode takes two URIs, representing the source and destination. >>>>The source URI cannot be null and must point to an existing node. >>>>The destination URI cannot be null, and must NOT point to an existing node. >>>>If a node already exists with the destination URI, then the method >>>>throws a DuplicateNodeException. >>>>It is up to the client to create and encode the destination URI correctly. >>>>If the server receives an invalid URI, it throws an Exception. >>>> >>>>To support client encoded URIs : >>>> >>>>5) We need to add MalformedIdentifierException to the list of exceptions >>>>for all the methods that take URI parameters. >>>> >>>>Hopefully, this should make the service API and WSDL a lot clearer. >>>> >>>>One caveat : >>>>I would like to re-visit this when we look at v2.x, based on what we >>>>find using v1.0 in real applications. >>>> >>>>---- >>>> >>>>Matthew is right when he says that if we have any changes we should be >>>>discussing them in the document, and not the WSDL. >>>>The WSDL should reflect the specification as defined in the document, >>>>presenting it in a machine readable form. >>>> >>>>So, based on the fact that both Paul and I have both found problems in >>>>creating a clear and concise WSDL to represent this part of the >>>>specification and that the original use cases for the extra parameters >>>>are either no longer valid or not worth the hassle. >>>>I propose we make the above changes to the specification document, and >>>>then update the WSDL to match. >>>> >>>>Guy, Matthew, and Paul can you reply with 'accept' or 'reject' for the >>>>five changes outlined above. >>>>If everyone says yes, then we can update the document tomorrow and >>>>publish it as v0.22. >>>> >>>>I know this is a bit formal and possibly OTT, but I suspect that we will >>>>be making quite a few changes like this over the next few days. >>>>Making specific requests for individual changes to the document should >>>>make it easier to keep track of everything. >>>> >>>>I know there is at least one case where I found the list of exceptions >>>>was wrong on one of the methods, but right now I can't remember where it >>>>was. >>>>If I find it again I'll post another change request with the details. >>>> >>>>There are also a couple of questions / suggestions I would like to raise >>>>regarding data types and formats. >>>>I'll post another change request when I have worked out the details. >>>> >>>>Thanks, >>>>Dave >>>> >>>> >>>> >>>> >>>> >>>Guy Rixon gtr@ast.cam.ac.uk >>>Institute of Astronomy Tel: +44-1223-337542 >>>Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>> >>> >>> >>> >>> > >Guy Rixon gtr@ast.cam.ac.uk >Institute of Astronomy Tel: +44-1223-337542 >Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > From owner-vospace@eso.org Fri Jun 16 16:40:08 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEdkpO021870 for ; Fri, 16 Jun 2006 16:39:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5GEdkDL021869 for vospace-outgoing; Fri, 16 Jun 2006 16:39:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEdUpO021829 for ; Fri, 16 Jun 2006 16:39:30 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5GEdRQk019096 for ; Fri, 16 Jun 2006 16:39:28 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:56492) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1FrFTh-0002Bs-UQ (Exim 4.54) for vospace@ivoa.net (return-path ); Fri, 16 Jun 2006 15:39:17 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GEdEXk012352; Fri, 16 Jun 2006 15:39:15 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5GEdEeB007900; Fri, 16 Jun 2006 15:39:14 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5GEdEPd007897; Fri, 16 Jun 2006 15:39:14 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 16 Jun 2006 15:39:14 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Dave Morris cc: IVOA VoSpace mailing list Subject: Re: 1.0rc1 WSDL issues (create node params) In-Reply-To: <4492BD3F.6020804@ast.cam.ac.uk> Message-ID: References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> <4492BD3F.6020804@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.16.65432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon CreateUniqueNode is fine by me. On Fri, 16 Jun 2006, Dave Morris wrote: > How about calling it CreateUniqueNode ? > Takes optional set of properties and returns a new DataNode with a > unique name within the space. > > We can add a type parameter in VoSpace-2.x to allow this to create other > types of node, including containers. > > Dave > > Guy Rixon wrote: > > >Yes to introducing CreateTempNode as you have written it with these caveats: > > > >1. Is createTempNode the best name? > > > >2. Spec needs language making it clear that the node is created with a > >guaranteed-unique name. > > > >3. Any other special semantics that we need to write down? > > > >4. Is it a special type of node? (I suggest it can't be, since we only really > >have data nodes at this stage.) > > > >5. The name parameter on the basic createNode will become mandatory if we make > >this change. > > > >Given that the node is an ordinary data-node and doesn't have any > >temporary-file semantics (c.f. the POSIX temporary files that disappear when > >the creating process exists), I suggest that createAndNameNode is a better > >name than createTempNode. > > > >(BTW, when we extend this to VOSpace 2, I hope we'll allow creation of > >auto-named container-nodes as well. But let's not get side-tracked by that > >now.) > > > >Cheers, > >Guy > > > >On Thu, 15 Jun 2006, Matthew Graham wrote: > > > > > > > >>Hi, > >> > >>I accept Dave's suggestions. > >> > >>I also accept Guy's suggestion for a separate operation for creating a > >>temporary node with a server-generated name and propose adding this text > >>to the spec: > >> > >>createTempNode > >> > >>Creates a temporary node in a space. This method is used to create a > >>temporary data node. > >> > >>Parameters: None > >> > >>Returns: A element for the new node. > >> > >>Faults: The service may throw an OperationNotSupported exception if it > >>does not support temporary nodes. > >> The service may throw an InternalFault exception if an > >>operation fails. > >> The service may throw a PermissionDenied exception if the > >>user does not have permissions to perform the operation. > >> > >>Questions: > >>- Should a properties structure be an optional parameter? > >>- A user can always make a temporary node permanent by renaming it to > >>something more meaningful. > >> > >> Cheers, > >> > >> Matthew > >> > >> > >> > >>Guy Rixon wrote: > >> > >> > >> > >>>Use case for server-generated names: when clients working in the same space > >>>want to generate temporary files with unique names. Java File.makeTempFile() > >>>and all that. If we support this, it might deserve its own operation with > >>>different parameters from createNode. > >>> > >>>On Thu, 15 Jun 2006, Dave Morris wrote: > >>> > >>> > >>> > >>> > >>> > >>>>Paul Harrison wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>On 14.06.2006, at 14:01, Dave Morris wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>However, when creating a new node, it was agreed that the client > >>>>>>would supply the name as a plain text string, and the server would > >>>>>>convert this into the URI encoded identifier. > >>>>>>This means that the server side code does the URI encoding, making > >>>>>>it easier to verify that we get it right. > >>>>>> > >>>>>> > >>>>>>The operations that create a new node (CreateNode, PushDataTo and > >>>>>>PullDataTo) take the name of the new node, not the identifier. > >>>>>>This gives us a way of distinguishing between import into an > >>>>>>existing node (node URI) and import into a new node (node name). > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>also I think that there was also the idea that the server would > >>>>>generate a name automatically so the URI could point to a container... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>The distinction still isn't as clear as I would like, but that is > >>>>>>what is in the current document. > >>>>>>If we want to change this, then we will need to modify the document. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>I think that the semantics of these operations are not still clear as > >>>>>currently implemented in the WSDL, and do need some work > >>>>> > >>>>> > >>>>> > >>>>> > >>>>I too was struggling with how to represent these multiple parameters in > >>>>the experimental WSDL examples I posted last week. > >>>>If they are causing problems, do we want to look at these again, and > >>>>possibly simplify them. > >>>> > >>>>---- > >>>> > >>>>Server generated identifiers : > >>>>The original reason for server generated identifiers dates back to when > >>>>we had two separate namespaces, VOSpace with user defined names, and > >>>>VOStore with server generated names. > >>>>The VOStore service needed to generate the names in order to ensure that > >>>>they were unique within that service. > >>>> > >>>>Now that we have brought everything into one VOSpace namespace, I don't > >>>>think we need the server generated names any more. > >>>>In which case, unless anyone has a compelling use case for this, I vote > >>>>we drop it. > >>>> > >>>>---- > >>>> > >>>>Plain string name : > >>>>I proposed the idea of using the separate name and URI in methods that > >>>>created nodes, primarily because I wanted to make the server responsible > >>>>for encoding the URI correctly. > >>>>The client would just supply the name as a plain text string, and the > >>>>server would encode it to create the full URI identifier. > >>>> > >>>>However, both of us have found problems trying to define a clear and > >>>>concise WSDL that distinguishes between an import operation that creates > >>>>a new node and one that imports data into an existing node. In which > >>>>case, it looks like having the separate name parameter for creating a > >>>>new node is causing us more problems than it is worth. > >>>> > >>>>---- > >>>> > >>>>For VoSpace-1.0 I propose we drop both the server generated names and > >>>>the separate name as string parameter. > >>>> > >>>>1) CreateNode takes a mandatory target URI of the new node, rather than > >>>>the optional string name. > >>>>The target URI cannot be null, and the service does not automatically > >>>>generate new names. > >>>>It is up to the client to create and encode the target URI correctly. > >>>>If the server receives an invalid URI, it throws an Exception. > >>>> > >>>>2) The two import methods also take a single URI parameter to identify > >>>>the target node. > >>>>The target URI cannot be null, and the service does not automatically > >>>>generate new names. > >>>>It is up to the client to create and encode the target URI correctly. > >>>>If the server receives an invalid URI, it throws an Exception. > >>>>If the target node already exists, then its contents will be replaced by > >>>>the import. > >>>>If the target node does not exist, then the import methods will create a > >>>>new node and import the data into that. > >>>>(this also implies that the flag is no longer needed either) > >>>> > >>>>Then, to make things symmetrical : > >>>> > >>>>3) MoveNode takes two URIs, representing the source and destination. > >>>>The source URI cannot be null and must point to an existing node. > >>>>The destination URI cannot be null, and must NOT point to an existing node. > >>>>If a node already exists with the destination URI, then the method > >>>>throws a DuplicateNodeException. > >>>>It is up to the client to create and encode the destination URI correctly. > >>>>If the server receives an invalid URI, it throws an Exception. > >>>> > >>>>4) CopyNode takes two URIs, representing the source and destination. > >>>>The source URI cannot be null and must point to an existing node. > >>>>The destination URI cannot be null, and must NOT point to an existing node. > >>>>If a node already exists with the destination URI, then the method > >>>>throws a DuplicateNodeException. > >>>>It is up to the client to create and encode the destination URI correctly. > >>>>If the server receives an invalid URI, it throws an Exception. > >>>> > >>>>To support client encoded URIs : > >>>> > >>>>5) We need to add MalformedIdentifierException to the list of exceptions > >>>>for all the methods that take URI parameters. > >>>> > >>>>Hopefully, this should make the service API and WSDL a lot clearer. > >>>> > >>>>One caveat : > >>>>I would like to re-visit this when we look at v2.x, based on what we > >>>>find using v1.0 in real applications. > >>>> > >>>>---- > >>>> > >>>>Matthew is right when he says that if we have any changes we should be > >>>>discussing them in the document, and not the WSDL. > >>>>The WSDL should reflect the specification as defined in the document, > >>>>presenting it in a machine readable form. > >>>> > >>>>So, based on the fact that both Paul and I have both found problems in > >>>>creating a clear and concise WSDL to represent this part of the > >>>>specification and that the original use cases for the extra parameters > >>>>are either no longer valid or not worth the hassle. > >>>>I propose we make the above changes to the specification document, and > >>>>then update the WSDL to match. > >>>> > >>>>Guy, Matthew, and Paul can you reply with 'accept' or 'reject' for the > >>>>five changes outlined above. > >>>>If everyone says yes, then we can update the document tomorrow and > >>>>publish it as v0.22. > >>>> > >>>>I know this is a bit formal and possibly OTT, but I suspect that we will > >>>>be making quite a few changes like this over the next few days. > >>>>Making specific requests for individual changes to the document should > >>>>make it easier to keep track of everything. > >>>> > >>>>I know there is at least one case where I found the list of exceptions > >>>>was wrong on one of the methods, but right now I can't remember where it > >>>>was. > >>>>If I find it again I'll post another change request with the details. > >>>> > >>>>There are also a couple of questions / suggestions I would like to raise > >>>>regarding data types and formats. > >>>>I'll post another change request when I have worked out the details. > >>>> > >>>>Thanks, > >>>>Dave > >>>> > >>>> > >>>> > >>>> > >>>> > >>>Guy Rixon gtr@ast.cam.ac.uk > >>>Institute of Astronomy Tel: +44-1223-337542 > >>>Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > >>> > >>> > >>> > >>> > >>> > > > >Guy Rixon gtr@ast.cam.ac.uk > >Institute of Astronomy Tel: +44-1223-337542 > >Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > > > > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Mon Jun 19 15:10:19 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5JD9p4V022593 for ; Mon, 19 Jun 2006 15:09:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5JD9pET022592 for vospace-outgoing; Mon, 19 Jun 2006 15:09:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5JD9J4V022510 for ; Mon, 19 Jun 2006 15:09:20 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5JD9JXR008148 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Jun 2006 15:09:19 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <4007F458-A29E-41B5-9CC9-25D7F21FB83F@eso.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IVOA mailing list VoSpace From: Paul Harrison Subject: Mandatory transports for VOSpace - why not? Date: Mon, 19 Jun 2006 15:09:19 +0200 X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison I think I have made it pretty clear why I think that the VOSpace specification should include some mandatory protocols - i.e. so that VOSpace implementations that are compliant have a common set of protocols that they can interoperate with - I genuinely do not understand the arguments for *not* mandating some protocols - can someone put forward these arguments? Paul Harrison ESO From owner-vospace@eso.org Mon Jun 19 15:27:29 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5JDRD4V025796 for ; Mon, 19 Jun 2006 15:27:13 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5JDRD0B025795 for vospace-outgoing; Mon, 19 Jun 2006 15:27:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5JDQv4V025736; Mon, 19 Jun 2006 15:26:57 +0200 (MEST) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5JDQsQk013879; Mon, 19 Jun 2006 15:26:55 +0200 (CEST) Received: from dropbox.aoc.nrao.edu (dropbox.aoc.nrao.edu [146.88.1.13]) by revere.aoc.nrao.edu (8.13.1/8.13.1/cv-ws-8.12) with ESMTP id k5JDQKcS010082; Mon, 19 Jun 2006 07:26:20 -0600 Received: from localhost (localhost [[UNIX: localhost]]) by dropbox.aoc.nrao.edu (8.13.1/8.13.1/Submit) id k5JDQKNw030335; Mon, 19 Jun 2006 07:26:20 -0600 Date: Mon, 19 Jun 2006 07:26:16 -0600 (MDT) From: Doug Tody X-X-Sender: dtody@localhost.localdomain To: Paul Harrison cc: IVOA mailing list VoSpace Subject: Re: Mandatory transports for VOSpace - why not? In-Reply-To: <4007F458-A29E-41B5-9CC9-25D7F21FB83F@eso.org> Message-ID: References: <4007F458-A29E-41B5-9CC9-25D7F21FB83F@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-101.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44, USER_IN_WHITELIST -100.00) X-MailScanner-From: dtody@aoc.nrao.edu X-Spam-Status: No X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.19.55433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Doug Tody I should think that support for at least HTTP would be mandatory. Clearly though, one would want to limit the number of mandatory protocols to a very small number (using widely standardized technologies likely to available in all implementation environments), with everything else being optional. - Doug On Mon, 19 Jun 2006, Paul Harrison wrote: > I think I have made it pretty clear why I think that the VOSpace > specification should include some mandatory protocols - i.e. so that VOSpace > implementations that are compliant have a common set of protocols that they > can interoperate with - I genuinely do not understand the arguments for *not* > mandating some protocols - can someone put forward these arguments? > > Paul Harrison > ESO From owner-vospace@eso.org Tue Jun 20 09:13:12 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K7CwP0022058 for ; Tue, 20 Jun 2006 09:12:58 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5K7Cwbr022057 for vospace-outgoing; Tue, 20 Jun 2006 09:12:58 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K7CrP0022044 for ; Tue, 20 Jun 2006 09:12:54 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5K7CrXR004042 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 20 Jun 2006 09:12:53 +0200 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> <4492BD3F.6020804@ast.cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues (create node params) Date: Tue, 20 Jun 2006 09:12:53 +0200 To: IVOA list VoSpace mailing X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison Cannot the functionality be simply overloaded on createNode? If we say that copyNode/moveNode and the import data methods simply do what they are told i.e. write to the data item that is pointed to by the vos: URL in their parameters, creating when necessary, then all "special" node creation could be done with createNode. Not a crucial point, but for a v1.0 VOSpace it is rather difficult to see a use case for createNode (which really has more relevance for links/containers).... On 16.06.2006, at 16:39, Guy Rixon wrote: > CreateUniqueNode is fine by me. > > On Fri, 16 Jun 2006, Dave Morris wrote: > >> How about calling it CreateUniqueNode ? >> Takes optional set of properties and returns a new DataNode with a >> unique name within the space. >> >> We can add a type parameter in VoSpace-2.x to allow this to create >> other >> types of node, including containers. >> >> Dave >> >> Guy Rixon wrote: >> >>> Yes to introducing CreateTempNode as you have written it with >>> these caveats: >>> >>> 1. Is createTempNode the best name? >>> >>> 2. Spec needs language making it clear that the node is created >>> with a >>> guaranteed-unique name. >>> >>> 3. Any other special semantics that we need to write down? >>> >>> 4. Is it a special type of node? (I suggest it can't be, since we >>> only really >>> have data nodes at this stage.) >>> >>> 5. The name parameter on the basic createNode will become >>> mandatory if we make >>> this change. >>> >>> Given that the node is an ordinary data-node and doesn't have any >>> temporary-file semantics (c.f. the POSIX temporary files that >>> disappear when >>> the creating process exists), I suggest that createAndNameNode is >>> a better >>> name than createTempNode. >>> >>> (BTW, when we extend this to VOSpace 2, I hope we'll allow >>> creation of >>> auto-named container-nodes as well. But let's not get side- >>> tracked by that >>> now.) >>> >>> Cheers, >>> Guy >>> >>> On Thu, 15 Jun 2006, Matthew Graham wrote: >>> >>> >>> >>>> Hi, >>>> >>>> I accept Dave's suggestions. >>>> >>>> I also accept Guy's suggestion for a separate operation for >>>> creating a >>>> temporary node with a server-generated name and propose adding >>>> this text >>>> to the spec: >>>> >>>> createTempNode >>>> >>>> Creates a temporary node in a space. This method is used to >>>> create a >>>> temporary data node. >>>> >>>> Parameters: None >>>> >>>> Returns: A element for the new node. >>>> >>>> Faults: The service may throw an OperationNotSupported >>>> exception if it >>>> does not support temporary nodes. >>>> The service may throw an InternalFault exception if an >>>> operation fails. >>>> The service may throw a PermissionDenied exception >>>> if the >>>> user does not have permissions to perform the operation. >>>> >>>> Questions: >>>> - Should a properties structure be an optional parameter? >>>> - A user can always make a temporary node permanent by renaming >>>> it to >>>> something more meaningful. >>>> >>>> Cheers, >>>> >>>> Matthew >>>> >>>> >>>> >>>> Guy Rixon wrote: >>>> >>>> >>>> >>>>> Use case for server-generated names: when clients working in >>>>> the same space >>>>> want to generate temporary files with unique names. Java >>>>> File.makeTempFile() >>>>> and all that. If we support this, it might deserve its own >>>>> operation with >>>>> different parameters from createNode. >>>>> >>>>> On Thu, 15 Jun 2006, Dave Morris wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Paul Harrison wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 14.06.2006, at 14:01, Dave Morris wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> However, when creating a new node, it was agreed that the >>>>>>>> client >>>>>>>> would supply the name as a plain text string, and the server >>>>>>>> would >>>>>>>> convert this into the URI encoded identifier. >>>>>>>> This means that the server side code does the URI encoding, >>>>>>>> making >>>>>>>> it easier to verify that we get it right. >>>>>>>> >>>>>>>> >>>>>>>> The operations that create a new node (CreateNode, >>>>>>>> PushDataTo and >>>>>>>> PullDataTo) take the name of the new node, not the identifier. >>>>>>>> This gives us a way of distinguishing between import into an >>>>>>>> existing node (node URI) and import into a new node (node >>>>>>>> name). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> also I think that there was also the idea that the server would >>>>>>> generate a name automatically so the URI could point to a >>>>>>> container... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The distinction still isn't as clear as I would like, but >>>>>>>> that is >>>>>>>> what is in the current document. >>>>>>>> If we want to change this, then we will need to modify the >>>>>>>> document. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I think that the semantics of these operations are not still >>>>>>> clear as >>>>>>> currently implemented in the WSDL, and do need some work >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I too was struggling with how to represent these multiple >>>>>> parameters in >>>>>> the experimental WSDL examples I posted last week. >>>>>> If they are causing problems, do we want to look at these >>>>>> again, and >>>>>> possibly simplify them. >>>>>> >>>>>> ---- >>>>>> >>>>>> Server generated identifiers : >>>>>> The original reason for server generated identifiers dates >>>>>> back to when >>>>>> we had two separate namespaces, VOSpace with user defined >>>>>> names, and >>>>>> VOStore with server generated names. >>>>>> The VOStore service needed to generate the names in order to >>>>>> ensure that >>>>>> they were unique within that service. >>>>>> >>>>>> Now that we have brought everything into one VOSpace >>>>>> namespace, I don't >>>>>> think we need the server generated names any more. >>>>>> In which case, unless anyone has a compelling use case for >>>>>> this, I vote >>>>>> we drop it. >>>>>> >>>>>> ---- >>>>>> >>>>>> Plain string name : >>>>>> I proposed the idea of using the separate name and URI in >>>>>> methods that >>>>>> created nodes, primarily because I wanted to make the server >>>>>> responsible >>>>>> for encoding the URI correctly. >>>>>> The client would just supply the name as a plain text string, >>>>>> and the >>>>>> server would encode it to create the full URI identifier. >>>>>> >>>>>> However, both of us have found problems trying to define a >>>>>> clear and >>>>>> concise WSDL that distinguishes between an import operation >>>>>> that creates >>>>>> a new node and one that imports data into an existing node. In >>>>>> which >>>>>> case, it looks like having the separate name parameter for >>>>>> creating a >>>>>> new node is causing us more problems than it is worth. >>>>>> >>>>>> ---- >>>>>> >>>>>> For VoSpace-1.0 I propose we drop both the server generated >>>>>> names and >>>>>> the separate name as string parameter. >>>>>> >>>>>> 1) CreateNode takes a mandatory target URI of the new node, >>>>>> rather than >>>>>> the optional string name. >>>>>> The target URI cannot be null, and the service does not >>>>>> automatically >>>>>> generate new names. >>>>>> It is up to the client to create and encode the target URI >>>>>> correctly. >>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>> >>>>>> 2) The two import methods also take a single URI parameter to >>>>>> identify >>>>>> the target node. >>>>>> The target URI cannot be null, and the service does not >>>>>> automatically >>>>>> generate new names. >>>>>> It is up to the client to create and encode the target URI >>>>>> correctly. >>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>> If the target node already exists, then its contents will be >>>>>> replaced by >>>>>> the import. >>>>>> If the target node does not exist, then the import methods >>>>>> will create a >>>>>> new node and import the data into that. >>>>>> (this also implies that the flag is no longer needed >>>>>> either) >>>>>> >>>>>> Then, to make things symmetrical : >>>>>> >>>>>> 3) MoveNode takes two URIs, representing the source and >>>>>> destination. >>>>>> The source URI cannot be null and must point to an existing node. >>>>>> The destination URI cannot be null, and must NOT point to an >>>>>> existing node. >>>>>> If a node already exists with the destination URI, then the >>>>>> method >>>>>> throws a DuplicateNodeException. >>>>>> It is up to the client to create and encode the destination >>>>>> URI correctly. >>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>> >>>>>> 4) CopyNode takes two URIs, representing the source and >>>>>> destination. >>>>>> The source URI cannot be null and must point to an existing node. >>>>>> The destination URI cannot be null, and must NOT point to an >>>>>> existing node. >>>>>> If a node already exists with the destination URI, then the >>>>>> method >>>>>> throws a DuplicateNodeException. >>>>>> It is up to the client to create and encode the destination >>>>>> URI correctly. >>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>> >>>>>> To support client encoded URIs : >>>>>> >>>>>> 5) We need to add MalformedIdentifierException to the list of >>>>>> exceptions >>>>>> for all the methods that take URI parameters. >>>>>> >>>>>> Hopefully, this should make the service API and WSDL a lot >>>>>> clearer. >>>>>> >>>>>> One caveat : >>>>>> I would like to re-visit this when we look at v2.x, based on >>>>>> what we >>>>>> find using v1.0 in real applications. >>>>>> >>>>>> ---- >>>>>> >>>>>> Matthew is right when he says that if we have any changes we >>>>>> should be >>>>>> discussing them in the document, and not the WSDL. >>>>>> The WSDL should reflect the specification as defined in the >>>>>> document, >>>>>> presenting it in a machine readable form. >>>>>> >>>>>> So, based on the fact that both Paul and I have both found >>>>>> problems in >>>>>> creating a clear and concise WSDL to represent this part of the >>>>>> specification and that the original use cases for the extra >>>>>> parameters >>>>>> are either no longer valid or not worth the hassle. >>>>>> I propose we make the above changes to the specification >>>>>> document, and >>>>>> then update the WSDL to match. >>>>>> >>>>>> Guy, Matthew, and Paul can you reply with 'accept' or 'reject' >>>>>> for the >>>>>> five changes outlined above. >>>>>> If everyone says yes, then we can update the document tomorrow >>>>>> and >>>>>> publish it as v0.22. >>>>>> >>>>>> I know this is a bit formal and possibly OTT, but I suspect >>>>>> that we will >>>>>> be making quite a few changes like this over the next few days. >>>>>> Making specific requests for individual changes to the >>>>>> document should >>>>>> make it easier to keep track of everything. >>>>>> >>>>>> I know there is at least one case where I found the list of >>>>>> exceptions >>>>>> was wrong on one of the methods, but right now I can't >>>>>> remember where it >>>>>> was. >>>>>> If I find it again I'll post another change request with the >>>>>> details. >>>>>> >>>>>> There are also a couple of questions / suggestions I would >>>>>> like to raise >>>>>> regarding data types and formats. >>>>>> I'll post another change request when I have worked out the >>>>>> details. >>>>>> >>>>>> Thanks, >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Guy Rixon gtr@ast.cam.ac.uk >>>>> Institute of Astronomy Tel: +44-1223-337542 >>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> Guy Rixon gtr@ast.cam.ac.uk >>> Institute of Astronomy Tel: +44-1223-337542 >>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>> >>> >> > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Tue Jun 20 09:32:15 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K7VvP0024982 for ; Tue, 20 Jun 2006 09:31:57 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5K7Vvtn024981 for vospace-outgoing; Tue, 20 Jun 2006 09:31:57 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K7VoP0024962; Tue, 20 Jun 2006 09:31:50 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K7VlQk020665; Tue, 20 Jun 2006 09:31:47 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:50778) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1Fsahv-0003Uz-2W (Exim 4.54) (return-path ); Tue, 20 Jun 2006 08:31:31 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5K7VVq6000711; Tue, 20 Jun 2006 08:31:31 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6) with ESMTP id k5K7VVsi028999; Tue, 20 Jun 2006 08:31:31 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.6+Sun/8.13.6/Submit) with ESMTP id k5K7VVGG028996; Tue, 20 Jun 2006 08:31:31 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 20 Jun 2006 08:31:30 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Paul Harrison cc: IVOA list VoSpace mailing Subject: Re: 1.0rc1 WSDL issues (create node params) In-Reply-To: Message-ID: References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> <4492BD3F.6020804@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.183432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon On Tue, 20 Jun 2006, Paul Harrison wrote: > Cannot the functionality be simply overloaded on createNode? The idea was to avoid overloading operation names. There's a rumor that overloading doesn't work consistently with doc/literal/wrapped. > > On 16.06.2006, at 16:39, Guy Rixon wrote: > > > CreateUniqueNode is fine by me. > > > > On Fri, 16 Jun 2006, Dave Morris wrote: > > > >> How about calling it CreateUniqueNode ? > >> Takes optional set of properties and returns a new DataNode with a > >> unique name within the space. > >> > >> We can add a type parameter in VoSpace-2.x to allow this to create > >> other > >> types of node, including containers. > >> > >> Dave > >> > >> Guy Rixon wrote: > >> > >>> Yes to introducing CreateTempNode as you have written it with > >>> these caveats: > >>> > >>> 1. Is createTempNode the best name? > >>> > >>> 2. Spec needs language making it clear that the node is created > >>> with a > >>> guaranteed-unique name. > >>> > >>> 3. Any other special semantics that we need to write down? > >>> > >>> 4. Is it a special type of node? (I suggest it can't be, since we > >>> only really > >>> have data nodes at this stage.) > >>> > >>> 5. The name parameter on the basic createNode will become > >>> mandatory if we make > >>> this change. > >>> > >>> Given that the node is an ordinary data-node and doesn't have any > >>> temporary-file semantics (c.f. the POSIX temporary files that > >>> disappear when > >>> the creating process exists), I suggest that createAndNameNode is > >>> a better > >>> name than createTempNode. > >>> > >>> (BTW, when we extend this to VOSpace 2, I hope we'll allow > >>> creation of > >>> auto-named container-nodes as well. But let's not get side- > >>> tracked by that > >>> now.) > >>> > >>> Cheers, > >>> Guy > >>> > >>> On Thu, 15 Jun 2006, Matthew Graham wrote: > >>> > >>> > >>> > >>>> Hi, > >>>> > >>>> I accept Dave's suggestions. > >>>> > >>>> I also accept Guy's suggestion for a separate operation for > >>>> creating a > >>>> temporary node with a server-generated name and propose adding > >>>> this text > >>>> to the spec: > >>>> > >>>> createTempNode > >>>> > >>>> Creates a temporary node in a space. This method is used to > >>>> create a > >>>> temporary data node. > >>>> > >>>> Parameters: None > >>>> > >>>> Returns: A element for the new node. > >>>> > >>>> Faults: The service may throw an OperationNotSupported > >>>> exception if it > >>>> does not support temporary nodes. > >>>> The service may throw an InternalFault exception if an > >>>> operation fails. > >>>> The service may throw a PermissionDenied exception > >>>> if the > >>>> user does not have permissions to perform the operation. > >>>> > >>>> Questions: > >>>> - Should a properties structure be an optional parameter? > >>>> - A user can always make a temporary node permanent by renaming > >>>> it to > >>>> something more meaningful. > >>>> > >>>> Cheers, > >>>> > >>>> Matthew > >>>> > >>>> > >>>> > >>>> Guy Rixon wrote: > >>>> > >>>> > >>>> > >>>>> Use case for server-generated names: when clients working in > >>>>> the same space > >>>>> want to generate temporary files with unique names. Java > >>>>> File.makeTempFile() > >>>>> and all that. If we support this, it might deserve its own > >>>>> operation with > >>>>> different parameters from createNode. > >>>>> > >>>>> On Thu, 15 Jun 2006, Dave Morris wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Paul Harrison wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On 14.06.2006, at 14:01, Dave Morris wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> However, when creating a new node, it was agreed that the > >>>>>>>> client > >>>>>>>> would supply the name as a plain text string, and the server > >>>>>>>> would > >>>>>>>> convert this into the URI encoded identifier. > >>>>>>>> This means that the server side code does the URI encoding, > >>>>>>>> making > >>>>>>>> it easier to verify that we get it right. > >>>>>>>> > >>>>>>>> > >>>>>>>> The operations that create a new node (CreateNode, > >>>>>>>> PushDataTo and > >>>>>>>> PullDataTo) take the name of the new node, not the identifier. > >>>>>>>> This gives us a way of distinguishing between import into an > >>>>>>>> existing node (node URI) and import into a new node (node > >>>>>>>> name). > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> also I think that there was also the idea that the server would > >>>>>>> generate a name automatically so the URI could point to a > >>>>>>> container... > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> The distinction still isn't as clear as I would like, but > >>>>>>>> that is > >>>>>>>> what is in the current document. > >>>>>>>> If we want to change this, then we will need to modify the > >>>>>>>> document. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> I think that the semantics of these operations are not still > >>>>>>> clear as > >>>>>>> currently implemented in the WSDL, and do need some work > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> I too was struggling with how to represent these multiple > >>>>>> parameters in > >>>>>> the experimental WSDL examples I posted last week. > >>>>>> If they are causing problems, do we want to look at these > >>>>>> again, and > >>>>>> possibly simplify them. > >>>>>> > >>>>>> ---- > >>>>>> > >>>>>> Server generated identifiers : > >>>>>> The original reason for server generated identifiers dates > >>>>>> back to when > >>>>>> we had two separate namespaces, VOSpace with user defined > >>>>>> names, and > >>>>>> VOStore with server generated names. > >>>>>> The VOStore service needed to generate the names in order to > >>>>>> ensure that > >>>>>> they were unique within that service. > >>>>>> > >>>>>> Now that we have brought everything into one VOSpace > >>>>>> namespace, I don't > >>>>>> think we need the server generated names any more. > >>>>>> In which case, unless anyone has a compelling use case for > >>>>>> this, I vote > >>>>>> we drop it. > >>>>>> > >>>>>> ---- > >>>>>> > >>>>>> Plain string name : > >>>>>> I proposed the idea of using the separate name and URI in > >>>>>> methods that > >>>>>> created nodes, primarily because I wanted to make the server > >>>>>> responsible > >>>>>> for encoding the URI correctly. > >>>>>> The client would just supply the name as a plain text string, > >>>>>> and the > >>>>>> server would encode it to create the full URI identifier. > >>>>>> > >>>>>> However, both of us have found problems trying to define a > >>>>>> clear and > >>>>>> concise WSDL that distinguishes between an import operation > >>>>>> that creates > >>>>>> a new node and one that imports data into an existing node. In > >>>>>> which > >>>>>> case, it looks like having the separate name parameter for > >>>>>> creating a > >>>>>> new node is causing us more problems than it is worth. > >>>>>> > >>>>>> ---- > >>>>>> > >>>>>> For VoSpace-1.0 I propose we drop both the server generated > >>>>>> names and > >>>>>> the separate name as string parameter. > >>>>>> > >>>>>> 1) CreateNode takes a mandatory target URI of the new node, > >>>>>> rather than > >>>>>> the optional string name. > >>>>>> The target URI cannot be null, and the service does not > >>>>>> automatically > >>>>>> generate new names. > >>>>>> It is up to the client to create and encode the target URI > >>>>>> correctly. > >>>>>> If the server receives an invalid URI, it throws an Exception. > >>>>>> > >>>>>> 2) The two import methods also take a single URI parameter to > >>>>>> identify > >>>>>> the target node. > >>>>>> The target URI cannot be null, and the service does not > >>>>>> automatically > >>>>>> generate new names. > >>>>>> It is up to the client to create and encode the target URI > >>>>>> correctly. > >>>>>> If the server receives an invalid URI, it throws an Exception. > >>>>>> If the target node already exists, then its contents will be > >>>>>> replaced by > >>>>>> the import. > >>>>>> If the target node does not exist, then the import methods > >>>>>> will create a > >>>>>> new node and import the data into that. > >>>>>> (this also implies that the flag is no longer needed > >>>>>> either) > >>>>>> > >>>>>> Then, to make things symmetrical : > >>>>>> > >>>>>> 3) MoveNode takes two URIs, representing the source and > >>>>>> destination. > >>>>>> The source URI cannot be null and must point to an existing node. > >>>>>> The destination URI cannot be null, and must NOT point to an > >>>>>> existing node. > >>>>>> If a node already exists with the destination URI, then the > >>>>>> method > >>>>>> throws a DuplicateNodeException. > >>>>>> It is up to the client to create and encode the destination > >>>>>> URI correctly. > >>>>>> If the server receives an invalid URI, it throws an Exception. > >>>>>> > >>>>>> 4) CopyNode takes two URIs, representing the source and > >>>>>> destination. > >>>>>> The source URI cannot be null and must point to an existing node. > >>>>>> The destination URI cannot be null, and must NOT point to an > >>>>>> existing node. > >>>>>> If a node already exists with the destination URI, then the > >>>>>> method > >>>>>> throws a DuplicateNodeException. > >>>>>> It is up to the client to create and encode the destination > >>>>>> URI correctly. > >>>>>> If the server receives an invalid URI, it throws an Exception. > >>>>>> > >>>>>> To support client encoded URIs : > >>>>>> > >>>>>> 5) We need to add MalformedIdentifierException to the list of > >>>>>> exceptions > >>>>>> for all the methods that take URI parameters. > >>>>>> > >>>>>> Hopefully, this should make the service API and WSDL a lot > >>>>>> clearer. > >>>>>> > >>>>>> One caveat : > >>>>>> I would like to re-visit this when we look at v2.x, based on > >>>>>> what we > >>>>>> find using v1.0 in real applications. > >>>>>> > >>>>>> ---- > >>>>>> > >>>>>> Matthew is right when he says that if we have any changes we > >>>>>> should be > >>>>>> discussing them in the document, and not the WSDL. > >>>>>> The WSDL should reflect the specification as defined in the > >>>>>> document, > >>>>>> presenting it in a machine readable form. > >>>>>> > >>>>>> So, based on the fact that both Paul and I have both found > >>>>>> problems in > >>>>>> creating a clear and concise WSDL to represent this part of the > >>>>>> specification and that the original use cases for the extra > >>>>>> parameters > >>>>>> are either no longer valid or not worth the hassle. > >>>>>> I propose we make the above changes to the specification > >>>>>> document, and > >>>>>> then update the WSDL to match. > >>>>>> > >>>>>> Guy, Matthew, and Paul can you reply with 'accept' or 'reject' > >>>>>> for the > >>>>>> five changes outlined above. > >>>>>> If everyone says yes, then we can update the document tomorrow > >>>>>> and > >>>>>> publish it as v0.22. > >>>>>> > >>>>>> I know this is a bit formal and possibly OTT, but I suspect > >>>>>> that we will > >>>>>> be making quite a few changes like this over the next few days. > >>>>>> Making specific requests for individual changes to the > >>>>>> document should > >>>>>> make it easier to keep track of everything. > >>>>>> > >>>>>> I know there is at least one case where I found the list of > >>>>>> exceptions > >>>>>> was wrong on one of the methods, but right now I can't > >>>>>> remember where it > >>>>>> was. > >>>>>> If I find it again I'll post another change request with the > >>>>>> details. > >>>>>> > >>>>>> There are also a couple of questions / suggestions I would > >>>>>> like to raise > >>>>>> regarding data types and formats. > >>>>>> I'll post another change request when I have worked out the > >>>>>> details. > >>>>>> > >>>>>> Thanks, > >>>>>> Dave > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> Guy Rixon gtr@ast.cam.ac.uk > >>>>> Institute of Astronomy Tel: +44-1223-337542 > >>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> Guy Rixon gtr@ast.cam.ac.uk > >>> Institute of Astronomy Tel: +44-1223-337542 > >>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > >>> > >>> > >> > > > > Guy Rixon gtr@ast.cam.ac.uk > > Institute of Astronomy Tel: +44-1223-337542 > > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Tue Jun 20 10:27:30 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K8REP0003894 for ; Tue, 20 Jun 2006 10:27:14 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5K8RDSi003892 for vospace-outgoing; Tue, 20 Jun 2006 10:27:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K8QuP0003820; Tue, 20 Jun 2006 10:26:56 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5K8QuXR005868 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 20 Jun 2006 10:26:56 +0200 In-Reply-To: References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> <4492BD3F.6020804@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9726AA11-EC88-40D4-AA73-80DD151B2310@eso.org> Cc: IVOA list VoSpace mailing Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues (create node params) Date: Tue, 20 Jun 2006 10:26:53 +0200 To: Guy Rixon X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison I should have chosen my words more carefully - I did not mean any formal "overloading" in the wsdl sense, but simply having a xsd:choice in the parameter set, though I can see that this is probably best avoided as I can see that it might not map too well onto the "pseudo rpc" that .NET transforms the doc/literal/wrapped into when presented to the programmer. It would still be very useful if someone could take the wsdl and run it through a .Net code generator. So yes go with another method CreateUniqueNode However, I am still unhappy about the use of CreateNode in VOSpace 1.0 - it seems to be leading Dave to what to produce complicated semantics for the data manipulation methods in his 5 point proposal in the start of this thread. He has it illegal for the target URI of these operations *NOT* to point to an existing node - this means that createNode has to be executed before a copyNode for instance - the unix analogy is that you have to do a "touch" before every "cp" - this seems perverse to say the least. I think that it would be far better if the opposite behaviour was the default - i.e. the data manipulation operations simply create the target node if it does not exist. We can set the "overwrite policy" to "don't overwrite - throw fault" by default with an optional flag to force the overwrite (permissions allowing of course). Paul. On 20.06.2006, at 09:31, Guy Rixon wrote: > On Tue, 20 Jun 2006, Paul Harrison wrote: > >> Cannot the functionality be simply overloaded on createNode? > > The idea was to avoid overloading operation names. There's a rumor > that > overloading doesn't work consistently with doc/literal/wrapped. >> >> On 16.06.2006, at 16:39, Guy Rixon wrote: >> >>> CreateUniqueNode is fine by me. >>> >>> On Fri, 16 Jun 2006, Dave Morris wrote: >>> >>>> How about calling it CreateUniqueNode ? >>>> Takes optional set of properties and returns a new DataNode with a >>>> unique name within the space. >>>> >>>> We can add a type parameter in VoSpace-2.x to allow this to create >>>> other >>>> types of node, including containers. >>>> >>>> Dave >>>> >>>> Guy Rixon wrote: >>>> >>>>> Yes to introducing CreateTempNode as you have written it with >>>>> these caveats: >>>>> >>>>> 1. Is createTempNode the best name? >>>>> >>>>> 2. Spec needs language making it clear that the node is created >>>>> with a >>>>> guaranteed-unique name. >>>>> >>>>> 3. Any other special semantics that we need to write down? >>>>> >>>>> 4. Is it a special type of node? (I suggest it can't be, since we >>>>> only really >>>>> have data nodes at this stage.) >>>>> >>>>> 5. The name parameter on the basic createNode will become >>>>> mandatory if we make >>>>> this change. >>>>> >>>>> Given that the node is an ordinary data-node and doesn't have any >>>>> temporary-file semantics (c.f. the POSIX temporary files that >>>>> disappear when >>>>> the creating process exists), I suggest that createAndNameNode is >>>>> a better >>>>> name than createTempNode. >>>>> >>>>> (BTW, when we extend this to VOSpace 2, I hope we'll allow >>>>> creation of >>>>> auto-named container-nodes as well. But let's not get side- >>>>> tracked by that >>>>> now.) >>>>> >>>>> Cheers, >>>>> Guy >>>>> >>>>> On Thu, 15 Jun 2006, Matthew Graham wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I accept Dave's suggestions. >>>>>> >>>>>> I also accept Guy's suggestion for a separate operation for >>>>>> creating a >>>>>> temporary node with a server-generated name and propose adding >>>>>> this text >>>>>> to the spec: >>>>>> >>>>>> createTempNode >>>>>> >>>>>> Creates a temporary node in a space. This method is used to >>>>>> create a >>>>>> temporary data node. >>>>>> >>>>>> Parameters: None >>>>>> >>>>>> Returns: A element for the new node. >>>>>> >>>>>> Faults: The service may throw an OperationNotSupported >>>>>> exception if it >>>>>> does not support temporary nodes. >>>>>> The service may throw an InternalFault exception >>>>>> if an >>>>>> operation fails. >>>>>> The service may throw a PermissionDenied exception >>>>>> if the >>>>>> user does not have permissions to perform the operation. >>>>>> >>>>>> Questions: >>>>>> - Should a properties structure be an optional parameter? >>>>>> - A user can always make a temporary node permanent by renaming >>>>>> it to >>>>>> something more meaningful. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Matthew >>>>>> >>>>>> >>>>>> >>>>>> Guy Rixon wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Use case for server-generated names: when clients working in >>>>>>> the same space >>>>>>> want to generate temporary files with unique names. Java >>>>>>> File.makeTempFile() >>>>>>> and all that. If we support this, it might deserve its own >>>>>>> operation with >>>>>>> different parameters from createNode. >>>>>>> >>>>>>> On Thu, 15 Jun 2006, Dave Morris wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Paul Harrison wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 14.06.2006, at 14:01, Dave Morris wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> However, when creating a new node, it was agreed that the >>>>>>>>>> client >>>>>>>>>> would supply the name as a plain text string, and the server >>>>>>>>>> would >>>>>>>>>> convert this into the URI encoded identifier. >>>>>>>>>> This means that the server side code does the URI encoding, >>>>>>>>>> making >>>>>>>>>> it easier to verify that we get it right. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The operations that create a new node (CreateNode, >>>>>>>>>> PushDataTo and >>>>>>>>>> PullDataTo) take the name of the new node, not the >>>>>>>>>> identifier. >>>>>>>>>> This gives us a way of distinguishing between import into an >>>>>>>>>> existing node (node URI) and import into a new node (node >>>>>>>>>> name). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> also I think that there was also the idea that the server >>>>>>>>> would >>>>>>>>> generate a name automatically so the URI could point to a >>>>>>>>> container... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> The distinction still isn't as clear as I would like, but >>>>>>>>>> that is >>>>>>>>>> what is in the current document. >>>>>>>>>> If we want to change this, then we will need to modify the >>>>>>>>>> document. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I think that the semantics of these operations are not still >>>>>>>>> clear as >>>>>>>>> currently implemented in the WSDL, and do need some work >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I too was struggling with how to represent these multiple >>>>>>>> parameters in >>>>>>>> the experimental WSDL examples I posted last week. >>>>>>>> If they are causing problems, do we want to look at these >>>>>>>> again, and >>>>>>>> possibly simplify them. >>>>>>>> >>>>>>>> ---- >>>>>>>> >>>>>>>> Server generated identifiers : >>>>>>>> The original reason for server generated identifiers dates >>>>>>>> back to when >>>>>>>> we had two separate namespaces, VOSpace with user defined >>>>>>>> names, and >>>>>>>> VOStore with server generated names. >>>>>>>> The VOStore service needed to generate the names in order to >>>>>>>> ensure that >>>>>>>> they were unique within that service. >>>>>>>> >>>>>>>> Now that we have brought everything into one VOSpace >>>>>>>> namespace, I don't >>>>>>>> think we need the server generated names any more. >>>>>>>> In which case, unless anyone has a compelling use case for >>>>>>>> this, I vote >>>>>>>> we drop it. >>>>>>>> >>>>>>>> ---- >>>>>>>> >>>>>>>> Plain string name : >>>>>>>> I proposed the idea of using the separate name and URI in >>>>>>>> methods that >>>>>>>> created nodes, primarily because I wanted to make the server >>>>>>>> responsible >>>>>>>> for encoding the URI correctly. >>>>>>>> The client would just supply the name as a plain text string, >>>>>>>> and the >>>>>>>> server would encode it to create the full URI identifier. >>>>>>>> >>>>>>>> However, both of us have found problems trying to define a >>>>>>>> clear and >>>>>>>> concise WSDL that distinguishes between an import operation >>>>>>>> that creates >>>>>>>> a new node and one that imports data into an existing node. In >>>>>>>> which >>>>>>>> case, it looks like having the separate name parameter for >>>>>>>> creating a >>>>>>>> new node is causing us more problems than it is worth. >>>>>>>> >>>>>>>> ---- >>>>>>>> >>>>>>>> For VoSpace-1.0 I propose we drop both the server generated >>>>>>>> names and >>>>>>>> the separate name as string parameter. >>>>>>>> >>>>>>>> 1) CreateNode takes a mandatory target URI of the new node, >>>>>>>> rather than >>>>>>>> the optional string name. >>>>>>>> The target URI cannot be null, and the service does not >>>>>>>> automatically >>>>>>>> generate new names. >>>>>>>> It is up to the client to create and encode the target URI >>>>>>>> correctly. >>>>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>>>> >>>>>>>> 2) The two import methods also take a single URI parameter to >>>>>>>> identify >>>>>>>> the target node. >>>>>>>> The target URI cannot be null, and the service does not >>>>>>>> automatically >>>>>>>> generate new names. >>>>>>>> It is up to the client to create and encode the target URI >>>>>>>> correctly. >>>>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>>>> If the target node already exists, then its contents will be >>>>>>>> replaced by >>>>>>>> the import. >>>>>>>> If the target node does not exist, then the import methods >>>>>>>> will create a >>>>>>>> new node and import the data into that. >>>>>>>> (this also implies that the flag is no longer needed >>>>>>>> either) >>>>>>>> >>>>>>>> Then, to make things symmetrical : >>>>>>>> >>>>>>>> 3) MoveNode takes two URIs, representing the source and >>>>>>>> destination. >>>>>>>> The source URI cannot be null and must point to an existing >>>>>>>> node. >>>>>>>> The destination URI cannot be null, and must NOT point to an >>>>>>>> existing node. >>>>>>>> If a node already exists with the destination URI, then the >>>>>>>> method >>>>>>>> throws a DuplicateNodeException. >>>>>>>> It is up to the client to create and encode the destination >>>>>>>> URI correctly. >>>>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>>>> >>>>>>>> 4) CopyNode takes two URIs, representing the source and >>>>>>>> destination. >>>>>>>> The source URI cannot be null and must point to an existing >>>>>>>> node. >>>>>>>> The destination URI cannot be null, and must NOT point to an >>>>>>>> existing node. >>>>>>>> If a node already exists with the destination URI, then the >>>>>>>> method >>>>>>>> throws a DuplicateNodeException. >>>>>>>> It is up to the client to create and encode the destination >>>>>>>> URI correctly. >>>>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>>>> >>>>>>>> To support client encoded URIs : >>>>>>>> >>>>>>>> 5) We need to add MalformedIdentifierException to the list of >>>>>>>> exceptions >>>>>>>> for all the methods that take URI parameters. >>>>>>>> >>>>>>>> Hopefully, this should make the service API and WSDL a lot >>>>>>>> clearer. >>>>>>>> >>>>>>>> One caveat : >>>>>>>> I would like to re-visit this when we look at v2.x, based on >>>>>>>> what we >>>>>>>> find using v1.0 in real applications. >>>>>>>> >>>>>>>> ---- >>>>>>>> >>>>>>>> Matthew is right when he says that if we have any changes we >>>>>>>> should be >>>>>>>> discussing them in the document, and not the WSDL. >>>>>>>> The WSDL should reflect the specification as defined in the >>>>>>>> document, >>>>>>>> presenting it in a machine readable form. >>>>>>>> >>>>>>>> So, based on the fact that both Paul and I have both found >>>>>>>> problems in >>>>>>>> creating a clear and concise WSDL to represent this part of the >>>>>>>> specification and that the original use cases for the extra >>>>>>>> parameters >>>>>>>> are either no longer valid or not worth the hassle. >>>>>>>> I propose we make the above changes to the specification >>>>>>>> document, and >>>>>>>> then update the WSDL to match. >>>>>>>> >>>>>>>> Guy, Matthew, and Paul can you reply with 'accept' or 'reject' >>>>>>>> for the >>>>>>>> five changes outlined above. >>>>>>>> If everyone says yes, then we can update the document tomorrow >>>>>>>> and >>>>>>>> publish it as v0.22. >>>>>>>> >>>>>>>> I know this is a bit formal and possibly OTT, but I suspect >>>>>>>> that we will >>>>>>>> be making quite a few changes like this over the next few days. >>>>>>>> Making specific requests for individual changes to the >>>>>>>> document should >>>>>>>> make it easier to keep track of everything. >>>>>>>> >>>>>>>> I know there is at least one case where I found the list of >>>>>>>> exceptions >>>>>>>> was wrong on one of the methods, but right now I can't >>>>>>>> remember where it >>>>>>>> was. >>>>>>>> If I find it again I'll post another change request with the >>>>>>>> details. >>>>>>>> >>>>>>>> There are also a couple of questions / suggestions I would >>>>>>>> like to raise >>>>>>>> regarding data types and formats. >>>>>>>> I'll post another change request when I have worked out the >>>>>>>> details. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dave >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Guy Rixon gtr@ast.cam.ac.uk >>>>>>> Institute of Astronomy Tel: +44-1223-337542 >>>>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> Guy Rixon gtr@ast.cam.ac.uk >>>>> Institute of Astronomy Tel: +44-1223-337542 >>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>>>> >>>>> >>>> >>> >>> Guy Rixon gtr@ast.cam.ac.uk >>> Institute of Astronomy Tel: +44-1223-337542 >>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >> > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Tue Jun 20 10:30:29 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K8UCP0004478 for ; Tue, 20 Jun 2006 10:30:13 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5K8UCnb004477 for vospace-outgoing; Tue, 20 Jun 2006 10:30:12 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K8U4P0004429; Tue, 20 Jun 2006 10:30:05 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K8U2Qk024243; Tue, 20 Jun 2006 10:30:03 +0200 (CEST) Received: from [172.16.1.34] (host86-130-222-249.range86-130.btcentralplus.com [86.130.222.249]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k5K8Th3G017739; Tue, 20 Jun 2006 01:29:44 -0700 Message-ID: <4497B1F5.5040906@cacr.caltech.edu> Date: Tue, 20 Jun 2006 01:29:41 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Paul Harrison , IVOA list VoSpace mailing Subject: Re: 1.0rc1 WSDL issues (create node params) References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> <4492BD3F.6020804@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.183432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, I'm in the UK now but on vacation this week so will have limited responses. Guy Rixon wrote: >On Tue, 20 Jun 2006, Paul Harrison wrote: > > > >>Cannot the functionality be simply overloaded on createNode? >> >> > >The idea was to avoid overloading operation names. There's a rumor that >overloading doesn't work consistently with doc/literal/wrapped. > > The problem is that although the WSDL 1.1 spec does allow for the overloading, it is not very well known or documented so the support for this is not universal - I seem to remember that .Net does not interpret an overloaded operation properly. WSDL 2.0 no longer supports this type of useful overloading. Cheers, Matthew From owner-vospace@eso.org Tue Jun 20 11:32:39 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K9UNP0008103 for ; Tue, 20 Jun 2006 11:30:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5K9UN0C008102 for vospace-outgoing; Tue, 20 Jun 2006 11:30:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K9UIP0008091; Tue, 20 Jun 2006 11:30:18 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5K9UDQk028239; Tue, 20 Jun 2006 11:30:15 +0200 (CEST) Received: from [172.16.1.34] (host86-130-222-249.range86-130.btcentralplus.com [86.130.222.249]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k5K9Tq3G021510; Tue, 20 Jun 2006 02:29:53 -0700 Message-ID: <4497C00F.6060502@cacr.caltech.edu> Date: Tue, 20 Jun 2006 02:29:51 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: Guy Rixon , IVOA list VoSpace mailing Subject: Re: 1.0rc1 WSDL issues (create node params) References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> <4492BD3F.6020804@ast.cam.ac.uk> <9726AA11-EC88-40D4-AA73-80DD151B2310@eso.org> In-Reply-To: <9726AA11-EC88-40D4-AA73-80DD151B2310@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.20.15432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, I do not think that this is what Dave is suggesting: for the import methods, he has: "if the target node does not exist, then the import methods will create a new node and import the data into that." I think that the same behaviour is implied for copyNode and that it just has failed to be stated explicitly. Cheers, Matthew Paul Harrison wrote: > I should have chosen my words more carefully - I did not mean any > formal "overloading" in the wsdl sense, but simply having a > xsd:choice in the parameter set, though I can see that this is > probably best avoided as I can see that it might not map too well > onto the "pseudo rpc" that .NET transforms the doc/literal/wrapped > into when presented to the programmer. It would still be very useful > if someone could take the wsdl and run it through a .Net code generator. > > So yes go with another method CreateUniqueNode > > However, I am still unhappy about the use of CreateNode in VOSpace > 1.0 - it seems to be leading Dave to what to produce complicated > semantics for the data manipulation methods in his 5 point proposal > in the start of this thread. He has it illegal for the target URI of > these operations *NOT* to point to an existing node - this means that > createNode has to be executed before a copyNode for instance - the > unix analogy is that you have to do a "touch" before every "cp" - > this seems perverse to say the least. I think that it would be far > better if the opposite behaviour was the default - i.e. the data > manipulation operations simply create the target node if it does not > exist. We can set the "overwrite policy" to "don't overwrite - throw > fault" by default with an optional flag to force the overwrite > (permissions allowing of course). > > Paul. > > On 20.06.2006, at 09:31, Guy Rixon wrote: > >> On Tue, 20 Jun 2006, Paul Harrison wrote: >> >>> Cannot the functionality be simply overloaded on createNode? >> >> >> The idea was to avoid overloading operation names. There's a rumor that >> overloading doesn't work consistently with doc/literal/wrapped. >> >>> >>> On 16.06.2006, at 16:39, Guy Rixon wrote: >>> >>>> CreateUniqueNode is fine by me. >>>> >>>> On Fri, 16 Jun 2006, Dave Morris wrote: >>>> >>>>> How about calling it CreateUniqueNode ? >>>>> Takes optional set of properties and returns a new DataNode with a >>>>> unique name within the space. >>>>> >>>>> We can add a type parameter in VoSpace-2.x to allow this to create >>>>> other >>>>> types of node, including containers. >>>>> >>>>> Dave >>>>> >>>>> Guy Rixon wrote: >>>>> >>>>>> Yes to introducing CreateTempNode as you have written it with >>>>>> these caveats: >>>>>> >>>>>> 1. Is createTempNode the best name? >>>>>> >>>>>> 2. Spec needs language making it clear that the node is created >>>>>> with a >>>>>> guaranteed-unique name. >>>>>> >>>>>> 3. Any other special semantics that we need to write down? >>>>>> >>>>>> 4. Is it a special type of node? (I suggest it can't be, since we >>>>>> only really >>>>>> have data nodes at this stage.) >>>>>> >>>>>> 5. The name parameter on the basic createNode will become >>>>>> mandatory if we make >>>>>> this change. >>>>>> >>>>>> Given that the node is an ordinary data-node and doesn't have any >>>>>> temporary-file semantics (c.f. the POSIX temporary files that >>>>>> disappear when >>>>>> the creating process exists), I suggest that createAndNameNode is >>>>>> a better >>>>>> name than createTempNode. >>>>>> >>>>>> (BTW, when we extend this to VOSpace 2, I hope we'll allow >>>>>> creation of >>>>>> auto-named container-nodes as well. But let's not get side- >>>>>> tracked by that >>>>>> now.) >>>>>> >>>>>> Cheers, >>>>>> Guy >>>>>> >>>>>> On Thu, 15 Jun 2006, Matthew Graham wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I accept Dave's suggestions. >>>>>>> >>>>>>> I also accept Guy's suggestion for a separate operation for >>>>>>> creating a >>>>>>> temporary node with a server-generated name and propose adding >>>>>>> this text >>>>>>> to the spec: >>>>>>> >>>>>>> createTempNode >>>>>>> >>>>>>> Creates a temporary node in a space. This method is used to >>>>>>> create a >>>>>>> temporary data node. >>>>>>> >>>>>>> Parameters: None >>>>>>> >>>>>>> Returns: A element for the new node. >>>>>>> >>>>>>> Faults: The service may throw an OperationNotSupported >>>>>>> exception if it >>>>>>> does not support temporary nodes. >>>>>>> The service may throw an InternalFault exception if an >>>>>>> operation fails. >>>>>>> The service may throw a PermissionDenied exception >>>>>>> if the >>>>>>> user does not have permissions to perform the operation. >>>>>>> >>>>>>> Questions: >>>>>>> - Should a properties structure be an optional parameter? >>>>>>> - A user can always make a temporary node permanent by renaming >>>>>>> it to >>>>>>> something more meaningful. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matthew >>>>>>> >>>>>>> >>>>>>> >>>>>>> Guy Rixon wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Use case for server-generated names: when clients working in >>>>>>>> the same space >>>>>>>> want to generate temporary files with unique names. Java >>>>>>>> File.makeTempFile() >>>>>>>> and all that. If we support this, it might deserve its own >>>>>>>> operation with >>>>>>>> different parameters from createNode. >>>>>>>> >>>>>>>> On Thu, 15 Jun 2006, Dave Morris wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Paul Harrison wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 14.06.2006, at 14:01, Dave Morris wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> However, when creating a new node, it was agreed that the >>>>>>>>>>> client >>>>>>>>>>> would supply the name as a plain text string, and the server >>>>>>>>>>> would >>>>>>>>>>> convert this into the URI encoded identifier. >>>>>>>>>>> This means that the server side code does the URI encoding, >>>>>>>>>>> making >>>>>>>>>>> it easier to verify that we get it right. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The operations that create a new node (CreateNode, >>>>>>>>>>> PushDataTo and >>>>>>>>>>> PullDataTo) take the name of the new node, not the identifier. >>>>>>>>>>> This gives us a way of distinguishing between import into an >>>>>>>>>>> existing node (node URI) and import into a new node (node >>>>>>>>>>> name). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> also I think that there was also the idea that the server would >>>>>>>>>> generate a name automatically so the URI could point to a >>>>>>>>>> container... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The distinction still isn't as clear as I would like, but >>>>>>>>>>> that is >>>>>>>>>>> what is in the current document. >>>>>>>>>>> If we want to change this, then we will need to modify the >>>>>>>>>>> document. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I think that the semantics of these operations are not still >>>>>>>>>> clear as >>>>>>>>>> currently implemented in the WSDL, and do need some work >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I too was struggling with how to represent these multiple >>>>>>>>> parameters in >>>>>>>>> the experimental WSDL examples I posted last week. >>>>>>>>> If they are causing problems, do we want to look at these >>>>>>>>> again, and >>>>>>>>> possibly simplify them. >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> Server generated identifiers : >>>>>>>>> The original reason for server generated identifiers dates >>>>>>>>> back to when >>>>>>>>> we had two separate namespaces, VOSpace with user defined >>>>>>>>> names, and >>>>>>>>> VOStore with server generated names. >>>>>>>>> The VOStore service needed to generate the names in order to >>>>>>>>> ensure that >>>>>>>>> they were unique within that service. >>>>>>>>> >>>>>>>>> Now that we have brought everything into one VOSpace >>>>>>>>> namespace, I don't >>>>>>>>> think we need the server generated names any more. >>>>>>>>> In which case, unless anyone has a compelling use case for >>>>>>>>> this, I vote >>>>>>>>> we drop it. >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> Plain string name : >>>>>>>>> I proposed the idea of using the separate name and URI in >>>>>>>>> methods that >>>>>>>>> created nodes, primarily because I wanted to make the server >>>>>>>>> responsible >>>>>>>>> for encoding the URI correctly. >>>>>>>>> The client would just supply the name as a plain text string, >>>>>>>>> and the >>>>>>>>> server would encode it to create the full URI identifier. >>>>>>>>> >>>>>>>>> However, both of us have found problems trying to define a >>>>>>>>> clear and >>>>>>>>> concise WSDL that distinguishes between an import operation >>>>>>>>> that creates >>>>>>>>> a new node and one that imports data into an existing node. In >>>>>>>>> which >>>>>>>>> case, it looks like having the separate name parameter for >>>>>>>>> creating a >>>>>>>>> new node is causing us more problems than it is worth. >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> For VoSpace-1.0 I propose we drop both the server generated >>>>>>>>> names and >>>>>>>>> the separate name as string parameter. >>>>>>>>> >>>>>>>>> 1) CreateNode takes a mandatory target URI of the new node, >>>>>>>>> rather than >>>>>>>>> the optional string name. >>>>>>>>> The target URI cannot be null, and the service does not >>>>>>>>> automatically >>>>>>>>> generate new names. >>>>>>>>> It is up to the client to create and encode the target URI >>>>>>>>> correctly. >>>>>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>>>>> >>>>>>>>> 2) The two import methods also take a single URI parameter to >>>>>>>>> identify >>>>>>>>> the target node. >>>>>>>>> The target URI cannot be null, and the service does not >>>>>>>>> automatically >>>>>>>>> generate new names. >>>>>>>>> It is up to the client to create and encode the target URI >>>>>>>>> correctly. >>>>>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>>>>> If the target node already exists, then its contents will be >>>>>>>>> replaced by >>>>>>>>> the import. >>>>>>>>> If the target node does not exist, then the import methods >>>>>>>>> will create a >>>>>>>>> new node and import the data into that. >>>>>>>>> (this also implies that the flag is no longer needed >>>>>>>>> either) >>>>>>>>> >>>>>>>>> Then, to make things symmetrical : >>>>>>>>> >>>>>>>>> 3) MoveNode takes two URIs, representing the source and >>>>>>>>> destination. >>>>>>>>> The source URI cannot be null and must point to an existing >>>>>>>>> node. >>>>>>>>> The destination URI cannot be null, and must NOT point to an >>>>>>>>> existing node. >>>>>>>>> If a node already exists with the destination URI, then the >>>>>>>>> method >>>>>>>>> throws a DuplicateNodeException. >>>>>>>>> It is up to the client to create and encode the destination >>>>>>>>> URI correctly. >>>>>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>>>>> >>>>>>>>> 4) CopyNode takes two URIs, representing the source and >>>>>>>>> destination. >>>>>>>>> The source URI cannot be null and must point to an existing >>>>>>>>> node. >>>>>>>>> The destination URI cannot be null, and must NOT point to an >>>>>>>>> existing node. >>>>>>>>> If a node already exists with the destination URI, then the >>>>>>>>> method >>>>>>>>> throws a DuplicateNodeException. >>>>>>>>> It is up to the client to create and encode the destination >>>>>>>>> URI correctly. >>>>>>>>> If the server receives an invalid URI, it throws an Exception. >>>>>>>>> >>>>>>>>> To support client encoded URIs : >>>>>>>>> >>>>>>>>> 5) We need to add MalformedIdentifierException to the list of >>>>>>>>> exceptions >>>>>>>>> for all the methods that take URI parameters. >>>>>>>>> >>>>>>>>> Hopefully, this should make the service API and WSDL a lot >>>>>>>>> clearer. >>>>>>>>> >>>>>>>>> One caveat : >>>>>>>>> I would like to re-visit this when we look at v2.x, based on >>>>>>>>> what we >>>>>>>>> find using v1.0 in real applications. >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> Matthew is right when he says that if we have any changes we >>>>>>>>> should be >>>>>>>>> discussing them in the document, and not the WSDL. >>>>>>>>> The WSDL should reflect the specification as defined in the >>>>>>>>> document, >>>>>>>>> presenting it in a machine readable form. >>>>>>>>> >>>>>>>>> So, based on the fact that both Paul and I have both found >>>>>>>>> problems in >>>>>>>>> creating a clear and concise WSDL to represent this part of the >>>>>>>>> specification and that the original use cases for the extra >>>>>>>>> parameters >>>>>>>>> are either no longer valid or not worth the hassle. >>>>>>>>> I propose we make the above changes to the specification >>>>>>>>> document, and >>>>>>>>> then update the WSDL to match. >>>>>>>>> >>>>>>>>> Guy, Matthew, and Paul can you reply with 'accept' or 'reject' >>>>>>>>> for the >>>>>>>>> five changes outlined above. >>>>>>>>> If everyone says yes, then we can update the document tomorrow >>>>>>>>> and >>>>>>>>> publish it as v0.22. >>>>>>>>> >>>>>>>>> I know this is a bit formal and possibly OTT, but I suspect >>>>>>>>> that we will >>>>>>>>> be making quite a few changes like this over the next few days. >>>>>>>>> Making specific requests for individual changes to the >>>>>>>>> document should >>>>>>>>> make it easier to keep track of everything. >>>>>>>>> >>>>>>>>> I know there is at least one case where I found the list of >>>>>>>>> exceptions >>>>>>>>> was wrong on one of the methods, but right now I can't >>>>>>>>> remember where it >>>>>>>>> was. >>>>>>>>> If I find it again I'll post another change request with the >>>>>>>>> details. >>>>>>>>> >>>>>>>>> There are also a couple of questions / suggestions I would >>>>>>>>> like to raise >>>>>>>>> regarding data types and formats. >>>>>>>>> I'll post another change request when I have worked out the >>>>>>>>> details. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dave >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Guy Rixon gtr@ast.cam.ac.uk >>>>>>>> Institute of Astronomy Tel: +44-1223-337542 >>>>>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> Guy Rixon gtr@ast.cam.ac.uk >>>>>> Institute of Astronomy Tel: +44-1223-337542 >>>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>>>>> >>>>>> >>>>> >>>> >>>> Guy Rixon gtr@ast.cam.ac.uk >>>> Institute of Astronomy Tel: +44-1223-337542 >>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>> >>> >> >> Guy Rixon gtr@ast.cam.ac.uk >> Institute of Astronomy Tel: +44-1223-337542 >> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > From owner-vospace@eso.org Tue Jun 20 12:16:59 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5KAGjP0016534 for ; Tue, 20 Jun 2006 12:16:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5KAGjbS016533 for vospace-outgoing; Tue, 20 Jun 2006 12:16:45 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5KAGeP0016525 for ; Tue, 20 Jun 2006 12:16:40 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5KAGeXR008590 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 20 Jun 2006 12:16:40 +0200 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4497C00F.6060502@cacr.caltech.edu> References: <448FFA91.6010703@ast.cam.ac.uk> <559CC360-58C5-40CE-A25E-CF043B40AFA0@eso.org> <4490AF97.7090105@ast.cam.ac.uk> <4491B37D.5030904@cacr.caltech.edu> <4492BD3F.6020804@ast.cam.ac.uk> <9726AA11-EC88-40D4-AA73-80DD151B2310@eso.org> <4497C00F.6060502@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D06E698-C872-44D5-B7AC-A3178D9B4C19@eso.org> Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: 1.0rc1 WSDL issues (create node params) Date: Tue, 20 Jun 2006 12:16:39 +0200 To: IVOA list VoSpace mailing X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 20.06.2006, at 11:29, Matthew Graham wrote: > Hi, > > I do not think that this is what Dave is suggesting: for the import > methods, he has: "if the target node does not exist, then the > import methods will create a new node and import the data into > that." I think that the same behaviour is implied for copyNode and > that it just has failed to be stated explicitly. yes - you are right - I miss-read the logic of the NOT on the copyNode operation (Dave was actually referring to the "overwrite policy"...), and mis-understood "does not create new names" to mean does not create new nodes - > Cheers, > > Matthew > > Paul Harrison wrote: > >> I should have chosen my words more carefully - I did not mean any >> formal "overloading" in the wsdl sense, but simply having a >> xsd:choice in the parameter set, though I can see that this is >> probably best avoided as I can see that it might not map too well >> onto the "pseudo rpc" that .NET transforms the doc/literal/ >> wrapped into when presented to the programmer. It would still be >> very useful if someone could take the wsdl and run it through >> a .Net code generator. >> >> So yes go with another method CreateUniqueNode >> >> However, I am still unhappy about the use of CreateNode in >> VOSpace 1.0 - it seems to be leading Dave to what to produce >> complicated semantics for the data manipulation methods in his 5 >> point proposal in the start of this thread. He has it illegal for >> the target URI of these operations *NOT* to point to an existing >> node - this means that createNode has to be executed before a >> copyNode for instance - the unix analogy is that you have to do a >> "touch" before every "cp" - this seems perverse to say the least. >> I think that it would be far better if the opposite behaviour was >> the default - i.e. the data manipulation operations simply create >> the target node if it does not exist. We can set the "overwrite >> policy" to "don't overwrite - throw fault" by default with an >> optional flag to force the overwrite (permissions allowing of >> course). >> >> Paul. >> >> On 20.06.2006, at 09:31, Guy Rixon wrote: >> >>> On Tue, 20 Jun 2006, Paul Harrison wrote: >>> >>>> Cannot the functionality be simply overloaded on createNode? >>> >>> >>> The idea was to avoid overloading operation names. There's a >>> rumor that >>> overloading doesn't work consistently with doc/literal/wrapped. >>> >>>> >>>> On 16.06.2006, at 16:39, Guy Rixon wrote: >>>> >>>>> CreateUniqueNode is fine by me. >>>>> >>>>> On Fri, 16 Jun 2006, Dave Morris wrote: >>>>> >>>>>> How about calling it CreateUniqueNode ? >>>>>> Takes optional set of properties and returns a new DataNode >>>>>> with a >>>>>> unique name within the space. >>>>>> >>>>>> We can add a type parameter in VoSpace-2.x to allow this to >>>>>> create >>>>>> other >>>>>> types of node, including containers. >>>>>> >>>>>> Dave >>>>>> >>>>>> Guy Rixon wrote: >>>>>> >>>>>>> Yes to introducing CreateTempNode as you have written it with >>>>>>> these caveats: >>>>>>> >>>>>>> 1. Is createTempNode the best name? >>>>>>> >>>>>>> 2. Spec needs language making it clear that the node is created >>>>>>> with a >>>>>>> guaranteed-unique name. >>>>>>> >>>>>>> 3. Any other special semantics that we need to write down? >>>>>>> >>>>>>> 4. Is it a special type of node? (I suggest it can't be, >>>>>>> since we >>>>>>> only really >>>>>>> have data nodes at this stage.) >>>>>>> >>>>>>> 5. The name parameter on the basic createNode will become >>>>>>> mandatory if we make >>>>>>> this change. >>>>>>> >>>>>>> Given that the node is an ordinary data-node and doesn't have >>>>>>> any >>>>>>> temporary-file semantics (c.f. the POSIX temporary files that >>>>>>> disappear when >>>>>>> the creating process exists), I suggest that >>>>>>> createAndNameNode is >>>>>>> a better >>>>>>> name than createTempNode. >>>>>>> >>>>>>> (BTW, when we extend this to VOSpace 2, I hope we'll allow >>>>>>> creation of >>>>>>> auto-named container-nodes as well. But let's not get side- >>>>>>> tracked by that >>>>>>> now.) >>>>>>> >>>>>>> Cheers, >>>>>>> Guy >>>>>>> >>>>>>> On Thu, 15 Jun 2006, Matthew Graham wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I accept Dave's suggestions. >>>>>>>> >>>>>>>> I also accept Guy's suggestion for a separate operation for >>>>>>>> creating a >>>>>>>> temporary node with a server-generated name and propose adding >>>>>>>> this text >>>>>>>> to the spec: >>>>>>>> >>>>>>>> createTempNode >>>>>>>> >>>>>>>> Creates a temporary node in a space. This method is used to >>>>>>>> create a >>>>>>>> temporary data node. >>>>>>>> >>>>>>>> Parameters: None >>>>>>>> >>>>>>>> Returns: A element for the new node. >>>>>>>> >>>>>>>> Faults: The service may throw an OperationNotSupported >>>>>>>> exception if it >>>>>>>> does not support temporary nodes. >>>>>>>> The service may throw an InternalFault >>>>>>>> exception if an >>>>>>>> operation fails. >>>>>>>> The service may throw a PermissionDenied exception >>>>>>>> if the >>>>>>>> user does not have permissions to perform the operation. >>>>>>>> >>>>>>>> Questions: >>>>>>>> - Should a properties structure be an optional parameter? >>>>>>>> - A user can always make a temporary node permanent by renaming >>>>>>>> it to >>>>>>>> something more meaningful. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Matthew >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Guy Rixon wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Use case for server-generated names: when clients working in >>>>>>>>> the same space >>>>>>>>> want to generate temporary files with unique names. Java >>>>>>>>> File.makeTempFile() >>>>>>>>> and all that. If we support this, it might deserve its own >>>>>>>>> operation with >>>>>>>>> different parameters from createNode. >>>>>>>>> >>>>>>>>> On Thu, 15 Jun 2006, Dave Morris wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Paul Harrison wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 14.06.2006, at 14:01, Dave Morris wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> However, when creating a new node, it was agreed that the >>>>>>>>>>>> client >>>>>>>>>>>> would supply the name as a plain text string, and the >>>>>>>>>>>> server >>>>>>>>>>>> would >>>>>>>>>>>> convert this into the URI encoded identifier. >>>>>>>>>>>> This means that the server side code does the URI encoding, >>>>>>>>>>>> making >>>>>>>>>>>> it easier to verify that we get it right. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The operations that create a new node (CreateNode, >>>>>>>>>>>> PushDataTo and >>>>>>>>>>>> PullDataTo) take the name of the new node, not the >>>>>>>>>>>> identifier. >>>>>>>>>>>> This gives us a way of distinguishing between import >>>>>>>>>>>> into an >>>>>>>>>>>> existing node (node URI) and import into a new node (node >>>>>>>>>>>> name). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> also I think that there was also the idea that the >>>>>>>>>>> server would >>>>>>>>>>> generate a name automatically so the URI could point to a >>>>>>>>>>> container... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> The distinction still isn't as clear as I would like, but >>>>>>>>>>>> that is >>>>>>>>>>>> what is in the current document. >>>>>>>>>>>> If we want to change this, then we will need to modify the >>>>>>>>>>>> document. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I think that the semantics of these operations are not still >>>>>>>>>>> clear as >>>>>>>>>>> currently implemented in the WSDL, and do need some work >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I too was struggling with how to represent these multiple >>>>>>>>>> parameters in >>>>>>>>>> the experimental WSDL examples I posted last week. >>>>>>>>>> If they are causing problems, do we want to look at these >>>>>>>>>> again, and >>>>>>>>>> possibly simplify them. >>>>>>>>>> >>>>>>>>>> ---- >>>>>>>>>> >>>>>>>>>> Server generated identifiers : >>>>>>>>>> The original reason for server generated identifiers dates >>>>>>>>>> back to when >>>>>>>>>> we had two separate namespaces, VOSpace with user defined >>>>>>>>>> names, and >>>>>>>>>> VOStore with server generated names. >>>>>>>>>> The VOStore service needed to generate the names in order to >>>>>>>>>> ensure that >>>>>>>>>> they were unique within that service. >>>>>>>>>> >>>>>>>>>> Now that we have brought everything into one VOSpace >>>>>>>>>> namespace, I don't >>>>>>>>>> think we need the server generated names any more. >>>>>>>>>> In which case, unless anyone has a compelling use case for >>>>>>>>>> this, I vote >>>>>>>>>> we drop it. >>>>>>>>>> >>>>>>>>>> ---- >>>>>>>>>> >>>>>>>>>> Plain string name : >>>>>>>>>> I proposed the idea of using the separate name and URI in >>>>>>>>>> methods that >>>>>>>>>> created nodes, primarily because I wanted to make the server >>>>>>>>>> responsible >>>>>>>>>> for encoding the URI correctly. >>>>>>>>>> The client would just supply the name as a plain text string, >>>>>>>>>> and the >>>>>>>>>> server would encode it to create the full URI identifier. >>>>>>>>>> >>>>>>>>>> However, both of us have found problems trying to define a >>>>>>>>>> clear and >>>>>>>>>> concise WSDL that distinguishes between an import operation >>>>>>>>>> that creates >>>>>>>>>> a new node and one that imports data into an existing >>>>>>>>>> node. In >>>>>>>>>> which >>>>>>>>>> case, it looks like having the separate name parameter for >>>>>>>>>> creating a >>>>>>>>>> new node is causing us more problems than it is worth. >>>>>>>>>> >>>>>>>>>> ---- >>>>>>>>>> >>>>>>>>>> For VoSpace-1.0 I propose we drop both the server generated >>>>>>>>>> names and >>>>>>>>>> the separate name as string parameter. >>>>>>>>>> >>>>>>>>>> 1) CreateNode takes a mandatory target URI of the new node, >>>>>>>>>> rather than >>>>>>>>>> the optional string name. >>>>>>>>>> The target URI cannot be null, and the service does not >>>>>>>>>> automatically >>>>>>>>>> generate new names. >>>>>>>>>> It is up to the client to create and encode the target URI >>>>>>>>>> correctly. >>>>>>>>>> If the server receives an invalid URI, it throws an >>>>>>>>>> Exception. >>>>>>>>>> >>>>>>>>>> 2) The two import methods also take a single URI parameter to >>>>>>>>>> identify >>>>>>>>>> the target node. >>>>>>>>>> The target URI cannot be null, and the service does not >>>>>>>>>> automatically >>>>>>>>>> generate new names. >>>>>>>>>> It is up to the client to create and encode the target URI >>>>>>>>>> correctly. >>>>>>>>>> If the server receives an invalid URI, it throws an >>>>>>>>>> Exception. >>>>>>>>>> If the target node already exists, then its contents will be >>>>>>>>>> replaced by >>>>>>>>>> the import. >>>>>>>>>> If the target node does not exist, then the import methods >>>>>>>>>> will create a >>>>>>>>>> new node and import the data into that. >>>>>>>>>> (this also implies that the flag is no longer >>>>>>>>>> needed >>>>>>>>>> either) >>>>>>>>>> >>>>>>>>>> Then, to make things symmetrical : >>>>>>>>>> >>>>>>>>>> 3) MoveNode takes two URIs, representing the source and >>>>>>>>>> destination. >>>>>>>>>> The source URI cannot be null and must point to an >>>>>>>>>> existing node. >>>>>>>>>> The destination URI cannot be null, and must NOT point to an >>>>>>>>>> existing node. >>>>>>>>>> If a node already exists with the destination URI, then the >>>>>>>>>> method >>>>>>>>>> throws a DuplicateNodeException. >>>>>>>>>> It is up to the client to create and encode the destination >>>>>>>>>> URI correctly. >>>>>>>>>> If the server receives an invalid URI, it throws an >>>>>>>>>> Exception. >>>>>>>>>> >>>>>>>>>> 4) CopyNode takes two URIs, representing the source and >>>>>>>>>> destination. >>>>>>>>>> The source URI cannot be null and must point to an >>>>>>>>>> existing node. >>>>>>>>>> The destination URI cannot be null, and must NOT point to an >>>>>>>>>> existing node. >>>>>>>>>> If a node already exists with the destination URI, then the >>>>>>>>>> method >>>>>>>>>> throws a DuplicateNodeException. >>>>>>>>>> It is up to the client to create and encode the destination >>>>>>>>>> URI correctly. >>>>>>>>>> If the server receives an invalid URI, it throws an >>>>>>>>>> Exception. >>>>>>>>>> >>>>>>>>>> To support client encoded URIs : >>>>>>>>>> >>>>>>>>>> 5) We need to add MalformedIdentifierException to the list of >>>>>>>>>> exceptions >>>>>>>>>> for all the methods that take URI parameters. >>>>>>>>>> >>>>>>>>>> Hopefully, this should make the service API and WSDL a lot >>>>>>>>>> clearer. >>>>>>>>>> >>>>>>>>>> One caveat : >>>>>>>>>> I would like to re-visit this when we look at v2.x, based on >>>>>>>>>> what we >>>>>>>>>> find using v1.0 in real applications. >>>>>>>>>> >>>>>>>>>> ---- >>>>>>>>>> >>>>>>>>>> Matthew is right when he says that if we have any changes we >>>>>>>>>> should be >>>>>>>>>> discussing them in the document, and not the WSDL. >>>>>>>>>> The WSDL should reflect the specification as defined in the >>>>>>>>>> document, >>>>>>>>>> presenting it in a machine readable form. >>>>>>>>>> >>>>>>>>>> So, based on the fact that both Paul and I have both found >>>>>>>>>> problems in >>>>>>>>>> creating a clear and concise WSDL to represent this part >>>>>>>>>> of the >>>>>>>>>> specification and that the original use cases for the extra >>>>>>>>>> parameters >>>>>>>>>> are either no longer valid or not worth the hassle. >>>>>>>>>> I propose we make the above changes to the specification >>>>>>>>>> document, and >>>>>>>>>> then update the WSDL to match. >>>>>>>>>> >>>>>>>>>> Guy, Matthew, and Paul can you reply with 'accept' or >>>>>>>>>> 'reject' >>>>>>>>>> for the >>>>>>>>>> five changes outlined above. >>>>>>>>>> If everyone says yes, then we can update the document >>>>>>>>>> tomorrow >>>>>>>>>> and >>>>>>>>>> publish it as v0.22. >>>>>>>>>> >>>>>>>>>> I know this is a bit formal and possibly OTT, but I suspect >>>>>>>>>> that we will >>>>>>>>>> be making quite a few changes like this over the next few >>>>>>>>>> days. >>>>>>>>>> Making specific requests for individual changes to the >>>>>>>>>> document should >>>>>>>>>> make it easier to keep track of everything. >>>>>>>>>> >>>>>>>>>> I know there is at least one case where I found the list of >>>>>>>>>> exceptions >>>>>>>>>> was wrong on one of the methods, but right now I can't >>>>>>>>>> remember where it >>>>>>>>>> was. >>>>>>>>>> If I find it again I'll post another change request with the >>>>>>>>>> details. >>>>>>>>>> >>>>>>>>>> There are also a couple of questions / suggestions I would >>>>>>>>>> like to raise >>>>>>>>>> regarding data types and formats. >>>>>>>>>> I'll post another change request when I have worked out the >>>>>>>>>> details. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dave >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Guy Rixon gtr@ast.cam.ac.uk >>>>>>>>> Institute of Astronomy Tel: >>>>>>>>> +44-1223-337542 >>>>>>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: >>>>>>>>> +44-1223-337523 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> Guy Rixon gtr@ast.cam.ac.uk >>>>>>> Institute of Astronomy Tel: >>>>>>> +44-1223-337542 >>>>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: >>>>>>> +44-1223-337523 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> Guy Rixon gtr@ast.cam.ac.uk >>>>> Institute of Astronomy Tel: +44-1223-337542 >>>>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >>>> >>>> >>> >>> Guy Rixon gtr@ast.cam.ac.uk >>> Institute of Astronomy Tel: +44-1223-337542 >>> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 >> >> From owner-vospace@eso.org Tue Jun 20 16:54:04 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5KEp9P0014127 for ; Tue, 20 Jun 2006 16:51:09 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id k5KEp9Bk014126 for vospace-outgoing; Tue, 20 Jun 2006 16:51:09 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k5KEp4P0014110 for ; Tue, 20 Jun 2006 16:51:04 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k5KEp4XR015384 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 20 Jun 2006 16:51:04 +0200 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IVOA VoSpace mailing list From: Paul Harrison Subject: version 1.0rc2 of VOSpace WSDL Date: Tue, 20 Jun 2006 16:51:01 +0200 X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison The latest version 1.0rc2 of VOSpace WSDL is now available on the http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace10schema page - see there for more details. Paul Harrison ESO From owner-vospace@eso.org Wed Jul 5 19:50:08 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k65EQPOK005991 for ; Wed, 5 Jul 2006 16:26:25 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k65EQPoi005990 for vospace-outgoing; Wed, 5 Jul 2006 16:26:25 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k65EQOnG005985 for ; Wed, 5 Jul 2006 16:26:24 +0200 (MEST) Received: from apollo.le.ac.uk (apollo.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k65EQNXU028037 for ; Wed, 5 Jul 2006 16:26:23 +0200 (CEST) Received: from [143.210.37.63] (helo=urdlu) by apollo.le.ac.uk with esmtp (Exim 4.44) id 1Fy8KX-0001pR-Gt for vospace@ivoa.net; Wed, 05 Jul 2006 15:26:17 +0100 From: "Tony Linde" To: "IVOA VoSpace" Subject: Open Source Storage Management Project Date: Wed, 5 Jul 2006 15:26:14 +0100 Message-ID: <003201c6a03e$f882b550$0e01a8c0@urdlu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcagPvht34n+KnFVSOWoj6Rv88kiSQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-UoL-Id: 48479138a5c000f41229a8b2fb507f75@1Fy8KX-0001pR-Gt@apollo.le.ac.uk X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.7.5.63433 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: "Tony Linde" Interesting... http://www-03.ibm.com/servers/storage/community/ -- Tony Linde Phone: +44 (0)116 223 1292 Mobile: +44 (0)785 298 8840 Fax: +44 (0)116 252 3311 Email: Tony.Linde@leicester.ac.uk Post: Department of Physics & Astronomy, University of Leicester, Leicester, UK LE1 7RH Website: http://www.star.le.ac.uk/~ael Calendar: http://cal.tonylinde.com Programme Manager, AstroGrid http://www.astrogrid.org Project Manager, EuroVO VOTech http://eurovotech.org From owner-vospace@eso.org Thu Aug 3 11:56:42 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k739uLia001964 for ; Thu, 3 Aug 2006 11:56:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k739uL5W001962 for vospace-outgoing; Thu, 3 Aug 2006 11:56:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k739u36t001917; Thu, 3 Aug 2006 11:56:03 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k739u1um008241; Thu, 3 Aug 2006 11:56:01 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:34086) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1G8ZvY-0003WF-2Y (Exim 4.54) (return-path ); Thu, 03 Aug 2006 10:55:40 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id k739tbS3013421; Thu, 3 Aug 2006 10:55:37 +0100 (BST) Message-ID: <44D1C814.9090408@ast.cam.ac.uk> Date: Thu, 03 Aug 2006 10:55:32 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Graham CC: Guy Rixon , Paul Harrison , IVOA VoSpace mailing list Subject: Re: Import behaviour to StructuredDataNodes References: <44D1A3E5.7080901@cacr.caltech.edu> In-Reply-To: <44D1A3E5.7080901@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.3.15432 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris I would agree with Guy on this. If the (structured) data is stored in a database table, then even though you imported a votable the first time, it wouldn't prevent you from replacing the contents with data from a FITS file later. Even if the FITS file contained different columns. Use case - I'm setting up a database by importing into vospace API on the database system. I accidentally import the wrong file the first time. I should just be able to replace this by importing the correct file. Dave ps. Can we move the discussion back to the vospace list. Matthew Graham wrote: > Hi, > > When I create a StructuredDataNode (either through createNode or one > of the import methods), the created node will have the that > the service sets: > > > > > > > > > When data of a particular format flows to this node, should the list > of views be cut down to just that of the input data? > Input format is votable so should the node become: > > > > > > > > If I were then to attempt to update the data with a second import, I > would be constrained to provide my data in votable format. > Is this the behaviour we want? > > Cheers, > > Matthew From owner-vospace@eso.org Thu Aug 3 17:45:19 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k73FieE3006323 for ; Thu, 3 Aug 2006 17:44:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k73FiekL006322 for vospace-outgoing; Thu, 3 Aug 2006 17:44:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k73FiLYM006247 for ; Thu, 3 Aug 2006 17:44:22 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k73FiJLY024164 for ; Thu, 3 Aug 2006 17:44:20 +0200 (CEST) Received: from [172.16.1.35] (adsl-69-234-60-133.dsl.irvnca.pacbell.net [69.234.60.133]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k73Fi83G007608; Thu, 3 Aug 2006 08:44:08 -0700 Message-ID: <44D219C8.8080306@cacr.caltech.edu> Date: Thu, 03 Aug 2006 08:44:08 -0700 From: Matthew Graham User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Dave Morris CC: IVOA VoSpace mailing list Subject: Re: Import behaviour to StructuredDataNodes References: <44D1A3E5.7080901@cacr.caltech.edu> <44D1C814.9090408@ast.cam.ac.uk> In-Reply-To: <44D1C814.9090408@ast.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.3.75433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, So the list is unchanged once created but the list needs to change to reflect changes in data formats: 1. I create a StructuredDataNode: 2. I then put votable data into this so the shows the views applicable to this format: 3. At a later stage, I replace the votable with an image so now needs to change to reflect this: Cheers, Matthew Dave Morris wrote: > I would agree with Guy on this. > If the (structured) data is stored in a database table, then even > though you imported a votable the first time, it wouldn't prevent you > from replacing the contents with data from a FITS file later. > Even if the FITS file contained different columns. > > Use case - > I'm setting up a database by importing into vospace API on the > database system. > I accidentally import the wrong file the first time. > I should just be able to replace this by importing the correct file. > Dave > ps. Can we move the discussion back to the vospace list. > > Matthew Graham wrote: > >> Hi, >> >> When I create a StructuredDataNode (either through createNode or one >> of the import methods), the created node will have the that >> the service sets: >> >> >> >> >> >> >> >> >> When data of a particular format flows to this node, should the list >> of views be cut down to just that of the input data? >> Input format is votable so should the node become: >> >> >> >> >> >> >> >> If I were then to attempt to update the data with a second import, I >> would be constrained to provide my data in votable format. >> Is this the behaviour we want? >> >> Cheers, >> >> Matthew > > From owner-vospace@eso.org Thu Aug 3 21:42:53 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k73JgZd4014666 for ; Thu, 3 Aug 2006 21:42:35 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k73JgZGe014665 for vospace-outgoing; Thu, 3 Aug 2006 21:42:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k73JgAg3014571 for ; Thu, 3 Aug 2006 21:42:10 +0200 (MEST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k73Jg6LY005099 for ; Thu, 3 Aug 2006 21:42:06 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:46869) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1G8j4p-0001Yn-NJ (Exim 4.54) (return-path ); Thu, 03 Aug 2006 20:41:51 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id k73JfnkW004971; Thu, 3 Aug 2006 20:41:49 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id k73JfnI3006506; Thu, 3 Aug 2006 20:41:49 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.7+Sun/8.13.7/Submit) with ESMTP id k73JfmXs006502; Thu, 3 Aug 2006 20:41:49 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 3 Aug 2006 20:41:48 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Matthew Graham cc: Dave Morris , IVOA VoSpace mailing list Subject: Re: Import behaviour to StructuredDataNodes In-Reply-To: <44D219C8.8080306@cacr.caltech.edu> Message-ID: References: <44D1A3E5.7080901@cacr.caltech.edu> <44D1C814.9090408@ast.cam.ac.uk> <44D219C8.8080306@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.3.113433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon Yes, sounds right to me. On Thu, 3 Aug 2006, Matthew Graham wrote: > Hi, > > So the list is unchanged once created but the list > needs to change to reflect changes in data formats: > > 1. I create a StructuredDataNode: > > uri="vos://nvo.caltech!vospace/0001"> > > > > > > > 2. I then put votable data into this so the shows the views > applicable to this format: > > uri="vos://nvo.caltech!vospace/0001"> > > > > > > > > > > 3. At a later stage, I replace the votable with an image so > now needs to change to reflect this: > > uri="vos://nvo.caltech!vospace/0001"> > > > > > > > > > > Cheers, > > Matthew > > > Dave Morris wrote: > > I would agree with Guy on this. > > If the (structured) data is stored in a database table, then even > > though you imported a votable the first time, it wouldn't prevent you > > from replacing the contents with data from a FITS file later. > > Even if the FITS file contained different columns. > > > > Use case - > > I'm setting up a database by importing into vospace API on the > > database system. > > I accidentally import the wrong file the first time. > > I should just be able to replace this by importing the correct file. > > Dave > > ps. Can we move the discussion back to the vospace list. > > > > Matthew Graham wrote: > > > >> Hi, > >> > >> When I create a StructuredDataNode (either through createNode or one > >> of the import methods), the created node will have the that > >> the service sets: > >> > >> > >> > >> > >> > >> > >> > >> > >> When data of a particular format flows to this node, should the list > >> of views be cut down to just that of the input data? > >> Input format is votable so should the node become: > >> > >> > >> > >> > >> > >> > >> > >> If I were then to attempt to update the data with a second import, I > >> would be constrained to provide my data in votable format. > >> Is this the behaviour we want? > >> > >> Cheers, > >> > >> Matthew > > > > > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Mon Aug 7 06:50:49 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k774oKwx012314 for ; Mon, 7 Aug 2006 06:50:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k774oK3h012313 for vospace-outgoing; Mon, 7 Aug 2006 06:50:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k774oGsB012302 for ; Mon, 7 Aug 2006 06:50:16 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k774oDLY015826 for ; Mon, 7 Aug 2006 06:50:14 +0200 (CEST) Received: from [172.16.1.35] (adsl-69-234-60-102.dsl.irvnca.pacbell.net [69.234.60.102]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k774o13G029281; Sun, 6 Aug 2006 21:50:03 -0700 Message-ID: <44D6C677.7010200@cacr.caltech.edu> Date: Sun, 06 Aug 2006 21:49:59 -0700 From: Matthew Graham User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Guy Rixon CC: Dave Morris , IVOA VoSpace mailing list Subject: Exceptions missing text References: <44D1A3E5.7080901@cacr.caltech.edu> <44D1C814.9090408@ast.cam.ac.uk> <44D219C8.8080306@cacr.caltech.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.6.205433 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, Two problems with RC6: The InternalFaultType needs an element so that explanatory text can be added. The InvalidArgumentType needs at least an element to refer to the URI of the value that is causing the problem. Cheers, Matthew From owner-vospace@eso.org Mon Aug 14 12:55:50 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7EAtaob024948 for ; Mon, 14 Aug 2006 12:55:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7EAtaea024947 for vospace-outgoing; Mon, 14 Aug 2006 12:55:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7EAtWfS024938 for ; Mon, 14 Aug 2006 12:55:32 +0200 (MEST) Received: from atum.hq.eso.org (atum.hq.eso.org [134.171.42.41]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id k7EAtVd04312 for ; Mon, 14 Aug 2006 12:55:31 +0200 (MEST) Received: (from apache@localhost) by atum.hq.eso.org (8.11.6/8.8.8) id k7EAtVt05355 for vospace@ivoa.net; Mon, 14 Aug 2006 12:55:31 +0200 Received: from 80.187.149.61 ([80.187.149.61]) by webmail.eso.org (IMP) with HTTP for ; Mon, 14 Aug 2006 12:55:31 +0200 Message-ID: <1155552931.44e056a3cd8a3@webmail.eso.org> Date: Mon, 14 Aug 2006 12:55:31 +0200 From: Markus Dolensky To: vospace@ivoa.net Subject: remarks about VOSpace level 1 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 80.187.149.61 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Markus Dolensky Dear All, Here my comments regarding the VOSpace level 1 doc (http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/vospace-022-0713.doc): section 3.3 What's the difference between a 'view' as defined in the document and a MIME type? Is it worth maintaining a specific list of data formats? And even so, how would this be done assuring some coherence? 5.1.3 Is there a list of (potential) service properties? Sample B1 in the appendix has a comment saying "List the service properties" It is, however, actually followed by node properities instead. 5.2.3 The paging mechanism is certainly a 'nice to have'. Judging from the list of exceptions it is one of the most complicated concepts in this spec. Therefore, I'd suggest to provide means to filter node listings instead. Filtering by node property value and owner (user/creator), for instance. Paging is not enough on its own without some prior sorting that brings the relevant records to the top. Otherwise it is likely that one has to page all the way to the end anyway. So again, it appears rather complicated but inefficient from a user's perspective and one can live without it in level 1. On the other hand it is much harder to life with some other limitations. Even when accepting that there are no directories and no operations to change access policy for the sake of simplicity I would still argue that some cross VOSpace store operations can be supported without bloating the level 1 specs: A VOSpace that supports pullData{To|From}VOSpace can exploit this functionality to implement copyNode and moveNode across stores. 5.2.4 What is the practical purpose of moveNode as is? According to the specs the data are untouched and it's just a way to create another node with some different identifier. Here's what I would expect from an operation called moveNode: - each node has a 'mandatory' name property similar to a filename - moveNode sets this property to a new value - when a different store is given as a 2nd parameter then it physically copies the data using pullDataToVOSpace and deleteNode. A last general remark: Only after going over the verbose XML messages it became apparent to me that this spec allows for specialized stores for DB storage and image manipulation. It would be interesting to see a bit clearer how to exploit this functionality given some scenario rather than being extremely detailed about specific XML messages. So, thanks to the authors for their hard work in finding their way to an agreed document (which always involves difficult compromises). - Markus From owner-vospace@eso.org Tue Aug 15 11:09:24 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7F997h6020558 for ; Tue, 15 Aug 2006 11:09:07 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7F997w5020557 for vospace-outgoing; Tue, 15 Aug 2006 11:09:07 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7F992Ri020548 for ; Tue, 15 Aug 2006 11:09:02 +0200 (MEST) Received: from sol.star.bris.ac.uk (sol.star.bris.ac.uk [137.222.58.39]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7F991um008941 for ; Tue, 15 Aug 2006 11:09:01 +0200 (CEST) Received: from andromeda.star.bris.ac.uk ([137.222.58.155] ident=root) by sol.star.bris.ac.uk with esmtp (Exim 3.35 #1) id 1GCuut-00052c-00 for vospace@ivoa.net; Tue, 15 Aug 2006 10:08:55 +0100 Received: from mbt (helo=localhost) by andromeda.star.bris.ac.uk with local-esmtp (Exim 3.36 #1) id 1GCuut-000784-00 for vospace@ivoa.net; Tue, 15 Aug 2006 10:08:55 +0100 Date: Tue, 15 Aug 2006 10:08:55 +0100 (BST) From: Mark Taylor X-X-Sender: mbt@andromeda.star.bris.ac.uk To: vospace@ivoa.net Subject: Re: remarks about VOSpace level 1 In-Reply-To: <1155552931.44e056a3cd8a3@webmail.eso.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.15.15442 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Mark Taylor On Mon, 14 Aug 2006, Markus Dolensky wrote: > 5.2.3 > The paging mechanism is certainly a 'nice to have'. Judging from the list of > exceptions it is one of the most complicated concepts in this spec. Therefore, > I'd suggest to provide means to filter node listings instead. Filtering by node > property value and owner (user/creator), for instance. > > Paging is not enough on its own without some prior sorting that brings the > relevant records to the top. Otherwise it is likely that one has to page all the > way to the end anyway. > > So again, it appears rather complicated but inefficient from a user's > perspective and one can live without it in level 1. Markus, I think you may have misapprehended the point of this feature. Paging is not mainly intended as a convenience for users so that they get relevant records without looking at all the data, but as a protection for software, both at the server and at the client ends. Without such a mechanism a client might in principle be delivered a multi-megabyte list of nodes which could put strains on its resource usage. Similarly, a server might have to stage such a response prior to sending it. In fact in many or most situations in which this facility is used, the expectation will be that the client does retrieve all the nodes in the list rather than just one or a few pages, but this can be effected with both ends of the connection able to budget their storage in a controlled way during the transfer. Disclaimer: I've not really been involved in VOSpace design, so if it's me whose misunderstood here then (a) apologies and (b) can someone who does understand it post a correction. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From owner-vospace@eso.org Tue Aug 15 18:48:19 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7FGm55c017543 for ; Tue, 15 Aug 2006 18:48:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7FGm5lt017542 for vospace-outgoing; Tue, 15 Aug 2006 18:48:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7FGm17t017533 for ; Tue, 15 Aug 2006 18:48:01 +0200 (MEST) Received: from atum.hq.eso.org (atum.hq.eso.org [134.171.42.41]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id k7FGm1d18715 for ; Tue, 15 Aug 2006 18:48:01 +0200 (MEST) Received: (from apache@localhost) by atum.hq.eso.org (8.11.6/8.8.8) id k7FGm1G26136 for vospace@ivoa.net; Tue, 15 Aug 2006 18:48:01 +0200 Received: from vpn-2.hq.eso.org (vpn-2.hq.eso.org [134.171.76.2]) by webmail.eso.org (IMP) with HTTP for ; Tue, 15 Aug 2006 18:48:01 +0200 Message-ID: <1155660481.44e1fac11adfe@webmail.eso.org> Date: Tue, 15 Aug 2006 18:48:01 +0200 From: Markus Dolensky To: vospace@ivoa.net Subject: Re: remarks about VOSpace level 1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 134.171.76.2 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Markus Dolensky Hi, Quoting Mark Taylor : > I think you may have misapprehended the point of this feature. > Paging is not mainly intended as a convenience for users so that > they get relevant records without looking at all the data, but as > a protection for software, both at the server and at the client ends. > Without such a mechanism a client might in principle be delivered > a multi-megabyte list of nodes which could put strains on its > resource usage. Similarly, a server might have to stage such a > response prior to sending it. In fact in many or most situations > in which this facility is used, the expectation will be that the client > does retrieve all the nodes in the list rather than just one or a few > pages, but this can be effected with both ends of the connection able to > budget their storage in a controlled way during the transfer. Nonetheless, a filter capability to restrict the response in first place and - if bandwidth is the rationale for paging - then a store-specific MaxRecords-limit can take care of it. -Markus From owner-vospace@eso.org Tue Aug 15 19:54:15 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7FHrVTZ025691 for ; Tue, 15 Aug 2006 19:53:31 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7FHrVf1025689 for vospace-outgoing; Tue, 15 Aug 2006 19:53:31 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7FHr1lc025639; Tue, 15 Aug 2006 19:53:02 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7FHquLY022050; Tue, 15 Aug 2006 19:52:58 +0200 (CEST) Received: from [192.168.1.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k7FHqo3G008481; Tue, 15 Aug 2006 10:52:50 -0700 Message-ID: <44E209ED.5000309@cacr.caltech.edu> Date: Tue, 15 Aug 2006 10:52:45 -0700 From: Matthew Graham User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Markus Dolensky CC: vospace@ivoa.net Subject: Re: remarks about VOSpace level 1 References: <1155552931.44e056a3cd8a3@webmail.eso.org> In-Reply-To: <1155552931.44e056a3cd8a3@webmail.eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.15.103442 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, Markus Dolensky wrote: > Dear All, > > Here my comments regarding the VOSpace level 1 doc > (http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/vospace-022-0713.doc): > > > section 3.3 > What's the difference between a 'view' as defined in the document and a MIME type? > > Is it worth maintaining a specific list of data formats? > And even so, how would this be done assuring some coherence? > A view defines a data format: the URI of a view is semantically equivalent to a MIME type but the view structure also provides information about whether if a particular view is used (to export data) then the bit pattern of the data is preserved and allows for additional parameters to be specified that are needed to define the view, e.g. JPEG compression level. The view URI is an IVOA identifier which points to resource description of the data format stored in a registry: the records will most likely be of xsi:type="vt:Standard" and we are hoping that there will be a central registry within the IVOA for registration of standards. > 5.1.3 > Is there a list of (potential) service properties? > > Sample B1 in the appendix has a comment saying > "List the service properties" > It is, however, actually followed by node properities instead. > The getProperties() method needs updating to reflect what is in the latest version (rc6) of the WSDL: getProperties() now returns: a list of identifiers for the properties that the service accepts and understands; a list of identifiers for the properties that the service provides; and a list of identifiers for all the properties currently used by nodes within the service. > 5.2.3 > The paging mechanism is certainly a 'nice to have'. Judging from the list of > exceptions it is one of the most complicated concepts in this spec. Therefore, > I'd suggest to provide means to filter node listings instead. Filtering by node > property value and owner (user/creator), for instance. > > Paging is not enough on its own without some prior sorting that brings the > relevant records to the top. Otherwise it is likely that one has to page all the > way to the end anyway. > > So again, it appears rather complicated but inefficient from a user's > perspective and one can live without it in level 1. > Filtering is a search functionality and we decided that it was one of the things to save for a later version of VOSpace in order to get v1.0 out of the door as quickly as possible. > On the other hand it is much harder to life with some other limitations. Evwhen accepting that there are no directories and no operations to change access > policy for the sake of simplicity I would still argue that some cross VOSpace > store operations can be supported without bloating the level 1 specs: > > A VOSpace that supports pullData{To|From}VOSpace can exploit this functionality > to implement copyNode and moveNode across stores. > VOSpace 1.0 (and indeed it's predecessor VOStore 1.0) has always conceptually been about flat, unconnected data stores; any notion of other spaces only comes along later. This keeps the specification and the implementation simple and clean. > 5.2.4 > What is the practical purpose of moveNode as is? > > According to the specs the data are untouched and it's just a way to create > another node with some different identifier. Here's what I would expect from an > operation called moveNode: > > - each node has a 'mandatory' name property similar to a filename > - moveNode sets this property to a new value > - when a different store is given as a 2nd parameter then it physically copies > the data using pullDataToVOSpace and deleteNode. > It is anticipated that subsequent versions of VOSpace will increase the functional aspects of many of these methods: however, within the limited scope of v1.0 (flat unconnected store) some of them seem to do little but we need to include them to ensure future backwards-compatibility. moveNode allows the user to assign a new identifier to an existing node (and also to change any of the node's properties in the process if they so desire) - the data bytes attached to the node remain unchanged: copyNode will make another node with a different identifier containing a copy of the original data bytes. Specifying a different VOSpace as an additional argument is outside of the scope of v1.0. > A last general remark: > Only after going over the verbose XML messages it became apparent to me that > this spec allows for specialized stores for DB storage and image manipulation. > It would be interesting to see a bit clearer how to exploit this functionality > given some scenario rather than being extremely detailed about specific XML > messages. > This has always been in the scheme of things: the idea is that structured and unstructured data objects are equivalent first-level entities but obviously understanding the internal structure of a data object means that you could do things with it. If it supports this type of operation (and I stress if - this is *not* a mandatory requirement for a space), a space can offer different views of a structured data object (the analogy is with views of a db table) so a FITS image could be viewed as a JPEG or a GIF or a VOTable as a CSV file. One use case is a SkyNode which has a VOSpace interface: the VOSpace interface can be used for loading the db that the SkyNode presents: in this case, the import view is just the import data format but since it is specified, the space knows how to convert it to a table for the SkyNode to use. > So, thanks to the authors for their hard work in finding their way to an agreed > document (which always involves difficult compromises) We're slowly getting there :-) Cheers, Matthew From owner-vospace@eso.org Wed Aug 16 10:40:44 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7G8dsRc024169 for ; Wed, 16 Aug 2006 10:39:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7G8dsMO024168 for vospace-outgoing; Wed, 16 Aug 2006 10:39:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7G8dc33024103; Wed, 16 Aug 2006 10:39:38 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7G8dZum009431; Wed, 16 Aug 2006 10:39:35 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:53182) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1GDGvn-0005cT-2B (Exim 4.54) (return-path ); Wed, 16 Aug 2006 09:39:20 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id k7G8dGTm026339; Wed, 16 Aug 2006 09:39:16 +0100 (BST) Message-ID: <44E2D9AF.50908@ast.cam.ac.uk> Date: Wed, 16 Aug 2006 09:39:11 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Dolensky , vospace@ivoa.net Subject: Re: remarks about VOSpace level 1 References: <1155552931.44e056a3cd8a3@webmail.eso.org> In-Reply-To: <1155552931.44e056a3cd8a3@webmail.eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.15.175442 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Markus Dolensky wrote: >5.2.3 >The paging mechanism is certainly a 'nice to have'. Judging from the list of >exceptions it is one of the most complicated concepts in this spec. Therefore, >I'd suggest to provide means to filter node listings instead. Filtering by node >property value and owner (user/creator), for instance. > >Paging is not enough on its own without some prior sorting that brings the >relevant records to the top. Otherwise it is likely that one has to page all the >way to the end anyway. > >So again, it appears rather complicated but inefficient from a user's >perspective and one can live without it in level 1. > > Mark Taylor has already mentioned some of this. The paging mechanism is not really intended to display a series of separate pages to the user e.g. Google search results. As Mark has suggested, the reason for splitting the results into a series of pages is to enable the system to handle large numbers of files without overloading the server or client. There is no limit on the number of files in a space, and one of the target requirements was that the system should be able to handle lists of over 10^6 files without failing. Although this wouldn't be an ideal way of organizing the data, it is possible to imagine a complex workflow creating a huge number of intermediate temp files, or a VO event receiver that stored a record of all the events for it received. The paging mechanism enables us to avoid overloading the system if a client requested a list of the contents of a large space. It also enables GUI developers to make the system appear much more responsive. If a space contains a large number of files, a GUI client could start to render the first set of results as soon as it receives them, rather than wait for the whole list to arrive. Your suggestion of sorting or filtering the list based on node properties would indeed be a very useful facility. We are planning to add more functionality to the list mechanism, including the ability to search, filter and sort the results based on node properties. However, this will probably be added as separate search API in future versions of VOSpace. >On the other hand it is much harder to life with some other limitations. Even >when accepting that there are no directories and no operations to change access >policy for the sake of simplicity I would still argue that some cross VOSpace >store operations can be supported without bloating the level 1 specs: > >A VOSpace that supports pullData{To|From}VOSpace can exploit this functionality >to implement copyNode and moveNode across stores. > > It is very tempting to try and include this type of functionality. Unfortunately enabling pullData{To|From}VOSpace to move data direct from one space to another without involving the client does not scale well. Solving this is the reason that VOSpace has taken so long to get to this stage. If the transfer only involves two spaces, then a direct transfer would probably work. However, the next stages in the VOSpace road map are to add containers and inter-space links which will link the separate space services and make them behave as one unified space. This document may provide a better explanation of why we avoided server to server method calls. http://wiki.astrogrid.org/bin/view/Astrogrid/VoSpace20060228 The inter-space links mean that the target path for a transfer may not point to a file within the a single space, part of the path include a link into another space, which may in turn contain a link into another space ... etc. >5.2.4 >What is the practical purpose of moveNode as is? > >According to the specs the data are untouched and it's just a way to create >another node with some different identifier. Here's what I would expect from an >operation called moveNode: > >- each node has a 'mandatory' name property similar to a filename >- moveNode sets this property to a new value >- when a different store is given as a 2nd parameter then it physically copies >the data using pullDataToVOSpace and deleteNode. > > You are right, within a flat space of a VOSpace-1.0 service MoveNode is effectively 'rename'. Once we get containers in place (top of the list for next version), MoveNode will move the node within the tree of containers within the space. However, moving data between space services will still be part of the client API. Again, moving data between services without involving the client does not scale well once we have inter-space links. (see above document on links) >A last general remark: >Only after going over the verbose XML messages it became apparent to me that >this spec allows for specialized stores for DB storage and image manipulation. >It would be interesting to see a bit clearer how to exploit this functionality >given some scenario rather than being extremely detailed about specific XML >messages. > > Point taken. There is still a lot of work to do in describing how it all fits together, with clearer and more detailed more examples and explanations. >So, thanks to the authors for their hard work in finding their way to an agreed >document (which always involves difficult compromises). > >- Markus > > Thank you for your comments and feedback. VOSpace-1.0 provides a very basic service, but we hope to address many of the limitations you highlighted in future versions of the specification. Many thanks, Dave Morris From owner-vospace@eso.org Wed Aug 16 13:23:31 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7GBNEmG015587 for ; Wed, 16 Aug 2006 13:23:14 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7GBNEeX015586 for vospace-outgoing; Wed, 16 Aug 2006 13:23:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7GBN1bM015561; Wed, 16 Aug 2006 13:23:01 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k7GBN1sD004261 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 16 Aug 2006 13:23:01 +0200 In-Reply-To: <44E2D9AF.50908@ast.cam.ac.uk> References: <1155552931.44e056a3cd8a3@webmail.eso.org> <44E2D9AF.50908@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Markus Dolensky , vospace@ivoa.net Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: remarks about VOSpace level 1 Date: Wed, 16 Aug 2006 13:22:57 +0200 To: Dave Morris X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 16.08.2006, at 10:39, Dave Morris wrote: > >> 5.2.3 >> The paging mechanism is certainly a 'nice to have'. Judging from >> the list of >> exceptions it is one of the most complicated concepts in this >> spec. Therefore, >> I'd suggest to provide means to filter node listings instead. >> Filtering by node >> property value and owner (user/creator), for instance. >> Paging is not enough on its own without some prior sorting that >> brings the >> relevant records to the top. Otherwise it is likely that one has >> to page all the >> way to the end anyway. >> So again, it appears rather complicated but inefficient from a user's >> perspective and one can live without it in level 1. >> > Mark Taylor has already mentioned some of this. > The paging mechanism is not really intended to display a series of > separate pages to the user e.g. Google search results. > > As Mark has suggested, the reason for splitting the results into a > series of pages is to enable the system to handle large numbers of > files without overloading the server or client. > > There is no limit on the number of files in a space, and one of the > target requirements was that the system should be able to handle > lists of over 10^6 files without failing. > Although this wouldn't be an ideal way of organizing the data, it > is possible to imagine a complex workflow creating a huge number of > intermediate temp files, or a VO event receiver that stored a > record of all the events for it received. The paging mechanism > enables us to avoid overloading the system if a client requested a > list of the contents of a large space. > > It also enables GUI developers to make the system appear much more > responsive. > If a space contains a large number of files, a GUI client could > start to render the first set of results as soon as it receives > them, rather than wait for the whole list to arrive. > > Your suggestion of sorting or filtering the list based on node > properties would indeed be a very useful facility. > We are planning to add more functionality to the list mechanism, > including the ability to search, filter and sort the results based > on node properties. > However, this will probably be added as separate search API in > future versions of VOSpace. I thought that we had agreed that basically in a 1.x version of VOSpace we would enhance the list function to have simple wildcarding facilities comparable to those for 'ls' in a unix shell, where a full search (analogous to unix 'find') would be part of a future API. Paul. From owner-vospace@eso.org Wed Aug 16 14:55:29 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7GCstaP005149 for ; Wed, 16 Aug 2006 14:54:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7GCstw7005148 for vospace-outgoing; Wed, 16 Aug 2006 14:54:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7GCshdq005088; Wed, 16 Aug 2006 14:54:43 +0200 (MEST) Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7GCsfum021299; Wed, 16 Aug 2006 14:54:41 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:38320) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1GDKug-0003GQ-WC (Exim 4.54) (return-path ); Wed, 16 Aug 2006 13:54:26 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id k7GCsOlg011770; Wed, 16 Aug 2006 13:54:24 +0100 (BST) Message-ID: <44E3157B.6060403@ast.cam.ac.uk> Date: Wed, 16 Aug 2006 13:54:19 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: vospace@ivoa.net Subject: Re: remarks about VOSpace level 1 References: <1155552931.44e056a3cd8a3@webmail.eso.org> <44E2D9AF.50908@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.16.52943 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > On 16.08.2006, at 10:39, Dave Morris wrote: > >> Your suggestion of sorting or filtering the list based on node >> properties would indeed be a very useful facility. >> We are planning to add more functionality to the list mechanism, >> including the ability to search, filter and sort the results based >> on node properties. >> However, this will probably be added as separate search API in >> future versions of VOSpace. > > I thought that we had agreed that basically in a 1.x version of > VOSpace we would enhance the list function to have simple wildcarding > facilities comparable to those for 'ls' in a unix shell, where a full > search (analogous to unix 'find') would be part of a future API. Absolutely. Dave From owner-vospace@eso.org Wed Aug 16 19:15:54 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7GHFW6G027673 for ; Wed, 16 Aug 2006 19:15:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7GHFWbg027671 for vospace-outgoing; Wed, 16 Aug 2006 19:15:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7GHFRJD027647 for ; Wed, 16 Aug 2006 19:15:27 +0200 (MEST) Received: from atum.hq.eso.org (atum.hq.eso.org [134.171.42.41]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id k7GHFRd09695 for ; Wed, 16 Aug 2006 19:15:27 +0200 (MEST) Received: (from apache@localhost) by atum.hq.eso.org (8.11.6/8.8.8) id k7GHFRp13295 for vospace@ivoa.net; Wed, 16 Aug 2006 19:15:27 +0200 Received: from 80.187.209.26 ([80.187.209.26]) by webmail.eso.org (IMP) with HTTP for ; Wed, 16 Aug 2006 19:15:27 +0200 Message-ID: <1155748527.44e352af69b9f@webmail.eso.org> Date: Wed, 16 Aug 2006 19:15:27 +0200 From: Markus Dolensky To: vospace@ivoa.net Subject: Re: remarks about VOSpace level 1 References: <1155552931.44e056a3cd8a3@webmail.eso.org> <44E2D9AF.50908@ast.cam.ac.uk> In-Reply-To: <44E2D9AF.50908@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 80.187.209.26 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Markus Dolensky Hi VOSpronauts: Quoting Dave Morris : > If the transfer only involves two spaces, then a direct transfer would > probably work. > However, the next stages in the VOSpace road map are to add containers > and inter-space links which will link the separate space services and > make them behave as one unified space. Hm, simple is not complicated enough it seems :^) The fact that there is already a way of supporting cross server operations (copy, move) with the existing methods was meant to show an option to keep implementation effort low. A specification should not disallow certain operations on the grounds that it won't be sophisticated enough to also cope with future requirements. > As Mark has suggested, the reason for splitting the results into a > series of pages is to enable the system to handle large numbers of files > without overloading the server or client. The incentive of my suggestions is to maintain simplicity by focusing on some usability issues. For instance, if the specification 'allows' to filter list output then this is a way to avoid such an overload. Dave's and Paul's latest postings seem to confirm that we anyway agree on this particular list functionality. Greetings, Markus From owner-vospace@eso.org Thu Aug 17 13:07:18 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HB6qMv015568 for ; Thu, 17 Aug 2006 13:06:52 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7HB6qoX015565 for vospace-outgoing; Thu, 17 Aug 2006 13:06:52 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HB6gBe015537 for ; Thu, 17 Aug 2006 13:06:42 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7HB6cum027419 for ; Thu, 17 Aug 2006 13:06:40 +0200 (CEST) Received: from [10.115.23.243] ([80.187.151.65]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k7HB6U3H003493 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Aug 2006 04:06:32 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-31--735559596 Message-Id: <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> Cc: Roy Williams From: Roy Williams Subject: Fwd: Amazon VOStore? Date: Thu, 17 Aug 2006 04:06:22 -0700 To: vospace@ivoa.net X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.15.175442 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Roy Williams --Apple-Mail-31--735559596 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I wonder what is common and what is different between Amazon S3 and VOSpace? Roy Begin forwarded message: > From: "Alex Szalay" > Date: August 17, 2006 12:49:14 AM PDT > To: "'Roy Williams'" , "'Alex Szalay'" > > Subject: Amazon VOStore? > > http://www.amazon.com/b/ref=sc_fe_l_2/104-7699424-9544708? > ie=UTF8&node=16427261&no=15879911&me=A36L942TSJ2AJA > > We should look at the WS specs. > > --Alex > California Institute of Technology 626 395 3670 --Apple-Mail-31--735559596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I wonder what is common and what = is different between Amazon S3 and = VOSpace?
Roy

Begin forwarded message:

From: = "Alex Szalay" <szalay@jhu.edu>
Date: = August 17, 2006 12:49:14 AM PDT
To: "'Roy = Williams'" <roy@cacr.caltech.edu>, = "'Alex Szalay'" <szalay@jhu.edu>
Subject: = Amazon VOStore?

=A0
We should = look at the WS specs.=A0=A0
=A0
--Alex
=A0

California Institute of = Technology

626 395 = 3670


= --Apple-Mail-31--735559596-- From owner-vospace@eso.org Thu Aug 17 13:18:06 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HBHsTo018544 for ; Thu, 17 Aug 2006 13:17:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7HBHs70018543 for vospace-outgoing; Thu, 17 Aug 2006 13:17:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HBHngU018511 for ; Thu, 17 Aug 2006 13:17:50 +0200 (MEST) Received: from dot.ex.ac.uk (dot.ex.ac.uk [144.173.6.11]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7HBHmLY015141 for ; Thu, 17 Aug 2006 13:17:48 +0200 (CEST) Received: from [144.173.229.234] (helo=[10.0.1.4]) by dot.ex.ac.uk with esmtpsa (Exim 4.62/mail:587) id 1GDfsd-0007ZA-Id; Thu, 17 Aug 2006 12:17:43 +0100 In-Reply-To: <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <693C97A1-79AE-4698-9069-1C81BA6222BA@astro.ex.ac.uk> Cc: vospace@ivoa.net Content-Transfer-Encoding: 7bit From: Alasdair Allan Subject: Re: Amazon VOStore? Date: Thu, 17 Aug 2006 12:17:40 +0100 To: Roy Williams X-Mailer: Apple Mail (2.746.2) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.17.35442 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Alasdair Allan Roy Williams wrote: > I wonder what is common and what is different between Amazon S3 and > VOSpace? I think VOStore and Amazon S3 are very similar, VOSpace is something that could sit on top of both (wasn't there some mumbling about using S3 as one of the backends for VOStore?) Al. From owner-vospace@eso.org Thu Aug 17 15:58:16 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HDv6vo022244 for ; Thu, 17 Aug 2006 15:57:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7HDoND4020119 for vospace-outgoing; Thu, 17 Aug 2006 15:50:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HDnk8T019727 for ; Thu, 17 Aug 2006 15:49:46 +0200 (MEST) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7HD7jum003706 for ; Thu, 17 Aug 2006 15:07:45 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:38630) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1GDhay-0003Ye-3P (Exim 4.54) (return-path ); Thu, 17 Aug 2006 14:07:36 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id k7HD7YZq021951; Thu, 17 Aug 2006 14:07:34 +0100 (BST) Message-ID: <44E46A11.4030807@ast.cam.ac.uk> Date: Thu, 17 Aug 2006 14:07:29 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alasdair Allan CC: Roy Williams , vospace@ivoa.net Subject: Re: Amazon VOStore? References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <693C97A1-79AE-4698-9069-1C81BA6222BA@astro.ex.ac.uk> In-Reply-To: <693C97A1-79AE-4698-9069-1C81BA6222BA@astro.ex.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.17.55442 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Alasdair Allan wrote: > Roy Williams wrote: > >> I wonder what is common and what is different between Amazon S3 and >> VOSpace? > > I think VOStore and Amazon S3 are very similar, VOSpace is something > that could sit on top of both (wasn't there some mumbling about using > S3 as one of the backends for VOStore?) Yes. Once we get the initial inter-op services running, one of the things I'd like to experiment with is a VOSpace service (facade) that stores its data in an Amazon S3 account. Dave From owner-vospace@eso.org Thu Aug 17 16:43:13 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HEg6CF005907 for ; Thu, 17 Aug 2006 16:42:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7HEU0s9002408 for vospace-outgoing; Thu, 17 Aug 2006 16:30:00 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HET1o2002139 for ; Thu, 17 Aug 2006 16:29:02 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7HESvLY026226 for ; Thu, 17 Aug 2006 16:28:58 +0200 (CEST) Received: from [10.115.23.140] ([80.187.215.31]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k7HESm3H014810 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Aug 2006 07:28:50 -0700 In-Reply-To: <44E46A11.4030807@ast.cam.ac.uk> References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <693C97A1-79AE-4698-9069-1C81BA6222BA@astro.ex.ac.uk> <44E46A11.4030807@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-32--723420450 Message-Id: <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> Cc: Roy Williams From: Roy Williams Subject: Re: Amazon VOStore? Date: Thu, 17 Aug 2006 07:28:42 -0700 To: vospace@ivoa.net X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.17.71443 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Roy Williams --Apple-Mail-32--723420450 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dave & VOSpacers: Perhaps I can ask my questions more specifically. (1) Why not take the Amazon definition and just use that exactly? (2) What can Amazon do that VOSpace cannot (and why is that feature there?) (3) What can VOSpace do that Amazon cannot (and which use-case needs that?) (4) How does the metadata model differ between Amazon and VOSpace? (5) What are the differences in security model? If the VO model is different, why is it different? (6) What does VOSpace do that Amazon cannot (and who is demanding that extra feature?) (7) Is there a problem in implementing Amazon on top of SRB? Roy On Aug 17, 2006, at 6:07 AM, Dave Morris wrote: > Alasdair Allan wrote: > >> Roy Williams wrote: >> >>> I wonder what is common and what is different between Amazon S3 >>> and VOSpace? >> >> I think VOStore and Amazon S3 are very similar, VOSpace is >> something that could sit on top of both (wasn't there some >> mumbling about using S3 as one of the backends for VOStore?) > > Yes. > Once we get the initial inter-op services running, one of the > things I'd like to experiment with is a VOSpace service (facade) > that stores its data in an Amazon S3 account. > > Dave > California Institute of Technology 626 395 3670 --Apple-Mail-32--723420450 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Dave & = VOSpacers:

Perhaps I can ask my = questions more specifically.=A0

(1) Why not take the Amazon = definition and just use that exactly?
(2) What can Amazon do = that VOSpace cannot (and why is that feature there?)
(3) What = can VOSpace do that Amazon cannot (and which use-case needs = that?)
(4) How does the metadata model differ between Amazon = and VOSpace?
(5) What are the differences in security model? = If the VO model is different, why is it different?
(6) What = does VOSpace do that Amazon cannot (and who is demanding that extra = feature?)
(7) Is there a problem in implementing Amazon on top = of SRB?

Roy


On Aug 17, 2006, = at 6:07 AM, Dave Morris wrote:

Alasdair Allan wrote:

Roy Williams wrote:

I wonder what is common and what is different = between Amazon S3 and=A0 = VOSpace?

I think VOStore and Amazon S3 = are very similar, VOSpace is something=A0 that could sit on top of both = (wasn't there some mumbling about using=A0 S3 as one of the backends for = VOStore?)

Yes.
Once we get the initial inter-op services running, = one of the things I'd like to experiment with is a VOSpace service = (facade) that stores its data in an Amazon S3 account.


=

California Institute of Technology

626 395 3670

=

= --Apple-Mail-32--723420450-- From owner-vospace@eso.org Thu Aug 17 17:14:39 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HFDs3R015147 for ; Thu, 17 Aug 2006 17:13:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7HFDs7o015146 for vospace-outgoing; Thu, 17 Aug 2006 17:13:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HFDeUC015090 for ; Thu, 17 Aug 2006 17:13:41 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7HFDbum012861 for ; Thu, 17 Aug 2006 17:13:37 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:48100) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1GDjYX-00024D-0c (Exim 4.54) (return-path ); Thu, 17 Aug 2006 16:13:13 +0100 Received: from cass30.ast.cam.ac.uk (cass30 [IPv6:2001:630:200:4240:a00:20ff:feac:45b]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id k7HFDB9U028371; Thu, 17 Aug 2006 16:13:11 +0100 (BST) Received: from cass30.ast.cam.ac.uk (localhost [127.0.0.1]) by cass30.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id k7HFDBil010467; Thu, 17 Aug 2006 16:13:11 +0100 (BST) Received: from localhost (gtr@localhost) by cass30.ast.cam.ac.uk (8.13.7+Sun/8.13.7/Submit) with ESMTP id k7HFDB7w010464; Thu, 17 Aug 2006 16:13:11 +0100 (BST) X-Authentication-Warning: cass30.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 17 Aug 2006 16:13:10 +0100 (BST) From: Guy Rixon X-X-Sender: gtr@cass30 To: Roy Williams cc: vospace@ivoa.net Subject: Re: Amazon VOStore? In-Reply-To: <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> Message-ID: References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <693C97A1-79AE-4698-9069-1C81BA6222BA@astro.ex.ac.uk> <44E46A11.4030807@ast.cam.ac.uk> <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.17.74942 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon On Thu, 17 Aug 2006, Roy Williams wrote: > Dave & VOSpacers: > > Perhaps I can ask my questions more specifically. > > (1) Why not take the Amazon definition and just use that exactly? > (2) What can Amazon do that VOSpace cannot (and why is that feature > there?) > (3) What can VOSpace do that Amazon cannot (and which use-case needs > that?) > (4) How does the metadata model differ between Amazon and VOSpace? > (5) What are the differences in security model? If the VO model is > different, why is it different? VOSpace is specified to use IVOA security mechanisms which means that it accepts RFC3820 certificates (i.e. Globus-style proxies). Almost nothing other than Grid software knows about RFC3820; I'd be suprised if S3 does. This affects both digital signature (SOAP) and TLS (HTTP-Get) mechanisms. > (6) What does VOSpace do that Amazon cannot (and who is demanding > that extra feature?) > (7) Is there a problem in implementing Amazon on top of SRB? > > Roy > > > On Aug 17, 2006, at 6:07 AM, Dave Morris wrote: > > > Alasdair Allan wrote: > > > >> Roy Williams wrote: > >> > >>> I wonder what is common and what is different between Amazon S3 > >>> and VOSpace? > >> > >> I think VOStore and Amazon S3 are very similar, VOSpace is > >> something that could sit on top of both (wasn't there some > >> mumbling about using S3 as one of the backends for VOStore?) > > > > Yes. > > Once we get the initial inter-op services running, one of the > > things I'd like to experiment with is a VOSpace service (facade) > > that stores its data in an Amazon S3 account. > > > > Dave > > > > California Institute of Technology > 626 395 3670 > > Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Thu Aug 17 17:39:34 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HFdHnr021599 for ; Thu, 17 Aug 2006 17:39:17 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7HFdHb9021598 for vospace-outgoing; Thu, 17 Aug 2006 17:39:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HFd1bg021546 for ; Thu, 17 Aug 2006 17:39:01 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7HFcwum015046 for ; Thu, 17 Aug 2006 17:38:59 +0200 (CEST) Received: from [172.16.1.35] (adsl-69-234-38-165.dsl.irvnca.pacbell.net [69.234.38.165]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k7HFcq3G018678; Thu, 17 Aug 2006 08:38:52 -0700 Message-ID: <44E48D8C.3070501@cacr.caltech.edu> Date: Thu, 17 Aug 2006 08:38:52 -0700 From: Matthew Graham User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Roy Williams CC: vospace@ivoa.net Subject: Re: Amazon VOStore? References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <693C97A1-79AE-4698-9069-1C81BA6222BA@astro.ex.ac.uk> <44E46A11.4030807@ast.cam.ac.uk> <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> In-Reply-To: <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.17.81442 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, We have been aware of the Amazon S3 for a while and have had a look at its interface but as their rubric states: Amazon S3 is intentionally built with a minimal feature set. It is designed to be a final solution whereas VOSpace is a layered functionality solution - it starts with VOSpace 1.0 and then progresses from there. > (1) Why not take the Amazon definition and just use that exactly? It does not answer all our use cases. > (2) What can Amazon do that VOSpace cannot (and why is that feature > there?) AS3 supports single-level directories (which it calls buckets): VOSpace 1.0 is a perfectly flat store but 1.x will support full directory structures. AS3 allows manipulation of Access Control Policy to data objects: VOSpace 1.0 is implementation dependent - your data objects might be world readable/writable or only only readable/writable. Future versions of VOSpace will use the Access Control mechanisms coming out of the IVOA security work. > (3) What can VOSpace do that Amazon cannot (and which use-case needs > that?) Move an object Copy an object Support third-party data transfers - the space pushes or pulls the data - this is the scalability use case where you do not want to bytes to come to your laptop first. Support arbitrary data transfer protocols In VOSpace, structured and unstructured data are both first-level entities and different views (data formats) can be taken of structured data (implementation dependent) since the space knows the data structure and how to manipulate this: for example, a VOTable could be imported and then exported as CSV. And then there is all the stuff that we are planning for the next versions of VOSpace, such as full directory hierarchy, searching , and space federation. > (4) How does the metadata model differ between Amazon and VOSpace? Both seem to support arbitrary metadata (key, value) for a data object but only VOSpace will list the metadata that is currently uses and system supported. > (5) What are the differences in security model? If the VO model is > different, why is it different? VOSpace uses SSO (WS-Security) for authentication but currently has no authorisation mechanism beyond what implementation dependent: Amazon uses credentials in the unsecure message to authenticate and has access control policies. VOSpace uses the agreed IVOA security model so that we have standardised security across all our services. > (6) What does VOSpace do that Amazon cannot (and who is demanding that > extra feature?) This is question (3) again. > (7) Is there a problem in implementing Amazon on top of SRB? Almost certainly. Cheers, Matthew From owner-vospace@eso.org Thu Aug 17 18:09:36 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HG9NHm029282 for ; Thu, 17 Aug 2006 18:09:23 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7HG9Ndl029280 for vospace-outgoing; Thu, 17 Aug 2006 18:09:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HG99Ob029242; Thu, 17 Aug 2006 18:09:09 +0200 (MEST) Received: from [192.168.2.101] (p5498D899.dip.t-dialin.net [84.152.216.153]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id k7HG98sD015836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 17 Aug 2006 18:09:08 +0200 In-Reply-To: <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <693C97A1-79AE-4698-9069-1C81BA6222BA@astro.ex.ac.uk> <44E46A11.4030807@ast.cam.ac.uk> <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: vospace@ivoa.net Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Amazon VOStore? - no its like a VOSpace... Date: Thu, 17 Aug 2006 18:09:05 +0200 To: Roy Williams X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 17.08.2006, at 16:28, Roy Williams wrote: > Dave & VOSpacers: > > Perhaps I can ask my questions more specifically. > > (1) Why not take the Amazon definition and just use that exactly? In general terms the VOSpace and S3 interface defintions are pretty similar (there are only so many functions you can add to a file storage system!)- however VOSpace 1. tries to be more general, but not tying down association with particular transport mechanisms, nor having a fixed set of node metadata. 2. has built-in some of the associations with other VO components and their associated semantics As Dave has pointed out the VOSpace interface is in a sense more general than the S3 interface and as such it should be possible to write a VOSpace proxy for S3 that would allow S3 to be used as the storage, and it might be reasonably efficient as the S3 REST interface could be used as a VOSpace transport protocol However, the real point is that S3 is really about the implementation rather than any particular niceties of the interface - being fast/ scalable/reliable are some of the most important features of the service - implementation and deployment are a key to wanting to use S3, and unfortunately we are unlikely to be able to use the Amazon implementation as they are charging for it. If we were to be storing all of our future data S3 then it might be worth adopting their proprietary interface, but in the VO we need a "vendor-neutral" interface to allow us to try to hide the differences between the inevitably varied systems from the end user astronomer. > (2) What can Amazon do that VOSpace cannot (and why is that feature > there?) it would appear that S3 has a subset of VOSpace 2.0 features. > (3) What can VOSpace do that Amazon cannot (and which use-case > needs that?) VOSpace 2 will have the concept of links to create connections between different VOSpaces - S3 does not appear to have that. An important use case for VOSpace is the ability to be able to run data processing applications locally to the storage, I do not think that S3 has had such a driver behind its design. > (4) How does the metadata model differ between Amazon and VOSpace? > (5) What are the differences in security model? If the VO model is > different, why is it different? As far as authentication is concerned we have had a long and hard debate and we have a mechanism that is compatible with the Globus and the wider grid world - S3 does not appear to be compatible with this out of the box > (6) What does VOSpace do that Amazon cannot (and who is demanding > that extra feature?) > (7) Is there a problem in implementing Amazon on top of SRB? not an expert on SRB, but I suspect that the S3 interface *could* be implemented as a facade, but see the comments on 1) - essentially I think that our interface design should be driven by the ability to use it as an efficient facade on existing systems such as SRB and NGAS because the majority of the value is in the underlying implementation rather than the interface - the VOSpace specification/ interface is driven by that aim. I think that we have a better architectural view than in the two layer VOSpace/VOStore days, which did not fit well with these other systems which all present a view of the storage that is symmetrical between servers. Ultimately I think that we remain more flexible with our own more general interface definition, however, if useful clients of S3 are built then there would probably be some merit in S3 interfaces being added to SRB and NGAS as well as VOSpace ones. Paul Harrison ESO > From owner-vospace@eso.org Fri Aug 18 00:36:24 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 10000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HMaABN017724 for ; Fri, 18 Aug 2006 00:36:10 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7HMaA6j017723 for vospace-outgoing; Fri, 18 Aug 2006 00:36:10 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7HMa4rw017711 for ; Fri, 18 Aug 2006 00:36:05 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7HMa0LY000957 for ; Fri, 18 Aug 2006 00:36:01 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/72) id k7HMZqO10931; Thu, 17 Aug 2006 15:35:52 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <693C97A1-79AE-4698-9069-1C81BA6222BA@astro.ex.ac.uk> <44E46A11.4030807@ast.cam.ac.uk> <46F99A1B-D808-45B1-B157-8453AFDC73B3@cacr.caltech.edu> Date: Thu, 17 Aug 2006 15:35:39 -0700 To: Roy Williams From: Reagan Moore Subject: Re: Amazon VOStore? Cc: vospace@ivoa.net Content-Type: multipart/mixed; boundary="============_-1056268349==_============" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.17.151942 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Reagan Moore --============_-1056268349==_============ Content-Type: multipart/alternative; boundary="============_-1056268349==_ma============" --============_-1056268349==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Roy: There is a strong correspondence between the VOSpace v1 design and the Storage Resource Manager design. SDSC is collaborating with groups in the high-energy physics community to port SRM as an interface on a SRB data grid. This will support simple access to data. SDSC will also collaborate on a port of VOSpace as an interface to a SRB collection. Since the Amazon S3 interface is proprietary, I do not expect it will be ported on top of the SRB. VOSpace, SRM, and Amazon S3 provide minimal access mechanisms to data that are being stored in other remote systems. A very interesting research issue is the number of additional capabilities that will be added in VOSpace v2 to improve the ability to manage the shared data. The corresponding set of management operations in the SRB environment now consists of over 80 different remote actions. I have attached a report that describes many of the operational challenges in managing distributed data collections. Reagan >Dave & VOSpacers: > >Perhaps I can ask my questions more specifically. > >(1) Why not take the Amazon definition and just use that exactly? >(2) What can Amazon do that VOSpace cannot (and why is that feature there?) >(3) What can VOSpace do that Amazon cannot (and which use-case needs that?) >(4) How does the metadata model differ between Amazon and VOSpace? >(5) What are the differences in security model? If the VO model is >different, why is it different? >(6) What does VOSpace do that Amazon cannot (and who is demanding >that extra feature?) >(7) Is there a problem in implementing Amazon on top of SRB? > >Roy > > >On Aug 17, 2006, at 6:07 AM, Dave Morris wrote: > >>Alasdair Allan wrote: >> >>>Roy Williams wrote: >>> >>>>I wonder what is common and what is different between Amazon S3 >>>>and VOSpace? >>>> >>> >>>I think VOStore and Amazon S3 are very similar, VOSpace is >>>something that could sit on top of both (wasn't there some >>>mumbling about using S3 as one of the backends for VOStore?) >>> >> >>Yes. >>Once we get the initial inter-op services running, one of the >>things I'd like to experiment with is a VOSpace service (facade) >>that stores its data in an Amazon S3 account. >> >>Dave >> > >California Institute of Technology > >626 395 3670 --============_-1056268349==_ma============ Content-Type: text/html; charset="us-ascii" Re: Amazon VOStore?
Roy:
There is a strong correspondence between the VOSpace v1 design and the Storage Resource Manager design.  SDSC is collaborating with groups in the high-energy physics community to port SRM as an interface on a SRB data grid.  This will support simple access to data.  SDSC will also collaborate on a port of VOSpace as an interface to a SRB collection.

Since the Amazon S3 interface is proprietary, I do not expect it will be ported on top of the SRB.

VOSpace, SRM, and Amazon S3 provide minimal access mechanisms to data that are being stored in other remote systems.  A very interesting research issue is the number of additional capabilities that will be added in VOSpace v2 to improve the ability to manage the shared data.  The corresponding set of management operations in the SRB environment now consists of over 80 different remote actions.

I have attached a report that describes many of the operational challenges in managing distributed data collections.

Reagan



Dave & VOSpacers:

Perhaps I can ask my questions more specifically.

(1) Why not take the Amazon definition and just use that exactly?
(2) What can Amazon do that VOSpace cannot (and why is that feature there?)
(3) What can VOSpace do that Amazon cannot (and which use-case needs that?)
(4) How does the metadata model differ between Amazon and VOSpace?
(5) What are the differences in security model? If the VO model is different, why is it different?
(6) What does VOSpace do that Amazon cannot (and who is demanding that extra feature?)
(7) Is there a problem in implementing Amazon on top of SRB?

Roy


On Aug 17, 2006, at 6:07 AM, Dave Morris wrote:

Alasdair Allan wrote:

Roy Williams wrote:

I wonder what is common and what is different between Amazon S3 and  VOSpace?

I think VOStore and Amazon S3 are very similar, VOSpace is something  that could sit on top of both (wasn't there some mumbling about using  S3 as one of the backends for VOStore?)

Yes.
Once we get the initial inter-op services running, one of the things I'd like to experiment with is a VOSpace service (facade) that stores its data in an Amazon S3 account.

Dave


California Institute of Technology
626 395 3670

--============_-1056268349==_ma============-- --============_-1056268349==_============ Content-Id: Content-Type: application/msword; name="escience-prod-long.doc" ; x-mac-type="5738424E" ; x-mac-creator="4D535744" Content-Disposition: attachment; filename="escience-prod-long.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAA+gAA AAAAAAAAEAAA/AAAAAEAAAD+////AAAAAPgAAAD5AAAAAAEAAP////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// ///spcEAj0AJBAAA+BK/AAAAAAABEQABAAEABgAAKegAAA4AamJqYnCvcK8AAAAAAAAA AAAAAAAAAAAAAAAJBBYAjWgBABrNAAAazQAAJ+IAAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAA AGwAAAAAAOoGAAAAAAAA6gYAAOoGAAAEAAAA7gYAAAgAAADuBwAAAAAAAO4HAAAAAAAA 7gcAAEQAAAAAAAAAAAAAAMoJAAAAAAAAygkAAAAAAADKCQAAAAAAAMoJAAAAAAAAygkA ABQAAADeCQAAhAEAAMoJAAAAAAAA1XIAAKIBAADOCwAATAAAABoMAAAAAAAAGgwAAAAA AAAaDAAAAAAAABoMAAAAAAAA+QwAAC4AAAAnDQAAFAAAADsNAAAMAAAAknIAAAIAAACU cgAAAAAAAJRyAAAAAAAAlHIAAAAAAACUcgAAAAAAAJRyAAAAAAAAlHIAACwAAAB3dAAA IAIAAJd2AACMAAAAwHIAABUAAAAAAAAAAAAAAAAAAAAAAAAA7gcAAAAAAABHDQAAAAAA AAAAAAAAAAAAAAAAAAAAAAD1DAAABAAAAPkMAAAAAAAARw0AAAAAAABHDQAAAAAAAMBy AAAAAAAAFxgAAAAAAADuBwAAAAAAAO4HAAAAAAAAGgwAAAAAAAAAAAAAAAAAABoMAADb AAAAzgsAAAAAAAAXGAAAAAAAABcYAAAAAAAAFxgAAAAAAABHDQAAJAcAAO4HAAAAAAAA GgwAAAAAAADuBwAAAAAAABoMAAAAAAAAknIAAAAAAAAAAAAAAAAAABcYAAAAAAAAMggA AHwAAACuCAAAHAEAAPYGAAB8AAAAcgcAAHwAAADuBwAAAAAAAO4HAAAAAAAARw0AAAAA AACScgAAAAAAABcYAABQCAAAFxgAAAAAAABnIAAALgMAAHZlAABIAgAA7gcAAAAAAADu BwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAALmwAAAAAAAAAAAAAAAAAAGILAABsAAAAoHgJwQAAAADKCQAAAAAA AMoJAAAAAAAAaxQAAKwDAAC+ZwAAQAAAAAAAAAAAAAAALmwAAGQGAADVcgAAAAAAANVy AAAAAAAA/mcAADAEAAAjdwAAAAAAABcYAAAAAAAAI3cAAAAAAAAubAAAAAAAABcYAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BADDAA8A5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABQcm9kdWN0aW9uIFN0b3JhZ2UgUmVzb3VyY2UgQnJva2VyIERhdGEgR3Jp ZHMNDQ1SZWFnYW4gVy4gTW9vcmUsIFNoZWF1LVllbiBDaGVuLCBXYXluZSBTY2hyb2Vk ZXIsIEFyY290IFJhamFzZWthciwgTWljaGFlbCBXYW4NU2FuIERpZWdvIFN1cGVyY29t cHV0ZXIgQ2VudGVyDXttb29yZSxzaGVhdWMsc2Nocm9lZGUsc2VrYXIsbXdhbn1Ac2Rz Yy5lZHUNDQ0MQWJzdHJhY3QNDUludGVybmF0aW9uYWwgZGF0YSBncmlkcyBhcmUgbm93 IGJlaW5nIGJ1aWx0IHRoYXQgc3VwcG9ydCBqb2ludCBtYW5hZ2VtZW50IG9mIHNoYXJl ZCBjb2xsZWN0aW9ucy4gQW4gZW1lcmdpbmcgc3RyYXRlZ3kgaXMgdG8gYnVpbGQgbXVs dGlwbGUgaW5kZXBlbmRlbnQgZGF0YSBncmlkcywgZWFjaCBtYW5hZ2VkIGJ5IHRoZSBs b2NhbCBpbnN0aXR1dGlvbi4gIFRoZSBkYXRhIGdyaWRzIGFyZSB0aGVuIGZlZGVyYXRl ZCB0byBlbmFibGUgY29udHJvbGxlZCBzaGFyaW5nIG9mIGZpbGVzLiBXZSBleGFtaW5l IHRoZSBtYW5hZ2VtZW50IGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggbWFpbnRhaW5pbmcg ZmVkZXJhdGlvbnMgb2YgcHJvZHVjdGlvbiBkYXRhIGdyaWRzLCBpbmNsdWRpbmcgbWFu YWdlbWVudCBvZiBhY2Nlc3MgY29udHJvbHMsIGNvb3JkaW5hdGVkIHNoYXJpbmcgb2Yg bmFtZSBzcGFjZXMsIHJlcGxpY2F0aW9uIG9mIGRhdGEgYmV0d2VlbiBkYXRhIGdyaWRz LCBhbmQgZXhwYW5zaW9uIG9mIHRoZSBkYXRhIGdyaWQgZmVkZXJhdGlvbi4NDTEuIElu dHJvZHVjdGlvbg0NRGF0YSBncmlkcyBhcmUgdXNlZCB0byBidWlsZCBzaGFyZWQgY29s bGVjdGlvbnMgb3V0IG9mIGZpbGVzIHRoYXQgYXJlIGxvY2F0ZWQgYXQgbXVsdGlwbGUg c2l0ZXMgYWNyb3NzIG11bHRpcGxlIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMgWzEsMl0u ICBBIHNoYXJlZCBjb2xsZWN0aW9uIHByb3ZpZGVzIHBlcnNpc3RlbnQgZ2xvYmFsIG5h bWUgc3BhY2VzIGZvciB0aGUgbmFtZXMgb2YgdGhlIGZpbGVzLCB0aGUgY3VyYXRvcnMg b2YgdGhlIHNoYXJlZCBjb2xsZWN0aW9uLCB0aGUgc3RvcmFnZSByZXNvdXJjZXMsIGFu ZCBldmVuIHRoZSBtZXRhZGF0YSBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCBlYWNo IGZpbGUgWzNdLiAgVGhlIHJlc3VsdCBpcyBhbiBlbnZpcm9ubWVudCBpbiB3aGljaCB0 aGUgZmlsZXMgbWF5IGJlIG1vdmVkIGZyb20gc2l0ZSB0byBzaXRlIHdpdGhvdXQgaGF2 aW5nIHRvIHdvcnJ5IGFib3V0IHRoZSBmaWxlIG5hbWUgY2hhbmdpbmcuICBBY2Nlc3Mg Y29udHJvbHMgdGhhdCBhcmUgc2V0IG9uIHRoZSBmaWxlcyBhbmQgdXNlci1kZWZpbmVk IG1ldGFkYXRhIHJlbWFpbiB1bmNoYW5nZWQgYXMgd2VsbC4gIEl0IGlzIHBvc3NpYmxl IHRvIGNvbnN0cnVjdCBhbiBlbnZpcm9ubWVudCBpbiB3aGljaCBhbGwgdGhlIHByb3Bl cnRpZXMgb2YgdGhlIHNoYXJlZCBjb2xsZWN0aW9uIGFyZSBtYW5hZ2VkIGluZGVwZW5k ZW50bHkgb2YgdGhlIGNob2ljZSBvZiBzdG9yYWdlIHN5c3RlbSBvciBkYXRhYmFzZS4g IFRoaXMgY2FwYWJpbGl0eSBpcyBjYWxsZWQgaW5mcmFzdHJ1Y3R1cmUgaW5kZXBlbmRl bmNlLCBhbmQgaXMgdGhlIGVzc2VudGlhbCBkZXNpZ24gZmVhdHVyZSBuZWVkZWQgdG8g bWFuYWdlIHRlY2hub2xvZ3kgZXZvbHV0aW9uIFs0XS4gIERhdGEgZ3JpZHMgdXNlIGlu ZnJhc3RydWN0dXJlIGluZGVwZW5kZW5jZSB0byBlbnN1cmUgdGhhdCBkYXRhIGNhbiBi ZSB1bmlmb3JtbHkgbWFuYWdlZCB3aXRoIHN0cm9uZyBhY2Nlc3MgY29udHJvbHMsIGV2 ZW4gd2hlbiB0aGUgZmlsZXMgYXJlIGRpc3RyaWJ1dGVkIGFjcm9zcyBtdWx0aXBsZSB0 eXBlcyBvZiBzdG9yYWdlIHN5c3RlbXMuDVByb2R1Y3Rpb24gZGF0YSBncmlkcyBoYXZl IGJvdGggdGhlIGNoYWxsZW5nZSBhbmQgdGhlIGJlbmVmaXQgdGhhdCB0aGV5IGFyZSB0 aGUgb25seSBpbnRlcmZhY2Ugc2VlbiBieSB0aGUgZW5kIHVzZXIuICBBIGNvbGxhYm9y YXRvciBvbiBhIHNoYXJlZCBjb2xsZWN0aW9uIGRvZXMgbm90IGhhdmUgdG8gd29ycnkg YWJvdXQgdGhlIGRpZmZlcmVudCBwcm90b2NvbHMgdXNlZCBieSB0aGUgbXVsdGlwbGUg c3RvcmFnZSBkZXZpY2VzLCBvciBkaWZmZXJlbmNlcyBpbiBhZG1pbmlzdHJhdGl2ZSBw b2xpY2llcyBhYm91dCBkYXRhIHJlc2lkZW5jeSBsaWZldGltZSwgb3IgbG9jYWwgc2l0 ZSBhdXRoZW50aWNhdGlvbi4gIE9uIHRoZSBvdGhlciBoYW5kLCBhbnkgcHJvYmxlbSB0 aGF0IG9jY3VycyBpbiB0aGUgZW52aXJvbm1lbnQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5 IG9mIHRoZSBkYXRhIGdyaWQsIHdoZXRoZXIgaXQgaXMgYSBuZXR3b3JrIG91dGFnZSwg b3IgYSBkaXNrIGNyYXNoLCBvciBhIGNvcnJ1cHRlZCB0YXBlLiAgQSBwcm9kdWN0aW9u IGRhdGEgZ3JpZCBoYXMgdG8gcHJvdGVjdCBpdHNlbGYgZnJvbSBhbGwgcG9zc2libGUg c291cmNlcyBvZiBkYXRhIGxvc3MgYW5kIHByb3ZpZGUgdG8gdGhlIHVzZXJzIGFuIGVu dmlyb25tZW50IGluIHdoaWNoIHRoZSBkYXRhIGhhdmUgc3Ryb25nIGd1YXJhbnRlZXMg b24gaW50ZWdyaXR5IGFuZCBhdXRoZW50aWNpdHkgWzVdLiANSW4gcHJhY3RpY2UsIG5v IHN0b3JhZ2Ugc3lzdGVtIGNhbiBiZSB0cnVzdGVkIHRvIHJlbGlhYmx5IHN0b3JlIGRh dGEgZm9yIHRoZSBsaWZldGltZSBvZiBhIGNvbGxlY3Rpb24sIHdoaWNoIG1heSBiZSBs b25nZXIgdGhhbiAyMCB5ZWFycy4gIEF0IGEgbWluaW11bSwgdGhlIHRlY2hub2xvZ3kg dXNlZCB3aXRoaW4gdGhlIHN0b3JhZ2Ugc3lzdGVtIHdpbGwgYmVjb21lIG9ic29sZXRl LCBhbmQgdGhlIGRhdGEgd2lsbCBuZWVkIHRvIGJlIG1pZ3JhdGVkIHRvIG1vcmUgY29z dCBlZmZlY3RpdmUgdGVjaG5vbG9neS4gIEF0IHRoZSB3b3JzdCwgdGhlIHN0b3JhZ2Ug c3lzdGVtIHdpbGwgbG9zZSB0aGUgZGF0YSBvciBjb3JydXB0IHRoZSBkYXRhLiAgVHlw ZXMgb2YgZXZlbnRzIHRoYXQgbGVhZCB0byBkYXRhIGxvc3MgaW5jbHVkZSBtZWRpYSBm YWlsdXJlLCBzeXN0ZW1pYyB2ZW5kb3IgcHJvZHVjdCBmYWlsdXJlIChzdWNoIGFzIGJh ZCBtaWNyb2NvZGUgaW4gYSB0YXBlIGRyaXZlKSwgb3BlcmF0aW9uYWwgZXJyb3IsIG5h dHVyYWwgZGlzYXN0ZXIsIGFuZCBtYWxpY2lvdXMgdXNlcnMuDVByb2R1Y3Rpb24gZGF0 YSBncmlkcyBwcm92aWRlIG1lY2hhbmlzbXMgdG8gZW5zdXJlIGRhdGEgaW50ZWdyaXR5 LCBvcGVyYXRpb25hbCBwcm9jZWR1cmVzIHRvIGVuc3VyZSByZWxpYWJsZSBtYW5hZ2Vt ZW50IG9mIHRoZSBjb2xsZWN0aW9uLCBhbmQgY29uc2lzdGVuY3kgbWVjaGFuaXNtcyB0 byBlbnN1cmUgdGhhdCB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBkYXRhIGluIHRoZSBj b2xsZWN0aW9uIHJlbWFpbnMgdW5jb21wcm9taXNlZC4gIEluIHRoaXMgcGFwZXIgd2Ug ZXhhbWluZSB0aGUgdHlwZXMgb2Ygb3BlcmF0aW9uYWwgc3VwcG9ydCBuZWVkZWQgdG8g bWFpbnRhaW4gYSBkYXRhIGdyaWQgYmFzZWQgb24gdGhlIFN0b3JhZ2UgUmVzb3VyY2Ug QnJva2VyIHRlY2hub2xvZ3kgWzZdLiAgV2UgYWxzbyBleGFtaW5lIHRoZSBlbWVyZ2Vu Y2Ugb2YgZmVkZXJhdGlvbnMgb2YgZGF0YSBncmlkcyBhcyB0aGUgcHJlZmVycmVkIG1l Y2hhbmlzbSBmb3Igc2hhcmluZyBkYXRhLCBhbmQgdGhlIGltcGxpY2F0aW9ucyB0aGF0 IHRoZSBtYW5hZ2VtZW50IG9mIGZlZGVyYXRpb25zIGhhcyBvbiBzaXRlLXNwZWNpZmlj IHByb2R1Y3Rpb24gb3BlcmF0aW9uYWwgcHJvY2VkdXJlcy4NDTIuIERhdGEgR3JpZCBN YW5hZ2VtZW50DQ1CZWZvcmUgYSBkYXRhIGdyaWQgZmVkZXJhdGlvbiBjYW4gYmUgZWZm ZWN0aXZlbHkgaW50ZWdyYXRlZCwgZWFjaCBvZiB0aGUgY29tcG9uZW50IGRhdGEgZ3Jp ZHMgbXVzdCBiZSByZWxpYWJseSBtYW5hZ2VkLiAgQSBkYXRhIGdyaWQgYWRtaW5pc3Ry YXRvciBwZXJmb3JtcyBvcGVyYXRpb25hbCB0YXNrcyB0byBlbnN1cmUgdGhlIHNtb290 aCBvcGVyYXRpb24gb2YgdGhlIGRhdGEgZ3JpZCwgdXN1YWxseSBhc3Npc3RlZCBieSBz eXN0ZW1zIGFuYWx5c3RzIHdobyBtYWludGFpbiB0aGUgc3RvcmFnZSBzeXN0ZW1zLCBu ZXR3b3JrIGFkbWluaXN0cmF0b3JzIHdobyBtYW5hZ2UgYm90aCBzZWN1cml0eSBzeXN0 ZW1zIGFuZCBuZXR3b3JrcywgYW5kIGRhdGFiYXNlIGFkbWluaXN0cmF0b3JzIHdobyBt YWludGFpbiBkYXRhYmFzZXMgaW4gd2hpY2ggdGhlIGRhdGEgZ3JpZCBtZXRhZGF0YSBj YXRhbG9nIGlzIGhvdXNlZC4NVGhlIG11bHRpcGxlIGxldmVscyBvZiBoYXJkd2FyZSBh bmQgc29mdHdhcmUgc3lzdGVtcyB0aGF0IG11c3Qgd29yayB0b2dldGhlciBzZWFtbGVz c2x5IGFyZToNRGF0YSBncmlkIGZlZGVyYXRpb24gc29mdHdhcmUNQXBwbGljYXRpb24g bGV2ZWwgY2xpZW50IHNvZnR3YXJlDURhdGEgZ3JpZCBzZXJ2ZXJzDURhdGEgZ3JpZCBt ZXRhZGF0YSBjYXRhbG9nDVNlY3VyaXR5IGVudmlyb25tZW50DVN0b3JhZ2Ugc3lzdGVt cw1EYXRhYmFzZQ1OZXR3b3JrDUEgZmFpbHVyZSBpbiBhbnkgb25lIG9mIHRoZXNlIHN5 c3RlbXMgaXMgdmlld2VkIGFzIGEgZmFpbHVyZSBvZiB0aGUgZGF0YSBncmlkLiAgQSBk YXRhIGdyaWQgbXVzdCBlbnN1cmUgdGhlIGVuZC10by1lbmQgcmVsaWFiaWxpdHkgYW5k IGF2YWlsYWJpbGl0eSBvZiB0aGUgaW50ZWdyYXRlZCBzeXN0ZW0gYWNyb3NzIGFsbCB0 eXBlcyBvZiBmYWlsdXJlcy4gIEdpdmVuIHRoZSBtdWx0aXBsZSBsZXZlbHMgb2YgaGFy ZHdhcmUgYW5kIHNvZnR3YXJlIHN5c3RlbXMgdGhhdCBhcmUgaW50ZWdyYXRlZCBieSBh IGRhdGEgZ3JpZCwgaXQgYXBwZWFycyB0aGF0IG1hbmFnZW1lbnQgb2YgaW50ZWdyaXR5 IGFuZCBhdXRoZW50aWNpdHkgb2YgZGlzdHJpYnV0ZWQgY29sbGVjdGlvbnMgaXMgdmVy eSBkaWZmaWN1bHQuICBEYXRhIGdyaWRzIG92ZXJjb21lIHRoZXNlIGFwcGFyZW50IGRp ZmZpY3VsdGllcyB0aHJvdWdoIHRoZSB1c2Ugb2YgY2hlY2tzdW1zLCByZXBsaWNhdGlv biwgc3luY2hyb25pemF0aW9uLCBhbmQgZmVkZXJhdGlvbiBbN10uICBUaGUgaW50ZW50 IGlzIHRvIHByb3ZpZGUgbXVsdGlwbGUgY29waWVzIG9mIGVhY2ggZmlsZSwgYXNzZXJ0 IHRoYXQgdGhlIGNvcGllcyBhcmUgdXAgdG8gZGF0ZSwgdGhhdCB0aGUgY29waWVzIGFy ZSB1bmNvcnJ1cHRlZCwgYW5kIHRoYXQgYSBjb3B5IHJlc2lkZXMgaW4gYW4gaW5kZXBl bmRlbnRseSBhZG1pbmlzdGVyZWQgZG9tYWluIG9uIGEgZGlmZmVyZW50IHR5cGUgb2Yg c3RvcmFnZSBzeXN0ZW0uICBBdCB0aGUgc2FtZSB0aW1lLCBzdGF0ZSBpbmZvcm1hdGlv biBtdXN0IGJlIHJlcGxpY2F0ZWQgYWNyb3NzIGluZGVwZW5kZW50IGRhdGFiYXNlcyB0 byBlbnN1cmUgbm8gc2luZ2xlIHBvaW50IG9mIGZhaWx1cmUuDUEgbGlzdCBvZiB0aGUg b3BlcmF0aW9ucyBzdXBwb3J0ZWQgYnkgZGF0YSBncmlkcyB0byBtYWludGFpbiBoaWdo IGF2YWlsYWJpbGl0eSB3aGlsZSBtaXRpZ2F0aW5nIHJpc2sgb2YgZGF0YSBsb3NzIGlz IGF2YWlsYWJsZSBhdCB0aGUgU3RvcmFnZSBSZXNvdXJjZSBCcm9rZXIgd2lraTogEyBI WVBFUkxJTksgImh0dHA6Ly93d3cuc2RzYy5lZHUvc3JiLyIgARRodHRwOi8vd3d3LnNk c2MuZWR1L3NyYi8VLiAgVGhlIG9wZXJhdGlvbnMgaW5jbHVkZToNTWFuYWdlbWVudCBv ZiBlbmQtdG8tZW5kIHZhbGlkYXRpb24gb2YgY2hlY2tzdW1zLiAgQSBjaGVja3N1bSBp cyBjcmVhdGVkIGJlZm9yZSBhIGZpbGUgaXMgcmVnaXN0ZXJlZCBpbnRvIGEgU1JCIGNv bGxlY3Rpb24sIGFuZCB0aGUgY2hlY2tzdW0gaXMgdmFsaWRhdGVkIGFmdGVyIHN0b3Jh Z2Ugb2YgdGhlIGZpbGUuICBSZWxhdGVkIG9wZXJhdGlvbnMgaW5jbHVkZSBjcmVhdGlv biBvZiBjaGVja3N1bXMgZm9yIHByZXZpb3VzbHkgcmVnaXN0ZXJlZCBkYXRhLg1NYW5h Z2VtZW50IG9mIHJlcGxpY2FzLCB2ZXJzaW9ucywgYW5kIGJhY2t1cHMgb2YgZmlsZXMu ICBBIHJlcGxpY2EgaXMgYSB0cnVlIGNvcHkgb2YgYSBmaWxlLiAgQ2hhbmdlcyB0byBv bmUgb2YgdGhlIHJlcGxpY2FzIG9mIGEgZmlsZSBjYW4gYmUgc3luY2hyb25pemVkIHRv IHRoZSBvdGhlciByZXBsaWNhcy4gQSB2ZXJzaW9uIGlzIGEgbnVtYmVyZWQgY29weSBv ZiBhIGZpbGUsIHN1Y2ggYXMgYSB1bmlxdWUgcmVwcmVzZW50YXRpb24uICBBIGJhY2t1 cCBpcyBhIHRpbWUtc3RhbXBlZCBjb3B5LiAgQSByZXF1ZXN0IHRvIG1ha2UgYSByZXBs aWNhIGFsd2F5cyBjcmVhdGVzIGFub3RoZXIgY29weSBvZiB0aGUgZmlsZS4gIEEgcmVx dWVzdCB0byBtYWtlIGEgYmFja3VwIHJlcGxhY2VzIHRoZSBwcmV2aW91cyBiYWNrdXAg b2YgdGhlIGZpbGUuDU1hbmFnZW1lbnQgb2Ygc3luY2hyb25pemF0aW9uLiAgVGhpcyBp c3N1ZSBpcyBtb3JlIGRpZmZpY3VsdCB0aGFuIGl0IGFwcGVhcnMsIGJlY2F1c2Ugc3lu Y2hyb25pemF0aW9uIGNvdWxkIGJlIGRvbmUgYmV0d2VlbiB0aGUgY29sbGVjdGlvbiBh bmQgZXh0ZXJuYWwgKG5vbi1TUkIgbWFuYWdlZCkgc3RvcmFnZSBzeXN0ZW1zLCBiZXR3 ZWVuIGZpbGUgc3lzdGVtIGJ1ZmZlcnMgYW5kIGRpc2ssIGJldHdlZW4gZGlzayBjYWNo ZXMgYW5kIHRhcGUgYXJjaGl2ZXMsIGJldHdlZW4gdHdvIFNSQi1tYW5hZ2VkIGNvbGxl Y3Rpb25zLCBhbmQgYmV0d2VlbiB0d28gU1JCIGRhdGEgZ3JpZCBmZWRlcmF0aW9ucy4g IFRoZSBTUkIgY2FuIHJlZ2lzdGVyIGFuIGV4dGVybmFsIGZpbGUgc3lzdGVtIGRpcmVj dG9yeSBzdHJ1Y3R1cmUgaW50byBhIFNSQiBjb2xsZWN0aW9uLiAgVGhlIHJlZ2lzdGVy ZWQgZmlsZXMgY2FuIHRoZW4gYmUgc3luY2hyb25pemVkIHdpdGggb3RoZXIgU1JCIGNv bGxlY3Rpb25zLiANVGhlIGFiaWxpdHkgdG8gc3luY2hyb25pemUgZmlsZSBzeXN0ZW0g YnVmZmVycyBpcyBlc3NlbnRpYWwgd2hlbiBkZWFsaW5nIHdpdGggc21hbGwgZmlsZXMu ICBJdCBpcyBwb3NzaWJsZSBmb3IgYSBzdG9yYWdlIHN5c3RlbSB0byByZXBvcnQgY29t cGxldGlvbiBhZnRlciB0aGUgZmlsZXMgYXJlIHdyaXR0ZW4gdG8gdGhlIGZpbGUgc3lz dGVtIGJ1ZmZlciBhbmQgYmVmb3JlIHRoZSBmaWxlcyBhcmUgd3JpdHRlbiB0byBkaXNr LiAgQSBzdG9yYWdlIHN5c3RlbSBjcmFzaCB3aWxsIHRoZW4gbG9zZSB0aGUgZmlsZXMs IGV2ZW4gdGhvdWdoIHRoZSBkYXRhIGdyaWQgYmVsaWV2ZXMgdGhlIGRhdGEgYXJlIHNh ZmVseSBzdG9yZWQuICBBIHNpbWlsYXIgcHJvYmxlbSBvY2N1cnMgd2l0aCBzdG9yYWdl IHN5c3RlbXMgdGhhdCB3cml0ZSBkYXRhIHRvIGEgZGlzayBjYWNoZSBiZWZvcmUgYXJj aGl2aW5nIGRhdGEgb24gdGFwZS4gIFRoZSBkYXRhIGdyaWQgbmVlZHMgdG8gcHJvdGVj dCBpdHMgaW50ZWdyaXR5IGJ5IGZvcmNpbmcgc3luY2hyb25pemF0aW9uIG9mIHRoZSBk YXRhIGFsbCB0aGUgd2F5IHRvIHRoZSBlbmQgc3RvcmFnZSBtZWRpYS4NVGhlIGFiaWxp dHkgdG8gc3luY2hyb25pemUgcmVwbGljYXMgaXMgZXNzZW50aWFsIGZvciBtYW5hZ2lu ZyBkYXRhIGRpc3RyaWJ1dGVkIG92ZXIgd2lkZS1hcmVhLW5ldHdvcmtzLiBJZiBhbiBh dHRlbXB0IHRvIGNyZWF0ZSBhIHJlbW90ZSBmaWxlIGZhaWxzIGJlY2F1c2Ugb2YgYSBu ZXR3b3JrIHByb2JsZW0gb3Igc3RvcmFnZSBzeXN0ZW0gb3V0YWdlLCB0aGUgZGF0YSBn cmlkIGNhbiBkZWZlciBjcmVhdGlvbiBvZiB0aGUgcmVwbGljYSB1bnRpbCB0aGUgc3lz dGVtIGlzIGF2YWlsYWJsZS4gIEFsc28sIGNoYW5nZXMgdG8gYSBmaWxlIGNhbiBiZSBt YWRlIG9uIGEgc2luZ2xlIHJlcGxpY2EsIGFuZCB0aGVuIHByb3BhZ2F0ZWQgdG8gdGhl IG90aGVyIHJlcGxpY2FzIGFmdGVyIHRoZSB1cGRhdGVzIGFyZSBjb21wbGV0ZS4gDUNv bnNpc3RlbmN5IGNoZWNrcyBvbiB0aGUgaW50ZWdyaXR5IG9mIHRoZSBtZXRhZGF0YSBj YXRhbG9nLiAgVGhpcyByZXF1aXJlcyB0d28gY2hlY2tzOiAgdGhhdCBmaWxlcyBleGlz dCBmb3IgZWFjaCBvZiB0aGUgZW50cmllcyBpbiB0aGUgbWV0YWRhdGEgY2F0YWxvZzsg YW5kIHRoYXQgZm9yIGVhY2ggZmlsZSBpbiBhIFNSQiB2YXVsdCBhIG1ldGFkYXRhIHJl Y29yZCBleGlzdHMgaW4gdGhlIG1ldGFkYXRhIGNhdGFsb2cuDU1hbmFnZW1lbnQgb2Yg c2xhdmUgY2F0YWxvZ3MuICBBIHN0YW5kYXJkIGFwcHJvYWNoIGlzIHRvIGNyZWF0ZSBh ZGRpdGlvbmFsIHJlYWQtb25seSBtZXRhZGF0YSBjYXRhbG9ncyB0byBlbnN1cmUgaGln aCBhdmFpbGFiaWxpdHkgb3IgdG8gZW5zdXJlIGltcHJvdmVkIHJlc3BvbnNlIGF0IGEg cmVtb3RlIHNpdGUuICBBbGwgd3JpdGVzIGFyZSBkb25lIHRvIHRoZSBtYXN0ZXIgY2F0 YWxvZyB0byBlbnN1cmUgY29uc2lzdGVuY3kuICBTeW5jaHJvbml6YXRpb24gb2YgdGhl IHNsYXZlIGNhdGFsb2cgaXMgZG9uZSBhdCBzZWxlY3RlZCBpbnRlcnZhbHMgdG8gZG93 bmxvYWQgY2hhbmdlZCBtZXRhZGF0YS4NTWFuYWdlbWVudCBvZiBmZWRlcmF0aW9ucy4g IFRoZSByZXBsaWNhdGlvbiBvZiBhbiBlbnRpcmUgY29sbGVjdGlvbiAoaW5jbHVkaW5n IG5hbWUgc3BhY2VzLCBkYXRhIGFuZCBtZXRhZGF0YSkgY2FuIGJlIGRvbmUgb250byBh IHNlcGFyYXRlbHkgYWRtaW5pc3RlcmVkIGRhdGEgZ3JpZC4gIFRoaXMgY2FwYWJpbGl0 eSBlbnN1cmVzIHRoYXQgYW4gaW5kZXBlbmRlbnQgZW52aXJvbm1lbnQgd2l0aCBzZXBh cmF0ZSBvcGVyYXRpb25hbCBwcm9jZWR1cmVzIGlzIG1hbmFnaW5nIGEgY29weSBvZiB0 aGUgY29sbGVjdGlvbi4gIEFuIG9wZXJhdGlvbmFsIHByb2NlZHVyYWwgZXJyb3Igb24g b25lIGRhdGEgZ3JpZCBjYW4gYmUgcmVjb3ZlcmVkIGJ5IHRyYW5zZmVycmluZyB0aGUg bG9zdCBkYXRhIG9yIG1ldGFkYXRhIGZyb20gdGhlIGZlZGVyYXRlZCBkYXRhIGdyaWQu ICBUaGlzIGNhcGFiaWxpdHkgaXMgdXNlZCBpbiBib3RoIHByZXNlcnZhdGlvbiBlbnZp cm9ubWVudHMgYW5kIGRpZ2l0YWwgbGlicmFyaWVzLg1UaGUgZGF0YSBncmlkIGFkbWlu aXN0cmF0b3IgZXhlY3V0ZXMgdGhlIGFib3ZlIG9wZXJhdGlvbnMgdG8gbWFuYWdlIGFz c2VydGlvbnMgYWJvdXQgdGhlIHNoYXJlZCBjb2xsZWN0aW9uLiAgVGhlIGFzc2VydGlv bnMgY2FuIGJlIGEgc3RhdGVtZW50IHRoYXQgdGhlIGludGVncml0eSBvZiBhbGwgZmls ZXMgaGFzIGJlZW4gdmVyaWZpZWQgd2l0aGluIGEgc3BlY2lmaWVkIHRpbWUgcGVyaW9k LCBvciB0aGF0IHRoZSByZXF1aXJlZCBudW1iZXIgb2YgcmVwbGljYXMgZXhpc3RzIGZv ciBlYWNoIGZpbGUsIG9yIHRoYXQgdGhlIG1ldGFkYXRhIGNhdGFsb2cgaGFzIGJlZW4g c3luY2hyb25pemVkIHdpdGggdGhlIFNSQiBkYXRhIGdyaWQgdmF1bHRzLiAgSWYgcHJv YmxlbXMgYXJlIGZvdW5kIHN1Y2ggdGhhdCBhIGRlc2lyZWQgYXNzZXJ0aW9uIGhhcyBu b3QgYmVlbiBtZXQgYnkgdGhlIGRhdGEgZ3JpZCwgdGhlIGRhdGEgZ3JpZCBhZG1pbmlz dHJhdG9yIG1heSBuZWVkIGhlbHAgZnJvbSBzeXN0ZW1zIGFuYWx5c3RzIGFib3V0IHN0 b3JhZ2Ugc3lzdGVtIGludGVyYWN0aW9ucyBvciBmcm9tIG5ldHdvcmsgYWRtaW5pc3Ry YXRvcnMgYWJvdXQgbmV0d29yayBpbnRlcmFjdGlvbnMgb3IgZnJvbSBkYXRhYmFzZSBh ZG1pbmlzdHJhdG9ycyBhYm91dCBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGUgbWV0YWRh dGEgY2F0YWxvZyBhbmQgdGhlIGRhdGFiYXNlLiAgVHlwaWNhbCBkYXRhIGdyaWQgYWRt aW5pc3RyYXRvciB0YXNrcyBpbmNsdWRlIGJvdGggcGVyaW9kaWMgYXNzZXJ0aW9uIHRl c3RpbmcgYXMgd2VsbCBhcyBpbnRlcm1pdHRlbnQgb3BlcmF0aW9uYWwgdGFza3M6DVBl cmlvZGljIHN5c3RlbSBhZG1pbmlzdHJhdGlvbiB0YXNrczoNTWFuYWdlIGludGVncml0 eSBjaGVja3Mgb24gZGF0YQ1NYW5hZ2UgYXVkaXQgdHJhaWxzDU1hbmFnZSBjb25zaXN0 ZW5jeSBjaGVja3Mgb24gY29sbGVjdGlvbnMNTWFuYWdlIHN5bmNocm9uaXphdGlvbiBv ZiByZXBsaWNhcw1NYW5hZ2UgZGVsZXRpb24gb2YgZmlsZXMgKHRyYXNoIGNhbiBlbXB0 eWluZykNVHJhY2sgYWxsIGVycm9ycyBhbmQgcmVwb3J0ZWQgZGF0YSBsb3NzZXMNTWFu YWdlIHVwZ3JhZGVzIHRvIG5ldyB2ZXJzaW9ucyBvZiB0aGUgZGF0YSBncmlkIHNlcnZl cnMNTWFuYWdlIHVwZ3JhZGVzIHRvIG5ldyB2ZXJzaW9ucyBvZiB0aGUgbWV0YWRhdGEg Y2F0YWxvZw1NYW5hZ2UgaW50ZXJhY3Rpb25zIHdpdGggbmV3IHN0b3JhZ2Ugc3lzdGVt LCBkYXRhYmFzZSwgYW5kIG5ldHdvcmsgdGVjaG5vbG9neQ1NYWludGFpbiBlbmQtdG8t ZW5kIGNvbmZpZ3VyYXRpb24gY29udHJvbCAoZGF0YWJhc2UgcG9ydCBhc3NpZ25lZCB0 byBhIGNvbGxlY3Rpb24sIHBvcnRzIG9wZW4gb24gZmlyZXdhbGxzLCBhbmQgbmV0d29y ayBhZGRyZXNzZXMpDU1hbmFnZSBpbnRlcmFjdGlvbnMgd2l0aCBhdXRoZW50aWNhdGlv biBlbnZpcm9ubWVudHMNT3BlcmF0aW9uYWwgdGFza3M6DUFkZCBzZXJ2ZXJzIGZvciBu ZXcgc3RvcmFnZSByZXNvdXJjZXMNQWRkIG5ldyB1c2Vycw1SZXNwb25kIHRvIHVzZXIg cXVlc3Rpb25zDU1vZGlmeSBhY2Nlc3MgY29udHJvbHMgb24gY29sbGVjdGlvbnMNUmVz dGFydCBkYXRhIGdyaWQgc2VydmVycyBhcyBuZWVkZWQNSWRlbnRpZnkgcHJvYmxlbXMg d2l0aCBzdG9yYWdlIHN5c3RlbXMNUmVzcG9uZCB0byBpbnN0YWxsYXRpb24gcXVlc3Rp b25zDUludGVncmF0ZSB1c2VyIGludGVyZmFjZXMgd2l0aCBkYXRhIGdyaWQNDTMuIEV4 YW1wbGUgT3BlcmF0aW9uYWwgSXNzdWVzDQ1UaGUgbWFuYWdlbWVudCBvZiBhIGRhdGEg Z3JpZCBpcyBiZXN0IGlsbHVzdHJhdGVkIHRocm91Z2ggZXhhbXBsZXMgb2YgaW50ZXJh Y3Rpb25zIGJldHdlZW4gdGhlIGRhdGEgZ3JpZCBhbmQgdGhlIHVuZGVybHlpbmcgc29m dHdhcmUgYW5kIGhhcmR3YXJlIHN5c3RlbXMgYW5kIGJldHdlZW4gdGhlIGRhdGEgZ3Jp ZCBhbmQgdGhlIHVzZXJzLiBXZSByZWNvZ25pemUgZm91ciBtYWluIG9wZXJhdGlvbnMg Y2F0ZWdvcmllczogZGF0YSBncmlkIGVycm9yIGRpYWdub3NpczsgdXNlciBzdXBwb3J0 OyBBUEkgc2VsZWN0aW9uOyBhbmQgZmVkZXJhdGlvbi4NDTMuMSBEYXRhIEdyaWQgRXJy b3IgRGlhZ25vc2lzDQ1UaGUgU1JCIGRhdGEgZ3JpZCBpcyBpbXBsZW1lbnRlZCBhcyBh IHBlZXItdG8tcGVlciBhcmNoaXRlY3R1cmUgaW4gd2hpY2ggYW55IFNSQiBzZXJ2ZXIg Y2FuIGNvbW11bmljYXRlIHdpdGggYW5vdGhlciBTUkIgc2VydmVyLiAgIFdoZW4gYSB1 c2VyIGV4ZWN1dGVzIGEgY2xpZW50IG9wZXJhdGlvbiwgdGhlIHJlcXVlc3QgaXMgc2Vu dCB0byBhIGRlZmF1bHQgc2VydmVyLCB3aGljaCBpbnRlcmFjdHMgd2l0aCBhIGNlbnRy YWwgbWV0YWRhdGEgY2F0YWxvZyB0byBpbnRlcnByZXQgdGhlIG9wZXJhdGlvbiBhbmQg aWRlbnRpZnkgd2hlcmUgdGhlIG9wZXJhdGlvbiBzaG91bGQgYmUgZXhlY3V0ZWQsIGFu ZCB0aGVuIGZvcndhcmRzIHRoZSByZXF1ZXN0IHRvIHRoZSBhcHByb3ByaWF0ZSBzdG9y YWdlIHNlcnZlci4gIFRoZSByZWxpYWJpbGl0eSBvZiB0aGUgZGF0YSBncmlkIGRlcGVu ZHMgb24gdGhlIGFiaWxpdHkgb2YgdGhlIHNlcnZlcnMgdG8gY29tbXVuaWNhdGUgc3Vj Y2Vzc2Z1bGx5Lg1BbnkgaW50ZXJydXB0aW9uIGluIGNvbW11bmljYXRpb24gYmV0d2Vl biBzZXJ2ZXJzIGlzIHNlZW4gYnkgdGhlIHVzZXIgYXMgYSBmYWlsdXJlIG9mIHRoZSBk YXRhIGdyaWQuICBUaHVzIGEgbWFqb3IgdGFzayBvZiB0aGUgZGF0YSBncmlkIGFkbWlu aXN0cmF0b3IgaXMgdGhlIGRpYWdub3NpcyBhbmQgY29ycmVjdGlvbiBvZiBzZXJ2ZXIt dG8tc2VydmVyIGNvbW11bmljYXRpb24gZXJyb3JzLiAgVGhlIG1ham9yIHRvb2wgcHJv dmlkZWQgYnkgdGhlIFNSQiBkYXRhIGdyaWQgdG8gbW9uaXRvciBvcGVyYXRpb25zIGlz IGEgc3lzdGVtIGxvZyB0aGF0IHRyYWNrcyBvcGVyYXRpb25zIHBlcmZvcm1lZCBieSB1 c2VycyBhbmQgdGhlIGFzc29jaWF0ZWQgdGFzayBjb21wbGV0aW9uIHN0YXR1cy4gIFNl cGFyYXRlIHN5c3RlbSBsb2dzIGFyZSBrZXB0IGJ5IGVhY2ggc2VydmVyLiAgVGhlIGRh dGEgZ3JpZCBhZG1pbmlzdHJhdG9yIGV4YW1pbmVzIGVhY2ggbG9nIHRvIHVuZGVyc3Rh bmQgd2hldGhlciB0aGUgcHJvYmxlbSBpcyBjYXVzZWQgYnkgYSByZW1vdGUgc3RvcmFn ZSBzeXN0ZW0gb3V0YWdlLCBhIG5ldHdvcmsgaW50ZXJydXB0LCBhIGNvbmZpZ3VyYXRp b24gY2hhbmdlLCBvciBhIGNvbGxlY3Rpb24gbWFuYWdlbWVudCBlcnJvci4gIFNpbmNl IHRoZSB1bmRlcmx5aW5nIGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSBzeXN0ZW1zIG1heSBi ZSBhZG1pbmlzdGVyZWQgYnkgaW5kZXBlbmRlbnQgZ3JvdXBzLCBpdCBpcyBxdWl0ZSBw b3NzaWJsZSBmb3IgYSBzeXN0ZW0gdGhhdCBpcyByZWxpYWJseSBmdW5jdGlvbmluZyB0 byBiZSBpbXBhY3RlZCBieSBhbiBhZG1pbmlzdHJhdGl2ZSBkZWNpc2lvbiBhdCBhIHJl bW90ZSBzaXRlLiAgRXhhbXBsZSBwcm9ibGVtcyBpbmNsdWRlOg1TdG9yYWdlIHN5c3Rl bSBtYWludGVuYW5jZS4gIEEgc3RvcmFnZSBzeXN0ZW0gbWF5IGJlIHRha2VuIG9mZiBs aW5lIHdpdGhvdXQgbm90aWZpY2F0aW9uLCByZXN1bHRpbmcgaW4gZmFpbHVyZSB3aGVu IHVzZXJzIGF0dGVtcHQgdG8gYWNjZXNzIGZpbGVzIG9uIHRoYXQgc3lzdGVtLiAgQWx0 aG91Z2ggdGhlIFNSQiBkYXRhIGdyaWQgc3VwcG9ydHMgYXV0b21hdGVkIGZhaWwgb3Zl ciB0byByZXBsaWNhcywgYSBjb2xsZWN0aW9uIG1hbmFnZXIgbWF5IGhhdmUgY2hvc2Vu IHRvIG9ubHkgaGF2ZSBhIHNpbmdsZSBjb3B5IG9mIGEgZmlsZS4NT25lIG1lY2hhbmlz bSB0byBpbXByb3ZlIGRldGVjdGlvbiBvZiByZW1vdGUgc3RvcmFnZSBzeXN0ZW0gYXZh aWxhYmlsaXR5IGlzIHRvIHJ1biBhIJNob3QgcGFnZZQgd2hpY2ggcGVyaW9kaWNhbGx5 IHBpbmdzIGVhY2ggc3RvcmFnZSBlbnZpcm9ubWVudCBhbmQgcmVwb3J0cyByZXNwb25z ZSB0aW1lcyBhbmQgdHJhbnNwb3J0IHJhdGVzLiAgU3lzdGVtcyB3aGljaCBtb25pdG9y IFNSQiBzZXJ2ZXIgc3RhdHVzIGFyZSBsaXN0ZWQgb24gdGhlIFNSQiB3aWtpOiAgEyBI WVBFUkxJTksgImh0dHA6Ly93d3cuc2RzYy5lZHUvc3JiLyIgARRodHRwOi8vd3d3LnNk c2MuZWR1L3NyYi8VIHVuZGVyIGRvd25sb2FkcyBhbmQgY29udHJpYnV0ZWQgc29mdHdh cmUuDVN0b3JhZ2Ugc3lzdGVtIHVwZ3JhZGVzLiAgV2hlbiB0aGUgc29mdHdhcmUgYW5k IGhhcmR3YXJlIHN0b3JhZ2Ugc3lzdGVtcyBwcm92aWRlZCBieSBhIHZlbmRvciBhcmUg dXBncmFkZWQsIHRoZSBTUkIgZHJpdmVyIHdyaXR0ZW4gZm9yIHRoYXQgc3lzdGVtIG1h eSBuZWVkIHRvIGJlIG1vZGlmaWVkLiAgVGhlIHByb2JsZW1zIHR5cGljYWxseSBhcmUg cmVsYXRlZCB0byBtYW5hZ2VtZW50IG9mIGV4Y2VwdGlvbmFsIGNhc2VzLCBzdWNoIGFz IHVzZSBvZiBwYXJhbGxlbCBJL08gdG8gbW92ZSB2ZXJ5IGxhcmdlIGZpbGVzLCBvciBi dWxrIG1hbmlwdWxhdGlvbiBvZiBhIGxhcmdlIG51bWJlciBvZiBzbWFsbCBmaWxlcy4g IEJvdGggY2FzZXMgc3RyZXNzIGxvY2FsIHJlc291cmNlcywgYW5kIGV4cG9zZSBwcm9i bGVtcyBpbiB2ZW5kb3Igc29mdHdhcmUuICBUaGUgU1JCIGRyaXZlciBtdXN0IHRoZW4g YmUgbW9kaWZpZWQgdG8gZW5zdXJlIHRoYXQgdGhlIHBhcnRpY3VsYXIgdmVuZG9yIHNv ZnR3YXJlIGlzIG5vIGxvbmdlciB1bmR1bHkgc3RyZXNzZWQuDU5ldHdvcmsgY29uZmln dXJhdGlvbi4gIEEgbWFqb3IgY2hhbGxlbmdlIGlzIG1hbmFnaW5nIGludGVyYWN0aW9u cyB3aXRoIG5ldHdvcmsgZGV2aWNlcyBzdWNoIGFzIGZpcmV3YWxscywgcHJpdmF0ZSB2 aXJ0dWFsIG5ldHdvcmtzLCBhbmQgbG9hZCBsZXZlbGVycy4gIFNpbmNlIHRoZSBTUkIg dXNlcyBtdWx0aXBsZSBuZXR3b3JrIHBvcnRzIHRvIHNlbmQgcGFyYWxsZWwgSS9PIHN0 cmVhbXMsIHRoZSBjb21tdW5pY2F0aW9uIHdpbGwgZmFpbCBpZiB0aGUgbmV0d29yayBk ZXZpY2VzIGFyZSBub3QgYXBwcm9wcmlhdGVseSBjb25maWd1cmVkLiAgTWFuYWdlbWVu dCB0YXNrcyBpbmNsdWRlIHNldHRpbmcgdXAgdGhlIGNvcnJlY3QgcG9ydCByYW5nZXMg dG8gc3VwcG9ydCBwYXJhbGxlbCBJL08gc3RyZWFtcyB0aHJvdWdoIGEgZmlyZXdhbGws IGFuZCBzcGVjaWZ5aW5nIHRoZSBJUCBhZGRyZXNzZXMgZnJvbSB3aGljaCBleHRlcm5h bCBjb21tdW5pY2F0aW9ucyB3aWxsIGJlIHJlY2VpdmVkIGZvciBwcml2YXRlIHZpcnR1 YWwgbmV0d29ya3MuICBXaGVuIGEgbmV3IHNlcnZlciBpcyBhZGRlZCB0byB0aGUgZW52 aXJvbm1lbnQsIHRoZSBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gbWF5IG5lZWQgdG8gYmUg bW9kaWZpZWQuDVRoZSBTUkIgdXNlcyBtdWx0aXBsZSBjb21tdW5pY2F0aW9uIGNvbnRy b2wgcHJvdG9jb2xzIHRvIGVuc3VyZSB0aGUgYWJpbGl0eSB0byBpbnRlcmFjdCBncmFj ZWZ1bGx5IHdpdGggZmlyZXdhbGxzLiAgVGhlIGNvbnRyb2wgcHJvdG9jb2xzIGluY2x1 ZGUgc2VyaWFsIEkvTyB3aXRoIGNvbnRyb2wgYW5kIGRhdGEgbW92ZW1lbnQgdGhyb3Vn aCB0aGUgc2FtZSBwb3J0LCBzZXJ2ZXItaW5pdGlhdGVkIHBhcmFsbGVsIEkvTywgY2xp ZW50LWluaXRpYXRlZCBwYXJhbGxlbCBJL08sIGNsaWVudC1pbml0aWF0ZWQgYnVsayBt ZXRhZGF0YSBvcGVyYXRpb25zLCBhbmQgc2VydmVyLWluaXRpYXRlZCBidWxrIG1ldGFk YXRhIG9wZXJhdGlvbnMuICBDdXJyZW50bHksIHRoZSB1c2VyIG11c3QgZXhlY3V0ZSBk aWZmZXJlbnQgY29tbWFuZHMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGRpZmZlcmVu dCBwcm90b2NvbHMuICBUaHVzIGFuIGF0dGVtcHQgdG8gdXNlIHBhcmFsbGVsIEkvTyB0 byBtb3ZlIGRhdGEgdG8gYSBzdG9yYWdlIHN5c3RlbSBiZWhpbmQgYSBmaXJld2FsbCBt YXkgZmFpbCBiZWNhdXNlIGEgY2xpZW50LWluaXRpYXRlZCBwYXJhbGxlbCBJL08gY29t bWFuZCB3YXMgYXR0ZW1wdGVkIGluc3RlYWQgb2YgYSBzZXJ2ZXItaW5pdGlhdGVkIHBh cmFsbGVsIEkvTyBjb21tYW5kLiAgS2VlcGluZyB0cmFjayBvZiB0aGlzIHR5cGUgb2Yg cHJvYmxlbSByZXF1aXJlcyBleGFtaW5pbmcgdGhlIHN5c3RlbSBsb2cgYW5kIGNvbXBh cmluZyB0aGUgcmVxdWVzdGVkIG9wZXJhdGlvbiB3aXRoIHRoZSBkYXRhIGdyaWQgY29u ZmlndXJhdGlvbiBpbmZvcm1hdGlvbi4NRGF0YWJhc2UgYWRtaW5pc3RyYXRpb24uICBB IGNyaXRpY2FsIGNvbXBvbmVudCBvZiB0aGUgZGF0YSBncmlkIGlzIHRoZSBtYW5hZ2Vt ZW50IG9mIHRoZSBzdGF0ZSBpbmZvcm1hdGlvbiB0aGF0IHJlc3VsdHMgZnJvbSB0aGUg ZGF0YSBvcGVyYXRpb25zIChmaWxlIHdyaXRlcywgYXVkaXQgdHJhaWxzLCBhY2Nlc3Mg Y29udHJvbCBjaGFuZ2VzLCBmaWxlIHVwZGF0ZXMsIHVzZXItZGVmaW5lZCBtZXRhZGF0 YSBjaGFuZ2VzLCByZXBsaWNhdGlvbiwghSkuICBFYWNoIG9mIHRoZXNlIHVwZGF0ZXMg aW5jcmVhc2VzIHRoZSBhbW91bnQgb2YgbWV0YWRhdGEgdGhhdCBtdXN0IGJlIG1hbmFn ZWQgd2l0aGluIHRoZSBkYXRhYmFzZSB0aGF0IGhvbGRzIHRoZSBtZXRhZGF0YSBjYXRh bG9nIChNQ0FUKS4gIEEgc3RhbmRhcmQgaW1wYWN0IGlzIHRoYXQgdGhlIHN5c3RlbSBj YW4gYmVjb21lIHVucmVzcG9uc2l2ZSwgd2l0aCBhIHF1ZXJ5IHRvIHRoZSBkYXRhYmFz ZSB0YWtpbmcgYW4gaW5vcmRpbmF0ZWx5IGxvbmcgdGltZSB0byByZXNwb25kLiAgVGhl IGRhdGEgZ3JpZCBhZG1pbmlzdHJhdG9yIG1hbmFnZXMgdGhlIGRhdGFiYXNlIGluc3Rh bmNlIHRvIGtlZXAgdGhlIHN5c3RlbSBydW5uaW5nIGludGVyYWN0aXZlbHkgYnkgcGVy aW9kaWNhbGx5IG9wdGltaXppbmcgaW5kaWNlcyBvbiB0aGUgbWV0YWRhdGEgY2F0YWxv ZyB0YWJsZXMuDVRoZSBkYXRhYmFzZSBhZG1pbmlzdHJhdG9yIHN1cHBvcnRzIHVwZGF0 ZXMgdG8gdGhlIGRhdGFiYXNlIHRlY2hub2xvZ3ksIG1hbmFnZXMgdGhlIHNpemUgb2Yg dGhlIHRhYmxlIHNwYWNlcywgbW9uaXRvcnMgdGhlIHJlc291cmNlIHV0aWxpemF0aW9u IChudW1iZXIgb2Ygc2ltdWx0YW5lb3VzIHRyYW5zYWN0aW9ucywgYW1vdW50IG9mIG1l bW9yeSB1c2VkLCBmcmFjdGlvbiBvZiBDUFUgdXNlZCkgdG8gZW5zdXJlIGludGVyYWN0 aXZlIHJlc3BvbnNlLCBhbmQgbWFuYWdlcyBiYWNrdXBzIG9mIHRoZSBtZXRhZGF0YSBj YXRhbG9nLiAgU2luY2UgYWxsIHN0YXRlIGluZm9ybWF0aW9uIG5lZWRlZCB0byBtYWlu dGFpbiB0aGUgZGF0YSBncmlkIHJlc2lkZXMgaW4gdGhlIGRhdGFiYXNlLCB0aGUgZGF0 YWJhc2UgYmFja3VwcyBhcmUgdGhlIG1vc3QgY3JpdGljYWwgY29tcG9uZW50IGluIGRh dGEgZ3JpZCBhZG1pbmlzdHJhdGlvbi4gIElmIHRoZSBzdGF0ZSBpbmZvcm1hdGlvbiBp biB0aGUgZGF0YWJhc2UgaXMgbG9zdCwgdGhlIGRhdGEgZ3JpZCBsb3NlcyB0aGUgYWJp bGl0eSB0byBpZGVudGlmeSBhbmQgcmV0cmlldmUgcmVtb3RlIGZpbGVzLiAgDUFuIGFk dmFudGFnZSBvZiBoYXZpbmcgZGF0YSBncmlkIHN0YXRlIGluZm9ybWF0aW9uIGluIGEg Y2VudHJhbCBjYXRhbG9nIGlzIHRoZSBhYmlsaXR5IHRvIHByb2Nlc3MgbWFueSBjb2xs ZWN0aW9uIG9wZXJhdGlvbnMgbXVjaCBtb3JlIGVmZmljaWVudGx5IHRoYW4gY2FuIGJl IGRvbmUgYnkgb3BlcmF0aW9ucyBvbiBmaWxlIHN5c3RlbSBpLW5vZGVzLiBFeGFtcGxl cyBhcmUgZ2VuZXJhdGlvbiBvZiBsaXN0cyBvZiBtaWxsaW9uLWZpbGUgY29sbGVjdGlv bnMgYW5kIGNoZWNraW5nIHRoZSBhbW91bnQgb2Ygc3BhY2UgdXNlZC4gIFRoZSBleGNl cHRpb24gaXMgdGhlIHBoeXNpY2FsIGRlbGV0aW9uIG9mIGZpbGVzLiAgVGhlIFNSQiBw cm92aWRlcyBhIJN0cmFzaCBjYW6UIGludG8gd2hpY2ggZGVsZXRlZCBmaWxlcyBhcmUg bW92ZWQuICBUaGUgcGh5c2ljYWwgZGVsZXRpb24gZG9lcyBub3Qgb2NjdXIgdW50aWwg dGhlIJN0cmFzaCBjYW6UIGlzIGVtcHRpZWQuIFRoaXMgcmVxdWlyZXMgYSBzZXBhcmF0 ZSBpbnRlcmFjdGlvbiB3aXRoIHRoZSBmaWxlIHN5c3RlbSBmb3IgZWFjaCBmaWxlLCBh bmQgY2FuIHRha2UgYSB2ZXJ5IGxvbmcgdGltZSB3aGVuIHRlbnMgb2YgdGhvdXNhbmRz IG9mIGZpbGVzIGFyZSBkZWxldGVkLiAgQSBwZXJpb2RpYyByZW1vdmFsIG9mIGZpbGVz IGZyb20gdGhlIJN0cmFzaCBjYW6UIGlzIGEgcmVxdWlyZWQgb3BlcmF0aW9uIG9uIHNv bWUgZGF0YSBncmlkcywgb3RoZXJ3aXNlIHVzZXJzIHBlcmNlaXZlIGVpdGhlciBzdG9y YWdlIHN5c3RlbXMgdGhhdCBhcmUgZmlsbGVkIHRvIGNhcGFjaXR5IG9yIGV4Y2Vzc2l2 ZSBwaHlzaWNhbCBmaWxlIHJlbW92YWwgdGltZXMuDU9jY2FzaW9uYWxseSwgaW50ZXJh Y3Rpb25zIHdpdGggdGhlIG1ldGFkYXRhIGNhdGFsb2cgYXBwZWFyIHRvIGZhaWwuICBJ biB0aGlzIGNhc2UsIGFkZGl0aW9uYWwgc3lzdGVtIGxvZ3MgY2FuIGJlIHR1cm5lZCBv biB0aGF0IGxpc3QgdGhlIGNvbXBsZXRlIFNRTCBjb21tYW5kIHRoYXQgaXMgaXNzdWVk IGJ5IHRoZSBtZXRhZGF0YSBjYXRhbG9nIGludGVyZmFjZSB0byB0aGUgZGF0YWJhc2Uu ICBUaGVzZSBzeXN0ZW1zIGxvZ3MgY2FuIGdyb3cgdmVyeSByYXBpZGx5LCBhbmQgdGh1 cyBhcmUgbm9ybWFsbHkgdHVybmVkIG9mZi4gIFRoZSBhYmlsaXR5IHRvIHRyYWNrIHRo ZSBhY3R1YWwgU1FMIG1ha2VzIGl0IHBvc3NpYmxlIHRvIGlkZW50aWZ5IHByb2JsZW1z IHdpdGggdW51c3VhbCBjaGFyYWN0ZXJzIGluIGNvbGxlY3Rpb24gYW5kIGZpbGUgbmFt ZXMsIGluY29uc2lzdGVuY2llcyBiZXR3ZWVuIHN0YXRlIGluZm9ybWF0aW9uIGluIHRo ZSBtZXRhZGF0YSBjYXRhbG9nIGFuZCB0aGUgZmlsZXMgdGhhdCBhY3R1YWxseSByZXNp ZGUgaW4gdGhlIFNSQiB2YXVsdCwgYW5kIGluY29tcGxldGUgc3RhdGUgaW5mb3JtYXRp b24gdGhhdCB3YXMgZ2VuZXJhdGVkIGJ5IGFuIGVhcmxpZXIgdmVyc2lvbiBvZiB0aGUg U1JCLiAgRWFjaCBvZiB0aGVzZSBwcm9ibGVtcyBjYW4gYmUgY29ycmVjdGVkIGJ5IHRo ZSBkYXRhIGdyaWQgYWRtaW5pc3RyYXRvciB0aHJvdWdoIGRpcmVjdCBtYW5pcHVsYXRp b24gb2YgdGhlIHN0YXRlIGluZm9ybWF0aW9uIHdpdGhpbiB0aGUgbWV0YWRhdGEgY2F0 YWxvZy4gIFRoaXMgcmVxdWlyZXMga25vd2xlZGdlIG9mIHRoZSB0YWJsZSBzdHJ1Y3R1 cmVzIHVzZWQgYnkgdGhlIFNSQiBNQ0FULCB0aGUgYWJpbGl0eSB0byBjb21wb3NlIGFu ZCBpc3N1ZSBTUUwgY29tbWFuZHMgdG8gdGhlIGRhdGFiYXNlLCBhbmQgYW4gdW5kZXJz dGFuZGluZyBvZiB0aGUgc2VtYW50aWMgbWVhbmluZyBvZiBlYWNoIHBpZWNlIG9mIFNS QiBtZXRhZGF0YS4NU1JCIGRhdGEgZ3JpZCBhZG1pbmlzdHJhdGlvbi4gIFRoZSBTUkIg ZGF0YSBncmlkIGNvbnRpbnVlcyB0byBldm9sdmUgdG8gc3VwcG9ydCBjYXBhYmlsaXRp ZXMgcmVxdWlyZWQgYnkgdGhlIG11bHRpcGxlIHByb2plY3RzIHRoYXQgdXNlIHRoZSB0 ZWNobm9sb2d5LiAgVGhlIHR5cGVzIG9mIHVwZ3JhZGVzIHJhbmdlIGZyb20gbWFqb3Ig cmVsZWFzZXMgdGhhdCBwcm92aWRlIG5ldyBmdW5kYW1lbnRhbCBjYXBhYmlsaXRpZXMg KFNSQiB2ZXJzaW9uIDMpLCB0byBtaW5vciByZWxlYXNlcyB0aGF0IHByb3ZpZGUgbmV3 IGZlYXR1cmVzIChTUkIgdmVyc2lvbiAzLjQpLCB0byBidWcgZml4ZXMgKFNSQiB2ZXJz aW9uIDMuNC4yKS4gRm9yIGV4YW1wbGUgdGhlIHJlbGVhc2Ugb2Ygc3VwcG9ydCBmb3Ig cGFyYWxsZWwgSS9PIHdhcyBwcm92aWRlZCBpbiBTUkIgdmVyc2lvbiAyLCBhbmQgc3Vw cG9ydCBmb3IgZGF0YSBncmlkIGZlZGVyYXRpb24gd2FzIHByb3ZpZGVkIGluIFNSQiB2 ZXJzaW9uIDMuICBBbGwgb2YgdGhlIG1ham9yIHJlbGVhc2VzLCBwbHVzIHNvbWUgb2Yg dGhlIG1pbm9yIHJlbGVhc2VzIHJlcXVpcmVkIGNoYW5nZXMgdG8gdGhlIFNSQiBwcm90 b2NvbCB1c2VkIHRvIHN1cHBvcnQgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFNSQiBzZXJ2 ZXJzLiAgVGhlIHZlcnNpb24gb2YgdGhlIGNvbW11bmljYXRpb24gcHJvdG9jb2wgaXMg c3BlY2lmaWVkIGJ5IGEgbGV0dGVyIHRoYXQgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBy ZWxlYXNlLiAgVGhlIGN1cnJlbnQgcHJvdG9jb2wgdmVyc2lvbiBpcyBsZXR0ZXIgk2aU LCBpbXBseWluZyB0aGUgY29tbXVuaWNhdGlvbiBwcm90b2NvbCBoYXMgY2hhbmdlZCA1 IHRpbWVzLg1UaGUgc3RhdGUgaW5mb3JtYXRpb24gdGhhdCBpcyBtYW5hZ2VkIGJ5IHRo ZSBTUkIgaGFzIGFsc28gZXZvbHZlZC4gIFRoaXMgbWVhbnMgdGhhdCBuZXcgdGFibGUg c3RydWN0dXJlcyBoYXZlIGJlZW4gYWRkZWQgdG8gdGhlIFNSQiBNQ0FUIGNhdGFsb2cu ICBBbiB1cGdyYWRlIG9mIHRoZSBTUkIgc3lzdGVtIG1heSByZXF1aXJlIHRoZSBjcmVh dGlvbiBvZiBuZXcgZGF0YWJhc2UgdGFibGVzIGluIE1DQVQuICBGb3IgaW5zdGFuY2Us IHdoZW4gc3VwcG9ydCBmb3IgZmVkZXJhdGlvbiB3YXMgZGV2ZWxvcGVkLCB0aGUgU1JC IGhhZCB0byBhc3NvY2lhdGUgYSB1bmlxdWUgem9uZSBuYW1lIHdpdGggZWFjaCBpbmRl cGVuZGVudCBkYXRhIGdyaWQuICBUaGlzIG1lYW50IHRoYXQgdGhlIGZpbGVzIGluIGEg Y29sbGVjdGlvbiBoYWQgdG8gYmUgaWRlbnRpZmllZCBieSB0aHJlZSBsYWJlbHM7IHpv bmUgbmFtZSAvIGNvbGxlY3Rpb24gbmFtZSAvIGxvZ2ljYWwgZmlsZSBuYW1lLiAgVGhp cyBhZmZlY3RlZCB0aGUgY2xpZW50cywgdGhlIHNlcnZlcnMsIGFuZCB0aGUgTUNBVCBt ZXRhZGF0YSBjYXRhbG9nLCBhbmQgaGVuY2UgcmVxdWlyZWQgYSBtYWpvciByZWxlYXNl Lg1XaGVuIHVwZ3JhZGVzIGFyZSBtYWRlIHRvIG5ldyBTUkIgdmVyc2lvbnMsIGFuIGF0 dGVtcHQgaXMgbWFkZSB0byBtYWludGFpbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiAg T2xkIGNsaWVudHMgYXJlIGV4cGVjdGVkIHRvIGJlIGFibGUgdG8gYWNjZXNzIHRoZSBu ZXcgZW52aXJvbm1lbnQuICBIb3dldmVyIHRoaXMgaXMgbm90IHRydWUgZm9yIFNSQiBz ZXJ2ZXJzLiAgVGh1cyBhIG1ham9yIHNvdXJjZSBvZiBxdWVzdGlvbnMgaXMgd2hpY2gg U1JCIHZlcnNpb25zIGFyZSByZXF1aXJlZCB3aGVuIGNvbWJpbmluZyBjbGllbnRzLCBz ZXJ2ZXJzLCBhbmQgdGhlIE1DQVQgY2F0YWxvZyBpbnRvIGEgZnVuY3Rpb25pbmcgc3lz dGVtLiBUd28gYXBwcm9hY2hlcyBoYXZlIGJlZW4gZm9sbG93ZWQgd2l0aGluIHRoZSBT UkIgdXNlciBjb21tdW5pdHkgdG8gbWFuYWdlIHVwZ3JhZGVzIHRvIG5ldyBTUkIgdmVy c2lvbnMuICBUaGUgYXBwcm9hY2hlcyBhcmUgZGlmZmVyZW50aWF0ZWQgYnkgd2hldGhl ciB0aGV5IHRyeSB0byBwcmVzZXJ2ZSB0aGUgY29sbGVjdGlvbiBpZGVudGl0eSwgb3Ig d2hldGhlciB0aGV5IHRyeSB0byBtYWludGFpbiB0aGUgYWJpbGl0eSBmb3IgcHJpb3Ig Y2xpZW50cyB0byBhY2Nlc3MgdGhlIG5ldyBzeXN0ZW0uICANVGhlIGZpcnN0IGFwcHJv YWNoIGtlZXBzIHRoZSBzYW1lIG5ldHdvcmsgYWRkcmVzcyBhbmQgc2FtZSBwb3J0IG51 bWJlciBmb3IgdGhlIE1DQVQgY2F0YWxvZy4gIEFsbCBjbGllbnRzIGFyZSB1cGdyYWRl ZCBzaW11bHRhbmVvdXNseSBhbG9uZyB3aXRoIGFsbCBzZXJ2ZXJzLCBlbnN1cmluZyB0 aGF0IHRoZSBjb3JyZWN0IHByb3RvY29sIGlzIHVzZWQgYmV0d2VlbiBhbGwgb2YgdGhl IHN5c3RlbSBjb21wb25lbnRzIGFuZCB0aGUgY29ycmVjdCBzdGF0ZSBpbmZvcm1hdGlv biBpcyBzYXZlZC4NVGhlIHNlY29uZCBhcHByb2FjaCBrZWVwcyB0aGUgc2FtZSBuZXR3 b3JrIGFkZHJlc3MgZm9yIHRoZSBNQ0FUIGNhdGFsb2csIGJ1dCBpbnN0YWxscyBhIG5l dyBNQ0FUIHNlcnZlciB1c2luZyBhIG5ldyBwb3J0IG51bWJlci4gIFRoZSBvbGQgY2xp ZW50cyBhY2Nlc3MgdGhlIG9yaWdpbmFsIE1DQVQgc2VydmVyIHVzaW5nIHRoZSBvcmln aW5hbCBwb3J0IG51bWJlci4gIFRoZSBuZXcgY2xpZW50cyBhY2Nlc3MgdGhlIG5ldyBN Q0FUIHNlcnZlciB1c2luZyB0aGUgbmV3IHBvcnQgbnVtYmVyLiAgVGhpcyBrZWVwcyB0 aGUgcHJvdG9jb2wgY29uc2lzdGVudCBiZXR3ZWVuIHRoZSBvbGQgYW5kIG5ldyBzeXN0 ZW1zLCBidXQgZm9yY2VzIHRoZSByZXNlYXJjaCBjb21tdW5pdHkgdG8gdXNlIGEgk25l d5QgcG9ydCBudW1iZXIgdG8gYWNjZXNzIHRoZSBjb2xsZWN0aW9uLg0NMy4yIFVzZXIg U3VwcG9ydA0NRGF0YSBncmlkcyBwcm92aWRlIGEgdW5pZm9ybSBhY2Nlc3MgaW50ZXJm YWNlIHRvIG11bHRpcGxlIHR5cGVzIG9mIHN0b3JhZ2Ugc3lzdGVtcyB0aHJvdWdoIGRh dGEgYW5kIHRydXN0IHZpcnR1YWxpemF0aW9uIGxheWVycy4gIFRoZSB1c2VyIHRoZXJl Zm9yZSBpbnRlcmFjdHMgd2l0aCBhIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhlIGRhdGEg aW5zdGVhZCBvZiB0aGUgcGh5c2ljYWwgZmlsZXMuICBUaGUgdXNlciBpbnRlcmFjdHMg d2l0aCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIHBy b3ZpZGVkIGJ5IHRoZSBkYXRhIGdyaWQgaW5kZXBlbmRlbnRseSBvZiB0aGUgcmVtb3Rl IHN0b3JhZ2Ugc3lzdGVtLiBUaGVzZSBhcmUgdGhlIGhhcmRlc3QgY29uY2VwdHMgdG8g dW5kZXJzdGFuZCBhYm91dCBkYXRhIGdyaWRzLiBUaGUgcmVjb2duaXRpb24gdGhhdCB0 aGUgbG9naWNhbCBuYW1lIHNwYWNlIGZvciBmaWxlcyBjYW4gYmUgb3JnYW5pemVkIGlu ZGVwZW5kZW50bHkgb2YgdGhlIHBoeXNpY2FsIGZpbGUgbmFtZXMgaXMgYSBtYWpvciBj b25jZXB0dWFsIGh1cmRsZS4NQXQgdGhlIHNhbWUgdGltZSwgdGhlIHZpcnR1YWxpemF0 aW9uIG1lY2hhbmlzbXMgZW5hYmxlIG11bHRpcGxlIG5ldyBvcGVyYXRpb25zIG5vdCBz dXBwb3J0ZWQgYnkgYSBVbml4IGZpbGUgc3lzdGVtLCBpbmNsdWRpbmcgbG9naWNhbCBm aWxlIG5hbWUgbWFuYWdlbWVudCwgcmVwbGljYXRpb24sIGF1ZGl0IHRyYWlscywgcGFy YWxsZWwgSS9PLCBidWxrIG9wZXJhdGlvbnMsIGFuZCBtZXRhZGF0YSBtYW5pcHVsYXRp b24uICBDaG9vc2luZyBiZXR3ZWVuIHRoZSBhdmFpbGFibGUgb3BlcmF0aW9ucyBmb3Ig dGhlc2UgbmV3IGNhcGFiaWxpdGllcyB0dXJucyBvdXQgdG8gYmUgYSBtYWpvciB1c2Vy IHN1cHBvcnQgaXNzdWUuICAgVGhlIGJlc3QgcGVyZm9ybWluZyBjb21tYW5kIGlzIGFs d2F5cyBkZXNpcmVkLCBidXQgdGhpcyBtYXkgaW52b2x2ZSB1bmRlcnN0YW5kaW5nIHdo ZXRoZXIgcGFyYWxsZWwgb3Igc2VyaWFsIEkvTyBzaG91bGQgYmUgdXNlZCwgd2hldGhl ciBhIG5ldHdvcmsgZmlyZXdhbGwgaXMgaW4gdGhlIGNvbW11bmljYXRpb24gcGF0aCwg d2hldGhlciBidWxrIG9wZXJhdGlvbnMgc2hvdWxkIGJlIHVzZWQgZm9yIG1hbmlwdWxh dGluZyBzbWFsbCBmaWxlcywgd2hldGhlciByZW1vdGUgcHJvY2VkdXJlcyBzaG91bGQg YmUgdXNlZCB0byBmaWx0ZXIgdGhlIGRlc2lyZWQgZGF0YSwgYW5kIHdoZXRoZXIgcmVw bGljYXRpb24gaXMgbmVlZGVkIHRvIG1pbmltaXplIHJpc2sgb2YgZGF0YSBsb3NzLiAg SW4gcHJhY3RpY2UsIHNlcmlhbCBJL08gb24gY3VycmVudCBHaWdhYml0L3NlY29uZCBu ZXR3b3JrcyBpcyByZWFzb25hYmxlIHVwIHRvIGZpbGUgc2l6ZXMgb2YgMTAgbWVnYWJ5 dGVzLCBidWxrIG9wZXJhdGlvbnMgb24gYSB0aG91c2FuZCBmaWxlcyBpcyBhbHdheXMg ZmFzdGVyLCBhbmQgbm8gc2luZ2xlIHN0b3JhZ2Ugc3lzdGVtIHNob3VsZCBiZSB0cnVz dGVkIHRvIHJlbGlhYmx5IGhvbGQgZGF0YS4NVGhlIGlzc3VlIG9mIGRhdGEgcmVsaWFi aWxpdHkgcmVxdWlyZXMgY2FyZWZ1bCBjb25zaWRlcmF0aW9uLCBhcyB0aGUgZWZmb3J0 IGludm9sdmVkIGluIGFzc2VtYmxpbmcgYSBzaGFyZWQgY29sbGVjdGlvbiBjYW4gYmUg c3Vic3RhbnRpYWwgYW5kIHRha2UgYXMgbXVjaCB0aW1lIGFzIHRoZSBnZW5lcmF0aW9u IG9mIHRoZSBvcmlnaW5hbCBkYXRhLiAgV2Ugbm90ZSB0aGF0IGFzIHRoZSBhbW91bnQg b2YgZGF0YSB0aGF0IGlzIGJlaW5nIG1hbmFnZWQgaW5jcmVhc2VzIGluIHNpemUsIGJv dGggdGhlIHNpemUgb2YgaW5kaXZpZHVhbCBmaWxlcyBhbmQgdGhlIGNhcGFjaXR5IG9m IHRoZSBzdG9yYWdlIHN5c3RlbXMgYXJlIGluY3JlYXNpbmcuICBSQUlEIHN5c3RlbXMg YXJlIHJlYWNoaW5nIGEgY2FwYWNpdHkgcG9pbnQgd2hlcmUgdGhlIHRpbWUgdG8gcmVj b3ZlciBmcm9tIGEgcGFyaXR5IGVycm9yIGlzIGdyZWF0ZXIgdGhhbiB0aGUgdGltZSBm b3IgYW5vdGhlciBwYXJpdHkgZXJyb3IgdG8gYXBwZWFyLiAgQXQgdGhlIHNhbWUgdGlt ZSwgdGhlIGZpbGVzIHRoYXQgYXJlIHN0b3JlZCBvbiB0aGUgUkFJRCBzeXN0ZW0gbXVz dCBiZSBsYXJnZXIgdG8gZWZmaWNpZW50bHkgdXNlIHRoZSBtdWx0aXBsZSBkaXNrcy4g IFRoaXMgaW1wb3NlcyBhIG1pbmltdW0gZGVzaXJlZCBmaWxlIHNpemUgb24gdGhlIGNv bGxlY3Rpb24sIGFuZCB0aGUgbmVlZCB0byByZXBsaWNhdGUgZGF0YSB0byBlbnN1cmUg dGhlIGFiaWxpdHkgdG8gcmVjb3ZlciBmcm9tIGEgUkFJRCBmYWlsdXJlLg1UaGUgbWlu aW1pemF0aW9uIG9mIHJpc2sgb2YgZGF0YSBsb3NzIG5vdyByZXF1aXJlcyB0aGUgdXNl IG9mIHJlcGxpY2F0aW9uIGFjcm9zcyBtdWx0aXBsZSB0eXBlcyBvZiBzdG9yYWdlIHN5 c3RlbXMsIHBlcmlvZGljIHN5bmNocm9uaXphdGlvbiBvZiB0aGUgcmVwbGljYXMsIHBl cmlvZGljIHZhbGlkYXRpb24gb2YgY2hlY2tzdW1zIG9uIGVhY2ggZmlsZSwgYW5kIGV2 ZW4gcmVwbGljYXRpb24gb2YgZGF0YSBhbmQgbWV0YWRhdGEgaW50byBhbiBpbmRlcGVu ZGVudCBkYXRhIGdyaWQuIFRoZXNlIG1lY2hhbmlzbXMgd29yayBlZmZlY3RpdmVseSB3 aXRoIGRpc2stYmFzZWQgZmlsZSBzeXN0ZW1zLCBidXQgYXJlIGRpZmZpY3VsdCB0byBh cHBseSBvbiBsYXJnZSB0YXBlIGFyY2hpdmVzLiAgVGhlIGVmZmljaWVudCB2YWxpZGF0 aW9uIG9mIGxhcmdlIG51bWJlcnMgb2YgZmlsZXMgc3RvcmVkIG9uIHRhcGUgcmVxdWly ZXMgYSB3YXkgdG8gYWdncmVnYXRlIGZpbGVzIHRvIG1pbmltaXplIGFjY2VzcyB0aW1l Lg1TUkIgY29udGFpbmVycyB3ZXJlIG9yaWdpbmFsbHkgZW52aXNpb25lZCBhcyBhIHdh eSB0byBhZ2dyZWdhdGUgc21hbGwgZmlsZXMgYmVmb3JlIHdyaXRpbmcgb250byB0YXBl LWJhc2VkIGFyY2hpdmVzLiAgVGhlIGNvbnRhaW5lcnMgd2VyZSBzaXplZCB0byBtYXRj aCB0aGUgbGF0ZW5jeSBvZiB0YXBlIGFjY2VzcyBhbmQgdGhlIHRhcGUgcmVhZCByYXRl LiAgVGh1cyBhIHN0b3JhZ2Ugc3lzdGVtIHRoYXQgcmVxdWlyZWQgMTUgc2Vjb25kcyB0 byByZXRyaWV2ZSBhbmQgbW91bnQgYSB0YXBlLCBhbmQgdGhhdCB0aGVuIHJlYWQgdGhl IHRhcGUgYXQgMTIwIE1lZ2FieXRlcy9zZWNvbmQgd291bGQgdXNlIGEgY29udGFpbmVy IHNpemUgb2YgMS44IEdieXRlcy4gIE90aGVyd2lzZSB0aGUgZHV0eSBjeWNsZSBvZiB0 aGUgdGFwZSBkcml2ZSB3b3VsZCBiZSB2ZXJ5IGxvdy4gIFdoZW5ldmVyIG1vcmUgdGhh biB0d28gZmlsZXMgd2VyZSByZXRyaWV2ZWQgZnJvbSB0aGUgY29udGFpbmVyLCB0aGUg ZWZmZWN0aXZlIHBlcmZvcm1hbmNlIG9mIHRoZSBzdG9yYWdlIHN5c3RlbSBpcyBvcHRp bWl6ZWQuICBUaGUgdXNlIG9mIGNvbnRhaW5lcnMgYWxzbyBtaW5pbWl6ZWQgdGhlIG51 bWJlciBvZiBuYW1lcyB0aGF0IHRoZSBzdG9yYWdlIHN5c3RlbSBoYWQgdG8gbWFuYWdl LiAgVGhlIGRhdGEgZ3JpZCB0cmFja2VkIHRoZSBsb2NhdGlvbiBvZiBlYWNoIGZpbGUg aW4gYSBjb250YWluZXIsIGFuZCBtYW5hZ2VkIGNhY2hpbmcgb2YgdGhlIGNvbnRhaW5l ciBvbiBkaXNrIHRvIHN1cHBvcnQgYWN0dWFsIHJlYWQgYW5kIHdyaXRlIG9wZXJhdGlv bnMuICBUaGlzIG9mZi1sb2FkZWQgZmlsZSBtYW5pcHVsYXRpb24gZnJvbSB0aGUgdGFw ZSBhcmNoaXZlLg1Db250YWluZXJzIG5vdyBhcmUgbmVlZGVkIG9uIGRpc2sgZmlsZSBz eXN0ZW1zIHdoZW4gY29sbGVjdGlvbiBzaXplcyBhcmUgbWVhc3VyZWQgaW4gdGhlIHRl bnMgb2YgbWlsbGlvbnMgb2YgZmlsZXMuICBBcyBjb2xsZWN0aW9uIHNpemVzIGluY3Jl YXNlLCB0aGUgYWJpbGl0eSBvZiBkaXNrIGZpbGUgc3lzdGVtcyB0byByZXNwb25kIGlu dGVyYWN0aXZlbHkgZGVjcmVhc2VzLiAgRGF0YSBncmlkcyBvZmZsb2FkIHRoZSBtYW5h Z2VtZW50IG9mIHN0YXRlIGluZm9ybWF0aW9uIG5vcm1hbGx5IHN0b3JlZCBpbiBpLW5v ZGVzIG9udG8gdGhlIG1ldGFkYXRhIGNhdGFsb2cuDVRoZSB1c2Ugb2YgY29udGFpbmVy cyBpcyBub3cgYXBwZWFyaW5nIGFzIGEgcmVxdWlyZW1lbnQgZm9yIGltcHJvdmluZyB0 aGUgYWJpbGl0eSBvZiBib3RoIGZpbGUtYmFzZWQgYW5kIHRhcGUtYmFzZWQgc3lzdGVt cyB0byBzdXBwb3J0IHBlcmlvZGljIGNoZWNrc3VtIHZhbGlkYXRpb24gb24gdmVyeSBs YXJnZSBjb2xsZWN0aW9ucy4NVHlwaWNhbCBwcm9ibGVtcyBlbmNvdW50ZXJlZCBieSB1 c2VycyBpbmNsdWRlIHNldHRpbmcgU1JCIGNvbW1hbmQgcGFyYW1ldGVycyBpbmNvcnJl Y3RseSwgc2V0dGluZyBhdXRoZW50aWNhdGlvbiBlbnZpcm9ubWVudCAoR3JpZCBTZWN1 cml0eSBJbmZyYXN0cnVjdHVyZSkgcGFyYW1ldGVycyBpbmNvcnJlY3RseSwgYW5kIGRl YWxpbmcgd2l0aCB1bmF2YWlsYWJsZSBzdG9yYWdlIHJlc291cmNlcy4gIFVzZXJzIHJl cXVpcmUgdGhlIGFiaWxpdHkgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgZGF0YSBncmlkIGFk bWluaXN0cmF0b3IgdG86DU1hbmFnZSB0aGUgcm9vdCBsZXZlbCBvZiB0aGUgZGF0YSBn cmlkLiAgVGhpcyBpbmNsdWRlcyByZXF1ZXN0cyB0byBhZGQgbmV3IHVzZXJzLCBhZGQg bmV3IHNlcnZlcnMsIGFkZCBhY2Nlc3MgcGVybWlzc2lvbnMsIHJlY292ZXIgZnJvbSBp bnB1dCBlcnJvcnMgKGluYXBwcm9wcmlhdGUgYmxhbmtzIGluIGEgZmlsZSBuYW1lKSwg bWFuYWdlIHN0b3JhZ2UgcXVvdGFzLCBhbmQgbWFuYWdlIHN0b3JhZ2UgcmVzb3VyY2Vz Lg1PdmVyIHRpbWUsIHNvbWUgb2YgdGhlc2Ugb3BlcmF0aW9ucyBoYXZlIGJlZW4gbW92 ZWQgaW50byB0aGUgdXNlciBzcGFjZSwgY29uc2lzdGVudCB3aXRoIHRoZSBhdXRoZW50 aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwb2xpY2llcy4gIFRodXMgY3VyYXRvcnMg b2YgY29sbGVjdGlvbnMgY2FuIHNldCBhY2Nlc3MgcGVybWlzc2lvbnMgZm9yIGNvLXdv cmtlcnMsIGJ1dCBvcGVyYXRpb25zIHRoYXQgcmVxdWlyZSBhIGhpZ2hlciBsZXZlbCBv ZiB0cnVzdCBoYXZlIHRvIGJlIGRvbmUgYnkgdGhlIGRhdGEgZ3JpZCBhZG1pbmlzdHJh dG9yLg1Qcm92aWRlIGluc3RhbGxhdGlvbiBzdXBwb3J0LiAgU3RhbmRhcmQgaW5zdGFs bGF0aW9uIHNjcmlwdHMgYXJlIHByb3ZpZGVkIGZvciBpbnN0YWxsaW5nIHRoZSBTUkIg ZGF0YSBncmlkIHNvZnR3YXJlIG9uIE1hY3MsIExpbnV4IHN5c3RlbXMsIGFuZCBTb2xh cmlzIHN5c3RlbXMuICBOb24tc3RhbmRhcmQgaW5zdGFsbGF0aW9ucywgc3VjaCBhcyB1 c2luZyBhIHByZS1leGlzdGluZyBkYXRhYmFzZSwgb3IgYSBzcGVjaWZpYyBsb2NhbCBz eXN0ZW0gY29uZmlndXJhdGlvbiByZXF1aXJlIGRhdGEgZ3JpZCBhZG1pbmlzdHJhdG9y IHN1cHBvcnQuICANQXV0aGVudGljYXRpb24gZW52aXJvbm1lbnQuICBUaGUgU1JCIGRh dGEgZ3JpZCBzdXBwb3J0cyB0aHJlZSBkaWZmZXJlbnQgYXV0aGVudGljYXRpb24gbWVj aGFuaXNtczogIGNoYWxsZW5nZS1yZXNwb25zZSwgR3JpZCBTZWN1cml0eSBJbmZyYXN0 cnVjdHVyZSAoR1NJKSBwdWJsaWMga2V5IGNlcnRpZmljYXRlcywgYW5kIHRpY2tldHMu ICBUaGUgY2hhbGxlbmdlLXJlc3BvbnNlIG1lY2hhbmlzbSByZXF1aXJlcyBhIHNoYXJl ZCBzZWNyZXQgYmV0d2VlbiB0aGUgcmVtb3RlIGNsaWVudCBhbmQgdGhlIFNSQiBkYXRh IGdyaWQuICBUaGUgc2hhcmVkIHNlY3JldCBpcyBub3Qgc2VudCBvdmVyIHRoZSBuZXR3 b3JrLiAgSW5zdGVhZCBhIGNoYWxsZW5nZSBpcyBlbmNyeXB0ZWQgYXQgdGhlIGNsaWVu dCBhbmQgc2VudCB0byB0aGUgTUNBVCBzZXJ2ZXIgd2hpY2ggdmFsaWRhdGVzIHRoZSB1 c2VyIGlkZW50aXR5IGJ5IGRlY3J5cHRpbmcgdGhlIGNoYWxsZW5nZS4gDVRoZSBHU0kg ZW52aXJvbm1lbnQgbWFuYWdlcyBwdWJsaWMvcHJpdmF0ZSBrZXlzIGluIGEgY2VydGlm aWNhdGUgYXV0aG9yaXR5LiAgVGhlIEdTSSBzeXN0ZW0gcHJvdmlkZXMgc3RhbmRhcmQg c2VydmljZXMgZm9yIHZhbGlkYXRpbmcgdGhlIGlkZW50aXR5IG9mIGEgdXNlci4gIEhv d2V2ZXIgdGhlIEdTSSBzeXN0ZW0gY29udGludWVzIHRvIGV2b2x2ZSwgaW1wbHlpbmcg dGhlIG5lZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSB2ZXJzaW9ucyBvZiB0aGUgc2Vydmlj ZXMuICBJbnN0YWxsaW5nIHRoZSBHU0kgZW52aXJvbm1lbnQgaXMgYSBub24tdHJpdmlh bCB0YXNrLiAgDVRoZSBTUkIgdGlja2V0LWJhc2VkIGFjY2VzcyBpcyBhIGdlbmVyYWxp emF0aW9uIG9mIGFub255bW91cyBGVFAgYW5kIHByb3ZpZGVzIGEgd2F5IHRvIGdyYW50 IGFjY2VzcyB0byBzcGVjaWZpZWQgZmlsZXMuICBUaGUgbnVtYmVyIG9mIGFjY2Vzc2Vz IGFuZCB0aGUgdGltZSBwZXJpb2QgZHVyaW5nIHdoaWNoIHRoZSBhY2Nlc3NlcyBhcmUg YWxsb3dlZCBjYW4gYmUgY29udHJvbGxlZC4gIEFueSBwZXJzb24gd2hvIGhhcyB0aGUg dGlja2V0IGNhbiBhY2Nlc3MgdGhlIGZpbGUuICANVGhlIG1hbmFnZW1lbnQgb2YgdGhl IEdTSSBhdXRoZW50aWNhdGlvbiBlbnZpcm9ubWVudCByZXF1aXJlcyBleHBlcnQga25v d2xlZGdlIG9mIGdyaWQgdGVjaG5vbG9neS4gIFRoaXMgaXMgYSBtYWpvciBpbXBlZGlt ZW50IHRvIHRoZSB1c2Ugb2YgR1NJIGF1dGhlbnRpY2F0aW9uIGluIG1vc3QgZGlnaXRh bCBsaWJyYXJpZXMgYW5kIHByZXNlcnZhdGlvbiBlbnZpcm9ubWVudHMuDQ0zLjMgQVBJ IFNlbGVjdGlvbg0NVGhlIFNSQiBkYXRhIGdyaWQgcHJvdmlkZXMgdGhyZWUgZnVuZGFt ZW50YWwgYWNjZXNzIG1ldGhvZHM6IEMgbGlicmFyeSBjYWxscyB0byBzdXBwb3J0IGFj Y2VzcyBmcm9tIGFwcGxpY2F0aW9uczsgVW5peC1zdHlsZSBzaGVsbCBjb21tYW5kcyBm b3IgaW50ZXJhY3RpdmUgYWNjZXNzOyBhbmQgSmF2YSBjbGFzcyBsaWJyYXJ5IGZvciB3 ZWItYmFzZWQgYWNjZXNzLiAgU28gZmFyLCBhbGwgb3RoZXIgYWNjZXNzIG1ldGhvZHMg KG9mIHdoaWNoIHRoZXJlIGFyZSBtb3JlIHRoYW4gZmlmdGVlbikgYXJlIHBvcnRlZCBv biB0b3Agb2YgdGhlc2UgdGhyZWUgbWVjaGFuaXNtcy4gIFdoaWxlIHRoaXMgcHJvdmlk ZXMgYSB3YXkgZm9yIGFueSBleGlzdGluZyBkYXRhIG1hbmFnZW1lbnQgc3lzdGVtIHRv IGFjY2VzcyBkaXN0cmlidXRlZCBkYXRhIHN0b3JlZCBpbiBhIFNSQiBjb2xsZWN0aW9u LCB0aGUgcG9ydGluZyBvZiB0aGUgbG9jYWwgaW50ZXJmYWNlcyB0byB0aGUgU1JCIG1h eSByZXF1aXJlIGFzc2lzdGFuY2UuDUVhY2ggU1JCIGludGVyZmFjZSB3YXMgZGV2ZWxv cGVkIGluIHJlc3BvbnNlIHRvIHRoZSBuZWVkcyBvZiBhIHBhcnRpY3VsYXIgcmVzZWFy Y2ggY29tbXVuaXR5LiAgVGhpcyBtZWFucyB0aGUgY2FwYWJpbGl0aWVzIHByb3ZpZGVk IGJ5IGEgcGFydGljdWxhciBpbnRlcmZhY2UgYXJlIHVuaXF1ZSwgYW5kIGFkZHJlc3Mg cHJvamVjdCBzcGVjaWZpYyBkYXRhIG1hbmFnZW1lbnQgcG9saWNpZXMuICBUaGUgQyBs aWJyYXJ5IGludGVyZmFjZSBpbXBsZW1lbnRzIGFsbCBvZiB0aGUgU1JCIGRhdGEgbWFu YWdlbWVudCBmdW5jdGlvbmFsaXR5LiAgVGhlIFVuaXgtc3R5bGUgc2hlbGwgY29tbWFu ZHMgd3JhcCBtb3N0IG9mIHRoZSBTUkIgZnVuY3Rpb25hbGl0eSBpbnRvIFMtY29tbWFu ZHMgdGhhdCBlbXVsYXRlIHNpbWlsYXIgb3BlcmF0aW9ucyBwcm92aWRlZCBieSBmaWxl IHN5c3RlbXMuICBUaHVzIJNTbHOUIGxpc3RzIGZpbGVzIGluIGEgU1JCIGNvbGxlY3Rp b24sIHNpbWlsYXIgdG8gdGhlIGFjdGlvbiBvZiB0aGUgk2xzlCBjb21tYW5kIGZvciBs aXN0aW5nIGZpbGVzIGluIGEgZmlsZSBzeXN0ZW0uICBUaGUgSmF2YSBjbGFzcyBsaWJy YXJ5IGV4dGVuZHMgdGhlIFN1biBJL08gY2xhc3NlcyB0byBzdXBwb3J0IGFjY2VzcyB0 byBTUkIgY29sbGVjdGlvbnMuDVRoZSBjaG9pY2Ugb2YgYSBzcGVjaWZpYyBhY2Nlc3Mg aW50ZXJmYWNlIGltcGxpZXMgdGhhdCB0aGUgYXNzb2NpYXRlZCBvcGVyYXRpb25zIG1h eSBiZSBhIHN1YnNldCBvZiBhdmFpbGFibGUgU1JCIG9wZXJhdGlvbnMuICBUaHVzIHRo ZSBXU0RMIGludGVyZmFjZSBzdXBwb3J0cyBhIGxpbWl0ZWQgc2V0IG9mIHNpbmdsZSBm aWxlIG1hbmlwdWxhdGlvbiBvcGVyYXRpb25zLCB0aGUgUGVybCBsb2FkIGxpYnJhcnkg c3VwcG9ydHMgc29tZSBtZXRhZGF0YSBvcGVyYXRpb25zLCB0aGUgaW5RIHdpbmRvd3Mg YnJvd3NlciBzdXBwb3J0cyBzb3BoaXN0aWNhdGVkIGRyYWcgYW5kIGRyb3Agb3BlcmF0 aW9ucyBmcm9tIHRoZSBkZXNrIHRvcCBpbnRvIGEgU1JCIGNvbGxlY3Rpb24sIGFuZCB0 aGUgbXlTUkIgd2ViIGJyb3dzZXIgaW50ZXJmYWNlIHN1cHBvcnRzIG11bHRpcGxlIGN1 cmF0aW9uIG9wZXJhdGlvbnMgcmVsYXRlZCB0byBtZXRhZGF0YSBjcmVhdGlvbi4NVXNl cnMgZW5jb3VudGVyIGNoYWxsZW5nZXMgd2hlbiB0aGV5IHN0YXJ0IHVzaW5nIGNhcGFi aWxpdGllcyBub3QgYXZhaWxhYmxlIGluIHRyYWRpdGlvbmFsIGZpbGUgc3lzdGVtcy4g IFR3byBzcGVjaWZpYyBjYXBhYmlsaXRpZXMgZXhlbXBsaWZ5IHRoaXM6DVNoYWRvdyBv YmplY3RzLiAgSXQgaXMgcG9zc2libGUgdG8gcmVnaXN0ZXIgYSBmaWxlIHRoYXQgcmVz aWRlcyBpbiBhIHJlbW90ZSBzdG9yYWdlIHN5c3RlbSBpbnRvIGEgU1JCIGNvbGxlY3Rp b24gd2l0aG91dCBwaHlzaWNhbGx5IGNvcHlpbmcgdGhlIGZpbGUuICBUaGUgdXNlciBv bmx5IGhhcyB0byBzZXQgdXAgcGVybWlzc2lvbiBmb3IgdGhlIFNSQiBkYXRhIGdyaWQg YWNjb3VudCB0byByZWFkIHRoZSBmaWxlLiAgT25jZSB0aGUgZmlsZSBpcyByZWdpc3Rl cmVkLCB0aGUgU1JCIGNhbiBtYW5hZ2UgdGhlIGxvZ2ljYWwgZmlsZSBuYW1lIHRoYXQg aXMgYXNzaWduZWQgdG8gdGhlIGZpbGUgYW5kIGNyZWF0ZSBhIGxvZ2ljYWwgY29sbGVj dGlvbiBoaWVyYXJjaHksIGFzc29jaWF0ZSB1c2VyLWRlZmluZWQgbWV0YWRhdGEgd2l0 aCB0aGUgZmlsZSwgYW5kIHN1cHBvcnQgYnJvd3NpbmcgYW5kIGRpc2NvdmVyeSBvZiB0 aGUgZmlsZSB0aHJvdWdoIGFueSBvZiB0aGUgU1JCIGludGVyZmFjZXMuICBTaW5jZSB0 aGUgZmlsZSBoYXMgbm90IGJlZW4gcGh5c2ljYWxseSBjb3BpZWQgaW50byBhIFNSQi1t YW5hZ2VkIHN0b3JhZ2Ugc3lzdGVtIGNvbnRyb2xsZWQgYnkgdGhlIFNSQiBhY2NvdW50 IElELCB0aGUgdXNlciBjYW4gc3RpbGwgbW9kaWZ5IGFuZCBldmVuIGRlbGV0ZSB0aGUg ZmlsZSB3aXRob3V0IGluZm9ybWluZyB0aGUgU1JCIGRhdGEgZ3JpZC4gIFRodXMgc2hh ZG93IG9iamVjdHMgYXJlIGNyZWF0ZWQgdG8gYWlkIHRoZSBpbmdlc3Rpb24gb2YgZmls ZXMgaW50byBhIGRhdGEgZ3JpZCwgYW5kIGRlY291cGxlIGRhdGEgcmVnaXN0cmF0aW9u IGZyb20gZGF0YSBtb3ZlbWVudC4NVGhlIGNvbmNlcHR1YWwgdW5kZXJzdGFuZGluZyBv ZiBsb2dpY2FsIHN0YXRlIGluZm9ybWF0aW9uIG1haW50YWluZWQgYWJvdXQgdGhlIHNo YWRvdyBvYmplY3QgdmVyc3VzIHRoZSByZXN1bHQgb2YgcGh5c2ljYWwgb3BlcmF0aW9u cyBwZXJmb3JtZWQgb3V0c2lkZSBvZiB0aGUgU1JCIGRhdGEgZ3JpZCBpcyBkaWZmaWN1 bHQuICBUbyBtaW5pbWl6ZSB0aGUgcG9zc2liaWxpdHkgb2YgaW5jb25zaXN0ZW50IGFj Y2VzcyBtZWNoYW5pc21zIChsb2NhbCB2ZXJzdXMgU1JCLWJhc2VkIGFjY2VzcyksIHNo YWRvdyBvYmplY3RzIHNob3VsZCBiZSBjb3BpZWQgb250byBTUkIgc3RvcmFnZSBzeXN0 ZW1zIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBTUkIgZGF0YSBncmlkLiAgVGhpcyBl bnN1cmVzIHRoYXQgYWxsIGZ1dHVyZSBvcGVyYXRpb25zIG9uIHRoZSBmaWxlIHdpbGwg YmUgdGhyb3VnaCB0aGUgU1JCIGRhdGEgZ3JpZCBhbmQgdGhlIGFzc29jaWF0ZWQgc3Rh dGUgaW5mb3JtYXRpb24gY2FuIGJlIGF1dG9tYXRpY2FsbHkgdXBkYXRlZC4NVXNlci1k ZWZpbmVkIG1ldGFkYXRhIGFuZCBtZXRhZGF0YSBxdWVyaWVzLiAgVGhlIGFiaWxpdHkg dG8gc3BlY2lmeSBtZXRhZGF0YSBhdHRyaWJ1dGVzIGZvciBlYWNoIGNvbGxlY3Rpb24g YW5kIGZvciBlYWNoIG9iamVjdCB3aXRoaW4gYSBjb2xsZWN0aW9uIGlzIHN1cHBvcnRl ZCBieSB0aGUgU1JCIGRhdGEgZ3JpZC4gIEhvd2V2ZXIgaXQgaXMgdXAgdG8gZWFjaCBy ZXNlYXJjaCBwcm9qZWN0IHRvIGRlZmluZSB0aGUgc2V0IG9mIG1ldGFkYXRhIHRoYXQg aXMgcmVsZXZhbnQgdG8gdGhlaXIgZGlnaXRhbCBob2xkaW5ncyBhbmQgZGF0YSBtYW5h Z2VtZW50IHBvbGljaWVzLiAgVGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIGRlc2lyZWQg bWV0YWRhdGEsIHRoZSBhc3NpZ25tZW50IG9mIHNlbWFudGljIG1lYW5pbmcgdG8gZWFj aCBtZXRhZGF0YSBlbGVtZW50LCBhbmQgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIGFs bG93ZWQgcmFuZ2Ugb2YgYXR0cmlidXRlIHZhbHVlcyBuZWVkIHRvIGJlIGEgY29uc2Vu c3VzIGZvcm1lZCBieSBlYWNoIGNvbW11bml0eS4NU2luY2UgdGhlIG11bHRpcGxlIFNS QiBpbnRlcmZhY2VzIHByb3ZpZGUgYSBkaWZmZXJlbnQgc3Vic2V0IG9mIG1ldGFkYXRh IG1hbmlwdWxhdGlvbiBvcGVyYXRpb25zLCB0aGUgY2hvaWNlIG9mIEFQSSBpcyBzdHJv bmdseSBkcml2ZW4gYnkgdGhlIHR5cGUgb2YgYnJvd3NpbmcgYW5kIHF1ZXJ5aW5nIHJl cXVpcmVtZW50cy4gIEF0IHRoZSBzYW1lIHRpbWUsIGVhY2ggY29tbXVuaXR5IGhhcyBh IHByZWZlcnJlZCBpbXBsZW1lbnRhdGlvbiBsYW5ndWFnZS4gIFRodXMgZWFjaCByZXNl YXJjaCBjb21tdW5pdHkgaW5ldml0YWJseSBkcml2ZXMgdGhlIGV4dGVuc2lvbiBvZiBt b3JlIHNvcGhpc3RpY2F0ZWQgaW50ZXJmYWNlcyBmb3IgdGhlIFNSQiBkYXRhIGdyaWQu ICBUaGUgYWJpbGl0eSB0byB0YWlsb3IgdGhlIGRhdGEgbWFuYWdlbWVudCBlbnZpcm9u bWVudCB0byB0aGUgaW50ZXJmYWNlcyBhbmQgb3BlcmF0aW9ucyBkZXNpcmVkIGJ5IGEg c3BlY2lmaWMgcmVzZWFyY2ggcHJvamVjdCByZXF1aXJlcyBpbnRlcmFjdGlvbnMgd2l0 aCBub3Qgb25seSB0aGUgU1JCIGRhdGEgZ3JpZCBhZG1pbmlzdHJhdG9yLCBidXQgYWxz byB0aGUgU1JCIGRldmVsb3BlcnMuICBUaGlzIHByb2Nlc3MgaGFzIGJlZW4gcmVwZWF0 ZWQgbWFueSB0aW1lcywgd2l0aCB0aGUgcmVzdWx0aW5nIGludGVyZmFjZXMgYWNjZXNz aWJsZSBmcm9tIHRoZSBTUkIgd2lraSBwYWdlIGFzIGNvbnRyaWJ1dGVkIHNvZnR3YXJl Lg0NMy40IEZlZGVyYXRpb24gb2YgZGF0YSBncmlkcw0NVGhlIGRvbWluYW50IGVtZXJn aW5nIHN0cmF0ZWd5IGZvciBsaW5raW5nIGRhdGEgZ3JpZHMgaXMgdGhlIGNvbnN0cnVj dGlvbiBvZiBmZWRlcmF0ZWQgY29sbGVjdGlvbnMgdGhhdCBhcmUgaW5kZXBlbmRlbnRs eSBtYW5hZ2VkIGJ5IHNlcGFyYXRlIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMgWzhdLiAg VGhlIGNvbmNlcHQgb2YgZmVkZXJhdGlvbiBoYXMgZW5hYmxlZCB0aGUgY3JlYXRpb24g b2YgcXVpdGUgc29waGlzdGljYXRlZCBlbnZpcm9ubWVudHMgdXNpbmcgZGF0YSBncmlk cyBhcyBjb21tb24gYnVpbGRpbmcgY29tcG9uZW50cy4gIEV4YW1wbGVzIG9mIGZlZGVy YXRpb25zIGluY2x1ZGU6DUNlbnRyYWwgYXJjaGl2ZXMuICBVbmRlciB0aGlzIG1hbmFn ZW1lbnQgcG9saWN5LCBpbmRlcGVuZGVudCBkYXRhIGdyaWRzIHB1c2ggZGF0YSBpbnRv IGEgY2VudHJhbCBhcmNoaXZlLiAgVGhlIGNlbnRyYWwgYXJjaGl2ZSBpdHNlbGYgaXMg YSBkYXRhIGdyaWQgdGhhdCBtYW5hZ2VzIGl0cyBvd24gc3RvcmFnZSBzeXN0ZW1zIHVz aW5nIGl0cyBvd24gbWV0YWRhdGEgY2F0YWxvZy4gIEVhY2ggZGF0YSBncmlkIGFzc3Vt ZXMgcmVzcG9uc2liaWxpdHkgZm9yIGRlY2lkaW5nIHdoaWNoIGZpbGVzIHRvIHJlcGxp Y2F0ZSB0byB0aGUgY2VudHJhbCBhcmNoaXZlLiAgRWFjaCBkYXRhIGdyaWQgaW5kZXBl bmRlbnRseSBzeW5jaHJvbml6ZXMgdGhlaXIgc2VsZWN0ZWQgZGF0YSB3aXRoIHRoZSBj ZW50cmFsIGFyY2hpdmUuDUNlbnRyYWwgZGF0YSBhdXRob3JpdHkuICBVbmRlciB0aGlz IG1hbmFnZW1lbnQgcG9saWN5LCBhbGwgZGF0YSBvcmlnaW5hdGVzIGZyb20gdGhlIGNl bnRyYWwgYXV0aG9yaXR5LiAgRGF0YSBpcyBwdXNoZWQgdG8gcmVtb3RlIGxlYWYgZGF0 YSBncmlkcyBmb3IgbG9jYWwgYWNjZXNzIGFuZCBtYW5hZ2VtZW50LiAgRWFjaCBvZiB0 aGUgbGVhZiBkYXRhIGdyaWRzIHJlbGllcyB1cG9uIHRoZSBjZW50cmFsIGRhdGEgYXV0 aG9yaXR5IGZvciBhdXRoZW50aWMgZGF0YS4NUHVsbCBlbnZpcm9ubWVudHMuICBUaGlz IGlzIHRoZSBtb3N0IHBvcHVsYXIgZmVkZXJhdGlvbiBlbnZpcm9ubWVudCwgdXNlZCB0 byBtYW5hZ2UgaW50ZXJuYXRpb25hbGx5IHNoYXJlZCBjb2xsZWN0aW9ucy4gIEVhY2gg ZGF0YSBncmlkIGRlY2lkZXMgd2hpY2ggZmlsZXMgd2lsbCBiZSBwdWxsZWQgZnJvbSBh bm90aGVyIGRhdGEgZ3JpZCBhbmQgcmVwbGljYXRlZCBsb2NhbGx5LiAgVGhlIGRhdGEg Z3JpZHMgY2FuIGJlIG9yZ2FuaXplZCBpbiBjaGFpbnMsIHdpdGggZGF0YSBwdWxsZWQg ZnJvbSBvbmUgZGF0YSBncmlkIHRvIHRoZSBuZXh0IHVuZGVyIGxvY2FsIGFkbWluaXN0 cmF0aXZlIGNvbnRyb2wuDURlZXAgYXJjaGl2ZXMuICBJdCBpcyBwb3NzaWJsZSB0byBi dWlsZCBmZWRlcmF0aW9ucyBzdWNoIHRoYXQgdGhlIGxvY2F0aW9uIG9mIHRoZSBkZWVw IGFyY2hpdmUgYW5kIHRoZSBpZGVudGl0eSBvZiB0aGUgYXJjaGl2aXN0cyBpbiB0aGUg ZGVlcCBhcmNoaXZlIGNhbm5vdCBiZSBzZWVuIGZyb20gdGhlIGV4dGVybmFsIHdvcmxk IFs5XS4gIFRoaXMgaXMgYWNjb21wbGlzaGVkIGJ5IGluc3RhbGxpbmcgYSBzdGFnaW5n IGRhdGEgZ3JpZCBiZXR3ZWVuIHRoZSBtdWx0aXBsZSBkYXRhIGdyaWRzIHRoYXQgY2Fu IGJlIGFjY2Vzc2VkIGJ5IHRoZSBwdWJsaWMsIGFuZCB0aGUgZGF0YSBncmlkIHRoYXQg d2lsbCBiZSB0aGUgZGVlcCBhcmNoaXZlLiAgVGhlIGlkZW50aXR5IG9mIGFuIGFyY2hp dmlzdCB3aXRoIGFjY2VzcyBwcml2aWxlZ2VzIGluIHRoZSBzdGFnaW5nIGRhdGEgZ3Jp ZCBpcyByZWdpc3RlcmVkIGludG8gdGhlIHB1YmxpYyBkYXRhIGdyaWRzLiAgVGhpcyBh cmNoaXZpc3QgdGhlbiBwdWxscyBkYXRhIHRocm91Z2ggYSBmaXJld2FsbCB1c2luZyBj bGllbnQtaW5pdGlhdGVkIHBhcmFsbGVsIEkvTy4gIFRoZSBpZGVudGl0eSBvZiB0aGUg YXJjaGl2aXN0IHdpdGggYWNjZXNzIHByaXZpbGVnZXMgaW4gdGhlIGRlZXAgYXJjaGl2 ZSBpcyByZWdpc3RlcmVkIGludG8gdGhlIHN0YWdpbmcgZGF0YSBncmlkLiAgVGhpcyBh cmNoaXZpc3QgdGhlbiBwdWxscyBkYXRhIGZyb20gdGhlIHN0YWdpbmcgZGF0YSBncmlk IGludG8gdGhlIGRlZXAgYXJjaGl2ZS4gIFRocm91Z2ggYXBwcm9wcmlhdGUgY29tYmlu YXRpb25zIG9mIHByaXZhdGUgdmlydHVhbCBuZXR3b3JrcyBhbmQgZmlyZXdhbGxzLCBh bGwgY29tbXVuaWNhdGlvbiBjYW4gYmUgcmVzdHJpY3RlZCBiZXR3ZWVuIHRoZSBzdGFn aW5nIGdyaWQgYW5kIHRoZSBwdWJsaWMgZGF0YSBncmlkcywgYW5kIGJldHdlZW4gdGhl IHN0YWdpbmcgZ3JpZCBhbmQgdGhlIGRlZXAgYXJjaGl2ZS4gIFRoZSByZXN1bHQgaXMg dGhlIGFiaWxpdHkgdG8gYXV0b21hdGUgdGhlIG1vdmVtZW50IG9mIGRhdGEgZnJvbSB0 aGUgZXh0ZXJuYWwgd29ybGQgaW50byB0aGUgZGVlcCBhcmNoaXZlLCB3aXRob3V0IGV4 cG9zaW5nIHRoZSBkZWVwIGFyY2hpdmUgdG8gdW53YXJyYW50ZWQgcHVibGljIGFjY2Vz cy4NVGhlIGFib3ZlIHNjZW5hcmlvcyBhcmUgZGVwZW5kZW50IHVwb24gdGhlIG1lY2hh bmlzbXMgdXNlZCBieSBkYXRhIGdyaWRzIHRvIG1hbmFnZSBhdXRoZW50aWNhdGlvbiBh bmQgYXV0aG9yaXphdGlvbiBiZXR3ZWVuIGluZGVwZW5kZW50IGVudmlyb25tZW50cy4g IFRoZSBhcHByb2FjaCB0YWtlbiBpbiBTUkIgZmVkZXJhdGlvbiBpcyB0byByZXF1aXJl IGFsbCBhdXRoZW50aWNhdGlvbnMgb2YgYSB1c2VyIHRvIGJlIGRvbmUgYnkgdGhlIHVz ZXKScyBob21lIGRhdGEgZ3JpZC4gIFRoaXMgbWVhbnMgdGhhdCB0aGUgaWRlbnRpdHkg b2YgZWFjaCB1c2VyIGlzIG5vdyBhIHRyaXBsZXQ6IHVzZXItbmFtZSAvIHByb2plY3Qt bmFtZSAvIGhvbWUtZGF0YS1ncmlkLiAgQSByZWdpc3RyeSBpcyB1c2VkIHRvIG1haW50 YWluIHVuaXF1ZSBuYW1lcyBmb3IgZWFjaCBkYXRhIGdyaWQuICANV2hlbiB0d28gZGF0 YSBncmlkcyBhcmUgZmVkZXJhdGVkLCB0aGV5IHNldCB1cCBhIHRydXN0IHJlbGF0aW9u c2hpcCwgaWRlbnRpZnlpbmcgd2hlcmUgcmVxdWVzdHMgZm9yIHVzZXIgdmFsaWRhdGlv biB3aWxsIGJlIHNlbnQuICBXaGVuIGEgZGF0YSBncmlkIHJlY2VpdmVzIGEgcmVxdWVz dCBmb3IgYWNjZXNzIGJ5IGEgdXNlciB0aGF0IGlzIGZyb20gYSBmb3JlaWduIGRhdGEg Z3JpZCwgdGhlIGZvcmVpZ24gZGF0YSBncmlkIGlzIGFjY2Vzc2VkIHRvIHByb3ZpZGUg YXV0aGVudGljYXRpb24sIHdoaWxlIHRoZSBhY2Nlc3MgY29udHJvbHMgYXJlIGFzc2Vy dGVkIGJ5IHRoZSBsb2NhbCBkYXRhIGdyaWQuICBUaGlzIG1vZGVsIGlzIHNpbWlsYXIg dG8gdGhhdCBlbXBsb3llZCBpbiB0aGUgU2hpYmJvbGV0aCBhdXRoZW50aWNhdGlvbiBt b2RlbCwgaW4gd2hpY2ggdGhlIGF1dGhlbnRpY2F0aW9uIG9mIGFuIGluZGl2aWR1YWwg aXMgYWx3YXlzIGRvbmUgYnkgdGhlaXIgaG9tZSBpbnN0aXR1dGlvbi4gDQ00LiBHR0Yg U1JCIERhdGEgR3JpZCBGZWRlcmF0aW9uCw1BbiBleHBlcmltZW50IHdhcyBjb25kdWN0 ZWQgdG8gZGVtb25zdHJhdGUgZGF0YSBzaGFyaW5nIGJldHdlZW4gZmVkZXJhdGVkIGRh dGEgZ3JpZHMgYXQgdGhlIDE3dGggR2xvYmFsIEdyaWQgRm9ydW0gbWVldGluZyBpbiBU b2t5bywgSmFwYW4sIGhlbGQgb24gTWF5IDExLCAyMDA2LiAgVGhlIHNwZWNpZmljIGdv YWxzIHdlcmUgdG8gZmVkZXJhdGUgZm91cnRlZW4gaW50ZXJuYXRpb25hbCBTUkIgZGF0 YSBncmlkcyBhbmQ6IA1EZW1vbnN0cmF0ZSBicm93c2luZyBpbiBhIHJlbW90ZSBkYXRh IGdyaWQNRGVtb25zdHJhdGUgcmVhZCBhY2Nlc3MgdG8gYSBmaWxlIGluIGEgcmVtb3Rl IGRhdGEgZ3JpZA1Jc3N1ZSBTUkIgY29tbWFuZHMgdG8gbGlzdCByZXNvdXJjZXMgaW4g cmVtb3RlIGRhdGEgZ3JpZA1EZW1vbnN0cmF0ZSB3cml0ZSBhY2Nlc3MgdG8gYSByZWdp c3RlcmVkIHVzZXIgYWNjb3VudCBpbiBhIHJlbW90ZSBkYXRhIGdyaWQNDVRhYmxlIDEu ICBMaXN0IG9mIFBhcnRpY2lwYXRpbmcgRGF0YSBHcmlkcw1Db3VudHJ5B0RhdGEgR3Jp ZAdEYXRhIEdyaWQgQWRtaW5pc3RyYXRvcgcHQXVzdHJhbGlhB0FQQUMHU3RlcGhlbiBN Y01haG9uBwdUYWl3YW4HQVNHQwdFcmljIFllbiwgV2VpLUxvbmcgVWVuZwcHTmV3IFpl YWxhbmQHSUIHRGFuaWVsIEhhbmxvbgcHVUsHSUIHRGFuaWVsIEhhbmxvbgcHSXRhbHkH REVJU0EHR2l1c2VwcGUgRmlhbWVuaQcHRnJhbmNlB0lOMlAzB0plYW4tWXZlcyBOaWVm BwdKYXBhbgdLRUsHWW9zaGltaSBJaWRhBwdUYWl3YW4HTkNIQwdIc3UtTWVpIENob3UH B0NoaWxlL1VTB05PQU8HSXJlbmUgQmFyZwcHVVMHUHVyZHVlB0xhbiBaaGFvBwdVSwdS QUwHQWRpbCBIYXNhbgcHTmV0aGVybGFuZHMHU0FSQQdCYXJ0IEhldXBlcnMHB1VTB1Rl cmFHcmlkB1NoZWF1LVllbiBDaGVuBwdVUyAHVSBNZAdNaWtlIFNtb3J1bAcHDVRoZSBm b3VydGVlbiBpbnRlcm5hdGlvbmFsIGRhdGEgZ3JpZHMgdGhhdCBwYXJ0aWNpcGF0ZWQg b24gc2hvd24gaW4gVGFibGUgMS4gIE1hbnkgb2YgdGhlIGRhdGEgZ3JpZHMgdGhhdCBw YXJ0aWNpcGF0ZWQgaW4gdGhlIGRlbW9uc3RyYXRpb24gd2VyZSB0aGVtc2VsdmVzIGZl ZGVyYXRpb25zIG9mIGRhdGEgZ3JpZHMuICBUaHVzIHRoZSBHR0YgaW50ZXJvcGVyYWJp bGl0eSB0ZXN0YmVkIHdhcyByZWFsbHkgYSBmZWRlcmF0aW9uIG9mIGRhdGEgZ3JpZCBm ZWRlcmF0aW9ucy4NRWFjaCBkYXRhIGdyaWQgY2FuIHRoaW5rIG9mIGl0c2VsZiBhcyB0 aGUgaHViIG9mIGEgZmVkZXJhdGlvbi4gIEVhY2ggZGF0YSBncmlkIGNvbnRyb2xzIHRo ZSBzaGFyaW5nIG9mIG5hbWUgc3BhY2VzLCBhY2Nlc3MgY3JpdGVyaWEgZm9yIHRoZSBs b2NhbCBjb2xsZWN0aW9uLCBhbmQgdGhlIHNwZWNpZmljYXRpb24gb2Ygd2hpY2ggc3Vi c2V0IG9mIHRoZSBmaWxlcyB3aWxsIGJlIHNoYXJlZC4gRWFjaCBkYXRhIGdyaWQgc2Vs ZWN0cyB0aGUgc2V0IG9mIG90aGVyIGRhdGEgZ3JpZHMgd2l0aCB3aGljaCB0aGV5IGV4 Y2hhbmdlIHRydXN0IGluZm9ybWF0aW9uIGFuZCBjcm9zcy1yZWdpc3RlciB1c2VyIGlu Zm9ybWF0aW9uLiAgVGhpcyBpbXBsaWVzIHRoYXQgYSBmZWRlcmF0aW9uIG9mIGRhdGEg Z3JpZHMgY2FuIHNpbXVsdGFuZW91c2x5IHN1c3RhaW4gbWFueSBvZiB0aGUgZmVkZXJh dGlvbiBtb2RlbHMgdGhhdCBhcmUgbGlzdGVkIGFib3ZlLg1Gb3IgdGhlIEdsb2JhbCBH cmlkIEZvcnVtIGRlbW9uc3RyYXRpb24sIGEgc2luZ2xlIHVzZXIgYWNjb3VudCB3YXMg Y3Jvc3MtcmVnaXN0ZXJlZCBhY3Jvc3MgYWxsIHRoZSBmZWRlcmF0ZWQgZGF0YSBncmlk cy4gIFRoZSB1c2VyIGFjY291bnQgd2FzIHNwZWNpZmllZCBhcyBhIHRyaXBsZXQgZGVm aW5pbmcgdGhlIHVzZXIgKHVzZXJfbmFtZSksIHRoZSBwcm9qZWN0IChkb21haW5fZGVz Y3JpcHRpb24pLCBhbmQgaG9tZSBkYXRhIGdyaWQgKHpvbmVfaWQpOg11c2VyX25hbWU6 IAlnZ2ZzZHNjDWRvbWFpbl9kZXNjOiAJc2RzYw16b25lX2lkOiAJU0RTQy1HR0YNQSBj b21tb24gYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIHdhcyB1c2VkIHRvIGF1dGhlbnRp Y2F0ZSBhY2Nlc3MgYmV0d2VlbiBkYXRhIGdyaWRzIGJhc2VkIG9uIHRoZSBTUkIgk0Vu Y3J5cHQxlCBhdXRoZW50aWNhdGlvbiBtZXRob2QuICBUaGlzIHByb3ZpZGVzIGEgY2hh bGxlbmdlLXJlc3BvbnNlIG1lY2hhbmlzbSB0byBhdXRoZW50aWNhdGUgdXNlciBpZGVu dGl0eSBhbmQgcmVxdWlyZXMgdGhlIGVzdGFibGlzaG1lbnQgb2YgYSBzaGFyZWQgc2Vj cmV0IGJldHdlZW4gdGhlIHVzZXIgYW5kIHRoZSBob21lIGRhdGEgZ3JpZC4gIEFsbCBh dXRoZW50aWNhdGlvbnMgb2YgdXNlciBpZGVudGl0eSB3ZXJlIHBlcmZvcm1lZCBieSB0 aGUgdXNlcpJzIGhvbWUgZGF0YSBncmlkICh6b25lX2lkKS4NTXVsdGlwbGUgdmVyc2lv bnMgb2YgdGhlIFN0b3JhZ2UgUmVzb3VyY2UgYnJva2VyIHdlcmUgdXNlZCB3aXRoaW4g dGhlIGZlZGVyYXRpb24uIFNSQiB2ZXJzaW9uIDMuNC4xIHdhcyByZWxlYXNlZCBhdCB0 aGUgZW5kIG9mIEFwcmlsIDIwMDYgYW5kIGluY2x1ZGVkIGJ1ZyBmaXhlcyBmb3IgaGFu ZGxpbmcgZmlsZSBuYW1lcyB0aGF0IGNvbnRhaW5lZCBpbGxlZ2FsIGNoYXJhY3RlcnMg YW5kIGEgcGF0Y2ggZm9yIGludGVyLXpvbmUgY29tbXVuaWNhdGlvbi4gIFNSQiB2ZXJz aW9uIDMuNC4wIHdhcyBhbHNvIHVzZWQgYWxvbmcgd2l0aCB0aGUgaW50ZXItem9uZSBj b21tdW5pY2F0aW9uIHBhdGNoLiAgIEEgZGF0YSBncmlkIGZlZGVyYXRpb24gY2FuIHVz ZSBtdWx0aXBsZSB2ZXJzaW9ucyBvZiB0aGUgU1JCIGRhdGEgZ3JpZCB0ZWNobm9sb2d5 IGFzIGxvbmcgYXMgdGhlIFNSQiBjb21tdW5pY2F0aW9uIHByb3RvY29sIGlzIGNvbnNp c3RlbnQgYWNyb3NzIHRoZSBTUkIgdmVyc2lvbnMuICBIb3dldmVyIGl0IGlzIHByZWZl cmFibGUgdG8gdXNlIHRoZSBzYW1lIFNSQiB2ZXJzaW9uIGFjcm9zcyBhbGwgcGFydGlj aXBhdGluZyBkYXRhIGdyaWRzLg1Tb21lIG9mIHRoZSBwYXJ0aWNpcGF0aW5nIGRhdGEg Z3JpZHMgaW52ZXN0aWdhdGVkIHR1bmluZyB0aGUgZGF0YSB0cmFuc21pc3Npb24gcGVy Zm9ybWFuY2Ugd2l0aGluIHRoZSBmZWRlcmF0aW9uLiAgVGhpcyByZXF1aXJlZCBpbmNy ZWFzaW5nIHRoZSBudW1iZXIgb2YgcGFyYWxsZWwgSS9PIHN0cmVhbXMsIGluY3JlYXNp bmcgdGhlIHdpbmRvdyBzaXplIHVzZWQgZm9yIFRDUC9JUCB0cmFuc21pc3Npb25zLCBh bmQgaW5jcmVhc2luZyB0aGUgc3lzdGVtIGJ1ZmZlciBzaXplLiAgVGhlIG9wdGltYWwg d2luZG93IHNpemUgZGVwZW5kcyB1cG9uIHRoZSB3aWRlLWFyZWEtbmV0d29yayBsYXRl bmN5IGFuZCBpcyB1c3VhbGx5IHNldCB0byB0aGUgbnVtYmVyIG9mIG1lc3NhZ2VzIHRo YXQgY2FuIGJlIGluIGZsaWdodCBhY3Jvc3MgdGhlIG5ldHdvcmssIG9yIHRoZSByb3Vu ZC10cmlwIGxhdGVuY3kgdGltZXMgdGhlIG5ldHdvcmsgYmFuZHdpZHRoIGRpdmlkZWQg YnkgdGhlIG1lc3NhZ2Ugc2l6ZS4gICBJbmNyZWFzaW5nIHRoZSB3aW5kb3cgc2l6ZSBt ZWFucyBtb3JlIG1lc3NhZ2VzIGNhbiBiZSBpbiBmbGlnaHQgd2l0aGluIHRoZSBuZXR3 b3JrIGJlZm9yZSBhbiBhY2tub3dsZWRnZW1lbnQgaXMgcmVxdWlyZWQgb2Ygc3VjY2Vz c2Z1bCBtZXNzYWdlIHJlY2VwdGlvbi4gIFRoZSBzeXN0ZW0gYnVmZmVyIHNpemUgbXVz dCBiZSBsYXJnZSBlbm91Z2ggdG8gaG9sZCBjb3BpZXMgb2YgYWxsIG9mIHRoZSBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBzZW50LCBpbiBvcmRlciB0byBhbGxvdyByZXRyYW5z bWlzc2lvbiBpbiBjYXNlIG9mIGEgbWVzc2FnZSBjb3JydXB0aW9uLiAgRm9yIHJvdW5k LXRyaXAgbmV0d29yayBsYXRlbmNpZXMgb2YgMjAwIG1pbGxpc2Vjb25kcyBhbmQgYSBi YW5kd2lkdGggb2YgMSBHaWdhYml0L3NlY29uZCwgdGhlIHN5c3RlbSBidWZmZXIgc2l6 ZSBuZWVkcyB0byBiZSAyMDAgbWVnYWJpdHMgb3IgMjUgTWJ5dGVzLg1UaGUgbnVtYmVy IG9mIHBhcmFsbGVsIEkvL08gc3RyZWFtcyB3YXMgYWxzbyBpbmNyZWFzZWQgdG8gZW5h YmxlIGZ1bGwgdXNlIG9mIHRoZSBuZXR3b3JrIGJhbmR3aWR0aC4gIEZvciBleGFtcGxl LCB0aGUgQVUgZGF0YSBncmlkIGluIEF1c3RyYWxpYSBvcHRpbWl6ZWQgZGF0YSB0cmFu c21pc3Npb24gdG8gdGhlIEtFSyBkYXRhIGdyaWQgaW4gSmFwYW4uIA1JbiB0aGUgk3J1 bnNyYpQgc2NyaXB0LCB0aGV5IHNldCB0aGUgZGVmYXVsdCBudW1iZXIgb2YgcGFyYWxs ZWwgSS9PIGNoYW5uZWxzIHRvIA1NYXhUaHJlYWQ9MTYNU2l6ZVBlclRocmVhZD0yDVRo aXMgc3BlY2lmaWVkIHVwIHRvIDE2IHBhcmFsbGVsIEkvTyBzdHJlYW1zLiAgVGhlIFNS QiBzeXN0ZW0gc2VsZWN0ZWQgdGhlIG51bWJlciBvZiBwYXJhbGxlbCBJL08gc3RyZWFt cyBieSBkaXZpZGluZyB0aGUgZmlsZSBzaXplIG1lYXN1cmVkIGluIE1ieXRlcyBieSB0 aGUgU2l6ZVBlclRocmVhZC4gIFNtYWxsZXIgZmlsZXMgdXNlZCBhIHNtYWxsZXIgbnVt YmVyIG9mIHBhcmFsbGVsIEkvTyBzdHJlYW1zLCB3aXRoIGZpbGVzIGxhcmdlciB0aGFu IDMyIE1ieXRlcyBpbiBzaXplIHVzaW5nIDE2IHBhcmFsbGVsIEkvTyBjaGFubmVscy4N VGhleSByZXNldCBuZXR3b3JrIHBhcmFtZXRlcnMgb24gdGhlaXIgaG9zdCBiYXNlZCBv biB0aGUgcmVjb21tZW5kYXRpb25zIHB1Ymxpc2hlZCBieSB0aGUgR2xvYmFsIEdyaWQg Rm9ydW0gaW4gdGhlIHR1bmluZyBndWlkZToNEyBIWVBFUkxJTksgImh0dHA6Ly93d3cu cHNjLmVkdS9uZXR3b3JraW5nL3Byb2plY3RzL3RjcHR1bmUvIiABFGh0dHA6Ly93d3cu cHNjLmVkdS9uZXR3b3JraW5nL3Byb2plY3RzL3RjcHR1bmUvFSANVGhlIHBhcnRpY2lw YXRpbmcgZGF0YSBncmlkcyB3ZXJlIGxvY2F0ZWQgaW4gRXVyb3BlLCB0aGUgVVMsIGFu ZCB0aGUgRmFyIEVhc3QuICBFYWNoIGRhdGEgZ3JpZCBjaG9zZSB3aGljaCB2ZXJzaW9u IG9mIHRoZSBTdG9yYWdlIFJlc291cmNlIEJyb2tlciBzb2Z0d2FyZSAoU1JCKSB0byB1 c2UuICBUaGUgc3RlcHMgcmVxdWlyZWQgZm9yIGEgZGF0YSBncmlkIHRvIGpvaW4gdGhl IGZlZGVyYXRpb24gd2VyZToNUmVnaXN0ZXIgdGhlIFpvbmUgbmFtZSBmb3IgdGhlaXIg ZGF0YSBncmlkIGludG8gdGhlIFNSQiB6b25lLW5hbWUgYXV0aG9yaXR5LiAgVGhpcyBl bnN1cmVzIHRoYXQgZWFjaCBkYXRhIGdyaWQgaGFzIGEgdW5pcXVlIHpvbmUgbmFtZS4N RmVkZXJhdGUgdGhlaXIgZGF0YSBncmlkIHdpdGggdGhlIGh1YiBkYXRhIGdyaWQgYXQg U0RTQy4gIFRoZSBodWIgZGF0YSBncmlkIHdhcyBsb2NhdGVkIGF0IFNEU0MgYW5kIGNh bGxlZCBTRFNDLUdHRi4NVGhlIG9wZXJhdGlvbnMgcmVxdWlyZWQgdG8gZXN0YWJsaXNo IHRoZSBkYXRhIGdyaWQgZmVkZXJhdGlvbiBoYWQgdG8gYmUgcnVuIGJ5IHRoZSBkYXRh IGdyaWQgYWRtaW5pc3RyYXRvciBvZiBlYWNoIGRhdGEgZ3JpZCwgZnJvbSB0aGVpciBT UkIgZGF0YSBncmlkIGFkbWluaXN0cmF0b3IgYWNjb3VudC4gIFRoZSBleHBsaWNpdCBz dGVwcyBpbmNsdWRlZDoNRXhlY3V0ZSB0aGUgIlN0b2tlbiBab25lIiBjb21tYW5kIHRv IGxpc3QgdGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZWlyIGxvY2FsIFNSQiBkYXRhIGdy aWQgYW5kIHN0b3JlIHRoZSByZXN1bHQgaW4gYSBmaWxlLiAgQW4gZXhhbXBsZSBvZiB0 aGUgb3V0cHV0IGZyb20gdGhlIJNTdG9rZW4gWm9uZZQgY29tbWFuZCBpcyBsaXN0ZWQg YmVsb3cgaW4gRmlndXJlIDEuDVNlbmQgdGhlIGZpbGUgdG8gZWFjaCBkYXRhIGdyaWQg dGhhdCB0aGUgZGF0YSBncmlkIGFkbWluaXN0cmF0b3Igd2FudGVkIGluIHRoZWlyIGZl ZGVyYXRpb24uICBBdCBhIG1pbmltdW0sIHdlIHJlcXVlc3RlZCB0aGF0IHRoZXkgc2Vu ZCB0aGUgaW5mb3JtYXRpb24gdG8gU0RTQyBmb3IgZmVkZXJhdGlvbiB3aXRoIHRoZSBT RFNDLUdHRiBkYXRhIGdyaWQuICBUaGUgZGF0YSBncmlkIGFkbWluaXN0cmF0b3IgYXQg U0RTQyB0aGVuIHNlbnQgdGhlIGNvcnJlc3BvbmRpbmcgaW5mb3JtYXRpb24gZmlsZSBh Ym91dCB0aGUgU0RTQy1HR0YgZGF0YSBncmlkIHRvIHRoZSByZW1vdGUgZGF0YSBncmlk IGFkbWluaXN0cmF0b3IuDUVhY2ggZGF0YSBncmlkIGFkbWluaXN0cmF0b3IgdGhlbiBy YW4gdGhlIHpvbmVpbmdlc3QucGwgcGVybCBzY3JpcHQgbG9jYXRlZCBpbiB0aGUgLi9N Q0FUIGRpcmVjdG9yeS4gVGhpcyBzY3JpcHQgcmVnaXN0ZXJlZCB0aGUgem9uZSBpbmZv cm1hdGlvbiBpbnRvIHRoZSBsb2NhbCBkYXRhIGdyaWQuICBBdCB0aGlzIHBvaW50LCB0 aGUgZGF0YSBncmlkcyBjb3VsZCBjb21tdW5pY2F0ZSBhbmQgcmVzcG9uZCB0byByZXF1 ZXN0cyBmcm9tIHRoZSByZW1vdGUgZGF0YSBncmlkLiAgSG93ZXZlciwgbm8gdXNlciBp bmZvcm1hdGlvbiBoYWQgYmVlbiBjcm9zcy1yZWdpc3RlcmVkLiAgQSB1c2VyIGZyb20g dGhlIFNEU0MtR0dGIGRhdGEgZ3JpZCBjb3VsZCBvbmx5IGFjY2VzcyBwdWJsaWMgaW5m b3JtYXRpb24gaW4gdGhlIHJlbW90ZSBkYXRhIGdyaWQuDVRvIGFsbG93IGEgdXNlciBm cm9tIHRoZSBTRFNDLUdHRiBkYXRhIGdyaWQgdG8gYmUgYWJsZSB0byBhY2Nlc3MgY29u dHJvbGxlZCBkYXRhIHdpdGhpbiB0aGUgcmVtb3RlIGRhdGEgZ3JpZCwgdGhlIGlkZW50 aXR5IG9mIHRoZSB1c2VyIGhhZCB0byBiZSByZWdpc3RlcmVkIGludG8gdGhlIHJlbW90 ZSBkYXRhIGdyaWQuICBUd28gU1JCIGNvbW1hbmRzIHdlcmUgZXhlY3V0ZWQgYnkgdGhl IGRhdGEgZ3JpZCBhZG1pbmlzdHJhdG9yIGF0IHRoZSByZW1vdGUgZGF0YSBncmlkIHRv IHJlZ2lzdGVyIHRoZSBpZGVudGl0eSBvZiBhIHVzZXIgY2FsbGVkIJNnZ2ZzZHNjlCBm cm9tIHRoZSBTRFNDLUdHRiBkYXRhIGdyaWQgaW50byB0aGUgcmVtb3RlIGRhdGEgZ3Jp ZDoNDSAgICBTaW5nZXN0dXNlciBnZ2ZzZHNjIHBhc3N3ZHh4eCBzZHNjIHN0YWZmICAn JyAnJyAnJyAnJyAnJw0gICAgU3pvbmUgLVUgU0RTQy1HR0YgZ2dmc2RzYyBzZHNjDQ1U aGUgZmlyc3QgY29tbWFuZCBlc3RhYmxpc2hlZCBhIHVzZXIgbmFtZSCTZ2dmc2RzY5Qg d2l0aGluIHRoZSByZW1vdGUgZGF0YSBncmlkLiAgVGhlIHNlY29uZCBjb21tYW5kIGFz c2lnbmVkIHRoaXMgdXNlciB0byB0aGUgk1NEU0MtR0dGlCBkYXRhIHpvbmUuICBBZnRl ciB0aGVzZSBzdGVwcywgdGhlIHVzZXIgk2dnZnNkc2OUIGZyb20gdGhlIJNTRFNDLUdH RpQgZGF0YSBncmlkIGNvdWxkIGxvZyBpbnRvIHRoZSByZW1vdGUgZGF0YSBncmlkIGFu ZCBhY2Nlc3MgZmlsZXMgZm9yIHdoaWNoIGhpcyB1c2VyIG5hbWUgaGFkIGJlZW4gZ3Jh bnRlZCByZWFkIHBlcm1pc3Npb24uICBBbHNvLCB0aGUgcHJvY2VzcyBjcmVhdGVkIGEg c3ViLWRpcmVjdG9yeSBpbnRvIHdoaWNoIHRoZSCTZ2dmc2RzY5QgdXNlciBjb3VsZCBz dG9yZSBoaXMgb3IgaGVyIG93biBmaWxlcy4NRmluYWxseSwgdGhlIHJlbW90ZSBkYXRh IGdyaWQgYWRtaW5pc3RyYXRvciBzcGVjaWZpZWQgYSBsb2dpY2FsIHN0b3JhZ2UgcmVz b3VyY2UgbmFtZSB3aGVyZSBmaWxlcyB3b3VsZCBhY3R1YWxseSBiZSB3cml0dGVuLiAg Tm90ZSB0aGF0IHRoaXMgbWVhbnMgdGhhdCBldmVuIHdpdGggdGhlIGNyZWF0aW9uIG9m IGFuIGFjY291bnQgaW4gdGhlIHJlbW90ZSBkYXRhIGdyaWQsIHBlcm1pc3Npb24gc3Rp bGwgaGFzIHRvIGJlIGdpdmVuIGZvciB0aGUgbmV3IHVzZXIgdG8gd3JpdGUgdG8gc3Bl Y2lmaWVkIHN0b3JhZ2Ugc3lzdGVtcy4NDA1UYWJsZSAyLiAgRGF0YSBHcmlkcyB0aGF0 IFBhcnRpY2lwYXRlZCBpbiB0aGUgR0dGIFN0b3JhZ2UgUmVzb3VyY2UgQnJva2VyIEZl ZGVyYXRpb24gRGVtb25zdHJhdGlvbg1EYXRhIEdyaWQHQ291bnRyeQdTUkIgdmVyc2lv bgdEZW1vIHVzZXIgZ2dmc2RzYwdTUkIgWm9uZSBuYW1lB1N0b3JhZ2UgUmVzb3VyY2Ug TG9naWNhbCBOYW1lB1RyYW5zZmVyDU1CL3NlYwcHQVBBQwdBdXN0cmFsaWEHMy40LjAt UAd5ZXMHQVUHU3RvcmVEZW1vUmVzY19BVQczLjkHB05PQU8HQ2hpbGUvVVMHMy40LjEH eWVzB25vYW8tbHMtdDMtejEHbm9hby1scy10My1mcwcHB0NoaW5hR3JpZAdDaGluYQdD R1NQLUlJByhzb2Z0d2FyZSkHBwcHB0lOMlAzB0ZyYW5jZQczLjQuMC1QB3llcwdjY2lu MnAzB0x5b25GUzQHWzI1Ll0HB0RFSVNBB0l0YWx5BzMuNC4wLVAHeWVzB0RFSVNBB2Rl bW8tY2luZWNhBwcHS0VLB0phcGFuBzMuNC4wLVAHeWVzB0tFSy1DUkMHcnNyMDEtdWZz BzcuNAcHU0FSQQdOZXRoZXJsYW5kcwczLjQuMC1QB3llcwdTQVJBB1NhcmFTdG9yZQcH B0lCB05ldyBaZWFsYW5kBzMuNC4xB3llcwdhdWNrbGFuZFpvbmUHYXVja2xhbmRSZXNj BygwLjMpBwdBU0dDB1RhaXdhbgczLjQuMC1QB3llcwdUV0dyaWQHU0RTQy1HR0ZfTFJT MQcoMC4xKQcHTkNIQwdUYWl3YW4HMy40LjAtUAd5ZXMHZWNvZ3JpZAdnZ2YtdGVzdAcH B1JBTAdVSwczLjQuMC1QB3llcwd0ZG1nMnpvbmUHBwcHSUIHVUsHMy40LjEHeWVzB2F2 b25ab25lB2F2b25SZXNjBwcHV3VuR3JpZAdVSwczLjMuMQcoaGFyZHdhcmUpB1NEU0Mt d3VuB3Nmcy10YXBlBwcHUHVyZHVlB1VTBzMuNC4wLVAHeWVzB1B1cmR1ZQd1eFJlc2Mx B3syLjV9BwdUZXJhZ3JpZAdVUwczLjQuMQd5ZXMHU0RTQy1HR0YHc2ZzLWRpc2sHBwdV IE1kB1VTBzMuNC4wLVAHeWVzB3VtaWFjcwduYXJhc3JiMDItdW5peDEHBwcMQWZ0ZXIg dGhlIGlzc3Vpbmcgb2YgdGhlc2UgY29tbWFuZHMgYnkgdGhlIHJlbW90ZSBkYXRhIGdy aWQgYWRtaW5pc3RyYXRvciwgdGhlIJNnZ2ZzZHNjlCBhY2NvdW50IHdhcyBhYmxlIHRv IGJyb3dzZSBmaWxlcyBpbiB0aGUgcmVtb3RlIGRhdGEgZ3JpZCwgcmVhZCBmaWxlcyBm b3Igd2hpY2ggYWNjZXNzIHBlcm1pc3Npb25zIHdlcmUgZW5hYmxlZCwgYW5kIHdyaXRl IGZpbGVzIHRvIHRoZSByZW1vdGUgc3RvcmFnZSBzeXN0ZW0uICAgV2hlbiB0aGUgdGVz dCB1c2VyIGFjY2Vzc2VkIGEgcmVtb3RlIGRhdGEgZ3JpZCwgc2F5IEFVLCB0aGUgQVUg ZGF0YSBncmlkIHNlbnQgYW4gYXV0aGVudGljYXRpb24gcmVxdWVzdCB0byB0aGUgaG9t ZSBkYXRhIGdyaWQgYXQgU0RTQy4gIElmIHRoZSBhdXRoZW50aWNhdGlvbiB3YXMgdmFs aWRhdGVkLCB0aGVuIHRoZSBBVSBkYXRhIGdyaWQgYXBwbGllZCBhY2Nlc3MgY29udHJv bHMgdG8gdGhlIJNnZ2ZzZHNjlCB1c2VyIHRvIGRlY2lkZSB3aGljaCBvcGVyYXRpb25z IHdlcmUgYWxsb3dlZC4gIEFjY2VzcyBjb250cm9scyB3ZXJlIGFwcGxpZWQgYnkgdGhl IHJlbW90ZSBkYXRhIGdyaWQgb24gZmlsZXMsIHN0b3JhZ2UgcmVzb3VyY2VzLCBhbmQg bWV0YWRhdGEuDURhdGEgdHJhbnNmZXIgdGVzdHMgd2VyZSBjb25kdWN0ZWQgYmV0d2Vl biB0aGUgcmVtb3RlIGRhdGEgZ3JpZCBhbmQgdGhlIFNEU0MtR0dGIGRhdGEgZ3JpZC4g IFRoZSBwZXJmb3JtYW5jZSB3YXMgaGlnaGx5IGRlcGVuZGVudCBvbiB0aGUgbnVtYmVy IG9mIHBhcmFsbGVsIEkvTyBzdHJlYW1zIHVzZWQgZm9yIHRoZSB0cmFuc2ZlciBhbmQg dGhlIHNpemUgb2YgdGhlIHN5c3RlbSBidWZmZXIsIGVzcGVjaWFsbHkgZm9yIGludGVy bmF0aW9uYWwgbGlua3MuICBUd28gdHlwZXMgb2YgZGF0YSB0cmFuc2ZlciB0ZXN0cyB3 ZXJlIGNvbmR1Y3RlZC4gIFRoZSBudW1iZXJzIGluIHBhcmVudGhlc2VzIGFyZSB1bnR1 bmVkIHRyYW5zZmVycywgdXNpbmcgb25seSA0IEkvTyBjaGFubmVscy4gIFRoZSBvdGhl ciBudW1iZXJzIHVzZWQgZWl0aGVyIDggb3IgMTYgSS9PIGNoYW5uZWxzLCBhbmQgaW5j cmVhc2VkIHRoZSBzeXN0ZW0gYnVmZmVyIHNpemUgdG8gc3VwcG9ydCBhIGxhcmdlciBU Q1AvSVAgd2luZG93IHNpemUuICBUaGUgcmVzdWx0cyBhcmUgc2hvd24gaW4gVGFibGUg Mi4NVGhlIGF0dGVtcHQgdG8gZmVkZXJhdGUgZGF0YSBncmlkcyBzdWNjZWVkZWQgd2l0 aCBmb3VydGVlbiBvZiBzaXh0ZWVuIGluZGVwZW5kZW50IGRhdGEgZ3JpZHMuICBUaGUg dHdvIGRhdGEgZ3JpZHMgdGhhdCB3ZXJlIG5vdCBmZWRlcmF0ZWQgd2VyZSBkZXBlbmRl bnQgdXBvbiBlaXRoZXIgc29mdHdhcmUgb3IgaGFyZHdhcmUgdXBncmFkZXMuICBUaGUg Q2hpbmFHcmlkIGRhdGEgZ3JpZCB1c2VzIHNvZnR3YXJlIGRldmVsb3BlZCB3aXRoaW4g Q2hpbmEgdG8gbWFuYWdlIGRpc3RyaWJ1dGVkIGRhdGEgY29sbGVjdGlvbnMuICBUaGV5 IHBsYW5uZWQgdGhlIGRldmVsb3BtZW50IG9mIGFuIGludGVyZmFjZSB0aGF0IHdvdWxk IGJlIGFibGUgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgcHVibGlzaGVkIChKYXJnb24gSmF2 YSBjbGFzcyBsaWJyYXJ5KSBTUkIgcHJvdG9jb2wuICBUaGUgV1VOZ3JpZCB3YXMgdXBn cmFkaW5nIHRvIG5ldyBoYXJkd2FyZSBzeXN0ZW1zIGF0IHRoZSB0aW1lIG9mIHRoZSBk ZW1vbnN0cmF0aW9uLCBhbmQgbmVlZGVkIHRvIGNvbXBsZXRlIHRoZSB1cGdyYWRlIGJl Zm9yZSBwYXJ0aWNpcGF0aW5nLg1UaGUgY29tbXVuaWNhdGlvbiByYXRlcyB0aGF0IHdl cmUgc3VzdGFpbmVkIGJldHdlZW4gcGFydGljaXBhdGluZyBncmlkcyB3ZXJlIGhpZ2hs eSBkZXBlbmRlbnQgb24gdGhlIGNhcGFiaWxpdGllcyBvZiB0aGUgbmV0d29ya3MgdGhh dCBqb2luZWQgdGhlIGRhdGEgZ3JpZHMsIHRoZSBhbW91bnQgb2YgdHVuaW5nIHRoYXQg d2FzIHBlcmZvcm1lZCB0byBpbXByb3ZlIFRDUC9JUCBwZXJmb3JtYW5jZSwgYW5kIHRo ZSBhYmlsaXR5IG9mIHRoZSBlbmQgc3RvcmFnZSBzeXN0ZW1zIHRvIHJlYWQgYW5kIHdy aXRlIGRhdGEgYXQgYSBoaWdoIHJhdGUuICBUaGUgSU4yUDMgZGF0YSBncmlkIGlzIHBh cnQgb2YgdGhlIEJhQmFyIGhpZ2ggZW5lcmd5IHBoeXNpY3MgZGF0YSBncmlkIHdoaWNo IGlzIHVzZWQgdG8gcmVwbGljYXRlIGRhdGEgZnJvbSB0aGUgU3RhbmZvcmQgTGluZWFy IEFjY2VsZXJhdG9yIHRvIEx5b24sIEZyYW5jZS4gIFRoZXkgaGF2ZSB0dW5lZCB0aGVp ciBuZXR3b3JrIHRvIHN1c3RhaW4gZGF0YSB0cmFuc2ZlciByYXRlcyBvZiAyIFRlcmFi eXRlcyBwZXIgZGF5LiAgVGhlIGRhdGEgZ3JpZHMgdGhhdCBoYWQgbG93ZXIgdHJhbnNt aXNzaW9uIHJhdGVzIChpbiBwYXJlbnRoZXNlcykgaGFkIGRvbmUgbm8gbmV0d29yayB0 dW5pbmcgYW5kIGdvdCB2ZXJ5IGxvdyB0cmFuc21pc3Npb24gcmF0ZXMsIGNvbnNpc3Rl bnQgd2l0aCBhIFRDUC9JUCBwYWNrZXQgYWNrbm93bGVkZ2VtZW50IGFmdGVyIGV2ZXJ5 IHBhY2thZ2UgdHJhbnNtaXNzaW9uLg1UaGUgZXN0YWJsaXNobWVudCBvZiB0aGUgZGF0 YSBncmlkIGZlZGVyYXRpb24gcmVxdWlyZWQgc3Vic3RhbnRpYWwgc3VwcG9ydCBieSB0 aGUgU0RTQyBkYXRhIGdyaWQgYWRtaW5pc3RyYXRvci4gIFRoZSB0eXBlcyBvZiBwcm9i bGVtcyB0aGF0IHdlcmUgc2VlbiBpbmNsdWRlZDoNT3BlbmluZyBvZiBwb3J0cyBpbiBm aXJld2FsbHMgdG8gYWxsb3cgcGFyYWxsZWwgSS9PIHRyYW5zZmVycy4NU3BlY2lmaWNh dGlvbiBvZiB0aGUgSVAgYWRkcmVzc2VzIGFsbG93ZWQgdG8gc2VuZCBtZXNzYWdlcyBp bnRvIGEgbG9jYWwgdmlydHVhbCBwcml2YXRlIG5ldHdvcmsuDUV4ZWN1dGlvbiBvZiB0 aGUgY29tbWFuZHMgZnJvbSB0aGUgY29ycmVjdCBkYXRhIGdyaWQgYWRtaW5pc3RyYXRv ciBhY2NvdW50Lg1Fc3RhYmxpc2htZW50IG9mIGEgZGVmYXVsdCBsb2dpY2FsIHN0b3Jh Z2UgcmVzb3VyY2UgbmFtZSBvbnRvIHdoaWNoIHRoZSCTZ2dmc2RzY5QgdXNlciB3b3Vs ZCBiZSBhbGxvd2VkIHRvIHdyaXRlIGRhdGEuDUV4ZWN1dGlvbiBvZiB0aGUgY29tbWFu ZHMgdG8gYXNzb2NpYXRlIHRoZSCTZ2dmc2RzY5QgdXNlciB3aXRoIHRoZSBTRFNDIGRh dGEgZ3JpZCCTU0RTQy1HR0aULg1VcGdyYWRpbmcgdGhlIGxvY2FsIFNSQiB2ZXJzaW9u IHRvIGluY2x1ZGUgdGhlIGludGVyLXpvbmUgY29tbXVuaWNhdGlvbiBwYXRjaC4NU2V0 dGluZyBvZiBhY2Nlc3MgY29udHJvbHMgZm9yIHdoYXQgdGhlIJNnZ2ZzZHNjlCB1c2Vy IHdhcyBhbGxvd2VkIHRvIGRvLiAgQW4gZXhhbXBsZSBpcyB0aGF0IHNvbWUgb2YgdGhl IGRhdGEgZ3JpZHMgYWxsb3dlZCB0aGUgk2dnZnNkc2OUIHVzZXIgdG8gbGlzdCBhbGwg b2YgdGhlIHVzZXJzIHBhcnRpY2lwYXRpbmcgZnJvbSB0aGVpciBkYXRhIGdyaWQuICBP dGhlciBkYXRhIGdyaWQgYWRtaW5pc3RyYXRvcnMgcmVzdHJpY3RlZCB0aGUgk2dnZnNk c2OUIHVzZXIgdG8gYWNjZXNzIHRvIGZpbGVzIHdpdGhpbiB0aGUgk2dnZnNkc2OUIHVz ZXIgaG9tZSBkaXJlY3RvcnkuDVRoZSBidWxrIG9mIHRoZSBzdXBwb3J0IGlzc3VlcyB3 ZXJlIHJlbGF0ZWQgdG8gY29vcmRpbmF0aW9uIGJldHdlZW4gZGF0YSBncmlkIGFkbWlu aXN0cmF0b3JzIHRvIGVzdGFibGlzaCB0aGUgbGlua3MgcmVxdWlyZWQgZm9yIHRoZSBk YXRhIGdyaWQgZmVkZXJhdGlvbi4gIE9uY2UgdGhlIGZlZGVyYXRpb24gd2FzIGNyZWF0 ZWQgYW5kIHRlc3RlZCwgdGhlIHJlbWFpbmluZyB0YXNrcyB3ZXJlIHJlbGF0ZWQgdG8g dHVuaW5nIHRoZSBuZXR3b3JrLg1GaWd1cmUgMSBzaG93cyB0aGUgaW5mb3JtYXRpb24g dGhhdCBuZWVkcyB0byBiZSBzaGFyZWQgYmV0d2VlbiB0aGUgZGF0YSBncmlkcy4gIFRo ZSBjcml0aWNhbCBwaWVjZXMgb2YgaW5mb3JtYXRpb24gYXJlIHRoZSBuYW1lIG9mIHRo ZSBkYXRhIGdyaWQgYXQgU0RTQyAoU0RTQy1HR0YpLCB0aGUgcG9ydF9udW1iZXIgYW5k IG5ldHByZWZpeCB3aGljaCBkZWZpbmUgdGhlIGNvbGxlY3Rpb24gYWRkcmVzcywgdGhl IGNob2ljZSBvZiBhdXRoZW50aWNhdGlvbiBzY2hlbWUgdGhhdCB3aWxsIGJlIHVzZWQg dG8gYXV0aGVudGljYXRlIHVzZXJzIChFTkNSWVBUMSBpcyBjaGFsbGVuZ2UtcmVzcG9u c2VzKSwgIGFuZCB0aGUgaWRlbnRpdHkgb2YgdGhlIGRhdGEgZ3JpZCBhZG1pbmlzdHJh dG9yIG9mIHRoZSBTRFNDLUdHRiBkYXRhIGdyaWQgKHVzZXJfbmFtZSBhbmQgZG9tYWlu X2Rlc2MpLiBJZiBhbnkgb2YgdGhlc2UgcGFyYW1ldGVycyBhcmUgbm90IHNldCBjb3Jy ZWN0bHksIHRoZSBmZWRlcmF0aW9uIHByb2Nlc3Mgd2lsbCBmYWlsLg0NDS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSBSRVNVTFRTIC0tLS0tLS0tLS0tLS0tDXpvbmVfaWQ6 IFNEU0MtR0dGDWxvY2FsX3pvbmVfZmxhZzogMQ1uZXRwcmVmaXg6IHNyYi1tY2F0LnNk c2MuZWR1Ok5VTEw6TlVMTA1wb3J0X251bWJlcjogNzU3OQ1hdXRoX3NjaGVtZTogRU5D UllQVDENZGlzdGluX25hbWU6IC9DPVVTL089TlBBQ0kvT1U9U0RTQy9VU0VSSUQ9c3Ji L0NOPVN0b3JhZ2UgUmVzb3VyY2UgQnJva2VyL0VtYWlsPXNyYkBzZHNjLmVkdQ16b25l X3N0YXR1czogMQ16b25lX2NyZWF0ZV9kYXRlOiAyMDAzLTA4LTAxLTAwLjAwLjAwDXpv bmVfbW9kaWZ5X2RhdGU6IDIwMDYtMDMtMjctMTMuNTguMjMNem9uZV9jb21tZW50czog U0RTQy1HR0Ygem9uZSBjcmVhdGVkIDMvMjcvMjAwNg16b25lX2NvbnRhY3Q6IHNyYkBz ZHNjLmVkdQ11c2VyX25hbWU6IHNyYg1kb21haW5fZGVzYzogc2RzYw1sb2NuX2Rlc2M6 IHNyYi1tY2F0DQ1GaWd1cmUgMS4gIE91dHB1dCBmcm9tIHRoZSCTU3Rva2VuIFpvbmUg Y29tbWFuZA0NDQ01LiBSdWxlLU9yaWVudGVkIERhdGEgU3lzdGVtcw0NVGhlIG1hbmFn ZW1lbnQgb2YgZGF0YSBncmlkcyBpcyBoYXJkLCByZXF1aXJlcyBleHBlcnRpc2UgaW4g ZGF0YWJhc2VzLCBuZXR3b3Jrcywgc2VjdXJpdHksIGFuZCBzdG9yYWdlIHN5c3RlbXMu ICBUaGUgcmVhc29uIHN1Y2ggYW4gZXh0ZW5zaXZlIGxldmVsIG9mIGV4cGVydGlzZSBp cyBuZWVkZWQgaXMgYmVjYXVzZSBhbnkgZmFpbHVyZSBieSB0aGUgc3lzdGVtcyBhY2Nl c3NlZCBieSB0aGUgZGF0YSBncmlkIGlzIHNlZW4gYXMgYSBmYWlsdXJlIG9mIHRoZSBk YXRhIGdyaWQuICBXaGlsZSB0aGUgU1JCIGRhdGEgZ3JpZCBwcm92aWRlcyB0b29scyB0 byBtYW5hZ2UgbWFueSB0eXBlcyBvZiByZW1vdGUgc3lzdGVtIGZhaWx1cmUsIHRoZSBj b21tYW5kcyB0aGF0IGRyaXZlIHRoZSB1c2Ugb2YgdGhlIHRvb2xzIG11c3QgYmUgZXhl Y3V0ZWQgYnkgdGhlIGRhdGEgZ3JpZCBhZG1pbmlzdHJhdG9yLiAgVGhpcyByZXF1aXJl cyBhbiBleHBlcnQgdW5kZXJzdGFuZGluZyBvZiBob3cgdGhlIHN5c3RlbSBpcyBjb25m aWd1cmVkLCB3aGF0IHR5cGVzIG9mIHByb2JsZW1zIGFyZSBjYXVzZWQgYnkgd2hpY2gg bGV2ZWwgb2YgdGhlIGludGVncmF0ZWQgYXJjaGl0ZWN0dXJlLCBhbmQgd2hhdCBvcGVy YXRpb25zIHNob3VsZCBiZSBwZXJmb3JtZWQgcGVyaW9kaWNhbGx5IHRvIHByb3RlY3Qg dGhlIHNoYXJlZCBkYXRhIGNvbGxlY3Rpb24uDUluIG9yZGVyIHRvIHNpbXBsaWZ5IHRo ZSBtYW5hZ2VtZW50IG9mIGRhdGEgZ3JpZHMsIHRoZSBhYmlsaXR5IHRvIGF1dG9tYXRl IHRoZSBhcHBsaWNhdGlvbiBvZiBtYW5hZ2VtZW50IHBvbGljaWVzIGlzIG5lZWRlZC4g IFRvd2FyZHMgdGhpcyBnb2FsLCBTRFNDIGlzIG5vdyBkZXZlbG9waW5nIGFuIGludGVn cmF0ZWQgcnVsZS1vcmllbnRlZCBkYXRhIHN5c3RlbSwgY2FsbGVkIGlST0RTLCB0byBz dXBwb3J0IHRoZSB2aXJ0dWFsaXphdGlvbiBvZiBtYW5hZ2VtZW50IHBvbGljaWVzIFsx MF0uICBUaGUgc3lzdGVtIGJ1aWxkcyB1cG9uIHRoZSBjb25jZXB0cyBvZiBzaGFyZWQg Y29sbGVjdGlvbnMgYW5kIGluZnJhc3RydWN0dXJlIGluZGVwZW5kZW5jZSwgYW5kIGFk ZHMgdGhlIGFiaWxpdHkgdG8gY2hhcmFjdGVyaXplIG1hbmFnZW1lbnQgcG9saWNpZXMg YXMgYWN0aW9ucyBvbiBtYW5hZ2VtZW50IG1ldGFkYXRhLiBFYWNoIG1hbmFnZW1lbnQg cG9saWN5IGlzIG1hcHBlZCB0byBhIHNldCBvZiBydWxlcy4gIEVhY2ggcnVsZSBzcGVj aWZpZXMgdGhlIGV4ZWN1dGlvbiBvZiBhbiBhc3NvY2lhdGVkIHNldCBvZiBhY3Rpb25z IHRoYXQgaW1wbGVtZW50IHRoYXQgcG9saWN5IGJhc2VkIHVwb24gdGhlIGF0dHJpYnV0 ZSB2YWx1ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBtYW5hZ2VtZW50IG1ldGFkYXRhLg1U aGlzIGFwcHJvYWNoIGlzIHBvc3NpYmxlIGlmIHRoZSBvcGVyYXRpb25zIHRoYXQgYXJl IHBlcmZvcm1lZCB1cG9uIHRoZSByZW1vdGUgZGF0YSBhcmUgd2VsbCBkZWZpbmVkLiAg Rm9ydHVuYXRlbHksIHRoZSBTUkIgZGF0YSBncmlkIHByb3ZpZGVzIGFuIGV4Y2VsbGVu dCBjaGFyYWN0ZXJpemF0aW9uIG9mIHRoZSBvcGVyYXRpb25zIHJlcXVpcmVkIGZvciBi dWlsZGluZyBjb2xsZWN0aW9ucywgZm9yIHNoYXJpbmcgZGF0YSBpbiBkYXRhIGdyaWRz LCBmb3IgcHVibGlzaGluZyBkYXRhIGluIGRpZ2l0YWwgbGlicmFyaWVzLCBmb3IgcHJl c2VydmluZyBkYXRhIGluIHBlcnNpc3RlbnQgYXJjaGl2ZXMsIGFuZCBmb3IgbWFuYWdp bmcgcmVhbC10aW1lIGRhdGEuICBUaGUgY3VycmVudCBzZXQgb2YgcmVtb3RlIG9wZXJh dGlvbnMgc3VwcG9ydGVkIGJ5IHRoZSBTUkIgY29ycmVzcG9uZCB0byB0aGUgc3RhbmRh cmQgb3BlcmF0aW9ucyB0aGF0IHNob3VsZCBiZSBwcm92aWRlZCBmb3IgdGhlIHJlbW90 ZSBtYW5pcHVsYXRpb24gb2YgZGF0YS4NVGhlIGlST0RTIHN5c3RlbSBtYXBzIGZyb20g dGhlIG1hbmFnZW1lbnQgbWV0YWRhdGEgdG8gdGhlIHN0YXRlIGluZm9ybWF0aW9uIG1h aW50YWluZWQgYnkgdGhlIFNSQiBmb3IgZWFjaCBkYXRhIGNvbGxlY3Rpb24sIGFuZCB0 aGVuIGFwcGxpZXMgdGhlIHJlbW90ZSBvcGVyYXRpb25zIGFzIHNwZWNpZmllZCBieSB0 aGUgYXBwcm9wcmlhdGUgcnVsZS4gIEFsbCByZW1vdGUgb3BlcmF0aW9ucyBhcmUgZW5j YXBzdWxhdGVkIGFzIG1pY3JvLXNlcnZpY2VzIHdob3NlIGV4ZWN1dGlvbiBpcyBjb250 cm9sbGVkIGJ5IGFuIGFzc29jaWF0ZWQgcnVsZSB0aGF0IGlzIGJhc2VkIG9uIG1ldGFk YXRhIChzdGF0ZSBpbmZvcm1hdGlvbikgbWFuYWdlZCBieSB0aGUgZGF0YSBncmlkLg1U aGUgdmlydHVhbGl6YXRpb24gb2YgbWFuYWdlbWVudCBwb2xpY2llcyBpcyBhY2NvbXBs aXNoZWQgYnkgbWFwcGluZyBmcm9tIHRoZSBtYW5hZ2VtZW50IG1ldGFkYXRhIGFuZCBk ZXNpcmVkIG9wZXJhdGlvbnMgdG8gdGhlIHN0YXRlIGluZm9ybWF0aW9uIGFuZCByZW1v dGUgbWljcm8tc2VydmljZXMgbWFuYWdlZCBieSB0aGUgZGF0YSBncmlkLiAgVGhlIGlS T0RTIHN5c3RlbSB1c2VzIGV4cGxpY2l0bHkgZGVmaW5lZCBydWxlcyB0byBleHByZXNz IHRoZSBtYXBwaW5nLiAgT25lIG9mIHRoZSBmZWF0dXJlcyBvZiB0aGlzIGFwcHJvYWNo IGlzIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gY2hhcmFjdGVyaXplIHRoZSBtYW5hZ2Vt ZW50IHBvbGljaWVzIGFzIHJ1bGVzLCBleHBvcnQgYSBkZXNjcmlwdGlvbiBvZiB0aGUg cnVsZXMgaW50byBhbm90aGVyIHJ1bGUtYmFzZWQgZGF0YSBzeXN0ZW0sIGFuZCBhcHBs eSB0aGUgc2FtZSBtYW5hZ2VtZW50IHBvbGljaWVzIGluIHRoZSBuZXcgZW52aXJvbm1l bnQuDUFub3RoZXIgZmVhdHVyZSBpcyB0aGF0IHRoZSByZXN1bHQgb2YgYXBwbHlpbmcg YW55IG1hbmFnZW1lbnQgcG9saWN5IGNhbiBiZSBleGFjdGx5IHNwZWNpZmllZCBieSBs aXN0aW5nIHRoZSBhc3NvY2lhdGVkIG1hbmFnZW1lbnQgbWV0YWRhdGEsIHRoZSBydWxl cyB0aGF0IHRoZW4gYXBwbHkgYW5kIHRoZSBkYXRhIGdyaWQgc3RhdGUgaW5mb3JtYXRp b24gdGhhdCBpcyB1cGRhdGVkIGFzIGEgcmVzdWx0IG9mIGFwcGx5aW5nIHRoZSBydWxl LiAgQSBzaW1wbGUgZXhhbXBsZSBpcyBhIG1hbmFnZW1lbnQgcG9saWN5IHRoYXQgc3Bl Y2lmaWVzIGEgZm9ybSBvZiBkaXNhc3RlciByZWNvdmVyeSB0aHJvdWdoIHVzZSBvZiBy ZXBsaWNhcy4gIFRoZSBtYW5hZ2VtZW50IHBvbGljeSBtZXRhZGF0YSB3b3VsZCBpbmNs dWRlIHRoZSBudW1iZXIgb2YgcmVwbGljYXMgdGhhdCBhcmUgZGVzaXJlZCwgdGhlIGRp c3RyaWJ1dGlvbiBvZiB0aGUgcmVwbGljYXMgYWNyb3NzIHN0b3JhZ2Ugc3lzdGVtcywg YW5kIHRoZSBmcmVxdWVuY3kgd2l0aCB3aGljaCB0aGUgcmVwbGljYXMgYXJlIHN5bmNo cm9uaXplZC4gIEZvciBhIHJlZ2lzdHJhdGlvbiBjb21tYW5kLCB0aGUgaVJPRFMgcnVs ZSB3b3VsZCB0aGVuIGNoZWNrIHRoZSBtYW5hZ2VtZW50IG1ldGFkYXRhLCBjcmVhdGUg dGhlIGNvcnJlY3QgbnVtYmVyIG9mIHJlcGxpY2FzLCBhbmQgZGlzdHJpYnV0ZSB0aGVt IHRvIHRoZSBkZXNpcmVkIHN0b3JhZ2Ugc3lzdGVtcy4gICBBbiBpbnRlZ3JpdHkgdmFs aWRhdGlvbiBydWxlIHdvdWxkIGNoZWNrIGVhY2ggc3ViLWNvbGxlY3Rpb24gZm9yIHdo ZXRoZXIgdGhlIG1pbmltYWwgdGltZSBwZXJpb2QgaGFkIHBhc3NlZCwgYW5kIHdvdWxk IHRoZW4gc3luY2hyb25pemUgdGhlIHJlcGxpY2FzIG9mIHRoZSBmaWxlcyB3aXRoaW4g dGhlIHN1Yi1jb2xsZWN0aW9uLg1BZGRpdGlvbmFsIG1hbmFnZW1lbnQgcnVsZXMgY2Fu IGJlIGNyZWF0ZWQgdG8gdmFsaWRhdGUgdGhlIGFzc2Vzc21lbnQgY3JpdGVyaWEgZm9y IGEgdHJ1c3RlZCBkaWdpdGFsIHJlcG9zaXRvcnkgWzExLDEyXSwgb3IgbWFuYWdlIHRo ZSBzdGVwcyByZXF1aXJlZCBmb3IgYSBkYXRhIGdyaWQgZmVkZXJhdGlvbiwgb3IgbWFu YWdlIHRoZSBzdGVwcyByZXF1aXJlZCB0byByZXBsaWNhdGUgYSBjb2xsZWN0aW9uIGJl dHdlZW4gdHdvIGRhdGEgZ3JpZHMuDQ02LiBBY2tub3dsZWRnZW1lbnRzDQ1UaGlzIHBy b2plY3Qgd2FzIHN1cHBvcnRlZCBieSB0aGUgTmF0aW9uYWwgQXJjaGl2ZXMgYW5kIFJl Y29yZHMgQWRtaW5pc3RyYXRpb24gdW5kZXIgTlNGIGNvb3BlcmF0aXZlIGFncmVlbWVu dCAwNTIzMzA3IHRocm91Z2ggYSBzdXBwbGVtZW50IHRvIFNDSSAwNDM4NzQxLCCTQ3li ZXJpbmZyYXN0cnVjdHVyZTsgRnJvbSBWaXNpb24gdG8gUmVhbGl0eZQsIGFuZCBieSB0 aGUgTmF0aW9uYWwgU2NpZW5jZSBGb3VuZGF0aW9uIGdyYW50IElUUiAwNDI3MTk2LCCT Q29uc3RyYWludC1iYXNlZCBLbm93bGVkZ2UgU3lzdGVtcyBmb3IgR3JpZHMsIERpZ2l0 YWwgTGlicmFyaWVzLCBhbmQgUGVyc2lzdGVudCBBcmNoaXZlc5QuIFRoZSB2aWV3cyBh bmQgY29uY2x1c2lvbnMgY29udGFpbmVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRob3Nl IG9mIHRoZSBhdXRob3JzIGFuZCBzaG91bGQgbm90IGJlIGludGVycHJldGVkIGFzIHJl cHJlc2VudGluZyB0aGUgb2ZmaWNpYWwgcG9saWNpZXMsIGVpdGhlciBleHByZXNzZWQg b3IgaW1wbGllZCwgb2YgdGhlIE5hdGlvbmFsIFNjaWVuY2UgRm91bmRhdGlvbiwgdGhl IE5hdGlvbmFsIEFyY2hpdmVzIGFuZCBSZWNvcmRzIEFkbWluaXN0cmF0aW9uLCBvciB0 aGUgVS5TLiBnb3Zlcm5tZW50Lg1UaGUgR2xvYmFsIEdyaWQgRm9ydW0gZGF0YSBncmlk IGludGVyb3BlcmFiaWxpdHkgZGVtb25zdHJhdGlvbiByZWxpZWQgdXBvbiB0aGUgYWJs ZSBhc3Npc3RhbmNlIG9mIFN0ZXBoZW4gTWNNYWhvbiBmcm9tIHRoZSBBdXN0cmFsaWFu IFBhcnRuZXJzaGlwIGZvciBBZHZhbmNlZCBDb21wdXRpbmcsIEVyaWMgWWVuIGFuZCBX ZWktTG9uZyBVZW5nIGZyb20gdGhlIEFjYWRlbWlhIFNpbmljYSBHcmlkIENvbXB1dGlu ZyBDZW50cmUsIERhbmllbCBIYW5sb24gZnJvbSB0aGUgSW50ZWdyYXRpdmUgQmlvbG9n eSBkYXRhIGdyaWQsIEdpdXNlcHBlIEZpYW1lbmkgZnJvbSB0aGUgRGlzdHJpYnV0ZWQg RXVyb3BlYW4gSW5mcmFzdHJ1Y3R1cmUgZm9yIFN1cGVyY29tcHV0aW5nIEFwcGxpY2F0 aW9ucywgSmVhbi1ZdmVzIE5pZWYgZnJvbSB0aGUgSW5zdGl0dXRlIE5hdGlvbmFsIGRl IFBoeXNpcXVlIE51Y2xlYWlyZSBldCBkZSBQaHlzaXF1ZSBkZXMgUGFydGljdWxlcywg WW9zaGltaSBJaWRhIGZyb20gdGhlIEtFSyBOYXRpb25hbCBMYWJvcmF0b3J5IGZvciBI aWdoIEVuZXJneSBQaHlzaWNzLCBIc3UtTWVpIENob3UgZnJvbSB0aGUgVGFpd2FuIE5h dGlvbmFsIENlbnRlciBmb3IgSGlnaC1QZXJmb3JtYW5jZSBDb21wdXRpbmcsIElyZW5l IEJhcmcgZnJvbSB0aGUgTmF0aW9uYWwgT3B0aWNhbCBBc3Ryb25vbXkgT2JzZXJ2YXRv cnksIExhbiBaaGFvIGZyb20gdGhlIFB1cmR1ZSBVbml2ZXJzaXR5IGRhdGEgZ3JpZCwg QWRpbCBIYXNhbiBmcm9tIHRoZSBSdXRoZXJmb3JkIEFwcGxldG9uIExhYm9yYXRvcnkg ZGF0YSBncmlkLCBCYXJ0IEhldXBlcnMgZnJvbSB0aGUgTmV0aGVybGFuZHMgU0FSQSBk YXRhIGdyaWQsIGFuZCBNaWtlIFNtb3J1bCBmcm9tIHRoZSBVbml2ZXJzaXR5IG9mIE1h cnlsYW5kIGRhdGEgZ3JpZC4NDTcuIFJlZmVyZW5jZXMNDVsxXSBSLiBNb29yZSwgTS4g V2FuLCBhbmQgQS4gUmFqYXNla2FyLCCTU3RvcmFnZSBSZXNvdXJjZSBCcm9rZXI6IEdl bmVyaWMgU29mdHdhcmUgSW5mcmFzdHJ1Y3R1cmUgZm9yIE1hbmFnaW5nIEdsb2JhbGx5 IERpc3RyaWJ1dGVkIERhdGGULCBQcm9jZWVkaW5ncyBvZiBJRUVFIENvbmZlcmVuY2Ug b24gR2xvYmFsbHkgRGlzdHJpYnV0ZWQgRGF0YSwgSUVFRSBDb21wdXRlciBTb2NpZXR5 LCBQaXNjYXRhd2F5IE5ldyBKZXJzZXksIEp1bmUgMjgsIDIwMDUsIHBwLiA2NS02OS4g DQ1bMl0gSS4gRm9zdGVyLCBhbmQgQy4gS2Vzc2VsbWFuLCCTVGhlIEdyaWQ6IEJsdWVw cmludCBmb3IgYSBOZXcgQ29tcHV0aW5nIEluZnJhc3RydWN0dXJlLJQgQ2hhcHRlciA1 LCCTRGF0YSBJbnRlbnNpdmUgQ29tcHV0aW5nLJQgTW9yZ2FuIEthdWZtYW5uLCBTYW4g RnJhbmNpc2NvLCAxOTk5LCBwcC4gMTA1LTEyOS4NDVszXSBSLiwgTW9vcmUsIEEuIFJh amFzZWthciwgYW5kIE0uIFdhbiwgk1N0b3JhZ2UgUmVzb3VyY2UgQnJva2VyIEdsb2Jh bCBEYXRhIEdyaWRzlCwgUHJvY2VlZGluZ3MgTkFTQSAvIElFRUUgTVNTVDIwMDYsIEZv dXJ0ZWVudGggTkFTQSBHb2RkYXJkIC8gVHdlbnR5LXRoaXJkIElFRUUgQ29uZmVyZW5j ZSBvbiBNYXNzIFN0b3JhZ2UgU3lzdGVtcyBhbmQgVGVjaG5vbG9naWVzLCBJRUVFIENv bXB1dGVyIFNvY2lldHksIFBpc2NhdGF3YXkgTmV3IEplcnNleSwgQXByaWwgMjAwNi4N DVs0XSBSLiBNb29yZSwgk0J1aWxkaW5nIFByZXNlcnZhdGlvbiBFbnZpcm9ubWVudHMg d2l0aCBEYXRhIEdyaWQgVGVjaG5vbG9neZQsIEFtZXJpY2FuIEFyY2hpdmlzdCwgVGhl IFNvY2lldHkgb2YgQW1lcmljYW4gQXJjaGl2aXN0cywgQ2hpY2FnbyBJbGxpbm9pcywg SnVseSAyMDA2LCB2b2wuIDY5LCBuby4gMSwgcHAuIDEzOS0xNTguDQ1bNV0gUi4gTW9v cmUsIFIuIE1hcmNpYW5vLCCTVGVjaG5vbG9naWVzIGZvciBQcmVzZXJ2YXRpb26ULCBj aGFwdGVyIDYgaW4gk01hbmFnaW5nIEVsZWN0cm9uaWMgUmVjb3Jkc5QsIGVkaXRlZCBi eSBKdWxpZSBNY0xlb2QgYW5kIENhdGhlcmluZSBIYXJlLCBGYWNldCBQdWJsaXNoaW5n LCBVSywgT2N0b2JlciAyMDA1Lg0NWzZdIEMuIEJhcnUsIFIsIE1vb3JlLCBBLiBSYWph c2VrYXIsIGFuZCBNLiBXYW4sICJUaGUgU0RTQyBTdG9yYWdlIFJlc291cmNlIEJyb2tl ciyUIFByb2MuIENBU0NPTic5OCBDb25mZXJlbmNlLCBUb3JvbnRvLCBDYW5hZGEsIE5v di4zMC1EZWMuMywgMTk5OCwgcC4gNS4NDVs3XSBBLiBSYWphc2VrYXIsIE0uIFdhbiwg Ui4gTW9vcmUsIGFuZCBXLiBTY2hyb2VkZXIsIJNEYXRhIEdyaWQgRmVkZXJhdGlvbpQs IDIwMDQgSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlIG9uIFBhcmFsbGVsIGFuZCBEaXN0 cmlidXRlZCBQcm9jZXNzaW5nIFRlY2huaXF1ZXMgYW5kIEFwcGxpY2F0aW9ucyAtIFNw ZWNpYWwgU2Vzc2lvbiBvbiBOZXcgVHJlbmRzIGluIERpc3RyaWJ1dGVkIERhdGEgQWNj ZXNzLCBMYXMgVmVnYXMgTmV2YWRhLCBKdW5lIDIwMDQuDQ1bOF0gUi4gTW9vcmUsIEYu IEJlcm1hbiwgQi4gU2Nob3R0bGFlbmRlciwgQS4gUmFqYXNla2FyLCBELiBNaWRkbGV0 b24sIGFuZCBKLiBKYUphLCCTQ2hyb25vcG9saXM6IEZlZGVyYXRlZCBEaWdpdGFsIFJl cG9zaXRvcmllcyBBY3Jvc3MgVGltZSBhbmQgU3BhY2WULCBQcm9jZWVkaW5ncyBvZiBJ RUVFIENvbmZlcmVuY2Ugb24gR2xvYmFsbHkgRGlzdHJpYnV0ZWQgRGF0YSwgSUVFRSBD b21wdXRlciBTb2NpZXR5LCBQaXNjYXRhd2F5IE5ldyBKZXJzZXksIEp1bmUgMjgsIDIw MDUsIHBwLiAxNzEtMTc2Lg0NWzldIFIuIE1vb3JlLCBBLiBSYWphc2VrYXIsIGFuZCBN LiBXYW4sIJNEYXRhIEdyaWRzLCBEaWdpdGFsIExpYnJhcmllcyBhbmQgUGVyc2lzdGVu dCBBcmNoaXZlczogQW4gSW50ZWdyYXRlZCBBcHByb2FjaCB0byBQdWJsaXNoaW5nLCBT aGFyaW5nIGFuZCBBcmNoaXZpbmcgRGF0YZQsIFNwZWNpYWwgSXNzdWUgb2YgdGhlIFBy b2NlZWRpbmdzIG9mIHRoZSBJRUVFIG9uIEdyaWQgQ29tcHV0aW5nLCBJRUVFIENvbXB1 dGVyIFNvY2lldHksIFBpc2NhdGF3YXkgbmV3IEplcnNleSwgTWFyY2ggMjAwNSwgVm9s LiA5MywgTm8uMywgcHAuIDU3OC01ODguDQ1bMTBdIEEuIFJhamFzZWthciwgTS4gV2Fu LCBSLiBNb29yZSwgYW5kIFcuIFNjaHJvZWRlciwgk0EgUHJvdG90eXBlIFJ1bGUtYmFz ZWQgRGlzdHJpYnV0ZWQgRGF0YSBNYW5hZ2VtZW50IFN5c3RlbZQsIEhpZ2ggUGVyZm9y bWFuY2UgRGlzdHJpYnV0ZWQgQ29tcHV0aW5nIHdvcmtzaG9wIG9uIJNOZXh0IEdlbmVy YXRpb24gRGlzdHJpYnV0ZWQgRGF0YSBNYW5hZ2VtZW50lCwgUGFyaXMsIEZyYW5jZSwg TWF5IDIwMDYuDQ1bMTFdIFIuIE1vb3JlLCBhbmQgTS4gU21pdGgsIJNBc3Nlc3NtZW50 IG9mIFJMRyBUcnVzdGVkIERpZ2l0YWwgUmVwb3NpdG9yeSBSZXF1aXJlbWVudHMslCBK b2ludCBDb25mZXJlbmNlIG9uIERpZ2l0YWwgTGlicmFyaWVzIHdvcmtzaG9wIG9uICJE aWdpdGFsIEN1cmF0aW9uICYgVHJ1c3RlZCBSZXBvc2l0b3JpZXM6IFNlZWtpbmcgU3Vj Y2Vzc5QsIENoYXBlbCBIaWxsLCBOb3J0aCBDYXJvbGluYSwgSnVuZSAyMDA2Lg0NWzEy XSBSTEcvTkFSQSBBdWRpdCBDaGVja2xpc3QgZm9yIENlcnRpZnlpbmcgRGlnaXRhbCBS ZXBvc2l0b3JpZXMsIBMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnJsZy5vcmcvZW4vcGFn ZS5waHA/UGFnZV9JRD0yMDc2IiABFGh0dHA6Ly93d3cucmxnLm9yZy9lbi9wYWdlLnBo cD9QYWdlX0lEPTIwNzYVDQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAALgYAADAGAADKBgAAzQYA ANYGAADXBgAAAQkAAKcUAACsGwAArRsAANMbAADUGwAA1RsAAO0bAADuGwAACRwAADoc AAAQHQAARx0AALkeAADXHgAApCQAAOAkAACXJQAAtCUAAO8mAAAJJwAANiwAAFwsAACr LgAAvi4AALo2AADVNgAA9TgAAPY4AAAcOQAAHTkAAB45AAA2OQAANzkAAGI5AAB6OQAA gTsAAJc7AAA7QQAAU0EAAIlNAACmTQAAcGoAAJdqAACWbAAAs2wAAM9tAADqbQAAFXoA ACR6AAB4fwAAo38AAO6FAAD/hQAAhocAAJ2HAACQiAAAoogAAOqJAAD4iQAAsJIAALKS AAAulAAAWZQAANqkAADbpAAAGKUAABmlAAAapQAASaUAAEqlAAAypwAA/acAAJqwAAD9 sAAADscAAEDHAAAA/QD9APsA+wD2AO726/YA6QDpAOkA6QDpAOkA6QDpAOkA9gDh9uv2 AOkA6QDpAOkA6QDpAOkA6QDpAOkA6QDpAOkA3wDaAPYA0vbr9gD7ANoA2gAPAgiBA2qy AQAABggBVQgBCE9KAABRSgAAAANIKgEPAgiBA2rZAAAABggBVQgBAzUIgQQwSg8AAA8C CIEDagAAAAAGCAFVCAEJA2oAAAAAVQgBAzYIgQRDShgAUwAGAAAuBgAALwYAADAGAAB/ BgAAngYAAMoGAADLBgAAzAYAAM0GAADWBgAA1wYAAO8IAADwCAAAAAkAAAEJAAA9DQAA EhAAAEQSAACnFAAAqBQAAMAUAADBFAAAkxYAAPAWAAAOFwAAMBcAAP0AAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD0AAAAAAAAAAAA AAAA9AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAA AAAAAPAAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADsAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAA AAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA7AAAAAAA AAAAAAAAAPIAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAN8AAAAA AAAAAAAAAADfAAAAAAAAAAAAAAAABQAACiYAC0YBAAAFAAARhPUAYIT1AAABEgAAAQEA AAEYAAABGgAAAQAAAAEZAAABFAAABAAAAyQBYSQBAAEXAAAaAAYAAC4GAAAvBgAAMAYA AH8GAACeBgAAygYAAMsGAADMBgAAzQYAANYGAADXBgAA7wgAAPAIAAAACQAAAQkAAD0N AAASEAAARBIAAKcUAACoFAAAwBQAAMEUAACTFgAA8BYAAA4XAAAwFwAAQhcAAF0XAABy FwAAghcAAIsXAACTFwAACBsAAAkcAAAQHQAAuR4AALYgAAAFIwAApCQAAJclAADvJgAA 9SgAADYsAABcLAAAfCwAAJAsAAC5LAAA3CwAAAotAAA0LQAAbS0AAKUtAADzLQAAdi4A AKsuAAC+LgAA5C4AAP0AAPv5+QAA9/UA8wDwAO7u7u4A8AAAAOvr6+vr6+vr6enp6enp 6enp6enp5N3Wz8jBurOspZ7plwAAAAAAAAAAAAAAAAANAhEACAIACQEKCwAAAA0CEQAI AgAJAQoKAAAADQIRAAgCAAkBCgkAAAANAhEACAIACQEKCAAAAA0CEQAIAgAJAQoHAAAA DQIRAAgCAAkBCgYAAAANAhEACAIACQEKBQAAAA0CEQAIAgAJAQoEAAAADQIRAAgCAAkB CgMAAAANAhEACAIACQEKAgAAAA0CEQAIAgAJAQoBAAAACAIRAAgCAAkBAAMCEQAFCAEA CQEDAhIABQIBAAUAAwIYAAMCGgACCQMAAwIZAAMCFAADAhcAADkwFwAAQhcAAF0XAABy FwAAghcAAIsXAACTFwAACBsAAAkcAAAQHQAAuR4AALYgAAAFIwAApCQAAJclAADvJgAA 9SgAADYsAABcLAAAfCwAAJAsAAC5LAAA3CwAAAotAAA0LQAAbS0AAKUtAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPIAAAAA AAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAA AAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAAPIAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcA AAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADn AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFEQAKJgALRgIA AAURABGEDgFghA4BAAURABGEAABghAAAAAERAAUAAAomAAtGAQAAGqUtAADzLQAAdi4A AKsuAAC+LgAA5C4AAPIuAAAMLwAAMi8AAFYvAAB9LwAAny8AAMgvAADJLwAA5y8AAOgv AAAhMQAAIjEAAEAxAABBMQAAPDMAALo2AADtNwAAYjkAAIE7AAD9PQAAO0EAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADu AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA 7gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APQAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABREAEYQOAWCE DgEAAQIAAAERAAABAQAAAQAAAAURABGEAABghAAABREACiYAC0YCAAAa5C4AAPIuAAAM LwAAMi8AAFYvAAB9LwAAny8AAMgvAADJLwAA5y8AAOgvAAAhMQAAIjEAAEAxAABBMQAA PDMAALo2AADtNwAAYjkAAIE7AAD9PQAAO0EAAPdDAABMRgAAoEkAAIlNAADoUAAARlMA AMxVAADmVgAAm1gAAJxYAACtWAAArlgAAOhaAAD48erj3NXOAMvIw764yMOzrqmkn5qV kIuGgXx3cm1oYl9aAAAAAAAACAIRAAbu////AAUG7////woCAgAFAQYt1///AAgCEQAG h9j//wAIAhEABjza//8ACAIRAAZW2///AAgCEQAG3N3//wAIAhEABjrg//8ACAIRAAaZ 4///AAgCEQAGguf//wAIAhEABtbq//8ACAIRAAYr7f//AAgCEQAG5+///wAIAhEABiXz //8ACAIRAAah9f//AAgCEQAGwPf//wAIAhEABjX5//8ACAIRAAZo+v//AAgCEQAG5v3/ /wAKAgIABQEGp/7//wAIAhEABqj+//8ACAIRAAbh////AAUG4v///wUCAQAFAA0CEQAI AgAJAQoSAAAADQIRAAgCAAkBChEAAAANAhEACAIACQEKEAAAAA0CEQAIAgAJAQoPAAAA DQIRAAgCAAkBCg4AAAANAhEACAIACQEKDQAAAA0CEQAIAgAJAQoMAAAAACI7QQAA90MA AExGAACgSQAAiU0AAOhQAABGUwAAzFUAAOZWAACbWAAAnFgAAK1YAACuWAAA6FoAALpe AADIYQAAz2MAADtnAACBaAAAQGkAAHBqAABhawAAlmwAAM9tAAC5bwAA/XAAABByAAD5 AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA APMAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAA AAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAQIA AAkRAA+E9QARhAAAXoT1AGCEAAAABREAEYQOAWCEDgEABREAEYQAAGCEAAAAGuhaAAC6 XgAAyGEAAM9jAAA7ZwAAgWgAAEBpAABwagAAYWsAAJZsAADPbQAAuW8AAP1wAAAQcgAA 6XIAAOpyAAD8cgAA/XIAAAV1AACZdwAAgXkAABV6AABifQAAeH8AAJqBAAB7hAAAfIQA AJmEAACahAAA7oUAAIaHAACQiAAA6okAAHKOAAAukAAAMJIAADGSAAD79vHs5+Ld2NPQ y8bBvLexrquopaKfmpeSjYeEf3p1cGtmY2AAAAAAAAAAAAUGTPL//wUGTvT//wgCEQAG Cvb//wAIAhEABpL6//8ACAIRAAbs+///AAgCEQAG9vz//wAIAhEABo7+//8ACAIRAAbi ////AAUG4////woCAgAFAQZNq///AAgCEQAGb+7//wAIAhUABlDx//8ABQZy8///CAIV AAaI9f//AAUG1fj//wUGafn//wUGUfv//wUG5f3//wUG7f///wUG7v///woCAgAFAQbf vP//AAgCEQAGs+X//wAIAhEABozm//8ACAIRAAaf5///AAgCEQAG4+j//wAIAhEABs3q //8ABQYG7P//CAIRAAY77f//AAgCEQAGLO7//wAIAhEABlzv//8ACAIRAAYb8P//AAgC EQAGYfH//wAIAhEABs30//8ACAIRAAbU9v//AAgCEQAG4vn//wAIAhEABrT9//8kEHIA AOlyAADqcgAA/HIAAP1yAAAFdQAAmXcAAIF5AAAVegAAYn0AAHh/AACagQAAe4QAAHyE AACZhAAAmoQAAO6FAACGhwAAkIgAAOqJAAByjgAALpAAADCSAAAxkgAAUpIAAEWTAAD5 AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA 7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAA APMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAA AADdAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADdAAAAAAAAAAAA AAAA3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA3QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAANgAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAAAAAAAAQCAAMkAGEkAAAFEQARhAAAYIQAAAAJFQAPhAAA EYQOAV6EAABghA4BAAUAABGEDgFghA4BAAEAAAABAgAAAREAAAURABGEDgFghA4BABkx kgAAUpIAAEWTAABwkwAAqJMAAOGTAAAtlAAALpQAAFmUAABhlAAAa5QAAIOUAACElAAA jpQAAJOUAACjlAAApJQAAKuUAACwlAAAyJQAAMmUAADVlAAA2JQAAOaUAADnlAAA6pQA AO2UAAD7lAAA/JQAAAKVAAAIlQAAGZUAABqVAAAhlQAA+vXv59/X1M/KxcC8t7KtqaSf mpaRjIeDfnl0cGtmYV1YAAAAAAAAAAkDAQUKBhf9//8HAwEGGP3//wkDAQUKBin9//8J AwEFCgYv/f//CQMBBQoGNf3//wcDAQY2/f//CQMBBQoGRP3//wkDAQUKBkf9//8JAwEF CgZK/f//BwMBBkv9//8JAwEFCgZZ/f//CQMBBQoGXP3//wkDAQUKBmj9//8HAwEGaf3/ /wkDAQUKBoH9//8JAwEFCgaG/f//CQMBBQoGjf3//wcDAQaO/f//CQMBBQoGnv3//wkD AQUKBqP9//8JAwEFCgat/f//BwMBBq79//8JAwEFCgbG/f//CQMBBQoG0P3//wkDAQUK Btj9//8IAhYABgP+//8ABQYE/v//DwZQ/v//CA0ACQEKAwAAAA8Gif7//wgNAAkBCgIA AAAPBsH+//8IDQAJAQoBAAAACgbs/v//CA0ACQEACAIRAAbf////AAoCAgAFAQaYnf// IUWTAABwkwAAqJMAAOGTAAAtlAAALpQAAFmUAABhlAAAa5QAAIOUAACElAAAjpQAAJOU AACjlAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAA AAAAAAAAAADwAAAAAAAAAAAAAAAAcoAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAA AAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAAAH4AABYkARckAUlmAQAAAAKWbAAF1hgEAQAA BAEAAAQBAAAEAQAABAEAAAQBAAAI1kYAA5T/kgTKCEgSAAb+BAAAAAAAAAAAAAAAAAAA AAAABjgEAAAAAAAAAAAAAAAAAAAAAAAGfgkAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYDtBIVNgEa 1gwAAAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAAAP8c1gwAAAD/AAAA/wAAAP8d1gwAAAD/ AAAA/wAAAP801gYAAQoDbABh9gMAAAYAABYkAUlmAQAAAAABFgAAAQAABQAACiYAC0YN AAANo5QAAKSUAACrlAAAsJQAAMiUAADJlAAA1ZQAANiUAADmlAAA55QAAOqUAADtlAAA +5QAAPyUAAAClQAAgZQAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAA ewAAAAAAAAAAAAAAAIF4AAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAAewAAAAAAAAAAAAAA AHsAAAAAAAAAAAAAAACBVAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAHsAAAAAAAAAAAAA AAB7AAAAAAAAAAAAAAAAgXgAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAAAAAAABgAAFiQB SWYBAAAAfgAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEA AAjWRgADlP+SBMoISBIABv4EAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAAAAAA AAAAAAZ+CQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gO0EhU2ARrWDAAAAP8AAAD/AAAA/xvWDAAA AP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTWBgABCgNsAGH2 AwAAAA4ClQAACJUAABmVAAAalQAAIZUAACeVAAA2lQAAN5UAAD2VAABBlQAATpUAAE+V AABWlQAAW5UAAGiVAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAHt0AAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAB7YAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAe2gAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAB+AAAW JAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNZGAAOU/5IE yghIEgAG/gQAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABn4JAAAA AAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAABT2A7QSFTYBGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/ HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAGAAAWJAFJ ZgEAAAAADiGVAAAnlQAANpUAADeVAAA9lQAAQZUAAE6VAABPlQAAVpUAAFuVAABolQAA aZUAAHKVAAB3lQAAgpUAAIOVAACGlQAAjZUAAJaVAACXlQAAmpUAAJ6VAACplQAAqpUA ALaVAAC7lQAAyJUAAMmVAADMlQAA1ZUAAOSVAADllQAA6ZUAAO6VAAD6lQAA+vXx7Ofi 3tnUz8vGwby4s66ppaCblpKNiIN/enVwbGdiXQAAAAAAAAAAAAAAAAkDAQUKBkP8//8J AwEFCgZI/P//CQMBBQoGTPz//wcDAQZN/P//CQMBBQoGXPz//wkDAQUKBmX8//8JAwEF CgZo/P//BwMBBmn8//8JAwEFCgZ2/P//CQMBBQoGe/z//wkDAQUKBof8//8HAwEGiPz/ /wkDAQUKBpP8//8JAwEFCgaX/P//CQMBBQoGmvz//wcDAQab/P//CQMBBQoGpPz//wkD AQUKBqv8//8JAwEFCgau/P//BwMBBq/8//8JAwEFCga6/P//CQMBBQoGv/z//wkDAQUK Bsj8//8HAwEGyfz//wkDAQUKBtb8//8JAwEFCgbb/P//CQMBBQoG4vz//wcDAQbj/P// CQMBBQoG8Pz//wkDAQUKBvT8//8JAwEFCgb6/P//BwMBBvv8//8JAwEFCgYK/f//CQMB BQoGEP3//wAiaJUAAGmVAABylQAAd5UAAIKVAACDlQAAhpUAAI2VAACWlQAAl5UAAJqV AACelQAAqZUAAKqVAAC2lQAAgWgAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB7AAAAAAAA AAAAAAAAewAAAAAAAAAAAAAAAIFQAAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAAewAAAAAA AAAAAAAAAHsAAAAAAAAAAAAAAACBTAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAHsAAAAA AAAAAAAAAAB7AAAAAAAAAAAAAAAAgXwAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAAAAAAA BgAAFiQBSWYBAAAAfgAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAE AQAABAEAAAjWRgADlP+SBMoISBIABv4EAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAA AAAAAAAAAAAAAAZ+CQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gO0EhU2ARrWDAAAAP8AAAD/AAAA /xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8AAAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTWBgAB CgNsAGH2AwAAAA62lQAAu5UAAMiVAADJlQAAzJUAANWVAADklQAA5ZUAAOmVAADulQAA +pUAAPuVAAD8lQAADJcAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAe3AAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAHtYAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAB7AAAAAAAA AAAAAAAAeQAAAAAAAAAAAAAAAHMAAAAAAAAAAAAAAAAAAAAAAAAFAAARhA4BYIQOAQAB AAB+AAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNZG AAOU/5IEyghIEgAG/gQAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAA Bn4JAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAABT2A7QSFTYBGtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAA AP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAG AAAWJAFJZgEAAAAADfqVAAD7lQAA/JUAAAyXAADumAAA85kAAAeaAAAamgAALZoAALmb AAANngAA66EAALeiAAAIowAAFaMAACWjAABZpAAA2qQAAEylAAA2pgAAvaYAADKnAAD+ pwAAzqgAADCqAADaqwAAU60AAFStAACRrQAAtK0AALWtAABprwAAmLAAAJmwAACasAAA /bAAAAexAAAPsQAA+/j18u/s6ebj4N3a09DNyMG+u7WtqKKakoqHhIF+e3h0cWxnYgAA AAAAAAAJAwEFCgYq4f//CQMBBQoGNOH//wgCFgAGl+H//wAFBpjh//8HBpnh//8JAwUI FgAJAQUGfOT//wUGfeT//wUGoOT//wUG3eT//wUG3uT//w8GV+b//wgWAAkBCgMAAAAP BgHo//8IFgAJAQoCAAAADwZj6f//CBYACQEKAQAAAAoGM+r//wgWAAkBAAgCEgAG/+r/ /wAPBnTr//8IDwAJAQoBAAAACgb76///CA8ACQEABQbl7P//BQZX7f//DAbY7f//BwEI EAAJAQAIAhUABgzv//8ABQYc7///BQYp7///DAZ67///BwEICQAJAQAFBkbw//8FBiT0 //8FBnj2//8FBgT4//8FBhf4//8FBir4//8FBj74//8FBkP5//8FBiX7//8FBjX8//8F Bjb8//8HAwEGN/z//wAlDJcAAO6YAADzmQAAB5oAABqaAAAtmgAAuZsAAA2eAADroQAA t6IAAAijAAAVowAAJaMAAFmkAADapAAATKUAADamAAC9pgAAMqcAAP6nAADOqAAAMKoA ANqrAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAA AAAAAAAA8wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAA AAAAAAAAAADjAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAAM8AAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAAygAAAAAAAAAAAAAAAMoAAAAAAAAAAAAAAADEAAAAAAAAAAAAAAAAvwAA AAAAAAAAAAAAAL8AAAAAAAAAAAAAAAC/AAAAAAAAAAAAAAAAAAAAAAUAAAomAAtGFgAA BRIAEYQOAWCEDgEFAAAKJgALRg8AAAUAABGEaAFghGgBDgAACiYBC0YQAA+EaAFehGgB DcYHAaAFAWgBBgABFQAOAAAKJgELRgkAD4RoAV6EaAENxgcBoAUBaAEGAAUAAA+E0AJe hNACAAUAABGEDgFghA4BABbaqwAAU60AAFStAACRrQAAtK0AALWtAABprwAAmLAAAJmw AACasAAA/bAAAAexAAAPsQAAG7EAAC2xAAA7sQAAWbEAAGKxAABpsQAA+gAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADoAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA4AAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA2gAAAAAA AAAAAAAAANoAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANoAAAAA AAAAAAAAAADaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQB SWYBAAAAAAEWAAAFAAARhA4BYIQOAQAJAAAPhGgBEYQOAV6EaAFghA4BAAUAAA+EaAFe hGgBAAEAAAUAAAomAAtGFgAAEg+xAAAbsQAALbEAADuxAABZsQAAYrEAAGmxAABqsQAA b7EAAHmxAACBsQAAhbEAAIixAACZsQAAnbEAAJ6xAACjsQAArLEAALKxAAC2sQAAxLEA ANKxAADTsQAA1LEAAN6xAADksQAA7LEAAPexAAD4sQAA+bEAAPqxAAD7sQAAAbIAAAiy AAAQsgAA+vXw6+bh3djTzsnEv7q2saynop2Yk4+KhYB7dnFsaGNeWQAAAAAJAwEFCgYp 4P//CQMBBQoGMOD//wkDAQUKBjbg//8HAwEGN+D//wkDAQUKBjjg//8JAwEFCgY54P// CQMBBQoGOuD//wkDAQUKBkXg//8JAwEFCgZN4P//CQMBBQoGU+D//wkDAQUKBl3g//8H AwEGXuD//wkDAQUKBl/g//8JAwEFCgZt4P//CQMBBQoGe+D//wkDAQUKBn/g//8JAwEF CgaF4P//CQMBBQoGjuD//wkDAQUKBpPg//8HAwEGlOD//wkDAQUKBpjg//8JAwEFCgap 4P//CQMBBQoGrOD//wkDAQUKBrDg//8JAwEFCga44P//CQMBBQoGwuD//wkDAQUKBsfg //8HAwEGyOD//wkDAQUKBs/g//8JAwEFCgbY4P//CQMBBQoG9uD//wkDAQUKBgTh//8J AwEFCgYW4f//CQMBBQoGIuH//wAiabEAAGqxAABvsQAAebEAAIGxAAAz0AAAAAAAAAAA AAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABgAAFiQBSWYBAAAAzAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgEAQAA BAEAAAQBAAAEAQAABAEAAAQBAAAI1p4AB5T/DAQKCeUMghEBGFUfFyMABngEAAAAAAAA AAAAAAAAAAAAAAAG/gQAAAAAAAAAAAAAAAAAAAAAAAbbAwAAAAAAAAAAAAAAAAAAAAAA Bp0EAAAAAAAAAAAAAAAAAAAAAAAGfwYAAAAAAAAAAAAAAAAAAAAAAAZUBwAAAAAAAAAA AAAAAAAAAAAABsIDAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A4MjFTYBGtYcAAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/xvWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1hwA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYcAAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/zTWBgABCgNsAGH2AwAAAASBsQAAhbEAAIixAACZsQAAnbEAAPYAAAAAAAAA AAAAAADwAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJ ZgEAAAAJAAADJAEWJAFJZgEAAABhJAEABJ2xAACesQAAo7EAAKyxAACysQAAM9gAAAAA AAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAMwAABYkARckAUlmAQAAAABUAQAClmwABdYY BAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaeAAeU/wwECgnlDIIRARhVHxcjAAZ4BAAA AAAAAAAAAAAAAAAAAAAABv4EAAAAAAAAAAAAAAAAAAAAAAAG2wMAAAAAAAAAAAAAAAAA AAAAAAadBAAAAAAAAAAAAAAAAAAAAAAABn8GAAAAAAAAAAAAAAAAAAAAAAAGVAcAAAAA AAAAAAAAAAAAAAAAAAbCAwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAA AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gODIxU2ARrWHAAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ HNYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WHAAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAAEsrEAALaxAADEsQAA0rEAANOxAAD2AAAA AAAAAAAAAAAA8AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAA FiQBSWYBAAAACQAAAyQBFiQBSWYBAAAAYSQBAATTsQAA1LEAAN6xAADksQAA7LEAADOc AAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAADMAAAWJAEXJAFJZgEAAAAAVAEAApZs AAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWngAHlP8MBAoJ5QyCEQEYVR8XIwAG eAQAAAAAAAAAAAAAAAAAAAAAAAb+BAAAAAAAAAAAAAAAAAAAAAAABtsDAAAAAAAAAAAA AAAAAAAAAAAGnQQAAAAAAAAAAAAAAAAAAAAAAAZ/BgAAAAAAAAAAAAAAAAAAAAAABlQH AAAAAAAAAAAAAAAAAAAAAAAGwgMAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYDgyMVNgEa1hwAAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/xzWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hwAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAABOyxAAD3sQAA+LEAAPmxAAD6sQAA 9gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAYAABYkAUlmAQAAAAkAAAMkARYkAUlmAQAAAGEkAQAE+rEAAPuxAAABsgAACLIAABCy AAAzwAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAzAAAFiQBFyQBSWYBAAAAAFQB AAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1p4AB5T/DAQKCeUMghEBGFUf FyMABngEAAAAAAAAAAAAAAAAAAAAAAAG/gQAAAAAAAAAAAAAAAAAAAAAAAbbAwAAAAAA AAAAAAAAAAAAAAAABp0EAAAAAAAAAAAAAAAAAAAAAAAGfwYAAAAAAAAAAAAAAAAAAAAA AAZUBwAAAAAAAAAAAAAAAAAAAAAABsIDAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAA AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A4MjFTYBGtYc AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWHAAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8c1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYcAAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAQQsgAAFLIAAByyAAAksgAA KrIAACuyAAAxsgAAN7IAAD+yAABDsgAASbIAAFWyAABWsgAAV7IAAFuyAABhsgAAabIA AG2yAAB1sgAAf7IAAIOyAACEsgAAibIAAJWyAACdsgAAobIAAKayAACwsgAAsbIAALKy AAC1sgAAwbIAAMeyAADLsgAA2LIAAPr18Ovn4t3Y087JxMC7trGsp6KdmZSPioWAe3Zy bWhjXlkAAAAACQMBBQoGZt///wkDAQUKBmrf//8JAwEFCgZw3///CQMBBQoGfN///wkD AQUKBn/f//8HAwEGgN///wkDAQUKBoHf//8JAwEFCgaL3///CQMBBQoGkN///wkDAQUK BpTf//8JAwEFCgac3///CQMBBQoGqN///wkDAQUKBq3f//8HAwEGrt///wkDAQUKBrLf //8JAwEFCga83///CQMBBQoGxN///wkDAQUKBsjf//8JAwEFCgbQ3///CQMBBQoG1t// /wkDAQUKBtrf//8HAwEG29///wkDAQUKBtzf//8JAwEFCgbo3///CQMBBQoG7t///wkD AQUKBvLf//8JAwEFCgb63///CQMBBQoGAOD//wkDAQUKBgbg//8HAwEGB+D//wkDAQUK Bg3g//8JAwEFCgYV4P//CQMBBQoGHeD//wkDAQUKBiHg//8AIhCyAAAUsgAAHLIAACSy AAAqsgAA9gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkARYkAUlmAQAAAGEkAQAEKrIAACuyAAAxsgAA N7IAAD+yAAAzsAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAzAAAFiQBFyQBSWYB AAAAAFQBAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1p4AB5T/DAQKCeUM ghEBGFUfFyMABngEAAAAAAAAAAAAAAAAAAAAAAAG/gQAAAAAAAAAAAAAAAAAAAAAAAbb AwAAAAAAAAAAAAAAAAAAAAAABp0EAAAAAAAAAAAAAAAAAAAAAAAGfwYAAAAAAAAAAAAA AAAAAAAAAAZUBwAAAAAAAAAAAAAAAAAAAAAABsIDAAAAAAAAAAAAAAAAAAAAABPWMAAA AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A4Mj FTYBGtYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWHAAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8c1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYcAAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAQ/sgAAQ7IAAEmy AABVsgAAVrIAAPYAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAEWJAFJZgEAAABhJAEABFayAABXsgAA W7IAAGGyAABpsgAAM7QAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAA LQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAMwAABYkARck AUlmAQAAAABUAQAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaeAAeU/wwE CgnlDIIRARhVHxcjAAZ4BAAAAAAAAAAAAAAAAAAAAAAABv4EAAAAAAAAAAAAAAAAAAAA AAAG2wMAAAAAAAAAAAAAAAAAAAAAAAadBAAAAAAAAAAAAAAAAAAAAAAABn8GAAAAAAAA AAAAAAAAAAAAAAAGVAcAAAAAAAAAAAAAAAAAAAAAAAbCAwAAAAAAAAAAAAAAAAAAAAAT 1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU 9gODIxU2ARrWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hwAAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/HNYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3W HAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAAEabIAAG2y AAB1sgAAf7IAAIOyAAD2AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQBFiQBSWYBAAAAYSQBAASDsgAA hLIAAImyAACVsgAAnbIAADO4AAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAA AAAAAC0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAADMAAAW JAEXJAFJZgEAAAAAVAEAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWngAH lP8MBAoJ5QyCEQEYVR8XIwAGeAQAAAAAAAAAAAAAAAAAAAAAAAb+BAAAAAAAAAAAAAAA AAAAAAAABtsDAAAAAAAAAAAAAAAAAAAAAAAGnQQAAAAAAAAAAAAAAAAAAAAAAAZ/BgAA AAAAAAAAAAAAAAAAAAAABlQHAAAAAAAAAAAAAAAAAAAAAAAGwgMAAAAAAAAAAAAAAAAA AAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAFPYDgyMVNgEa1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YcAAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8d1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAABJ2y AAChsgAAprIAALCyAACxsgAA9gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkAAAMkARYkAUlmAQAAAGEkAQAE sbIAALKyAAC1sgAAwbIAAMeyAAAz6AAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAA AAAAAAAAAAAtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAA zAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI 1p4AB5T/DAQKCeUMghEBGFUfFyMABngEAAAAAAAAAAAAAAAAAAAAAAAG/gQAAAAAAAAA AAAAAAAAAAAAAAbbAwAAAAAAAAAAAAAAAAAAAAAABp0EAAAAAAAAAAAAAAAAAAAAAAAG fwYAAAAAAAAAAAAAAAAAAAAAAAZUBwAAAAAAAAAAAAAAAAAAAAAABsIDAAAAAAAAAAAA AAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAABT2A4MjFTYBGtYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWHAAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/HdYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAA AATHsgAAy7IAANiyAADlsgAA67IAAPYAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAEWJAFJZgEAAABh JAEABNiyAADlsgAA67IAAOyyAADxsgAA+LIAAACzAAAEswAAC7MAABmzAAAfswAAILMA ACWzAAAsswAANLMAADizAABAswAASbMAAEqzAABLswAAT7MAAFKzAABaswAAXrMAAGiz AABpswAAarMAAGuzAABuswAAcbMAAHezAAB7swAAhLMAAI2zAACOswAA+vXx7Ofi3djT zsrFwLu2sayno56ZlI+KhYB8d3JtaGNeWQAAAAAJAwEFCgak3v//CQMBBQoGrd7//wkD AQUKBrbe//8JAwEFCga63v//CQMBBQoGwN7//wkDAQUKBsPe//8JAwEFCgbG3v//BwMB Bsfe//8JAwEFCgbI3v//CQMBBQoGyd7//wkDAQUKBtPe//8JAwEFCgbX3v//CQMBBQoG 397//wkDAQUKBuLe//8JAwEFCgbm3v//BwMBBufe//8JAwEFCgbo3v//CQMBBQoG8d7/ /wkDAQUKBvne//8JAwEFCgb93v//CQMBBQoGBd///wkDAQUKBgzf//8JAwEFCgYR3/// BwMBBhLf//8JAwEFCgYY3///CQMBBQoGJt///wkDAQUKBi3f//8JAwEFCgYx3///CQMB BQoGOd///wkDAQUKBkDf//8JAwEFCgZF3///BwMBBkbf//8JAwEFCgZM3///CQMBBQoG Wd///wAi67IAAOyyAADxsgAA+LIAAACzAAAz0AAAAAAAAAAAAAAALQAAAAAAAAAAAAAA AC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQB SWYBAAAAzAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA AAQBAAAI1p4AB5T/DAQKCeUMghEBGFUfFyMABngEAAAAAAAAAAAAAAAAAAAAAAAG/gQA AAAAAAAAAAAAAAAAAAAAAAbbAwAAAAAAAAAAAAAAAAAAAAAABp0EAAAAAAAAAAAAAAAA AAAAAAAGfwYAAAAAAAAAAAAAAAAAAAAAAAZUBwAAAAAAAAAAAAAAAAAAAAAABsIDAAAA AAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAABT2A4MjFTYBGtYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /xvWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1hwAAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/HdYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNs AGH2AwAAAAQAswAABLMAAAuzAAAZswAAH7MAAPYAAAAAAAAAAAAAAADwAAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAEWJAFJ ZgEAAABhJAEABB+zAAAgswAAJbMAACyzAAA0swAAM6wAAAAAAAAAAAAAAC0AAAAAAAAA AAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYA ABYkAUlmAQAAAMwAABYkARckAUlmAQAAAABUAQAClmwABdYYBAEAAAQBAAAEAQAABAEA AAQBAAAEAQAACNaeAAeU/wwECgnlDIIRARhVHxcjAAZ4BAAAAAAAAAAAAAAAAAAAAAAA Bv4EAAAAAAAAAAAAAAAAAAAAAAAG2wMAAAAAAAAAAAAAAAAAAAAAAAadBAAAAAAAAAAA AAAAAAAAAAAABn8GAAAAAAAAAAAAAAAAAAAAAAAGVAcAAAAAAAAAAAAAAAAAAAAAAAbC AwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAU9gODIxU2ARrWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8b1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYcAAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/x3WHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYA AQoDbABh9gMAAAAENLMAADizAABAswAASbMAAEqzAAD2AAAAAAAAAAAAAAAA8AAAAAAA AAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAACQAAAyQB FiQBSWYBAAAAYSQBAARKswAAS7MAAE+zAABSswAAWrMAADOAAAAAAAAAAAAAAAAtAAAA AAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAGAAAWJAFJZgEAAADMAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAQBAAAEAQAABAEA AAQBAAAEAQAABAEAAAjWngAHlP8MBAoJ5QyCEQEYVR8XIwAGeAQAAAAAAAAAAAAAAAAA AAAAAAb+BAAAAAAAAAAAAAAAAAAAAAAABtsDAAAAAAAAAAAAAAAAAAAAAAAGnQQAAAAA AAAAAAAAAAAAAAAAAAZ/BgAAAAAAAAAAAAAAAAAAAAAABlQHAAAAAAAAAAAAAAAAAAAA AAAGwgMAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYDgyMVNgEa1hwAAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/G9YcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWHAAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ NNYGAAEKA2wAYfYDAAAABFqzAABeswAAaLMAAGmzAABqswAA9gAAAAAAAAAAAAAAAPAA AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAkA AAMkARYkAUlmAQAAAGEkAQAEarMAAGuzAABuswAAcbMAAHezAAAzkAAAAAAAAAAAAAAA LQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABgAAFiQBSWYBAAAAzAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgEAQAABAEA AAQBAAAEAQAABAEAAAQBAAAI1p4AB5T/DAQKCeUMghEBGFUfFyMABngEAAAAAAAAAAAA AAAAAAAAAAAG/gQAAAAAAAAAAAAAAAAAAAAAAAbbAwAAAAAAAAAAAAAAAAAAAAAABp0E AAAAAAAAAAAAAAAAAAAAAAAGfwYAAAAAAAAAAAAAAAAAAAAAAAZUBwAAAAAAAAAAAAAA AAAAAAAABsIDAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A4MjFTYBGtYcAAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/xvWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1hwAAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/zTWBgABCgNsAGH2AwAAAAR3swAAe7MAAISzAACNswAAjrMAAPYAAAAAAAAAAAAA AADwAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEA AAAJAAADJAEWJAFJZgEAAABhJAEABI6zAACPswAAl7MAAJqzAACgswAAq7MAALSzAAC9 swAAvrMAAL+zAADGswAAybMAANGzAADVswAA3LMAAOSzAADqswAA67MAAPSzAAD3swAA /bMAAAG0AAAKtAAAE7QAABS0AAAVtAAAGrQAAB20AAAltAAAKbQAADC0AABAtAAAQbQA AEK0AABDtAAA+/bx7Ofi3djUz8rFwLu2sa2oo56ZlI+KhoF8d3JtaGNfWwAAAAAAAAAA Bwbv3f//CQMHAwEG8N3//wkDAQUKBvHd//8JAwEFCgYB3v//CQMBBQoGCN7//wkDAQUK Bgze//8JAwEFCgYU3v//CQMBBQoGF97//wkDAQUKBhze//8HAwEGHd7//wkDAQUKBh7e //8JAwEFCgYn3v//CQMBBQoGMN7//wkDAQUKBjTe//8JAwEFCgY63v//CQMBBQoGPd7/ /wkDAQUKBkbe//8HAwEGR97//wkDAQUKBk3e//8JAwEFCgZV3v//CQMBBQoGXN7//wkD AQUKBmDe//8JAwEFCgZo3v//CQMBBQoGa97//wkDAQUKBnLe//8HAwEGc97//wkDAQUK BnTe//8JAwEFCgZ93v//CQMBBQoGht7//wkDAQUKBpHe//8JAwEFCgaX3v//CQMBBQoG mt7//wkDAQUKBqLe//8HAwEGo97//wAijrMAAI+zAACXswAAmrMAAKCzAAAzwAAAAAAA AAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAzAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgE AQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1p4AB5T/DAQKCeUMghEBGFUfFyMABngEAAAA AAAAAAAAAAAAAAAAAAAG/gQAAAAAAAAAAAAAAAAAAAAAAAbbAwAAAAAAAAAAAAAAAAAA AAAABp0EAAAAAAAAAAAAAAAAAAAAAAAGfwYAAAAAAAAAAAAAAAAAAAAAAAZUBwAAAAAA AAAAAAAAAAAAAAAABsIDAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A4MjFTYBGtYcAAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/xvWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c 1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYcAAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAASgswAAq7MAALSzAAC9swAAvrMAAPYAAAAA AAAAAAAAAADwAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAW JAFJZgEAAAAJAAADJAEWJAFJZgEAAABhJAEABL6zAAC/swAAxrMAAMmzAADRswAAM7AA AAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAMwAABYkARckAUlmAQAAAABUAQAClmwA BdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaeAAeU/wwECgnlDIIRARhVHxcjAAZ4 BAAAAAAAAAAAAAAAAAAAAAAABv4EAAAAAAAAAAAAAAAAAAAAAAAG2wMAAAAAAAAAAAAA AAAAAAAAAAadBAAAAAAAAAAAAAAAAAAAAAAABn8GAAAAAAAAAAAAAAAAAAAAAAAGVAcA AAAAAAAAAAAAAAAAAAAAAAbCAwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gODIxU2ARrWHAAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/HNYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WHAAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAAE0bMAANWzAADcswAA5LMAAOqzAAD2 AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BgAAFiQBSWYBAAAACQAAAyQBFiQBSWYBAAAAYSQBAATqswAA67MAAPSzAAD3swAA/bMA ADOoAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAADMAAAWJAEXJAFJZgEAAAAAVAEA ApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWngAHlP8MBAoJ5QyCEQEYVR8X IwAGeAQAAAAAAAAAAAAAAAAAAAAAAAb+BAAAAAAAAAAAAAAAAAAAAAAABtsDAAAAAAAA AAAAAAAAAAAAAAAGnQQAAAAAAAAAAAAAAAAAAAAAAAZ/BgAAAAAAAAAAAAAAAAAAAAAA BlQHAAAAAAAAAAAAAAAAAAAAAAAGwgMAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYDgyMVNgEa1hwA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YcAAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/xzWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hwAAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAABP2zAAABtAAACrQAABO0AAAU tAAA9gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAYAABYkAUlmAQAAAAkAAAMkARYkAUlmAQAAAGEkAQAEFLQAABW0AAAatAAAHbQA ACW0AAAztAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAzAAAFiQBFyQBSWYBAAAA AFQBAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1p4AB5T/DAQKCeUMghEB GFUfFyMABngEAAAAAAAAAAAAAAAAAAAAAAAG/gQAAAAAAAAAAAAAAAAAAAAAAAbbAwAA AAAAAAAAAAAAAAAAAAAABp0EAAAAAAAAAAAAAAAAAAAAAAAGfwYAAAAAAAAAAAAAAAAA AAAAAAZUBwAAAAAAAAAAAAAAAAAAAAAABsIDAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2A4MjFTYB GtYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWHAAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8c1hwAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYcAAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAQltAAAKbQAADC0AABA tAAAQbQAAPYAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGAAAWJAFJZgEAAAAJAAADJAEWJAFJZgEAAABhJAEABEG0AABCtAAAQ7QA ALe2AADhuAAAMwAAAAAAAAAAAAAAADEAAAAAAAAAAAAAAAArAAAAAAAAAAAAAAAAKwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAABGEDgFghA4BAAEAAMwAABYkARckAUlm AQAAAABUAQAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaeAAeU/wwECgnl DIIRARhVHxcjAAZ4BAAAAAAAAAAAAAAAAAAAAAAABv4EAAAAAAAAAAAAAAAAAAAAAAAG 2wMAAAAAAAAAAAAAAAAAAAAAAAadBAAAAAAAAAAAAAAAAAAAAAAABn8GAAAAAAAAAAAA AAAAAAAAAAAGVAcAAAAAAAAAAAAAAAAAAAAAAAbCAwAAAAAAAAAAAAAAAAAAAAAT1jAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gOD IxU2ARrWHAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hwAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/HNYcAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WHAAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAAEQ7QAALe2AADh uAAAI7sAACO+AADDvgAAAr8AAGO/AACvvwAAJsAAAITAAADTwAAAG8IAABvDAAAuxQAA L8UAADDFAABjxQAAdcUAAIjFAACvxQAAwcUAANfFAAAzxgAAQsYAAGjGAACOxgAAvcYA ANjGAADnxgAA+cYAAA3HAAAOxwAAPscAAD/HAABAxwAAQccAAF/HAABgxwAA/Pn28/Dq 4trSysK6t7SxrquopaKfnJmWk5CNioeEgX55dG9saWYAAAAAAAAAAAAABQbg////BQIB AAUABQbxyv//CAIWAAbyyv//AAgCFgAG88r//wAIAhYABiPL//8ABQYky///BQY4y/// BQZKy///BQZZy///BQZ0y///BQajy///BQbJy///BQbvy///BQb+y///BQZazP//BQZw zP//BQaCzP//BQapzP//BQa8zP//BQbOzP//BQYBzf//BQYCzf//BQYDzf//BQYWz/// BQYW0P//DwZe0f//CBcACQEKBgAAAA8GrdH//wgXAAkBCgUAAAAPBgvS//8IFwAJAQoE AAAADwaC0v//CBcACQEKAwAAAA8GztL//wgXAAkBCgIAAAAPBi/T//8IFwAJAQoBAAAA CgZu0///CBcACQEABQYO1P//BQYO1///BQZQ2f//BQZ62///BQbu3f//ACbhuAAAI7sA ACO+AADDvgAAAr8AAGO/AACvvwAAJsAAAITAAADTwAAAG8IAABvDAAAuxQAAL8UAADDF AABjxQAAdcUAAIjFAACvxQAAwcUAANfFAAAzxgAAQsYAAGjGAACOxgAAvcYAANjGAADn xgAA+cYAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAA AAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAA APIAAAAAAAAAAAAAAAAAAAAAAAEAAAUAAAomAAtGFwAABQAAEYQOAWCEDgEAHPnGAAAN xwAADscAAD7HAAA/xwAAQMcAAEHHAABfxwAAYMcAABzKAADJzAAA4M4AAF/QAABi0gAA CNYAAAnXAAAK1wAAHtcAAB/XAACe2QAAMt0AADPdAABB3QAAQt0AAFPeAABU3gAACd8A APUAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AADxAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADzAAAAAAAAAAAA AAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAA AAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAA AAAAAAAA8wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAA AAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAETAAAB JAAABQAAEYQOAWCEDgEAAQEAAAEWAAABAAAKAAAmZAYBAAFQxggAAAD/BgEBAAAaYMcA ABzKAADJzAAA4M4AAF/QAABi0gAACNYAAAnXAAAK1wAAHtcAAB/XAACe2QAAMt0AADPd AABB3QAAQt0AAFPeAABU3gAACd8AAArfAAAd4AAAHuAAAN7gAADf4AAAluEAAJfhAAAz 4gAANOIAADzjAAA94wAAXeQAAF7kAACX5QAAmOUAAIfmAACI5gAAeOcAAHnnAAAl6AAA /AAA+fbz8O3q6uXg3erY087JxL+6tbCrpqGcl5KNiIN+eXRvamUAAAAAAAAAAAgCEwAG w/X//wAIAhMABsT1//8ACAITAAa09v//AAgCEwAGtfb//wAIAhMABqT3//8ACAITAAal 9///AAgCEwAG3vj//wAIAhMABt/4//8ACAITAAb/+f//AAgCEwAGAPr//wAIAhMABgj7 //8ACAITAAYJ+///AAgCEwAGpfv//wAIAhMABqb7//8ACAITAAZd/P//AAgCEwAGXvz/ /wAIAhMABh79//8ACAITAAYf/f//AAgCEwAGMv7//wAIAhMABjP+//8ACAITAAbo/v// AAgCEwAG6f7//wAIAhMABvr///8ACAITAAb7////AAUG9fn//wgCJAAGif3//wAIAiQA BggAAAAABQIBAAUABQY28P//BQY38f//BQbd9P//BQbg9v//BQZf+P//BQbf////ACZA xwAAHtcAAB/XAAAx3QAAMt0AAEHdAABC3QAAUd4AAFPeAAAd4AAALeAAAGzgAAB+4AAA R+EAAIThAAA04gAAPOMAAF3kAABe5AAAl+UAAHjnAAC85wAAvecAAPbnAAD35wAA+OcA ACPoAAAk6AAAKegAAAD9APoA9QD1APUA8wD1APUA8QD1AOwA5Ozh7AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMEoPAAAPAgiB A2rnAgAABggBVQgBCQNqAAAAAFUIAQM1CIEDNgiBCUIqAXBoAAAAAARtSAkEAARDShQA HAnfAAAK3wAAHeAAAB7gAADe4AAA3+AAAJbhAACX4QAAM+IAADTiAAA84wAAPeMAAF3k AABe5AAAl+UAAJjlAACH5gAAiOYAAHjnAAB55wAAJegAACboAAAn6AAAKOgAACnoAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAET AAAYJegAACboAAAn6AAAKOgAACnoAAD7APkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAAgCEwAG F/X//wQcAB+w0C8gsOA9IbCgBSKwoAUjkKAFJJDABiWwAAAjAAkwAB+w0C8gsOA9IbCg BSKwoAUjkKAFJJDABiWwAAALUAEAIwAJMAAfsNAvILDgPSGwoAUisKAFI5CgBSSQwAYl sAAADJDNASMACTAAH7DQLyCw4D0hsKAFIrCgBSOQoAUkkMAGJbAAAAtQAQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAANkAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABkA AABoAHQAdABwADoALwAvAHcAdwB3AC4AcwBkAHMAYwAuAGUAZAB1AC8AcwByAGIALwAA AODJ6nn5us4RjIIAqgBLqQsyAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHMAZABzAGMA LgBlAGQAdQAvAHMAcgBiAC8AAADZAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoA S6kLAgAAABcAAAAZAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHMAZABzAGMALgBlAGQA dQAvAHMAcgBiAC8AAADgyep5+brOEYyCAKoAS6kLMgAAAGgAdAB0AHAAOgAvAC8AdwB3 AHcALgBzAGQAcwBjAC4AZQBkAHUALwBzAHIAYgAvAAAANQEAAEQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAMAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBw AHMAYwAuAGUAZAB1AC8AbgBlAHQAdwBvAHIAawBpAG4AZwAvAHAAcgBvAGoAZQBjAHQA cwAvAHQAYwBwAHQAdQBuAGUALwAAAODJ6nn5us4RjIIAqgBLqQtgAAAAaAB0AHQAcAA6 AC8ALwB3AHcAdwAuAHAAcwBjAC4AZQBkAHUALwBuAGUAdAB3AG8AcgBrAGkAbgBnAC8A cAByAG8AagBlAGMAdABzAC8AdABjAHAAdAB1AG4AZQAvAAAAJQEAAEQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAALAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcA LgByAGwAZwAuAG8AcgBnAC8AZQBuAC8AcABhAGcAZQAuAHAAaABwAD8AUABhAGcAZQBf AEkARAA9ADIAMAA3ADYAAADgyep5+brOEYyCAKoAS6kLWAAAAGgAdAB0AHAAOgAvAC8A dwB3AHcALgByAGwAZwAuAG8AcgBnAC8AZQBuAC8AcABhAGcAZQAuAHAAaABwAD8AUABh AGcAZQBfAEkARAA9ADIAMAA3ADYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASACUACgABAGkADwACAAAAAAAAACoAAEDx/wIA KgAMAAYATgBvAHIAbQBhAGwAAAAIAAAAAyQDYSQDBABtSAkEOAABQAEAAgA4AAwACQBI AGUAYQBkAGkAbgBnACAAMQAAAAgAAQAGJAFAJgALADUIgUNKGABLSBwAADwAAkABAAIA PAAMAAkASABlAGEAZABpAG4AZwAgADIAAAAQAAIABiQBDcYFAAGgBQBAJgEHADUIgUNK FgAAMAADQAEAAgAwAAwACQBIAGUAYQBkAGkAbgBnACAAMwAAAAgAAwAGJAFAJgIDADUI gQAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAEWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBh AGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAKABVQKIA8QAoAAAACQBIAHkA cABlAHIAbABpAG4AawAAAAYAPioBQioCKAD+TwEAAgEoAAwACABGAG8AbwB0AG4AbwB0 AGUAAAACABAABABDShAARgBDQAEAEgFGAAwAEABCAG8AZAB5ACAAVABlAHgAdAAgAEkA bgBkAGUAbgB0AAAAEAARAAMkAxGE9QBghPUAYSQDBABDShQATgBSQAEAIgFOAAwAEgBC AG8AZAB5ACAAVABlAHgAdAAgAEkAbgBkAGUAbgB0ACAAMgAAABAAEgADJAMRhPUAYIT1 AGEkAwcANgiBQ0oUAAAsAP5PAQAyASwADAAKAFIAZQBmAGUAcgBlAG4AYwBlAHMAAAAC ABMABABDShIAKgD+TwEAQgEqAAwABgBBAHUAdABoAG8AcgAAAAgAFAADJAFhJAEEAENK GABAAFNAAQBSAUAAAAASAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAIAAz AAAACgAVAA+EaAFehGgBAAA8AP5PAQBiATwADAALAFAAYQBnAGUAIABuAHUAbQBiAGUA cgAAAAgAFgADJAFhJAEMAE9KAwBRSgMAa0jkBDAAPkABAHIBMAAMAAUAVABpAHQAbABl AAAADAAXAAMkAROk4AFhJAEHADUIgUNKHAAALgD+TyEBggEuAAwADQBBAGIAcwB0AHIA YQBjAHQAIABUAGUAeAB0AAAAAgAYAAAAOAD+TwEAkgE4AAwACwBBAGYAZgBpAGwAaQBh AHQAaQBvAG4AAAAIABkAAyQBYSQBBwA2CIFDShgAAD4A/k8BAKIBPgAMAA4AQQBiAHMA dAByAGEAYwB0ACAAVABpAHQAbABlAAAACAAaAAMkAWEkAQcANQiBQ0oYAABWAP5PAQCy AVYADAAbAEYAaQBnAHUAcgBlACAAYQBuAGQAIABDAGEAcAB0AGkAbwBuACAAQwBhAHAA dABpAG8AbgBzAAAAAgAbAAsANQiBT0oEAFFKBAAAMAD+TwEAwgEwAAwACABDAGEAbABs AG8AdQB0AHMAAAACABwADABDShIAT0oEAFFKBABMAEJAAQDSAUwAAAAJAEIAbwBkAHkA IABUAGUAeAB0AAAACAAdAAMkAWEkAR8ANQiBOQiBQioLQ0oYAE9KAwBQSgMAUUoDAHBo AIAAAAAyAB1AAQDiATIAAAANAEYAbwBvAHQAbgBvAHQAZQAgAFQAZQB4AHQAAAACAB4A BABDShgAOAAmQKIA8QE4AAAAEgBGAG8AbwB0AG4AbwB0AGUAIABSAGUAZgBlAHIAZQBu AGMAZQAAAAMASCoBAOAA/k8BAAIC4AAAAA8ATABpAHMAdAAgACgAbgB1AG0AYgBlAHIA ZQBkACkAAACdACAAAyQACiYLC0b/Bw+E+AERhAj+EmTIAAAAE6Q8ADckADgkAD7GVAAB AQgAAAUAAAABAPgBAAAAAAAAWwBdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRmAAAA/16E+AFghAj+YSQADcYO AATQAnAIGBWcGAAAAAAAEQBCKgFPSgMAUUoDAHBoAAAAAABEACBAAQASAkQAAAAGAEYA bwBvAHQAZQByAAAAGQAhAAMkADckADgkAGEkAA3GCAAC4BDAIQECAAwAQ0oYAE9KAwBR SgMAQgAfQAEAIgJCAAAABgBIAGUAYQBkAGUAcgAAABMAIgADJABhJAANxggAAuAQwCEB AgAQAENKFgBPSgMAUEoDAFFKAwAkAFhAogAxAiQAAAAIAEUAbQBwAGgAYQBzAGkAcwAA AAMANgiBADIA/k8BAEICMgAMAAkAUABhAHIAYQBnAHIAYQBwAGgAAAAKACQAEYQcAWCE HAEEAG1ICQgp4gAAAAAAAAMAAAAMAAAAEAH//wEAAAAAABAA//8CAAAAAAAQAP//AwAA AAAAEAD//wQAAAAAABAA//8FAAAAAAAQAP//BgAAAAAAEAD//wcAAAAAABAA//8IAAAA AAAQAP//CQAAAAAAEAD//woAAAAAABAA//8LAAAAAAAQAP//DAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAEA AAAAAAIAAAAAAAMAAAAAAAQAAAAAAAUAAAAAAAYAAAAAAAcAAAAAAAgAAAAAAAkAAAAA AAoAAAAAAAsAAAAAAAAAAADNAAAAmaoAAEOuAAAp4gAAAwAAaAEACAD/////AwAeaAEA CAD/////AwBDaAEACAD/////AwBoaAEACAD/////DAAAAAQj//8BAKB6mQAAAv//AgCg epkABAL//wMAoHqZAAAC//8EAKB6mQAEAv//BQCgepkAAAL//wYAoHqZAAQC//8HAKB6 mQAAAv//CACgepkABAL//wkAoHqZAAAC//8KAKB6mQAEAv//CwCgepkAAAL//wwAoHqZ AAAAAADNAAAARggAAE0QAAAEGgAA9SQAADwtAAD9NwAASkMAAHVOAAC6WAAAomMAAMBt AAC2eAAA5IIAAHCNAAC5lQAANqAAAGylAACZqgAAQ64AANuuAAB7rwAAr7kAAEHBAADj ywAAYdYAAJjfAAAp4gAAAAAAAAACAAAAAAACAABGAAECAQAAAAACAQBBAQECAgAAAAAC AgA+AwECAwAAAAACAwBXAQECBAAAAAACBADOAAECBQAAAAACBQDCAAECBgAAAAACBgA4 AAECBwAAAAACBwCHAAECCAAAAAACCAAAAAECCAAAAAACCAAAAAACCAA8AQECCQAAAAAC CQAeAAECCgAAAAACCgDRAAECCwAAAAACCwAAAAECAAYAAEDHAAAp6AAAdQAAALEAAAAA BgAAMBcAAKUtAAA7QQAAEHIAAEWTAACjlAAAApUAAGiVAAC2lQAADJcAANqrAABpsQAA gbEAAJ2xAACysQAA07EAAOyxAAD6sQAAELIAACqyAAA/sgAAVrIAAGmyAACDsgAAnbIA ALGyAADHsgAA67IAAACzAAAfswAANLMAAEqzAABaswAAarMAAHezAACOswAAoLMAAL6z AADRswAA6rMAAP2zAAAUtAAAJbQAAEG0AADhuAAA+cYAAAnfAAAp6AAAdgAAAHgAAAB5 AAAAewAAAH0AAAB/AAAAgAAAAIEAAACDAAAAhAAAAIYAAACHAAAAiQAAAIoAAACLAAAA jAAAAI0AAACOAAAAjwAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAA AJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAApAAAAKUAAACmAAAApwAAAKgA AACpAAAAqgAAAKsAAACsAAAArgAAAK8AAACyAAAAAAYAAOQuAADoWgAAMZIAACGVAAD6 lQAAD7EAABCyAADYsgAAjrMAAEO0AABgxwAAJegAACnoAAB3AAAAegAAAHwAAAB+AAAA ggAAAIUAAACIAAAAkAAAAJoAAACjAAAArQAAALAAAACzAAAArBUAANQVAADtFQAA9TIA AB0zAAA2MwAA2p4AABmfAABJnwAAvOEAAPfhAAAj4gAAKeIAABNYFP8VgBNYFP8VhBNY FP8VhBNYFP8VhA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAAIAAAABAAAAAQAAAAMAAABA AB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIAAAAQAAjwCAAAAAEAAAACBAAADwAD 8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUA AAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAI AAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAACniAAD//wIAAAAJAE8ATABFAF8ATABJAE4A SwAxAAkATwBMAEUAXwBMAEkATgBLADIAVKcAAFSnAAAq4gAAAAAAAAEAAAC1pwAAtacA ACriAAAAAAAAQQAAAEYAAABiAAAAZwAAAGgAAABxAAAAnwAAAL8AAACmFQAAqhUAAO4y AADyMgAADUEAAA5BAAA/XwAARV8AAF5iAABfYgAAy3AAAM5wAAAPcQAAEXEAAHNyAAB3 cgAArHIAAK9yAAAhcwAAJnMAAE9zAABXcwAAWH4AAFx+AAC6jgAAvY4AAMOOAADHjgAA EY8AABiPAAAxjwAANY8AAF+PAABijwAAfY8AAIGPAACNjwAAkI8AAJ6PAACijwAAo48A AKiPAADAjwAAx48AAMyPAADUjwAA1Y8AANqPAADrjwAA7Y8AAPOPAAD5jwAA0pAAANmQ AACnkwAAsJMAAMCTAADSkwAA6ZMAAPCTAADzkwAA/JMAAP+TAAAGlAAAB5QAABKUAAAV lAAAGZQAABqUAAAhlAAAr5UAALaVAAC/nAAAxZwAAAidAAARnQAAFZ0AACKdAADDnQAA 0J0AAAuiAAARogAAnKIAAKKiAABopAAAbKQAABOnAAAapwAAWKcAAGOnAABkpwAAa6cA AGynAAB1pwAAdqcAAHqnAACFpwAAh6cAAIinAACKpwAAi6cAAI2nAACOpwAAkKcAAJWn AACapwAAp6cAAK6nAACvpwAAs6cAAOCnAADnpwAAaKgAAG+oAAA5qQAAQKkAACWrAAAs qwAAiKsAAJirAADUqwAA3asAAE6sAABUrAAApqwAAK+sAADLrAAA16wAANisAADkrAAA BK0AAAqtAAA4rQAAP60AAECtAABDrQAAe60AAIOtAACErQAAjK0AAI+tAACWrQAAsK0A ALOtAAC0rQAAt60AAOutAADzrQAACq4AAA2uAAAXrgAAGa4AACmuAAAvrgAAk64AAJqu AAAfsAAAJrAAAA6yAAAVsgAAqrMAALOzAACatAAAobQAAH62AACDtgAA+LkAAP+5AABS ugAAWboAAPy6AAADuwAAVbsAAFy7AADQuwAA17sAAP27AAAEvAAAxL0AAM+9AADUvQAA 3b0AAL6+AADHvgAAzL4AANe+AABjvwAAar8AAHW/AACEvwAAiL8AAJG/AACTvwAArr8A AK+/AAC6vwAAwb8AAMy/AADXvwAA4r8AAAHAAAAEwAAAM8AAAD7AAABCwAAAUsAAAGjA AAB4wAAAjsAAAJvAAAC9wAAAycAAANjAAADhwAAA48AAAObAAADnwAAA8sAAAPTAAAD4 wAAA+cAAAALBAAAEwQAADMEAACrBAAAwwQAA9MQAAPnEAADkyAAA6cgAACrLAAAvywAA uc4AAL7OAAC80QAAz9EAAFXUAABY1AAAXtQAAGLUAAB11AAAe9QAANLUAADZ1AAAMtUA ADbVAABf1QAAaNUAAHzVAACG1QAA09UAANbVAAD11QAA+9UAACLWAAAm1gAAWNYAAFvW AACH1gAAi9YAAIzWAACR1gAAytYAANHWAAAA1wAABtcAAF/XAABo1wAAatgAAHPYAAAc 2QAAJdkAAPDaAAD42gAAntsAAKLbAACx2wAAutsAADvcAABE3AAAWd0AAGbdAABr3QAA dN0AAIvdAACP3QAAkt0AAJ3dAABv3gAAeN4AAKDfAACp3wAAHeEAACXhAAAn4gAAKuIA AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABsABwAbAAcAGwAHABsABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAcAAAAA AJ8AAAC/AAAAhyQAALwkAAD5JQAAAiYAAA8rAAAQKwAAPC0AAIEtAADHLgAA8y4AAIgv AACeLwAAyS8AAB8wAADyMgAA9TIAADg8AAA8PAAAGkoAAIBKAACnTAAAqEwAAHJpAAB+ aQAAR3YAAEh2AABTiwAAhosAAPyPAABIkAAA85MAAPeTAAAHlAAADZQAABqUAAAelAAA f6QAAIWkAABaqQAAYakAAH2qAACGqgAAgasAAISrAACyqwAAtasAALarAAC6qwAAxKsA AMirAADtqwAA9asAABCsAAATrAAAFKwAABusAAA/rAAAQqwAAEmsAABNrAAAaawAAGys AAB1rAAAeqwAAJ2sAACgrAAAx6wAAMqsAADLrAAA16wAANisAADkrAAAAK0AAAOtAAA0 rQAAN60AADitAAA/rQAAQK0AAEOtAABarQAAXa0AAF6tAABnrQAAd60AAHqtAAB7rQAA g60AAIStAACMrQAAoa0AAKmtAAC0rQAAt60AANGtAADUrQAA3K0AAOOtAAD9rQAAAK4A AAquAAANrgAAJa4AACiuAAAprgAAL64AADCuAAA5rgAAbK8AAG+vAABXsAAAtbAAAIS2 AACPtgAALLkAADO5AABwvgAAdr4AAGO/AABnvwAAdb8AAHq/AACIvwAAkb8AAK+/AACz vwAAwb8AAMW/AADXvwAA3b8AADPAAAA3wAAAQsAAAEbAAABowAAAbMAAAI7AAACSwAAA vcAAAMHAAADYwAAA3MAAAOfAAADtwAAA+cAAAP3AAADNwgAAJcMAAE/IAACHyAAAeswA AF3NAAAn4gAAKuIAAAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcA OgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAH ADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoA BwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6 AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcA OgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAH ADoABwA6AAcAOgAHADoABwAHAP//FAAAAAwAUgBlAGEAZwBhAG4AIABNAG8AbwByAGUA XQBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AFUAcwBlAHIAcwA6AHIAZQBhAGcAYQBu AG0AbwBvAHIAZQA6AEQAbwBjAHUAbQBlAG4AdABzADoAcABhAHAAZQByAHMAOgBwAGEA cABlAHIAcwAtADIAMAAwADYAOgBlAC0AUwBjAGkAZQBuAGMAZQA6AGUAcwBjAGkAZQBu AGMAZQAtAHAAcgBvAGQALQBzAGgAbwByAHQALgBkAG8AYwAMAFIAZQBhAGcAYQBuACAA TQBvAG8AcgBlAFwATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBVAHMAZQByAHMAOgBy AGUAYQBnAGEAbgBtAG8AbwByAGUAOgBEAG8AYwB1AG0AZQBuAHQAcwA6AHAAYQBwAGUA cgBzADoAcABhAHAAZQByAHMALQAyADAAMAA2ADoAZQAtAFMAYwBpAGUAbgBjAGUAOgBl AHMAYwBpAGUAbgBjAGUALQBwAHIAbwBkAC0AbABvAG4AZwAuAGQAbwBjAAwAUgBlAGEA ZwBhAG4AIABNAG8AbwByAGUAXABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AFUAcwBl AHIAcwA6AHIAZQBhAGcAYQBuAG0AbwBvAHIAZQA6AEQAbwBjAHUAbQBlAG4AdABzADoA cABhAHAAZQByAHMAOgBwAGEAcABlAHIAcwAtADIAMAAwADYAOgBlAC0AUwBjAGkAZQBu AGMAZQA6AGUAcwBjAGkAZQBuAGMAZQAtAHAAcgBvAGQALQBsAG8AbgBnAC4AZABvAGMA DABSAGUAYQBnAGEAbgAgAE0AbwBvAHIAZQBcAE0AYQBjAGkAbgB0AG8AcwBoACAASABE ADoAVQBzAGUAcgBzADoAcgBlAGEAZwBhAG4AbQBvAG8AcgBlADoARABvAGMAdQBtAGUA bgB0AHMAOgBwAGEAcABlAHIAcwA6AHAAYQBwAGUAcgBzAC0AMgAwADAANgA6AGUALQBT AGMAaQBlAG4AYwBlADoAZQBzAGMAaQBlAG4AYwBlAC0AcAByAG8AZAAtAGwAbwBuAGcA LgBkAG8AYwAMAFIAZQBhAGcAYQBuACAATQBvAG8AcgBlAFwATQBhAGMAaQBuAHQAbwBz AGgAIABIAEQAOgBVAHMAZQByAHMAOgByAGUAYQBnAGEAbgBtAG8AbwByAGUAOgBEAG8A YwB1AG0AZQBuAHQAcwA6AHAAYQBwAGUAcgBzADoAcABhAHAAZQByAHMALQAyADAAMAA2 ADoAZQAtAFMAYwBpAGUAbgBjAGUAOgBlAHMAYwBpAGUAbgBjAGUALQBwAHIAbwBkAC0A bABvAG4AZwAuAGQAbwBjAAwAUgBlAGEAZwBhAG4AIABNAG8AbwByAGUAXABNAGEAYwBp AG4AdABvAHMAaAAgAEgARAA6AFUAcwBlAHIAcwA6AHIAZQBhAGcAYQBuAG0AbwBvAHIA ZQA6AEQAbwBjAHUAbQBlAG4AdABzADoAcABhAHAAZQByAHMAOgBwAGEAcABlAHIAcwAt ADIAMAAwADYAOgBlAC0AUwBjAGkAZQBuAGMAZQA6AGUAcwBjAGkAZQBuAGMAZQAtAHAA cgBvAGQALQBsAG8AbgBnAC4AZABvAGMADABSAGUAYQBnAGEAbgAgAE0AbwBvAHIAZQBc AE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoAVQBzAGUAcgBzADoAcgBlAGEAZwBhAG4A bQBvAG8AcgBlADoARABvAGMAdQBtAGUAbgB0AHMAOgBwAGEAcABlAHIAcwA6AHAAYQBw AGUAcgBzAC0AMgAwADAANgA6AGUALQBTAGMAaQBlAG4AYwBlADoAZQBzAGMAaQBlAG4A YwBlAC0AcAByAG8AZAAtAGwAbwBuAGcALgBkAG8AYwAMAFIAZQBhAGcAYQBuACAATQBv AG8AcgBlAFwATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBVAHMAZQByAHMAOgByAGUA YQBnAGEAbgBtAG8AbwByAGUAOgBEAG8AYwB1AG0AZQBuAHQAcwA6AHAAYQBwAGUAcgBz ADoAcABhAHAAZQByAHMALQAyADAAMAA2ADoAZQAtAFMAYwBpAGUAbgBjAGUAOgBlAHMA YwBpAGUAbgBjAGUALQBwAHIAbwBkAC0AbABvAG4AZwAuAGQAbwBjAAwAUgBlAGEAZwBh AG4AIABNAG8AbwByAGUAXABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AFUAcwBlAHIA cwA6AHIAZQBhAGcAYQBuAG0AbwBvAHIAZQA6AEQAbwBjAHUAbQBlAG4AdABzADoAcABh AHAAZQByAHMAOgBwAGEAcABlAHIAcwAtADIAMAAwADYAOgBlAC0AUwBjAGkAZQBuAGMA ZQA6AGUAcwBjAGkAZQBuAGMAZQAtAHAAcgBvAGQALQBsAG8AbgBnAC4AZABvAGMADABS AGUAYQBnAGEAbgAgAE0AbwBvAHIAZQBcAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoA VQBzAGUAcgBzADoAcgBlAGEAZwBhAG4AbQBvAG8AcgBlADoARABvAGMAdQBtAGUAbgB0 AHMAOgBwAGEAcABlAHIAcwA6AHAAYQBwAGUAcgBzAC0AMgAwADAANgA6AGUALQBTAGMA aQBlAG4AYwBlADoAZQBzAGMAaQBlAG4AYwBlAC0AcAByAG8AZAAtAGwAbwBuAGcALgBk AG8AYwAdADcIWwlm2eLo/w//D/8P/w//D/8P/w//D/8PEAA7XLgKDkvUFv8P/w//D/8P /w//D/8P/w//DxAA7TZZDf4E8Kn/D/8P/w//D/8P/w//D/8P/w8QAPx5PxDw04yC/w// D/8P/w//D/8P/w//D/8PEABmHEwStE8UR/8P/w//D/8P/w//D/8P/w//DxAAU3fWFbyD qNb/D/8P/w//D/8P/w//D/8P/w8QAKpSZhsKWzYA/w//D/8P/w//D/8P/w//D/8PEACW XWYegB/cI/8P/w//D/8P/w//D/8P/w//DxAAtyztIT6ZpkD/D/8P/w//D/8P/w//D/8P /w8QAAppTCJuXVTX/w//D/8P/w//D/8P/w//D/8PEADPazUjTPFSQ/8P/w//D/8P/w// D/8P/w//DxAAQHc2LtAddGn/D/8P/w//D/8P/w//D/8P/w8QAFdPCzRUL0AZ/w//D/8P /w//D/8P/w//D/8PEABZRp06IoX6I/8P/w//D/8P/w//D/8P/w//DxAAd20NPDR/6Ir/ D/8P/w//D/8P/w//D/8P/w8QAE9l8j+YKHrK/w//D/8P/w//D/8P/w//D/8PEACCVQNI nuqmYv8P/w//D/8P/w//D/8P/w//DxAAOHDJVBwfiOX/D/8P/w//D/8P/w//D/8P/w8Q ALJ/EF3Of1pJ/w//D/8P/w//D/8P/w//D/8PEACINUVf6pkCy/8P/w//D/8P/w//D/8P /w//DxAAYR02ZaIP7Ir/D/8P/w//D/8P/w//D/8P/w8QAKQS42X03miX/w//D/8P/w// D/8P/w//D/8PEABmJuxqZELgfP8P/w//D/8P/w//D/8P/w//DxAAK27Ra4KzIFH/D/8P /w//D/8P/w//D/8P/w8QACFqHW/c+QCh/w8AAAAAAAAAAAAAAAAAAAAAAQBYQjBwIhcu +f8P/w//D/8P/w//D/8P/w//DxAAyVDTck45sN3/D/8P/w//D/8P/w//D/8P/w8QALxx W31QPBID/w//D/8P/w//D/8P/w//D/8PEAA/Ha5/FsKuZP8P/w//D/8P/w//D/8P/w// DxAAAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EXQIRhJj+FcYFAAFdAgZehF0C YISY/k9KAQBRSgEAbygAAQC38AQAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhC0F EYSY/hXGBQABLQUGXoQtBWCEmP5PSgAAUEoAAFFKAABvKAABAC0AAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+E/QcRhJj+FcYFAAH9BwZehP0HYISY/k9KBgBRSgYAbygA AQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhM0KEYSY/hXGBQABzQoGXoTN CmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Sd DRGEmP4VxgUAAZ0NBl6EnQ1ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAACxgAAA+EbRARhJj+FcYFAAFtEAZehG0QYISY/k9KBgBRSgYAbygAAQCn 8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhD0TEYSY/hXGBQABPRMGXoQ9E2CE mP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QNFhGE mP4VxgUAAQ0WBl6EDRZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+E3RgRhJj+FcYFAAHdGAZehN0YYISY/k9KBgBRSgYAbygAAQCn8AEA AAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhF0CEYSY/hXGBQABXQIGXoRdAmCEmP5P SgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QtBRGEmP4V xgUAAS0FBl6ELQVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+E/QcRhJj+FcYFAAH9BwZehP0HYISY/k9KBgBRSgYAbygAAQCn8AEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhM0KEYSY/hXGBQABzQoGXoTNCmCEmP5PSgEA UUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SdDRGEmP4VxgUA AZ0NBl6EnQ1ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA CxgAAA+EbRARhJj+FcYFAAFtEAZehG0QYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhD0TEYSY/hXGBQABPRMGXoQ9E2CEmP5PSgEAUUoB AG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QNFhGEmP4VxgUAAQ0W Bl6EDRZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+E3RgRhJj+FcYFAAHdGAZehN0YYISY/k9KBgBRSgYAbygAAQCn8AEAAAAAEAEAAAAA AAAAAAAAAAAAAAAAAAMYAAAPhHwBEYSE/hXGBQABfAEGXoR8AWCEhP5vKAACAAAALgAB AAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+ AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZe hHAIYIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXG BQABQAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQ DhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAA AAAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABIABAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAA AAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIA CAAuAAAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQ AmCEmP5PSgMAUEoDAFFKAwBvKAABAC0AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8o AAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6E QAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E EA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgYAUUoGAG8oAAEA p/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNg hJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYR hJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgYAUUoGAG8oAAEAp/AB AAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+ T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EOAQRhJj+ FcYFAAE4BAZehDgEYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oB AFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwRhJj+FcYF AAGoDAZehKgMYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+T0oBAFFK AQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EGBURhJj+FcYFAAEY FQZehBgVYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsY AAAPhOgXEYSY/hXGBQAB6BcGXoToF2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAAFxAAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBv KAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EOAQRhJj+FcYFAAE4BAZe hDgEYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAA AAAAaAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oBAFFKAQBvKAAB ALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwRhJj+FcYFAAGoDAZehKgM YISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhHgP EYSY/hXGBQABeA8GXoR4D2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+T0oBAFFKAQBvKAABALfw AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZehBgVYISY /k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOgXEYSY /hXGBQAB6BcGXoToF2CEmP5PSgYAUUoGAG8oAAEAp/AAAAAAFxAAAAAAAAAAAAAAaAEA AAAAAAAPGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oDAFBKAwBRSgMAbygAAQAt AAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCE mP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QIBxGE mP4VxgUAAQgHBl6ECAdghJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAQBRSgEAbygAAQC38AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhKgMEYSY/hXGBQABqAwGXoSoDGCEmP5P SgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4R4DxGEmP4V xgUAAXgPBl6EeA9ghJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/k9KAQBRSgEAbygAAQC38AEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP5PSgUA UUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4ToFxGEmP4VxgUA AegXBl6E6BdghJj+T0oGAFFKBgBvKAABAKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoF AG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGEmP4VxgUAAXAI Bl6EcAhghJj+T0oGAFFKBgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgUAUUoFAG8o AAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E 4BBghJj+T0oGAFFKBgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E sBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEA bwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlg hJj+T0oGAFFKBgBvKAABAKfwAAAAABcQAAAAAAAAAAAAAGgBAAAAAAAADxgAAA+E0AIR hJj+FcYFAAHQAgZehNACYISY/k9KAABQSgMAUUoAAG8oAAEALQABAAAAFxAAAAAAAAAA AAAAaAEAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAAB AG8AAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAI YISY/k9KBgBRSgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8A AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY /k9KBgBRSgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9K BgBRSgYAbygAAQCn8AAAAAAXEAAAAAAAAAAAAABoAQAAAAAAAA8YAAAPhAgHEYSY/hXG BQABCAcGXoQIB2CEmP5PSgAAUEoDAFFKAABvKAABAC0AAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KBQBRSgUAbygAAQBvAAEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhKgMEYSY/hXGBQABqAwGXoSoDGCEmP5P SgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4R4DxGEmP4V xgUAAXgPBl6EeA9ghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/k9KBQBRSgUAbygAAQBvAAEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP5PSgYA UUoGAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4ToFxGEmP4VxgUA AegXBl6E6BdghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA CxgAAA+EuBoRhJj+FcYFAAG4GgZehLgaYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhIgdEYSY/hXGBQABiB0GXoSIHWCEmP5PSgYAUUoG AG8oAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgB Bl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+EOAQRhJj+FcYFAAE4BAZehDgEYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAA AAAAAABoAQAAAAAAAAsYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgYAUUoGAG8o AAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E 2AlghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E qAwRhJj+FcYFAAGoDAZehKgMYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAA AABoAQAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgYAUUoGAG8oAAEA p/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJg hJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EGBUR hJj+FcYFAAEYFQZehBgVYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhOgXEYSY/hXGBQAB6BcGXoToF2CEmP5PSgYAUUoGAG8oAAEAp/AA AAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAPGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+ T0oAAFBKAwBRSgAAbygAAQAtAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhDgE EYSY/hXGBQABOAQGXoQ4BGCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+T0oGAFFKBgBvKAABAKfw AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E2AkRhJj+FcYFAAHYCQZehNgJYISY /k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhKgMEYSY /hXGBQABqAwGXoSoDGCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oGAFFKBgBvKAABAKfwAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/k9K AQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBgVEYSY/hXG BQABGBUGXoQYFWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4ToFxGEmP4VxgUAAegXBl6E6BdghJj+T0oGAFFKBgBvKAABAKfwAAAAABcQ AAAAAAAAAAAAAGgBAAAAAAAADxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAABQ SgMAUUoAAG8oAAEALQABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Q4BBGEmP4V xgUAATgEBl6EOARghJj+T0oFAFFKBQBvKAABAG8AAQAAABcQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/k9KBgBRSgYAbygAAQCn8AEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgEA UUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4VxgUA AagMBl6EqAxghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA CxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5PSgEAUUoB AG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgV Bl6EGBVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+E6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXEAAAAAAA AAAAAABoAQAAAAAAAAsYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8o AAEAt/ABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6E oAVghJj+AgABAC4AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EcAgRhJj+FcYF AAFwCAZehHAIYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFK BQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E4BARhJj+FcYFAAHg EAZehOAQYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsY AAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBv KAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZe hFAZYISY/k9KBgBRSgYAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAP hNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAAB AG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAI YISY/k9KBgBRSgYAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8A AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY /k9KBgBRSgYAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9K BgBRSgYAbygAAQCn8AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhGgBEYSY/hXG BQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/k9KBgBR SgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB 2AkGXoTYCWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAL GAAAD4SoDBGEmP4VxgUAAagMBl6EqAxghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KBgBRSgYA bygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIG XoRIEmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+E6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KBgBRSgYAbygA AQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhNACEYSY/hXGBQAB0AIGXoTQ AmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Sg BRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KBgBRSgYAbygAAQCn 8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CE mP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QQDhGE mP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBgBRSgYAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5P SgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SAFhGEmP4V xgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBgBRSgYAbygAAQCn8AAAAAAX EAAAAAAAAAAAAABoAQAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgAA UEoDAFFKAABvKAABAC0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oB AFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EEA4RhJj+FcYF AAEQDgZehBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFK AQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGA FgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgYAUUoGAG8oAAEAp/ABAAAAABABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAgAA AAAQAQAAAAAAAAAAAGgBAAAAAAAAHhgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/jUI ADYIAEIqAUNKFABPSgAAUUoAAG8oAHBoAAAAAAIAAQAuAAEAAAACEgEAAAAAAAAAAABo AQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAA AASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIA BAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTg EGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUA AbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYR hJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAY AAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgAAAAAAFxAAAAAAAAAAAAAAaAEA AAAAAAAPGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oAAFBKAwBRSgAAbygAAQAt AAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCE mP5PSgUAUUoFAG8oAAEAbwABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RwCBGE mP4VxgUAAXAIBl6EcAhghJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5P SgUAUUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TgEBGEmP4V xgUAAeAQBl6E4BBghJj+T0oGAFFKBgBvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUA UUoFAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RQGRGEmP4VxgUA AVAZBl6EUBlghJj+T0oGAFFKBgBvKAABAKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EdgIRhJj+FcYFAAF2AgZehHYCYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhEYFEYSY/hXGBQABRgUGXoRGBWCEmP5PSgUAUUoF AG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4QWCBGEmP4VxgUAARYI Bl6EFghghJj+T0oGAFFKBgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+E5goRhJj+FcYFAAHmCgZehOYKYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhLYNEYSY/hXGBQABtg0GXoS2DWCEmP5PSgUAUUoFAG8o AAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SGEBGEmP4VxgUAAYYQBl6E hhBghJj+T0oGAFFKBgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E VhMRhJj+FcYFAAFWEwZehFYTYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhCYWEYSY/hXGBQABJhYGXoQmFmCEmP5PSgUAUUoFAG8oAAEA bwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4T2GBGEmP4VxgUAAfYYBl6E9hhg hJj+T0oGAFFKBgBvKAABAKfwAAAAABcQAAAAAAAAAAAAAGgBAAAAAAAADxgAAA+E0AIR hJj+FcYFAAHQAgZehNACYISY/k9KAABQSgMAUUoAAG8oAAEALQABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAAB AG8AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAI YISY/k9KBgBRSgYAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8A AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY /k9KBgBRSgYAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9K BgBRSgYAbygAAQCn8AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhF0CEYSY/hXG BQABXQIGXoRdAmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4QtBRGEmP4VxgUAAS0FBl6ELQVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E/QcRhJj+FcYFAAH9BwZehP0HYISY/k9KBgBR SgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhM0KEYSY/hXGBQAB zQoGXoTNCmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAL GAAAD4SdDRGEmP4VxgUAAZ0NBl6EnQ1ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAACxgAAA+EbRARhJj+FcYFAAFtEAZehG0QYISY/k9KBgBRSgYA bygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhD0TEYSY/hXGBQABPRMG XoQ9E2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4QNFhGEmP4VxgUAAQ0WBl6EDRZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAACxgAAA+E3RgRhJj+FcYFAAHdGAZehN0YYISY/k9KBgBRSgYAbygA AQCn8AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhF0CEYSY/hXGBQABXQIGXoRd AmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Qt BRGEmP4VxgUAAS0FBl6ELQVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAACxgAAA+E/QcRhJj+FcYFAAH9BwZehP0HYISY/k9KBgBRSgYAbygAAQCn 8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhM0KEYSY/hXGBQABzQoGXoTNCmCE mP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SdDRGE mP4VxgUAAZ0NBl6EnQ1ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+EbRARhJj+FcYFAAFtEAZehG0QYISY/k9KBgBRSgYAbygAAQCn8AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhD0TEYSY/hXGBQABPRMGXoQ9E2CEmP5P SgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QNFhGEmP4V xgUAAQ0WBl6EDRZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+E3RgRhJj+FcYFAAHdGAZehN0YYISY/k9KBgBRSgYAbygAAQCn8AEAAAAA AAIAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5DShIA T0oAAFFKAABvKAADAFsAAABdAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNAC EYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAABAG8A AQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY /k9KBgBRSgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEALEYSY /hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9K BgBRSgYAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhLATEYSY/hXG BQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBgBR SgYAbygAAQCn8AAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB 0AIGXoTQAmCEmP5PSgMAUEoDAFFKAwBvKAABAC0AAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgYA UUoGAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUA AUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgYAUUoG AG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SwExGEmP4VxgUAAbAT Bl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgYAUUoGAG8o AAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6E aAFghJj+T0oBAFFKAQBvKAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E OAQRhJj+FcYFAAE4BAZehDgEYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXEAAAAAAAAAAA AABoAQAAAAAAAAsYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgYAUUoGAG8oAAEA p/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2Alg hJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwR hJj+FcYFAAGoDAZehKgMYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgYAUUoGAG8oAAEAp/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+ T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EGBURhJj+ FcYFAAEYFQZehBgVYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhOgXEYSY/hXGBQAB6BcGXoToF2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oB AFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EOAQRhJj+FcYF AAE4BAZehDgEYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAA AAsYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4TYCRGEmP4VxgUAAdgJBl6E2AlghJj+T0oBAFFK AQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EqAwRhJj+FcYFAAGo DAZehKgMYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsY AAAPhHgPEYSY/hXGBQABeA8GXoR4D2CEmP5PSgYAUUoGAG8oAAEAp/ABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4RIEhGEmP4VxgUAAUgSBl6ESBJghJj+T0oBAFFKAQBv KAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EGBURhJj+FcYFAAEYFQZe hBgVYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hOgXEYSY/hXGBQAB6BcGXoToF2CEmP5PSgYAUUoGAG8oAAEAp/AdAAAAO1y4CgAAAAAA AAAAAAAAAGYm7GoAAAAAAAAAAAAAAAA3CFsJAAAAAAAAAAAAAAAAT2XyPwAAAAAAAAAA AAAAACtu0WsAAAAAAAAAAAAAAABmHEwSAAAAAAAAAAAAAAAAPx2ufwAAAAAAAAAAAAAA AM9rNSMAAAAAAAAAAAAAAABZRp06AAAAAAAAAAAAAAAAWEIwcAAAAAAAAAAAAAAAALxx W30AAAAAAAAAAAAAAAD8eT8QAAAAAAAAAAAAAAAAqlJmGwAAAAAAAAAAAAAAAMlQ03IA AAAAAAAAAAAAAABXTws0AAAAAAAAAAAAAAAAsn8QXQAAAAAAAAAAAAAAAAppTCIAAAAA AAAAAAAAAAA4cMlUAAAAAAAAAAAAAAAApBLjZQAAAAAAAAAAAAAAAIg1RV8AAAAAAAAA AAAAAAC3LO0hAAAAAAAAAAAAAAAAQHc2LgAAAAAAAAAAAAAAAFN31hUAAAAAAAAAAAAA AADtNlkNAAAAAAAAAAAAAAAAIWodbwAAAAAAAAAAAAAAAHdtDTwAAAAAAAAAAAAAAACC VQNIAAAAAAAAAAAAAAAAll1mHgAAAAAAAAAAAAAAAGEdNmUAAAAAAAAAAAAAAAD///// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// ////////////////HQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//x0AAAASAATnRApQmwz6BQAJBAEACQQDAAkE BQAJBAEACQQDAAkEBQAJBBIABOdECgMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQF AAkEEgCSUto2GQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAP////////// /////////////////////////////////////xIABOdECgMACQQFAAkEAQAJBAMACQQF AAkEAQAJBAMACQQFAAkEEgAE50QKAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUA CQQSAP///////////////////////////////////////////////xIABOdECgMACQQF AAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgB2m/yRAwAJBAUACQQBAAkEAwAJBAUA CQQBAAkEAwAJBAUACQQSAHab/JEDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJ BBIABOdECgMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgB2m/yRAwAJBAUA CQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAHab/JEDAAkEBQAJBAEACQQDAAkEBQAJ BAEACQQDAAkEBQAJBBIA/////w8ACQT///////////////////////////////////// EgAE50QKAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAATnRAoDAAkEBQAJ BAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIABOdECgMACQQFAAkEAQAJBAMACQQFAAkE AQAJBAMACQQFAAkEEgB2m/yRAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQS AA8ACQS0a/owGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIAdpv8kQMACQQFAAkE AQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgAE50QKAwAJBAUACQQBAAkEAwAJBAUACQQB AAkEAwAJBAUACQQSAHab/JEDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIA BOdECgMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgAE50QKAwAJBAUACQQB AAkEAwAJBAUACQQBAAkEAwAJBAUACQQAABIA//////////////////////////////// ////////////////EgD///////////////////////////////////////////////8S AP///////////////////////////////////////////////xIABOdECgMACQQFAAkE AQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAAAAAH8AAAAtjgAAWY4AAGGOAABrjgAAg44A AISOAACOjgAAk44AAKOOAACkjgAAq44AALCOAADIjgAAyY4AANWOAADYjgAA5o4AAOeO AADqjgAA7Y4AAPuOAAD8jgAAAo8AAAiPAAAZjwAAGo8AACGPAAAnjwAANo8AADePAAA9 jwAAQY8AAE6PAABPjwAAVo8AAFuPAABojwAAaY8AAHKPAAB3jwAAgo8AAIOPAACGjwAA jY8AAJaPAACXjwAAmo8AAJ6PAACpjwAAqo8AALaPAAC7jwAAyI8AAMmPAADMjwAA1Y8A AOSPAADljwAA6Y8AAO6PAAD6jwAA+48AAJiqAACaqgAA/aoAAAerAAAPqwAAG6sAAC2r AAA7qwAAWasAAGmrAABqqwAAb6sAAHmrAACBqwAAhasAAIirAACZqwAAnasAAJ6rAACj qwAArKsAALKrAAC2qwAAxKsAANKrAADTqwAA1KsAAN6rAADkqwAA7KsAAPerAAD4qwAA +asAAPqrAAD7qwAAAawAAAisAAAQrAAAFKwAABysAAAkrAAAKqwAACusAAAxrAAAN6wA AD+sAABDrAAASawAAFWsAABWrAAAV6wAAFusAABhrAAAaawAAG2sAAB1rAAAf6wAAIOs AACErAAAiawAAJWsAACdrAAAoawAAKasAACwrAAAsawAALKsAAC1rAAAwawAAMesAADL rAAA2KwAAOWsAADrrAAA7KwAAPGsAAD4rAAAAK0AAAStAAALrQAAGa0AAB+tAAAgrQAA Ja0AACytAAA0rQAAOK0AAECtAABJrQAASq0AAEutAABPrQAAUq0AAFqtAABerQAAaK0A AGmtAABqrQAAa60AAG6tAABxrQAAd60AAHutAACErQAAja0AAI6tAACPrQAAl60AAJqt AACgrQAAq60AALStAAC9rQAAvq0AAL+tAADGrQAAya0AANGtAADVrQAA3K0AAOStAADq rQAA660AAPStAAD3rQAA/a0AAAGuAAAKrgAAE64AABSuAAAVrgAAGq4AAB2uAAAlrgAA Ka4AADCuAABArgAAQa4AAEKuAAAm4gAAKuIAAAAAAAABAAAAAbOzBAgAAAACAQAAAgEA AAIBAACeAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIB AACeAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACe AQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACeAQAA AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAACeAQAAAgEA AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAJYBAAANw7MEBcOzBAgAAAACAQAAAgEAAAIB AAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACe AQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAA AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEA AAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIB AAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAAC AQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAA ngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEA AAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIB AAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAAC AQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAA AgEAAAIBAAACAQAAAgEAAAIBAACWAQAAKTMUAP9AAYABAFTBAABUwQAAnKj6BmsAawBU wQAAAAAAAFTBAAAAAAAAswLI/z8FpQICEAAAAAAAAAAp4gAAMAAADABAAAAHAAAARwaQ AQAAAAICBgMFBAUCAwAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAgAE4A ZQB3ACAAUgBvAG0AYQBuAAAANQaQAQIAAAIABQAAAAAAAAAAAAAQAAAAAAAAAAAAAAAA AACAAAAAAFMAeQBtAGIAbwBsAAAAMwaQAQAAAAILBgQCAgICAgAAAAMAAAAAAAAAAAAA AAABAAAAAAAAAEEAcgBpAGEAbAAAADMGkAEAAAACAAUAAAAAAAAAAAADAAAAAAAAAAAA AAAAAQAAAAAAAABUAGkAbQBlAHMAAAA7BpABAAAAAgAFAAAAAAAAAAAAAwAAAAAAAAAA AAAAAAEAAAAAAAAASABlAGwAdgBlAHQAaQBjAGEAAAA/BpABAAAAAgcDCQICBQIEAAAA AwAAAAAAAAAAAAAAAAEAAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAOwaQAQIA AAUCAQIBCAQIBwAAAAAQAAAAAAAAAAAAAAAAAACAAAAAAFcAaQBuAGcAZABpAG4AZwBz AAAAIgAEAHEIjJgA8NACAABoAQAAAABKhKhmpISoZs9CqEYKAA4AAACcIAAA47kAAAwA XwAAAAQAgxCMAQAAhgMAABYUAAAMAAoAAAAqAAAAAAAAACEDAPAQhAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAA BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAA ABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0A AAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAq AAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA NwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAA AEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAA AABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABd AAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAA agAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAA AHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAAAACBAAAAggAAAIMA AACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQ AAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAA nQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAACoAAAAqQAA AKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0AAAA/v///7YA AAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAD+////vgAAAL8AAADAAAAAwQAAAMIAAADD AAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA 0AAAANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAA AN0AAADeAAAA3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkA AADqAAAA6wAAAOwAAADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2 AAAA9wAAAAEBAAD9/////f////sAAAD+/////v////4AAAD/AAAAAgEAAFIAbwBvAHQA IABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUB//////////8CAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAAB4 BuViwcYB/QAAAEAGAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC1AAAAABAAAAAAAAAxAFQAYQBi AGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADgACAQEAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAL0AAAAjdwAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBgAAAP//////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI1oAQAAAAAABQBTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACgAAgADAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAzAEAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5 AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAACkAwAAAAAAAAEAQwBv AG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAFwAAAFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA AgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA/v///wkAAAAKAAAACwAAAAwAAAANAAAADgAA AA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAA/v///xgAAAD+//////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////7/ AAADCgEAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAAS AAAAAQAAAJgAAAACAAAAoAAAAAMAAADAAAAABAAAAMwAAAAFAAAA5AAAAAYAAADwAAAA BwAAAPwAAAAIAAAADAEAAAkAAAAkAQAAEgAAADABAAAKAAAATAEAAAsAAABYAQAADAAA AGQBAAANAAAAcAEAAA4AAAB8AQAADwAAAIQBAAAQAAAAjAEAABMAAACUAQAAAgAAABAn AAAeAAAAGAAAAEF1dGhvciBHdWlkZWxpbmVzIGZvciA4AB4AAAAEAAAAAAAAAB4AAAAQ AAAAVGhvbWFzIEJhbGR3aW4AAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAIAAAA Tm9ybWFsAAAeAAAAEAAAAFJlYWdhbiBNb29yZQAAAAAeAAAABAAAADEwAAAeAAAAFAAA AE1pY3Jvc29mdCBXb3JkIDEwLjEAQAAAAADUrfQBAAAAQAAAAADqoI8Wu8YBQAAAAAD8 uHqRwcYBQAAAAACAUn6dwcYBAwAAAAwAAAADAAAAnCAAAAMAAADjuQAAAwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN 1ZwuGxCTlwgAKyz5rmgBAAAkAQAADQAAAAEAAABwAAAADwAAAHgAAAAEAAAAmAAAAAUA AACgAAAABgAAAKgAAAARAAAAsAAAABcAAAC4AAAACwAAAMAAAAAQAAAAyAAAABMAAADQ AAAAFgAAANgAAAANAAAA4AAAAAwAAAAEAQAAAgAAABAnAAAeAAAAGAAAAElFRUUgQ29t cHV0ZXIgU29jaWV0eQAAAAMAAAAAUgAAAwAAAIwBAAADAAAAXwAAAAMAAABI5AAAAwAA AAgBCgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAGAAAAEF1 dGhvciBHdWlkZWxpbmVzIGZvciA4AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAA AAAAPAIAAAMAAAAAAAAAIAAAAAEAAAA4AAAAAgAAAEAAAAABAAAAAgAAAAwAAABfUElE X0hMSU5LUwACAAAAECcAAEEAAAD0AQAAGAAAAAMAAABRABkAAwAAAAkAAAADAAAAAAAA AAMAAAAFAAAAHwAAACwAAABoAHQAdABwADoALwAvAHcAdwB3AC4AcgBsAGcALgBvAHIA ZwAvAGUAbgAvAHAAYQBnAGUALgBwAGgAcAA/AFAAYQBnAGUAXwBJAEQAPQAyADAANwA2 AAAAHwAAAAEAAAAAAAAAAwAAAGsAXwADAAAABgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA MAAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBwAHMAYwAuAGUAZAB1AC8AbgBlAHQAdwBv AHIAawBpAG4AZwAvAHAAcgBvAGoAZQBjAHQAcwAvAHQAYwBwAHQAdQBuAGUALwAAAB8A AAABAAAAAAAAAAMAAAATAFYAAwAAAAMAAAADAAAAAAAAAAMAAAAFAAAAHwAAABkAAABo AHQAdABwADoALwAvAHcAdwB3AC4AcwBkAHMAYwAuAGUAZAB1AC8AcwByAGIALwAAAAAA HwAAAAEAAAAAAAAAAwAAABMAVgADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGQAA AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBzAGQAcwBjAC4AZQBkAHUALwBzAHIAYgAvAAAA AAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wIAAQD/ ////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAD+//// TkI2V/3////+/////v////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// ////////AAAAAAAAAKUGwAe0ALQAgAA+MAAAEAAZAGQAAAAZAAAASOQAAJwXAAAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANqeAAAdAAkAAAAAAAAAAAAA AAAAAAACAAAAtAIAAQAADTODUQDwEITf3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABIWP//EgAAAAAAAAAXAEEAdQB0AGgAbwByACAARwB1AGkAZABlAGwAaQBuAGUAcwAg AGYAbwByACAAOAAAAAAAAAAOAFQAaABvAG0AYQBzACAAQgBhAGwAZAB3AGkAbgAMAFIA ZQBhAGcAYQBuACAATQBvAG8AcgBlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAQAAAAV29yZC5Eb2N1bWVudC44AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA== --============_-1056268349==_============-- From owner-vospace@eso.org Fri Aug 18 12:02:25 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IA1u3R019751 for ; Fri, 18 Aug 2006 12:01:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7IA1u6P019750 for vospace-outgoing; Fri, 18 Aug 2006 12:01:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IA1qDV019720 for ; Fri, 18 Aug 2006 12:01:52 +0200 (MEST) Received: from esa-av-smtp1.gmessaging.net (esa-av-smtp1.gmessaging.net [194.51.201.22]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7IA1nLY004380 for ; Fri, 18 Aug 2006 12:01:49 +0200 (CEST) Received: from esa-spas2.gmessaging.net (relay [172.24.21.38]) by esa-av-smtp1.gmessaging.net (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTP id <0J4600LP8UIUYI@esa-av-smtp1.gmessaging.net> for vospace@ivoa.net; Fri, 18 Aug 2006 12:01:44 +0200 (MEST) Received: from localhost (esa-spas2 [127.0.0.1]) by localhost.esa.gmessaging.net (Postfix) with ESMTP id 4AEF5219F88; Fri, 18 Aug 2006 12:01:43 +0200 (CEST) Received: from esa-spas2.gmessaging.net ([127.0.0.1]) by localhost (esa-spas2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02765-01-7; Fri, 18 Aug 2006 12:01:39 +0200 (CEST) Received: from sciops-mailgw.vilspa.esa.int (sciops-mailgw.vilspa.esa.int [193.147.152.105]) by esa-spas2.gmessaging.net (Postfix) with ESMTP id 52E1621A1FC; Fri, 18 Aug 2006 11:26:42 +0200 (CEST) Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100]) by sciops-mailgw.vilspa.esa.int (Postfix) with ESMTP id 5230011F8EF; Fri, 18 Aug 2006 11:26:42 +0200 (CEST) Received: from www.iso.vilspa.esa.es (www.iso.vilspa.esa.es [193.147.153.243]) by iso.vilspa.esa.es (8.13.6/8.13.6) with ESMTP id k7I9QfDw006041; Fri, 18 Aug 2006 11:26:42 +0200 (MEST) Received: from www.iso.vilspa.esa.es (localhost [127.0.0.1]) by www.iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id k7I9QfdU002259; Fri, 18 Aug 2006 11:26:41 +0200 (MEST) Received: (from nobody@localhost) by www.iso.vilspa.esa.es (8.12.10/8.12.10/Submit) id k7I9QbW6002256; Fri, 18 Aug 2006 11:26:37 +0200 (MEST) Received: from 80.187.153.98 ([80.187.153.98]) by webmail.iso.vilspa.esa.es (IMP) with HTTP for ; Fri, 18 Aug 2006 11:26:36 +0200 Date: Fri, 18 Aug 2006 11:26:36 +0200 From: Christophe.Arviset@esa.int Subject: Re: Fwd: Amazon VOStore? In-reply-to: <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> X-Originating-IP: 80.187.153.98 To: Roy Williams Cc: vospace@ivoa.net Message-id: <1155893196.44e587ccd5757@webmail.iso.vilspa.esa.es> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Spam-Score: Content analysis details: (-0.2 points, 4.5 points required to be considered as spam) 0.2 NO_REAL_NAME From: does not include a real name -0.4 BAYES_01 BODY: Bayesian spam probability is 1 to 10% [score: 0.0124] References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> X-Authentication-warning: www.iso.vilspa.esa.es: nobody set sender to carviset@iso.vilspa.esa.es using -f X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.17.13943 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Christophe.Arviset@esa.int Roy Apparently, one has to pay (both for storage and for transfer!) to use Amazon S3: "Pricing Pay only for what you use. There is no minimum fee, and no start-up cost. $0.15 per GB-Month of storage used. $0.20 per GB of data transferred." There might be technical things to learn from them, but I'm not sure how this pricing scheme would fit for the VO. Cheers Christophe Quoting Roy Williams : > I wonder what is common and what is different between Amazon S3 and > VOSpace? > Roy > > Begin forwarded message: > > > From: "Alex Szalay" > > Date: August 17, 2006 12:49:14 AM PDT > > To: "'Roy Williams'" , "'Alex Szalay'" > > > > Subject: Amazon VOStore? > > > > http://www.amazon.com/b/ref=sc_fe_l_2/104-7699424-9544708? > > ie=UTF8&node=16427261&no=15879911&me=A36L942TSJ2AJA > > > > We should look at the WS specs. > > > > --Alex > > > > California Institute of Technology > 626 395 3670 > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-vospace@eso.org Fri Aug 18 12:14:10 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IADuCJ022219 for ; Fri, 18 Aug 2006 12:13:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7IADupD022218 for vospace-outgoing; Fri, 18 Aug 2006 12:13:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IADqe9022204 for ; Fri, 18 Aug 2006 12:13:52 +0200 (MEST) Received: from katrine.roe.ac.uk (katrine.roe.ac.uk [195.194.120.81]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7IADoum020965 for ; Fri, 18 Aug 2006 12:13:51 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost.localdomain [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 7581A184E9; Fri, 18 Aug 2006 11:13:45 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 1425; Fri, 18 Aug 2006 11:13:44 +0100 (BST) Received: from katrine (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 263A0181A9; Fri, 18 Aug 2006 11:13:44 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Fri, 18 Aug 2006 11:13:44 +0100 (BST) Received: from [127.0.0.1] (katrine.roe.ac.uk [195.194.120.81]) by katrine.roe.ac.uk (Postfix) with ESMTP id 85CAF181A9; Fri, 18 Aug 2006 11:13:43 +0100 (BST) Message-ID: <44E592D7.3080609@roe.ac.uk> Date: Fri, 18 Aug 2006 11:13:43 +0100 From: John Taylor User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: Fwd: Amazon VOStore? References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <1155893196.44e587ccd5757@webmail.iso.vilspa.esa.es> In-Reply-To: <1155893196.44e587ccd5757@webmail.iso.vilspa.esa.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.18.24943 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: John Taylor I'm not sure that this is necessarily the end of the world. We already pay for hardware, ongoing maintenance, staff time, supercomputing resources....etc If an organisation decided it was more cost-effective to outsource this to Amazon or anyone else, why not? Christophe.Arviset@esa.int wrote: > Roy > > Apparently, one has to pay (both for storage and for transfer!) to use Amazon > S3: > > "Pricing > Pay only for what you use. There is no minimum fee, and no start-up cost. > $0.15 per GB-Month of storage used. > $0.20 per GB of data transferred." > > There might be technical things to learn from them, but I'm not sure how this > pricing scheme would fit for the VO. > > Cheers > > Christophe > > > > > Quoting Roy Williams : > > >> I wonder what is common and what is different between Amazon S3 and >> VOSpace? >> Roy >> >> Begin forwarded message: >> >> >>> From: "Alex Szalay" >>> Date: August 17, 2006 12:49:14 AM PDT >>> To: "'Roy Williams'" , "'Alex Szalay'" >>> >>> Subject: Amazon VOStore? >>> >>> http://www.amazon.com/b/ref=sc_fe_l_2/104-7699424-9544708? >>> ie=UTF8&node=16427261&no=15879911&me=A36L942TSJ2AJA >>> >>> We should look at the WS specs. >>> >>> --Alex >>> >>> >> California Institute of Technology >> 626 395 3670 >> >> >> > > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & Institute for Astronomy, Edinburgh Skype:johndavidtaylor ------------------------------------------------------------------------ From owner-vospace@eso.org Fri Aug 18 12:55:39 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IAtLSS029394 for ; Fri, 18 Aug 2006 12:55:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7IAtLLg029393 for vospace-outgoing; Fri, 18 Aug 2006 12:55:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IAtH2t029380 for ; Fri, 18 Aug 2006 12:55:17 +0200 (MEST) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7IAtELY006517 for ; Fri, 18 Aug 2006 12:55:15 +0200 (CEST) Received: from dropbox.aoc.nrao.edu (dropbox.aoc.nrao.edu [146.88.1.13]) by revere.aoc.nrao.edu (8.13.1/8.13.1/cv-ws-8.12) with ESMTP id k7IAt2Ut024059; Fri, 18 Aug 2006 04:55:03 -0600 Received: from localhost (localhost [[UNIX: localhost]]) by dropbox.aoc.nrao.edu (8.13.1/8.13.1/Submit) id k7IAt2Tl030481; Fri, 18 Aug 2006 04:55:02 -0600 Date: Fri, 18 Aug 2006 04:55:01 -0600 (MDT) From: Doug Tody X-X-Sender: dtody@localhost.localdomain To: vospace@ivoa.net Subject: Re: Fwd: Amazon VOStore? In-Reply-To: <44E592D7.3080609@roe.ac.uk> Message-ID: References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <1155893196.44e587ccd5757@webmail.iso.vilspa.esa.es> <44E592D7.3080609@roe.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-101.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44, USER_IN_WHITELIST -100.00) X-MailScanner-From: dtody@aoc.nrao.edu X-Spam-Status: No X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.18.32942 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Doug Tody The fundamental thing here is that we need to control where the data is stored, as we often need to colocate storage and computation. Hence using the commercial S3 service is not very interesting. As with VOSpace itself, the interesting thing to look at with S3 is the access interface. The physical storage will usually be located where we want to do the computations. Rather than think of VOSpace as a mere storage manager, one might think of it as a Grid version of distributed shared memory. We take some storage near where the computation will take place, and put a VOSpace interface on it so that we can move data in and out asynchronously. How the storage is physically implemented can vary greatly depending upon what we are doing. Computation is done on a per-user basis, so VOSpace is always managing data on behalf of some user. The real archive/Grid storage managers are used for more permanent storage of data. - Doug On Fri, 18 Aug 2006, John Taylor wrote: > I'm not sure that this is necessarily the end of the world. We already pay > for hardware, ongoing maintenance, staff time, supercomputing > resources....etc > If an organisation decided it was more cost-effective to outsource this to > Amazon or anyone else, why not? > > Christophe.Arviset@esa.int wrote: >> Roy >> >> Apparently, one has to pay (both for storage and for transfer!) to use >> Amazon >> S3: >> >> "Pricing >> Pay only for what you use. There is no minimum fee, and no start-up cost. >> $0.15 per GB-Month of storage used. $0.20 per GB of data transferred." >> >> There might be technical things to learn from them, but I'm not sure how >> this >> pricing scheme would fit for the VO. >> >> Cheers >> >> Christophe >> >> >> >> >> Quoting Roy Williams : >> >> >>> I wonder what is common and what is different between Amazon S3 and >>> VOSpace? >>> Roy >>> >>> Begin forwarded message: >>> >>> >>>> From: "Alex Szalay" >>>> Date: August 17, 2006 12:49:14 AM PDT >>>> To: "'Roy Williams'" , "'Alex Szalay'" >>>> >>>> Subject: Amazon VOStore? >>>> >>>> http://www.amazon.com/b/ref=sc_fe_l_2/104-7699424-9544708? >>>> ie=UTF8&node=16427261&no=15879911&me=A36L942TSJ2AJA >>>> >>>> We should look at the WS specs. >>>> >>>> --Alex >>>> >>>> >>> California Institute of Technology >>> 626 395 3670 >>> >>> >>> >> >> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> > > > From owner-vospace@eso.org Fri Aug 18 13:10:23 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IBA0qL001903 for ; Fri, 18 Aug 2006 13:10:00 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7IBA0s6001902 for vospace-outgoing; Fri, 18 Aug 2006 13:10:00 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IB9rGE001881 for ; Fri, 18 Aug 2006 13:09:53 +0200 (MEST) Received: from katrine.roe.ac.uk (katrine.roe.ac.uk [195.194.120.81]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7IB9pum023713 for ; Fri, 18 Aug 2006 13:09:51 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost.localdomain [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 40F331859C; Fri, 18 Aug 2006 12:09:46 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 16526; Fri, 18 Aug 2006 12:09:45 +0100 (BST) Received: from katrine (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D997E184E9; Fri, 18 Aug 2006 12:09:44 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Fri, 18 Aug 2006 12:09:44 +0100 (BST) Received: from [127.0.0.1] (katrine.roe.ac.uk [195.194.120.81]) by katrine.roe.ac.uk (Postfix) with ESMTP id 12AE7184E9; Fri, 18 Aug 2006 12:09:43 +0100 (BST) Message-ID: <44E59FF8.8000905@roe.ac.uk> Date: Fri, 18 Aug 2006 12:09:44 +0100 From: John Taylor User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: vospace@ivoa.net Subject: Re: Fwd: Amazon VOStore? References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <1155893196.44e587ccd5757@webmail.iso.vilspa.esa.es> <44E592D7.3080609@roe.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.18.35443 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: John Taylor Hi Doug - you're up early. I'm not suggesting that S3 is a VOSpace-killer, just that it's one possible VOSpace backend (of several) and the fact that it costs money isn't necessarily a problem. John Doug Tody wrote: > The fundamental thing here is that we need to control where the data > is stored, as we often need to colocate storage and computation. > Hence using the commercial S3 service is not very interesting. > As with VOSpace itself, the interesting thing to look at with S3 is > the access interface. The physical storage will usually be located > where we want to do the computations. > > Rather than think of VOSpace as a mere storage manager, one might think > of it as a Grid version of distributed shared memory. We take some > storage near where the computation will take place, and put a VOSpace > interface on it so that we can move data in and out asynchronously. > How the storage is physically implemented can vary greatly depending > upon what we are doing. Computation is done on a per-user basis, > so VOSpace is always managing data on behalf of some user. The real > archive/Grid storage managers are used for more permanent storage > of data. > > - Doug > > > On Fri, 18 Aug 2006, John Taylor wrote: > >> I'm not sure that this is necessarily the end of the world. We >> already pay for hardware, ongoing maintenance, staff time, >> supercomputing resources....etc >> If an organisation decided it was more cost-effective to outsource >> this to Amazon or anyone else, why not? >> >> Christophe.Arviset@esa.int wrote: >>> Roy >>> >>> Apparently, one has to pay (both for storage and for transfer!) to >>> use Amazon >>> S3: >>> >>> "Pricing >>> Pay only for what you use. There is no minimum fee, and no start-up >>> cost. $0.15 per GB-Month of storage used. $0.20 per GB of data >>> transferred." >>> >>> There might be technical things to learn from them, but I'm not sure >>> how this >>> pricing scheme would fit for the VO. >>> >>> Cheers >>> >>> Christophe >>> >>> >>> >>> >>> Quoting Roy Williams : >>> >>> >>>> I wonder what is common and what is different between Amazon S3 and >>>> VOSpace? >>>> Roy >>>> >>>> Begin forwarded message: >>>> >>>> >>>>> From: "Alex Szalay" >>>>> Date: August 17, 2006 12:49:14 AM PDT >>>>> To: "'Roy Williams'" , "'Alex Szalay'" >>>>> >>>>> Subject: Amazon VOStore? >>>>> >>>>> http://www.amazon.com/b/ref=sc_fe_l_2/104-7699424-9544708? >>>>> ie=UTF8&node=16427261&no=15879911&me=A36L942TSJ2AJA >>>>> >>>>> We should look at the WS specs. >>>>> >>>>> --Alex >>>>> >>>>> >>>> California Institute of Technology >>>> 626 395 3670 >>>> >>>> >>>> >>> >>> >>> >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> >> >> >> > -- ------------------------------------------------------------------------ AstroGrid/VOTech & Institute for Astronomy, Edinburgh Skype:johndavidtaylor ------------------------------------------------------------------------ From owner-vospace@eso.org Fri Aug 18 15:12:07 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IDBmIi028133 for ; Fri, 18 Aug 2006 15:11:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7IDBmtg028132 for vospace-outgoing; Fri, 18 Aug 2006 15:11:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IDBhkw028116 for ; Fri, 18 Aug 2006 15:11:44 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7IDBfum000159 for ; Fri, 18 Aug 2006 15:11:42 +0200 (CEST) Received: from [10.115.22.67] ([80.187.152.68]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id k7IDBO3H002890 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 18 Aug 2006 06:11:28 -0700 In-Reply-To: <1155893196.44e587ccd5757@webmail.iso.vilspa.esa.es> References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <1155893196.44e587ccd5757@webmail.iso.vilspa.esa.es> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-36--642249617 Message-Id: Cc: Roy Williams , vospace@ivoa.net From: Roy Williams Subject: Re: Amazon VOStore? Date: Fri, 18 Aug 2006 06:01:33 -0700 To: Christophe.Arviset@esa.int X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.18.55442 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Roy Williams --Apple-Mail-36--642249617 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Aug 18, 2006, at 2:26 AM, Christophe.Arviset@esa.int wrote: > $0.15 per GB-Month of storage used. > $0.20 per GB of data transferred." > > There might be technical things to learn from them, but I'm not > sure how this > pricing scheme would fit for the VO. So backing up a terabyte for a year would be a $200 transfer cost plus $1800 for the rent. This represents 1 to 2% of the salary of a sysadmin, and sounds like a much better deal than buying hardware and hiring somebody to watch the RAID failures. Obviously if you have 100 TB, you get economy of scale. One can also try to do data storage without paying, by getting an account at a national supercomputer center. But the problem is that every few months they will revise the purging policies, and you need to be on the ball with touching the data, renewal proposals etc etc. Also you need to maintain the client software that gives access to the remote data (GridFTP, SRB, etc etc). I wonder who is intending to deploy a VOSpace that I can put my terabytes in and leave them there for ever.? Roy California Institute of Technology 626 395 3670 --Apple-Mail-36--642249617 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Aug 18, 2006, at = 2:26 AM, Christophe.Arviset@esa.int = wrote:
$0.15 per = GB-Month of storage used.=A0
$0.20 = per GB of data transferred."

There might be technical things = to learn from them, but I'm not sure how this
pricing scheme would fit for the = VO.

So backing up a terabyte = for a year would be a $200 transfer cost plus $1800 for the rent.=A0This = represents 1 to 2% of the salary of a sysadmin, and sounds like a much = better deal than buying hardware and hiring somebody to watch the RAID = failures. Obviously if you have 100 TB, you get economy of = scale.

One = can also try to do data storage without paying, by getting an account at = a national supercomputer center. But the problem is that every few = months they will revise the purging policies, and you need to be on the = ball with touching the data, renewal proposals etc etc. Also you need to = maintain the client software that gives access to the remote data = (GridFTP, SRB, etc etc).

I wonder who is intending = to deploy a VOSpace that I can put my terabytes in and leave them there = for ever.?
Roy

California Institute of Technology

626 395 3670

=

= --Apple-Mail-36--642249617-- From owner-vospace@eso.org Fri Aug 18 15:48:59 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IDmees007063 for ; Fri, 18 Aug 2006 15:48:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id k7IDmeTO007061 for vospace-outgoing; Fri, 18 Aug 2006 15:48:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id k7IDmaV7007052 for ; Fri, 18 Aug 2006 15:48:36 +0200 (MEST) Received: from katrine.roe.ac.uk (katrine.roe.ac.uk [195.194.120.81]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id k7IDmYLY014729 for ; Fri, 18 Aug 2006 15:48:35 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost.localdomain [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id BD060181F9; Fri, 18 Aug 2006 14:48:29 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 13394; Fri, 18 Aug 2006 14:48:28 +0100 (BST) Received: from katrine (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 665E9181A9; Fri, 18 Aug 2006 14:48:28 +0100 (BST) Received: from localhost.localdomain ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Fri, 18 Aug 2006 14:48:28 +0100 (BST) Received: from [127.0.0.1] (katrine.roe.ac.uk [195.194.120.81]) by katrine.roe.ac.uk (Postfix) with ESMTP id B6BAF181A9; Fri, 18 Aug 2006 14:48:27 +0100 (BST) Message-ID: <44E5C52B.3070307@roe.ac.uk> Date: Fri, 18 Aug 2006 14:48:27 +0100 From: John Taylor User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Roy Williams , vospace@ivoa.net Subject: Re: Amazon VOStore? References: <200608170749.k7H7nEq0003217@concorde.pha.jhu.edu> <94C77B92-DBC3-4349-8E1F-3D9508D53DAD@cacr.caltech.edu> <1155893196.44e587ccd5757@webmail.iso.vilspa.esa.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.8.18.62943 X-Virus-Scanned: by amavisd-new Sender: owner-vospace@eso.org Precedence: bulk Reply-To: John Taylor Google? There are already ftp servers that sit in front of gmail accounts....why not a VOSpace? They currently only offer about 2.5 gig of space, but it's growing. By the time we get an implementation done you might have your terabytes! Roy Williams wrote: > > I wonder who is intending to deploy a VOSpace that I can put my > terabytes in and leave them there for ever.? > Roy > > California Institute of Technology > > 626 395 3670 > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & Institute for Astronomy, Edinburgh Skype:johndavidtaylor ------------------------------------------------------------------------ From owner-vospace@eso.org Fri Nov 10 07:58:20 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAA6wBNg014702 for ; Fri, 10 Nov 2006 07:58:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAA6wB4x014699 for vospace-outgoing; Fri, 10 Nov 2006 07:58:11 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAA6wARh014690; Fri, 10 Nov 2006 07:58:10 +0100 (MET) Received: from [192.168.2.101] (p5498D059.dip.t-dialin.net [84.152.208.89]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id kAA6w3fk004777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Nov 2006 07:58:07 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <9D9955F3-1A8E-42BB-BF32-697B424DC67A@eso.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-151086207; protocol="application/pkcs7-signature" To: IVOA mailing list VoSpace Subject: ESO VOSpace Pilot installation ready for Interoperability testing From: Paul Harrison Date: Fri, 10 Nov 2006 07:57:59 +0100 X-Mailer: Apple Mail (2.752.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison --Apple-Mail-8-151086207 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed We now have a pilot VOSpace 1.0 installation available for interoperability testing. The endpoint of the service is http://vops1.hq.eso.org:8080/vospace/ services/VOSpacePort and the vospace root URL is vos://org.eso!vospacetest/ It implements the v1.0 interface with http-put and http-get transports (which have a crude one-time-password mechanism) and stores the data/metadata in a back-end NGAS system. There are stlll some inefficiencies in the implementation that require some changes to the NGAS backend, but otherwise I think that this provides minimal VOSpace compliance. I think that I have put in place the necessary security infrastructure to accept requests signed by certificates from the current Astrogrid and NVO CAs. N.B. this is a pilot installation - do not use to store important/ sensitive data - there is no guarantee of data safety. Paul. p.s. I have started a new wiki page http://www.ivoa.net/twiki/bin/ view/IVOA/VOSpaceHome to centralize the VOSpace information Paul Harrison ESO Garching www.eso.org --Apple-Mail-8-151086207 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILNjCCBTYw ggQeoAMCAQICBAbswJUwDQYJKoZIhvcNAQEFBQAwWDELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRG Ti1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxIjAgBgNVBAMTGURGTi1WZXJlaW4gUENBIEdyaWQg LSBHMDEwHhcNMDUwNzA3MTQ1ODE1WhcNMDkwNzA3MTQ1ODE1WjBcMQswCQYDVQQGEwJERTETMBEG A1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEmMCQGA1UEAxMdREZOLVZlcmVpbiBV c2VyIENBIEdyaWQgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDhVXep2PYe He/12goskgaUYn+F+pkqE3XAjRZVO0LzI/UdTA5AZpI1oX4aMnyqAetv2DdBfWp2X8loxnn4WkPS Q43ba0XPShVIvEjr5EAtq4kc0i1M96A/q/zqcReNqmuQ6rzfOi31lCN+UaHje/vXprA3xvSNnTEj MeqIkjrvUda6xHYayp8XQccTtj7rQv3TwoC8w9NohY6rzhter6GwmUGuca5dOa/ZQfmO5XcvynKR dpOCOX7gqQkJcAgjGh/RRvZT0tTDWCdyyuGhL27yyk7pQWhpoDn5LdRd+tfzNhL/SxWdsTsdxjXr 0tzFSctJUEdSosty3ufltxBeUhB3AgMBAAGjggICMIIB/jAdBgNVHQ4EFgQU1jBSM/6RY0P7nyBM kcr77CsFACcwHwYDVR0jBBgwFoAUluzcrZrD/lCjPCLlPcLF/8rZIsYwDwYDVR0TAQH/BAUwAwEB /zCBwQYDVR0fBIG5MIG2MFmgV6BVhlNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Rmbi1wa2kvY2Vy dGlmaWNhdGlvbi94NTA5L2dyaWQvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDBZoFegVYZT aHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9ncmlkL2cx L2RhdGEvY3Jscy9yb290LWNhLWNybC5jcmwwgdYGCCsGAQUFBwEBBIHJMIHGMGEGCCsGAQUFBzAC hlVodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2dyaWQv ZzEvZGF0YS9jZXJ0cy9yb290LWNhLWNlcnQuY3J0MGEGCCsGAQUFBzAChlVodHRwOi8vY2RwMi5w Y2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2dyaWQvZzEvZGF0YS9jZXJ0cy9y b290LWNhLWNlcnQuY3J0MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAfACAenA1 5oBJLEIeXyvKQPOpoA9IarMLLEi1+IuFsorf7NFcWzW8QQYKYsHGBEMkOwnV0YA/a/d8wTNjx1ki MaK3Qu/RpMKrqFFp1oO7uTYMkWPh+Rj8csewng9Ltn4uXUjY+GZkS2w3iqYluOkxMrrtfkznQsDI +DQNqoi0tJ7uM+YmAfVr9AFI2WBPHcfP5FA2k2aAKTH0h4BcVctbMWXqhjLkIQ5cvdzV0zzInHES CQinZNvpmC+DK0PmoME1phmgmT6xPKxTRIHCKDues2uHDwj8YZu3jRlwmtp+sV9CSk7FKSFwsdd3 wTh8R0pa0hRQ1a7yNsWO8U9KQhUxPDCCBfgwggTgoAMCAQICBAkKiRgwDQYJKoZIhvcNAQEFBQAw XDELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJjAk BgNVBAMTHURGTi1WZXJlaW4gVXNlciBDQSBHcmlkIC0gRzAxMB4XDTA2MDgyMjEzNTAwMFoXDTA3 MDkyMTEzNTAwMFowgZYxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtHcmlkR2VybWFueTE+MDwGA1UE CxM1RVNPIC0gRXVyb3BlYW4gT3JnYW5pc2F0aW9uIGZvciBBc3Ryb25vbWljYWwgUmVzZWFyY2gx GTAXBgNVBAsTEEdyaWQtUkEgR2FyY2hpbmcxFjAUBgNVBAMTDVBhdWwgSGFycmlzb24wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1hFq/f6i+fXdUF+z048UlkDW4pHtH7kYbAn6TA3s7 Hz2owtrQV1DhiXYj20KrfAHD0028wA+I6AvRgBHN8r8sOAprsQowYKXUgw8qDs5wueR2BjBVZ4AO zu43esKouHfTaH+UYKrUKaWljlogfLeYZ5Ug6Xaj5+zbpS/3uFLRKFRY2YiriE/gOiN+ksvhW1yy Ka6kll0L9rMrDQ2hO+HBIlDz3QmYxe1GRDnY6P/Lf3TmYSfblqmhf708AAiwYu1grQEK9CbcNfMm A6nOaOWDqNMMCTaGB76CjKYuvDBSwdS3OJoNRdPUKrXpiCnispCImVEf7xbzVrBe330MB9xBAgMB AAGjggKFMIICgTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFPV/Nb2EXjmp4uSmoRA82culOfj8MB8GA1UdIwQYMBaA FNYwUjP+kWND+58gTJHK++wrBQAnMBsGA1UdEQQUMBKBEHBoYXJyaXNvQGVzby5vcmcwHAYDVR0g BBUwEzARBg8rBgEEAYGtIYIsAQEDAQIwgdcGA1UdHwSBzzCBzDBkoGKgYIZeaHR0cDovL2NkcDEu cGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9ncmlkL2cxL2NhLXVzZXIvZzEv ZGF0YS9jcmxzL2NhLXVzZXItY3JsLmNybDBkoGKgYIZeaHR0cDovL2NkcDIucGNhLmRmbi5kZS9k Zm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9ncmlkL2cxL2NhLXVzZXIvZzEvZGF0YS9jcmxzL2Nh LXVzZXItY3JsLmNybDCB7AYIKwYBBQUHAQEEgd8wgdwwbAYIKwYBBQUHMAKGYGh0dHA6Ly9jZHAx LnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0aWZpY2F0aW9uL3g1MDkvZ3JpZC9nMS9jYS11c2VyL2cx L2RhdGEvY2VydHMvY2EtdXNlci1jZXJ0LmNydDBsBggrBgEFBQcwAoZgaHR0cDovL2NkcDIucGNh LmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9ncmlkL2cxL2NhLXVzZXIvZzEvZGF0 YS9jZXJ0cy9jYS11c2VyLWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCDSPfTAm/btlf5sxfG Kd2OUVcxfehHyqdoiYenUYfKndTETgRbkZI2LlUh0Db0WgTwwiUOhoD1FuIQlYE9gQTT2uAiwuPk o4hfDR3DLrDccx6FvyJCuQIJsE3KzhzCW0lYCUnvQIov+CZH+odSNZEUZBwUqc9GaYAqrki65JEc xKcuysesc3uxB+GjF3XfjYqBB3D4/u6SiZVwoDjH7NREPAOI9lFzjSkrJ8A4Y5EHa6c2HkR00l5W gDf61OsPnKn30n6+yH/7egYXAzlZeBYfAtjW0q3Okb5W6Wz3Sm1Fpstqhh5dyL56G+9GvedGow0v b4lEjIRGEc6HFo5zkE4lMYIC2DCCAtQCAQEwZDBcMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEmMCQGA1UEAxMdREZOLVZlcmVpbiBVc2VyIENBIEdy aWQgLSBHMDECBAkKiRgwCQYFKw4DAhoFAKCCAUkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDYxMTEwMDY1NzYwWjAjBgkqhkiG9w0BCQQxFgQUTJgClisN+42043ZX ySq9hIfN5cUwcwYJKwYBBAGCNxAEMWYwZDBcMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZl cmVpbjEQMA4GA1UECxMHREZOLVBLSTEmMCQGA1UEAxMdREZOLVZlcmVpbiBVc2VyIENBIEdyaWQg LSBHMDECBAkKiRgwdQYLKoZIhvcNAQkQAgsxZqBkMFwxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpE Rk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSYwJAYDVQQDEx1ERk4tVmVyZWluIFVzZXIgQ0Eg R3JpZCAtIEcwMQIECQqJGDANBgkqhkiG9w0BAQEFAASCAQALjyotrN/ZRY+3QuVFesKeM7UZ73Hu tsO0DmkT74i1k/DPzLxfmMj6K5xsTH96EZROyWZbidxpUSNS1wVS9vkqAMiBTOOeO9JHfy+ks5Rn ILY/RdiwjxiQKBL9R+lpLKTpQMUrAcUOjwruL76aKIHHTM7f6C5n2HEGqJWkr3mvmFkAxzXSWK7M MEpIAw+hyj4ET3cTKyQTQV/bWOSGyRiHwU2+2t6iqeBlrB70KOQyelG2Ocf/Dn3FwL3uzpeQd2ZD puMAXmliB1fk7UPACZCOA/SSNqG/xViddiQHao2c0VTCNoKyi2CDfeVh494/2kLGoS1rjp4zbhrk NOezSSeoAAAAAAAA --Apple-Mail-8-151086207-- From owner-vospace@eso.org Fri Nov 10 13:52:05 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAACptac025683 for ; Fri, 10 Nov 2006 13:51:55 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAACptaQ025682 for vospace-outgoing; Fri, 10 Nov 2006 13:51:55 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAACpseZ025677 for ; Fri, 10 Nov 2006 13:51:55 +0100 (MET) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAACpkkP008983 for ; Fri, 10 Nov 2006 13:51:50 +0100 (CET) Received: from [10.71.2.114] (ip-69-33-174-50.iad.megapath.net [69.33.174.50]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id kAACpcIf000348 for ; Fri, 10 Nov 2006 04:51:39 -0800 Message-ID: <455475D1.6020900@cacr.caltech.edu> Date: Fri, 10 Nov 2006 07:51:29 -0500 From: Matthew Graham User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: vospace@ivoa.net Subject: Java VOSpace implementation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.11.10.43933 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, As part of the NVO Summer School software package (http://nvo.caltech.edu/nvoss2006.zip), there is a VOSpace v1.0 implementation (under java/src/vospace) which implements everything in the interface except WS-Security. It is configured to use MySQL as a metadata store but this is extensible to use any db/flat files. It also supplies an HTTP-based data server to support HTTP get and put with limited-lifetime-one-use URLs. There is a command line client for VOSpace as well. An implementation utilising WS-Security will be appearing soon. Cheers, Matthew From owner-vospace@eso.org Tue Nov 21 02:08:16 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL17uU8026677 for ; Tue, 21 Nov 2006 02:07:56 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAL17u9t026676 for vospace-outgoing; Tue, 21 Nov 2006 02:07:56 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL17qG2026661 for ; Tue, 21 Nov 2006 02:07:52 +0100 (MET) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAL17mTt029344 for ; Tue, 21 Nov 2006 02:07:49 +0100 (CET) Received: from [192.168.10.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id kAL0iaIf012269; Mon, 20 Nov 2006 16:44:37 -0800 Message-ID: <45624BF0.9070300@cacr.caltech.edu> Date: Mon, 20 Nov 2006 16:44:32 -0800 From: Matthew Graham User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: IVOA VoSpace mailing list , Tamas Budavari , Alex Szalay , Jim Gray Subject: Why not use Amazon S3? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.11.20.165432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, I've been working with Tamas Budavari at JHU on building an Amazon S3 interface on top of a db, the idea being to introduce this into CasJobs. A VOSpace interface will be added later but can reuse much of the infrastructure and code for the S3 interface. So why aren't we using S3 in the VO instead of VOSpace; well, having being through S3, we now have a much better idea of what its problems are: - Security: S3 uses private/public keys to sign messages (note: this is not WS-Security). When you register with S3, it generates a private-public key pair for you which you can then download. Any SOAP method call then requires three additional elements: AWSAccessKeyId - your public key (used as an identifier for you), TimeStamp - the current UTC time, and Signature - a HMAC-SHA1 digest of the concatenation of "AmazonS3" + operation name + TimeStamp using your private key. Since the S3 also has your private key, it can construct the Signature element it expects for a given message, compare it what it receives from you and authenicate your request (which must also travel over SSL to the server). There are three problems with this approach: firstly there are two copies of your private key - one on your machine and one on the S3 server. If the S3 server gets compromised then you are screwed. Secondly it does not scale with multiple S3 servers since each server will have its own private key for each user so to communicate with many servers, e.g. for federation purposes, then the client will have to manipulate multiple private keys to talk with all the different servers. Thirdly delegation is not secure as the server already has your private key, it could initiate a data transfer as you without you knowing about it. - Containers: S3 has one level of containers (called buckets) into which data objects can be grouped. Buckets cannot contain further buckets, however, and the bucket name must be unique since the bucket namespace is global so there can only be one bucket called "MyData". Metadata can also not be associated with buckets, only individual data objects. - Pseudo-hierarchy: Listing in S3 supports a pseudo-hierarchical view of data: if you construct the identifier for data objects in a hierarchical fashion, e.g. using '/' to delimit levels, then you can view the levels when you list by specifying what the delimiter is and what the identifier for the level you want to view is, e.g. my delimiter is '/' and I want to list all objects that I have labelled with identifiers beginning '/mydata/galaxies/images/'. The problem is that none of the data transfer operation recognise this hierarchy (only the listing operation) so if I try and retrieve '/mydata/galaxies/images' as an implied collection since I could list it, I am going to get an error since the container does not actually exist - S3 only allows 1 level of hierarchy with buckets. - Transfer protocols: Data transfer is either inline in the SOAP message or as a DIME attachment. No other protocols are supported. - Federation There is no notion of multiple S3 servers or how to federate them to present a single consistent space. - Extensibility and future functionality: - There is some clear roadmap for how and when S3 is going to evolve. Future functionality is promised but with no milestones or timescales. The existing methods can also not be altered from the WSDL POV since that would break all the S3 clients, which is one of the attractions of looking at S3 in the first place. In summary, although S3 is simple and has user tools, it is not scalable to multiple instances and has some strange organisational features which rely on interpretations not documented in the contract. I would, however, advocate S3 as a single instance use on large data collections. Cheers, Matthew From owner-vospace@eso.org Tue Nov 21 02:52:29 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL1qLix003064 for ; Tue, 21 Nov 2006 02:52:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAL1qLHP003063 for vospace-outgoing; Tue, 21 Nov 2006 02:52:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL1qJU0003053 for ; Tue, 21 Nov 2006 02:52:19 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAL1qFXh023857 for ; Tue, 21 Nov 2006 02:52:17 +0100 (CET) Received: from localhost (budavari@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id kAL1q1j09555; Mon, 20 Nov 2006 20:52:01 -0500 X-Authentication-Warning: skysrv.pha.jhu.edu: budavari owned process doing -bs Date: Mon, 20 Nov 2006 20:52:01 -0500 (EST) From: Tamas Budavari To: Matthew Graham cc: IVOA VoSpace mailing list , Alex Szalay , Jim Gray Subject: Re: Why not use Amazon S3? In-Reply-To: <45624BF0.9070300@cacr.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.11.20.173932 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Tamas Budavari Indeed, why not use S3, which BTW stands for Simple Storage Service! That is a nice summary, Matthew, and let me just add that most of these listed weaknesses of S3 may be considered its strengths, as well, and the rest (not REST!) is implementation details ;-) I recommend you read Matthew's message again, while chanting the following mantra: SIMPLE, WORKS, NOW :-) No, I am serious, read it again! People pay for Amazon S3... To me S3 is an interface definition that can be implemented to leverage the industry standard client tools (and all the documentation, user forums, etc out there) and there is nothing to stop us from extending its functionalities, having multiple instances of S3 servers, or even implementing other data access interfaces, such as VOSpace 1.x on top of the same data storage. Cheers, T. On Mon, 20 Nov 2006, Matthew Graham wrote: > Hi, > > I've been working with Tamas Budavari at JHU on building an Amazon S3 > interface on top of a db, the idea being to introduce this into CasJobs. > A VOSpace interface will be added later but can reuse much of the > infrastructure and code for the S3 interface. So why aren't we using S3 > in the VO instead of VOSpace; well, having being through S3, we now have > a much better idea of what its problems are: > > - Security: > S3 uses private/public keys to sign messages (note: this is not > WS-Security). When you register with S3, it generates a private-public > key pair for you which you can then download. Any SOAP method call then > requires three additional elements: AWSAccessKeyId - your public key > (used as an identifier for you), TimeStamp - the current UTC time, and > Signature - a HMAC-SHA1 digest of the concatenation of "AmazonS3" + > operation name + TimeStamp using your private key. Since the S3 also has > your private key, it can construct the Signature element it expects for > a given message, compare it what it receives from you and authenicate > your request (which must also travel over SSL to the server). > There are three problems with this approach: firstly there are two > copies of your private key - one on your machine and one on the S3 > server. If the S3 server gets compromised then you are screwed. Secondly > it does not scale with multiple S3 servers since each server will have > its own private key for each user so to communicate with many servers, > e.g. for federation purposes, then the client will have to manipulate > multiple private keys to talk with all the different servers. Thirdly > delegation is not secure as the server already has your private key, it > could initiate a data transfer as you without you knowing about it. > > - Containers: > S3 has one level of containers (called buckets) into which data objects > can be grouped. Buckets cannot contain further buckets, however, and the > bucket name must be unique since the bucket namespace is global so there > can only be one bucket called "MyData". Metadata can also not be > associated with buckets, only individual data objects. > > - Pseudo-hierarchy: > Listing in S3 supports a pseudo-hierarchical view of data: if you > construct the identifier for data objects in a hierarchical fashion, > e.g. using '/' to delimit levels, then you can view the levels when you > list by specifying what the delimiter is and what the identifier for the > level you want to view is, e.g. my delimiter is '/' and I want to list > all objects that I have labelled with identifiers beginning > '/mydata/galaxies/images/'. The problem is that none of the data > transfer operation recognise this hierarchy (only the listing operation) > so if I try and retrieve '/mydata/galaxies/images' as an implied > collection since I could list it, I am going to get an error since the > container does not actually exist - S3 only allows 1 level of hierarchy > with buckets. > > - Transfer protocols: > Data transfer is either inline in the SOAP message or as a DIME > attachment. No other protocols are supported. > > - Federation > There is no notion of multiple S3 servers or how to federate them to > present a single consistent space. > > - Extensibility and future functionality: > - There is some clear roadmap for how and when S3 is going to evolve. > Future functionality is promised but with no milestones or timescales. > The existing methods can also not be altered from the WSDL POV since > that would break all the S3 clients, which is one of the attractions of > looking at S3 in the first place. > > In summary, although S3 is simple and has user tools, it is not scalable > to multiple instances and has some strange organisational features which > rely on interpretations not documented in the contract. I would, > however, advocate S3 as a single instance use on large data collections. > > Cheers, > > Matthew > From owner-vospace@eso.org Tue Nov 21 05:38:13 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL4c00K015589 for ; Tue, 21 Nov 2006 05:38:00 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAL4c01B015588 for vospace-outgoing; Tue, 21 Nov 2006 05:38:00 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL4bwuO015583 for ; Tue, 21 Nov 2006 05:37:58 +0100 (MET) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAL4bpTv015851 for ; Tue, 21 Nov 2006 05:37:56 +0100 (CET) Received: from [172.16.1.35] (adsl-69-234-49-8.dsl.irvnca.pacbell.net [69.234.49.8]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id kAL3oKIf018804; Mon, 20 Nov 2006 19:50:21 -0800 Message-ID: <4562777C.2080901@cacr.caltech.edu> Date: Mon, 20 Nov 2006 19:50:20 -0800 From: Matthew Graham User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Tamas Budavari CC: IVOA VoSpace mailing list , Alex Szalay , Jim Gray Subject: Re: Why not use Amazon S3? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.11.20.202433 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, I agree that there is much in favour of S3 and that we can build other interfaces such as VOSpace on top but S3 does not meet the use cases we have for S3. Once we start extending an existing interface such as S3 for our own needs, the question needs to be asked why not just define our own one from the start. Cheers, Matthew Tamas Budavari wrote: > Indeed, why not use S3, which BTW stands for Simple Storage Service! > > That is a nice summary, Matthew, and let me just add that most of these > listed weaknesses of S3 may be considered its strengths, as well, and the > rest (not REST!) is implementation details ;-) I recommend you read > Matthew's message again, while chanting the following mantra: > > SIMPLE, WORKS, NOW :-) > > No, I am serious, read it again! People pay for Amazon S3... To me S3 is > an interface definition that can be implemented to leverage the industry > standard client tools (and all the documentation, user forums, etc out > there) and there is nothing to stop us from extending its functionalities, > having multiple instances of S3 servers, or even implementing other data > access interfaces, such as VOSpace 1.x on top of the same data storage. > > Cheers, T. > > > On Mon, 20 Nov 2006, Matthew Graham wrote: > > >> Hi, >> >> I've been working with Tamas Budavari at JHU on building an Amazon S3 >> interface on top of a db, the idea being to introduce this into CasJobs. >> A VOSpace interface will be added later but can reuse much of the >> infrastructure and code for the S3 interface. So why aren't we using S3 >> in the VO instead of VOSpace; well, having being through S3, we now have >> a much better idea of what its problems are: >> >> - Security: >> S3 uses private/public keys to sign messages (note: this is not >> WS-Security). When you register with S3, it generates a private-public >> key pair for you which you can then download. Any SOAP method call then >> requires three additional elements: AWSAccessKeyId - your public key >> (used as an identifier for you), TimeStamp - the current UTC time, and >> Signature - a HMAC-SHA1 digest of the concatenation of "AmazonS3" + >> operation name + TimeStamp using your private key. Since the S3 also has >> your private key, it can construct the Signature element it expects for >> a given message, compare it what it receives from you and authenicate >> your request (which must also travel over SSL to the server). >> There are three problems with this approach: firstly there are two >> copies of your private key - one on your machine and one on the S3 >> server. If the S3 server gets compromised then you are screwed. Secondly >> it does not scale with multiple S3 servers since each server will have >> its own private key for each user so to communicate with many servers, >> e.g. for federation purposes, then the client will have to manipulate >> multiple private keys to talk with all the different servers. Thirdly >> delegation is not secure as the server already has your private key, it >> could initiate a data transfer as you without you knowing about it. >> >> - Containers: >> S3 has one level of containers (called buckets) into which data objects >> can be grouped. Buckets cannot contain further buckets, however, and the >> bucket name must be unique since the bucket namespace is global so there >> can only be one bucket called "MyData". Metadata can also not be >> associated with buckets, only individual data objects. >> >> - Pseudo-hierarchy: >> Listing in S3 supports a pseudo-hierarchical view of data: if you >> construct the identifier for data objects in a hierarchical fashion, >> e.g. using '/' to delimit levels, then you can view the levels when you >> list by specifying what the delimiter is and what the identifier for the >> level you want to view is, e.g. my delimiter is '/' and I want to list >> all objects that I have labelled with identifiers beginning >> '/mydata/galaxies/images/'. The problem is that none of the data >> transfer operation recognise this hierarchy (only the listing operation) >> so if I try and retrieve '/mydata/galaxies/images' as an implied >> collection since I could list it, I am going to get an error since the >> container does not actually exist - S3 only allows 1 level of hierarchy >> with buckets. >> >> - Transfer protocols: >> Data transfer is either inline in the SOAP message or as a DIME >> attachment. No other protocols are supported. >> >> - Federation >> There is no notion of multiple S3 servers or how to federate them to >> present a single consistent space. >> >> - Extensibility and future functionality: >> - There is some clear roadmap for how and when S3 is going to evolve. >> Future functionality is promised but with no milestones or timescales. >> The existing methods can also not be altered from the WSDL POV since >> that would break all the S3 clients, which is one of the attractions of >> looking at S3 in the first place. >> >> In summary, although S3 is simple and has user tools, it is not scalable >> to multiple instances and has some strange organisational features which >> rely on interpretations not documented in the contract. I would, >> however, advocate S3 as a single instance use on large data collections. >> >> Cheers, >> >> Matthew >> >> > > From owner-vospace@eso.org Tue Nov 21 05:47:42 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL4lZcM016973 for ; Tue, 21 Nov 2006 05:47:35 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAL4lZHQ016972 for vospace-outgoing; Tue, 21 Nov 2006 05:47:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL4lXJ2016963 for ; Tue, 21 Nov 2006 05:47:33 +0100 (MET) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAL4lSXh004015 for ; Tue, 21 Nov 2006 05:47:29 +0100 (CET) Received: from dropbox.aoc.nrao.edu (dropbox.aoc.nrao.edu [146.88.1.13]) by revere.aoc.nrao.edu (8.13.1/8.13.1/cv-ws-8.12) with ESMTP id kAL3Fltd019318; Mon, 20 Nov 2006 20:15:47 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by dropbox.aoc.nrao.edu (8.13.1/8.13.1/Submit) id kAL3FkNY028034; Mon, 20 Nov 2006 20:15:46 -0700 Date: Mon, 20 Nov 2006 20:15:44 -0700 From: Doug Tody X-X-Sender: dtody@ender To: Tamas Budavari cc: Matthew Graham , IVOA VoSpace mailing list , Alex Szalay , Jim Gray Subject: Re: Why not use Amazon S3? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-101.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44, USER_IN_WHITELIST -100.00) X-MailScanner-From: dtody@aoc.nrao.edu X-Spam-Status: No X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.11.20.202433 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Doug Tody On Mon, 20 Nov 2006, Tamas Budavari wrote: > Indeed, why not use S3, which BTW stands for Simple Storage Service! > > That is a nice summary, Matthew, and let me just add that most of these > listed weaknesses of S3 may be considered its strengths, as well, and the > rest (not REST!) is implementation details ;-) Avoiding for the moment the issue of VOSpace vs S3; S3 of course does have a REST interface as well as SOAP; I don't know the statistics, but I'll bet 80-90% of the traffic is with the REST interface, as that is how these things generally run. Seriously, SOAP is a nice technology, but like much new technology it is over-hyped. The main thing it gives you is a formally defined interface (via WSDL), and automatic language bindings - essentially IDL/CORBA for the Web. But this does come at a cost, and may not be cost effective unless you need to bind enough interfaces to make the cost worth the effort to invest in the technology needed to automate the language bindings. > I recommend you read > Matthew's message again, while chanting the following mantra: > > SIMPLE, WORKS, NOW :-) > > No, I am serious, read it again! People pay for Amazon S3... To me S3 is > an interface definition that can be implemented to leverage the industry > standard client tools (and all the documentation, user forums, etc out > there) and there is nothing to stop us from extending its functionalities, > having multiple instances of S3 servers, or even implementing other data > access interfaces, such as VOSpace 1.x on top of the same data storage. This argument probably holds true for many other things as well; WebDAV for example. Apple had something similar (although more proprietary) a while back. Others are sure to follow. For astronomy I don't think we really care how many folks use something like S3, mainly we just need something which works for us and is stable. I agree though, that it is always a good check to study these simple interfaces and ask why we can't use them, or at least what we can learn from them. - Doug From owner-vospace@eso.org Tue Nov 21 10:04:56 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL94lhW016204 for ; Tue, 21 Nov 2006 10:04:47 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAL94lbI016203 for vospace-outgoing; Tue, 21 Nov 2006 10:04:47 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAL94hU2016194 for ; Tue, 21 Nov 2006 10:04:43 +0100 (MET) Received: from ppsw-2.csi.cam.ac.uk (ppsw-2.csi.cam.ac.uk [131.111.8.132]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAL94fXh021292 for ; Tue, 21 Nov 2006 10:04:41 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:61846) by ppsw-2.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.132]:25) with esmtp id 1GmRYE-0005h9-8X (Exim 4.63) (return-path ); Tue, 21 Nov 2006 09:04:23 +0000 Received: from cass60.ast.cam.ac.uk (cass60 [IPv6:2001:630:200:4240:203:baff:feb0:3f6f]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAL94KHD016887; Tue, 21 Nov 2006 09:04:21 GMT Received: from cass60.ast.cam.ac.uk (localhost [127.0.0.1]) by cass60.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAL94K2S000613; Tue, 21 Nov 2006 09:04:20 GMT Received: from localhost (gtr@localhost) by cass60.ast.cam.ac.uk (8.13.7+Sun/8.13.7/Submit) with ESMTP id kAL94IYw000609; Tue, 21 Nov 2006 09:04:18 GMT X-Authentication-Warning: cass60.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 21 Nov 2006 09:04:18 +0000 (GMT) From: Guy Rixon X-X-Sender: gtr@cass60 To: Doug Tody cc: Tamas Budavari , Matthew Graham , IVOA VoSpace mailing list , Alex Szalay , Jim Gray Subject: Re: Why not use Amazon S3? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.11.21.5432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Guy Rixon On Mon, 20 Nov 2006, Doug Tody wrote: > Avoiding for the moment the issue of VOSpace vs S3; S3 of course does > have a REST interface as well as SOAP; I don't know the statistics, but > I'll bet 80-90% of the traffic is with the REST interface, as that is how > these things generally run. > > Seriously, SOAP is a nice technology, but like much new technology > it is over-hyped. The main thing it gives you is a formally defined > interface (via WSDL), and automatic language bindings - essentially > IDL/CORBA for the Web. But this does come at a cost, and may not be > cost effective unless you need to bind enough interfaces to make the > cost worth the effort to invest in the technology needed to automate > the language bindings. The other aspects of SOAP are that it is independent of transport protocol and has an envelope/body structure that separates the concerns of the service from the concerns of the middleware. These two combine to make it easier to _standardize_ things like security across a range of services. As an example of a benefit to IVOA, when we work on the specs for VOSpace and UWS-PA interfacess, which are both SOAP, we don't need to consider security. We write something like "most VOSpaces should have controlled access using IVOA standards" and "any UWS-PA service that needs controlled access should also implement the IVOA security standard" and we're done. The details are elsewhere and we _know_ that we can fit the security spec to the others because SOAP gives us a way of doing so. As an example of a benefit to the service implementors, a secured SOAP service in Java can be a composite: servlet engine + unsecured service code + security-plug-in implementing WS-Security. That is, the security doesn't disrupt either the HTTP server or the basic code for the unsecured service. There are services built this way in Edinburgh using AstroGrid parts. Now compare the situation for a secured DAL service using HTTP-get. The security standard says "HTTPS with RFC3820 support". To get the RFC3820 support, I'm having to write my own HTTP server and JSSE provider! Because the message and its security metadata are intertwined with the transport, I have to change the transport - which I'd much rather treat as a given - to change some aspects of the message. SOAP uses more complex messages than REST which in turn uses more than stateless HTTP-get, but the interface complexity allows one the chance to manage the implementation complexity. Cheers, Guy Guy Rixon gtr@ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 From owner-vospace@eso.org Fri Nov 24 17:46:04 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGjnG3026454 for ; Fri, 24 Nov 2006 17:45:49 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAOGjns1026453 for vospace-outgoing; Fri, 24 Nov 2006 17:45:49 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGjmwV026441 for ; Fri, 24 Nov 2006 17:45:48 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAOGjjUY026274 for ; Fri, 24 Nov 2006 17:45:46 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:39086) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1GneBB-0002tE-EQ (Exim 4.63) (return-path ); Fri, 24 Nov 2006 16:45:33 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAOGjTe7028167; Fri, 24 Nov 2006 16:45:29 GMT Message-ID: <456721A4.4050207@ast.cam.ac.uk> Date: Fri, 24 Nov 2006 16:45:24 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Graham CC: IVOA VoSpace mailing list Subject: Re: Changes to VOSpace specification (properties) References: <456520A5.1010902@cacr.caltech.edu> In-Reply-To: <456520A5.1010902@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.21.83432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Matthew Graham wrote: > I've had meetings in the past two weeks with the folks at JHU about > putting a VOSpace interface onto CasJobs and Arun Jagatheesan at SDSC > about the VOSpace interface with SRB. Predictably both parties raised > issues but there were three that both brought up and I think we need to > address them: Assuming that we are now talking about changes to add to the _next_ version, then ok. We _are_ talking about the next version here ... aren't we guys ? > 1. Properties > The current scheme is limited to key-value pairs where the value is > interpreted as a string. A problem with this that some key-values pairs > might be intended to represent other datatypes, e.g. a date or a float, > and without this typing information, it is impossible to check the > validity of the value. I know it is very tempting to try to add extended types to the properties. 1.1 Property type attribute First, _if_ we do introduce type attribute, the attribute should be in our own schema, and not using the xsi:type attribute. Reason is that some XML parsers may swallow the xsi:type attribute, and the type information might not be passed on to the application layer. So, it would have to be [property vos:type="xxxx"] rather than [property xsi:type="xxxx"] ------- 1.2 Avoiding large blobs I experimented with quite a few variations of typed properties before we introduced the node/properties structured into vospace, and all of them had one drawback. It makes it very tempting for 3rd party developers to put large and complex information into the properties. Remember that the full properties list is returned for every element in a list response. Personally, I'd prefer to keep node properties as small and lightweight as possible. In a lot of my earlier work I actually had the property value as an attribute [property uri="yyyy" value="data here"/] rather than the element value we have at the moment [property uri="yyyy"]data here[/property] purely to discourage [property uri="yyyy"] People who want to put large blobs of descriptive text in what should really be a primitive type. Adding this much text into a property makes it difficult for a database system to store, and it also makes it difficult for a UI developer to display in a GUI client. Ideally, all properties should be small values that can be displayed in a single line in the GUI. [/property] Form what I remember, we didn't adopt property value as attribute in the initial vospace spec, mainly because it is easier for XML/SOAP handlers to extract element data than attribute values. Allowing large complex bits of data in the node properties means we are in danger of heading down same the road that registry has gone. Where we are starting to see clients using xpath expressions to ask the registry for small parts of the registration document because they don't want to handle the whole document when they only want one or two small bits of data e.g having to parse all of the curation information just to get the service endpoint(s). ------- 1.3 Simple type information On the other hand, type information for primitive values, e.g string, int, float, date etc. would indeed be useful. However, adding the type attribute to the message schema means that the message sender has control over the type information. If we allow the sender to set the type attribute, then what happens if client A sends [property uri="xxxx" type="xsi:int" value="51"/] and client B sends [property uri="xxxx" type="xsi:string" value="fifty-one"/] We would need some way for the recipient to find out what the property type should actually be, and convert or reject one or other of the two values. Which is what the property registration documents were supposed to do. The property URI attribute should point to a resource that defines what the property means, in a human readable form, and it should also define the allowed format and range of values in a machine readable form. In effect, a property registration document should contain the schema rules for the contents of a property element with that URI. ------- 1.4 Complex properties If we really do have a use case for larger property values, could we add them using a separate xml element. For text based information, we could add a new [text-property] element, that would should wrap the text blob in a CDATA element. [text-property uri="xxxx"] <[CDATA[ The node property list may also contain text-property elements, which wrap the text in a CDATA element. ]]> [/text-property] In order to keep prevent large text properties from slowing the system down too much, I would ask that these are excluded from most of the service responses, and are only returned in response to a specific getNode() request. It would be up to the client UI developers how they handled text-property elements. For complex xml data, we could add a corresponding [xml-property] element, which can contain arbitrary xml data, possibly adding an additional schema and namespace attribute. [xml-property uri="yyyy"] [colour] [red]123[/red] [blue]234[/blue] [green]89[/green] [/colour] [/xml-property] Note that we shouldn't need to add type, schema, or namespace attributes to the [xml-property] element itself. Again, the property URI should point to a registration document that defines these for all instances of properties with that URI. Again, to reduce the impact on control messages, I would ask that these are excluded from most of the service responses, and are only returned in response to a specific getNode() request. Once we allow these larger properties, there is nothing to prevent people from abusing them. ------- 1.5 Property syntax Your example of the [colour] information is fairly harmless, but once this is in the spec. then there is nothing to prevent a 3rd party adding a 2 page description to a [text-property] or embedding a full registry resource document in an [xml-property]. If this became common place, then it would make things very difficult for UI developers to display the node properties in a clear and consistent way. Some properties would be a single numerical value, others would contain large blocks of text or xml. Unless we can filter out the complex values, then there is nothing to prevent large blobs of text and xml being returned in the node properties for every import, export and list response from then on. I would prefer to restrict the size and complexity of properties, keeping node/properties as simple as possible and use references to point to the more complex metadata stored in separate nodes. [node uri="xxxx"] [properties] [property uri="ivo://..../abstract" value="vos://...."/] [property uri="ivo://..../registration" value="vos://...."/] .... [/properties] [/node] The text description and registration document can then be handled as separate data nodes, containing the complex data as text and xml files The case you highlighted is an edge case, where the xml isn't that complex, and the structure would be useful. However, as Paul mentioned, the same information could be represented as a simple string : [property uri="xxxx" value="123:234:89"/] The property URI should point to a registration document that defines the property type, and syntax, in a machine readable way. One possibility would be to use a regular expression in the registration document to define the property syntax. [property uri="xxxx" type="complex-string"] .... [regexp]{0-9}+:{0-9}+:{0-9}+[/regexp] .... [/property] Message parsers could use the regular expression in the property registration document to validate the property value, without needing to understand the particular property meaning. If a property value did not match the regular expression, then the recipient would be allowed to reject the property. This would allow you to define your own complex properties, with a specific syntax, and enable me to write a generic message handler that could validate the property as a string, by checking if it matched the regular expression. Without having to understand the internal details of the property meaning. ------- 1.6 Summary so far To avoid large properties, use attribute rather than element to restrict the size and complexity. Yes, I know it is theoretically possible to add a large blob of text or xml to an attribute, but it makes it more difficult. [property uri="xxxx" value="123:234:89"/] The property registration document should contain all the type and syntax information about the property. For complex properties, this could include a regular expression to describe the property syntax. [property uri="xxxx" type="complex-string"] .... [regexp]{0-9}+:{0-9}+:{0-9}+[/regexp] .... [/property] If we want to add larger text or xml properties, we should add a new element to the schema to support them. [text-property uri="xxxx"] <[CDATA[ The text data, wrapped in a CDATA element. ]]> [/text-property] and [xml-property uri="yyyy"] [colour] [red]123[/red] [blue]234[/blue] [green]89[/green] [/colour] [/xml-property] The [text-property] and [xml-property] would only be returned in response to an explicit getNode() call. They should be filtered out of the import, export and list responses. Thank you for reading this far :-) Dave From owner-vospace@eso.org Fri Nov 24 17:47:04 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGkvL8027101 for ; Fri, 24 Nov 2006 17:46:57 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAOGkvfn027100 for vospace-outgoing; Fri, 24 Nov 2006 17:46:57 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGkvEc027092 for ; Fri, 24 Nov 2006 17:46:57 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAOGktUY026379 for ; Fri, 24 Nov 2006 17:46:55 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:39261) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1GneCM-0003Wq-Ey (Exim 4.63) (return-path ); Fri, 24 Nov 2006 16:46:46 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAOGkhYN028493; Fri, 24 Nov 2006 16:46:43 GMT Message-ID: <456721EE.1080508@ast.cam.ac.uk> Date: Fri, 24 Nov 2006 16:46:38 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: [Fwd: Re: Changes to VOSpace specification] Content-Type: multipart/mixed; boundary="------------070704030406060102060505" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.21.83432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris This is a multi-part message in MIME format. --------------070704030406060102060505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm forwarding these messages to the vospace list for discussion. There are a number of interested parties on the list who may not have seen the original messages. Dave --------------070704030406060102060505 Content-Type: message/rfc822; name="Re: Changes to VOSpace specification" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: Changes to VOSpace specification" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cass41 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,TW_QN autolearn=ham version=3.1.7 Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAO7ZiLi013387; Fri, 24 Nov 2006 07:35:44 GMT X-Cam-SpamDetails: scanned, SpamAssassin-3.1.7 (score=0) X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from apollo.hq.eso.org ([134.171.42.42]:62341) by ppsw-1.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.141]:25) with esmtp (csa=unknown) id 1GnVaz-0004VF-4D (Exim 4.63) (return-path ); Fri, 24 Nov 2006 07:35:37 +0000 Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAO7ZQBB009508; Fri, 24 Nov 2006 08:35:26 +0100 (CET) Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAO7ZKia019951; Fri, 24 Nov 2006 08:35:21 +0100 (MET) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id kAO7ZKYp002746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 Nov 2006 08:35:20 +0100 In-Reply-To: <4565EFB6.3040603@cacr.caltech.edu> References: <456520A5.1010902@cacr.caltech.edu> <4565EFB6.3040603@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <949B0437-D7C6-4A5B-80EC-A16CDA61AF01@eso.org> Cc: Guy Rixon , Dave Morris Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Changes to VOSpace specification Date: Fri, 24 Nov 2006 08:35:19 +0100 To: Matthew Graham X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.35 On 23.11.2006, at 20:00, Matthew Graham wrote: > One of the problems with the first way is that there will be > different behaviour depending on whether the space has coupled or > decoupled data servers: > Coupled servers: > A. Client calls pushToVoSpace(, ) returns > and - the latter containing details for the data server > B. Client transfers data to data server > C. Behind the scenes, the data server tells VOSpace that transfer > has occurred > > Decoupled servers: > A. Client calls pushToVoSpace(, ) returns > and - the latter containing details for the data server > B. Client transfers data to data server > C. Client notifies VOSpace that transfer has been completed, e.g. > transferComplete(). > > Unless, of course, we make the decoupled server scenario the only > way of doing it. We also have to enforce the use of > transferComplete otherwise the state of the data transfer is > indeterminate. > > The alternate is that the first part of the process is the user > finding out what data servers are available with the getDataServers > call I suggest at the end: > A. Clients get list of data servers with getDataServers > B. Client transfers data to data server > C. Client registers data with VOSpace: register(, URI of > location) returns the registered > > This is much more in keeping with the other data discovery methods > we already have such as getProtocols. The process also does not > leave the space in an indeterminate state. except as I said before, one of the original use cases was that VOSpace was supposed to be managing physical location of data - if the client gets to choose where the data are sent first then it breaks that use case (though I suppose if the getDataServers call had as its argument the intended this could still be done). I am not convinced the "breakage scenario" in this last process is better - if the client pushes data to a store then fails to register the node - the data server gets filled up without the VOSpace knowing about it - there are still 3 steps for the client to perform. In fact if the getDataServers call has an an argument a Node, then there is really little difference between process 2 qnd process 3 above - all that is different is when the VOSpace chooses to actually make the entry in its metadata tree. The last process also makes it more difficult to implement simple "coupled" data stores - it implies that we have to have authentication on simple http where the client knows an authentication secret in advance for instance to stop mass uploading of porn. Simple one-time-password implementations cannot work if the client has to contact the data server first. Another point is how decoupled are you talking about - I am presuming that the space still has access to the same filesystem as the decoupled data servers. If it is more decoupled than that then the space is unlikely to be able to control the contents on the data server, which will lead to inconsistent states anyway. Cheers, Paul. --------------070704030406060102060505-- From owner-vospace@eso.org Fri Nov 24 17:48:30 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGmLLv028081 for ; Fri, 24 Nov 2006 17:48:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAOGmLN4028078 for vospace-outgoing; Fri, 24 Nov 2006 17:48:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGmKmP028071 for ; Fri, 24 Nov 2006 17:48:20 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAOGmIRq028753 for ; Fri, 24 Nov 2006 17:48:18 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:39349) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1GneDe-00046v-Cy (Exim 4.63) (return-path ); Fri, 24 Nov 2006 16:48:06 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAOGm2RZ028573; Fri, 24 Nov 2006 16:48:02 GMT Message-ID: <4567223D.1070107@ast.cam.ac.uk> Date: Fri, 24 Nov 2006 16:47:57 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: [Fwd: Re: Changes to VOSpace specification] Content-Type: multipart/mixed; boundary="------------020806060909060001020400" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.21.83432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris This is a multi-part message in MIME format. --------------020806060909060001020400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm forwarding these messages to the vospace list for discussion. There are a number of interested parties on the list who may not have seen the original messages. Dave --------------020806060909060001020400 Content-Type: message/rfc822; name="Re: Changes to VOSpace specification" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: Changes to VOSpace specification" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cass41 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,TW_QN autolearn=ham version=3.1.7 Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAOGg9TA027526; Fri, 24 Nov 2006 16:42:09 GMT X-Cam-SpamDetails: scanned, SpamAssassin-3.1.7 (score=0) X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail.cacr.caltech.edu ([131.215.145.9]:52684) by ppsw-3.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.143]:25) with esmtp (csa=unknown) id 1Gne7a-000242-AX (Exim 4.63) (return-path ); Fri, 24 Nov 2006 16:41:51 +0000 Received: from [172.16.1.35] (adsl-69-234-49-8.dsl.irvnca.pacbell.net [69.234.49.8]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id kAOGfVIf010307; Fri, 24 Nov 2006 08:41:34 -0800 Message-ID: <456720BA.2000802@cacr.caltech.edu> Date: Fri, 24 Nov 2006 08:41:30 -0800 From: Matthew Graham User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Paul Harrison CC: Guy Rixon , Dave Morris Subject: Re: Changes to VOSpace specification References: <456520A5.1010902@cacr.caltech.edu> <4565EFB6.3040603@cacr.caltech.edu> <949B0437-D7C6-4A5B-80EC-A16CDA61AF01@eso.org> In-Reply-To: <949B0437-D7C6-4A5B-80EC-A16CDA61AF01@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, >> One of the problems with the first way is that there will be >> different behaviour depending on whether the space has coupled or >> decoupled data servers: >> Coupled servers: >> A. Client calls pushToVoSpace(, ) returns and >> - the latter containing details for the data server >> B. Client transfers data to data server >> C. Behind the scenes, the data server tells VOSpace that transfer has >> occurred >> >> Decoupled servers: >> A. Client calls pushToVoSpace(, ) returns and >> - the latter containing details for the data server >> B. Client transfers data to data server >> C. Client notifies VOSpace that transfer has been completed, e.g. >> transferComplete(). >> >> Unless, of course, we make the decoupled server scenario the only way >> of doing it. We also have to enforce the use of transferComplete >> otherwise the state of the data transfer is indeterminate. >> >> The alternate is that the first part of the process is the user >> finding out what data servers are available with the getDataServers >> call I suggest at the end: >> A. Clients get list of data servers with getDataServers >> B. Client transfers data to data server >> C. Client registers data with VOSpace: register(, URI of >> location) returns the registered >> >> This is much more in keeping with the other data discovery methods we >> already have such as getProtocols. The process also does not leave >> the space in an indeterminate state. > > except as I said before, one of the original use cases was that > VOSpace was supposed to be managing physical location of data - if the > client gets to choose where the data are sent first then it breaks > that use case (though I suppose if the getDataServers call had as its > argument the intended this could still be done). I am not > convinced the "breakage scenario" in this last process is better - if > the client pushes data to a store then fails to register the node - > the data server gets filled up without the VOSpace knowing about it - > there are still 3 steps for the client to perform. In fact if the > getDataServers call has an an argument a Node, then there is really > little difference between process 2 qnd process 3 above - all that is > different is when the VOSpace chooses to actually make the entry in > its metadata tree. > > The last process also makes it more difficult to implement simple > "coupled" data stores - it implies that we have to have authentication > on simple http where the client knows an authentication secret in > advance for instance to stop mass uploading of porn. Simple > one-time-password implementations cannot work if the client has to > contact the data server first. > > Another point is how decoupled are you talking about - I am presuming > that the space still has access to the same filesystem as the > decoupled data servers. If it is more decoupled than that then the > space is unlikely to be able to control the contents on the data > server, which will lead to inconsistent states anyway. Although it sounds good in theory, the use case where VOSpace manages the physical location is actually very impractical for the reasons I outlined previously (access to source code of third party data servers to implement callback). Another popular use case here is that the user already has the data on a data server somewhere and does not want to load it all into VOSpace just to register it so that it is exposed this way. I actually think that both these use cases are far more realistic, although more complicated, than where the VOSpace manages the physical location. I also have complete decoupling in mind. Cheers, Matthew --------------020806060909060001020400-- From owner-vospace@eso.org Fri Nov 24 17:53:33 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGpKFp028968 for ; Fri, 24 Nov 2006 17:51:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAOGpKcv028967 for vospace-outgoing; Fri, 24 Nov 2006 17:51:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGpJeZ028963 for ; Fri, 24 Nov 2006 17:51:20 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAOGpHRq028949 for ; Fri, 24 Nov 2006 17:51:17 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:37966) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1Gne0B-0006mt-Ej (Exim 4.63) (return-path ); Fri, 24 Nov 2006 16:34:11 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAOGY8vK026235; Fri, 24 Nov 2006 16:34:08 GMT Message-ID: <45671EFA.3060103@ast.cam.ac.uk> Date: Fri, 24 Nov 2006 16:34:02 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: [Fwd: Re: Changes to VOSpace specification] Content-Type: multipart/mixed; boundary="------------090907080504050907040101" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.21.83432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris This is a multi-part message in MIME format. --------------090907080504050907040101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm forwarding these messages to the vospace list for discussion. There are a number of interested parties on the list who may not have seen the original messages. Dave --------------090907080504050907040101 Content-Type: message/rfc822; name="Re: Changes to VOSpace specification" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: Changes to VOSpace specification" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cass41 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kANJ0NmN012043; Thu, 23 Nov 2006 19:00:23 GMT X-Cam-SpamDetails: scanned, SpamAssassin-3.1.7 (score=0) X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail.cacr.caltech.edu ([131.215.145.9]:57010) by ppsw-4.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.144]:25) with esmtp (csa=unknown) id 1GnJo2-0006dj-DG (Exim 4.63) (return-path ); Thu, 23 Nov 2006 19:00:19 +0000 Received: from [172.16.1.35] (adsl-69-234-49-8.dsl.irvnca.pacbell.net [69.234.49.8]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id kANJ07If031969; Thu, 23 Nov 2006 11:00:07 -0800 Message-ID: <4565EFB6.3040603@cacr.caltech.edu> Date: Thu, 23 Nov 2006 11:00:06 -0800 From: Matthew Graham User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Paul Harrison CC: Guy Rixon , Dave Morris Subject: Re: Changes to VOSpace specification References: <456520A5.1010902@cacr.caltech.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Paul Harrison wrote: >> 1. Properties >> The current scheme is limited to key-value pairs where the value is >> interpreted as a string. A problem with this that some key-values pairs >> might be intended to represent other datatypes, e.g. a date or a float, >> and without this typing information, it is impossible to check the >> validity of the value. It is always possible for a client to add this >> information with an xsi:type attribute, e.g. >> > xsi:type="xs:dateTime">2006-11-22T18:50:03Z >> but this might not be interpreted properly by the browser. However, if >> we actually add a type attribute then we can cover this: >> > type="xs:dateTime">2006-11-22T18:50:03Z. >> The attribute is optional and non-inclusion implies that the datatype is >> string. The value of the attribute can either be an XML datatype or a >> reference to an XML schema that describes the data structure thus >> allowing for more complicated properties such as: >> >> >> 123 >> 234 >> 89 >> >> > > I am not so sure that this is a good idea - more or less the whole > point of properties is that the server does not check the validity of > them - they are simply opaque strings except for the ones that the > server knows about, and then it already knows the data type. I think > that this is adding an extra level of complexity to implementation > requirements, without too much benefit, as it is ultimately only the > client that is really going to understand your myschema.xsd example, > and it could achieve the same simply by passing the xml as a string. A savvy user can always impose this themselves with xsi:type and I would rather we had a mechanism to do this instead - in fact, it would be interesting to do the exercise and see what effect putting xsi:type on the property element had. >> >> 2. Views >> This needs to be renamed to what it actually is, i.e. format(s), since >> the current name is universally confusing. > > yes! - but I think it is really two concepts - on import it is just a > statement of the format of the data - on export it is a request to > convert the data to a format. The whole transfer object in the WSDL > should reflect this difference by not using the same data structure > for requests and returned information, as this is also confusing IMHO > as the distinction is lost between the statements > "this data is in format x" > "convert this data to format y" I think that having format on its own on input and contained within accepts and provides on output is fine - so did the various people, it was just the naming of view that was at issue. > > >> 3. Decoupled data servers >> Under the current scheme, it is assumed that there is some communication >> channel between the VOSpace and a data server, e.g. a gridftp server, so >> that when a pushTo or pullFrom is completed, the data server can notify >> the VOSpace service that the transfer has completed. This sort of >> activity is particularly necessary when the endpoint is a logical one, >> e.g. a one-time-use URL. This design is fine for the cases where we have >> implemented the data servers ourselves or have access to the source code >> so that we can add the callback; however, what happens when you are >> dealing with an off-the-shelf data server where this is not the case or >> non-trivial, e.g. the Globus gridftp server. >> One solution is to have the client notify the VOSpace when the >> transaction is complete (since this really is only a problem for the >> asynchronous services) so pushToVoSpace would become: >> >> A. Client calls pushToVoSpace(, ) returns and >> - the latter containing details for the data server >> B. Client transfers data to data server >> C. Client notifies VOSpace that transfer has been completed, e.g. >> transferComplete(). >> >> There are a couple of problems with this, however: the client has to >> call the space twice and might forget to do the notification call and >> what happens if the transfer fails or is not done. >> An alternate approach is to do the data transfer first of all and then >> register the data object with the node including its physical >> location so pushToVoSpace becomes: >> >> A. Client transfer data to data server >> B. Client registers data with VOSpace: register(, URI of location) >> returns the registered >> >> This is actually the only transfer method which needs a modification: >> all the others work fine with decoupled servers. In fact, instead of >> adding an additional operation, we can modify pushToVoSpace either to >> have an additional URI argument: pushToVoSpace(, , >> location-uri) or we could just incorporate the location-uri into the >> transfer so that if the protocol contains an endpoint then that >> endpoint is interpreted to be the physical location of the data object. >> >> One thing that would be useful is another operation to return the >> list of (decoupled) data servers (resources in SRB speak) that the >> VOSpace is using so I would suggest that we add a getDataServers >> operation. >> > > this has always been my point that we cannot brush the asynchronicity > of this call under the carpet - however, I think that we have to go > with the first of your two options, as I do not see how the client > can really know which data server to transfer data to without > contacting the VOSpace first to say where in VOSpace they want to put > the data - it is then up to the VOSpace to say which data server to > use as the VOSpace knows the topology. I think that the > transferComplete() call would have to be "advisory", in the sense that > the VOSpace should keep track of all pending inward transfers and try > to determine if the data have arrived after a given time (e.g. for an > ftp service it could do an ls and see if the size is the same as the > size that was specified in the original pushToVoSpace) - if the > VOSpace does received a transferComplete() call, it can assume that > the client believes that the data have arrived safely. One of the problems with the first way is that there will be different behaviour depending on whether the space has coupled or decoupled data servers: Coupled servers: A. Client calls pushToVoSpace(, ) returns and - the latter containing details for the data server B. Client transfers data to data server C. Behind the scenes, the data server tells VOSpace that transfer has occurred Decoupled servers: A. Client calls pushToVoSpace(, ) returns and - the latter containing details for the data server B. Client transfers data to data server C. Client notifies VOSpace that transfer has been completed, e.g. transferComplete(). Unless, of course, we make the decoupled server scenario the only way of doing it. We also have to enforce the use of transferComplete otherwise the state of the data transfer is indeterminate. The alternate is that the first part of the process is the user finding out what data servers are available with the getDataServers call I suggest at the end: A. Clients get list of data servers with getDataServers B. Client transfers data to data server C. Client registers data with VOSpace: register(, URI of location) returns the registered This is much more in keeping with the other data discovery methods we already have such as getProtocols. The process also does not leave the space in an indeterminate state. Cheers, Matthew --------------090907080504050907040101-- From owner-vospace@eso.org Fri Nov 24 17:53:42 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGqvkB029183 for ; Fri, 24 Nov 2006 17:52:57 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAOGqvWO029182 for vospace-outgoing; Fri, 24 Nov 2006 17:52:57 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGqvjd029177 for ; Fri, 24 Nov 2006 17:52:57 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAOGqtRq029051 for ; Fri, 24 Nov 2006 17:52:55 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:37935) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1Gndzo-0006eA-DO (Exim 4.63) (return-path ); Fri, 24 Nov 2006 16:33:48 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAOGXeYx026218; Fri, 24 Nov 2006 16:33:40 GMT Message-ID: <45671EDF.3000104@ast.cam.ac.uk> Date: Fri, 24 Nov 2006 16:33:35 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: [Fwd: Re: Changes to VOSpace specification] Content-Type: multipart/mixed; boundary="------------070805090203050706060900" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.21.83432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris This is a multi-part message in MIME format. --------------070805090203050706060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm forwarding these messages to the vospace list for discussion. There are a number of interested parties on the list who may not have seen the original messages. Dave --------------070805090203050706060900 Content-Type: message/rfc822; name="Re: Changes to VOSpace specification" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: Changes to VOSpace specification" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cass41 X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL autolearn=unavailable version=3.1.7 Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAN97Y7j018089; Thu, 23 Nov 2006 09:07:34 GMT X-Cam-SpamDetails: scanned, SpamAssassin-3.1.7 (score=0) X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from apollo.hq.eso.org ([134.171.42.42]:39831) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (csa=unknown) id 1GnAXz-0002H7-12 (Exim 4.63) (return-path ); Thu, 23 Nov 2006 09:07:07 +0000 Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAN96vBB003196; Thu, 23 Nov 2006 10:06:58 +0100 (CET) Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAN96qmf006960; Thu, 23 Nov 2006 10:06:52 +0100 (MET) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id kAN96pfk000302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Nov 2006 10:06:52 +0100 In-Reply-To: <456520A5.1010902@cacr.caltech.edu> References: <456520A5.1010902@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Guy Rixon , Dave Morris Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Changes to VOSpace specification Date: Thu, 23 Nov 2006 10:06:49 +0100 To: Matthew Graham X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.35 On 23.11.2006, at 05:16, Matthew Graham wrote: > Hi, > > I've had meetings in the past two weeks with the folks at JHU about > putting a VOSpace interface onto CasJobs and Arun Jagatheesan at SDSC > about the VOSpace interface with SRB. Predictably both parties raised > issues but there were three that both brought up and I think we > need to > address them: > > 1. Properties > The current scheme is limited to key-value pairs where the value is > interpreted as a string. A problem with this that some key-values > pairs > might be intended to represent other datatypes, e.g. a date or a > float, > and without this typing information, it is impossible to check the > validity of the value. It is always possible for a client to add this > information with an xsi:type attribute, e.g. > xsi:type="xs:dateTime">2006-11-22T18:50:03Z > but this might not be interpreted properly by the browser. However, if > we actually add a type attribute then we can cover this: > type="xs:dateTime">2006-11-22T18:50:03Z. > The attribute is optional and non-inclusion implies that the > datatype is > string. The value of the attribute can either be an XML datatype or a > reference to an XML schema that describes the data structure thus > allowing for more complicated properties such as: > > > 123 > 234 > 89 > > I am not so sure that this is a good idea - more or less the whole point of properties is that the server does not check the validity of them - they are simply opaque strings except for the ones that the server knows about, and then it already knows the data type. I think that this is adding an extra level of complexity to implementation requirements, without too much benefit, as it is ultimately only the client that is really going to understand your myschema.xsd example, and it could achieve the same simply by passing the xml as a string. > > 2. Views > This needs to be renamed to what it actually is, i.e. format(s), since > the current name is universally confusing. yes! - but I think it is really two concepts - on import it is just a statement of the format of the data - on export it is a request to convert the data to a format. The whole transfer object in the WSDL should reflect this difference by not using the same data structure for requests and returned information, as this is also confusing IMHO as the distinction is lost between the statements "this data is in format x" "convert this data to format y" > 3. Decoupled data servers > Under the current scheme, it is assumed that there is some > communication > channel between the VOSpace and a data server, e.g. a gridftp > server, so > that when a pushTo or pullFrom is completed, the data server can > notify > the VOSpace service that the transfer has completed. This sort of > activity is particularly necessary when the endpoint is a logical one, > e.g. a one-time-use URL. This design is fine for the cases where we > have > implemented the data servers ourselves or have access to the source > code > so that we can add the callback; however, what happens when you are > dealing with an off-the-shelf data server where this is not the > case or > non-trivial, e.g. the Globus gridftp server. > One solution is to have the client notify the VOSpace when the > transaction is complete (since this really is only a problem for the > asynchronous services) so pushToVoSpace would become: > > A. Client calls pushToVoSpace(, ) returns and > - the latter containing details for the data server > B. Client transfers data to data server > C. Client notifies VOSpace that transfer has been completed, e.g. > transferComplete(). > > There are a couple of problems with this, however: the client has to > call the space twice and might forget to do the notification call and > what happens if the transfer fails or is not done. > An alternate approach is to do the data transfer first of all and then > register the data object with the node including its physical > location so pushToVoSpace becomes: > > A. Client transfer data to data server > B. Client registers data with VOSpace: register(, URI of > location) > returns the registered > > This is actually the only transfer method which needs a > modification: all the others work fine with decoupled servers. In > fact, instead of adding an additional operation, we can modify > pushToVoSpace either to have an additional URI argument: > pushToVoSpace(, , location-uri) or we could just > incorporate the location-uri into the transfer so that if the > protocol contains an endpoint then that endpoint is interpreted to > be the physical location of the data object. > > One thing that would be useful is another operation to return the > list of (decoupled) data servers (resources in SRB speak) that the > VOSpace is using so I would suggest that we add a getDataServers > operation. > this has always been my point that we cannot brush the asynchronicity of this call under the carpet - however, I think that we have to go with the first of your two options, as I do not see how the client can really know which data server to transfer data to without contacting the VOSpace first to say where in VOSpace they want to put the data - it is then up to the VOSpace to say which data server to use as the VOSpace knows the topology. I think that the transferComplete() call would have to be "advisory", in the sense that the VOSpace should keep track of all pending inward transfers and try to determine if the data have arrived after a given time (e.g. for an ftp service it could do an ls and see if the size is the same as the size that was specified in the original pushToVoSpace) - if the VOSpace does received a transferComplete() call, it can assume that the client believes that the data have arrived safely. Cheers, Paul. --------------070805090203050706060900-- From owner-vospace@eso.org Fri Nov 24 17:53:46 2006 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGq1CH029082 for ; Fri, 24 Nov 2006 17:52:01 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAOGq1FQ029081 for vospace-outgoing; Fri, 24 Nov 2006 17:52:01 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAOGq0oK029077 for ; Fri, 24 Nov 2006 17:52:00 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAOGpwUY026897 for ; Fri, 24 Nov 2006 17:51:58 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:37881) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1GndzH-0006SY-Fx (Exim 4.63) (return-path ); Fri, 24 Nov 2006 16:33:17 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAOGXApM026192; Fri, 24 Nov 2006 16:33:11 GMT Message-ID: <45671EC1.6000702@ast.cam.ac.uk> Date: Fri, 24 Nov 2006 16:33:05 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: [Fwd: Changes to VOSpace specification] Content-Type: multipart/mixed; boundary="------------090500020906070504010900" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.21.83432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris This is a multi-part message in MIME format. --------------090500020906070504010900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm forwarding these messages to the vospace list for discussion. There are a number of interested parties on the list who may not have seen the original messages. Dave --------------090500020906070504010900 Content-Type: message/rfc822; name="Changes to VOSpace specification" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Changes to VOSpace specification" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cass41 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAN5wMc5010236; Thu, 23 Nov 2006 05:58:22 GMT X-Cam-SpamDetails: scanned, SpamAssassin-3.1.7 (score=0) X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail.cacr.caltech.edu ([131.215.145.9]:41559) by ppsw-1.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.141]:25) with esmtp (csa=unknown) id 1Gn7bE-0001xF-5g (Exim 4.63) (return-path ); Thu, 23 Nov 2006 05:58:17 +0000 Received: from [172.16.1.35] (adsl-69-234-49-8.dsl.irvnca.pacbell.net [69.234.49.8]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id kAN5w6If002834; Wed, 22 Nov 2006 21:58:07 -0800 Message-ID: <456520A5.1010902@cacr.caltech.edu> Date: Wed, 22 Nov 2006 20:16:37 -0800 From: Matthew Graham User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Guy Rixon , Dave Morris , Paul Harrison Subject: Changes to VOSpace specification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I've had meetings in the past two weeks with the folks at JHU about putting a VOSpace interface onto CasJobs and Arun Jagatheesan at SDSC about the VOSpace interface with SRB. Predictably both parties raised issues but there were three that both brought up and I think we need to address them: 1. Properties The current scheme is limited to key-value pairs where the value is interpreted as a string. A problem with this that some key-values pairs might be intended to represent other datatypes, e.g. a date or a float, and without this typing information, it is impossible to check the validity of the value. It is always possible for a client to add this information with an xsi:type attribute, e.g. 2006-11-22T18:50:03Z but this might not be interpreted properly by the browser. However, if we actually add a type attribute then we can cover this: 2006-11-22T18:50:03Z. The attribute is optional and non-inclusion implies that the datatype is string. The value of the attribute can either be an XML datatype or a reference to an XML schema that describes the data structure thus allowing for more complicated properties such as: 123 234 89 2. Views This needs to be renamed to what it actually is, i.e. format(s), since the current name is universally confusing. 3. Decoupled data servers Under the current scheme, it is assumed that there is some communication channel between the VOSpace and a data server, e.g. a gridftp server, so that when a pushTo or pullFrom is completed, the data server can notify the VOSpace service that the transfer has completed. This sort of activity is particularly necessary when the endpoint is a logical one, e.g. a one-time-use URL. This design is fine for the cases where we have implemented the data servers ourselves or have access to the source code so that we can add the callback; however, what happens when you are dealing with an off-the-shelf data server where this is not the case or non-trivial, e.g. the Globus gridftp server. One solution is to have the client notify the VOSpace when the transaction is complete (since this really is only a problem for the asynchronous services) so pushToVoSpace would become: A. Client calls pushToVoSpace(, ) returns and - the latter containing details for the data server B. Client transfers data to data server C. Client notifies VOSpace that transfer has been completed, e.g. transferComplete(). There are a couple of problems with this, however: the client has to call the space twice and might forget to do the notification call and what happens if the transfer fails or is not done. An alternate approach is to do the data transfer first of all and then register the data object with the node including its physical location so pushToVoSpace becomes: A. Client transfer data to data server B. Client registers data with VOSpace: register(, URI of location) returns the registered This is actually the only transfer method which needs a modification: all the others work fine with decoupled servers. In fact, instead of adding an additional operation, we can modify pushToVoSpace either to have an additional URI argument: pushToVoSpace(, , location-uri) or we could just incorporate the location-uri into the transfer so that if the protocol contains an endpoint then that endpoint is interpreted to be the physical location of the data object. One thing that would be useful is another operation to return the list of (decoupled) data servers (resources in SRB speak) that the VOSpace is using so I would suggest that we add a getDataServers operation. I will be post these details on the Twiki page as well. Cheers, Matthew --------------090500020906070504010900-- From owner-vospace@eso.org Mon Nov 27 09:16:42 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAR8GPGY006487 for ; Mon, 27 Nov 2006 09:16:25 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAR8GPZQ006486 for vospace-outgoing; Mon, 27 Nov 2006 09:16:25 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAR8GPnb006480 for ; Mon, 27 Nov 2006 09:16:25 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAR8DgCj006315 for ; Mon, 27 Nov 2006 09:14:58 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:33722) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1GoYsg-0007I7-Ef (Exim 4.63) (return-path ); Mon, 27 Nov 2006 05:18:14 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAR5IAj2000291; Mon, 27 Nov 2006 05:18:11 GMT Message-ID: <456A750D.1090903@ast.cam.ac.uk> Date: Mon, 27 Nov 2006 05:18:05 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Morris , IVOA VoSpace mailing list Subject: Re: Changes to VOSpace specification References: <456520A5.1010902@cacr.caltech.edu> <4567371D.3000800@ast.cam.ac.uk> In-Reply-To: <4567371D.3000800@ast.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.26.233932 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Dave Morris wrote: > Matthew Graham wrote: > >> 3. Decoupled data servers > >> ..... >> This is actually the only transfer method which needs a modification: >> all the others work fine with decoupled servers. > > No transfer methods need modification. > You can achieve the same effect using a pullToVospace call instead of > pushToVospace. Actually, this is wrong (I was still thinking in terms of version-1.0 not version-1.+). As Paul points out in another email : "we cannot brush the asynchronicity of this call under the carpet" I agree. We already have two asynchronous calls in VOSpace-1.0, and no way to manage the implied state on the server. The pushToVospace and pullFromVospace methods both initiate transfers that will happen in the future, which implies setting up something on the server to handle them. But, we don't have any way of referring to new state information created on the server. I wasn't keen on making the other two import and export methods asynchronous - until we had a way of referring to, and managing, the transfer state. Once we have that mechanism in place, then we can go ahead and make all of the transfer methods asynchronous. As Matthew has highlighted, without it, we are creating state information on the server that the client can't reach. Now that we are opening up discussion about a new version of the spec. this might be a good time to bring up a couple of suggestions I made in September. http://wiki.astrogrid.org/bin/view/Astrogrid/VoSpace20060904 Vospace version-1.1 proposal Section 2.3 - asynchronous transfers Paul added some notes when he saw them in September, and since then I have re-evaluated some of the ideas in light of his comments. So, the details in these documents are already out of date, but (I hope) the general idea is still sound. Basically, we need something (an object) to represent the state of a transfer. We could create a new set of objects, methods, service WSDL and schema to handle the new status object(s). However, we already have client and server components for querying and modifying objects (nodes) on the VOSpace server. In which case, can we represent the transfer state as a node, with child nodes for each of the protocol options ? This would enable us to query and manage the state of a transfer without having to invent a completely new set of objects and service API. So, when I said this in my previous email : > > No transfer methods need modification. > You can achieve the same effect using a pullToVospace call instead of pushToVospace. > I was wrong, they do need modification to support asynchronous transfers properly. All four of the import and export methods need to return something that refers to the state information created on the server. If the status is represented as a VOSpace node, then the the import and export methods could either return a simple "vos://..." identifier of the status node, or the full status node element. So where at the moment we have : import response ..... ..... This would change to : import response ..... ..... In effect, replacing the current transfer details node in the response with a status node. We would still be returning all the same information, but in a different wrapper. The new status node would contain the same information as the current transfer details, including the target view (as a property of the transfer node) and the list of the protocol options (as child nodes of the transfer). However, representing the information as nodes in the VOSpace service means that it remains persistent after the end of the initial SOAP call. This gives us something that the client and server can use to refer to the state information later on. The client can use the "vos://....." URI of a status node to update the state, either by manipulating the status node properties, or by using a new set of methods specifically for updating transfers, e.g. complete(), fail() and cancel(). This part of the specification wouldn't mandate _what_ the client should have to do with the status node once it has been given it. It just gives the client and server a common way of referring to the status of that particular transfer. As Matthew described, some protocols may complete without requiring a notification callback from the client, e.g a HTTP put to a servlet within the VOSpace service. In which case, the status node just provides the client, or a 3rd party, with a way of checking if the transfer has been completed yet. Other protocols will require some form of callback. In Matthews example, if the protocol involves a put to a gFTP server followed by an 'adoption' step where the VOSpace server updates its metadata to include the uploaded file, then the client may have to tell the VOSpace server when the data is ready. The client could use the "vos://...." URI of the transfer status in the callback, to tell the server which transfer (and protocol option) it is talking about. We need to remember that the VOSpace server may have offered more than one protocol option for the transfer, so the client needs to tell it which option has been completed, to enable the server to collect the data from the right place and cancel the others. The details of what the callback means, and what the server does with it, would be specific to the implementation of the protocol. If the VOSpace and gFTP server are acting as one entity, then the VOSpace server may leave the data within the gFTP server file system, and just update the node metadata. On the other hand, if the gFTP server is acting as a staging post, then the VOSpace server may collect the data from the back end and move it to another location within its own file system. In summary : Mathew has highlighted the fact that we already need a callback mechanism for some of the existing import and export protocols. Whatever callback mechanism we adopt, it will need some way to refer to the persistent state within the VOSpace server, that represents the state of the transfer and the individual protocol options within it. Representing these as VOSpace nodes means that we can use the existing "vos://..." URI scheme to refer to them, and the existing API to list, query and modify them. Once we have a standard way of referring to the persistent state of a transfer, then my previous email about making the details of the callback specific to the protocol might make sense. Without it, the client has no way of telling the server which transfer and protocol option it is talking about. Hope some of this may be useful, Dave From owner-vospace@eso.org Mon Nov 27 13:05:04 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kARC4rZ0012202 for ; Mon, 27 Nov 2006 13:04:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kARC4rx1012200 for vospace-outgoing; Mon, 27 Nov 2006 13:04:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kARC4k5w012169; Mon, 27 Nov 2006 13:04:46 +0100 (MET) Received: from [192.168.2.101] (p5498F097.dip.t-dialin.net [84.152.240.151]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id kARC4ifk004911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Nov 2006 13:04:45 +0100 In-Reply-To: <456A750D.1090903@ast.cam.ac.uk> References: <456520A5.1010902@cacr.caltech.edu> <4567371D.3000800@ast.cam.ac.uk> <456A750D.1090903@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Changes to VOSpace specification Date: Mon, 27 Nov 2006 13:04:41 +0100 To: Dave Morris X-Mailer: Apple Mail (2.752.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 27.11.2006, at 06:18, Dave Morris wrote: > Dave Morris wrote: > >> Matthew Graham wrote: >> >>> 3. Decoupled data servers >> >>> ..... >>> This is actually the only transfer method which needs a >>> modification: all the others work fine with decoupled servers. >> >> No transfer methods need modification. >> You can achieve the same effect using a pullToVospace call instead >> of pushToVospace. > > Actually, this is wrong (I was still thinking in terms of > version-1.0 not version-1.+). > > As Paul points out in another email : > "we cannot brush the asynchronicity of this call under the carpet" > > I agree. > We already have two asynchronous calls in VOSpace-1.0, and no way > to manage the implied state on the server. > > The pushToVospace and pullFromVospace methods both initiate > transfers that will happen in the future, which implies setting up > something on the server to handle them. > But, we don't have any way of referring to new state information > created on the server. > > I wasn't keen on making the other two import and export methods > asynchronous - until we had a way of referring to, and managing, > the transfer state. > Once we have that mechanism in place, then we can go ahead and make > all of the transfer methods asynchronous. > As Matthew has highlighted, without it, we are creating state > information on the server that the client can't reach. > > Now that we are opening up discussion about a new version of the > spec. this might be a good time to bring up a couple of suggestions > I made in September. > > http://wiki.astrogrid.org/bin/view/Astrogrid/VoSpace20060904 > > Vospace version-1.1 proposal > Section 2.3 - asynchronous transfers > > Paul added some notes when he saw them in September, and since then > I have re-evaluated some of the ideas in light of his comments. > So, the details in these documents are already out of date, but (I > hope) the general idea is still sound. To summarize my objections * sometimes it is more convenient for both the client and the server implementation to have a specific API for operations rather than having to manipulate objects using a "general" api - though I do recognize that there is some power and flexibility in the general api approach cf everything is a file in unix... * I was not keen on the "control" objects polluting the namespace in the sense that as illustrated in the document that they would appear directly in listings - I would much prefer that any such control objects attached to a data node were only accessible by using the ? (query) portion of the vos url - e.g. the full URL to obtain the transfer status for a data node could be vos://org.test!vospace/container/node?transfer and a list of all pending transfers for the space itself could be referred to by such a query on the root node. > > Basically, we need something (an object) to represent the state of > a transfer. > We could create a new set of objects, methods, service WSDL and > schema to handle the new status object(s). > > However, we already have client and server components for querying > and modifying objects (nodes) on the VOSpace server. > In which case, can we represent the transfer state as a node, with > child nodes for each of the protocol options ? > This would enable us to query and manage the state of a transfer > without having to invent a completely new set of objects and > service API. > > So, when I said this in my previous email : > > > > No transfer methods need modification. > > You can achieve the same effect using a pullToVospace call > instead of pushToVospace. > > > I was wrong, they do need modification to support asynchronous > transfers properly. > All four of the import and export methods need to return something > that refers to the state information created on the server. > > If the status is represented as a VOSpace node, then the the import > and export methods could either return a simple "vos://..." > identifier of the status node, or the full status node element. > > So where at the moment we have : > > import response > > > ..... > > > > > > ..... > > > > This would change to : > > import response > > > ..... > > > > ..... > > > In effect, replacing the current transfer details node in the > response with a status node. > We would still be returning all the same information, but in a > different wrapper. > > The new status node would contain the same information as the > current transfer details, including the target view (as a property > of the transfer node) and the list of the protocol options (as > child nodes of the transfer). However, representing the information > as nodes in the VOSpace service means that it remains persistent > after the end of the initial SOAP call. This gives us something > that the client and server can use to refer to the state > information later on. > > The client can use the "vos://....." URI of a status node to update > the state, either by manipulating the status node properties, or by > using a new set of methods specifically for updating transfers, > e.g. complete(), fail() and cancel(). > > This part of the specification wouldn't mandate _what_ the client > should have to do with the status node once it has been given it. > It just gives the client and server a common way of referring to > the status of that particular transfer. > > As Matthew described, some protocols may complete without requiring > a notification callback from the client, e.g a HTTP put to a > servlet within the VOSpace service. In which case, the status node > just provides the client, or a 3rd party, with a way of checking if > the transfer has been completed yet. > > Other protocols will require some form of callback. > In Matthews example, if the protocol involves a put to a gFTP > server followed by an 'adoption' step where the VOSpace server > updates its metadata to include the uploaded file, then the client > may have to tell the VOSpace server when the data is ready. > > The client could use the "vos://...." URI of the transfer status in > the callback, to tell the server which transfer (and protocol > option) it is talking about. We need to remember that the VOSpace > server may have offered more than one protocol option for the > transfer, so the client needs to tell it which option has been > completed, to enable the server to collect the data from the right > place and cancel the others. > > The details of what the callback means, and what the server does > with it, would be specific to the implementation of the protocol. > If the VOSpace and gFTP server are acting as one entity, then the > VOSpace server may leave the data within the gFTP server file > system, and just update the node metadata. > On the other hand, if the gFTP server is acting as a staging post, > then the VOSpace server may collect the data from the back end and > move it to another location within its own file system. > > In summary : > > Mathew has highlighted the fact that we already need a callback > mechanism for some of the existing import and export protocols. And this does has a bearing on the delivery of a 1.0 standard if we are to promise backward compatibility..... > > Whatever callback mechanism we adopt, it will need some way to > refer to the persistent state within the VOSpace server, that > represents the state of the transfer and the individual protocol > options within it. Representing these as VOSpace nodes means that > we can use the existing "vos://..." URI scheme to refer to them, > and the existing API to list, query and modify them. It might just be a question of teminology, but as I said the idea that they are just "ordinary nodes" that appear in the container listings, I do not like, however if they are accessible via the query part of the URL, I am more amenable. However, although the existing api is ok for querying and listing control objects, I am not so sure it is that suitable for modifying them - after all, this whole discussion has flared up because of the complexities of the data upload within VOSpace - whilst these complexities are acceptable for uploading data objects (so that we can take advantage of the special qualities of existing data transfer protocols), an specialized api might be more suitable for modifying control objects. > > Once we have a standard way of referring to the persistent state of > a transfer, then my previous email about making the details of the > callback specific to the protocol might make sense. Without it, the > client has no way of telling the server which transfer and protocol > option it is talking about. I think that we should try to extract as much common protocol behaviour as possible - I think that as soon as a protocol is not completely described by the transfer URL we get into complications that would be better to avoid to maintain interoperability - we need to utilise as much of the common characteristics of a protocol as possible before layering what are non-standard protocol behaviours on top of externally defined protocols From owner-vospace@eso.org Mon Nov 27 14:49:00 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kARDmo0O011123 for ; Mon, 27 Nov 2006 14:48:50 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kARDmocG011122 for vospace-outgoing; Mon, 27 Nov 2006 14:48:50 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kARDmnUo011118; Mon, 27 Nov 2006 14:48:49 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kARDmYWe018949; Mon, 27 Nov 2006 14:48:48 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:52459) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1GogqH-0006sH-F0 (Exim 4.63) (return-path ); Mon, 27 Nov 2006 13:48:18 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kARDmBfm010176; Mon, 27 Nov 2006 13:48:12 GMT Message-ID: <456AEC96.2060401@ast.cam.ac.uk> Date: Mon, 27 Nov 2006 13:48:06 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: IVOA VoSpace mailing list Subject: Re: Changes to VOSpace specification References: <456520A5.1010902@cacr.caltech.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.27.53433 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > On 23.11.2006, at 05:16, Matthew Graham wrote: > >> 2. Views >> This needs to be renamed to what it actually is, i.e. format(s), sincexx >> the current name is universally confusing. > > yes! - but I think it is really two concepts - on import it is just a > statement of the format of the data - on export it is a request to > convert the data to a format. The whole transfer object in the WSDL > should reflect this difference by not using the same data structure > for requests and returned information, as this is also confusing IMHO > as the distinction is lost between the statements > "this data is in format x" > "convert this data to format y" I agree. These are two separate things, and 'view' on its own does not work for either. I started to write a reply to this ... but it kind of grew, so I converted it into a wiki page instead. http://wiki.astrogrid.org/bin/view/Astrogrid/VoSpace20061127 Summary : In an import to VOSpace, all you want to say is "I want to send a FITS image". Every time I explain the current system to people, they look blank when I describe "selecting which view to import". It isn't clear what it actually means - even to us. * Drop 'view' for import and just use 'format' instead. In the export from VOSpace, we have mangled three concepts into one element, and it doesn't work properly. Describing the available outputs requires three separate things * What views of the data are available ('original file' qualifies as a view) * What formats are they available in * What transport protocols can I use to get them Anyway ... see what you think. Thanks, Dave From owner-vospace@eso.org Mon Nov 27 15:52:47 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAREqbD9022646 for ; Mon, 27 Nov 2006 15:52:37 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAREqbra022645 for vospace-outgoing; Mon, 27 Nov 2006 15:52:37 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAREqagX022639; Mon, 27 Nov 2006 15:52:37 +0100 (MET) Received: from ppsw-2.csi.cam.ac.uk (ppsw-2.csi.cam.ac.uk [131.111.8.132]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAREqVEY000515; Mon, 27 Nov 2006 15:52:31 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:58306) by ppsw-2.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.132]:25) with esmtp id 1Gohq7-0001PT-7l (Exim 4.63) (return-path ); Mon, 27 Nov 2006 14:52:11 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAREq3WP014514; Mon, 27 Nov 2006 14:52:04 GMT Message-ID: <456AFB8E.2060606@ast.cam.ac.uk> Date: Mon, 27 Nov 2006 14:51:58 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: IVOA VoSpace mailing list Subject: Re: Changes to VOSpace specification References: <456520A5.1010902@cacr.caltech.edu> <4567371D.3000800@ast.cam.ac.uk> <456A750D.1090903@ast.cam.ac.uk> <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> In-Reply-To: <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.27.63933 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > On 27.11.2006, at 06:18, Dave Morris wrote: > >> Paul added some notes when he saw them in September, and since then I >> have re-evaluated some of the ideas in light of his comments. >> So, the details in these documents are already out of date, but (I >> hope) the general idea is still sound. > > To summarize my objections > > * sometimes it is more convenient for both the client and the server > implementation to have a specific API for operations rather than > having to manipulate objects using a "general" api - though I do > recognize that there is some power and flexibility in the general api > approach cf everything is a file in unix... Yep, I agree. The existing VOSpace tools would give us a standard way of referring to the status object (their URI) and a quick way of checking their status by looking at the properties. Changing the state _could_ be done by setting the node properties, but I agree it is stretching things. It might be better to have a separate API with methods like completed(), failed() and cancel() . It could still use the same URI identifiers, so you would pass the URI of the status node to the cancel() method. > * I was not keen on the "control" objects polluting the namespace in > the sense that as illustrated in the document that they would appear > directly in listings Yep, I agree. Sorry, I haven't updated the document since we talked. The status nodes should not appear alongside the data nodes. > - I would much prefer that any such control objects attached to a data > node were only accessible by using the ? (query) portion of the vos > url - e.g. the full URL to obtain the transfer status for a data node > could be > > vos://org.test!vospace/container/node?transfer > > and a list of all pending transfers for the space itself could be > referred to by such a query on the root node. Not sure about that one. There are possibly better uses of the ? operator - and we can only use it once. The functionality you describe could be handled by a separate ListStatusNodes() method. You pass in the URI of the data node you are interested in, and it returns a list of the active transfers for that node. We could extend it later to query for all the active|completed|failed|canceled transfers over a specific time range ... giving us a history of the target data node. It also means that it is up to the server implementation where it puts them. They could be in a separate container, or even a separate space. The ListStatusNodes() method would find them and return a single list of simple nodes or even just their URIs. In the document I wasn't clear about where the status nodes were, because I hadn't figured that bit out yet. If we added a ListStatusNodes() method the UI would be able to show them in a separate panel, possibly something triggered off the right-click menu. >> Whatever callback mechanism we adopt, it will need some way to refer >> to the persistent state within the VOSpace server, that represents >> the state of the transfer and the individual protocol options within >> it. Representing these as VOSpace nodes means that we can use the >> existing "vos://..." URI scheme to refer to them, and the existing >> API to list, query and modify them. > > > It might just be a question of teminology, but as I said the idea that > they are just "ordinary nodes" that appear in the container listings, > I do not like, Yep, I agree, not in the same list as the data nodes. Implementation dependent as to where the service actually puts them, just not in the same place as the normal data nodes that they refer to. They could even be in a separate space altogether, one that just contains status nodes. The two spaces could be within the same service implementation - just different ivo:// registration URIs for the root nodes. The ListStatusNodes() method would just return vos://... URIs pointing to the status nodes in the 'other space'. > however if they are accessible via the query part of the URL, I am > more amenable. However, although the existing api is ok for querying > and listing control objects, I am not so sure it is that suitable for > modifying them - after all, this whole discussion has flared up > because of the complexities of the data upload within VOSpace - whilst > these complexities are acceptable for uploading data objects (so that > we can take advantage of the special qualities of existing data > transfer protocols), an specialized api might be more suitable for > modifying control objects. Yep - agree with that too. It would be better to modify the status using a separate set of methods, complete(), fail() and cancel() etc. The status node can display the current state as properties, but they would be read-only. Attempting to modify a transfer status by tweaking one of the properties should probably throw PermissionDenied. I think I agree with most of your comments, I just hadn't had time to update the doc yet. I'll see if I can bring together some of the new ideas from various discussions over the last few months and write a new doc. Thanks, Dave From owner-vospace@eso.org Mon Nov 27 16:41:56 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kARFfmsM001477 for ; Mon, 27 Nov 2006 16:41:48 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kARFfmZ2001476 for vospace-outgoing; Mon, 27 Nov 2006 16:41:48 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kARFfgku001460; Mon, 27 Nov 2006 16:41:42 +0100 (MET) Received: from [192.168.2.101] (vpn-6.hq.eso.org [134.171.76.6]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id kARFfefk010638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Nov 2006 16:41:41 +0100 In-Reply-To: <456AFB8E.2060606@ast.cam.ac.uk> References: <456520A5.1010902@cacr.caltech.edu> <4567371D.3000800@ast.cam.ac.uk> <456A750D.1090903@ast.cam.ac.uk> <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> <456AFB8E.2060606@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Changes to VOSpace specification Date: Mon, 27 Nov 2006 16:41:32 +0100 To: Dave Morris X-Mailer: Apple Mail (2.752.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 27.11.2006, at 15:51, Dave Morris wrote: > >> * I was not keen on the "control" objects polluting the namespace >> in the sense that as illustrated in the document that they would >> appear directly in listings > > Yep, I agree. > Sorry, I haven't updated the document since we talked. > The status nodes should not appear alongside the data nodes. > >> - I would much prefer that any such control objects attached to a >> data node were only accessible by using the ? (query) portion of >> the vos url - e.g. the full URL to obtain the transfer status for >> a data node could be >> >> vos://org.test!vospace/container/node?transfer >> >> and a list of all pending transfers for the space itself could be >> referred to by such a query on the root node. > > Not sure about that one. > There are possibly better uses of the ? operator - and we can only > use it once. > > The functionality you describe could be handled by a separate > ListStatusNodes() method. > You pass in the URI of the data node you are interested in, and it > returns a list of the active transfers for that node. > We could extend it later to query for all the active|completed| > failed|canceled transfers over a specific time range ... giving us > a history of the target data node. I guess that I am arguing for what we could do if there was no ListStatusNodes() method and this was done with the existing API - we could use this part of the URL for multiple things - I was not really very careful with the syntax but if we had something like vos://org.test!vospace/container/node?operation=transfer_status we could then do things like vos://org.test!vospace/container/node? operation=get_view&view=jpeg_cutout which leads me to the thought that perhaps we are being too purist not having a direct getContent(URI) SOAP call that does return the "content" of the URI as a synchronous result, in-line. With the formal XML being a choice of an "any" xml or a small xml structure with a element with base64 encoded data in it, so that either the actual node data could be returned, or any of the control objects (actually pretty much the same as Amazon S3 - getObject method). OK- this is not as efficient as the multiprotocol data transfer methods, but it does give the client something very simple that it can implement, and perhaps we can also say that servers are allowed to throw a "fetch with multiprotocol transfer method instead" exception if they feel that a data object is being requested is too large to return in-line. Paul. Paul Harrison ESO Garching www.eso.org From owner-vospace@eso.org Tue Nov 28 04:22:36 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAS3MGq7001276 for ; Tue, 28 Nov 2006 04:22:16 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAS3MGst001275 for vospace-outgoing; Tue, 28 Nov 2006 04:22:16 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAS3MFtG001271; Tue, 28 Nov 2006 04:22:15 +0100 (MET) Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAS3MBEY020495; Tue, 28 Nov 2006 04:22:12 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:48918) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1GotXn-0004JC-4v (Exim 4.63) (return-path ); Tue, 28 Nov 2006 03:22:03 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAS3Lwtf019328; Tue, 28 Nov 2006 03:21:58 GMT Message-ID: <456BAB51.50008@ast.cam.ac.uk> Date: Tue, 28 Nov 2006 03:21:53 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: IVOA VoSpace mailing list Subject: Re: Changes to VOSpace specification References: <456520A5.1010902@cacr.caltech.edu> <4567371D.3000800@ast.cam.ac.uk> <456A750D.1090903@ast.cam.ac.uk> <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> In-Reply-To: <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.27.190932 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > On 27.11.2006, at 06:18, Dave Morris wrote: > >> The details of what the callback means, and what the server does >> with it, would be specific to the implementation of the protocol. >> If the VOSpace and gFTP server are acting as one entity, then the >> VOSpace server may leave the data within the gFTP server file >> system, and just update the node metadata. >> On the other hand, if the gFTP server is acting as a staging post, >> then the VOSpace server may collect the data from the back end and >> move it to another location within its own file system. >> >> In summary : >> >> Mathew has highlighted the fact that we already need a callback >> mechanism for some of the existing import and export protocols. > > And this does has a bearing on the delivery of a 1.0 standard if we > are to promise backward compatibility..... Only if you want to do the complicated side of things. If you have an image archive in a public ftp server, then the files stay where they are and the URLs don't change, so the VOSpace server does not have to store any state for a transfer. For read access, we would only need to store state if we wanted to do things like one-time access URLs with cookies encoded in them. Even then, if we are using a servlet integrated with the VOSpace service the servlet will know when the transfer has been completed so we don't need a callback. For write access, then using a servlet integrated with the VOSpace service means that we don't need callbacks, because the servlet knows when the transfer ends. Write access to an external GridFtp server, which is what Matthew initially raised, is a little complicated to achieve, but still possible. I'm not saying the current spec does everything we need. Just that it does enough for now. If we delay the spec to add the asynchronous callbacks, then a) we will never get it out the door because new thing will always come up, and b) we will be under pressure to get the specification signed off, so we will not be as careful as we should be about how we implement the callbacks. We have some good ideas for the next version, but barring major show stoppers, lets leave 1.0 as it is, and get it through the process. >> Once we have a standard way of referring to the persistent state of >> a transfer, then my previous email about making the details of the >> callback specific to the protocol might make sense. Without it, the >> client has no way of telling the server which transfer and protocol >> option it is talking about. > > I think that we should try to extract as much common protocol > behaviour as possible - I think that as soon as a protocol is not > completely described by the transfer URL we get into complications > that would be better to avoid to maintain interoperability - we need > to utilise as much of the common characteristics of a protocol as > possible before layering what are non-standard protocol behaviours > on top of externally defined protocols I think we might be using the same word to talk about two different things. Protocol can mean different things depending on what layer you are looking at. HTTP and SMTP are protocols, but so is SOAP, and you can layer one protocol on top of another, giving you SOAP via HTTP and SOAP via SMTP, or even SOAP via Jabber. In addition, SOAP itself has a number of sequence variations, call-only, call and respond, call and call-back etc. - I can't remember the acronyms for these. I think perhaps we need to find some different words to describe the parts that we have. First, at the bottom layer is the actual transport-protocol on the network, http, ftp etc. On top of that we have the way that we use the transport-protocol, call it the transfer-method. This describes things like what authentication is required and how we want to notify the service that the transfer has completed. These are things we will have to define ourselves, and register descriptions in the registry. In all of my examples I have tended to use an abbreviated form of notation : because the full registry URIs would make things very complicated for a human to read. This isn't a problem in the live system, because a human should never have to write or edit them. But in the examples I needed to use short abbreviations to make things easier to read. So replacing 'protocol' with 'transfer-method' the full expanded form would be: Where the transfer-method URI points to a registration document that says something like this : ivo://net.ivoa.vospace/transfer-methods/http-put This is a VOSpace transfer method that uses the standard http-put transport protocol, with chunked data encoding. On a call to pushToVoSpace, the service returns a standard http://.. URL which the client should send the data to. The client sends the data to the URL using the HTTP-1.1 PUT transport protocol. Using chunked-data encoding means that the client does not need to send the content-length header field at the start of the transfer. The transfer completes automatically when the client closes the HTTP connection, and no callback is required to complete the transfer. Note - any service that offers this as a protocol option must ensure that it can receive data sent using the chunked data encoding. A VOSpace service could implement this using a Java Servlet integrated within the VOSpace service. There is no need to have a callback because the Servlet will know when the transfer finishes, and it can update the VOSpace metadata internally. The client sends the data and then forgets it, the server side takes care of updating everything. However, if someone wants to use a separate Apache web server to receive the data, then they will either have to modify the Apache server, or they will have to use a more complex transfer-method. The transfer-method URI refers to a registration document that says something like this : ivo://net.ivoa.vospace/transfer-methods/http-put-callback-1.3 This is a VOSpace transfer method that uses the standard http-put transport protocol, with chunked data encoding. .... When the client has finished sending the data, it must notify the VOSpace service via a callback API. If no callback has been received within the time limit, then the service may cancel the transfer and remove and temporary files. The details of the callback service API is defined in [this] document. The WSDL and schema for the callback WebService are [here] and [here]. We may want to add some general purpose callback methods to the next version of the VOSpace API. It looks like completed(), failed() and canceled() operations on the status nodes are good candidates for this. In which case, a new version of the [http-put-callback] transfer method could be defined as follows : ivo://net.ivoa.vospace/transfer-methods/http-put-callback-1.4 This is a VOSpace transfer method that uses the standard http-put transport protocol. .... When the client has finished sending the data, it must notify the VOSpace service using the completed() or failed() methods defined in the VOSpace-1.1 specification. If no callback has been received within the time limit, then the service may cancel the transfer and remove and temporary files. Sorry for being long winded about this, but I think you have highlighted an important point of confusion, between ourselves and in our presentation of this to others, so it would be useful to work through the details and get things right. Three things to note about the above descriptions. 1) Both transfer-methods use the same underlying transport-protocol, so the transport layer endpoint URLs will look identical, so we can't use the transport layer URLs to distinguish between the different transfer-methods. 2) Each transfer-method has a unique URI that points to a full description of the transfer-method. That was one of the original reasons for putting them in the registry, we get a unique identifier for each one, and a common way of resolving the URI into a description. 3) The description of the [http-put-callback] transfer method does not need to be part of the VOSpace service specification. It doesn't even need to use the standard VOSpace callback mechanism. This means that you could define a new transfer-method for moving things around within ESO, using the [ngas-replication] method. Underneath, it might use the http transport-protocol to move the bytes, and it might use calls to the VOSpace-1.1 status callback as part of the process, but you could add any additional steps or notifications required to update the NGAS system in the transfer method description : ivo://org.eso.vospace/transfer-methods/ngas-replication-2.0 This is a VOSpace transfer method for use by the internal NGAS systems within ESO. The transfer method uses the standard http-put transport protocol to move the data. The sending client must use the completed() or failed() methods defined in the VOSpace-1.1 specification to notify the service when the transfer has finished. In addition, the client needs to call the xyz() method on the NGAS system to authenticate and receive a transfer token. We will start with a set of commonly used transfer-methods, defined in the ivo://net.ivoa.vospace/ registry, which will cover the plain vanilla uses of the core protocols with no callback, like [http-get], [http-put], [ftp-get] and [ftp-put] etc. Once we have a way of referring to and manipulating server side state (status nodes), then we can add the completed(), failed() and canceled() callback methods to the VOSpace specification. Once we have the standard callback methods, then we can define the callback versions of [http-put-callback], [ftp-put-callback] and [gftp-callback] etc. In the mean time, 3rd party developers can implement the standard [http-get] and [http-put] transfer methods, with no callback required, by using Java Servlets integrated into the same webapp as the VOSpace service. We only start to need callbacks when we are trying to import data into 3rd party servers like an Apache or GridFtp server co-located but not integrated with the VOSpace service itself. Even that isn't impossible, just a little more complicated. Again, apologies for going into so much detail, but I think we are actually fairly close to getting a lot of this solved. The stopping points seem to be when I/we use words like 'view' and 'protocol' to mean different things, and we get side tracked. So, does the distinction between 'transfer-method' and 'transport-protocol' make sense ? If so, are 'transfer-method' and 'transport-protocol' good replacements for the more generic term 'protocol' ? In your comment, waaay back up there somewhere, you said > ... as soon as a protocol is not completely described by the transfer URL we get into complications Unfortunately, the endpoint URL can't be used to describe the transfer-method. There is no way to tell from a transfer-protocol URL if it the transfer-method it is being used in requires a callback or not (which is where this thread started). On the other hand, our SOAP messages use the transfer-method URI to refer to transport-method, and this does resolve to a resource that describes all the details of the method. So, for brevity in descriptions and examples I may use this : When I actually mean this : which should be resolvable to a full description of the transfer-method, including details of how it uses the underlying transport-protocol and the API of any callback methods it requires. Thank you for reading this far. Dave From owner-vospace@eso.org Tue Nov 28 06:30:42 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAS5UXc9012517 for ; Tue, 28 Nov 2006 06:30:33 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kAS5UX20012516 for vospace-outgoing; Tue, 28 Nov 2006 06:30:33 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kAS5UXnp012509; Tue, 28 Nov 2006 06:30:33 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kAS5UVpM025773; Tue, 28 Nov 2006 06:30:31 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:54729) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1GovXx-0002mE-Fr (Exim 4.63) (return-path ); Tue, 28 Nov 2006 05:30:21 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kAS5UIkb021619; Tue, 28 Nov 2006 05:30:18 GMT Message-ID: <456BC965.7020804@ast.cam.ac.uk> Date: Tue, 28 Nov 2006 05:30:13 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: IVOA VoSpace mailing list Subject: Re: Changes to VOSpace specification References: <456520A5.1010902@cacr.caltech.edu> <4567371D.3000800@ast.cam.ac.uk> <456A750D.1090903@ast.cam.ac.uk> <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> <456AFB8E.2060606@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.27.211433 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > I guess that I am arguing for what we could do if there was no > ListStatusNodes() method and this was done with the existing API - we > could use this part of the URL for multiple things - I was not really > very careful with the syntax but if we had something like > > vos://org.test!vospace/container/node?operation=transfer_status > > we could then do things like > > vos://org.test!vospace/container/node? > operation=get_view&view=jpeg_cutout We are designing a SOAP webservice - so why add yet another syntax for calling methods. If we didn't already have a SOAP service, then you might have a case. Just add status nodes and ListStatusNodes() to version-1.1 of the schema, and we can have it up and running by the next IVOA meeting. All of the operations can be handled in the existing VOSpace specification using Java Servlets or their equivalent integrated within the VOSpace service. We don't _need_ callbacks in version-1.0. > which leads me to the thought that perhaps we are being too purist > not having a direct getContent(URI) SOAP call that does return the > "content" of the URI as a synchronous result, in-line. With the > formal XML being a choice of an "any" xml or a small xml structure > with a element with base64 encoded data in it .... How about this : Where the URI points to a resource that says something like this : ivo://net.ivoa.vospace/transfer-methods/dime-get-inline-1.0 This is a VOSpace transfer method that uses the Direct Internet Message Encapsulation (DIME) message format to return the node contents as a SOAP attachment. Details of the DIME specification can be found at here [http://msdn.microsoft.com/library/en-us/dnglobspec/html/draft-nielsen-dime-02.txt] Usage: The client calls PullFromVOSpace specifying this transfer-method in the request. If the request is valid, then the server will respond with the standard PullFromVOSpace, response, and attach the data node contents to the end of the message as a DIME attachment. The transfer completes when the SOAP response is received by the client. No additional steps are required. If the server is unable to attach the data node contents to the message, then it either will response with the appropriate error message, or a list of other transfer-methods if they are available. Or this : Where the URI points to a resource that says something like this : ivo://net.ivoa.vospace/transfer-methods/mtom-get-inline-1.0 This is a VOSpace transfer method that uses the Message Transmission Optimization Mechanism (MTOM) message format to return the node contents as a SOAP attachment. Details of the MTOM specification can be found here [http://www.w3.org/TR/soap12-mtom/] Usage: The client calls PullFromVOSpace specifying this transfer-method in the request. If the request is valid, then the server will respond with the standard PullFromVOSpace, response, and attach the data node contents to the end of the message as a MTOM attachment. The transfer completes when the SOAP response is received by the client. No additional steps are required. If the server is unable to attach the data node contents to the message, then it either will response with the appropriate error message, or a list of other transfer-methods if they are available. Both of which are possible within the current VOSpace version 1.0 specification. > .... (actually pretty much the same as Amazon S3 - getObject method). > OK- this is not as efficient as the multiprotocol data transfer > methods .... See : http://solutions.amazonwebservices.com/connect/ann.jspa?annID=144 Posted : Oct 23, 2006 11:21 PM /In a few weeks time, you will no longer be able to use the Amazon S3 SOAP interface's PutObjectInline or GetObjectInline for objects that are larger than 1 megabyte in size. After November 21, affected requests will fail with the new error response InlineDataTooLargeError. To put or get objects that are larger than 1 megabyte in size, you will need to either use DIME attachments with SOAP requests or use our REST interface. We apologize for any inconvenience this change may cause you. Please be assured that deprecating existing functionality is not a change we take lightly. We are making this change because transferring large objects inline in the SOAP message (as happens with PutObjectInline and GetObjectInline) has significant negative performance implications; it is a mechanism only suited to transferring small amounts of data. The SOAP-based alternative, using DIME attachments, now has wide support in SOAP toolkits, is more efficient and does not suffer from the same performance bottlenecks. It also allows us to optimize our service to give you better performance./ > .... but it does give the client something very simple that it can > implement .... What is so difficult in a client implementing this : Where the URI points to a resource that says something like this : ivo://net.ivoa.vospace/transfer-methods/http-get This is a VOSpace transfer method that uses the standard http-get transport protocol. Details of the transport protocol are available here [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3]. Usage: The client calls PullFromVOSpace specifying this transfer-method in the request. If the request is valid, then the server will respond with the standard PullFromVOSpace, response, and add a element containing the endpoint URL to fetch the data from. The client uses the URL to download the data using a standard http-get request. The transfer method completes automatically when the client has received the data, and no notification callbacks are required. > .... and perhaps we can also say that servers are allowed to throw a > "fetch with multiprotocol transfer method instead" exception if they > feel that a data object is being requested is too large to return > in-line .... This would mean adding a new exception to the VOSpace service WSDL, one that isn't connected with the core VOSpace API but is specific to one transfer-method only. Given that the current version-1.0 specification can support [dime-get-inline], [mtom-get-inline] and [http-get], I don't see the case for modifying the VOSpace specification to support a custom version of http-get, using ? to encode method params outside the SOAP message and a non standard way of encoding the data. As yet, no show stopper bugs found - the current version-1.0 specification is good enough. Lets get that through the process and then we can add status nodes, ListStatusNodes() and a generic set of notification callbacks to the next version. Dave From owner-vospace@eso.org Tue Nov 28 11:22:35 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kASALr4P013520 for ; Tue, 28 Nov 2006 11:21:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kASALruM013519 for vospace-outgoing; Tue, 28 Nov 2006 11:21:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kASALkOZ013505; Tue, 28 Nov 2006 11:21:46 +0100 (MET) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id kASALkYp009258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Nov 2006 11:21:46 +0100 In-Reply-To: <456BC965.7020804@ast.cam.ac.uk> References: <456520A5.1010902@cacr.caltech.edu> <4567371D.3000800@ast.cam.ac.uk> <456A750D.1090903@ast.cam.ac.uk> <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> <456AFB8E.2060606@ast.cam.ac.uk> <456BC965.7020804@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00D12ED4-069E-474C-ACBD-915A997F147C@eso.org> Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Changes to VOSpace specification Date: Tue, 28 Nov 2006 11:21:44 +0100 To: Dave Morris X-Mailer: Apple Mail (2.752.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 28.11.2006, at 06:30, Dave Morris wrote: > Paul Harrison wrote: > >> I guess that I am arguing for what we could do if there was no >> ListStatusNodes() method and this was done with the existing API - >> we could use this part of the URL for multiple things - I was not >> really very careful with the syntax but if we had something like >> >> vos://org.test!vospace/container/node?operation=transfer_status >> >> we could then do things like >> >> vos://org.test!vospace/container/node? >> operation=get_view&view=jpeg_cutout > > We are designing a SOAP webservice - so why add yet another syntax > for calling methods. > If we didn't already have a SOAP service, then you might have a case. because a major thing that people want to be able to do is use a URL to identify a dataset when publishing a paper for instance - if views are allowed that alter the presentation of data, then it is not really very pretty to have to write a chunk of xml that represents the call to VOSpace to be able to make the statement - "get this dataset with this particular view" as a reference in a paper. However, it is not a showstopper for 1.0 - but something to consider for the future. If we can find a good compromise between the advantages of SOAP with some REST-like semantics in the vos: URI, it would be appreciated by the users. > > How about this : > > > > Where the URI points to a resource that says something like this : > > ivo://net.ivoa.vospace/transfer-methods/dime-get-inline-1.0 > This is a VOSpace transfer method that uses the Direct > Internet Message Encapsulation (DIME) message format to return the > node contents as a SOAP attachment. > Details of the DIME specification can be found at here > [http://msdn.microsoft.com/library/en-us/dnglobspec/html/draft- > nielsen-dime-02.txt] > > Usage: > The client calls PullFromVOSpace specifying this transfer- > method in the request. > If the request is valid, then the server will respond with > the standard PullFromVOSpace, > response, and attach the data node contents to the end of the > message as a DIME attachment. > > The transfer completes when the SOAP response is received by > the client. > No additional steps are required. > > If the server is unable to attach the data node contents to > the message, then it either > will response with the appropriate error message, or a list > of other transfer-methods > if they are available. > > Or this : > > > > Where the URI points to a resource that says something like this : > > ivo://net.ivoa.vospace/transfer-methods/mtom-get-inline-1.0 > This is a VOSpace transfer method that uses the Message > Transmission Optimization Mechanism (MTOM) message format to return > the node contents as a SOAP attachment. > Details of the MTOM specification can be found here [http:// > www.w3.org/TR/soap12-mtom/] > > Usage: > The client calls PullFromVOSpace specifying this transfer- > method in the request. > If the request is valid, then the server will respond with > the standard PullFromVOSpace, > response, and attach the data node contents to the end of the > message as a MTOM attachment. > > The transfer completes when the SOAP response is received by > the client. > No additional steps are required. > > If the server is unable to attach the data node contents to > the message, then it either > will response with the appropriate error message, or a list > of other transfer-methods > if they are available. > > Both of which are possible within the current VOSpace version 1.0 > specification. These are fine, and having the attachment as part of the control method SOAP call is much my preferred way of doing things - Appendix A of the current draft of the standard is still a little confusing in this respect, as it makes it sound as if the expected way for attachments to work is by calling another service, which defeats the point of attachments a little in that the whole operation to get or put data is no-longer atomic nor synchronous. just one more point - why do we need to distinguish between get and put? > >> .... (actually pretty much the same as Amazon S3 - getObject >> method). OK- this is not as efficient as the multiprotocol data >> transfer methods .... > > See : http://solutions.amazonwebservices.com/connect/ann.jspa? > annID=144 > Posted : Oct 23, 2006 11:21 PM > /In a few weeks time, you will no longer be able to use the Amazon > S3 SOAP interface's PutObjectInline or GetObjectInline for objects > that are larger than 1 megabyte in size. After November 21, > affected requests will fail with the new error response > InlineDataTooLargeError. To put or get objects that are larger than > 1 megabyte in size, you will need to either use DIME attachments > with SOAP requests or use our REST interface. We apologize for any > inconvenience this change may cause you. > > Please be assured that deprecating existing functionality is not a > change we take lightly. We are making this change because > transferring large objects inline in the SOAP message (as happens > with PutObjectInline and GetObjectInline) has significant negative > performance implications; it is a mechanism only suited to > transferring small amounts of data. The SOAP-based alternative, > using DIME attachments, now has wide support in SOAP toolkits, is > more efficient and does not suffer from the same performance > bottlenecks. It also allows us to optimize our service to give you > better performance./ ok - how amusing - I guess we can say "told you so" - they are still leaving the method there for small transfers however... > >> .... but it does give the client something very simple that it >> can implement .... > > What is so difficult in a client implementing this : > > > > Where the URI points to a resource that says something like this : > > ivo://net.ivoa.vospace/transfer-methods/http-get > This is a VOSpace transfer method that uses the standard http- > get transport protocol. > Details of the transport protocol are available here [http:// > www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3]. > > Usage: > The client calls PullFromVOSpace specifying this transfer- > method in the request. > If the request is valid, then the server will respond with > the standard PullFromVOSpace, > response, and add a element containing the > endpoint URL to fetch the data from. > > The client uses the URL to download the data using a standard > http-get request. > The transfer method completes automatically when the client > has received the data, > and no notification callbacks are required. The real point here (and part of my motivation for suggesting the in- line data transfer), is that the bare VOSpace specification does not mandate any minimum data transport mechanism that a space has to implement, so there is no guarantee that two fully compliant 1.0 VOSpaces can actually exchange data, which I think is a shame. Paul Harrison ESO Garching www.eso.org From owner-vospace@eso.org Tue Nov 28 16:48:25 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kASFmAxX010316 for ; Tue, 28 Nov 2006 16:48:10 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kASFmAkg010315 for vospace-outgoing; Tue, 28 Nov 2006 16:48:10 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kASFm9XA010311; Tue, 28 Nov 2006 16:48:09 +0100 (MET) Received: from ppsw-2.csi.cam.ac.uk (ppsw-2.csi.cam.ac.uk [131.111.8.132]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kASFm8pM026892; Tue, 28 Nov 2006 16:48:08 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:40821) by ppsw-2.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.132]:25) with esmtp id 1Gp5BZ-0007QO-7y (Exim 4.63) (return-path ); Tue, 28 Nov 2006 15:47:53 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kASFlkG8024140; Tue, 28 Nov 2006 15:47:47 GMT Message-ID: <456C5A1D.5070903@ast.cam.ac.uk> Date: Tue, 28 Nov 2006 15:47:41 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: IVOA VoSpace mailing list Subject: Re: Changes to VOSpace specification References: <456520A5.1010902@cacr.caltech.edu> <4567371D.3000800@ast.cam.ac.uk> <456A750D.1090903@ast.cam.ac.uk> <14BADE13-6F57-4A19-AD1C-B879F5665FAA@eso.org> <456AFB8E.2060606@ast.cam.ac.uk> <456BC965.7020804@ast.cam.ac.uk> <00D12ED4-069E-474C-ACBD-915A997F147C@eso.org> In-Reply-To: <00D12ED4-069E-474C-ACBD-915A997F147C@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.11.28.73432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: >> We are designing a SOAP webservice - so why add yet another syntax >> for calling methods. >> If we didn't already have a SOAP service, then you might have a case. > > because a major thing that people want to be able to do is use a URL > to identify a dataset when publishing a paper for instance - if views > are allowed that alter the presentation of data, then it is not > really very pretty to have to write a chunk of xml that represents > the call to VOSpace to be able to make the statement - "get this > dataset with this particular view" as a reference in a paper. > However, it is not a showstopper for 1.0 - but something to consider > for the future. If we can find a good compromise between the > advantages of SOAP with some REST-like semantics in the vos: URI, it > would be appreciated by the users. Ok - I take your point. Would this work (once we have links in VOSpace version-1.1) : A right-click menu option in the UI that lets you create a 'citation link' to the target object. The link properties contain The [vos://..] URI of the target object. The URIs of the current view and format. Plus any additional properties required to retrieve the data (e.g. search criteria applied to a 'virtual container'). In effect, the CitationLink holds a snapshot of the information that was used to select a particular view of the target object. The view can then be referred to using just the [vos://...] URI of the CitationLink. The links would be created in the users own space - even if the target object was in another space. So the user could create a separate directory in their home space containing all of the citation links for each of their papers. The CitationLink behaves like a normal link so the default action is to redirect the client to the target object, using the view, format and params stored in the link properties. This would be similar to the way that this works : [http://tinyurl.com/y6f8fr] which underneath is actually doing this : [http://preview.tinyurl.com/y6f8fr] For a citation in a paper, you could create two 'citation links' or 'citation views', one that gives you the raw votable view, and another that gives you a PDF or HTML view for publication. Hmmm, interesting ... this could have useful applications beyond citations. If we make it a generic behavior that links can store not only the target URI, but other information like view, format etc. then this could be useful in creating workflows etc. Thanks, Dave From owner-vospace@eso.org Wed Dec 20 14:09:02 2006 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kBKD8oNg008015 for ; Wed, 20 Dec 2006 14:08:50 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id kBKD8nko008014 for vospace-outgoing; Wed, 20 Dec 2006 14:08:49 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id kBKD8mTg008009; Wed, 20 Dec 2006 14:08:49 +0100 (MET) Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id kBKD8kpM015935; Wed, 20 Dec 2006 14:08:47 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:60798) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp id 1Gx0q4-0000cs-AT (Exim 4.63) (return-path ); Wed, 20 Dec 2006 12:46:29 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id kBKCkJe3009653; Wed, 20 Dec 2006 12:46:19 GMT Message-ID: <45893096.8090701@ast.cam.ac.uk> Date: Wed, 20 Dec 2006 12:46:14 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: Matthew Graham , Guy Rixon , IVOA VoSpace mailing list Subject: Re: VOSpace property registration References: <45877729.1080908@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.20.45432 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Hiya, Thanks for the links. Can we setup a discussion page on the wiki for these ? I'd like to request a [displayName] element which contains a short name that would give UI developers something to display in a menu item. How closely do we want to link the VOSpace specification to these. We could just say "the property URI should point to a property description, as defined by the VOStandard schema" and leave it at that. Or, we could put explicit examples in the VOSpace specification as to how these would be used. Adding examples would make things much clearer in the VOSpace specification, but it might delay things if the VOStandard schema isn't stable yet. Dave Paul Harrison wrote: > Hi, > > Ray liked the idea so much that we agreed to move this into the > VOStandard schema - The latest draft that I am working on is at > http://www.eso.org/~pharriso/ivoa/VOStandard.html and copies of the > latest schema are under http://www.eso.org/~pharriso/ivoa/schema/ - > In particular there is a version of the definitions in http:// > www.eso.org/~pharriso/ivoa/schema/vospace-1.0rc4.xml (which is > different from that uploaded to the VOSpace wiki) that uses the > latest schema definitions - essentially unchanged apart from movement > of some elements to the VOStandard namespace. > > note of course that all of these schema are under my personal web > space, so that they are not officially published in any fashion - I > will make an effort to upload them to the ivoa site after Christmas. > > > Paul Harrison > ESO Garching > www.eso.org > > On 19.12.2006, at 06:22, Dave Morris wrote: > >> I'm looking at updating the details in the VOSpace specification for >> the properties, protocols and formats. >> Can someone send me a URL for the latest schema for the property, >> protocol and format registration(s). >> >> Many thanks, >> Dave >> From owner-vospace@eso.org Tue Jan 9 15:07:24 2007 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l09E5WDk022204 for ; Tue, 9 Jan 2007 15:05:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l09E5WCs022203 for vospace-outgoing; Tue, 9 Jan 2007 15:05:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l09E5UAd022189; Tue, 9 Jan 2007 15:05:31 +0100 (MET) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l09E5RVR005441; Tue, 9 Jan 2007 15:05:27 +0100 (CET) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:36909) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1H4Ha0-0006fn-Fq (Exim 4.63) (return-path ); Tue, 09 Jan 2007 14:03:56 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.7+Sun/8.13.7) with ESMTP id l09E3iec029410; Tue, 9 Jan 2007 14:03:45 GMT Message-ID: <45A3A0BB.8020902@ast.cam.ac.uk> Date: Tue, 09 Jan 2007 14:03:39 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list CC: Guy Rixon , Paul Harrison , Matthew Graham Subject: Corrections to the VOSpace specification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.9.55433 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris I'm working on some corrections to the current specification document. http://wiki.astrogrid.org/bin/view/Astrogrid/VOSpace20070104 This is a work in progress, and I'll add more over the next few days. It is based on version 022-0713 of the document from the IVOA wiki. Shout if I'm using the wrong version of the specification. This is not intended to change the specification itself, just to bring the document up to speed with what we have agreed so far, and to improve the descriptions and explanations. Please shout if I have missed anything or got things wrong. At the moment, this is just a wiki page showing the proposed changes, as a way of getting things moving. No changes to the document until everyone gives the ok. Thanks, Dave From owner-vospace@eso.org Mon Apr 30 16:23:20 2007 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l3UENB6c009892 for ; Mon, 30 Apr 2007 16:23:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l3UENB4X009891 for vospace-outgoing; Mon, 30 Apr 2007 16:23:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l3UENAX2009887; Mon, 30 Apr 2007 16:23:10 +0200 (MEST) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l3UEN8vM007808; Mon, 30 Apr 2007 16:23:08 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:52485) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1HiWlk-0008G6-DJ (Exim 4.63) (return-path ); Mon, 30 Apr 2007 15:22:25 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id l3UEMK3Z001875; Mon, 30 Apr 2007 15:22:20 +0100 (BST) Message-ID: <4635FB9B.8000401@ast.cam.ac.uk> Date: Mon, 30 Apr 2007 15:22:19 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list , Paul Harrison , Matthew Graham CC: Guy Rixon Subject: VOSpace-1.0 schema Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.4.26.164934 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Hiya, I'm trying to bring the IVOA VOSpace wiki pages up to date. The VOSpace home page http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceHome has links to the v1.0rc6 schema. http://www.ivoa.net/internal/IVOA/VOSpace10schema/VOSpaceContract-v1.0rc6.wsdl and http://www.ivoa.net/internal/IVOA/VOSpace10schema/VOSpaceTypes-v1.0rc6.xsd This was the schema used for the v1.0 working draft, submitted in March http://www.ivoa.net/Documents/cover/VOSpace-20070304.html Now that the v1.0 specification has been submitted I'd like to re-publish the rc6 schema as the final version for v1.0. No changes to the schema itself, but it would mean changing the namespaces : from xmlns:vos.contract.1.0="http://www.net.ivoa/xml/VOSpaceContract-v1.0rc6" xmlns:vos.types.1.0="http://www.net.ivoa/xml/VOSpaceTypes-v1.0rc6" to xmlns:vos.contract.1.0="http://www.net.ivoa/xml/VOSpaceContract-v1.0" xmlns:vos.types.1.0="http://www.net.ivoa/xml/VOSpaceTypes-v1.0" and the identifiers for the SOAP actions would change : from to ... etc This will mean that we will have to update the namespaces and SOAP actions of any existing services. Let me know if this will cause any problems. Thanks, Dave From owner-vospace@eso.org Mon Apr 30 17:03:57 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l3UF3mD1018273 for ; Mon, 30 Apr 2007 17:03:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l3UF3mdF018272 for vospace-outgoing; Mon, 30 Apr 2007 17:03:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l3UF3l8A018268; Mon, 30 Apr 2007 17:03:47 +0200 (MEST) Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l3UF3jvM013277; Mon, 30 Apr 2007 17:03:46 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:55603) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1HiXOy-0006kJ-Fq (Exim 4.63) (return-path ); Mon, 30 Apr 2007 16:02:57 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id l3UF2pj9014859; Mon, 30 Apr 2007 16:02:52 +0100 (BST) Message-ID: <4636051B.7000700@ast.cam.ac.uk> Date: Mon, 30 Apr 2007 16:02:51 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Harrison CC: Matthew Graham , Guy Rixon , IVOA VoSpace mailing list Subject: Re: VOSpace 1.x session at Beijing References: <4635F182.3090203@ast.cam.ac.uk> <21BA92D7-E2D5-4CA3-80B1-8AC50BE1DE6A@eso.org> In-Reply-To: <21BA92D7-E2D5-4CA3-80B1-8AC50BE1DE6A@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.4.26.164934 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Paul Harrison wrote: > In the schedule http://www.ivoa.net/twiki/bin/view/IVOA/ > InterOpMay2007 there is a VOSpace 1.x slot on the Monday, and there > is a VOSpace 2.x slot (with other GWS issues, so it would be a very > small slot I would guess) mentioned on the Tuesday. Is this split > intentional? I am not sure if I know the roadmap well enough to make > the distinction anyway. Yes. First session - VOSpace-1.x We still have a commitment to complete VOSpace-1.0, and provide VOSpace-1.1 with containers and links. So the first session is for completing and reporting on VOSpace-1.0, and discussing what changes are needed to implement VOSpace-1.1. We need to get these done asap, as people want to start using VOSpace now. Unless we make extraordinary progress in the second session, and everything moves to REST based services within the next six months, we will still need to deliver a VOSpace-1.1 SOAP service . Second session - VOSpace-2.x This is the working title for discussion on moving VOSpace to a REST and/or WebDav service. It was combined with the second GWS discussion because there would be a lot of overlap with the more general discussion of using REST for the other GWS services. > However, If I were to make a split between what I would want to say > it would be > > 1. ESO lessons learned from implementing VOSpace 1.0 with NGAS backend. > 2. What WebDAV can teach VOSpace 1+ Yep, these look fine. If you think there won't be enough time in the second session to cover what you have found with WebDav, we could add it to the end of the first session (need to check with Guy first). Although the VOSpace-1.x services will still be SOAP services, given that it looks like we will go for some form of REST service for 2.x it would make sense to include suggestions for making VOSpace-1.1 more REST friendly. Things like deprecating the paging in ListNodes, and changing the transfer operations to return an object representing the state of the transfer. Ideally, it would be good to come up with a gradual migration from SOAP to REST, where we could have the same back-end business logic providing both SOAP and REST services. Whether this is a realistic goal is what the VOSpace-2.0 discussion would be about. Thanks, Dave > > > Paul Harrison > ESO Garching > www.eso.org > > On 30.04.2007, at 15:39, Dave Morris wrote: > >> Hiya, >> >> The current plan is to have a 15min presentation from each of us, >> describing what we found from implementing 1.0 and changes we would >> like to make for 1.1, and then leave the rest of the time for >> discussion. >> >> If this is ok, can I have working titles for your presentations so >> that we can put together an agenda for Guy. >> >> Thanks, >> Dave >> >> Guy Rixon wrote: >> >>> Hi, >>> >>> can I leave you to organize the materials for the VOSpace 1.x >>> session. I don't mind chairing, but you are better placed to set >>> the agenda. If you forward agenda materias to me I will publicize >>> them. >>> >>> Cheers, >>> Guy >> >> >> From owner-vospace@eso.org Fri Jul 20 13:19:37 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6KBJSNZ001697 for ; Fri, 20 Jul 2007 13:19:28 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l6KBJS6l001696 for vospace-outgoing; Fri, 20 Jul 2007 13:19:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6KBJRAG001689; Fri, 20 Jul 2007 13:19:27 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l6KBJPKb019908; Fri, 20 Jul 2007 13:19:26 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:41294) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1IBqVl-0005hP-2W (Exim 4.63) (return-path ); Fri, 20 Jul 2007 12:19:05 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id l6KBIwsH013933; Fri, 20 Jul 2007 12:18:58 +0100 (BST) Message-ID: <46A09A1D.6000707@ast.cam.ac.uk> Date: Fri, 20 Jul 2007 12:18:53 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA VoSpace mailing list CC: Paul Harrison , Matthew Graham , Guy Rixon Subject: Re: Listing question References: <469FB715.8080702@cacr.caltech.edu> <2332F138-FD27-4F32-BEA7-BA8A4A52F572@eso.org> In-Reply-To: <2332F138-FD27-4F32-BEA7-BA8A4A52F572@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.20.40334 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='LEO_OBFU_SUBJ_RE 0.1, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris I agree with Paul, including the type would give a GUI client some clue as to what icon to show. Being pedantic about the wording for the specification, is it 'must' or 'should'. If it is 'should', then it means A server 'should' include the types, if it can, but a very simple server implementation 'may' leave them out. A client 'must' be able to handle a list with types, but it 'must' also be able to handle a response without them. If it is 'must', then it means A server 'must' always include the types. A client 'must' be able to handle a list with types. Personally, I'd prefer 'should' (avoid explicit limits in the spec. if we don't need them), but I'm happy to go with the consensus. Dave Paul Harrison wrote: > I think that it should attempt to return the full type if possible, > as even for minimum listing, as certainly for vospace 1.+ this > enables the client to make some sort of decision as to whether they > want to query further... > > Paul Harrison > ESO Garching > www.eso.org > > On 19.07.2007, at 21:10, Matthew Graham wrote: > >> Hi, >> >> Should a min or props listing return the xsi:type of the node: e.g. >> >> >> >> or at this level of detail is OK just to return a higher node type: >> >> >> >> ? >> >> Cheers, >> >> Matthew > From owner-vospace@eso.org Sat Jul 21 00:47:33 2007 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6KMlLAH026009 for ; Sat, 21 Jul 2007 00:47:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l6KMlLQQ026008 for vospace-outgoing; Sat, 21 Jul 2007 00:47:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6KMlLtK026004; Sat, 21 Jul 2007 00:47:21 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l6KMlIKb011759; Sat, 21 Jul 2007 00:47:19 +0200 (CEST) Received: from [192.168.10.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id l6KMl8YW012393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 20 Jul 2007 15:47:08 -0700 Message-ID: <46A13B65.4060402@cacr.caltech.edu> Date: Fri, 20 Jul 2007 15:47:01 -0700 From: Matthew Graham User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Dave Morris , Guy Rixon , Paul Harrison , IVOA VoSpace mailing list Subject: Optional elements with listing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.20.150842 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, Just some fine tuning here: detail and nodes are both minOccurs = 0, maxOccurs = 1 in the WSDL but the implication of the spec is that they are required elements. Which is correct? Cheers, Matthew From owner-vospace@eso.org Tue Jul 24 09:35:01 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6O7Y8b6022809 for ; Tue, 24 Jul 2007 09:34:08 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l6O7Y8JG022807 for vospace-outgoing; Tue, 24 Jul 2007 09:34:08 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from clyde.hq.eso.org (clyde.hq.eso.org [134.171.45.17]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6O7Y056022771; Tue, 24 Jul 2007 09:34:01 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by clyde.hq.eso.org (8.12.8/8.12.8) with ESMTP id l6O7X3HS005804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jul 2007 09:33:03 +0200 In-Reply-To: <46A13B65.4060402@cacr.caltech.edu> References: <46A13B65.4060402@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B399601-1D51-4D42-ABFB-537A6FF1995A@eso.org> Cc: Dave Morris , Guy Rixon , IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Optional elements with listing Date: Tue, 24 Jul 2007 09:34:03 +0200 To: Matthew Graham X-Mailer: Apple Mail (2.752.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison Hi, my preference would be to have the element as required and the element as optional (in both the specification and WSDL!) Cheers, Paul. Paul Harrison ESO Garching www.eso.org On 21.07.2007, at 00:47, Matthew Graham wrote: > Hi, > > Just some fine tuning here: detail and nodes are both minOccurs = > 0, maxOccurs = 1 in the WSDL but the implication of the spec is > that they are required elements. Which is correct? > > Cheers, > > Matthew From owner-vospace@eso.org Tue Jul 24 09:44:57 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6O7inhw024607 for ; Tue, 24 Jul 2007 09:44:49 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l6O7ings024606 for vospace-outgoing; Tue, 24 Jul 2007 09:44:49 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6O7inKS024602; Tue, 24 Jul 2007 09:44:49 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.13.8+Sun/8.12.10) with ESMTP id l6O7ilwK019845; Tue, 24 Jul 2007 09:44:48 +0200 (CEST) Received: from [172.16.1.34] (adsl-75-50-155-46.dsl.lsan03.sbcglobal.net [75.50.155.46]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id l6O7ibug014646 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 24 Jul 2007 00:44:37 -0700 Message-ID: <46A5ADE0.2050300@cacr.caltech.edu> Date: Tue, 24 Jul 2007 00:44:32 -0700 From: Matthew Graham User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Paul Harrison CC: Dave Morris , Guy Rixon , IVOA VoSpace mailing list Subject: Re: Optional elements with listing References: <46A13B65.4060402@cacr.caltech.edu> <8B399601-1D51-4D42-ABFB-537A6FF1995A@eso.org> In-Reply-To: <8B399601-1D51-4D42-ABFB-537A6FF1995A@eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.24.2133 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, Except that it makes no sense to include a element when you are also including a continuation token, whereas you could envisage that the first listing you request is detail=max and then subsequent ones might just detail=min. Also if the detail element is missing then what is the default setting: min or max? Given that we are now in RFC, I believe that we can raise this as a comment with a response that lays down what the rules are. Cheers, Matthew Paul Harrison wrote: > Hi, > > my preference would be to have the element as required and the > element as optional (in both the specification and WSDL!) > > Cheers, > Paul. > > Paul Harrison > ESO Garching > www.eso.org > > On 21.07.2007, at 00:47, Matthew Graham wrote: > >> Hi, >> >> Just some fine tuning here: detail and nodes are both minOccurs = 0, >> maxOccurs = 1 in the WSDL but the implication of the spec is that >> they are required elements. Which is correct? >> >> Cheers, >> >> Matthew > From owner-vospace@eso.org Tue Jul 24 11:05:11 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6O951cj007787 for ; Tue, 24 Jul 2007 11:05:01 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l6O9518L007785 for vospace-outgoing; Tue, 24 Jul 2007 11:05:01 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from forth.hq.eso.org (forth.hq.eso.org [134.171.45.18]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6O94sTl007755; Tue, 24 Jul 2007 11:04:54 +0200 (MEST) Received: from [134.171.10.74] (ma011930.hq.eso.org [134.171.10.74]) (authenticated bits=0) by forth.hq.eso.org (8.12.8/8.12.8) with ESMTP id l6O93ths006713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jul 2007 11:03:55 +0200 In-Reply-To: <46A5ADE0.2050300@cacr.caltech.edu> References: <46A13B65.4060402@cacr.caltech.edu> <8B399601-1D51-4D42-ABFB-537A6FF1995A@eso.org> <46A5ADE0.2050300@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <128CC308-E443-4ACE-928B-86EF8846C909@eso.org> Cc: Dave Morris , Guy Rixon , IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Optional elements with listing Date: Tue, 24 Jul 2007 11:04:57 +0200 To: Matthew Graham X-Mailer: Apple Mail (2.752.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison On 24.07.2007, at 09:44, Matthew Graham wrote: > Hi, > > Except that it makes no sense to include a element when you > are also including a continuation token, whereas you could envisage > that the first listing you request is detail=max and then > subsequent ones might just detail=min. Also if the detail element > is missing then what is the default setting: min or max? True, which is how it probably got to this state - the intention being that the first call both node and detail must be included but for continuation calls only the token is really needed - this could of course be made more explicit within the WSDL with a "xsd choice" construct. I have also forgotten why a list of element is used as the argument here rather than simply a list of element...it seems that there is no important information that could be present other than the URIs of the desired nodes. > > Given that we are now in RFC, I believe that we can raise this as a > comment with a response that lays down what the rules are. > > Cheers, > > Matthew > > > Paul Harrison wrote: >> Hi, >> >> my preference would be to have the element as required and >> the element as optional (in both the specification and >> WSDL!) >> >> Cheers, >> Paul. >> >> Paul Harrison >> ESO Garching >> www.eso.org >> >> On 21.07.2007, at 00:47, Matthew Graham wrote: >> >>> Hi, >>> >>> Just some fine tuning here: detail and nodes are both minOccurs = >>> 0, maxOccurs = 1 in the WSDL but the implication of the spec is >>> that they are required elements. Which is correct? >>> >>> Cheers, >>> >>> Matthew >> > From owner-vospace@eso.org Thu Jul 26 00:33:13 2007 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6PMWpS4016540 for ; Thu, 26 Jul 2007 00:32:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l6PMWpTQ016539 for vospace-outgoing; Thu, 26 Jul 2007 00:32:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l6PMWpCf016534 for ; Thu, 26 Jul 2007 00:32:51 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.13.8+Sun/8.12.10) with ESMTP id l6PMWnuF018512 for ; Thu, 26 Jul 2007 00:32:50 +0200 (CEST) Received: from [192.168.10.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id l6PMWh0A000933 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 25 Jul 2007 15:32:43 -0700 Message-ID: <46A7CF7D.8050909@cacr.caltech.edu> Date: Wed, 25 Jul 2007 15:32:29 -0700 From: Matthew Graham User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: VOSpace 1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.25.150934 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, With VOSpace 1.0 in its RFC phase now, the time has come to start thinking seriously about VOSpace 1.1. VOSpace 1.1 aims to extend the VOSpace 1.0 specification to include links and containers. The proposed mechanism is that we introduce two new node types: * LinkNode^? - this is like a Node but also has a URI to where the link is pointing * ContainerNode^? - this cannot hold any data (no bytes) but can have children nodes (of any type) and views for container level formatting (aggregate zip/gzip). At the May 2007 interop, we identified the following items as requiring resolution for VOSpace 1.1: * Container level metadata - how to distinguish those that relate to the contents of the container through inheritance and those to the container itself * Generated names - vos://null does not work for containers so use ".auto" or "/" as an alternative * Typing of protocol and view parameters - these are currently designated as "string" but normal parameters are "URI" * ACL - although this forms part of a wider SSO context, should VOSpace have some notions of ACL control * Find - a equivalent to the Unix command is desired I have posted this also to the VOSpace 1.1 discussion page (http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace11Spec). I would like these to be resolved by the end of the IVOA in September so that we can produce a Working Draft specification in early October. If you have any thoughts on the above then please post them to this mailing list and the discussion page. Cheers, Matthew From owner-vospace@eso.org Mon Aug 13 20:33:23 2007 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7DIWSvS013755 for ; Mon, 13 Aug 2007 20:32:28 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7DIWSnr013754 for vospace-outgoing; Mon, 13 Aug 2007 20:32:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7DIWSZa013750 for ; Mon, 13 Aug 2007 20:32:28 +0200 (MEST) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l7DIWOMo027796 for ; Mon, 13 Aug 2007 20:32:26 +0200 (CEST) Received: from [192.168.10.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id l7DIWIRb006061 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 13 Aug 2007 11:32:19 -0700 Message-ID: <46C0A3A8.9090106@cacr.caltech.edu> Date: Mon, 13 Aug 2007 11:32:08 -0700 From: Matthew Graham User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: IVOA VoSpace mailing list Subject: Logical storage units in VOSpace 1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.311128, Antispam-Data: 2007.8.13.111023 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, A request has from our friends at SDSC to include references to the actual storage units that data is being deposited on. The use case is data replication so, for example, I want to move/copy a data object from a slow tape archive to an ultrafast disk but both hardware units are within the same VOSpace or I want to retrieve a data object from the ultrafast disk copy and not the slow tape one. I think that we can incorporate this easily into our existing data model. We will refer to hardware units as logical storage units with the implication that they are identified via a logical identifier (URI) that is set by the particular VOSpace implementation. To get the list of available storage units from a VOSpace, we will need a method: getLogicalStorageUnits() which will return a list of URIs. These URIs may be resolvable to a description of the storage unit. The logical storage unit identifier will be an optional argument in the entity so that as part of the data transfer negotiation, the user can specify a list of storage units that they want the data transferred to/from. The identifier will also be an optional argument in the entity so that specific hardware can be targetted in moving and copying data. Comments, suggestions, etc. Cheers, Matthew From owner-vospace@eso.org Wed Aug 15 14:59:39 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7FCxIrL006557 for ; Wed, 15 Aug 2007 14:59:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7FCxIv7006556 for vospace-outgoing; Wed, 15 Aug 2007 14:59:18 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7FCxHSB006552 for ; Wed, 15 Aug 2007 14:59:17 +0200 (MEST) Received: from clarity.mcc.ac.uk (clarity.mcc.ac.uk [130.88.200.144]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l7FCxDWf027260 for ; Wed, 15 Aug 2007 14:59:13 +0200 (CEST) Received: from star1.jb.man.ac.uk ([130.88.24.176]) by clarity.mcc.ac.uk with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ILISp-0007ia-Lx; Wed, 15 Aug 2007 13:59:07 +0100 Received: from [130.88.24.12] (helo=[127.0.0.1]) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1ILISp-0003dQ-00; Wed, 15 Aug 2007 13:59:07 +0100 In-Reply-To: <46C0A3A8.9090106@cacr.caltech.edu> References: <46C0A3A8.9090106@cacr.caltech.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12384E37-FE91-4221-BCF7-5C49D78FB0F4@manchester.ac.uk> Cc: IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Paul Harrison Subject: Re: Logical storage units in VOSpace 1.1 Date: Wed, 15 Aug 2007 14:06:23 +0100 To: Matthew Graham X-Mailer: Apple Mail (2.752.3) X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details. X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.311128, Antispam-Data: 2007.8.15.52923 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison Hi, I think that data replication is an important functionality of VOSpace, but I think that introducing the concept of logical storage units in this fashion into the "public" api might not be very easy to use in practice without knowledge of the underlying storage system, and additionally is contrary to one of the aims of the VOSpace design of trying to hide as much as possible about the internals from the outside world. The use case that you describe could also be handled in a more easy-to-reason-about way by having "move to fast storage" and "move to slow storage" functions in the api, or having similar hints in the various get api calls .Perhaps a compromise using a similar api to the one you suggest, is that the "hardware units" are generic classes of unit rather than each vospace defining its own set of proprietary hardware units. VOSpaces that want to, simply map the generic classes onto specific internal hardware units transparently. The VOSpace then hides all the details of exactly where items are stored. Paul Harrison On 13.08.2007, at 19:32, Matthew Graham wrote: > Hi, > > A request has from our friends at SDSC to include references to the > actual storage units that data is being deposited on. The use case > is data replication so, for example, I want to move/copy a data > object from a slow tape archive to an ultrafast disk but both > hardware units are within the same VOSpace or I want to retrieve a > data object from the ultrafast disk copy and not the slow tape one. > > I think that we can incorporate this easily into our existing data > model. We will refer to hardware units as logical storage units > with the implication that they are identified via a logical > identifier (URI) that is set by the particular VOSpace > implementation. To get the list of available storage units from a > VOSpace, we will need a method: getLogicalStorageUnits() which will > return a list of URIs. These URIs may be resolvable to a > description of the storage unit. > > The logical storage unit identifier will be an optional argument in > the entity so that as part of the data transfer > negotiation, the user can specify a list of storage units that they > want the data transferred to/from. The identifier will also be an > optional argument in the entity so that specific hardware > can be targetted in moving and copying data. > > Comments, suggestions, etc. > > Cheers, > > Matthew From owner-vospace@eso.org Wed Aug 15 18:21:39 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7FGLKZ6007039 for ; Wed, 15 Aug 2007 18:21:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7FGLKxH007038 for vospace-outgoing; Wed, 15 Aug 2007 18:21:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7FGLJwc007034 for ; Wed, 15 Aug 2007 18:21:19 +0200 (MEST) Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l7FGLHWf009732 for ; Wed, 15 Aug 2007 18:21:18 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:54689) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1ILLb2-0003RH-1U (Exim 4.63) (return-path ); Wed, 15 Aug 2007 17:19:48 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id l7FGJhXA025760; Wed, 15 Aug 2007 17:19:44 +0100 (BST) Message-ID: <46C3279A.8020802@ast.cam.ac.uk> Date: Wed, 15 Aug 2007 17:19:38 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Graham CC: IVOA VoSpace mailing list Subject: Re: Logical storage units in VOSpace 1.1 References: <46C0A3A8.9090106@cacr.caltech.edu> In-Reply-To: <46C0A3A8.9090106@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.311128, Antispam-Data: 2007.8.15.90024 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_MEDIA_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Matthew Graham wrote: > A request has from our friends at SDSC to include references to the > actual storage units that data is being deposited on. The use case is > data replication so, for example, I want to move/copy a data object > from a slow tape archive to an ultrafast disk but both hardware units > are within the same VOSpace or I want to retrieve a data object from > the ultrafast disk copy and not the slow tape one. Yep, would be nice to have this. We talked about this with the SDSC developers in February, but I haven't figured out an easy way to integrate this into vospace yet. > I think that we can incorporate this easily into our existing data > model. We will refer to hardware units as logical storage units with > the implication that they are identified via a logical identifier > (URI) that is set by the particular VOSpace implementation. Ok so far. > To get the list of available storage units from a VOSpace, we will > need a method: getLogicalStorageUnits() which will return a list of URIs. Problem : this works if everything is treated as a 'BLOB'. As soon as we distinguish between types of structured data, e.g. 'tabular data' or 'image', then the global method no longer works. If I have three 'logical storage units', two implemented as disk files, and one as a relational database, then the system behaves differently depending on which 'storage unit' the data is stored in. You could transfer tabular data from the 'database store' to one of the 'disk store'(s), but it would be stored as a file on the disk, and you will probably loose the ability to treat it as structured data (would this change the node type from StructuredData to UnstructuredData ?). If you have two copies of the data, one in a database store and one in a file store, and used an ADQL interface to modify the structured data in the database, do all the changes get replicated to the copy stored as a file ? How do we express rules like "you can replicate a FITS tabular file in a database store, but you can't replicate a FITS image file a database store". To do this sort of thing, we would need a list of 'allowed stores' for each node, and some may be mutually exclusive. So although you could transfer the tabular data from database store to file store, you can't have it in both at the same time (one is structured queryable data the other isn't - if it was in both, would it be represented as a Structured or Unstructured data node ?). We have a similar problem with the global listViews and listProtocols methods at the moment, not all nodes may be able to support all the views and protocols, but the global methods don't tell you which ones are valid for which nodes. > These URIs may be resolvable to a description of the storage unit. Yep, ok with that. > The logical storage unit identifier will be an optional argument in > the entity so that as part of the data transfer > negotiation, the user can specify a list of storage units that they > want the data transferred to/from. This implies replicated storage, which is what SRB is very good at. However, this does add a lot of complications. Do we guarantee that data replication is handled transparently, or do we mark some of the stored data as out of date ? If the data for a node is stored in two 'storage units'[a] and [b], user 'A' sends new data to 'storage unit'[a] and user B reads their data from 'storage unit'[b], what data does user B get back ? Do the same permissions apply to all the copies of the data ? If user 'root' can read/write from all the stores, but user 'fred' can't write to the tape store, then what happens if 'root' creates a replicated copy of a node on the tape store. Can 'fred' still modify the data on disk (making the tape version out of date), or does it become read only because he can't modify the tape copy ? > The identifier will also be an optional argument in the entity > so that specific hardware can be targetted in moving and copying data. If the data for one node may be replicated on more than one store, it would have to be a list of elements in each , > Comments, suggestions, etc. Yes, data replication and logical stores would be nice. However, to do it right would mean a lot of work, and add a lot of complexity. The SRB and IRODS system have already solved these problems, so do we really want to re-invent this particular wheel ? What is the science use case for this ? And can the use case be handled by using the existing SRB or IRODS systems ? When our astronomers saw a demo of IRODS, their comments were "I'd like the system to have this capability, but I wouldn't need to use it as part of my normal work". "It would be very useful if our sys admin had these kind of tools ... so they could manage the data for us" ".. but as a scientist I wouldn't want to handle things at this level" If we add a list of [capability] elements alongside the [accepts] and [provides] elements in a [node], then a replicated data store based on IRODS could include [uri for IRODS interface + endpoint] as a capability. [node] [properties] .... [/properties] [accepts] .... [/accepts] [provides] .... [/provides] [capabilities] [capability uri="ivo://capability.uri.for.irods"] [endpoint].....[/endpoint] [/capability] [/capabilities] [/node] Effectively, the vospace service would be saying 'replication settings for the data in this node can be manipulated with the IRODS API using this endpoint'. We get access to all of the very nice tools that SDSC are developing, without having to define a whole new API for handling replication. Note : I haven't studied the IRODS in detail, but I am impressed with what I have seen. Note : This does not mean that IRODS is the only replication API. If we really, really, want to, we could still define an IVOA standard replication API, and add that as a capability. .... [capabilities] [capability uri="ivo://capability.uri.for.ivoa.replication"] [endpoint].....[/endpoint] [/capability] [/capabilities]However, w .... Data replication would be nice, but do we need to define it in vospace. Or can we pass it over to an established API that has been designed to handle this sort of thing. Dave From owner-vospace@eso.org Wed Aug 15 21:08:53 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7FJ8c63002658 for ; Wed, 15 Aug 2007 21:08:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7FJ8cGX002657 for vospace-outgoing; Wed, 15 Aug 2007 21:08:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7FJ8beJ002653 for ; Wed, 15 Aug 2007 21:08:37 +0200 (MEST) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by apollo.hq.eso.org (8.13.8+Sun/8.12.10) with ESMTP id l7FJ8ZLM010982 for ; Wed, 15 Aug 2007 21:08:36 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/73) id l7FJ8Na09633; Wed, 15 Aug 2007 12:08:23 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <46C3279A.8020802@ast.cam.ac.uk> References: <46C0A3A8.9090106@cacr.caltech.edu> <46C3279A.8020802@ast.cam.ac.uk> Date: Wed, 15 Aug 2007 11:50:15 -0700 To: Dave Morris From: Reagan Moore Subject: Re: Logical storage units in VOSpace 1.1 Cc: Matthew Graham , IVOA VoSpace mailing list Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.311128, Antispam-Data: 2007.8.15.114623 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_MEDIA_2_BODY 0, __CP_MEDIA_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Reagan Moore Dave: Actually we use logical storage names in iRODS/SRB to simplify interactions with remote storage systems. Users interact with: - logical file names - logical storage names The system selects which replica of the file to access, based on whether there is a copy at the same IP address, whether there is a copy on any disk resource in the world, or whether there is a copy on tape. When a user writes a file, the logical storage name can be used to represent: - compound resource. This is typically a disk cache in front of a tape. The system stages all interactions with the tape through the disk cache transparently to the user. Any disk can be paired with any tape system. Thus you can have a local cache for a tape system at a remote site. - cluster resource. This is typically a collection of storage systems, each managed by a separate node in a cluster. Load leveling is done with the data grid automatically distributing the files across each node file system. - automated replication. The system makes a copy on each of the associated storage system represented by the logical storage name. - fault tolerant replication. The system makes a copy on n of m storage systems, allowing for the possibility that some might be off line. From the perspective of the user, they only interact with logical file names and logical storage names. A sophisticated user can query the system, identify the associated physical storage systems, and direct specific replicas to specific storage locations. This is the exception. The concern about integrating both storage systems and databases into the same logical name space is handled by differentiating between BLOBs and tables. The SRB provides the same set of operations on BLOBs as on files. Thus a Binary Large Object can be read, written, modified through the same file manipulation commands used to read, write, modify files. For interactions with a database table, the user issues a different set of commands, such as an SQL query command with the results packaged as an XML file that is sent to the client. Operations that depend upon the data type of a file are implemented through separate APIs. An example is manipulation of HDFv5 files. We use the HDFv5 client APIs to control the requested operations, but execute the HDFv5 library calls at the remote storage system to perform the desired manipulations. If a user extracts data from a database table into an XML file using an SQL query command, a SRB client that understands how to parse XML files is needed to do further manipulation. The iRODS system removes this restriction by supporting micro-services that process explicit data format types. A rule can be written that checks the data type, and then automatically invokes the correct parsing operations for manipulating the file. It is possible to create a rule that checks the type of storage system, and then based upon the file type issues different micro-services to parse and manipulate a file. The VOSpace interface can remain independent of the logical name spaces used by SRB/iRODS. However, interactions with data in the data grid would be based on the logical names for both files and storage. The physical file names (including replicas) and actual storage locations would be hidden from the users by default data grid functions. The default functions would implement a standard algorithm for selecting the best file (closest replica) and for writing to the best storage resource. Reagan >Matthew Graham wrote: > >>A request has from our friends at SDSC to include references to the >>actual storage units that data is being deposited on. The use case >>is data replication so, for example, I want to move/copy a data >>object from a slow tape archive to an ultrafast disk but both >>hardware units are within the same VOSpace or I want to retrieve a >>data object from the ultrafast disk copy and not the slow tape one. > >Yep, would be nice to have this. >We talked about this with the SDSC developers in February, but I >haven't figured out an easy way to integrate this into vospace yet. > >>I think that we can incorporate this easily into our existing data >>model. We will refer to hardware units as logical storage units >>with the implication that they are identified via a logical >>identifier (URI) that is set by the particular VOSpace >>implementation. > >Ok so far. > >>To get the list of available storage units from a VOSpace, we will >>need a method: getLogicalStorageUnits() which will return a list of >>URIs. > >Problem : this works if everything is treated as a 'BLOB'. >As soon as we distinguish between types of structured data, e.g. >'tabular data' or 'image', then the global method no longer works. > >If I have three 'logical storage units', two implemented as disk >files, and one as a relational database, then the system behaves >differently depending on which 'storage unit' the data is stored in. > >You could transfer tabular data from the 'database store' to one of >the 'disk store'(s), but it would be stored as a file on the disk, >and you will probably loose the ability to treat it as structured >data (would this change the node type from StructuredData to >UnstructuredData ?). > >If you have two copies of the data, one in a database store and one >in a file store, and used an ADQL interface to modify the structured >data in the database, do all the changes get replicated to the copy >stored as a file ? > >How do we express rules like "you can replicate a FITS tabular file >in a database store, but you can't replicate a FITS image file a >database store". > >To do this sort of thing, we would need a list of 'allowed stores' >for each node, and some may be mutually exclusive. >So although you could transfer the tabular data from database store >to file store, you can't have it in both at the same time (one is >structured queryable data the other isn't - if it was in both, >would it be represented as a Structured or Unstructured data node ?). > >We have a similar problem with the global listViews and >listProtocols methods at the moment, not all nodes may be able to >support all the views and protocols, but the global methods don't >tell you which ones are valid for which nodes. > >>These URIs may be resolvable to a description of the storage unit. > >Yep, ok with that. > >>The logical storage unit identifier will be an optional argument in >>the entity so that as part of the data transfer >>negotiation, the user can specify a list of storage units that they >>want the data transferred to/from. > >This implies replicated storage, which is what SRB is very good at. >However, this does add a lot of complications. > >Do we guarantee that data replication is handled transparently, or >do we mark some of the stored data as out of date ? >If the data for a node is stored in two 'storage units'[a] and [b], >user 'A' sends new data to 'storage unit'[a] and user B reads their >data from 'storage unit'[b], what data does user B get back ? > >Do the same permissions apply to all the copies of the data ? >If user 'root' can read/write from all the stores, but user 'fred' >can't write to the tape store, then what happens if 'root' creates a >replicated copy of a node on the tape store. Can 'fred' still modify >the data on disk (making the tape version out of date), or does it >become read only because he can't modify the tape copy ? > >>The identifier will also be an optional argument in the >>entity so that specific hardware can be targetted in moving and >>copying data. > >If the data for one node may be replicated on more than one store, >it would have to be a list of elements in each , >>Comments, suggestions, etc. > >Yes, data replication and logical stores would be nice. >However, to do it right would mean a lot of work, and add a lot of complexity. >The SRB and IRODS system have already solved these problems, so do >we really want to re-invent this particular wheel ? > >What is the science use case for this ? >And can the use case be handled by using the existing SRB or IRODS systems ? > >When our astronomers saw a demo of IRODS, their comments were > "I'd like the system to have this capability, but I wouldn't need >to use it as part of my normal work". > "It would be very useful if our sys admin had these kind of tools >... so they could manage the data for us" > ".. but as a scientist I wouldn't want to handle things at this level" > >If we add a list of [capability] elements alongside the [accepts] >and [provides] elements in a [node], then a replicated data store >based on IRODS could include [uri for IRODS interface + endpoint] as >a capability. > > [node] > [properties] > .... > [/properties] > [accepts] > .... > [/accepts] > [provides] > .... > [/provides] > [capabilities] > [capability uri="ivo://capability.uri.for.irods"] > [endpoint].....[/endpoint] > [/capability] > [/capabilities] > [/node] > >Effectively, the vospace service would be saying 'replication >settings for the data in this node can be manipulated with the IRODS >API using this endpoint'. We get access to all of the very nice >tools that SDSC are developing, without having to define a whole new >API for handling replication. > >Note : I haven't studied the IRODS in detail, but I am impressed >with what I have seen. > >Note : This does not mean that IRODS is the only replication API. If >we really, really, want to, we could still define an IVOA standard >replication API, and add that as a capability. > > .... > [capabilities] > [capability uri="ivo://capability.uri.for.ivoa.replication"] > [endpoint].....[/endpoint] > [/capability] > [/capabilities]However, w > .... > >Data replication would be nice, but do we need to define it in vospace. >Or can we pass it over to an established API that has been designed >to handle this sort of thing. > >Dave From owner-vospace@eso.org Mon Aug 20 08:57:15 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7K6uAuR002766 for ; Mon, 20 Aug 2007 08:56:10 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7K6uAhI002765 for vospace-outgoing; Mon, 20 Aug 2007 08:56:10 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7K6u58b002760 for ; Mon, 20 Aug 2007 08:56:06 +0200 (MEST) Received: from relay.sdsc.edu (relay.sdsc.edu [132.249.20.66]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l7K6twWf024994 for ; Mon, 20 Aug 2007 08:55:59 +0200 (CEST) Received: from [192.168.0.103] (cpe-76-88-62-157.san.res.rr.com [76.88.62.157]) (authenticated bits=0) by relay.sdsc.edu (8.14.1/8.14.1/SDSCrelay/10) with ESMTP id l7K6tlRw008354 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 19 Aug 2007 23:55:47 -0700 (PDT) In-Reply-To: <12384E37-FE91-4221-BCF7-5C49D78FB0F4@manchester.ac.uk> References: <46C0A3A8.9090106@cacr.caltech.edu> <12384E37-FE91-4221-BCF7-5C49D78FB0F4@manchester.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Matthew Graham , IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Arun Jagatheesan Subject: Re: Logical storage units in VOSpace 1.1 Date: Sun, 19 Aug 2007 23:55:51 -0700 To: Paul Harrison X-Mailer: Apple Mail (2.752.3) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.311128, Antispam-Data: 2007.8.19.233526 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Arun Jagatheesan Hi Sorry for the tardiness in replying to this thread... Having logical storage namespace as part of the VOSpace is a requirement to go along with the VoSpace design objective - to hide as much as possible about the internals from the outside wold - without making the internals as a blackbox that is not useful in real world situations. Without this, the model of VoSpace would not reflect the real world and the protocol would not be useful to take advantage big data centers. We are not interested in exposing the hardware or hardware details to users (seems like the example might have led to some confusion). We want to model the real world as it is -but make it logical and allow late binding. We are just trying to associate space (as in storage space) with a logical identifier. VOSpace 1.0 already has logical data namespace (nodes). The VOSpace concept allows late binding for the major entities involved in a data transfer between spaces: - Data Name defined as Logical Name and represented as Node - Data transfer defines the protocols and the data type "transfer" is the data type that we use. - Data storage is just defined as space in v1.0 - NO modeling has been done to reflect this in the architecture. The dataname and protocol undergo late binding (i.e) the physical name of the file and the data transfer protocol are not binded untill the client and server decide to commit the transaction (transfer). But, the storage space is left opaque. The VOSpace in a large data center could have multiple servers - assume there are multiple FTP or iROD/SRB servers. As per v1.0, the protocol allows getProtocols () to define either FTP or iRODS protocol to be used. If FTP was used, the client would not know which physical storage space to use. This might seem like an advantage on the surface, as the VOSpace server could decide any FTP server that is available. However, it restricts the client from taking advantage of late binding. While the client had the luxury to do a late-binding on data-transfer protocol, it does not have the freedom to ask for the "prefered-storage-type" or "prefered-storage-resource" or "less-expensive-storage". When the vo-space control protocol wanted to give the luxury to the client to pick and negotiate the data transfer protocol, shouldn't it give the follow-up luxury or smartness to the client to decide on the "class of storage" to be used? The client could have a getResources () call. Rather than providing the physical end-points, this call would return the identifiers for the logical storage units. Each data node, apart from providing its logical name, would also have the identifiers of the logical storage units where the data is physically located. Thus, this allows us to model replicas, replication, data migration etc., as part of the data model it self. We dont use the physical identifier or end-point of the storage (like an IP address or 132.0.0.1) - instead we provide logical identifiers for these storage units such as "sdsc-tape", "manchester-disk", "sdsc- gpfs". These are mostly human readable names that could also help a end-user - it could have additional attributes (optional resource properties) to help the applications to decide on a storage unit to use. Cheers, Arun On Aug 15, 2007, at 6:06 AM, Paul Harrison wrote: > Hi, > > I think that data replication is an important functionality of > VOSpace, but I think that introducing the concept of logical > storage units in this fashion into the "public" api might not be > very easy to use in practice without knowledge of the underlying > storage system, and additionally is contrary to one of the aims of > the VOSpace design of trying to hide as much as possible about the > internals from the outside world. > The use case that you describe could also be handled in a more easy- > to-reason-about way by having "move to fast storage" and "move to > slow storage" functions in the api, or having similar hints in the > various get api calls .Perhaps a compromise using a similar api to > the one you suggest, is that the "hardware units" are generic > classes of unit rather than each vospace defining its own set of > proprietary hardware units. VOSpaces that want to, simply map the > generic classes onto specific internal hardware units > transparently. The VOSpace then hides all the details of exactly > where items are stored. > > Paul Harrison > > On 13.08.2007, at 19:32, Matthew Graham wrote: > >> Hi, >> >> A request has from our friends at SDSC to include references to >> the actual storage units that data is being deposited on. The use >> case is data replication so, for example, I want to move/copy a >> data object from a slow tape archive to an ultrafast disk but both >> hardware units are within the same VOSpace or I want to retrieve a >> data object from the ultrafast disk copy and not the slow tape one. >> >> I think that we can incorporate this easily into our existing data >> model. We will refer to hardware units as logical storage units >> with the implication that they are identified via a logical >> identifier (URI) that is set by the particular VOSpace >> implementation. To get the list of available storage units from a >> VOSpace, we will need a method: getLogicalStorageUnits() which >> will return a list of URIs. These URIs may be resolvable to a >> description of the storage unit. >> >> The logical storage unit identifier will be an optional argument >> in the entity so that as part of the data transfer >> negotiation, the user can specify a list of storage units that >> they want the data transferred to/from. The identifier will also >> be an optional argument in the entity so that specific >> hardware can be targetted in moving and copying data. >> >> Comments, suggestions, etc. >> >> Cheers, >> >> Matthew From owner-vospace@eso.org Mon Aug 20 09:50:45 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7K7oYkH013305 for ; Mon, 20 Aug 2007 09:50:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7K7oY2h013303 for vospace-outgoing; Mon, 20 Aug 2007 09:50:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7K7oXFW013297 for ; Mon, 20 Aug 2007 09:50:33 +0200 (MEST) Received: from relay.sdsc.edu (relay.sdsc.edu [132.249.20.66]) by apollo.hq.eso.org (8.13.8+Sun/8.12.10) with ESMTP id l7K7oVI9009769 for ; Mon, 20 Aug 2007 09:50:32 +0200 (CEST) Received: from [192.168.0.103] (cpe-76-88-62-157.san.res.rr.com [76.88.62.157]) (authenticated bits=0) by relay.sdsc.edu (8.14.1/8.14.1/SDSCrelay/10) with ESMTP id l7K7oGHY008532 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 20 Aug 2007 00:50:17 -0700 (PDT) In-Reply-To: <46C3279A.8020802@ast.cam.ac.uk> References: <46C0A3A8.9090106@cacr.caltech.edu> <46C3279A.8020802@ast.cam.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Matthew Graham , IVOA VoSpace mailing list Content-Transfer-Encoding: 7bit From: Arun Jagatheesan Subject: Re: Logical storage units in VOSpace 1.1 Date: Mon, 20 Aug 2007 00:50:21 -0700 To: Dave Morris X-Mailer: Apple Mail (2.752.3) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.311128, Antispam-Data: 2007.8.20.2641 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='IP_HTTP_ADDR_WITH_PORT 0, __CP_MEDIA_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Arun Jagatheesan > Embedded are my replies to this discussion... >> To get the list of available storage units from a VOSpace, we will >> need a method: getLogicalStorageUnits() which will return a list >> of URIs. > > Problem : this works if everything is treated as a 'BLOB'. > As soon as we distinguish between types of structured data, e.g. > 'tabular data' or 'image', then the global method no longer works. > > If I have three 'logical storage units', two implemented as disk > files, and one as a relational database, then the system behaves > differently depending on which 'storage unit' the data is stored in. > > You could transfer tabular data from the 'database store' to one > of the 'disk store'(s), but it would be stored as a file on the > disk, and you will probably loose the ability to treat it as > structured data (would this change the node type from > StructuredData to UnstructuredData ?). > > If you have two copies of the data, one in a database store and one > in a file store, and used an ADQL interface to modify the > structured data in the database, do all the changes get replicated > to the copy stored as a file ? > > How do we express rules like "you can replicate a FITS tabular file > in a database store, but you can't replicate a FITS image file a > database store". > > To do this sort of thing, we would need a list of 'allowed stores' > for each node, and some may be mutually exclusive. > So although you could transfer the tabular data from database store > to file store, you can't have it in both at the same time (one is > structured queryable data the other isn't - if it was in both, > would it be represented as a Structured or Unstructured data node ?). > We have a similar problem with the global listViews and > listProtocols methods at the moment, not all nodes may be able to > support all the views and protocols, but the global methods don't > tell you which ones are valid for which nodes. Just like each VOSpace defines its list of accepted protocols, each storage unit would have its list of known protocol and known data types that would supported. If a VOSpace has only FTP or HTTP store (and assuming it does not want to have a database to store or support ADQL interface), it just throws an exception "not supported" when a put or replicate operation is attempted with structured data. > >> These URIs may be resolvable to a description of the storage unit. > > Yep, ok with that. > >> The logical storage unit identifier will be an optional argument >> in the entity so that as part of the data transfer >> negotiation, the user can specify a list of storage units that >> they want the data transferred to/from. > > This implies replicated storage, which is what SRB is very good at. > However, this does add a lot of complications. > > Do we guarantee that data replication is handled transparently, or > do we mark some of the stored data as out of date ? > If the data for a node is stored in two 'storage units'[a] and > [b], user 'A' sends new data to 'storage unit'[a] and user B reads > their data from 'storage unit'[b], what data does user B get back ? You are refering to the classical problem of dirty read. Its left to the designer - whether they want a very flexible system that embraces every thing (analogy is HTML code) or a strict system ensures replica consitency (again analogy would be languages that are very strict). An intermediate approach that allows policies at the vo-space level would be a better approach. [a] and [b] could be replicas following a policy X. Where X could again be a logical identifier that could mean any thing from no-guarantee-of-replication to 1-second-latency- replication or real-time. An example: Node [/file/a/b/c] where c could be replicated at two places. The data node C will have the logical storage identifiers where physically the data is present. As part of the node it could have a resource description for "replicaiton policy" where each VOSpace could define very simple policies. > > Do the same permissions apply to all the copies of the data ? > If user 'root' can read/write from all the stores, but user 'fred' > can't write to the tape store, then what happens if 'root' creates > a replicated copy of a node on the tape store. Can 'fred' still > modify the data on disk (making the tape version out of date), or > does it become read only because he can't modify the tape copy ? Good question. I am providing my opinion of the expected behavior. I dont know if V1.1 has access controls. But if it were - there could be access controls on both data and storage units. Usually, the access control over the storage units will over ride the access controls over the data namespace. So even if fred is allowed to access /a/b/c based on data namespace - he might not access it if the data is on a resource where is not allowed even read. Continuing with the approach - Let us assume /a/b/c has two replicas on disk and tape. When Fred tries to update C on disk where he has access - the system checks for access controls and approves Fred's write. IF the replication is carried out by root later (as per the "policy"), it should go through and the physical copy on tape would be updated. On the other hand, Fred can not himself replicate data to tape as he does not have access to "write" on tape. > >> The identifier will also be an optional argument in the >> entity so that specific hardware can be targetted in moving and >> copying data. > > If the data for one node may be replicated on more than one store, > it would have to be a list of elements in each , >> Comments, suggestions, etc. > > Yes, data replication and logical stores would be nice. > However, to do it right would mean a lot of work, and add a lot of > complexity. > The SRB and IRODS system have already solved these problems, so do > we really want to re-invent this particular wheel ? > Hmm.. that is the question i had asked from day one of VOSpace. Why not just use iRODS as the protocol, it can be standardized, its open software and open protocol too. Well, it does not have the late- binding for transfer protocol though. But, we are trying to add some thing similar with support from TCP/IP and non-TCP protocols. To have a large community working on a common product would provide faster results and standards. > What is the science use case for this ? > And can the use case be handled by using the existing SRB or IRODS > systems ? Well, going with the philosophy to support the small and big (with out taking away functionalities)..... Logical storage unit is nothing but a name that identfies a mapping from logical name to storage end point. This can be done just like we do for data name to node-name mapping. However concepts like replication and ensuring replication, might be too much for smaller systems. We could bring this inside by allowing any type of storage policy that is guranteed by the VOspace (which could be no-guarantee too as mentioned before). > > When our astronomers saw a demo of IRODS, their comments were > "I'd like the system to have this capability, but I wouldn't > need to use it as part of my normal work". > "It would be very useful if our sys admin had these kind of > tools ... so they could manage the data for us" > ".. but as a scientist I wouldn't want to handle things at this > level" It just has to be made simple. Yet the bells and whistles provided only when needed (without much difficult for any one to understand and use). Every one is aware that files are not on a single disk and they are distributed. Its easy to understand this file is in "sdsc- tape" and let me replicate it to "my-lab-disk" using "replicate- daily".(the system finds out the protocols and does the transfers every day). Rather than let me find the data in ftp://ftp.sdsc.edu: 8090/a/b/c and copy it every day (replicate) to ftp:// 132.232.33.80:24/a/b/c. > > If we add a list of [capability] elements alongside the [accepts] > and [provides] elements in a [node], then a replicated data store > based on IRODS could include [uri for IRODS interface + endpoint] > as a capability. > > [node] > [properties] > .... > [/properties] > [accepts] > .... > [/accepts] > [provides] > .... > [/provides] > [capabilities] > [capability uri="ivo://capability.uri.for.irods"] > [endpoint].....[/endpoint] > [/capability] > [/capabilities] > [/node] > I forgot the some of these. I think each node must have: - logical name of the data - formats it provies (forgot the VOSpace lingo here) - logical storage unit(s) - assuming its a data node. It *MIGHT* also individually have information such as date it was created, last user or owner - if more than one storage unit has the data - what replication policy is used - Any user defined microServices that can be invoked on this node (provides behaviour to the node) Note that replication policy here could be done by any tool or manually also. So, iRODS is not the only API to do replication. > Effectively, the vospace service would be saying 'replication > settings for the data in this node can be manipulated with the > IRODS API using this endpoint'. We get access to all of the very > nice tools that SDSC are developing, without having to define a > whole new API for handling replication. > > Note : I haven't studied the IRODS in detail, but I am impressed > with what I have seen. Thanks. There is lot more that could be done as wider community rather than every one building and discovering the individual wheels. > > Note : This does not mean that IRODS is the only replication API. > If we really, really, want to, we could still define an IVOA > standard replication API, and add that as a capability. > .... > [capabilities] > [capability uri="ivo:// > capability.uri.for.ivoa.replication"] > [endpoint].....[/endpoint] > [/capability] > [/capabilities]However, w > .... > > Data replication would be nice, but do we need to define it in > vospace. > Or can we pass it over to an established API that has been designed > to handle this sort of thing. > > Dave From owner-vospace@eso.org Thu Aug 23 11:24:45 2007 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7N9OUdJ002841 for ; Thu, 23 Aug 2007 11:24:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7N9OU9U002840 for vospace-outgoing; Thu, 23 Aug 2007 11:24:30 +0200 (MEST) Message-Id: <200708230924.l7N9OU9U002840@mercury.hq.eso.org> X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Date: Wed, 22 Aug 2007 12:12:29 +0200 From: Olivier Ricou To: vospace@ivoa.net Subject: MTOM and Python Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Olivier Ricou Dear all, I seen in the archives that you suggest to use MTOM for attachments. Since I use Axis2 that is fine, however I would like to make a client in Python but I cannot find any toolkit including MTOM for Python. Does it mean I have to wait that someone makes it or is there another solution ? Olivier. From owner-vospace@eso.org Thu Aug 23 14:55:13 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7NCsuwO005850 for ; Thu, 23 Aug 2007 14:54:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7NCsur3005849 for vospace-outgoing; Thu, 23 Aug 2007 14:54:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7NCsuhF005845 for ; Thu, 23 Aug 2007 14:54:56 +0200 (MEST) Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l7NCsq0P014968 for ; Thu, 23 Aug 2007 14:54:52 +0200 (CEST) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:64107) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp id 1IOCCx-0006Bd-J3 (Exim 4.67) (return-path ); Thu, 23 Aug 2007 13:54:43 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id l7NCsfOK010858; Thu, 23 Aug 2007 13:54:41 +0100 (BST) Message-ID: <46CD838C.7020502@ast.cam.ac.uk> Date: Thu, 23 Aug 2007 13:54:36 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Ricou CC: vospace@ivoa.net Subject: Re: MTOM and Python References: <200708230924.l7N9OU9U002840@mercury.hq.eso.org> In-Reply-To: <200708230924.l7N9OU9U002840@mercury.hq.eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.311128, Antispam-Data: 2007.8.23.53228 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Unfortunately, yes. This is one of the reasons why we made the specification protocol-agnostic, and allowed support for multiple protocols. DIME was the early standard for transferring data as SOAP attachments, which has now been replaced by MTOM. However, at the moment there are only a few language libraries that support MTOM. With an Axis2 service, you could support both, use DIME in the client for now, and then replace the client with an MTOM one when the Python libraries become available. The service could 'offer' both options, and the client picks whichever it can understand. Hope this helps, Dave Olivier Ricou wrote: >Dear all, > > I seen in the archives that you suggest to use MTOM for attachments. >Since I use Axis2 that is fine, however I would like to make a >client in Python but I cannot find any toolkit including MTOM for >Python. Does it mean I have to wait that someone makes it or is >there another solution ? > >Olivier. > > From owner-vospace@eso.org Fri Aug 24 02:58:59 2007 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7O0wmJM024222 for ; Fri, 24 Aug 2007 02:58:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l7O0wm3K024221 for vospace-outgoing; Fri, 24 Aug 2007 02:58:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l7O0wlRw024212 for ; Fri, 24 Aug 2007 02:58:47 +0200 (MEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.42.46]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l7O0wVVS007110 for ; Fri, 24 Aug 2007 02:58:32 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAH7JzUaD15EJaGdsb2JhbACODwsEBgcHGQ X-IronPort-AV: E=Sophos;i="4.19,302,1183327200"; d="scan'208";a="33456" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by flux.hq.eso.org with ESMTP; 24 Aug 2007 02:57:20 +0200 Received: from [192.168.10.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id l7O0vKfx002647 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 23 Aug 2007 17:57:20 -0700 Message-ID: <46CE2CE4.4030801@cacr.caltech.edu> Date: Thu, 23 Aug 2007 17:57:08 -0700 From: Matthew Graham User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dave Morris CC: Olivier Ricou , vospace@ivoa.net Subject: Re: MTOM and Python References: <200708230924.l7N9OU9U002840@mercury.hq.eso.org> <46CD838C.7020502@ast.cam.ac.uk> In-Reply-To: <46CD838C.7020502@ast.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi Olivier, An alternative might be to use Axis2/C which I believe supports MTOM and put a Python wrapper around it. Otherwise the only real support for MTOM is currently in Java and C#. Cheers, Matthew Dave Morris wrote: > Unfortunately, yes. > This is one of the reasons why we made the specification > protocol-agnostic, and allowed support for multiple protocols. > > DIME was the early standard for transferring data as SOAP attachments, > which has now been replaced by MTOM. > However, at the moment there are only a few language libraries that > support MTOM. > > With an Axis2 service, you could support both, use DIME in the client > for now, and then replace the client with an MTOM one when the Python > libraries become available. The service could 'offer' both options, > and the client picks whichever it can understand. > > Hope this helps, > Dave > > > Olivier Ricou wrote: > >> Dear all, >> >> I seen in the archives that you suggest to use MTOM for attachments. >> Since I use Axis2 that is fine, however I would like to make a >> client in Python but I cannot find any toolkit including MTOM for >> Python. Does it mean I have to wait that someone makes it or is >> there another solution ? >> >> Olivier. >> >> > From owner-vospace@eso.org Mon Oct 1 18:35:02 2007 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 21A7E6240DB; Mon, 1 Oct 2007 18:35:02 +0200 (CEST) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l91GYu23001409 for ; Mon, 1 Oct 2007 18:34:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id l91GYuJd001408 for vospace-outgoing; Mon, 1 Oct 2007 18:34:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id l91GYu5L001398 for ; Mon, 1 Oct 2007 18:34:56 +0200 (MEST) Received: from clarity.mcc.ac.uk (clarity.mcc.ac.uk [130.88.200.144]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id l91GYs6G004515 for ; Mon, 1 Oct 2007 18:34:55 +0200 (CEST) Received: from star1.jb.man.ac.uk ([130.88.24.176]) by clarity.mcc.ac.uk with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IcO4w-000Pht-HV for vospace@ivoa.net; Mon, 01 Oct 2007 17:25:06 +0100 Received: from [130.88.24.12] (helo=[127.0.0.1]) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1IcO4w-00075E-00 for vospace@ivoa.net; Mon, 01 Oct 2007 17:25:06 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <81B4ECF7-247E-4CCE-B845-E70E14E519AC@manchester.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IVOA mailing list VoSpace From: Paul Harrison Subject: VOSpace Usage Note 0.1 Date: Mon, 1 Oct 2007 17:25:07 +0100 X-Mailer: Apple Mail (2.752.3) X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details. X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.10.1.91143 X-Perl-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_400_499 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Paul Harrison Hi, After the Interop meeting and as a response to the RFC for the VOSpace 1.0 Standard, I have written a first draft of a note that describes how to implement and register a VOSpace instance on the http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceHome page. The actual document itself is at http://www.ivoa.net/internal/IVOA/VOSpaceHome/ VOSpace-Usage.odt Cheers, Paul. Dr. Paul Harrison JBCA, Manchester University http://www.manchester.ac.uk/jodrellbank From owner-vospace@eso.org Tue Jan 8 00:05:49 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id E0CF962422C; Tue, 8 Jan 2008 00:05:48 +0100 (CET) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m07N5Zvv007750 for ; Tue, 8 Jan 2008 00:05:35 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id m07N5ZLH007749 for vospace-outgoing; Tue, 8 Jan 2008 00:05:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.42.40]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m07N5YAe007740; Tue, 8 Jan 2008 00:05:34 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by aeon.hq.eso.org (Postfix) with ESMTP id 91FF91E5145; Tue, 8 Jan 2008 00:06:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aeon.hq.eso.org Received: from aeon.hq.eso.org ([127.0.0.1]) by localhost (aeon.hq.eso.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umMZ6ECyB1+c; Tue, 8 Jan 2008 00:06:07 +0100 (CET) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by aeon.hq.eso.org (Postfix) with ESMTP id 682FC1E418D; Tue, 8 Jan 2008 00:06:06 +0100 (CET) Received: from [172.18.72.111] (vpn-250-44.caltech.edu [131.215.250.44]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m07N5Yrl021215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 7 Jan 2008 15:05:35 -0800 Message-Id: <308CB491-6D85-49E2-A6CD-B84AAFAE6F5B@cacr.caltech.edu> From: Matthew Graham To: Grid_Ivoa_List , IVOA VoSpace mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: VOSpace 1.1 specification Date: Mon, 7 Jan 2008 15:51:33 -0600 X-Mailer: Apple Mail (2.915) X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.1.7.144951 Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, Apologies if you get this email twice but I've posted the first draft of the VOSpace 1.1 specification on the IVOA Twiki at: http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace11Specification . Cheers, Matthew From owner-grid@eso.org Tue Jan 8 00:06:07 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 6726C62422C; Tue, 8 Jan 2008 00:06:07 +0100 (CET) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m07N5ZPu007745 for ; Tue, 8 Jan 2008 00:05:35 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id m07N5ZRh007744 for grid-outgoing; Tue, 8 Jan 2008 00:05:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.42.40]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m07N5YAe007740; Tue, 8 Jan 2008 00:05:34 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by aeon.hq.eso.org (Postfix) with ESMTP id 91FF91E5145; Tue, 8 Jan 2008 00:06:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aeon.hq.eso.org Received: from aeon.hq.eso.org ([127.0.0.1]) by localhost (aeon.hq.eso.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umMZ6ECyB1+c; Tue, 8 Jan 2008 00:06:07 +0100 (CET) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by aeon.hq.eso.org (Postfix) with ESMTP id 682FC1E418D; Tue, 8 Jan 2008 00:06:06 +0100 (CET) Received: from [172.18.72.111] (vpn-250-44.caltech.edu [131.215.250.44]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m07N5Yrl021215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 7 Jan 2008 15:05:35 -0800 Message-Id: <308CB491-6D85-49E2-A6CD-B84AAFAE6F5B@cacr.caltech.edu> From: Matthew Graham To: Grid_Ivoa_List , IVOA VoSpace mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: VOSpace 1.1 specification Date: Mon, 7 Jan 2008 15:51:33 -0600 X-Mailer: Apple Mail (2.915) X-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.1.7.144951 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, Apologies if you get this email twice but I've posted the first draft of the VOSpace 1.1 specification on the IVOA Twiki at: http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace11Specification . Cheers, Matthew From owner-vospace@eso.org Sat Mar 15 01:32:05 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 84C9A624286; Sat, 15 Mar 2008 01:32:05 +0100 (CET) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m2F0Vtjh002364 for ; Sat, 15 Mar 2008 01:31:55 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id m2F0Vt5p002363 for vospace-outgoing; Sat, 15 Mar 2008 01:31:55 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.42.40]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m2F0VsXN002354; Sat, 15 Mar 2008 01:31:55 +0100 (MET) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by aeon.hq.eso.org (Postfix) with ESMTP id 336D91E401C; Sat, 15 Mar 2008 01:33:17 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioGABq22keD15EJYmdsb2JhbACQeBUEBhAZmCc X-IronPort-AV: E=Sophos;i="4.25,504,1199660400"; d="scan'208";a="4960269" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 15 Mar 2008 01:31:23 +0100 Received: from [192.168.10.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m2F0VwoM027124 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Mar 2008 17:31:58 -0700 Message-Id: <409D7362-75E0-4B5D-9E3B-D2DB6E1E6E58@cacr.caltech.edu> From: Matthew Graham To: IVOA VoSpace mailing list , Grid_Ivoa_List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: VOSpace 1.1 Working Draft Date: Fri, 14 Mar 2008 17:31:46 -0700 X-Mailer: Apple Mail (2.919.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, The Working Draft for VOSpace 1.1 is now available at: http://www.ivoa.net/Documents/cover/VOSpace-20080311.html You can find the WSDL, message schema and discussion page for the discussion points in the WD on the VOSpaceHome wiki page (http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceHome ). Cheers, Matthew From owner-grid@eso.org Sat Mar 15 01:33:39 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 3DCAD624286; Sat, 15 Mar 2008 01:33:39 +0100 (CET) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m2F0VtN8002359 for ; Sat, 15 Mar 2008 01:31:55 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id m2F0Vt8Y002358 for grid-outgoing; Sat, 15 Mar 2008 01:31:55 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.42.40]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m2F0VsXN002354; Sat, 15 Mar 2008 01:31:55 +0100 (MET) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by aeon.hq.eso.org (Postfix) with ESMTP id 336D91E401C; Sat, 15 Mar 2008 01:33:17 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioGABq22keD15EJYmdsb2JhbACQeBUEBhAZmCc X-IronPort-AV: E=Sophos;i="4.25,504,1199660400"; d="scan'208";a="4960269" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 15 Mar 2008 01:31:23 +0100 Received: from [192.168.10.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m2F0VwoM027124 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Mar 2008 17:31:58 -0700 Message-Id: <409D7362-75E0-4B5D-9E3B-D2DB6E1E6E58@cacr.caltech.edu> From: Matthew Graham To: IVOA VoSpace mailing list , Grid_Ivoa_List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: VOSpace 1.1 Working Draft Date: Fri, 14 Mar 2008 17:31:46 -0700 X-Mailer: Apple Mail (2.919.2) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, The Working Draft for VOSpace 1.1 is now available at: http://www.ivoa.net/Documents/cover/VOSpace-20080311.html You can find the WSDL, message schema and discussion page for the discussion points in the WD on the VOSpaceHome wiki page (http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceHome ). Cheers, Matthew From owner-vospace@eso.org Thu Mar 20 03:24:21 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id C4080624287; Thu, 20 Mar 2008 03:24:21 +0100 (CET) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m2K2O6ii022619 for ; Thu, 20 Mar 2008 03:24:06 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id m2K2O6LY022618 for vospace-outgoing; Thu, 20 Mar 2008 03:24:06 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.42.40]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m2K2O5U0022614 for ; Thu, 20 Mar 2008 03:24:05 +0100 (MET) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by aeon.hq.eso.org (Postfix) with ESMTP id 360551E401C for ; Thu, 20 Mar 2008 03:25:31 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.25,527,1199660400"; d="scan'208";a="5137653" Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by clavius.hq.eso.org with ESMTP; 20 Mar 2008 03:23:18 +0100 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:56583) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1JcARm-00087s-UU (Exim 4.67) (return-path ); Thu, 20 Mar 2008 02:24:02 +0000 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id m2K2No7v014153; Thu, 20 Mar 2008 02:23:50 GMT Message-ID: <47E1CAB0.2070308@ast.cam.ac.uk> Date: Thu, 20 Mar 2008 02:23:44 +0000 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Graham CC: IVOA VoSpace mailing list Subject: Re: VOSpace 1.1 Working Draft References: <409D7362-75E0-4B5D-9E3B-D2DB6E1E6E58@cacr.caltech.edu> In-Reply-To: <409D7362-75E0-4B5D-9E3B-D2DB6E1E6E58@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris Draft looks good. Some initial thoughts : Discussion point in section 2.1 Should ContainerNode include a list of capabilities. Yes - If I remember correctly, the capabilities element was added to provide support for external services like SRB and iRODS. In which case it is perfectly acceptable to publish an iRODS capability on a ContainerNode. Section 2.1.2 (inheritable properties) What is the use case for inherited properties ? Discussion point in section 2.1.2 If an inheritable property is also declared on a child, which value takes priority ? My guess would be that the child setting should take precedence for that child and any nodes below it. Otherwise, setting the property on the root node would fix that property for all nodes in the tree. Discussion point in section 3.1.3 Should we use the getProperties response to denote properties as inheritable ? No - If we are going to have inheritable properties, then the flag to denote a particular property as inheritable has to be external to any one individual service (global property registration ?) and all services must treat the property in the same way. Otherwise we would end up with some properties that were inheritable in one service and not inheritable in another. Section 3.2.4 (findNodes) I know that we always planned to add this to vospace-1.1. However, I would like to propose that we make this an optional part of the specification. The only reason I suggest this is that up to this point, it would be theoretically possible to create a simple implementation of the node and data access methods of a vospace-1.1 service using a scripting language like PHP, without requiring a database behind it. Adding the findNodes search would make it more difficult to implement without resorting to using a full scale database server behind it. Now that we are moving to the new registry schema, with multiple capabilities for a service, it would be easy enough to declare this as additional capability. * A standard vospace-1.1 service (without findNodes) would only declare a vospace-1.1-core capability. * A service that also implemented findNodes could declare both the vospace-1.1-core capability and a vospace-1.1-find capability. The two capabilities could still be implemented within the same WebService, in which case the two capability elements would contain the same endpoint address. Making it optional would also prevent disagreements about the query syntax from stalling the acceptance of vospace-1.1-core. Discussion point in section 3.2.4.1 Should we allow wild cards in the property URIs ? No, probably not at this stage - simplest solution first, add complications if we need them. The proposed schema for MatchType defines the uri attribute as 'xsd:anyURI'. If we allowed wild cards in the property URIs I suspect it would make this a lot more complicated. Hope this helps, Dave Matthew Graham wrote: > Hi, > > The Working Draft for VOSpace 1.1 is now available at: > > http://www.ivoa.net/Documents/cover/VOSpace-20080311.html > > You can find the WSDL, message schema and discussion page for the > discussion points in the WD on the VOSpaceHome wiki page > (http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceHome ). > > Cheers, > > Matthew From owner-vospace@eso.org Tue Apr 22 03:02:21 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 556FC6242AC; Tue, 22 Apr 2008 03:01:52 +0200 (CEST) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m3M11fNJ017612 for ; Tue, 22 Apr 2008 03:01:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id m3M11fmN017611 for vospace-outgoing; Tue, 22 Apr 2008 03:01:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.42.40]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m3M11eYv017607 for ; Tue, 22 Apr 2008 03:01:40 +0200 (MEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by aeon.hq.eso.org (Postfix) with ESMTP id E7D0C1E4022 for ; Tue, 22 Apr 2008 03:03:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcCAG/VDEiD15EJiGdsb2JhbACRUwEBAQ8mmQY X-IronPort-AV: E=Sophos;i="4.25,691,1199660400"; d="scan'208";a="6557232" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 22 Apr 2008 02:59:07 +0200 Received: from [192.168.10.100] (sidhe.cacr.caltech.edu [131.215.145.158]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m3M11fCY011628 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 21 Apr 2008 18:01:42 -0700 Message-Id: From: Matthew Graham To: IVOA VoSpace mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: VOSpace 1.1 reference implementation Date: Mon, 21 Apr 2008 18:01:27 -0700 Cc: Bernhard Bauer X-Mailer: Apple Mail (2.919.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, I've deployed a test reference implementation of VOSpace 1.1 at: http://testnvo.cacr.caltech.edu:8080/vospace-1.1/VOSpaceServiceImpl Everything in the spec is implemented including packing and unpacking of tar/tar.gz archives to/from ContainerNodes if you specify the correct view. Theoretically it also supports inheritable properites but this is as yet untested (as is the find function). I've tested all the main functionalities on a version on my laptop and they all work as expected - this version, however, is deployed in a slightly different way so there might be certain library issues. So play with it and let me know of any problems that you encounter. It's presently unsecured so SOAP + WS-Security is not required. Cheers, Matthew From owner-vospace@eso.org Mon May 19 11:30:42 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 444DA624164; Mon, 19 May 2008 11:30:42 +0200 (CEST) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m4J9UTVG001802 for ; Mon, 19 May 2008 11:30:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id m4J9UTOi001801 for vospace-outgoing; Mon, 19 May 2008 11:30:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.42.40]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m4J9USaY001797 for ; Mon, 19 May 2008 11:30:28 +0200 (MEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by aeon.hq.eso.org (Postfix) with ESMTP id 85B8C1E401D for ; Mon, 19 May 2008 11:32:37 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcCAA3lMEiDbwiLhWdsb2JhbACSLwEBAQoECQcRmT4 X-IronPort-AV: E=Sophos;i="4.27,508,1204498800"; d="scan'208";a="7416196" Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by clavius.hq.eso.org with ESMTP; 19 May 2008 11:29:44 +0200 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:39015) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1Jy1XU-0005kJ-UX (Exim 4.67) (return-path ); Mon, 19 May 2008 10:20:16 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id m4J9K5er017299; Mon, 19 May 2008 10:20:05 +0100 (BST) Message-ID: <48314642.7020202@ast.cam.ac.uk> Date: Mon, 19 May 2008 10:20:02 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vospace@ivoa.net Subject: VOSpace 1.1 changes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Dave Morris I would like to request a few changes to the proposed VOSpace 1.1 specification. Most are just small changes to the document or wsdl that should not need much discussion. The last two points, regarding inherited properties and the FindNodes operation may need to be discussed further. Thanks, Dave ---- 1) Faults in wsdl Container and Link faults need to be added to the WSDL binding. Although both the LinkFound and ContainerNotFound faults have been added to the definition of the wsdl:portType, .... .... .... The new faults also need to be added to the corresponding operations in the wsdl:binding .... .... .... Without this, the Axis wsdl2java code generator does not add the corresponding exceptions to the service methods. This applies to all of the methods that can throw ContainerNotFoundFault or LinkFoundFault. ---- 2.1) Link target In the document, the text describing the LinkFoundFault describes the link target as : ".. a node that points to another node." This implies that the link target should only be used to point to other VOSpace nodes, and cannot be used to point to other types of resources. In the XML schema the link target is defined as xsd:anyURI in both the LinkNodeType and the LinkFoundFault Can we change the description in the document to allow any URI, with no restriction on what the link can link point to. There is a valid science use case for allowing the link to point to any URI. An easy way to mirror the contents of an existing FTP server within the VO would be to create a set of link nodes that point to the data in the FTP server. This also allows scientists to use LinkNodes with properties to annotate data that is stored in external servers outside the VO. ---- 2.2) Link target (null) The document does not say if a LinkNode target may be null or not. The XML schema for a LinkNode implies that it cannot be null. .... .... However, the XML schema for the LinkFoundFault does allow the target to be null. .... .... The document should be updated to specify whether the link may be null, and the two XML schema definitions should be consistent. ---- 3) GetNode and SetNode faults The list of faults for both GetNode and SetNode method should probably include ContainerNotFoundFault (in both the document and the wsdl). ---- 4) LinkFoundException A link may occur at any point in a path, so the LinkFoundException needs to return the URI of the point where the link was encountered. Given the path vos://service/alpha/beta/gamma/delta If the link node is at vos://service/alpha/beta with a link target of vos://other/path, then the client will need to know that it needs to add the remainder gamma/delta to the link URI to create the new URI vos://other/path/gamma/delta. In order to enable the client to do this, it needs to know which of the nodes in the original path caused the exception. vos://service/alpha/beta I would like to propose that we change the structure of the LinkFoundFault to contain two URIs, one for the node where the link was found, and another for the link target. Suggested XML schema change : .... The URI of the node where the link was encountered. The target URI that the link points to. .... ---- 6) Inherited properties. At the moment, I'm not sure that inherited properties are ready to be accepted yet. There are a number of issues that need to be resolved before we can add these to the final specification. First is the issue of how we define a property as being inheritable. This would have to be done with an external definition of the property, probably in the registry resource that defines the property. If not, then we will get inconsistent behavior if one service treats a particular property and inheritable and another does not. Second, I think we need to produce some detailed use cases describing what happens when a node with an inherited property is copied from one service to another. If I remember correctly, in version 1.0 we said that if a service does not understand the meaning of a specific property, then it may treat the property as a simple string value. This could produce inconsistent behavior if tree of nodes with an inherited property is copied from a service that does treat a property as inherited to a service that does not. Note, I have no objection to the concept of inherited properties, and if we can address these issues at the meeting then I would be quite happy for them to be included in the 1.1 specification. ---- 7) FindNodes 7.1) Optional capability I would like to request that the FindNodes operation be moved to an optional part of the specification, defined as a separate capability from the core VOSpace 1.1 service. The main reason for requesting this is that up to this point it should be fairly easy to implement a simple VOSpace service without requiring a SQL database to store the metadata. Adding the FindNodes operation to the core service specification makes it much harder to implement a full VOSpace 1.1 service without using a SQL database. Making the FindNodes operation an optional capability does not detract from its usefulness, and I expect that most large scale implementations will support it. However, we should take care not to exclude smaller scale implementations who just want to make a small number of simple files available via a VOSpace service. If we define the FindNodes operation as a separate capability, a service registration would list the core VOSpace 1.1 service capability, and a separate capability for the VOSpace 1.1 FindNodes operation, if the service supported it. ---- 7.2) Regular expression syntax The current document specifies a FindNodes match element as containing a regular expression that is used to match a property value. However, it does not define which variant of regular expression syntax should be used. SQL standard regular expressions use a different syntax to the other commonly used forms such as Perl and POSIX. We would need to specify which form of regular expressions should be used, and we will need to check that whichever form we choose is compatible with the majority of the database systems used in the VO. Based on a quick look at the some of the popular database servers it looks as though POSIX may be the best standard to adopt. Postgresql POSIX yes SQL yes http://www.postgresql.org/docs/8.3/interactive/functions-matching.html MySQL POSIX yes SQL unknown http://dev.mysql.com/doc/refman/4.1/en/regexp.html Oracle POSIX yes SQL unknown http://www.oracle.com/technology/products/database/application_development/pdf/TWP_Regular_Expressions.pdf Note : Choosing the SQL standard syntax would make it much harder to implement the FindNodes operation without using a database server. If we choose POSIX standard regular expressions, then it may still be possible to implement the FindNodes method without using a SQL database. ------------------------------------- That's all Dave From owner-vospace@eso.org Mon May 19 11:45:00 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id A473B6242D5; Mon, 19 May 2008 11:45:00 +0200 (CEST) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m4J9isJo003426 for ; Mon, 19 May 2008 11:44:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.13.6+Sun/8.13.6/Submit) id m4J9isLq003425 for vospace-outgoing; Mon, 19 May 2008 11:44:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-vospace@eso.org using -f Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.42.40]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m4J9irdj003418 for ; Mon, 19 May 2008 11:44:53 +0200 (MEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by aeon.hq.eso.org (Postfix) with ESMTP id 2867D1E401D for ; Mon, 19 May 2008 11:47:02 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.27,508,1204498800"; d="scan'208";a="7416499" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 19 May 2008 11:44:08 +0200 Received: from [192.167.2.103] ([192.167.2.103]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m4J9iplU004730 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 19 May 2008 02:44:54 -0700 Cc: vospace@ivoa.net Message-Id: From: Matthew Graham To: Dave Morris In-Reply-To: <48314642.7020202@ast.cam.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: VOSpace 1.1 changes Date: Mon, 19 May 2008 11:44:38 +0200 References: <48314642.7020202@ast.cam.ac.uk> X-Mailer: Apple Mail (2.919.2) Sender: owner-vospace@eso.org Precedence: bulk Reply-To: Matthew Graham Hi, Thanks very much for all of these. I'm aware of most of the WSDL errors and will amend them. Inherited properties and FindNodes are in my list of open issues so hopefully there will be some fruitful discussion about them. In case there is apathy, we will follow your suggestions: inheritable properties, in particular, were an absolute swine to implement and raised the very points that you have made. Cheers, Matthew On May 19, 2008, at 11:20 AM, Dave Morris wrote: > I would like to request a few changes to the proposed VOSpace 1.1 > specification. > Most are just small changes to the document or wsdl that should not > need much discussion. > > The last two points, regarding inherited properties and the > FindNodes operation may need to be discussed further. > > Thanks, > Dave > > ---- > 1) Faults in wsdl > Container and Link faults need to be added to the WSDL binding. > > Although both the LinkFound and ContainerNotFound faults have been > added to the definition of the wsdl:portType, > > > .... > > .... > message="vos.contract.1.1:ContainerNotFoundFaultMessage"/> > > > .... > > > The new faults also need to be added to the corresponding operations > in the wsdl:binding > > > .... > > .... > > name="ContainerNotFoundFault"/> > > > > > .... > > > > Without this, the Axis wsdl2java code generator does not add the > corresponding exceptions to the service methods. > This applies to all of the methods that can throw > ContainerNotFoundFault or LinkFoundFault. > > ---- > 2.1) Link target > In the document, the text describing the LinkFoundFault describes > the link target as : > > ".. a node that points to another node." > This implies that the link target should only be used to point to > other VOSpace nodes, and cannot be used to point to other types of > resources. > In the XML schema the link target is defined as xsd:anyURI in both > the LinkNodeType and the LinkFoundFault > > Can we change the description in the document to allow any URI, with > no restriction on what the link can link point to. > There is a valid science use case for allowing the link to point to > any URI. > > An easy way to mirror the contents of an existing FTP server > within the VO > would be to create a set of link nodes that point to the data in > the FTP server. > > This also allows scientists to use LinkNodes with properties > to annotate data that is stored in external servers outside the VO. > ---- > 2.2) Link target (null) > The document does not say if a LinkNode target may be null or not. > The XML schema for a LinkNode implies that it cannot be null. > > > .... > maxOccurs="1"> > .... > > > However, the XML schema for the LinkFoundFault does allow the target > to be null. > > > .... > > .... > > > The document should be updated to specify whether the link may be > null, and the two XML schema definitions should be consistent. > > ---- > 3) GetNode and SetNode faults > > The list of faults for both GetNode and SetNode method should > probably include ContainerNotFoundFault (in both the document and > the wsdl). > > ---- > 4) LinkFoundException > A link may occur at any point in a path, so the LinkFoundException > needs to return the URI of the point where the link was encountered. > > Given the path > vos://service/alpha/beta/gamma/delta > > If the link node is at > vos://service/alpha/beta > > with a link target of > vos://other/path, > > then the client will need to know that it needs to add the remainder > gamma/delta to the link URI > > to create the new URI > vos://other/path/gamma/delta. > > In order to enable the client to do this, it needs to know which of > the nodes in the original path caused the exception. > vos://service/alpha/beta > > I would like to propose that we change the structure of the > LinkFoundFault to contain two URIs, one for the node where the link > was found, and another for the link target. > > Suggested XML schema change : > > > .... > > > > > The URI of the node where the link was > encountered. > > > > > > > > The target URI that the link points to. > > > > > .... > > > ---- > 6) Inherited properties. > > At the moment, I'm not sure that inherited properties are ready to > be accepted yet. > There are a number of issues that need to be resolved before we can > add these to the final specification. > > First is the issue of how we define a property as being inheritable. > This would have to be done with an external definition of the > property, probably in the registry resource that defines the property. > If not, then we will get inconsistent behavior if one service treats > a particular property and inheritable and another does not. > > Second, I think we need to produce some detailed use cases > describing what happens when a node with an inherited property is > copied from one service to another. If I remember correctly, in > version 1.0 we said that if a service does not understand the > meaning of a specific property, then it may treat the property as a > simple string value. This could produce inconsistent behavior if > tree of nodes with an inherited property is copied from a service > that does treat a property as inherited to a service that does not. > > Note, I have no objection to the concept of inherited properties, > and if we can address these issues at the meeting then I would be > quite happy for them to be included in the 1.1 specification. > > ---- > 7) FindNodes > 7.1) Optional capability > > I would like to request that the FindNodes operation be moved to an > optional part of the specification, defined as a separate capability > from the core VOSpace 1.1 service. > > The main reason for requesting this is that up to this point it > should be fairly easy to implement a simple VOSpace service without > requiring a SQL database to store the metadata. Adding the FindNodes > operation to the core service specification makes it much harder to > implement a full VOSpace 1.1 service without using a SQL database. > > Making the FindNodes operation an optional capability does not > detract from its usefulness, and I expect that most large scale > implementations will support it. However, we should take care not to > exclude smaller scale implementations who just want to make a small > number of simple files available via a VOSpace service. > > If we define the FindNodes operation as a separate capability, a > service registration would list the core VOSpace 1.1 service > capability, and a separate capability for the VOSpace 1.1 FindNodes > operation, if the service supported it. > > ---- > 7.2) Regular expression syntax > > The current document specifies a FindNodes match element as > containing a regular expression that is used to match a property > value. > However, it does not define which variant of regular expression > syntax should be used. > > SQL standard regular expressions use a different syntax to the other > commonly used forms such as Perl and POSIX. > > We would need to specify which form of regular expressions should be > used, and we will need to check that whichever form we choose is > compatible with the majority of the database systems used in the VO. > > Based on a quick look at the some of the popular database servers it > looks as though POSIX may be the best standard to adopt. > Postgresql > POSIX yes > SQL yes > http://www.postgresql.org/docs/8.3/interactive/functions-matching.html > > MySQL > POSIX yes > SQL unknown > http://dev.mysql.com/doc/refman/4.1/en/regexp.html > > Oracle > POSIX yes > SQL unknown > http://www.oracle.com/technology/products/database/application_development/pdf/TWP_Regular_Expressions.pdf > > Note : Choosing the SQL standard syntax would make it much harder to > implement the FindNodes operation without using a database server. > If we choose POSIX standard regular expressions, then it may still > be possible to implement the FindNodes method without using a SQL > database. > > ------------------------------------- > > That's all > Dave > From vospace-bounces@ivoa.net Thu Jun 26 13:36:36 2008 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id E1E2E624196; Thu, 26 Jun 2008 13:36:35 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m5QBabJk007369; Thu, 26 Jun 2008 13:36:37 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 75E99ECA38F; Thu, 26 Jun 2008 13:36:37 +0200 (CEST) X-Original-To: vospace@pat.hq.eso.org Delivered-To: vospace@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 36A32ECA370 for ; Thu, 26 Jun 2008 13:36:36 +0200 (CEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m5QBaasU007364 for ; Thu, 26 Jun 2008 13:36:36 +0200 (MEST) X-IronPort-AV: E=Sophos;i="4.27,708,1204498800"; d="scan'208";a="8514745" Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by clavius.hq.eso.org with ESMTP; 26 Jun 2008 13:33:50 +0200 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:62087) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1KBpmB-0007Sh-P2 (Exim 4.67) (return-path ); Thu, 26 Jun 2008 12:36:31 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id m5QBaNgq016307; Thu, 26 Jun 2008 12:36:24 +0100 (BST) Message-ID: <48637F32.2020109@ast.cam.ac.uk> Date: Thu, 26 Jun 2008 12:36:18 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Graham Subject: Re: Document promotions References: <31848FE7-4715-4A6F-AB6E-54F63CC18034@cacr.caltech.edu> In-Reply-To: <31848FE7-4715-4A6F-AB6E-54F63CC18034@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: vospace@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: "VOSpace Group \(GWS WG\) - IVOA" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: vospace-bounces@ivoa.net Matthew Graham wrote: > I also intend to move VOSpace 1.1 to Proposed Recommendation in a few > week's time. I'm working my way through our vospace 1.1 implementation building a suite of unit tests to check that it returns the correct faults for all the edge cases. (ContainerNotFound, NodeNotFound, LinkFound etc). Copy and move were the most complicated, working on push/pull at the moment. The spec is fine, but some minor points about copy/move may need clarification. (no technical changes, but possibly some extra descriptive text to clarify what happens in some of the edge cases) The wsdl needs the fixes raised in May, I'll send you a copy of the version I'm working from at the moment. I do have one request. At the meeting in May, you asked if node CapabilityType should have additional parameters, (I think they are commented out in the current wsdl). At the time I said they would be nice, but I couldn't think of a specific use case. Since then I have found a use case, so yes. Use case : If the capability represents a SOAP endpoint, then it is difficult to represent it with just the http endpoint URL. Example : If I have a vos 1.1 service that also provides vos 1.0 access to each container within the vos 1.1 space. The top level vos 1.1 service is registered in the registry, but the vos 1.0 services for each container would not be registered. To represent 'access this node via vos 1.0', you would need the SOAP endpoint of the vos 1.0 service *and* the node identifier (name) within that service. It would be possible solve this specific case by mangling the SOAP endpoint to include the identifier, using # or (), but adding params to the node CapabilityType would solve the general case. Hope this helps, Dave From vospace-bounces@ivoa.net Tue Sep 30 02:55:35 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 351A46242C0; Tue, 30 Sep 2008 02:55:35 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0tZQP016435; Tue, 30 Sep 2008 02:55:35 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 150A5ECA36C; Tue, 30 Sep 2008 02:55:35 +0200 (CEST) X-Original-To: vospace@pat.hq.eso.org Delivered-To: vospace@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 532E5EC8147; Tue, 30 Sep 2008 02:55:33 +0200 (CEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0tWsD016431; Tue, 30 Sep 2008 02:55:33 +0200 (MEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUDAE0V4UiD15EJiGdsb2JhbACTPQEBARUiokmFRjyBZw X-IronPort-AV: E=Sophos;i="4.33,334,1220220000"; d="scan'208";a="11100350" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 30 Sep 2008 02:52:24 +0200 Received: from brighid.cacr.caltech.edu (brighid.cacr.caltech.edu [131.215.146.27]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m8U0tRSS008728 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 29 Sep 2008 17:55:29 -0700 Message-Id: From: Matthew Graham To: interop@ivoa.net, Grid_Ivoa_List , IVOA VoSpace mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: VOSpace 1.1 RFC Period Date: Mon, 29 Sep 2008 17:55:26 -0700 References: X-Mailer: Apple Mail (2.926) X-BeenThere: vospace@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: "VOSpace Group \(GWS WG\) - IVOA" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: vospace-bounces@ivoa.net > Hi, The VOSpace 1.1 document is now in its RFC period, which runs from 2008 September 29 to 2008 October 27. Version 1.12 of the PR document is at: http://www.ivoa.net/Documents/PR/GWS/VOSpace-20080929.doc , and the RFC comments page at: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/VOSpace11RFC . Comments are warmly solicited. Cheers, Matthew From grid-bounces@ivoa.net Tue Sep 30 02:55:35 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id BB5446242D7 for ; Tue, 30 Sep 2008 02:55:35 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0tZBk016440 for ; Tue, 30 Sep 2008 02:55:35 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id AD670ECA399; Tue, 30 Sep 2008 02:55:35 +0200 (CEST) X-Original-To: grid@pat.hq.eso.org Delivered-To: grid@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 532E5EC8147; Tue, 30 Sep 2008 02:55:33 +0200 (CEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0tWsD016431; Tue, 30 Sep 2008 02:55:33 +0200 (MEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUDAE0V4UiD15EJiGdsb2JhbACTPQEBARUiokmFRjyBZw X-IronPort-AV: E=Sophos;i="4.33,334,1220220000"; d="scan'208";a="11100350" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 30 Sep 2008 02:52:24 +0200 Received: from brighid.cacr.caltech.edu (brighid.cacr.caltech.edu [131.215.146.27]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m8U0tRSS008728 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 29 Sep 2008 17:55:29 -0700 Message-Id: From: Matthew Graham To: interop@ivoa.net, Grid_Ivoa_List , IVOA VoSpace mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: VOSpace 1.1 RFC Period Date: Mon, 29 Sep 2008 17:55:26 -0700 References: X-Mailer: Apple Mail (2.926) X-BeenThere: grid@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Grid and Web Services Working Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: grid-bounces@ivoa.net > Hi, The VOSpace 1.1 document is now in its RFC period, which runs from 2008 September 29 to 2008 October 27. Version 1.12 of the PR document is at: http://www.ivoa.net/Documents/PR/GWS/VOSpace-20080929.doc , and the RFC comments page at: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/VOSpace11RFC . Comments are warmly solicited. Cheers, Matthew From grid-bounces@ivoa.net Tue Sep 30 02:55:36 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id BB46E6242D6; Tue, 30 Sep 2008 02:55:35 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0tZ72016439; Tue, 30 Sep 2008 02:55:35 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id AD670ECA399; Tue, 30 Sep 2008 02:55:35 +0200 (CEST) X-Original-To: grid@pat.hq.eso.org Delivered-To: grid@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 532E5EC8147; Tue, 30 Sep 2008 02:55:33 +0200 (CEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0tWsD016431; Tue, 30 Sep 2008 02:55:33 +0200 (MEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUDAE0V4UiD15EJiGdsb2JhbACTPQEBARUiokmFRjyBZw X-IronPort-AV: E=Sophos;i="4.33,334,1220220000"; d="scan'208";a="11100350" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 30 Sep 2008 02:52:24 +0200 Received: from brighid.cacr.caltech.edu (brighid.cacr.caltech.edu [131.215.146.27]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m8U0tRSS008728 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 29 Sep 2008 17:55:29 -0700 Message-Id: From: Matthew Graham To: interop@ivoa.net, Grid_Ivoa_List , IVOA VoSpace mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: VOSpace 1.1 RFC Period Date: Mon, 29 Sep 2008 17:55:26 -0700 References: X-Mailer: Apple Mail (2.926) X-BeenThere: grid@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Grid and Web Services Working Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: grid-bounces@ivoa.net > Hi, The VOSpace 1.1 document is now in its RFC period, which runs from 2008 September 29 to 2008 October 27. Version 1.12 of the PR document is at: http://www.ivoa.net/Documents/PR/GWS/VOSpace-20080929.doc , and the RFC comments page at: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/VOSpace11RFC . Comments are warmly solicited. Cheers, Matthew From interop-bounces@ivoa.net Tue Sep 30 02:55:36 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 6650C6242D9 for ; Tue, 30 Sep 2008 02:55:36 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0takh016445 for ; Tue, 30 Sep 2008 02:55:36 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 4B06AECA392; Tue, 30 Sep 2008 02:55:35 +0200 (CEST) X-Original-To: interop@pat.hq.eso.org Delivered-To: interop@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 532E5EC8147; Tue, 30 Sep 2008 02:55:33 +0200 (CEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0tWsD016431; Tue, 30 Sep 2008 02:55:33 +0200 (MEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUDAE0V4UiD15EJiGdsb2JhbACTPQEBARUiokmFRjyBZw X-IronPort-AV: E=Sophos;i="4.33,334,1220220000"; d="scan'208";a="11100350" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 30 Sep 2008 02:52:24 +0200 Received: from brighid.cacr.caltech.edu (brighid.cacr.caltech.edu [131.215.146.27]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m8U0tRSS008728 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 29 Sep 2008 17:55:29 -0700 Message-Id: From: Matthew Graham To: interop@ivoa.net, Grid_Ivoa_List , IVOA VoSpace mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: VOSpace 1.1 RFC Period Date: Mon, 29 Sep 2008 17:55:26 -0700 References: X-Mailer: Apple Mail (2.926) X-BeenThere: interop@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Interoperability Forum - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: interop-bounces@ivoa.net > Hi, The VOSpace 1.1 document is now in its RFC period, which runs from 2008 September 29 to 2008 October 27. Version 1.12 of the PR document is at: http://www.ivoa.net/Documents/PR/GWS/VOSpace-20080929.doc , and the RFC comments page at: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/VOSpace11RFC . Comments are warmly solicited. Cheers, Matthew From interop-bounces@ivoa.net Tue Sep 30 02:55:39 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 53D216242C0; Tue, 30 Sep 2008 02:55:39 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0takf016445; Tue, 30 Sep 2008 02:55:36 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 4B06AECA392; Tue, 30 Sep 2008 02:55:35 +0200 (CEST) X-Original-To: interop@pat.hq.eso.org Delivered-To: interop@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 532E5EC8147; Tue, 30 Sep 2008 02:55:33 +0200 (CEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m8U0tWsD016431; Tue, 30 Sep 2008 02:55:33 +0200 (MEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUDAE0V4UiD15EJiGdsb2JhbACTPQEBARUiokmFRjyBZw X-IronPort-AV: E=Sophos;i="4.33,334,1220220000"; d="scan'208";a="11100350" Received: from mail.cacr.caltech.edu ([131.215.145.9]) by clavius.hq.eso.org with ESMTP; 30 Sep 2008 02:52:24 +0200 Received: from brighid.cacr.caltech.edu (brighid.cacr.caltech.edu [131.215.146.27]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-7.2) with ESMTP id m8U0tRSS008728 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 29 Sep 2008 17:55:29 -0700 Message-Id: From: Matthew Graham To: interop@ivoa.net, Grid_Ivoa_List , IVOA VoSpace mailing list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: VOSpace 1.1 RFC Period Date: Mon, 29 Sep 2008 17:55:26 -0700 References: X-Mailer: Apple Mail (2.926) X-BeenThere: interop@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Interoperability Forum - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: interop-bounces@ivoa.net > Hi, The VOSpace 1.1 document is now in its RFC period, which runs from 2008 September 29 to 2008 October 27. Version 1.12 of the PR document is at: http://www.ivoa.net/Documents/PR/GWS/VOSpace-20080929.doc , and the RFC comments page at: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/VOSpace11RFC . Comments are warmly solicited. Cheers, Matthew From vospace-bounces@ivoa.net Sun Oct 5 16:36:55 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id D92DE624028; Sun, 5 Oct 2008 16:36:54 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m95Eau3r004708; Sun, 5 Oct 2008 16:36:56 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 6869FECA32A; Sun, 5 Oct 2008 16:36:56 +0200 (CEST) X-Original-To: vospace@pat.hq.eso.org Delivered-To: vospace@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 58723ECA320 for ; Sun, 5 Oct 2008 16:36:54 +0200 (CEST) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m95Eass6004705 for ; Sun, 5 Oct 2008 16:36:54 +0200 (MEST) X-IronPort-AV: E=Sophos;i="4.33,363,1220220000"; d="scan'208";a="11267154" Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by clavius.hq.eso.org with ESMTP; 05 Oct 2008 16:33:29 +0200 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:58424) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1KmUj6-0006lY-1z (Exim 4.70) (return-path ); Sun, 05 Oct 2008 15:36:52 +0100 Received: from [127.0.0.1] (capc49.ast.cam.ac.uk [131.111.68.77]) by cass41.ast.cam.ac.uk (8.13.8+Sun/8.13.8) with ESMTP id m95Eaj2h003302; Sun, 5 Oct 2008 15:36:46 +0100 (BST) Message-ID: <48E8D0F8.3080500@ast.cam.ac.uk> Date: Sun, 05 Oct 2008 15:36:40 +0100 From: Dave Morris User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Graham Subject: Re: Reissuing VOSpace 1.1 References: <934057B1-BFB4-4431-881A-68E5EB9982FF@cacr.caltech.edu> In-Reply-To: <934057B1-BFB4-4431-881A-68E5EB9982FF@cacr.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IVOA VoSpace mailing list X-BeenThere: vospace@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: "VOSpace Group \(GWS WG\) - IVOA" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: vospace-bounces@ivoa.net Matthew Graham wrote: > I've had some comments about the format of the VOSpace 1.1 spec and > basically certain people are unhappy that it references VOSpace 1.0 > so much and would rather that it was more standalone. I am therefore > going to cut and paste a lot of stuff from the VOSpace 1.0 spec to > accommodate this. If you are going to merge a lot of the the content from vospace 1.0 specification, then it might be good to look at the wording for the exceptions/faults. When I was doing the notes for the vospace1.1 specification I noticed that all the method descriptions have a 'Faults' section, and in both the appendix and the service WSDL they are referred to as 'faults', but in the in the document text we say : ".... the service should throw an XyxException" rather than ".... the service should throw an XyxFault" I left it as it was because we did the same in the vospace 1.0 specification, and I wanted to keep the style and wording consistent because we were referring back to the original document. However, if we are going to make the vospace 1.1. document stand alone, then it might be good to fix this. I think it is probably just a search for 'exception' and replace with 'fault' where appropriate. Hope this helps, Dave From interop-bounces@ivoa.net Sun Oct 26 23:41:34 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id DA71362409F for ; Sun, 26 Oct 2008 23:41:33 +0100 (CET) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m9QMfahC000555 for ; Sun, 26 Oct 2008 23:41:36 +0100 (MET) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 0363AECA346; Sun, 26 Oct 2008 23:41:36 +0100 (CET) X-Original-To: interop@pat.hq.eso.org Delivered-To: interop@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 7B850EC8141; Sun, 26 Oct 2008 23:41:33 +0100 (CET) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m9QMfXxm000551; Sun, 26 Oct 2008 23:41:33 +0100 (MET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwEABePBEmCT8iYZmdsb2JhbACGaowJgQcNCwgIEqpFg08 X-IronPort-AV: E=Sophos;i="4.33,489,1220220000"; d="pdf'?scan'208";a="11852542" Received: from mailhost.u-strasbg.fr ([130.79.200.152]) by clavius.hq.eso.org with ESMTP; 26 Oct 2008 23:37:00 +0100 Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m9QMfROk070908 ; Sun, 26 Oct 2008 23:41:27 +0100 (CET) Received: from localhost (www-data@astron [130.79.128.15]) by newb6.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id XAA24643; Sun, 26 Oct 2008 23:41:09 +0100 (MET) Received: from 72.4.254.58 ([72.4.254.58]) by astron.u-strasbg.fr (Horde MIME library) with HTTP; Sun, 26 Oct 2008 23:39:07 +0100 Message-ID: <20081026233907.1ide941oua0448k4@astron.u-strasbg.fr> Date: Sun, 26 Oct 2008 23:39:07 +0100 From: schaaff@newb6.u-strasbg.fr To: interop@ivoa.net, grid@ivoa.net, vospace@ivoa.net Subject: last version of the VOSpace-iRODS note MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_201c2at93vy8" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-MailScanner-Astro: Message analyse non infecte par sophos sur astro.u-strasbg.fr X-MailScanner-SpamCheck: ORDB-RBL X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [130.79.200.152]); Sun, 26 Oct 2008 23:41:28 +0100 (CET) X-Virus-Scanned: ClamAV 0.94/8497/Sun Oct 26 22:30:29 2008 on mr2.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mr2.u-strasbg.fr X-BeenThere: interop@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Interoperability Forum - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: interop-bounces@ivoa.net This message is in MIME format. --=_201c2at93vy8 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The final note concerning the VOSpace-iRODS implementation. Andr=E9 --=_201c2at93vy8 Content-Type: application/pdf; name="noteVOSpaceiRODS-v1.0.pdf" Content-Disposition: attachment; filename="noteVOSpaceiRODS-v1.0.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nMVa3XJctw2+36c4d92TmaVJ8D93buxJ3ck0ibPjXDi5WGtXllJ5JevHbp6j fcm+RQCeQxLUUpZV200zTbk8AIi/DwCpvh2kUDBI+icvjt4s3g4qgE2/lIQweIgiRjdYJZ1wnkge PffDk/PFjws5fIv/fb14uwhC038SG18fvRn+ukaGMCiF3DEM6+OFRIHR6PmQQZPgwSkQ+PXNYjmM 698WT9dJvhTagrQKF05pCGp4/m13+/JjtIiD0sI5a6sWkJUAKQJaiwTBkBovUY+VFsoZqZfPxl/X f0cBSnIJXrhgDJmx3iL9fkQbwbiwvK6cu3HlhAYb1fJyXNEZymmPtCCMk0YvNz2uU+IyRoe4PC+U nCevzkYAEFIq0m/22WeJSYzkh+qOPzUq6GZh3UFUhtEKB6Chv/lidM734gZGgDUqx405+3L0Ikrj FQUDvROtNMubEqH/g9+9Ec4wg/9cv1uLXn2o37/vggWsCKpg5VXx5NW4isJJHwGxkh3NofIurUFZ b1kAGFgqQmr4fh+tlCU2bxfaqDhYa1IJe4M/XSg/z+afmAH5JxGXnyeLn4f9Z4qvUVIAdyyLL+kJ zpvBkvuTnuAxC/LPs/mnivlnIi4/Jz0/S9wpWFMxftyod5/oNuS3ZGspPDDZLwlFQhswlq1Oy2pT S2ctfUcsG3ajte5/ACBpeTcCXRSmcUGK0K2wasxTFfSUzhPFCoIVBL4VaOFd/YAeMVhDv6Off5n+ 9UXwrNSgorDSQjXLuNmsgM2KMh71nnz/FF2qIgD1ohVVG3BAzQjZ8HQEaNk8G0kWtgLqS14oC95R sxM2aqmWrzOlR9MK5YZ2lQOlcDcxJXwqPNNahZjN7K/K6qasrirz9eiEtwB2Fo7F4QVBPzqIEUsN JkvEOWX502SOM8uLImbWQWmHaUOGGbR2VzerYsco20bn8Pt5NfySltHJZANGUUs0vDl9RZE2TmXl dACmcTUShSLwPU5WszcT5VVRirFvxiCUidiMWFy2dTmM4EPuPNiDNFBqrb96yb22K3EsNgAWUmXQ BhMwjCVOR4VyV9knxZKHPnN/m9IQv8svPVXcjwaDhTN3tzmqGm1mfqB+olFbnT2CbmK+q/Hd1/jO mRLUUlVBojLJ1repHHvBtVSq0dLNgH02rkDE4I1HbUEAGCyMKQUhAMp7nLDgEwxnSrf8R9kkZdGL NmKCGiF1lGQq1lIfDFQWv4SyKceVFdGbSFp74bXyfhnmz1pxplkPBDdmVOavB52TpCBlhIR3mUC3 KzIxSYMwFJ8s0znNFLH8zC+RkTj9UdEvGdkp2VNGVTEU5QK9NUELKwEsT8hSH61LQzwO0drbgOlD fdVIXA51990IigbPSDkXMU7oFvIFHqK9SzBUNOO4LAr7HrrSoKoGPbmfj8L8+zpBG1OiZFUYcKqi 5lvTKnCLsWqmpMujnaZpx1DOKkx57ylnsf0GrzxFP+1iAJYrWhplFSVKoZXdZSD9JaAAEoulEr3O vzMBtpBmA1pv94KmsQ7Og8R3k1MgYvksnr4mA0B7badEn3avOAHmpwHrc1DIv++K02cmF1wblLJL pcAY5ZWdEnyKxaeFxTkRD8NyUj11XcNCd5SIVxkchS5GHDqM0gHPLN8f4UhulUFFHtXN94Q1zD5s Je9HnNXAK75iUT+lUQudjldc9Ar2Hy9t6o9ZlU03WfZ1d9dV+1FV+0k5l4nFEc/TXQFT7GZKi7B8 QwECLbWZbgm0t2+kJ5ERw0ONkmrOo7J3RhzGgOYazwppMFzNyn6dnIdd/JPlZHYGnXeTic7Fas5l /XxVP5+WM89TCoHFnHOuvjn0kLnvxmj2oQo2H/owuOHwKGe8/UBSVcTelKHhYihVDKFRS9sEEtBG c5DclCrG8ES1H1uyCi0K8+pyupIrzJu7QNgpjb8s5zIQAyuov4x19+upDJjw8Sg109x1C6UP8CXE ud+8pL6NHc9ZemhYKSckXvJ47Topte28rFg9au0rbmkNfHAZwpHEHxr4mI4NgI16euyitN3WBGMZ /N+6O1Tk/1T5GchPutnKlse1YBwnVGKV5GIZKcv87YEKIOPym1Jxfh/R2alRo97ghAo4JVW4nbHq x876YcRBzxLXrva0q2pMvxxkYdrDHAN66QhlwviIEQXih0aUaSASWtHTLWIQCwIGFGcqUHiLxYHZ azkAAJ2BSMbpW+nhcrc4/mpBrwfWhzRf4z3BOlrQ/+rKpxMf4D/Ec9cmlE08QeZ9MtxqPA4XOPYM lKLOq0jS0dFwKOnDGvV5Zvtg2owfffQBx/3OmF5j4GPs6zJMjpo2uaOyRi11f/fT514rA5VzvDHP VX1+xTCQLjIDXWhoEtl+6UsaAlpTJpf3oqYS4c2G/jgxV0rSSUmPlwhKcunSzQznGWwvMrVij8Y4 IEgDig3SUHHI39PbEea+9zT7oaZGy6i/0JUCqJT38Er3hRe1f36PtyApbXRTdZw2L+qQuik96ygV nIgli4+mWJtwJIhUHF/WVqgrwa91l9GepssptupUvbCOYY4HTnBd2U6qsNqNqSYqajAGb6aF9MUY 0WqLfaHa9Xi2K/oqP6KyZeSOReikK9VpRvk+VVdvLXXARKlp7KCmrWH5z0l7lwJZeI75hYm013R5 LEyM8sDORLkrBzHSLf9eluwo5tR9JWC715TBHlODNrEpY5V2zKj9NOIhJJWJecRjClTK4zoqsZht mKQUMhU4e1895oBdx1XMvE39fDQ6eo+KkfPgUYbKlHdc6HlDkHXZ9Bz8rsaS+aeowoTeFHam1Fm1 L6sSOuFxyhBpEu/aUIMPFIFVDsFqRi3F4WqGn6PRATxWJV2w44of06DLrptp6I52nliU1ogEn2+p Lk3KBX0bft/P1jOjGNerQsq+t1Uhn3UAhflGS06l9xpG+iJN2IYejib4Yqqm7/Q84j1T8KI+WFxw VbLWLNWOalBr0Fko70BCiepVA/DWg4mA0W6bXMu0TEIvw9usyxly1GW6SnmvYHrSK2U1wdYbimOG 7bPq9mtOWrTaFmMfUkwOdCEMMqnnU2CcidOIng7AwAAphze/NPWmOwSL6wdroGl8yaK1Z9EsWj+0 hFjbVpCCwNmbHIHsbWdfl9vmbQ2HEAogXQTyXfS8JCjTk5Gy3abTtfdSovW8Vx6UuPxSlK9dDK6v 7+iggNOP0f4w1omU+a3ClUntK1NJb/jokJO5KaIlV0qsdqVxNAleHLCe76jIc1Liz5KiScps3nkX rG3nyAfcJ+vmDuBPEPTCRp8huDucFpigg7AfNn4Ai17zt71zuyxdVD/2Lb06qDAU6Vc9/52NNO8q aBzBYtbgN/uMnXrcpnixtQ/wLvAmH3Lg/bs8lLJ+18yoZXlUCXKm11Ex8L5R87QClDVD5qhtZWpe gzLQ/lMktTmbD2Xz6b5BdSboz7qHI7IxmrPtizKsAByMU/kwr4SlP3a8p79lYzaZNteyUBaUf+WJ I+Ymqw1vshueQJ1ewaSyDLnpouJQu4nFRqPuGLanWRUVlGVWZeX9FQdFPpGB9/ogVKaNQ2HfdS1i JrMZq+un3fwYqTnljiO1M5ZsuqqyU/tQb3zOpnUGyvx9U03kk+fkUA6/z3tbzE2/uS3WC9j016mg 27mvCGAA2nbFHsawxS2RWkwim0v53Mqo1Bswt5WdSWuJaH2ZT2XF8nnJ4MlZxi+flK3steku2nGF raGsl9G2rGSudXluZjX1tNTvW3PrzMTxVXGYSpnzBDA+0x0ax1tiwl/A+7bUGX9s/m3Sk2GJz3RV fr963Dcf9mgPhhYNHEsNAln5y+x3trKuLp0JmkFp9s29UFrXv9k+rd+/SZGiV4e/ldVQUoKljLnj rSWTXnSnQ9Yyfute4Y4KJJjJguOTrLz1/yn6cfEHGdX05GVuZHN0cmVhbQplbmRvYmoKNiAwIG9i agoyOTMwCmVuZG9iagoxNSAwIG9iago8PC9MZW5ndGggMTYgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJy9XEmX3EQSvvevqNtUzaOFck9xYzAzMM9spod584wPvZTdxu4FNzb0v59I SZnxpRTqqjI2cJFVuUTG+kVkqH9dtY3Sqzb9nx/Or47Sv4zTrVP04JXRUa2e/Et8/ebF0a9HsTHp v346Pp9frf5xcvTpE6VWyjXOWLs6eX7UNl3XWR37IWoVQ+NXQasm+NXJ1dHT9Y8b3ejolV7/tqF9 rGlbvT7dHMdGG9sqekt7BK3N+u3mONB20Zr13ea4bVxrQ4jrVXrWTnUqrG9oCdO1RO36+bCaDTaN CE0XlXLrEx5wyY8vecDSyo82x7Zx9FrjJucwOpPn9fqKRigTgtPr7TDCRGPX1zwxn7UztMuzk38f fXly9AOxPLF9Hx7HlVKND11kFhtXsbglFuuBxScb29hoddefOUbbupjObBvlInGbzmyaoLxRREzb WEuc75miaJ4JHQ3wjfOGTkYs6ZpoolYkIyJBeevzpLZbf0vCpNVd1zOJdvLR92e1VgXi7nZ4q+K6 4ZcrfjzZHLsmdI7kflmW3/JSMPQ5U5IppQFv6KitVV0SpPJNJLJo/zIS5vNIWP/1yBSf3ub9T/l3 4pQyxG3n8+/G4qLDqYl7CumDAUDLZVkA6B84rbsOJ13wqrDBeRn6ll9epfU7ZzwSeM2//4ZsT3qn HZ3HJuU6uSBV+b0XIJnNeOp+EhLVkx+iWWv+vRUfY5E1HOUbpg82uB9kZTzql0qPpvO2W9tRFqpW m0T/cT5AEkzyOOkUX7MWX7PG09q0RtOarJL9gKxni/o+zAnrd4OVOB9RY1Dh0iSrK3neFC26Ri0u i/5eDGYL5lR+vkJ25d9fTQlxnVX9LGJFcAEVFtYSFf5WVK1hqJmYTlnptGgWKDkMZc0rC8FsUByg +VbY/UbU25GlxDLaUpOjVbFoELm4W1YbNNFe14Mjqfis6yCm6zIy+8LO4J6gq+Ai4PFUJPUlD4Cz XC9YFrMXhma6LgSudeszPKzkem7motjWK42bAtWX4qKrjQ5xsLiRjWhxt2xmbzbHnmJ3MEVUifp+ SeIEOavx3Tmrcc2yHbYDHnzYqItgPK95/p4e3FYO+uf1uKqt7OR6PIBOZ6njHjj+fqjs+DUPaMsC LXM6FmJ+3gwUeIIaM3c3svzxEf37bwNoILRFGk3ILJh25bQ3hAtWhKg0QQS9erM9er4nplDtLlBB etTYAVN8URwXYIob8RHghRzKb5i513LUn+qzXWJzpcZlgcq35llzK6nV5zXZptJKBxTu4K99rGwb 1POFpBxFp0hTT/GsxbguJDDxhvVgy4qSsKXRXvsAxv1u1GpfOz3BDSzZObuJsungnJzDhW7LQHB+ gD/uRkdraGGbHS2c6X5GqPITlzoxf9qKQQlQwuIR/fh2IzhZMq3RCX7GQAbwd21KBNp7U2ot2YU6 xJJ2onPfBiJzsKQZZk42AwAF3VSidGqo2ve51OOjk78fCPUHFgwDROiTo+spOkI0yzzga5bwT7RW ozpLHv67TWja1nV+/Tm/pFkmpUE0C0+ezWaeLEw8ALz9IyvoLRuViHIYmt1x0KkMuFjCCzSfTOid BLVfiI/bHUiiim8Q5wsBFSTI/AVfNRzQBTTqq42idLKdCq2seT1aZWySzoxWWSOKPAuIYlsXLWwe qetUQzxIlSBBbCusFhOkrUgq4CQQi+zgBBw0yqeztg6zoNQAbonBQStfwaCBnQiDFi2NQnHjTcAB 1wvWXt6CqV1gLJPepi20blKlooLK1YCRBrCBSzYczi8qXCXtcDalpk9A2MgmWcM461baADwL57Mw H4z0nO1JNLJPKiHyrpDgCLPgEfY6wzDHeLICzuMGp8yBW7QdSGdKRL0Z7NB35Lx1tkPOps45OIq6 zxb1Sc1hY8i5BknJgdAqmxKNrFgLkCyzUsjw7pj4aiDUKxb8YWb6OzbImYCtNWh6IwfR9G7QcMYU IxEfbZMi0L6GN+T0RT85MEGM2e7Q5LPy+0uEk+Wg8BY4cV/sJ5EdbGMU1geAUeyNLmv77Cd5Qbwz PJ3XT9FaNTZYjxsMQm19h/SBjz2VzKMwO4yB3wawozvJeovyAH49FdUUVbvo5n2O/7X/zlR8PVqb alodsrVNfNPIBqDuUnIYcHaQ4yQnH9e6xgXkwlsh8WwhxOXfpaQd4mZlsvOR16LxwYB8gErlbmau q9O18Q0MXTC+qrRW3kJYGyjVbkG578Qy20r0GBAhZdwI9imGn+3CAg8n+5DDVe4JBgj5phgfeSRA QM4GTwUBY64Iixf5im76XAxzz3cFWjb0papWDfz6MNhbYyr2LKZWJP2Uv6yMDh+hSuEI53RjcnVc lE1+KqWq6nHHyPrnlGscs0otvBR/l552DNy15J/bZ3l1UryPt01yMJNt+ofi6aUfpVHShL5s1kUK cgVy/Ym9FBmx8v49qbRkae9xhP22kn7c993BP34QSvbj7+GyMh3FzvF+KIue8rV0593Lvy5HREV5 XCiBnRCinMaNsKsPhnlSVfeFCD8Gy/FWN12lx7YN5WKd/73fjfpDPk8ZvbLRNXGszEJd/S3EvGx9 WCARyq41PhpOGQ6s7+RZT+ByC9K8Qh4wD6qa8FhhGQiPAEQPuXYRsChQW9VLZhDJVPzAeipgbSnt wVQsT5+BlQqj9UsBLULBhXNl+WYK9qouj3tA3KkUqbMvhGhf3SODEARafkPo4dqW47xqKb63po/v OnTdyufovm9vw4Pabn0gGiuFh8OK0OW6EmGnmzYEPxYxptJimGsiyahzFcx9ztgWEO/bWckmPV5A EtpXlALiwjodmGdr8DuwmjHsZ/z7p/z7p/yWsbX01GykguQ70TShwAHTAHrLIBpoeTSpcGdtzynf kt493L8AVgx7NVmAkyq8VmOPA/H75JeZlpnGeNXVI6r5x5Ru0xiMI8O47OL/4hYq+mejRwP4PAWm TrW9/ue+qVf8CH1HN5tIqtjFdKlCWSY9t33kK31OW+houuB5L/gRR1ylnifXta5+PWyonPO50Sm1 YY2tVc6Zj9X0ZNvYtPE9mp5KCa1YLRhA1lTnIaBWjTbS7cgk4S/ri1WkHJIrY8zp4hbTTawR9Wv2 N6G5ZM0r3UiUAiGzi9JJwpiGWvJ8IaXpqXAce6c3T0dfVcE01wovsPQuFSQm9Y6RKjmelwFuvHZO V4GPytOPFfjIS4l3FmMfCMWAaEsE3HUlCovOWG00BJqZTkyPt9QedpBUxqGPkunFwOhqLBGXGuqo 615ZvJ+qgmEp6YwMSXpuRowMXIWSDsQ66Om43/RO0TgOsGtT1RsnwMlWWisjo6XSZR4qAlFoIPyS f+dmha/K/X1eiR6f8qaWt3pWKeCwa66uQOtX36eU5fPLrPukrr3A8YZYmpom4UzfcPg7FWXGfU4V 0wBBFAUWAdCrAhxlEDy7PJoi338PFhSJjdl+QP1mRKf2P8jX/rdRRJ53uu5YkO8M85bfFkt/KbG3 tqSgKH8MYX5jWveTAc6ASXDjx5vqstP3rFFGNKOeKwv3gXUjonZ0UAooj/ntfbl5L21Tk8t2S2wM leXcCDEEVt+jGyYP5chWFWCn1hoK3B3bZaH6n+njmqlc1j0vQQyWqq7kshIcdsU8nkQ2nMlt90jq nZj8yPd4cn9kdXE8p+BMnP92NKJkC0YIQ7AWsPBJUclyv1IHwf4ip8PzPS03RY53f4aeh2lm/gqF aBhZ9U2JaW7eHUIYBCNoK2LDGTixu6Mwa6TQVDa5Mp91b07fzqoEQn9LHbjn7X2INmoxpWDDYWkM 1paQbxEUbODrSw1sBB7Xh1lwBDZ6Fh+o9BmCML7KmmO43LWWMjzpdFVYkqok91UfawEzUmlENs+l uJQxKN44DrZD+X8sBV12BHXUEnAVYFgYwLZVRTNoC8rRTOzOBUqBVzcLzgPa+naA4AVbZLsZuIB2 c8gnHnLfSa5S1JmD9OEFmAXGnwe+dlhs7ORQAxYImRds9Vbq9oIqxQsp1FXYfFr3rO+3Kg2cXvrV ZbAqqsjHllF8DuAQX8AwxfaTeTC1/PnCUpPWCyRwaALT5MULdrtBGMV4fHqTOa2iSVwR7/orZ1X0 HjRc7PoRO1dlAsU7egxGeSFuIpWi1ivOm8TN5bRp5CWa39L1NxcDoekyW6ccMvK7Kr/N8fy/RDDt 3um0UO6EhS9Dxpfe4HmAb5DzKLYXU+zlGc/CTGWhB/2vr38ZYoTTuRedHGdUTuGnedf8OR7UoOoq lTQifwDoYj7vh65S6Y6I7O+nhwoiDW+tRy9OIhlqlAHX8o1vCQQ9UKTUpomdKYUNuLURL3iwWlRU 4AIdbZ60x7cagKAG9xpyucWQmZhMtpFPRujPP1R9tW1HJqCQR/qD8Og/xczuoOAm9Z0AD7iOX31O kiHCRz32wkoHHnsnXp06n3KhWh3Lvu+xTON93Tpr2Fs27EPVhlKOseu92iRV43WnH9iF1o5tKO3O X5UjQToArUBQmf0dhu5qip2ihkln+bxxl/XDp28Awl/FSY31h0L1Y6Tv4V5gwGW7v32R+op2K1pJ YHv+dOSdW/tn+TMzoIWVDjQgsfoIkRrqhKfoRqcfny19RfZOGloVeaYcNhWDSRl1MBWHS4eu+sim bBdMWVJAiFEA0fmiU/yeb+nyRbg9Xcz9xcglGfZCyRrQft2N2+cgonhFhF59NzsHppBtVah50s4J buXDmM2+UtUfzEFD8VWUpNzWOfuAYGiwPOB7UsgQ+nsut9SgfSn5t91+AArye8nvvcMCaaFNkLig TpU7hAhL65UKbbkxtpvYWO96cH9Mp3Y6pg+zhZeLAXjWhRRT0yVvshdhjvBwrCj7PHHGOtUOJRFK H2z/UVRC2q7/0xrHrmm9SQ0emdzXPbk+ucDXm67xXavSbBJRKqfAit/z49fDz6VJlVINsmz/ENsn J3ZtAvMHHniQhIuHimHRzBbEMOxwiAwyTT+RFgedGsG/6wNLZ1rXK7RtvHaaFDqTxwIgddbJHvpg RY+hjV1kCXzJbP+DR95W8kt39W0qmZXpb9Kj1l4lx5iHvqGnzg4tTnOxuf3FdgCDBplZV/5kzf5i MweKrWxyiOSAMtl6UKS+/zs3dkmihfuVSBUZleksrvnPtJOL7fCNyyg9ECSL7IukRqavT1yWlyBn eLwbNu0ro/tJPOwvcYm3C0hRL2vTwUARYsFWyqffYliDPhD+2KfEmvvyJ22qL7LLfPEz9rqxP2NK /IsrMygYPxTWfjpeOwHo60EDBM3q02MpgzrbaNIpa6uoLH78PfuWyoSMdG1LeqXjYefr6z4/HP0f WJltVmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKMzk4MgplbmRvYmoKMjAgMCBvYmoKPDwvTGVu Z3RoIDIxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicxVvbchy3EX3fr5i37FZl x4M7kLdITrmcSlVimfGLrAdquSQV8SJRomR9R/LBAWYA9MFMj5cuKxWpVBrO4NJo9OnLAfi+G3oh uyH9LQ+H283QfRf/XW3eb3yv0p/xAz4fbrtnZ5tvXvhOiN664Luzy83QhxC0MmML0QXfW905aXpl u7Pbzdbuzv4V+wiHnWxvB+XSqGcXm203NWmGlar3YRw1tni5fb6TvR6MCdv7XWwlrLbbu93Qe6+t t9vDzvbGaqm3N7u90L1W8eVjbflht1e9E8b67ZvdXvfCeGviSPvQq2BirzyU8FGWV2d/3Sgne1XE 8/wKlI0rXF/AXg+hF0F0e6F6radl/DlKJ3rtokzvsnTxYRIjSnyEtVXZLurLN7S2X+qCu9TSKy/F OHqcUsdB/xQXpLWIa44N6uO/d7oftAiGBAlVkCRSVeiRHkHNTxflLM6kvQ4SFf6RJLmhtzDVf0b5 pC7boAfZe+mzlsPv3wclp314sdu73jutVNX59nKS3hmPIj1UlfEqOZBpHdHe4mQhWPFVFyKHXioH BjW1+8vZ5odNwrIycjAiPlihpBfdi+/Y1w9PwbgQnTC9UWmiAvJxAQnk3vW2s8ZmjL/cit1+6M2g nUtbtzfC90KI7ffptTRS+TDqTIUhyhDtIGp/8MYl9co4iR90RGP9fkGPj/QYNe3j+vUgRkOyWkXz TeaVpogb7BKgXVyKt7LMFlWXdyAr6Wu4uGn1KvRyWvxPBLu/7+LCBhPs9kd6mWE1RMM6ryZyyCZi GqxlBDmvti8JLIoavEJc17aAxg+Axtr0IwHzukqwnDZ9/556sesCDwa9AOSADcA7i6hLGiArRukC KBtU7qS0EjgXjHrPNrioYy30IkNAZUyiqMZJvaYxH+tA0OdYX8KUH0joRrxkedLEVtKVSFbnPKeJ ruiRhu9peH5/Pja2EJ2DEL7ZClozr77rcVoT9GxVZahPtX+jSGF7r2VolVa6Q/w9pSnof8EpACS5 ry8vWa0sFrUYSjqfNmNfdgOjcpFJlYGil1E10Yg7trfJ8SqT92yE8hUXttuFFoB/qZgkdC4tKna/ TS+DUdbG3Z8DfQqre9O7YAYBeRDo6Ta5PWmldVHUmkG8HWc1ZgXya/5Lit4ZV/KDqEWw2F9F6eS+ 6viKGvDu65EagHnAbIDJNftizP/ulPu4nlRkYxLE2urDhF/n+xQIMn6P1Omcs3roD0kOiHWJO09p Z335eSdkb71WrVAqBbS4wDu0b0b+i2bVRS2gzDu2AeziJWkIHsEFHBZ+wSLYYIKPOzH0TgqLCMz6 /N8hUPaDcw2ajhh3S752TQg5Z3O7xpXWboCxmYse55UROiFlN9LHNLNULc8yxoJDCQEkoko4rEb7 PP7P2xJCIMkAfwJRMSvOuvVw02Aky5XT4yQ4bWtNagO440cywRrYGt+AsMqjPyOpo3wxmhgRt4jG fEsTHScEBtsH6RcR9OddtgttcPzltiVRYgMRs3BFWVgrVRO366Lu1yCe9wKtHvzCiucCb1DGuqsD XLFbsRbZoG0FVlYTAuuC4FLUMsgVuE16ldHlQ9PXNADV02BsTT0NIGLwCBGJvl+0ISmrtUlYoSiF UWkzuVpsrSwrL+FxzQaWcll0rufo5Wq3kuCLpYhj009k22SFoEOwMvrOG1EbPKqOZylriq/NAmjS EVo2VlK2JqeN65+FqexQMvZW3P3SX1mUGVzTASM9Cc3Fm3turlPQBjxeLPEuEeR33HeIHrA/v0yz at3kPThBRWPWLKKRiUgrCIUwF2WyInm56vkTQXLJQpCnVbAmzGP5VbSW7wBMPg6+pcc/NvtOI0B8 JdcBWKnfX9fv5yg2lMgzDOdtdyIGD6efsO1TS9fOXzfwHVc0QMCLkSbbfc8sVSeig8kvQRfX6Dhg AlrLhMb4sw8FjVRVNZneSiY3U3ubFX7iYvINQgx0cTKrLMoEx/QFa80iyulcO6OlUFhdHG8YXOWu 6OcnkVa/xtpoZxIOjR//G4mbH4nL+HbM1HSUCXKq55QGtZLGdchOe5sm66STnesejpvLr8ErGSdJ uJrbQUpc/QKF6wKkuI9Xxa0cCVzJPdrYVjlISJdkpbHoEx45wubAIRKGbzK70glodq4QfdhFHVXN OjV0iZVOihVChqLZr8PcSaliZk46BtE/zsPdKBz5LXDd0Kspq3jHU5oeuPQZEAiuu8kfS9O1rJ6h qGj8Gq6Lq4lfWw9WxAMfD9n/xAdoN8NHPjmA7sBWmjr7q6Y8Kk2pfGHT4MVGzEuWU6tv4jJ6LWHU SGjA+oB5yPq3Qpeqwydbzs54u09M+17HaiV2bM4SIEMu5kKhQ2KgryhNFHk0TeNUVGw9icAgOSdG NXQKlZyJdc+XiY7TEkMzT7zWwjVQ5RQ8jssHemjQSFOiAKUP4HQ+V08D3Z+QPnMR7Wppz2A6DdrK TE2xCswGF6Y/V9s+Z63seGICCn1IMk/UkUspOFFHZaDWm5QxXy9ipF4jtK6oKa9fQAHRuJBG8En5 Oy7jaBRc9gRkbUJ/EWUt9HN1a9bSCiFUQdVkz5Ae1+AIcfK0D+fS0NWyNBdSZNRQlcIGNeTSjBOe +o/Unmmqmxu2+gMB2SNIOrXlA8cKCVMHhdznRbX/hqWqTcG3C5pgmLv5tMAmtoybMYSc2+bN/Vs6 tPzD/+vM0gxqivySP7D8Z9Kl0an++wAtjm3reuB4gPfn8Mz1Nb5o4msfReqY0paMhgj8R8wUK31a GF9XuN0RLVB4Qls8rMCUoTDRBCyAALCj0JQM/xzzTogwhYdepWBKA8DYAwUxSkcnDIyHWnxO17Di ANIiK3tGgykVpB/VsV2B4zzBvzeRhYuHdY+aKr/J/3IUhJZw94N3CBeV73G+RqQmuMwPG1yT1tmV tK4IQJkqJFX8ESVIdcNytfesDk8r4+nHgXXQOzY40RkMKON59ZNMNtyccGQlY0D7B+0PW8NB7ALu p6gHODzA0m8LQjGddcExlwWUE/TdFUofrkVNV3+Ahi3E40OTRc44xvaKwSckZOvbRRYyi21NyGf4 Otjo9iymLAaOyxmWz85gV3q15FrRFhRTlOahfZfu7F0Dsr53QNxOmIw60JX1oXSUPT2BbIrKn4be 4Y4RTmeGHCSBIz2dGTIqZVW+5qmYUeF4EYcinE2Kw2rsJeHIEo5e0VtIx94tgRYjIATOK4xws1K1 Pe2/YqEIRs/fkLniAhCdIUBLNmq1Bx6rZClz4LF2l2Z+N+A3nJaDiiijXCEQ8v7z9wWQQFiED+fb bKP6BzJQ9orAbYZaTJiUWBZk/CEGX6QujryAjJ2d5T+BH5pfXFAtamabvnqZBgB8YAMprLClRWaD aa2W/MGcJEcMThrFWAex7JrAVImQRMU43Sth16/O1UuyUMZx53xtXjcN69q7cwUMPBvFApu9nAPB 7nK+w+tXQUEqisbtIQceY2WpGiaAgV3L/JcJztkt5l0/nBLACPd8RGFyX16FJ4A/Xq0eZC9FhSC/ a4YEbX1AaUskIo+BY7u8Jcl7vZKwl6aX3OWzG/akjb5T6H5DbOIaa1MQVBSCCGprs1G7LhC539R2 JYOs+MJrEU1BvlKGv++kG6ZfA5BS2M7JkIitTkgzJB7+cBurUKm6b+9T4993CBM/eR2r9CHx8OnX A+gG8w+b/wLUVwCQZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iagoyNzY1CmVuZG9iagoyOCAwIG9i ago8PC9MZW5ndGggMjkgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzNXFtz5cQR fvevOG85pyoWmtGMLo8QIIGiCth1bVLF8uDLsRdYX1h7Dfs7kh+cHml6+mupZXu32AR44CDNpdXT l68v4183deX8pk7/8o/Ty4P0f030dXT0o3WN793m2d/Nx28uDn496Ksm/TNOx9+nl5vPjg4+eebc xsUqNiFsjs4P6moYhuD7cYjb9F3Vbjrvqq7dHF0e/LBtdod1FevQdf12szuMrq+cc9uf0mMffdMP 22e7w1BFGuG33+5iVXdd7befy8PnO1/5vnUDLfDj0dcHXxwdfE/kp094Cr39xrmq7YZeyG2iIrcO Vab2aBeq0Ac/bF/t6qrvQx377X5HC7g2JPqHqm86ena/O2yqzrWNo9fjyLZvt29oeh3cELe30/vY 9ulTQ+Vi38btdVqgGaIP26u8aEur1lUIjgZvnSxVTXv13m1reQpjX8nTY/kJ+25khZOy2V4oyJ8V B6IFNiiT5GPgC1/Lx8BSx9NSTeD926HJs5pALDqTn/AFxBhH7G5o2auyALz/WtY6nvZqAxM7rvVW fh7Lzze7w7byTUuS805WgHX9ODYOgVk7ToOfvUnu8Sh8vmsTISQ9R2ckMEK4/Y13u0NPyuh6RwfG Q/fmUPW51tdcCBOuy1pXs7XoQPrtD3KKTt67MulH2RUO3CbgHp/qU/L1sP2UDtFVoSPZ+o5+Vm4I pClf4Qa+6xPnDpl1h66pkvFI/NuLml3Jz2P5yaKbJG+Ulm4QhWRp8260LaTckV4fF2nXgs3vl4Ib RsUhsoYhtiQ1viP7GcZFW0fcJ9v11hq5ByU+DGRGaSDo+Hm2F30Sv8OG7O3QOxT7u52rK7KWSd2Z obLSt7uuqus4tFnQZyYGvujGlBcRkjs5jmsZeidH/27XVrH1g1oKxPQWFYnpe4XqV0TzviylxJwn ncjIPSgEqPekZckPRNYy+NQzpI/n3+cjadWmr9Hwlqf2B56BaJe9fts5X7V9aPSZFa69siYBr+U9 zL8t/OFJMdhMm4668cz9IQR2Jq0L+E3KCIi6TTxEdTsRxWKBzgR7mo0ODp4qV2i5ohsReRHPaxl6 Jj9FjU7FUwHLgFGwwJW57eMO6gEPGUKj1ZcP9TdCG/St5BbBcb9WP5lCoOXEEkuxkieoKuArDalV kshEqbOeiHb4Hkh9NtIfaP5kP0JHWIofPRcTvUEfMemcI0DYsM5Vcx8SXJ8B2CEPFdGiN0c/MzL7 Y/HmsKFd2jZGgJsI39qmqwKDTfrQlr40Ud8Ql/yQQBU/TEa4Hwia+u0/kuVt6nY0XeSWfBySwiXW 9mSlzohPvuqTQv5GUtbXyYEfl4XejAwlGaKDg8Vp9hDIRN6mdXyYsB+TcZaOiAZGz5Oa7iMB2pYg Rwa0X4kag3/dZFTSRXS18PRcDAGLFmHySeF87BBmig8DHzcZueADmktRtxtRx78qKDLt34MSKosD WMpS7Xuhypg2Hmt5CgNuTOsBfvzdzrVVT2xER6X0dPzurvtAPeTZPwgvImC1wkD4kjXjXzjkzaeX abEhNm1b4KxS+lPx86bzukIzB+gAXBqLwLFJ4RlaLz10si+FVIAcwFX4gJtCIJjkvXUqxZG+fXSK FrAVgz1qu7jZuS1UbnZv/mQjPgKjpD8xMoZKAndWNOVsEa8F5U9HYEVS00XUtGtzAODeK1N/Th5w o2O4pHazItG9sXGHogAhmw1KL+ln41vfqmkaITBlpzNUOlFWThuU1ZQVe6XjEhbfmf516YonyeHt 4f1kRUOtB9yNitfQ/7mO9W4lNixzxNgophT64KmOJLJsfbobqrqPvmfLniYtTXMThHtKMo3vPBdl AVA6Ta8J0gDOutt5RxZwdBGsNvn7V2LBCQ835KjBP70WT/Q2i/IovwrHLlGkHQy6BO3JA6OnATTo ak9anWIcI1a8xwhQLTrO6pZCPIfBe7R4vJdSKUPtF1QnTwLiVo7uF6UXPEdOERIJx7aVh/OWLc1g yAh24JOOlTTzUlcg7YUS+SSYfzs5qYHgVF+iQRFW2B6WX2ggO09ZFZJUC8G/N1NYEFeLu6uM5bsx JSLOnTeV7Au45pxvHPz2M2NSt325nbYdfEPTCq/A+2TWJIFs/MSfXzHIs3IqZ+B96D9V3YzhGMu0 qEz+aIKac0EfZ3WA88wsqFIUWdRIkqY1u1A1rghaVKZ+4W7YHzElvVKT/PDvJYMyY29+D2hCBAEe Xpvnn+GgH3CpNbij5D9/YatUJS8wiUJH+vWZpNTS+0g8ijOpVmKfF4C9gHEg679kx0O22EFmheeD sItVMAHhy50wo1A44NhrTOjwtHPlT9mEXJT3bw1Tdgy6/j7emD8KXNMkqzEqJzTyAp0QaMwVaoyF 4iQeSjsOFCd2ClWAx7k1sx3iUgCWAPQC52EjIJUjYWQ9s0p9qOLQUSQIjh9CtolurXZt5bzznaaK H8IcrCso85Dfm+5BIxweem5+3zwFlmRrZvTz/BtDeCQBeiby+NaS7Qexw5hlH/1QpLi79ag7mblg HewEpKlcdgIIln2KUfF1pD3QP0thx3y9mtbin4WrAxJgQtCbNVdsCQBDHqWTBSSCT8tsRrXks2pc cU+on3a+4gIdoeHTRP3eLwM5g93jU4Wry2KmV1QLgNdiOH1uWro3OyKr8W5Y2hI/dDi/tdKaC6+G RkOf3yslX7zAjZW4L6q24NpcUlVYwmse7Q5j1Q2xVgH3HoHOrBzZeK1Kk1oSj/rAaqklmZliZy7s GqXKZ/ACqia3JMXeyizBQOZjD0pVPhpsnYIahnxdmwQAWVJYAPqBQ2+tUEAFhlZlITMcFRTgpe03 01cPRODAYA5rC22/KKZNUeaNpUAgwJCyUI63hE8X9qpGPVzWXzjYEWyeWSs9oVoAwjgxoLOdIQy9 UcfKbHu7IqFGSuYasdAyiQC7ZmMTuyVwWVQzSkJHpUmNSvQFhLdTAEdM9gNr6MJAaq2C6BmofyEI viRUIY0KLFPoVRwsw6NDw2ZhspaUz3e+c2vpWgm9po9a0QIBh+C7oJQGfgr0AdClXSBTjoyMQ3Qd pi7QzCYqM23fpALNX/4/9ZnQk799oD7jpQCz2cWq9U0zbL+ZqiWhbqHEggUYrtRcSVnlpzIbHl7I T1kdyjLPdo54mGzxt6XQ83kpDj1PbUpdS/z8WLWa0A5cvYK8wa2ITCktN1tdq+GnD9VqZlG2dkLS D1Fs6O8yFm2kYYPtnDwMvbLAFTRUzEs8HNDze1XiMTNvYI55kuoOACdoZXSe0B5gF3t4M53c4qdm qlmCjgv5WNvgwsEAELzO1ZqGCCpIB3O1PAeEaBFIznGOImAk0CluQhuRpCx0PWoaGuzwYhVTMrE/ WxxaDfWk28UI5mwhUwGUeZpSxplYi4k0iB9Ky5HdLXEK+eqSmb5BCQbEwnL7kxnzm+1BwFRQMcm+ raFDIxCw8xPKJS8zdUD/Keb1geflp8rfrSeKNVW2qNiNcit+++EiK7tFVWMtq+uGOC6yrtUdp6CD 5CQ0EHQs64lmehFUXWWCHql1mYmuChvMMjSfyPqfdGY83gkckrXOrQjB7gR+kWJAkibnoPv3eZL8 2sWE6xpHvnjsVJD5JIQ9aXioRys9Po79CIZTV7EbXMqXHhJxdeo5u0+hM51DynGWeW/SFoQxGzWL ON5VhAZcXGtLJuDQuzjWp2HfjwENyFiRej+xMZllFopkABcW/Ri5J1GC+6XOX6N1sErLi/7BtD4Y PVXkMszPY73KqjnTaOzQZXCDwCvb0kD/nm1prObZSrTSIRhgvosl+lsSob5LyMZZvVqQG9eJfB7w QvL/dqQjOQPuSO5i6Ug+XRS39Pbg1Btw6mwfdfKYf0I/7x0mcpa9zWDIzDTKiRWE7tG4WQeBoevD RX2wk+844a+AnJXPyBxE379QnuTciaIuhQvdrGdl7G0lS/JP+unp7H2HcnqCYjjNnw40H7LlcKGV admmsGxwYhhmO3fY9iiZwq4NPeoJBNywg118gLVWMJ/dHsuTAJ/+y+wX161RPM0juxndnc+1PuN6 KV/wL9A5k2qVuwCqe1d1wzyPPSndkKZKSRqllol+NGVh5N5OzVilLBoQwDQIYFBtJ3lskzw2vqLI usV9BSF9Y+7wcstxhY3KljW1wC7wkPmCSRF1VyZ7rEUrYQvxSO1ZOrFXyqiGzjPvMADk7HdTlxR4 5lmn5SFI/6xxJDRjDgwyj3uLQtAkswflwWpoaM1q6NqVmrLpampYqJ5n8YNaQNzYF8JAsFUZh+SS Z54EIgke06+EjEzK6aRI/Zh1YUWyO8FuLO0Grh2vo+vkqF7umIGVMmRMvypDrJQpM9Ggs1BmtNwL nN9pcYTLIvaTOvkzj1CpRIEgZQjgD56WDqlSb/RaZNk3m50Xa8nsWev7QhHgvX3dRjyZ0fe4QUGe X5qLa+UQCS3tiwpryCo/Uzlk4/Q+GCTyUBMkNvORdKZPug8ya43lFFFfxVgaC69mxI3XwzaoBdls T7P+FA39DcVtg+eg0ezoNzLGX8n7yzF/25KY3xDLOopJfZJdfr2X6Zcp+0shWDeJ7tizD8njuxTj 9X0dxxRamXVHsjPUsVP9/ddlq7yADxHIu5ZVz8v0jUyXNV/NLgrEfir/pZGhbnKa2zfeoNS1Y5Cr 7ymkPphzeC9p9NPyq/CESzZ/dDCbqiU+J7q/LMEs2/BuWLFdgLglx8Yl/AaTVR/SK9NuP8ECMzS7 8Xu7bH5fYMKyazK0nDdMI2F9tRTbMRvnA0y4sIKHVxZyVFnuyWR2CkOrO0qPx16Mfc3YyzRQH3zh jre6L5Cg7gskMP08fNbXUuST9+9xbVZjAl4VDLSZelOlRTDRZVsZanbWXpgRg4qeAKmtgILEJQQF Uz5hTE4Dll7VLNc0YzlaNAtgNyRychdC86QaOy+qckbG+0VwlNo0l9FR1Fh8NQJ23lcpgbdMb9C2 P6qkFw/l5tqk8XB32axECC48GsuudafE6VFgYbR5mLhCX4diXinqLHWDBMiXpaUYAOpUhCe77Evx COC1Rb0kb9Yq60aYmhpDx5p0O7/YxV8ivYV35vu1ezfYz56HnhQjujdVxYbSmQmoNdCkosJOM886 9fC2a13K8+RHlvnc+HusRTaHH3Z2E3NB7G2WVYbQYkZ3Ft6UzuJ5eLNs2MwEyqp2bQhMGQSlGEfq vttZbkVVmZaBFITET8DfxlYzQSkDWOaefnvsMoNpwkdN2CwuHqx909y9Bae5W97/Xj7K1qSbx5h2 hgkx/tJ/Cycf/isbEKf+B4rIsxb8YN0CbPlE4qyqK9nUiWkr7ZslGmUHAtAJ9W9ZaJ2qA3bWhUNY 9WcaHqsZzHLakDZZXjW3LkLc4QCjMQKG3j9y6/zY3Na+rKYK5NLJbWV+VG6Mh6rME7R6G73K8Ac2 lG35k7QWedeTr3sgUvTW3W+IFFUExQHYPH5K97ytmAmjw4cCwan3qLwn5Wqq2PdTA1q+Mm6GfxI9 vtj1VU3y1+YuJd8P3JvUtHFMS/EkiFMxvNM3zqfaLem4g9JtUKVbN3jCl8xbgrrkOseKc1dFsqCJ t/KQvqINfcqFpKKrq7up5kNmKRJJn+4crUiHO0LdPP2WhzZkbEnI+sYn4sc12xG08sjXZfnRRBH2 InGUNb9LNd3e1X2kkx1Hth8phnVdrGJOTHBq3c/gQcEx+dna9XQDEQO2Nf+0hR3hrqTPSsZyhjky 9uWgKc4u0Bvpb6AQkuprf+ynjIX7ofMLGUEFwypmsLtAIOrD8KFg1rFlM3q/2hAKYGKlvMLrqvLK SgI73zPkat9YtOL7tZ9Pl6ym9gUGDt+YW60n6/Mh2RfvH762awKnO01/loz369ky4rqVZHm5XZWZ gEAADkiivplYlbtvTbrbSIQ8oazKJMH6j5dVmblS9ZGWBeXuHvd83x/8F1y2UwxlbmRzdHJlYW0K ZW5kb2JqCjI5IDAgb2JqCjQ0NDUKZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAzMyAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nKVYS28cNwy+z6+YW2cCrKL345ikQdEggBN34R6M HDbrtddN7HVs59F/X0ojidTOGA0Q+yKTIsXXR3L8pedMyJ7H33LY3nTxL2UkNwIOVijpRX/6xyL5 /qr70nmm4k8Sp+ftTf9y3T0/FaIXEiR0v77sOAshaO3TDdF7x2zvpGZG9uub7nzQo2JBBq4HNq4c M0ZZM0hCFCxY7QXQVsIwwV0Y+nElLagwcjgbOXPcWTGcAJEZofXwV6XdgbQXXothM64MM957PWzx uJvesTKqTI97O7yu4j/wJmr6XC06RBnHOTfDPRjHpHGSqMw0Gwxo/7B+071ed+8hqjGyPxNG3wvB rAsew6hME0bumNdTGP8eVwrcD9KDBSAnLJgKTgXmlTN+2INT4AeH46byv4EQc8LYIyEFiQ/g4MUk ZCEoOzx+Gy0zVktNiZ/HlWbCeEjeIb6qgpEpaklrlK/Ei0osTzlXjbL0/TOIoGDaAfVkFI5JbwJk txJR/QYt2U5O2aCyfUqr5JWEmhfOQ34hLyJoq2OCy92sS+noitBMx1I4VCIk0zKpbMpw1Xo/asa1 klT9NYrfVnHi1Bt8c4OapqDKECixaAWpR6BqLSBZYBS9UNQSsW3VtU11Jz1UgdZQOOsLKJVdteoB TSHHRmm5ejvlz+qQq+LYwBugKmmljbmsd2/xLjHwCo87GiJ0th73lb+QTOBfTiXupYDAW2hqClJQ MmjF3FmtU1MBiEthMzBXJUIroSDKU5j+TBGX8GC0p+AInvaCueBinlPFc1mDN5kWJONQ0aU4c75S bT5U6Dwg9K4ROh8XAUVgVtXbeUUcX0CcLfOJgj0FOgFiubotsVMFEsC/iVEJ0K+b44GUDE1YUYUl RYBKTLleQh9R9VCLmyglkFh+tfG1rSgTdHO1qaiagyYdCVTWsNSOU7EQ+DB8qhaLy9WUqOSBxbgQ 4hm2qpPRMc61o+w1tB/tdZA0AIelRkYswQB+RaG7xSPRWjvdI1q/mIqLYxluA+0IVzQ/0vkJf1Mw I/yUnCK6wYF1i8cLPPaIT0Kd3oRJ3I4hUv+00kpKH5ucLaQfgUsUELWHOj4JsFGIFPXHih+SnhZ0 +fkG4At8Yt5t5ZP0oNI8vGCVaMfEEv6If7MG0VYCqY6vi/ndk5ImShd6exNpMoiq1PdRMg2vanAg oc9wJqUo8Pu3qcTs//cxbqEe6qPJdOU/Zd6c346eo/iqozWiXm1WotppmkUCt4scU5bUa56MmqCR PcXRBJz1P2WZjL+wlDuY2DrYXskYXNcrLngvlQTmrrt81sFG3k/be2SJJAZsAas4NO4kKAIsm/Fz 4Pmp0v3vB1D/c5fNdPnXl1oNrsKHgvKw2tu41k6erpRVjPvYHuA7xGMIckTexj9/69bPzuf90gSb FsZMvJtvwWm4gaYQjD2atMBlXLm0MOaN80eFNAH/LNGJSkC3iETywHxlPEZy1Xo1IQ22s1w0Aj4v Nv8jRHoSefUduvW2VuILDBZZtHHQkDn2qmIyKnWaKeGGc+R7hMKHpr+Wu09sl4loAr1J9gvSwD5V 1BOANkOpyD8mLCkOVtSeQVpai++nswKWzgLc9kQy6HALf1zs2U8tSsVm/CA5UO/Ixl70Z0O1EGW6 kOFvj9wrIzcHg268uWEaXMJcyEMgjdl92WjJd2WZTHRHbrZJgodSrk/NuNk0baDVFHGVIkOUxPbT /MO2GZ0vxhA7ivT0AfINiUW4CE3y/jkqtZXflnvhH+btnnDX8X8NLhgucNV7h2BEsBGEEpnGpHp0 ixCcNlTJQ54xeevKfbTtqmnMwBzQQU9dOh7KHBBckTlg89D4pRlguIfM9ELK/K+NPAPAXEioTzPA H03B991/pUHdW2VuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTQwOQplbmRvYmoKNDAgMCBvYmoK PDwvTGVuZ3RoIDQxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVRNbxMxEL37 V/iGXbFTe2b8xREVISEkaLo3xAFCUkCNQlI48O8Z7252XRGkSiWrSBP7zdd7L3vQDjxqV59TsN4p p1/L91YdVAaqn+Gijdc7/bJXl6usvYeYStb9VjkopTCFAeF1ThB1wgAUdb9TRtv+u/IEzLp/q/qL D6a3DJwZi/lqHeTMLmSzsVLSRxZ8VyBTkrM72zH4kB2aTwvy3kYIkZHNzxGa0UuWkw4++SDQsVI0 R2nk2Jdg1raTEUoJ8dQz5mi+TfVjkFJz/mYBrM+1+tXU7yIgCQ9t0ouhFLoiQ33s39TdCevu8vuZ etWra3XQFNxAv0aXSegqMlzUJP2F1yrG5YpRX+0r+ElyBJcgoWYOkBpBOhkQKGTdeQdREr+cU+q9 0Aa+sMgycokhmf0ixY9WvzlcoA2rwrUX2UkI2swE3tuOQG5jngSsrO0XKrf/EHgGNKfbB71Out4t YSPR8wWrz6atLILsEop5Z30CzBJd2S5BTkxkbhZezs+1eLS5P5kwlglKTH7icAib088jR8Qtcc0y f1m3Mtcc/rY+QmaKBtpdqx8XG44OPN6qRIIR/yGSdE0aS2TxFCd93KjthfK6PgI81KvJWp7zbFxJ dItxaTLuo8A8gp/+4mEmYU9jTEJ943QKUV43fnB6Y/TzDBQUBuX/gIR16kJnGCD001KF56UKEkRJ HJcKMwOPAMf/xQDFDINw7sHLd9j0Wv0BJO817GVuZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoKNTUy CmVuZG9iago1MCAwIG9iago8PC9MZW5ndGggNTEgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJytVdtOHDEMfZ+vyFszlSbETuwkj5QCUlUJla76gvqwYpdL1eWOyufXmZ1NAmwlpAJC Cie+HNvHmVtlDaCy+XdzOF11Vh3K33l320Xj8s940Z5PV+rTrNs5jgrAcEhRzc46a1JK3tFoASoG wyogGcdqtuq06me/uv1Z963L2RyhJZADg8MI6vhwK3z3FhYAClA8fGXhY8uCUzIOM4sT7XtnEibr temHYIgck8YGBJPYR9CuH4AM2JCE+oDsxRb1bg8SURhkcOP+ox+iiWAj6SMxNQTe6++9NcEGBn2T LYO1lvS8H8hQjNHr03VORr0spybmgRCJED3oywr+LuyWNdCeEDXeOtYXxee6prwewURB31efmvIu eyNxIsn+c/ZlM6J3kwBHNKGRADjjZVJfu9nHE72fs0Py7PVTPzgTgB1IlyQmCLbqh2SSlM7SRGuE OUeWLgzeAEVpyHKNQpTYVuJCgLHi0Z31mUxDlA3SsOb+oR4vatRl8WpMZbKC+iDoUR+M9DOxTLaQ vilO80zVJcI82bES4rg96EGeQ0hkx9luSpGqwBvvnlHZ61FG652fmDrv8nC3He97NsSYUtZGpsI+ yXS9EXds01/WRCtBHTJymPo7RnrV3xFtbCd+wuqq3j/krNFFhOZ+Ue9VvZ9vY/3sPgsRE4rYWZQ0 W8jiXrWhSjG77SyKwU0h8LqrAjYCMGNW2R4/yX/YpB0moS7ap+tWObLje6nQspP3TfSZWDkX5c0K +fXcOSZUn6+z8X8tD1nZYFQy/bo7g8f8RkYhJ7VWbmWn5N8P42JVta6LRemLaGit0UZik0JQngc1 LUugRoBPVcvzAr51LTPajPVPn5/pSNTKvpHNxbZlmW8N9VjRtYLoX0nnLy09+im+jY7avX2lMLSp FVhTYKPgRZFVs1hXBWyobFXlYwHPa8xnkQpqCqm1VMdhy+jzp20a/UakGPxaRl6+phuRgiOqInXv IVL5FIkOgaHRqEtCHd2oUY4vFuhb9xdvbLesZW5kc3RyZWFtCmVuZG9iago1MSAwIG9iago3NjIK ZW5kb2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nMVaTXMbxxGtXPEr9paFq7Da+dzZ3BzLSTmlimMa5QvtA0iApCJSoAmRivLr07O7M/0G 2xApp5xIl+V8d0/369c9+LVqG6WrNv5PH5d3i/iXcbp1ij68Mjqo6uyvYvPD9eLXRWhM/DdMx+/L u+rP68WrM6Uq5RpnrK3WV4u26fve6jAMUVXoGl91WjWdr9Z3i/PaLVdt41rbdaGuliunQqOUqn9c 6kYHr3S9gwGXy1VotLGtqh+Xq442D17XD0vVNtp3pn4bx2qnetXVH+KANrjO15+WXaO19Tbu0DV9 UMrV90uSr29JsnrPn7ewAq4GO3+aDuRCT+v9sv7b4tv14gfSV9TZSxQUKqUa3/WB9WNcoZ/WNpN6 viE92Na5vr6hQ4ZA34HOSwsoEodOqGxjTdfTAX3jvPFRYcNAH3wUt2+CCVoNMk6tV9xaUau1qiN9 fODPGx67m7Yq1trkxkce+YH7b3L/Ljaa3mlbv8+NMJIEsI1ywbuoYdPQ7j6k9Uloeeg+L/UeZc3n v4uzeme8n5RhrFGThnQfVTmcyts+bWXstNQwErY6jKfyvcFVx71029cXeT7sBKf+ONyfLfvhcxJA hfpPfP7Rql6duR4tRXWNo9NXK2Wa6FvbRf2H5fqfxwblaD/TRnuiEeeDxXsy406jsvbyteb+R7ws TWihwguuNQuQ7DJo4VpPDPXza1XhhCpWScjfrIv1kjYNttf1G5b6RzpLo/oRKPIJP2YXBLuQvQVm 3XMr6PXA2oBP3gG89GG58oQ4JEm9BXXkDX6ueQBr9mkZVdL3Lm1bGPSAb0kE6GcrvuXr2OXGn5ek LTJiXQJK6n446u1onzVBedP1jvDyTR4Y9asa21lf6lfpxgdrSv0eo4kpLuWS/XLH3jzpzNMFFybm Kdwp3SHyFcgTbYwCSOONSrbCwABH2UlHoYuI8msbUKVPfEBeCoy9uIjUf8HzoR/ggoEHgGnP/XvW xXu8vtFSbIKWle5M0xqL/lNF/5kiWfxPsb4ztFvvK2NaWqqrdCD9aNJk9bBbXH21oEBfjaQgdo2E groNBXhCynEicYcusoxXZ15Vr/e0/MsG63Hwfx9RLS2vbWV6S4QiBtVR0pWxim7VkApIe6wBUggd bv0m/vnHrI//MUGKZzMyQYqMRBuiHj8tKSB0lnzpLbQeYDTylwumOG+ZA51iOye40+/BdYwm5wmj qBMo64LsJAYShbeO7qyz9XejG5DJ13+PR6U2Y2qdUfAfDDQGI904352A2WsRsjnAgff+e+AS5PMY CgHR4150h663gM0FWZn6HQLR2ShLDATfk9pbusb6dSYQBXrm6eD8wGAKyMhinyAjCSfejee3pFXY AGjPoxQmylhOoviWuMKKkXiL8CfwKoByGHCPUBgNz6ieDDvjM1wGIx3gL4SCT0vlm8GsQKyPrGsh kr3jM8FJb0SgvYeggLc6HM8X11ItdRcGAE7SMACf13/J5r9j87/gz2SqxiXeHVs3oi1PMtshKHsV WwM5SB7aip99YaGO/NV1Be15Lw4ACvUpO8YeXSj7CMwaD04uosDHtsUG6eBMkDACQ7fAIG7FT9gf DHtz7AMjrxC22mBjWukezW6yIJ59YLfaSeEZHAjst3CrgZ90IWZ6yf5lvy/Uy6wi78qm/ihuBfML hpsXEJUCax1O6C+tCscu0tCVjbE/oFufZbQawVCrvkDDPkYoHcCpkopWUxCfcGK4+zbnP9FpKg4g H/iziDrS2J84QQBLG+9c9QVr5QwKHLQwxKzeUTzX++TsU6aQiDzn4LxTwfOFxHoPcwAIk3M2w+5t MIkRTjD0/6U92rlGj1TAy2Whb6ICHbVqkjA29WHM3CducwnTbpnnPPKII4KURkAJaFououjvQ3nI Z5p+khPM8yyDHBvE64nduDI3XWlN2RURtXO+cZdv/JecJMDIIvYmM4j9xtEROzAyOV0tAkqaBBix LzBe2PUuqlV7SrMwN56lOUNrUcARCjQlYqXTiLWcLaJQGnkPET97B0DTk0hJtjPSZAvAA7k3BSSn ba+RP0ifW5w2kB5KvJjzyDkfqPARgopcOIOgIeiluM9CgkmunbRAgirfZ9Qb+BcZjFPFFcpb3aBe Ja40KgGp0giE2nXZ7oJPVQyL7OiQy6KpkNU5oBs7tPXkFSWPLyPXvIB6xGeOuRGEDHZrcOaiTpSO dYmUYWjUxVnA7Y3g9o14Pi553cwMuQzSIrcG45MZS0m40gIbiecURT9NSU1M32QaM8OtWMCF/gO6 6ljH0Y1qQ/IZgJJ78azP0LxTUJL2v5TqPLIoF0ijpAFbBAVeSyZfaRIndbPypCW3RfJ2gv2BsWQm NSkRfW6eCNosvVFInlIdkD7nJNsW+cB9boQAMqP7BfVpuMoI5cjv2LqOosNUvZ4nn6ODQ8WWjyIX bBNAgPle5EnzymlZXZ+Ts/EeU+Mp/4Li5pRayPIVSZCQnN8UJnf0lDMexUTiExQ4WnF94D2poHo7 uRwRHp1dDg7Fby5i6JHrsdeSmUKgPpUlPR/mplMVmWfW71a6ledu7YpX5f5bsczL/eyyxU4vDohJ 3+idkLA85Zi358ZbJpoQHiH5ASZapO5gykeS2uNIKIoihFpwOigo7PAzY8E2L5AchDZo0AOOns1y JrP+6rz+umDNCZSgPPgmIRmMhEIbx0zAF36ThQePc+4PEJKP1ROHwpMYa7KIU4ApyXr4EUOsTQqY 0IU5n5se/+SENN8v+zc4VVEZOYaSKNaM6dhuTnSGSQw6lyfKBUmAb3n+v3joveRpQhVvh/CR36jG YgqxUOWhmCgUJsGin6twXIlDk3bNlyCKVEwqUpOEqADzDF3zq+GX3ePWg7TU3A5HNUdBvLInAGlS JwLShlGGf5sAfCHX9Q/cJgdm2YqLAfBY+PmfLnAQL+4BSqiJZogYBJteIbXgeJi+iswC6uo4/7P7 w1DJs6D7a8YrvjKZ7MJFc2j+bfEU/KCAYyBn0TaGetIRFMONv6AQlzJKuEWoJQAanqpTHz8al8AL Q6G/SKqFHLHIYACPpW2LcJls5tlf3nyOr2pKoJnvwfXAAwbkSkwR+f1HeMgW39zFXPCdCJIygxEf 0iu0swGQXdfALzWOa7/5IcwHd+JnBKcwXEpVofVJgvNZzXRUZJ50LeVU8CQkUsmDxIVndvbltDaD 8KRCBOErJj3ABbl68mL3Q0GKop7MWuaZ0Ow3WacJDLj0C38oJDscETTZ4TZSZGDk5eUhY3+UgK9k XWmlLyFC+XPOhOwRz82SAJKyHWxF654FmQklRg4Unchw1ib9fm6DNpc/RacA2iX8vA6KhFjbkGgV qHL6bQ0t+n3sJ56hNQQ58T0te8RQt/9h8R+iy9tLZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iagoy NTMzCmVuZG9iago2NiAwIG9iago8PC9MZW5ndGggNjcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJzNWktzFEcSvs+v6NtOR2hK9X5wwzaBTbDhNSi8B9uxoReItYSwQCAue9tfsPuD N6u7qjJ7JnskEWO0EBA91fXM/PLLR/UfnRRKdzL/rQ/HFwvZPYV/rxd/LKIw+c/wgj4fX3TfHCz2 X8ROKeFDit3Bq4UUKSVr3NBDdTEI3wXthPHdwcXil+X7fmVEUN6o5WUP45S3y+t+lYRJLvrlVW+F tNqF5TF2PK0d93oprFVBuWWXx0QTdX4tRYzWw/BDfCwLOR+Xn3svnLfawqg2wQd8vMRRZNprOled gKw12Ux7fNWvNIhRRbU8h1FKKx3oqJthKueWb/qVssIaaDsq5/MwpDWetkYy+6/LQT4queVJEVrb lLEgqle4f1jACgVCdcu341zG0sYPvZIiaOXpVi5bz7c4abcuqvWlSIcLeDTaax/oWsfDqXVKRcFG V6GruFz1vx08W2jrRTAJUHNwQnCSDD1eG/0RX0+WIYPqQchMv/Z1PI8kciQUBNHJOS5FBPGpV1r4 aE3BST4mmZQA7QwHnbLiJa3khGQtsoNrbCVLvGG3OKfMekaC2q7XIWaFrKpGVsrAiFEt40oaZiqH sdJFNNBy7ABth/h6w6izUZ41fBP4fVgXxWAzx838PrDmedWMYs48Oa4ga5FtCWJsfZtX9Jyt19NG A49ZZE8OFj8tMo0ap6VT8OCV0VF1L56yzVd3oVelOuWEM1kFlV91pPzqoxHajvz6OFt1UjIs32VL TBKWgsdVgJmj1yCAVRSgPzmConQ4wUfQhhTaqaQCkFXrDLDQIhnQ5uNee6DzpJeP8rQyujDwZhv1 H9BnENHFAH2NAFA5VXajnPN0Y5PdRABgipbZjI5e5c1I4aQBGNflhvaDHsQTbRoYL4gUtUyDcr01 Ngz22/qekjn+C5iHdVKKU+3tzO1570E6o1r+3WvYYxjsL69VTOr5An7/ZfzvocADeHF63OWLpq4i KBtCBHIYZCnlBD1XcCJnorQzkDomM9DZ3pdnF9OfJHeXqjnAAgf/HIeAq7P5mG2ImgyJ+YijEH4B +IKwrU1LlSESZASI/NaDqasUMvSA7gFOEcTlAeYaeEngmK52/B7anLAJfP0hYNt6p0eUj0+Z9YQF ggxZJDrzk8tU1x7Phq4WZtqjsxd2BtVKeqqQz6xCdZ8vshswJfhohyALXWLrda+S8CZZ0Ck0au2V ohs5bXvucCN/7VdOSG8Mef0BXx/i9CftPWksXV2kwumw8dUo5ez7mM2RjmSiM5x+Y8v5/c99gHjH qEBlT2YlU13jVIdtA+fDnrwb6D4rOcLpfxz8bTLSQRi3LuigyU6u4CnZKGN27eUtL5FLMqbt7nPv pBRSqlH7E0hrDRZhfVX+XttdhkvIeKfeCSgkShkas+DvO1HK7cbkgQ4K751tHDCjgzy+a2d9hI37 7OOnZm7lCVwQPhETJOr9yCIeISeqNQdimiyiyUa+Q+Mikx73WVoQ/gF66viL0UpUstQM307mL8u/ zzhzEl6Tlc7xJCNUFKCXIGVi23m8UrpOamCiioMXTUxot6J2O2sIJzNftH7n4Pl1w08wsrMhDwid ihqSu+7qdPHqfvw9ix8jIeTUBEEjg680LKit6/KOIUUdUE54Wj88T+eue8zsU3mvv+WRRLTOouZ9 Q9rvQ+gs8/jPDT+TbRDChmxUae0o5sn75w1fCP9LbnUikBmiWfdNKjqhfaOnbebjIXfaMJ/BycxY T4ErofmXjeabIVC9Er/E8AEh3BMi78rXyPuo10Nua6TxNXVL1dJmTkbIsi70iD3kU3Q71xPNFAd1 wpDZOczpk1STjm/p7rgDQ7xRvc6qKjKPzgWdrE32+ES2BGJ/y2mWdUo2OTtriLebxBxM/HDNqem0 h5yC8YkBIlEvVQVdM7k9iv6v5BYVZAIJaM0a0fwi42Jud4vlDPt4hk+9Av3ooP58p8iAc79a2MSm K8iPG4wmJq08ZAvBEbyxJo0g3MdGxDAfOk0cYiUU8h5d4m0s9BLBSsYjGKdgzvmclIY9vKAhKh4U NqKV9CCRofzlIJVGjpw6XQWZcwdr2ex1tfJ6t17XDgk9wrM4XWMgYHVmYu3E6ZptTjeQaPtHgGOK Slkq03cUeEwMdcp71ZL9fA2bdTan6M6oIVMfjZYGSuWc9zLaL7PFMmrGFjdX+g4jGpZceQfLuMiJ NVbDQBMiCdHhxIIHSqDuhFriWmg6g5OMde00kekEJpheVZWQcJYhk7lwVoEKO2uHigLEs07uOJ4N fgqiGs/GBE7VzZmWvb9pHWTTchH45El7+23zA98j2T2YOZkcuTtQl+Ryw3LKiTW1148Yx0fMiZgD W8sghvWxEcwla0OnnL2UjSY9cahslk6Cvf2N3BvE7ztrZMxgiwCInWJNZ8IiAi5Qy7FHTLNQc9uh 9mb0tyGRJApBR4gGo+6HAphVIoETGzNIhq+5IItHGMn4t0ZZtU1QeXGVJYK1k/UAJWORTDCDqhLj jjAC3gSfDQcFGIUYdwwj43M9GOVYcWSRsrTdwJHfjqPHDR4luTVmpkhIJEg80R7O+RUhBQEQHNUm MKxbOKsc884RADn6Ro3nTgIhRHTdCsWrVmIkpQoCeAKpQ4rD1veorfqaRCBl+60mS6ZhSE6BLK2S Q6yavOn8bkkux6ioEUJyep7kwgw4y+vRd4aUFOE2Et+jH0UYHwwhSnD2obDpVE4pbRwLYrvEJqW4 FjawbMejjEALa94Er0fce1KSmPJiuyVgcrQW86Hb/53LGv/Va5FviRKJA4+4MBHD0kk5vi39jtsF E/tyvh+SO0gR5RBoOrXrwqkBu7AEDjXQtJDaxTnSjttJm5jA83ZGNIGX1BhK8PlDnebb/5eI03rY 0a4jTrQlnr0RwmT6N612QWJLYhdzt3NMQMDlyeTKbHtgetrT5HIYsuXuYzQLNpQ1MNsAZ2XDjoOQ BK880V2FszQirzzD8wkD9Vbv+2F73vR4Ere2wuDXDDLyZzCddaFdw39hcXDLndmkKPil5UESexTZ ssXjSUWCylHJZCAjTm6IW0PaMWS0zVf4KMcaGpiQP2yagwy54pfbowRSvMLrtG8eHj7526jOWpdR tOva8hpkZpIeQlwblyZrl2UEcTMlfpI/E2asdEcY7Yh2rW57crPB3EaQRW/ahWmjQZTMGevzcR16 /YOBeuV3Yhf/oAXjWtQ6JGE22do0yQO3DeGFGQtTxu04XnB+INgGm0qwwLhGmbmAgVjL3Lcxpecz 1PkkHiQOaest44NVEcKQ8hmdo+vt5tTi6hp7EsjfEj/QesL2EJsAelJQYLC9ETePVartwidRMovf E47ib7i7DWInE+up0ml3Rc9I5HwPZEysQ+sAGE5j2dZZvdss04D6dSQoaNG0zVq9gy+Z+yKh9HyM vuSmaY1NgcggzX2Hha7oCc5JI3NwhylnPg/ln4ITOlerspfaUXRT5In28p51MIcshyP3blZ4Z6Lj 2yu9XJp602C++QkJWI7mTFBxjkNxPSc34NvvPFfYFT069vzCixPrZWdsHBOAAE5ktxYY1ZC8NdxU C8wOMYY7+Ke568nS82e0ltvvJ9kPFLDo1sSLDEq+v5yUy2sjWijJt3EhLE7cp5CHWSHp2rG+4G3b fjeJnQpMZ7ZfwUPkBFySVafd8u8wexSQdQciByzHYNseoutrf59oQNQBYCVhIHtJMBgCft8wqQgw VaLm0/g8a82fm7tcD2x+g0N4iLncmvDQF4XBSATMsZEU3rGER3Pq9knSNjvSdnp/65wDHYUGAO2l BwcchyxRebnjyoKTbsiXGgIKsVjQlUo0TRxflJ/0Q/1CPRvf7v+0+B9UpUpUZW5kc3RyZWFtCmVu ZG9iago2NyAwIG9iagoyODg2CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvSW1hZ2VDIC9UZXh0XQovWE9iamVjdCAxMiAwIFIKL0ZvbnQgMTMgMCBSCj4+Ci9Db250 ZW50cyA1IDAgUgo+PgplbmRvYmoKMTQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRm9udCAxOCAwIFIKPj4KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoKMTkgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUMgL0ltYWdlSSAvVGV4dF0KL0Nv bG9yU3BhY2UgMjQgMCBSCi9YT2JqZWN0IDI1IDAgUgovRm9udCAyNiAwIFIKPj4KL0NvbnRlbnRz IDIwIDAgUgo+PgplbmRvYmoKMjcgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRm9udCAzMCAwIFIKPj4KL0NvbnRlbnRzIDI4IDAgUgo+PgplbmRvYmoKMzEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL0ltYWdlQyAvVGV4dF0KL1hPYmpl Y3QgMzcgMCBSCi9Gb250IDM4IDAgUgo+PgovQ29udGVudHMgMzIgMCBSCj4+CmVuZG9iagozOSAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvSW1hZ2VDIC9UZXh0XQov WE9iamVjdCA0NyAwIFIKL0ZvbnQgNDggMCBSCj4+Ci9Db250ZW50cyA0MCAwIFIKPj4KZW5kb2Jq CjQ5IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VDIC9UZXh0XQovWE9i amVjdCA1NCAwIFIKL0ZvbnQgNTUgMCBSCj4+Ci9Db250ZW50cyA1MCAwIFIKPj4KZW5kb2JqCjU2 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VCIC9JbWFnZUMgL1RleHRd Ci9YT2JqZWN0IDYzIDAgUgovRm9udCA2NCAwIFIKPj4KL0NvbnRlbnRzIDU3IDAgUgo+PgplbmRv YmoKNjUgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA2OCAw IFIKPj4KL0NvbnRlbnRzIDY2IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMg L0tpZHMgWwo0IDAgUgoxNCAwIFIKMTkgMCBSCjI3IDAgUgozMSAwIFIKMzkgMCBSCjQ5IDAgUgo1 NiAwIFIKNjUgMCBSCl0gL0NvdW50IDkKL1JvdGF0ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlw ZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDczIDAgUgo+PgplbmRvYmoKMTIgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNyAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggMzAwCi9IZWlnaHQgMTY5Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9EQ1REZWNvZGUvTGVuZ3RoIDc2NzI+PnN0cmVhbQr/2P/uAA5BZG9iZQBkAAAAAAH/ 2wBDAA4KCw0LCQ4NDA0QDw4RFiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIySGJJTlZYXV5d OEVmbWVabFNbXVn/2wBDAQ8QEBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVn/wAARCACpASwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEA AAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJx FDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJ ytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQF BgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3 eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0miiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKY7rGheRlVR1LHAFZz6/pwYrHObhh2t42l/9BBFAGpRWT/bYP3dO1Fh/1wx/MilG uW6/663vYR6vbPj9AaANWiqdpqVle8Wt1FK3dVYbh9R1FXKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqKaeK3QvPKkSD+J2Cj9aw7rxloluSq3Ru XH8Nuhf9Rx+tAHQ0Vwtz8QQCVtdOb2NxMqfoMmqM3i3X54nljSCCNQSTHbSPtHrk8U7MV0ejEhQS TgDkk1iy6vNeEppSI0XQ3cudn/AB1f68D3NYejWuraxD9p1e9lls5ACluVCCQerAfw+3fvXSrBgA ZAA4AApDKA02GRxJes99L1DTnKj6J90flV9flUKuAB0AGBThEP736Uoj9xQACnrSbT6UooAiubG1 vAPtNvFKR0Zh8w+h6ioBb31iM2U5uoh/y73L5bH+zJ1/Bs/UVfFPFAENjqMN7vRd0U8f+sgkGHT6 j09xwau1m6hpyXyhlke3ukB8q4j4dP8AEeoPFceNQ8S2F3JaT6jG0sS7v3tuCHXswIwSD+h4ppX2 E3bc9CorhIfF+rxf6+wtLgesMpjP5NmtKLxraJgX9le2Z/vNHvX81zQ4tApJnU0VnWOuaXqOPsd/ BKx/hDgN+R5rRpDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAoopjusaM7sFVRksxwBQA+mS SJCjSSuqIoyWY4ArnZ/Ekt6Xi0C3W5C8PeTHZbx/j/F9BWBeT6O0m/XdVn1qdTkW9uCIVPsBx+JN AG5eeNdOjlNvp0c+qXP9y2Ukf99f4Zqmz+MtX+7HBpEB9wZMfXn+QrO/4TP7LF5Ok6Tb2kQ6bz/7 KuP51nz+KdauTg3vlA9oY1X9Tk1SgyeZHQR+AluJBLqupXF3J3PX9Wz/ACFaUfhnw/YqPOijbHe4 lJH5E4/SvPZry7uCfPu7mUejzMR+WahCJjJjQnPdQarkfcnnR6lHeeHrHiKfTYMdkZAf0qldXUHi G7W2t5Vl0y3Ie4ZTlZn6rH9B94/gK88yqKSIxnsF4yfSvQ9Hsxp2mQ2+MyAbpD6ueSf6fQVMo2Kj K5reYO1JvqHn2FOB9P1qSiTNOBqMcdc59O9OHPpj17UASKaeMHr+dRZ7U/P/ANegB2KcKaDTqAHA 1m67pUeqWynykkuIDviDHAb1Un0PT24PatDNLmgDm4fDen39olzZTXNtvH3C28Ke4IbPIPHXtVa7 8PanGSUMN2g6bP3bj8DwfzFbtsfsetywdIb1TMg9JFwHH4jafzrXqlNolwTPMJrS3e6ZNQtAjkEh Zk2sfoe/4GpLdr/T1B0/U7mJRyI5T5sePo3I/A16LcW0F1CYriJJYz1V1BFc1qPhl4UZ9MYun/Pt I3/oLHp9Dx7irUov4kQ4yXwsrW3i6+tgo1PTxMh/5a2ZyfxQ8/rXRaXrmnasP9CukkcdYz8rr9VP NcQ7bmPDLsO0qwwVI7EdjUb2cFxmSWP94n3ZFJV1PsRzTdLsJVe56bRXn9jrmr6YQrP/AGnbD+CQ hZlHs3Rvx5rrdJ1yx1dG+yykSp9+GQbZE+oP/wCqsnFrc1Uk9jTooopDCiiigAooooAKKKKACiis LxL4hh0K0HAlu5c+TDnr/tH0AoAn17X7LQbXzruTLt/q4l+859h6e9ec6n4judXkD3SB4gcpakkQ r7tjlz+QrIup5r68e7vJWnuH6segHoB2FNzWih3M3PsWru8ur0KtzM0iL92PhY1Hso4FQgcDp+dN q7p91b2sm64sY7xfR2ZcflxWm2xG4t3YyWkVq8hGLiISr7Ak8f59agVTnt+ddh4k1jTnsdPH9mwz mSAOm5ivlKeMcc9v0rD0jQNQ1hvNt4Vhtj0mkyFx/s92/l70lLTUfLroZgVvQ0oOSqLln/uqCx/I V6FYeCdNtwDdtJeSd952p/3yP65roba0t7RNltBFCnpGgUfpUup2Godzy/TdMujqlgLi0niiaXdm RCobaC2OeewrvfmPtnPtTNWJbXbFR0SCV/1QUKMbMkfnWbdzRKxIMcc5yKcCT0HXqBUYI29zg08E k+xpDJBxwTz2pQSen4imAdj1HQU4EkcdaAJAQBxzTh79OxqMcc9+4pwJPT8qAJAcntTgeajyBx29 adn86AHn1pM0A8fWm5oApaufLitrroba4Ryf9ljsb9GrZrF1v5tEvh38liPqBmthTlQfUUAOoooo A5zxPp37htSt1xNCuZQB/rIx1z7jqD9RWBmNoV6KW5z2ru7x4orKeScgRLGxfPpjmvOowywQo4IZ Y1BB9cVvSfQwqrqWEjYSLnp61XuLdJ5RNl4p0OY5o22uv0P9K0NMaJZgbhnCbgOADnnv7U69jtmv ZBas33yCGAAznt7Vo9dGZrTVFrS/E8tq8dtrhXa2BHeqMK3s4/hPv0rrgQwBByD3rz64VXLxuoZS NpVuQRU2j6tJ4faOC5dpNKfhWbJa1PofVP5VjOnbVG0Kl9Gd7RTVYOoZSGU8gjoadWRqFFFFABRR RQBS1bUYdK02e9uD8kS5wOrHsB9TXjd/ez6jfS3l02ZpTkjso7KPYV1HxG1MzajBpqH93bqJpB6u fuj8Bz+NcfWkF1Im+g4U4A4puQPSpriCS2k8uYYbargezAEfzrQzG46cin4HHI/Ko/4RTv4RTEdN 4Q0iPWL5nuz5ttZquIz0YnJAPsOTjvkV6UAFAAGAOABXm/gXUkstVkt5mCx3gVVJ6BxnA/EE/iK9 KrCe5tHYKKKKkowdYQrrVlKfuPDLFn/a+VgPyDflSDAVeR+Fat/Zx31q0MmVyQyuvVGHRh7isJnk tHW31DEchOElA/dy/T0P+yfwzQBbGNxGDz604MWXHp2FMyAQcHPvTt2Gx2/pQA/tkn607djleKYo IOGwAeKcpA4x+JoAkHHPQUucdOhqNckkHNOUgcd/60ASDjr0pRknBP41GvPX86bNcQwpmWVIgO7s FoAsA5OaGPQ1QGoxycWsM90T1MUZ2/8AfRwv6012nlH+mXlvp0XdUkBkP/AjwPwB+tAC37faydNh +aWYYlI6RRnqT6EjgDv9BW50rEi1XQ9NiEUN1DhiTiMmRnPckjJJ96guPFUKbfs9lcy7skM4Ea4/ Hn9KaTewm0tzo6qX2oWunxCS7mWMHhQeSx9AOp/CuU/t/Ur+by/Mjs4sEnyRubH+83H5Cqum25uL h2eaPzXOGe4clzj0J5q1TfUh1F0J9T1iXVpNmxoLJDu8tvvSEdC3oPb8/SqIl3f6wbvfvW3remxQ sXjnhj3Ko2M2CcDHArCWNt4DD8a2ha2hjO99Sd4/3ahDnuR3psX3ix/h5qNnJkLDI9KlaaMRqkhA lk6BRlm/AcmqIFVw/wAr/ge9VtUuFt/3W0TSy/JHF/f+voPU0+RZ4Ww6mF8ZEeAZSPXb0Qe7fkaS zt1jmMkgDSP1brgemT1+v8hxSvfYq1tzU8I38mnTpod3JvRl3Wsp9erR/h1HtXa15tqMEkkXmW7Y niYTQuOzLyP8K7zSb5NT0u2vY+FnjDY9D3H4GueceVnRCXMi7RRRUFhRRRQB4lrtwbrxBqUxOd1w yj6Kdo/lVMdP0qbU0MesahGw5W6lH/jxqFelbR2MXuTW1xJazLLFs3r03oGH5GtbXdal1eVcrGsS xqP9WobcAM89cZzxWKOPqeaXPIaqsFx4C7Tz+lPG3b/F1pi/eK/hSr0b6UyR/wAhjPDdR3rsvD/j Iwqttqpd41AC3OMkf74/r+frWd4U0T7depLNJbmAAkx+aC54P8PbrWXfabJpsjxyTW8p6AxShj17 jqKh2ehSutT12CeK5iWWCRJY25V0OQfxqWvGtOvbqwm32dxJbk5JCH5W47g8Gun0/wAdXKbUv7RZ h08yE7W/FTx+tQ4NFqaZ31RyxRzRtHKiyRsMMrDINY1p4s0e5IU3Qt36bZ12fqeP1rZiminTfDIk iH+JGBFQWZMuiNFzYXLRKOkMoLx/h3X8Dj2qvI19b48+xcgcF7Y+YPy4b9DXRUUAc0moWsrhftCL J3ST5G/JsGrnGA33s9x0rVmhinTZNEki+jqCKoNoWmk7kthCfWFmj/8AQSKAIiS2P5e9O4xk9e4p f7FVf9VfX0Y9PMDf+hA0z+ybtfuam5H+3Ah/ligB+ScEVQfRdKabzm0+3aUnJfbzmrn9naiBgX9u frbH+j0n2DUx/wAvdmfrA3/xdAEP9laeDzZwse25c/zqaOys4gfLtLdDjOViUUosNTyCby0/8B2/ +LoOnaiVIOpRLkYyltyPzY0Acprl39r1fy4z+6tR5S46bz94/hwPzpi3G0MsnzRv8oz2x3rei8Hx IiK+oXTBOhCoD+ePxqceEtOHMst3IB/emI/litlNJWMZQbdzm9ix275yjudo7jA70yV44pFMk0QJ XB+Yde9dHNZ+F7PH2g2pK9FllMhH4Emm/wBu6RZoWsLBnAON0UAjGfqcU/aN7IXs7bswriS51O48 yG1uZsKqgrEccD1OBV600XV2U7oIYFI6zSZIH0XP86fL4ov7htsEUFqp6FsyN/QfzrMv3ublv9Lu ZrlPRmwmf90YFC535CfIvMtvaaZBJsn1Ca+n/wCeFkAq/Qtnj8WFQNeSR7orKCLTYjwfJ+aVvrIe fy/OoIgIosqAvZQBgVYtbh0lVlYq46OOoquTvqJz7aFmOxMGjCcRNh5TuGDnGPve/Peq23ahcHIP ANbEutXI0wFZB9oMpXdtH3cdayJbh3k/esXJ+8TTjfqTK3QIWwp3dDx+NbHgVyumXloeltdyIo/2 Thh/M1jSLt2qOQea1/A4Ji1aT+Fr1lB+iqKirsXS3OqooorA6AooooA8n8aaXND4rm8iGSQXaCZV RSxyOG6fTP41kJpeoZ/48Lvn/pi3+FeqeJbCe4tYryxz9vsW82EDjeP4k/EcVBY6l9vs4rmCZzHI M4LHKnuD7jpVqVlYlxueaf2ZqHX7Bdev+pb/AAp40q/wf9Busdv3Lf4V6h50v/PV/wDvo0edL/z1 f/vo0+cXIeY/2deghv7Puz9Ym/wp66dfB8f2fcYPfyWr0vzpf+er/wDfRo86X/nq/wD30aOcOQ8+ 0uPUtPvkuY9PuN6BgP3LDqCKgj0+9+bOnXHIPPlMK9I86X/nq/8A30aPOl/56v8A99GjnDkPOY9O u8n/AEC7Xg/8sm9PpTotLuzIv+i3I5/ihYf0r0Tzpf8Anq//AH0aPOl/56v/AN9Gj2guQ86bS9QH Jsrgg+kZNPGnXkVwGjs7pNuBmONlP5ivQvOl/wCer/8AfRo86X/nq/8A30aPaeQcnmctZXGqWU5F 1PqgtmP+sAL+Vj13A/L79R9K30utQADRaikqHkGSFWBHrlSKtedL/wA9X/76NZz2TRSNLZOsTMct E2TE59cDlT7j8Qahu5aVi5/aGqq2P9Ck/wCAuv8AU1J/aepKfmtLRvpcMP8A2Ss5tQ8rAvIntT0L H5oz/wACH9cVajZZo1eN0df7ykEfpSGTnVr4f8w6I/S5/wDsaUarfYz/AGamPX7SP8KjyNvAyR60 4BmUnnjvQA7+1b//AKB0Qz63X/2NDajqX/PpaLn1nY/+yVUl1C1g+RplMvZF+dz9FGTURkvLrAjQ 2cXd5AGkI9l6D6nP0oAffaxqtv8Au4Y7SW5YfJBGrufqTxtX3/Kqd1qXiLH7vAI4by7Q9fbJORWl axLaKwhLgucu5YlnPqT3NT+dL/z1f/vo000ugmm+pzc02uyW4aW41DzGPSOPYAPwFQiwup4vMuIb qZ14ImLvkeuD37V1XnS/89X/AO+jR50v/PV/++jVqaXQjkfc5e3s5V+T7DLH5gO4pERgdv8AGn3N jciONY4JmH3j+7PX0rpfOl/56v8A99Gjzpf+ej/maftfIXsvM5SKzulyxtZ8joPLPWiO1vA3FtPz 1zGcV1fnS/8APV/++jR50v8Az1f/AL6NHtfIXsvM5qSznk4S2mXb22HBpos7pI/+PabJ/wBg9K6f zpf+er/99Gjzpf8Ano/5mn7XyD2Xmc3DbXK/ftpio7eWetH2K5D5+zzEdf8AVmuk86X/AJ6v/wB9 Gjzpf+ej/maPa+QeyXc5mUS2tvNcXEMqxRKXJZCMYrpfCVk9l4dtVlGJpQZpP95zn+oFZdz5muav HpQdntLcrNenOQccpH+J5PtXXVEp8xcYcotFFFQWFFFFABXJ6tZyaHeS6naRtJYTnddwIMmNv+eq j+Y/GuspOtAGBDLHPCksLrJG4yrLyCKdVO90e50mZ7vRY/NtnO6awzjnu0fofboafYX9tqEJktnJ 2nDoww6H0YdjQBZooooAWq1vNeXUCTQ6bM0TjKt5sYyPXrVkdat+H/8AkA2P/XJaAMaTUDFaSTtb SZikMcke5cpg4JznGB61YH28jI0yYj/rtH/8VTbfBlvgRkG6kyD+FT6XcGxnSwlP+jv/AMezn+E/ 88yf1Htx2oAjt51ni3qGUglWRuGRh1B96kqTVrR4ZTqFshY4AuIlHMij+If7Q/UcelRI6yRq8bBk YAqw6EetAC1As000ki2lpJcrG21nV1Ubu4GSMkd6VxLc3AsrVisjDdLIP+WSev8AvHoB+PatWaS2 0fTlCIRHGAkca8lmPRR6k/8A1zQBjPdXEN1DBNYyxtNnH7xGwB1JwelQzW9lNcNHFYm4uR94QIFK n/abgA/jmnzedDaXl7MwN40TMSOQmASqj2H6nmuh062jtLKGGFcKFBJ7sT1J9SaAObGl3A+7p1+o 9BfD/wCLoOlSt/rNIuZf+ut0rj8i9XBfX19mWK5FrBuYIqRhmIBIyxbI7dAPxozf/wDQUm/79R// ABNADIbe7gXbBo7RL6I8Sj9DRJPNbjddWVxAnd8B1H12kkU/dqA6anLn/ahjI/QCtLSbyS8tnMyq JYpGicp90kdx9RjigCgjrIiujBkYZBU5BHrS1EYlttWvIIgFiISYKOilt2cfXbn6mnTzJbwtLISF X0GST2A9SemPegBJ7iODZv3FnOERAWZz6ADrQF1BhldNcD/bmQH8uau6TYvFuu7pR9rlGNvXyk7I P5k9z+FQT6xcGd2s4EmtYTtc87pCPvBO3Hv1PHvQBXS4/f8AkTRSW85BISQD5gP7pBINTVoTw22r 6epV90bgPFKnVD2YehH/ANY1kwSSb3t7kBbqHAcAcMOzj2P6HigCaiiigAoopaAErPv72b7Qmn6c ol1CYZAP3YV/vv6ew70xr241Kd7PRAsjqcS3bcxQ/T+83t+db+kaRb6TAyxFpJpDulnk5eRvUn+n agB2jaXDpNiLeIl3Yl5ZW+9I56sa0KKKACiiigAooooAKKKKACsbVfD9vfzfaoJHs79RhbmHqfZh 0YfWtmigDjZb690k7NbtsRdBe26loj/vDqv8q0YZY54llhkSSNujoQQa3yAwIIyDxg1g3fha1MrX GmTSaZcNyTB/q2P+0h4P6UAPHWrfh/8A5ANj/wBclrCkfWtN/wCP6wF9CP8AlvY8tj3jPP5VFpGs sYI7O01Oz3RDYI5rdlkGOxBYfpQBftv9de/9fcn8xUk8KXELRSZ2t3HBB7EehHXNMtoZIVk851eS SRpGKrtGT2xk1NQBa0m+ebda3RH2uEAk9BKnZx/Udj+FVLnT7q0uHOnwpLDMSwjZ9oic9T/unqQO QenXiOeASmN1d4pYzmOROGQ/1B7g8GpFvdVQY3WcuP4mVlP5DIoA0LO2h0uydpJcnmSeZ+Nxxyx9 B/ICsoSPf3IvZlKoARbxN1RT/Ef9o/oOPWiVbm8ZTfTI8akEQxKVQkd2zkt9OntU/WgCvfo0un3M aAlmiYKPUkHit2ymjuLKCWJgyOgII+lZNQrDLbyPJZXDW5c7mTaHjY+u09D7gjNACLb3dhug+xzX EasxjkhKnIJJ5BIIIzj0pfMuf+gbe/8AfKf/ABVSfatV/wCfm0/8B2/+LpftWrf8/Nn/AOA7f/F0 AR+Zcnppt5n6IP8A2atHRrWa2tpTOoSSaVpSgOdmcYGe/Aql9q1b/n5s/wDwHb/4umPJqM67Zb5Y 0PX7PFsY/iScfhQAszq+t3zKQVSONGPYMNxI/AEfnT9Lt/t06X8o/wBHjObZT/Ef+ehH6D2571Su bJmtUt7UxRxBsyLICRIPQkHPJ6nvVv7Zq2zar2C8YGI34/WgC9e6nYwySWs8rltuHWNHYqD7qOD+ tZCJ4ejRUT7YqqMAL9oAAqe3hFvFtDMzElndurserH3qXJ96AEsdQ0bT4jFbvLFGzFiZI5cAk8kl hx/Krmq2LXSLPb7Vu4cmMno47ofY/oeapnDAhsEHggjII9KrrcXmmW2xbq0W0T7huQcov93ORkDt 7UASW863EQdQykEqyN1Rh1U+4qWufTVrm81NptPgGoM67ZRaxMkbEdCXY4BHTPOR9BWpHomrahzq V6tlCf8Al3sj8xHoZD/SgBl7q1raSiDL3F233baAb5D+A6D3NLDouoav82rv9jsz/wAucD/M4/6a OP5CtzTdJsdKi8uxtkiB+8w5ZvqTyav0AQ21tDaQJBbxJFEgwqIMAVNRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAVR1DSdP1Ndt9Zwz+7LyPoeoq9RQBzTeFWtx/xKtVvLQdo5CJox+Dc/rUL2/iO 1+9bWWoL6xSGF/ybI/WurooA41tZNv8A8f2majaY6sYfMT81zT4df0mc4TUIA39122H9cV19Vrix tLoYubWCYf8ATSMN/OgDIjkjlGYpEkHqrA0/B9DSy+EdClOTpsKH1iJT/wBBIqE+D7BceRdajb+0 d02P1zQBJRUP/CLSr/qtd1RfZnVv5rTT4c1Efc8Q3P8AwKCM/wBKALFFV/8AhHtV7eIZP/ASOj/h HdUPXxDN+FrGKALFLUA8NXh/1niC+P8AuJGv9KUeE42/12ratL/28bR+gFAE2COoNVZ9Qsrb/X3l vF/vSAVMvg7RiczQzXB9Zrh2/rV628P6PakGDTLRSP4vKBP5mgDnv+Ei01m22zzXb/3baFn/AJDF Spc6vc/8eehzIv8Afu5FiH5DJrrURUUKqhQOwGBTqAOXTRdbuubvVIbNT1Sziyf++2/wq1beE9Kh kEs8T30w/wCWl25lP5Hj9K3qKAGoqooVFCqOAAMAU6iigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKAP//ZCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKPDwvUjEwCjEwIDAgUi9S MTEKMTEgMCBSL1I4CjggMCBSL1I5CjkgMCBSPj4KZW5kb2JqCjE4IDAgb2JqCjw8L1IxMAoxMCAw IFIvUjExCjExIDAgUi9SOAo4IDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjIyIDAgb2JqClsvSW5k ZXhlZAovRGV2aWNlR3JheQoyNTUKKFwwMDBcMDI2XDAzMVwwMzRcMDMwXG5cMDAzXDAwN1wwMjJc MDAyXDAyNVwwMTZcZlwwMzJcMDIwXDAzNVwwMDZcMDEzXDAxN1x0XDAyNFwwMDRcMDA1XDAzN1xi XHJcMDI3XDAyM1wwMzZcMDIxXDAzM1wwMDEgLzw/LS43Pj0zOCMmKjA0JTU7NixcKScrIToxIiQ5 XCgyW1xcSU1MWlRTTl5SR0hYVktXUEJRWVVfQURFT0BDSl18dXBcMTc3enFlb3lpc31idmthe2pt fnhkbnJoYHRsZ3djZlwyMDFcMjI3XDIwNFwyMDBcMjA2XDIyNlwyMzRcMjMxXDIzNVwyMjVcMjEz XDIwMlwyMTVcMjExXDIzMFwyMjBcMjIyXDIxNFwyMTBcMjEyXDIyNFwyMjNcMjAzXDIxN1wyMzZc MjM3XDIwNVwyMjFcMjA3XDIzMlwyMzNcMjU0XDI2MlwyNTZcMjQ2XDI1MlwyNTVcMjcxXDI1N1wy NzdcMjQxXDI3MlwyNDNcMjczXDI2MFwyNTNcMjQwXDI0NFwyNjRcMjY1XDI2NlwyNDJcMjQ3XDI2 M1wyNjFcMjc1XDI1MVwyNDVcMjY3XDI1MFwyNzRcMjc2XDI3MFwzMjJcMzE1XDMyMVwzMzZcMzI3 XDMzMlwzMTJcMzIwXDMxMFwzMDBcMzM1XDMwNFwzMDVcMzA2XDMzM1wzMjRcMzExXDMwM1wzMDFc MzAyXDMyNlwzMzBcMzM0XDMzN1wzMTNcMzMxXDMxNFwzMTZcMzIzXDM0NVwzNDFcMzQzXDM3Mlwz NjVcMzc0XDM1N1wzNzBcMzc1XDM1NVwzNjNcMzczXDM2MFwzNDRcMzUxXDM0MFwzNzFcMzc2XDM2 MVwzNDJcMzU2XDM2MlwzNjdcMzQ2XDM1MlwzNTNcMzQ3XDM2NlwzNTRcMzUwXDM2NFwzNzdcMDAw XDAwMFwwMDBcMDAwXDAwMCldZW5kb2JqCjI0IDAgb2JqCjw8L1IyMgoyMiAwIFI+PgplbmRvYmoK MjUgMCBvYmoKPDwvUjIzCjIzIDAgUj4+CmVuZG9iagoyMyAwIG9iago8PC9TdWJ0eXBlL0ltYWdl Ci9Db2xvclNwYWNlIDIyIDAgUgovV2lkdGggNTY4Ci9IZWlnaHQgNDY3Ci9CaXRzUGVyQ29tcG9u ZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzkxMz4+c3RyZWFtCnic7Z17fBTV2ccf CAmEayBsDEGJFyIoFhQiLwi2XlBbRfBepPoqliqIl2K9YH37qlQRqYJVaq3VYr2CiGKx9daCVxCj eMEbL5eELAQ1iIAYyPPXe87M7O5ssnF3T87sPCfn+X4+mT1zzjPnueSX2Zk5mwSRYRijgezM17dL 3t/QPvUMTe2y98QQZyMA5P0NcdNFHfKPq3Y7Cg68uUa0bjmoY6fjl3t2KwovRlxwQvLBj5yYYrYO f29mx7Q5Hh2DNX8Xp4eTTt6w+ZRJXsfygy9CvOinr9W+fuvPPLtDThRauOSi5IN/ObP5bNHHOjez Y9oUW7ogTv494tau+Hj/OsTXu6HbgW/kIXbf5jN9rOLNHohjnkB8EqDo0Lfwy1N7tr/ttKfEDFt6 LRxQ3Pl2x8yZLV/Yfdlb7H3VCd8e2LFiQXvpyW/GGM3KwxAPfxK/+tWlePIisV8XEZvDV8lWCeJ+ F30dt6wf9PT2nt9g+x2Il8369ps7jtj8o9k7d4wtfULMsLLj6e/ULe7j2MnZpowTdo+NF3urD13f 45ldywefKD35zRijWXQG1haJK5JTothht9jf3QGxtqe8yPmuDPHtcX3LTnrDtbxTyGDIu4nL3S5T Lxfbd9uLGXBRhbgY2thJdsvZ+k7bJuyumCN2lxx35Z3iZfLN0pPPjDEbcRlSNRhrHum4ByPyQvjZ UxCrDpMji890DDZccqTzuqe30M9Vs+Tl7pbJR3QE2G//jaJ7yYnyQuYSKaHnzpJ2YjaJsDvkcfF6 9cw8KcdxS6UnnxljNictwT/8Wrwe9RR224BYM3gh4h+mi466Q593Lb7p6bxMAcl0qZKhd31di7ed HdmKGD10ppgBT/qHsLjmN9LOmc3RY/fvEbcf9GykAXFvr33Sk8+MMZth7+LJz4rXmdfideds23Du eaJ98jKsrTrrKsTT7369/r0znNup99t9K7aP/1xeFnd9ctOXcw+4tf9ljV8fX/SCmAGHVYnBsY9I Q2c25/K5y+3131/XcU3lXQ3vD8hzPPnMGLM54Cvs97p4feto3HpOftllm0S7H0DXo2ZHxcXLcT0i ZVc2SrvT5snt+s7ysvip/YuOvueQ56uGl/zXok67xQx4wHdisO+X0sSZDeXl8+29S4c+3mXLByNK J/zyVMeTz4xh0nM+33sz2bFt+pY9k4fXhh0GYxg1U7t0OWVj2FEwDMMwDMMwDMMwDMMwpgCMubBu GBVC1U2IzpnWwLphVGDdMCqwbhgVWDeMCqwbRgXWDaMC64ZRgXXDqMC6YVRg3TAqsG4YFVg3jAqs G0YF1g2jAuuGUYF1o4wlH5JKDetGlVzKhl6hWDeq5DL4QH2ZJ3/WDQFfuZSNpjxYNwR8GZgH64aA LwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPNq8bjwb8dIX9jnN76Ev Lj+jLJJ33mrNvlRh3eSW7HQzEj50mk/C0I9Ks350yroJYppwyE43V8Esp3kLTBsGY5dv2rt4gmZf qrBuckt2uvkjXO80J8G9RbA3CF+q/ODcP3RiTCSnx1fOpwmH7HTzBIzHX8OlOBb+2QOu2B2AL1VS zn0DTPEGWTeayU43H8MgPKb0UDwQ1t5eDjDq+MVRzb5USTn3KBFuOt8KQbFustVNfUHBloLpRZsL S+pw1cSu4qd46Ba9vlRJNfcnIr7X0/lm3SiRnW5wNNxX8GXBbTBcdtQsnz8KZuj1pUqquW8Turml yfjq83qUdD57hWx+Ou6A/OMb5UDifQxg+10Hlgyan7UvTSEbQybBFzk226Ej4ngYchQOGQYTvaFP oK9eX6qkmvtMOArObjLuPjwo/QDxq/aydUZT3Vzm7CzK1pemkI0hk+Dbwx6x3Qf9EK8HuBGnAlzh De2FEr2+VEkxd10vWAW9apLHf7Hs+5qN18LP5T1h/7c3fTY8+boYYPiq+t3nwtAsfWkK2RwyCX4i nPlO3XsnwimIswBewAUAd+Cwuz+vrf1sAlTq9aVKirnfhSPwSKhKMb4TuqMY+kg0/9VUN/8S243Q JUtfKrR53bzd1Tl3d30NcRUUbsbNhfCud8KHgif0+lIlxdyXwG/xtzAzeXzZhM4FIuxCxI6wS+w3 NNWN/D+K26E8S1+aQjaHjIJfe05ZQdk5b6BcmJL/zH0w7MWVU44uLck7t0q3L0VSzH2sI+yRSeNz Ep8sb0E3GUTKujHy+XyGc28rcAQS2ebsFcFW+dIb7ttdg1uk9fDU71MZRMq6acu6eQwGiO0AeMTZ q4S528VLT3ixsX7FWGl9vbwu/uLHrBsl2q5uboJbxfZPcIOzd7/75jTNOQdNlk33Pvz0+H04uK0M ImXdtGXdjII1YrsSRjl70cvLpMmuK/IK8uZEHevXT+5efFIj60aJtqsb8r5YNwR8GZgH64aALwPz YN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP43VTNy4jy2xmTXkQ6yaIacJBBv/SvW57ASz4IUul 6Zv6CgrWTW6RwY95y22fdvrYH7JUmr6pr6Bg3eQWGXw7d8n4k4qaincQZ/YWfe/+OIrbB62FW3v1 fQrXHVMgH8E7bZhegl9URCrWefuxHTmVe6gza7z/4uLRK/2+gswjV7Bu3OAjNU5z6jP4zI2IPZfI jy6d+iJ+dCLC/IaXO2PFXNnjtmFJDfaf1zivwtuP7UgD71CnGeufXT2vv99XkHnkCtaN/3zT0AkA Ou3CV0Z2ugjx88O2X7sKISo1EKl2LJ021AmdNWB1xNuP7SBGwTsU/f3O1ucryDxyBevGDX68c33z 5xPE5oQHxGZFqdhc+eIF6J1GvPON8yW3lbc03Bc7xXg7vRfuug1ih/r6QWxzfb7xbg8zdpbOcFxd y75ag/G6eelO2RqyVGyWHiV6es8Rre96/z2mlRUVheDXzZrKSP8vYrpxd5b07TIHYof6+mFq7q9v YreHurjrpZZ9tQbjdZPy+U30nKY/ZpnzXp8WfQWFb+7Y7aEu1oxp2VdrMF43Kfvzl6pPWnJ1Vr50 4Jvbuz2Up8i/dG/34tXdOy2S4/0WYNXo/CtE98fHlhwh/97T2vYN2ND+80RPh/VPw9Pr23m78tZR srksmDzapG5M8+Wb27s9BOcWcGHJ/IZX24nd6L9HiGuu6tmie8gDtc87v6g88UGcezYmei788MLf jF91gbcrbx0ldU1/tZB10yZ14zvfRGO3gfN6FEI5Foi7O3mrJ24cnV+QejdvZ7+VmOi5/OIjo4Mu nuTtgvdGzeebFLRB3bi3hxi/lJdfpQsbFoC8x3PON0uqPdORAwc4Fl7PE0V/xVuL7vB2YzO+NTGY PFg3BHz576fudHv8urmmV/eZgFWD8q8rQnzzglLPfDE851h4PTtK9uH6gjXebmzGe5cFk4c9umlF ovIhSG6f36Sk/p4hWU/Nz29SkHHwGdq1ZCYfgoT/vBjKj8zmF5Nb5StX04RDrnQjH4KErxtSvtqK btynFjc8isumeM8znIVw7zkxuO/4SWvh6K6ee4vnsumYeY8/Eg9P0L0pYd0EMU04+IJ3n1psOv/B 8zd5zzOchSnv4tJ7SVoLR2/13F08d5oQn8j/8MR9CMK6CWKacPA/L3MfYrwKq2PNiHc7Gk3oJmkt XOAsgbuL504T4hMlHp5I+HwT1DTh4D/fOE8tGoc+d3CD9zzDOd94S91F6/3L3Ji4kpFL4M7iudOU ZonHHwk7+RCEdRPENOHgC959ajFtIb5wrfc8w1kId5e6cXIx+Ja5MaYHdwncXTyXTWmWePyRsJMP QVg3QUwTDnqCT794nsPnN4HDutEUfIaL56ybIKYJBwPrnfO5A/LFuiHgy8A8WDcEfBmYB+uGgC8D 82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDLwDxYNwR8GZgH64aALwPzYN0Q 8GVgHmA2WmqQYaHMnDsgX2F/41uJlhpkWCgz5w7IF79PEfBlYB6sGwK+DMyDdUPAl4F5sG4I+DIw D9YNAV8G5sG6IeDLwDxYNwR8GZgH64aALwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0B Xwbmwboh4MvAPFg3BHwZmAfrhoAvA/Ng3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubB uiHgy8A8WDcEfBmYB+uGgC8D82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDL wDxYNwR8GZgH64aALwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPFg3 BHwZmAfrhoAvA/Ng3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubBuiHgy8A8WDcEfBmY B+uGgC8D82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDLwDxYNwR8GZgH64aA LwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPFg3BHwZmAfrhoAvA/Ng 3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubBuiHgy8A8WDcEfBmYh+G6ySVB5hHc3AH5 Mlo3ORVOoGkEOHkwvszWjRL0Us6l/Fk3qhBM2TjZUCxi0FiYsn4sLKKFKevHwiJamLJ+LCyihSnr x8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqY sn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyi hSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fC IlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+ LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp 68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJa mLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiws ooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevH wiJamHJmgEfyLu81KUwQHoyGxDeH7p63H4QHe+CUGRUsLKKFKevHwiJamLJ+LCyihSnrx8IiWpiy fiwsooUp68fCIlqYsn4CL+Kff1JaXHndZwF7yQbWjQaCLuL9cO/O+pWDKX2rWDcaCLqI+0NUbP+P 0reKdaOBoItYBKvi7VcP6Vk6bLHzbP7l/iXy8fy5uEc+pG8yEGxErBsdBF3EMwGOnvTobtl8unBO 486rYal0evrmJ2ENlNUhru1X03Qg2IhYNzoIuojbpnUUZ5Hy0zYiHgwNiFvhEOn0DTlWCY8gTr26 +UCwsG40EHwRtz5+8wCAsYjF7tJxV+lUXvSIa+bxWN/u9eYDwcK60UBuijgb8qVu6pOd7i0q+PLF CSkGgoV1o4Ggiwgr5LYRuiGOdNpvjE44HQd/mvBKqoFgQ2LdtJ7AdXPgY1uiu2+EexCfLx/4Xt26 w25JOF0IZZ3rUw0EGxLrpvUEXcQVUw/rU9DprBdl+z8DepYcfZ/7GTlnMLofTE45ECisGw1YWEQL U9aPhUW0MGX9WFhEC1PWj4VFtDDl9MQuLYN+NRjjEwgAyIluzK682dEHQ25qYnblzY4+GFg36TE7 +mBg3aTH7OiZsGDdMCqwbjKmEhaI7QLoj7jjqm4l3WbsQNx9Zp+C3seEHVkIsG4y5vdwutieAX/E HWXdPqj/sEPZDhwL/6xdMzHsyEKAddOcFmryaXn+VtyaX74BZ8BLYv8fMAM7wm7vEID8abXy43eF HX71DeLtB3XsNwu3/2FQSY8/bs/GiyGYHX0wtFSTkbBIiGUgYgf4Tux+Bd2wDDpPe2i9PGRS9WS4 DPF/VjQ8JPQ0Dy78fs90vBd+V32N/NhMFl7MwOzog6GlmsyGE8Qb092IEagRuzVQgovLxImm6A5x yG5cD3mOWR30xhHwnmzuB5/itzAqKy9mYHb0wdBSTfZEIu9HSrbI880esfud/Nxm3Qe/HwTtnM+C 10AEPxrYpxyg3FOWeJEUZOXFDMyOPsecAAfBieJ1BiwT20VwldO7EUqd881u6IHtYWldg6jpKHhT Do2AjSGGGySsmyxYJE4er4jXHWX9Vtd/0F7cTw18ZV/9M0JLANc3XA+/xM7wUeMkUdP5cOG+vZNw Lhy3eefS88OOOwBYN1mwNR+6NsjGjhkdIh3k85vTDiwtbHfeHud+qviqWnx5eLm76P3wQUX9Hkac 1b+oy4ULw447AFg3WrCujNYlnAEKNcnNIYQwO/pgYN2kx+zog4E/R5Ees6MPBtZNesyOngkL1g2j AuuGUYF1kwL+/am0GJ9AELBu0mJ8AhSwsIgWpqwfC4toYcr6sbCIFqasHwuLaGHK+rGwiBamrB8L i2hhyvqxsIgWpqwfC4toYcr6sbCIFqasHwuLaGHKTQAqcMYmEXbtfHDGBkEm+BzqJkeO0kEmEBXI BM+6MQoywbNujIJM8KwboyATPOvGKMgEz7oxCjLBs26MgkzwrBujIBM868YoyATPujEKMsFT1E2w iwFkSq+CL/hw8yCkm6+nDOrYa+zLmeimNVG3Md3IWpXs/9/vi+bO6/cv2n/qVrczf/S01+T48jPK InnnrU6eJmVnS46UxrWR1tG/+/hWHVk3qWkevLdWW1yF0YFOa0A01hl5APGj0hRruSk70znKblwb 6Rx91xfOeK128/MnZGLNuknqqV93AQzEV6D96toPyuBFp7Nh+aTyorU4DMYu37R38YSkY1J2pnOU 3bg20jm6GcY0t/a/vHJC+5KOR/5udeITGaKz9i9Hd+x07iee0SWdes9tdSCkiQXf9My8D4rxZJgl WrfBybHOK+FSLIK9zWfxdQ6BRWL7BBzkK7C/wokCAzzW6dAtl/esTAokcNI5OhRebW7te7kxnosv q02/cBqdNzpG8zO6nm6TutkDB+Ag569Xr4XRsc63YDD2gCt2N5vF13kHjBTbiXC/r8C+CvsKDHAA wPkZXkjoI52j7vBtc2vfS0+4dUNd7ZsPHeuf7E447LO6DafCTU5f5bLq73/d6kBIk+q6GLHmjYnw K8wH+deKq6FnbOwb6IW3lwOMOn5xNGkWX2d1d3gNvyuJfJVc4NjsvgIDLF0K8MJ/iOmmwP0fAcnW vpcD4RfHXTz3yWjSZAc5P2JfwX5O331aAiFN6vspcUf1s0YsBFmcKBTGxmrk/1pYNbGrGB+6JWka X+ckuAHvl3+PP6nAsdl9BQbY2uh8NQ0kWFp7vvlohFOg/jv8kxV759OI07deSyCkaUk3Q8UVSMrz jaBm+fxRMKPJRPHOtdB152B4rEmBY7P7Cgywfbvz5XObBs0Zp2RYy9c3tc5LdMWSmWfmu1fPTXUD Tl/yybjlQHKUcRCkfp/aczUMqvaubz5PXN+skVe7Dp9A3+ZzeZ1nwU3QqR6TC9xUN+D2OF/eeI7K mG6SS+Cnvr0ikI+vsI/zH0r+lTj2HciXL4Xem9rgop0ZO0jYGSyc1LpBHA/X4KnwsGjd7b+fmu7Z 7oWS5nN5nX8T2SauCr0CxyrsK3BT3WQVrDrpJtl3AJy0vH7bf9znN5UwV/6/vmNh3O5NH/xIHvuT e9Y11nx6sXvq7QCzdsnXuXDIqp11n95+eBZR5izjIGhJN2ug765noV9V/eoO3vObXcsnl5d8jMPu /ry29rMJUOmfJamzrhvAh9ikwLEK+wpMVDf4dE/fT/r9busBp+cy/73hJXL4fz3LujGJ04NVukl+ +xAcBQ/UHO50JZ4XFzwcNyx4InkWf+c10D6KTQocq7CvwFR1g+/cNKKo12kvO+3o5WXOAfePiOx3 13bZ/OLSyuJIhwsfcYZ3Xtkj4l70PDS0S8mI31VlEWXb1M1TcBRuuzSvJO/6ne5w8aAZ60Rr5ZSj S0vyzq1KmiW58zdwpXxJKnC8wokCk9VNjmgTutFItIfzNhVAIKwbMugPLPog5KX+18+tDoR1Qwb9 gYm3tL8EFAjrhgwB6KZ42qaAAmHdkIFMYKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCs G1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgEFrZu6sa5o6mOaDaQ coofCG5OFoFkbRMKLQbm1dGx+YHDmw1CGvusA8nSRnWSl+51R1Md0Wwg2zh6ZxFI1jah0GJgXh0d m2aN5kP+sR8oMV3djHnLHU11RLOBbONIfX5qk7rx6ujYNGs0HzJeN+22uaOIX1REKtZJu34LEFeO zr/C1c3FxaNXotcN8catvfo+hbjumALnzOvtVsUOik+lmo15uvHqGKubrFLsc6SynvEh0TOzt/cZ U5he4lTPLbF7mOz/+NiSI1YnvgXZBZKljeokkRp3FLH/vMZ5FaIZ/fcIsTO7ep6rG9Hoj143xBvz G17ujFgxt9Z9h3Z3K2+pnu2YxKaySDdeHeN1i5fLrWd8SPT1XFLrqWRJjVM9t8ROj7Md8kDt88MT U2UXSJY2qpMkzjeRBqyO4LwehVDu7ri6cXq9bog3ou4h1e6h3m5B7CB3Kqt049XRq1u8XLF6xodE 3ysjO13kqqTOrZ5bLZC/I+z0R8RJpzzxLcgukCxtVCcZH7++qbyl4b4KLF3YsECefMSOqxvRED8M bjf4GvIrfr6Jz+Ceb9yprNKNV0evbm6VitbHWokhp72i1BnzyuaVuPfCXbe5xwxZUo2+b0F2gWRp ozrJS3e6o4hrKiP9v8BrenWfCfLNuPhGVzdTnTdftxt8Dfm1oqIQfLqpGpR/XZE8yJ3KKt14dfTq 5lZpcjHE6hkfcq54es9xxmK6cUu8pG+XOe4xb15QKvzEvwXZBZKljeokvucOGqi/Z4hqIFnbhEIm z29yQti60QqUH1mV3qhN6ibXtCndZATrRgesG1WbUCATGOtG1SYUyATGulG1CQUygdHRDTRrZDJr 865xda0MJEObUAgusHRlawId3SQsW2d310utD6Rt6SajY9KVTSEQs3SzZkzq/mwCsVA36cqmEEjO 3qfcdezYEjh6C7M3PIrLprjN+Ao4un/+2neQuyQu2FzWykAytAmFbAOLr317VZpegt4KufvhAa+s mL5sCoHkTDfuOnZ8CdxbmN10/oPnb3Kb8RUp3+qCd5C7JC6oS/EnELMKJEObUMg2sPjat1elJTXo rZC7Hx7wyorpy6YQSM50465je+uzGFuYxVdhdawZWwGPJnTjHRSNnY/5fOMjvvbtVakuvkLufnjA Kyuafb5x17G99VmMLcw2Dn3u4Aa36Z5v3JXb2JKudxDGdPPWxFYGkqFNKGQfmLf2naiSt0LufnjA KyumL5tCIDnTjbuO7a3PCtyF2WkL8YVr3aa7Au6u3MaWdL2DMKabe5e1MpAMbUIh28Dia9+JKnkr 5O6HB7yyYvqyKQSSE92810eDEwk/v8mQ5A8PmPr8puRqDU4ygXXjTZXJhwdaFQivM5CBTGCsG1Wb UCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFM YKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFu VG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFMYKwbVZtQIBMY60bVJhTIBMa6UbUJ BTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgE xrpRtQkFMoGxblRtQoFMYKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG 1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFMYKwbVZtQ IBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CAeiQ SbCcMRXCrl2cjGLljA2CTPA5C8S+jIOATPCsG6MgEzzrxijIBM+6MQoywbNujIJM8KwboyATPOvG KMgEz7oxCjLBs26MgkzwrBujIBM868YoyATPujEKMsGzboyCTPCsG6MgEzzrxijIBM+6MQoywbNu jIJM8KwboyATPOvGKML+HK4Pztgkwq5dHM6YYUzm/wH20LcVCmVuZHN0cmVhbQplbmRvYmoKMjYg MCBvYmoKPDwvUjExCjExIDAgUi9SOAo4IDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjMwIDAgb2Jq Cjw8L1IxMQoxMSAwIFIvUjgKOCAwIFIvUjkKOSAwIFI+PgplbmRvYmoKMzcgMCBvYmoKPDwvUjM2 CjM2IDAgUi9SMzUKMzUgMCBSL1IzNAozNCAwIFI+PgplbmRvYmoKMzYgMCBvYmoKPDwvU3VidHlw ZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VSR0IKL1dpZHRoIDQ2OQovSGVpZ2h0IDIwMgovQml0 c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRENURGVjb2RlL0xlbmd0aCAxNDc0NT4+c3RyZWFtCv/Y /+4ADkFkb2JlAGQAAAAAAf/bAEMADgoLDQsJDg0MDRAPDhEWJBcWFBQWLCAhGiQ0Ljc2My4yMjpB U0Y6PU4+MjJIYklOVlhdXl04RWZtZVpsU1tdWf/bAEMBDxAQFhMWKhcXKlk7MjtZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWf/AABEIAMoB1QMBIgACEQED EQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0B AgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEB AQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFR B2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AOVuHjCcsAeg qmvPykD61X8yUKQ6bsHOcU5X3R+9AE0sINu205UspLdhwaoo3OCc1IsZBwCSrc496aUw2OhpJWNJ yUkklsO6g9TUikFcE8U0EnHNBbsFzTMyW2d0lGCTWulwEQZYIfXNY8cgI7jFRvKQTkkj0NAGydQP PzAP2FPt4/Ol86d+ewp+i28N1bmRoTv6VdSEKxKrlR69qALdhbgENGoIJ6mtqGOANl1VSO9Z9pNF 9lKsRnocdqJW2kbAZFHIyKANswwuRhhgDmmeSY5AVQsme1M0+PzSrvhfQVrLGQOBwKAGQ8kNyo7V fA3YxTURio4GKemQwB4BoAsL0peo6GkUYFLQAuSOlJ2pScCj+VAFZY7j7azlx5G3AXHOasblGeRm lqKSFXBOMHOeKAJaTmm8uo6rmn57ZoARxuQr6jFRxQ+XGF3MSO5NTE8dKTPpQA1QQOuTTqBRQAf1 oz6UZo7UAHek3DdjPNLjHWs06dKdWF39pcRhdvl9v89aANGgj3pfwpNxJxigByd6ox/66T/eb+dX 1qhH/rpP95v50mBNUVxPHbx75WCjOBkgZPpzTpZUhiaSVgqKMkmuellfV5WklYwafCckn/PLfy/m DNhNRt2tmm3bVD7MEj73pnOPxzipLe6ju4HePOFJUg44I9xwfwrAtbZtSdYoVaGwiPXux9T6sf0/ n0EFtFaW3lQrhQOvcn1NAEFn/rbv/rqP/QFq1VCB3WeZIkV3kuNoDNgf6oH0PpViY3cMMkrQQ7UU scSnOAM/3aaERQ6gLeacvaXbuzbcpFkbR0wc89z+PtU/9tJ/z433/fr/AOvUOoyyrCkNu225uXEM TYB2kgktg8HaoZsHrtx3rM1R5dOkaAanqFxdFGljija3GI1XJeRmjAjXdkZJPtnkAA2f7aT/AJ8b 7/v1/wDXo/tpP+fG+/79f/Xri4NTvLm5uv8Aiq47e3hdE3JafaEQk7fnl8pFAJ6Hp+WTuxx6rpV/ EL7VI9Qtmwkp2JE8Rc7YzsVc4LArndzu6DaSQDTsX3wkCKSNEYqgkXadvbj26fhVmo7ieO2t5Z5m 2xRIXdsZwAMk8VSm1vTYdLTUpLuMWcmNkgydxPYAc568YyMHPQ0AaNFV7u9t7LyPtMmzz5Vhj+Un c7dBx9KY2o2iakmntOq3bx+asZBG5ckcHoeh468UAW6KqW2o2l3dXNtbzrJNakLMFB+QnPGeh6Hp 0xT7S9t73z/s0m/yJWhk+Uja69Rz9aALFFZ0mtWUd5Na7p5J4NvmLFbSSbMjIyVUjkU1Ne06S6Nu s7BxObfLROE80fwbyNueOmeaANOiqV1qdpaXCW8ryNO6FxHFE8jbQcZIUEgZ4yajm1qwiuEg82SW WSITqsELy5jJwG+QHigDRorKk8Q6ZFM8Uk8iNHs8wtBIFj3427yVwucjrirF1qdpaXCW8ryNO6Fx HFE8jbQcZIUEgZ4yaALtFNjkSWNZI3V0cBlZTkMD0INFAHi13IiqUjTJ6Eis+Nz5nPIqyilDljTW TA3DHNACjdlvTtmkKEnd3NN3HA5705pW42p0oARkKnBXrzUEp2yfKamLySKeME96ktLTJLvzQAyN XfA4GfSrtpboZl3ruwec1NFZRvjkhq17SyQrgn60AXIZI4ztgQBQOcHvUqxmVWZkxk80ltaLbynY Mgj1q5DIjzeX932PegChDYkfddVBP3fWtq1smiRS3zL70fZVJHykH1FW4G2qEJLfWgAVYwQqAqc9 Ksxs6ttyT9ahZQXDBuR2q5GhyDg0ATxysv3lOKnHOMVEAO5zjpU6AAcCgCQVDeyPDaySRoXdRkKO 9Td6XqOaAKWl3Ut5ZJNNC0Lt/A3arhGRgkigcDjikaQKVByC3SgBaXt0pD9aXrQADGKCaTvTZEEi 7Tx9KAH0fQUg470vegBhDb+vFO/Gl70MQDgigAo460dqBQBT1PUYNNtmnuH2oB1pbG9hvrZZ4WDI 3Qg5pupaZb6nbNBcoHT0p9hZQ2NqkEK4RBgUAWs0jAsMA7felxx7UcUAOQYFUI/9dJ/vN/Or61Qj /wBdJ/vN/OkwMe7juNR1F4ZyYbSAkk9vrnpnB/AfrBMjXdwsDhrWxhbYq7SCxxnpjJYj+fqed1rb d56l/wB3ODuGOQcAcH6D0pFtiHV3cFxJ5jYXAPy7cAZ44xQMdamARmK3wEiO0gA4BzyPr/8Ar71K /wBxvpTIojEu0MCN7Mcj1JOP1p7/AHG+lIDLVjHcPIFYhLnJ2qWI/cgdvrUt3dmW0mjVJyzoygeS /OR9Kr/aXt5pwi7y82AApJ4jT0pzX9wqlmt3CgZJMT4AraMG1fQllUatajUbi4F/psc0BNtHHc3I QgA5kOOoLMqpyONm4ZBwampavpV/Ok0n7q6jRommtr20ZZEIwyHe/wA6E8gMoPfA5pNQOnxQzXUu k6fNKTn5oFzI7HABOO5I596yJtQtLeNnm8P6JGqnBLcZOM8fu+fwolTcHaQXE0TTdNht5EGoabpq 3UbxXDyailxOYyVyi4CxqCFPzYY811Mmq6UGg0uO70ltFNq0MpN+A68BVUDOSMZ5z68jA3ciuqRu 7LH4Q09wuPmKKgP03IDVqxvbOe9S3u/DWnWpkB2HylcEjnGQuOm49e30qVG7smM3nuTqXhXUo4pV vJ44ZbdnhwwlYIcMNvHzAqcDON2OorB1zRL9dI1S2SBpbWCQvZRxIDnzJEYhVXkbMOM9w5xgcV0V rPHZxmO1tba3QncVij2gn1wPpU39pSf3U/I/41t9WmK6MzxBpV7rlvfeUyxokZhhjeM7pMFXJB3D buZVXkHhMjhqrzQ6jfT2+rW9owv4ILZ/LaLy95zKssYL/d4b36D2Nbf9pSf3U/I/40f2lJ/dT8j/ AI0fVphdGJpdje6bqOswwpKZZxaxR3JiOGfYd8vPBwdzHJ5PGcmi2huvDWsXMjW0t5aXNtGB9jtm JV48IqAbmx8pzljz26Yrb/tKT+6n5H/Gj+0pP7qfkf8AGj6tMLoyIxLa+LdXuJW1CGGQwFDBatIk 21OQSEbp04I6n8M6PT72K6lu5YLmW1i1uSZrbyzyp4WZcDccE9BkH8DXUf2lJ/dT8j/jR/aUn91P yP8AjR9WmF0Y2rlrpE1iyi1Ww1NbdkhH2Yv5gDH926ANj1BOB8wPOMBs63o8S213dC9tC2lqksln bmUCXfkp91x6/kOfXb/tKT+6n5H/ABo/tKT+6n5H/Gj6tMLo5fVNPvby9165hguZLZzaSm2MZT7W iqCygkbgRjtz2xnFbNszaf4i1G8mguWttRjheJ4oHfbsXBV1A3Kec8j17jFX/wC0pP7qfkf8aP7S k/up+R/xo+rTC6NKNi8asyNGWAJRsZX2OCR+RorN/tKT+6n5H/Gij6tMLo8ldCw5BqKRtqhecCp/ PLIDwM+lIIhIvPWucZWABwM04A/UCporZl5PaporZiScZGe1AFUHAxjHNXI25AwNv1pr2pbcVGat W9tiMMRQBbtyBggfjWtBFhN68etUrSLdxgVpxIoj8tzsDdCKAEluGt4TIELeuKW0U3DpMgCt160r 2xETK3C+ueKZakwOvlDcQcHnigDchlYj58KfSrMcR3bqy5VYuJE+Zu+O1XbGeWXIx045oAsgZYHb tYnBrQjQDknNVVY55XrVmMHHWgBzJk8GpVbFNXrT9o60ASUo5HTmkAp3GfegApCB1xS89ulJQAo+ lFRyCTI2EDnnI7VJxigAA4pqjbn39aVwSh2nntTIt4QeYQW7kUAObOPl6+9LnHXrRjmgqM5NAAcg 1kaprtlp1xFHcShGc4Ga1yAc/wA65vXPC1vq17DcSEhoz24zyKAOhilWVA6kEH0qQ1XtoBbxLGo4 AwKnz7UAL3ppyRwcc07qPSmFPmDZPHagB9GBSDp6UtADlqhGcSzEdQXP6mr6DAqgn+sn/wCB/wAz QtwMnWtebSrdG2LNNI21I8hc9yScHgeuDyQO9c/F401ONws1tbXG4jmMGIRjuzZ3fKOMnjH41f8A FOmzXkENxbI0stvuBjBGWRsZx6nKr36Z6nFedTX07u/kHajK0Zwv3kPXr64HSrdGvUq8tFdDrtQW ElL/AJeN2W56Umv39swe+NvJASAzxRlDGOmSCWyOcnkYAJ5rWubiU3Nku8hWlYMBxkeW5wfxA/Ku F0u8udftpbRbciQ4SWReEVG6nk5BwGA68gV2s/8Ax+WH/XZv/RT1jh1WUZwrrVen6aHjYOdZpqtu hkb7NXQ/9N2/9FLWXpM+uahpQuNYd7dYIpR5ewI9wxDDc4wMKAcBe5G49q0LixkvZZvLKDZMc7vd E9qg/sO4/vQfmf8ACuuEIyim5JHY7mDf3PmXgG13jtjyEXJ3kf0U/ju9QBWZeyQS3KTx3kAcRtGY 5JdhTP8AEvdW7citq78JPBHcXUmpXEMS75nCTEKo5Y4AX61T/wCEfP8Az+63/wB+Lj/41RUXPJyu ho5ywsXkSV0JupZgSsgRlVGBHz+YwByDngZziugkI3x2rySG5eMMsuw7QyEENjoDnnH0B7VVuLfT bWdobnXr+GZcbkk85WGRnkGP0q1puj22qybLHW72U4Y53yKDjGcEoBkbl49xUez80Fy7d3X2nw/d SY2s0EgZc52sAQRnvggjNZaJHa22hy2caRXUrRq5jUBpEK5fIHUdDk9K6S08LzWsEkJnWdZWLOZn LE5AGDx0wKkh8NG3cvBFaRMRglF2nH4Cu7nhKzclcnU5S2X7Ey2s5iD3KStFqUTYYjBOX7ng56kd PTNWtIAtrg6bPaxw3C24Jmt2IEq5xk4wd3v164xnnoo/DjxStLGlqkjZ3OowTnk5OKSPw0YkdI4r RFkGHCrgMPfjnrSi6aa95BqYtrHb219LfwtFa2RhEeAAiOd2d/pjnAPfJ7YzVihW48R6nvtLa4UG HJm6oNvYbTn9OgroR4VRQwW3sQGGGATqM55+X1AqddBmWR5F+zq743MM5bHTJxzVc1N295Bqczqz x3mqaQYlgu0bzsK7ZRvlHfB9PTtUVratFf2On6g4uIYrVmRXGUaTdyBn72FOBnoOcCuoTw46eXsS 1Xys7MDGzPXHHGadN4ekuECTrbSqDkB/mGfxFK9Nu7kr/wDDBqcdBDPdQp5JiuIbW5m8m2mOVmiA AGCeuM4BOcZ69qc7rcQQanDbwz20Vu2+ymbPljccsucgdCOg4XA9B1snhx5YlikS1eNcbUYZAxwM DFJJ4aMqIkkVo6xjCBlyFHtxx0qf3f8AMg1OVu5kmvJ5I9+x9GYrvOWwTxk+tbmkvjSLIf8ATBP/ AEEVov4ekd2d1tmZk2EnklfTp09qcmh3CIqI0CqowACQAPyrSEqcXdyQalfzKKtf2Ldf34f++j/h RWntaX8wrM80tbVntUfrTY0cTkNwnatjR51a3WCRAHTgkmrs1sitmQAL2NeMaGMoA+7yPSrVico4 xz2NTmKN9/2bBdetNjtpS4aI7f7wxxQBBa20ss0gRsknlaneF7ZfKmzuPIpieZY3TPvw7n8MVs3d qL6x80nEgHVetAEembHiHGW71aum8tlXGPQ1j6fcNpsoSVc7zkFj1reuf31sJl2lumBQBIjCWHnB /rVPzxG+fLZS3GCKu28RFqpI+Yj1qaO2DOCy8e9AEVuwkO2M4J6irkIlimVQfqfWqohdbkNGmAOp 9a2YlU4OPmx1oAlU84I5PcU8lgcg0sYB/CnMNr4J60AEcjbgjDLHuBwKtKPl5qncz/Y7SWcIzlVz gdTTNF1FdVtFn8p489AwwaANKm7Rv385xin96guXlQL5UYfLYPOMCgCbtzR0oHTnrRyRnp7UALnN HaqmoXyWEAlkVmBOPlGaso4dA/YjNADuPWjPFJ05o3DdjvQAjNgj3pxqMnYWd2Gwe3SiOVJk3Rsr j1BzQBIKjeMmRWDEAdvWnnpS0AFFR5dVYtyO2KybC/m1G9kwkkMcDbSrD7/vQBtUdRzRnA68UgOV yKAAnAqOeV0ClEL5OD7VLnj2o47UAKmcc1RT/WT/APA/5mr6d6zW83M/kIryEsArMVHX1AP8qOoF G9u47K2M8quyBlXCLuOWYKOByeT25rzLUtHuIJZ3trdhADIwjZl3whckhhuPAGOckEMvOWAr0y5s NRuYlje2twBIkny3DdVYMP8Aln6gVVuNCup3una2hDXMTRORctwGAViP3fUhU9vlHqc91LFyotyp slxvuZXgrTJtPivWuSFuGdUeIc+XtGRk9DkODx6/gOgn/wCPyw/67N/6KemWmnalarJ+5hlkkbfJ I9wcucAZ4jA6ADgDpUjW959qtXuUtokSRiNsxYsfLYYAKj1z+BrOrW9peUnqxpWBEje6Kyorobrl WGQf3NWb62sVsbgpbRKwjYghBwcVDFCJpLj52QpOGBXGf9Wo7g+tSvZmRGRrqcqwIIwnT/vmuZWs DI7gpcalb20jqsMJS4mLHAJ3YhX6lxnj/nngj5qp+J7e6a6CCGRtNnhk3i2V8yXG3avn+X85j2gD 5e4GeMVVks/ECzXaxw6HPBNO8oN0sjMQRsGQOPuYXjtnrkk1f7L8SDhDpsa9kjvbxEUegUOAB6AD ApDMrSL3WdPjvbieGPSWk+a1gS0ij+0SKwxD5e3zHB34DA/Lzya7W/tGu1gvTb28erxwrNDF8plB X/WR784KkPszjALbueMYWmaZr2kqBYWPhuBgCu8LMXIJzgseSM+p7Cpnt/E0moRXz23h1ruJDGkp WbcqnqP5/mfU5ANTUL3/AIp66v7OT/l1eaF9v+wSpwfw61jx6hf2VpoV7LeSXaag8UMsMiIoUyLk MpVQRgg8HOQe3WtGw0+8k0q+tNVa3U3TycWhbaiuPmxu5yWLHnPX04C22gwwtZ+dc3N1HZAC3imK bEIAAbCqMkAcE5xk96AMnTNW1CTzoLqeSPWwkrLYTwqsUmM7fLYYJGcDJY5Ab/eFrw7qUt7G0Ml/ L/aKQAzW13bhWifswChcr3xycFeV73v7Dhe8iuJ7m7nMCOkKvIB5QcYOGUBiccZJJ79eadDo6xXk t493czXbweQsz7AY0yTwAoXrzyD0oAhsnv49fntWuJLuxS3VmlkVA0cxb7nygfw4JBBxx0zzRF9c 3HifU7F769ghhMIhW3t1cDcmTuby2xz3JHf0rQXRGWye0Gq6gI2GAVaNXU7gxbcqA5JzkknOTnnm nHRQupXd9b313bS3ezzRGIyp2jAxuQ4oA5+21zUJNa+zpdSSynVZLcW7RKI/s6gliG2j5l/3s9OD nnS17Ubmw1WHz5rm00kwEvc28Kvtl3cB8q2BjGOOS35Wm8OWZhlQSTqz3v29ZAw3Ry+o4xj2IPWn Poe/T/sZ1LUCjRtFIzyK7SqSepZTj7xGRg4xnOBgAzbvU7g+IYLX+0J1tX09Z91jbCTe5fG4Da5C kf059aOpa1qNrq2oWkF7K80ElrFaQtCmyZ3A3B228Z5PVe+OnHQNoMK3kN1a3NzaPDbLaKIijDyw cgfOrfn7U2bw5Z3C6iLiSeU6gkazMzAHMYwrDAGD39M9scUARrc3eo+IL+yiupLOCwSMHylRmlZx uySwIAAGMAd857VtxhxGokZWcAbiq4BPfAycfmazn0dTdC6hu7m3uWjEcssWz9/joXBUqSPUAdSO nFaMaCONUUsQoABZix49SeT9TQA6iiigDzW8sjFeobdfZsVIzvLG0AhLN6ntW5FDIgObRyScn54/ /iqeqyKS32JgT6PH/wDFVHtI9yuSXY5+Cya3jIZWUkZ4FXrS5QRmNk2t6+taMi3Bk3JbSbduCC8f /wAVUUds45a0fd7PH/8AFUe0j3Dkl2MuSxmmvUeWPCDowrSVZQghWLBB6gda0PNcxhDaTY7/ADR/ /FVLHduibRZzfXfH/wDFUe0j3Dkl2M690yC+siNm2Vec4qhplqba2kWVnLdlroo7vBJeymOfRo// AIuq0rF9220mAP8AtR//ABVHtI9w5JdhbCOQ2ieYm1/TOcU7LLKRg5NNjmmTaPs020dfnj/+Kp7z vjKWc2/1Lx//ABVHtI9w5Jdi5DEPL5BqYLmMkc1Qt72YL+/tJd3+y8ZH/oVTnUWwALKf/vqP/wCL o9pHuHJLsX4DuXOMGnKAz9OazxqRHSznH/Ao/wD4upU1RV/5crjP+9F/8XR7SPcOSXY0wFdcEceh FOSNY0CqAF9qzRrC4x9iuf8AvqL/AOLoOs+llcf99Rf/ABdHtI9w5JdjScOUIQgN2Jpy5AAYjPfF Zn9sjP8Ax5XP/fUX/wAXSDWR/wA+Vz/31F/8XR7SPcOSXY1D0pay/wC2R/z5XP8A31F/8XR/bI/5 8rn/AL6i/wDi6PaR7hyS7Gk6K33gCPen9FwO1ZB1ng4srj/vuL/4ugaxn71nc/8AfUX/AMXR7SPc OSXY1uMUmOe2ay/7ZGP+PK5/76i/+LoOsA/8uVz/AN9Rf/F0e0j3Dkl2NC6EZtnEv3MfNx2qDToY La0SO15i6g5zVZtXRlKtY3BB7Fov/i6F1dFUKtjchRxgNF/8XR7SPcOSXY1agkuQtwkRVssM5xxV L+2R/wA+Nz/31F/8XSf2wuc/Yrn/AL6i/wDi6PaR7hyS7Gpj8jSBFQ5AAz6Vmf2yP+fK5/76i/8A i6P7YXvZXP8A31F/8XR7SPcOSXY1eDVdWn+1MpRfI28Edc1T/tlf+fK5/wC+ov8A4uj+2R/z5XP/ AH1F/wDF0e0j3Dkl2NPmgn161mHWQf8Alyuf++ov/i6Q6upYN9iusj/ai/8Ai6PaR7hyS7GrGWLt kYGBiqSf6yf/AIH/ADNVYtXKSSM1rdMGIwN0XH/j9RLqRDSH7HcfNux80ff/AIHTVSN9w5JdjP1f VLnTpB5di08ATfJNiTbHyAclY2GACW69FPHTNC18SX15BHNb6PJJDJjDp5zL1UHkRHOCWzj+43+z nYvbx7jRL6yS0mEtxDJGpLx4BZcDPzVD4WuJNG8PWthc2krzQ79xjeMqcuW4yw7GtJV1fRh7OXYy pfFF3BLbx3OlNbyXBCxrKZlLE7OAPK5I39s/dPXK7ti3nluV0uae3a2leRi0TBgU/dycHcAc/h9M jmqPiRbjVtX0O7t7V1jsJ/NlEjxgkbkPy4Y8/KeuK0by9ee9gmSzmCxyFiC8ecbGX+96kUvbppps PZy7F9U2M5Riu87m9zgD+QFOy/8Az0b8h/hVL+0G/wCfOf8A76j/APi6P7Qb/nzn/wC+o/8A4usv aR7j5Jdi7l/+ejfkP8KMv/z0b8h/hVL+0G/585/++o//AIuj+0G/585/++o//i6PaR7hyS7F3L/8 9G/If4UZf/no35D/AAql/aDf8+c//fUf/wAXR/aDf8+c/wD31H/8XR7SPcOSXYu5f/no35D/AAoy /wDz0b8h/hVL+0G/585/++o//i6pX5N9cWYktbkW8cjNMqTqjMuwgAFXB+9tPXtR7SPcOSXY2sv/ AM9G/If4UZf/AJ6N+Q/wrH+yaT/0D9U/8D2/+PUfZNJ/6B+qf+B7f/HqOePcOSXY2Mv/AM9G/If4 UZf/AJ6N+Q/wrLgsNEklWOSDULdnIVPMvJSGJ7ZWQgfjjOeK0f8AhGdL/uXX/gbN/wDF1Sd9iWrb j8v/AM9G/If4UZf/AJ6N+Q/wpn/CM6X/AHLr/wADZv8A4ukbwzpgUkLddP8An9m/+LpiJMv/AM9G /If4UZf/AJ6N+Q/wq8/yNtX5VAAAHAFN3N/eP50DKeX/AOejfkP8KMv/AM9G/If4VD4juJrfw9qE sMrxyLAxVlOCDjqDU1ABl/8Ano35D/CiiigRhebR5tVMH1NGD6mvHuerYt+bR5tVMH1NGD6mi4WL fm1LIVS0jnDkhn8thj7p7fnWfg+pqxbXEcKSpcxyTQOASiY3ZByCM1cLN2ZM7pXRbZVW6S3aTD+Q biQkcRp7+9QxTw3Fm1zA7mJXCN5ibTz0PU8GqVpcySXl9eXMTH7WGjaPOCEPAA/DFRS3H/EuOn2k FxiRlMksyheFOQAAT371vy03sY3mal+6WEjRyi4LqFO4Q/Ic+jZ7fSpPJmBjBCgyDcgLqCw9hnmq MmptBb3cEAv5/NQoizBdiH+8Dknj6Cpb6aC31HTZ54riWeK0jYJEoIPJ9SMc/Wn7OD1FzzWhIrFg SWRQCAS7hRn05NPCSl5E24MfL7iAF+pPArNjuv8AQpWuLdxcS3BlykKS7VJztw/A+tSz3yXkuqh7 e5S2u/Lx8o3gqBzjODyOmalU4W1ZXPK+iLce6TfsKMqDczhxtA9d2cUkjNG21xg4z1zkVStLmKG0 u4UtpUjmCjLRIzZHfa3yn6ZqESy3FyHd7gqsYjHmxpHwCcYC8Dr71MoRUbp6jUpc1mjTuporSC2k lM7tcbtqxRhsbTz1YetEJkniSVIpArvsUOAGz7gE4qtd3uba0gWXUofJDbzajh8njneOn9aSy1Nr FFWCG6meaT969wcEJ9QT8x9e1XyQdieaauXfLk2SPmMJG5jdjIuFYdQTmnBCkd2ZQwaCBpQARzgZ HPpWe8donh0RtHcrD9v+T5QXPy5GRnB/P3obUWke9cWs6Qmy+yxJgbiexPOO56U/ZwWtxe0k9LFy ISSwxyhcCRN6qWAYjuQM5NEgaK3W4lZI4WzhndVBx9TVRL9IJLS7NrcPcwWvkqiqNhODgk5yOvoa qyu01rpVs8Uha2V97EfLyeP5VLhBa3Gpz2sa7JKiksAMKGK7huAPQkdcU2fdbojTskYcArukUFs9 MDOTVPUr95pZ3iFxG00XlssdvEQeMcufmx7YqG8cXl7bkxSbYbVIi0gGGYZzjn3pShBK6Y1Obdmi 95tHm1UwfU0YPqa57m9i35tHm1UwfU0YPqaLhYt+bR5tVMH1NGD6mi4WLfm0ebVTB9TRg+pouFi3 5tHm1UwfU0YPqaLhYt+bR5tVMH1NGD6mi4WLfm0ebVTB9TRg+pouFi35tHm1UwfU0YPqaLhYt+bR 5tVMH1NGD6mi4WLfm1HCYPs8JaCFmMaszNGCSSASSTUGD6mqzb/sybCd3krj67RVxbsS1qambb/n 2t/+/S/4VHMYPs8xWCFWEbMrLGAQQCQQRUedM9dX/OGqa7/sz7yd3ktn67TV6prUjRp6GjG0TGVp Yo5G8zaC6hsDapwM/U1LHHC8SyMulQhi21ZnVWIDFc42+oNZvOH5P+tP/oK0gKNHEGadHRSh2xK4 PzuwOd4/velOL7ikuxosIUleN7ezJUj5o0VlYFQwIOB2NQxmMzlHRXjTzdqsMgYcAcH0BxVRm3SE pvCBUQbwATtRVzgE46etAz50vJ/5a/8AowUm9XYaWiuacMSTtIIbO2fy1DlRGu5hnnaMc47/AFHX NE0SQNGJrO2TzFLhTGu5RnjcMcZ7fQ9MVUsboWc7TmNpJkX9xk/IrHIJbnJ4PAHqenBBfXQvJ1nE bRzOv7/B+RmGACvORwOQfQdeSauuS99RWfNa2g+Tyi8kaoqxyRDcqjAOSwPT2ArU0a7u57XTzdSy i1dVYTNw0kmB8rH+7nOD/FgD/ewhkydT/ql/9Ceuv0OVBoOnAkcW0fcf3RW2Her+RjXWi+Zp01/u N9Kb5yeo/wC+h/jSNKhUjI5H94V1nMQ3KJL5kciq6ONrKwyCCOQRXAXXw/3a2n2ebZpj5ducvH/s DPXPY9uc5wM9hf6zb2128RhvJSMZaG1kden94DB/Cq//AAkNt/z6al/4BS//ABNIZFr1rBZeD762 to1ihjtmCqvbj/PNaNYeuatHfaJe2sFnqJllhZUBspRk4/3a3KQBRRRQBlf2HqPpa/8Afxv/AImj +w9R9LX/AL+N/wDE10u+jfWX1en2Nfbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8AE10u+jfR9Xp9 g9vPuc1/Yeo+lr/38b/4mj+w9R9LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/wDfxv8A4mj+w9R9 LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/8Afxv/AImmDw5erM0oS1EjDBbzG5/8drqN9G+j6vAP bzOa/sPUfS1/7+N/8TR/Yeo+lr/38b/4mul30b6Pq9PsHt59zmv7D1H0tf8Av43/AMTR/Yeo+lr/ AN/G/wDia6XfRvo+r0+we3n3Oa/sPUfS1/7+N/8AE0f2HqPpa/8Afxv/AImul30b6Pq9PsHt59zl 5PDl7KyM6WpZDlT5jcf+O0/+w9R9LX/v43/xNdLvo30fV4B7eZzX9h6j6Wv/AH8b/wCJo/sPUfS1 /wC/jf8AxNdLvo30fV6fYPbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8AE10u+jfR9Xp9g9vPuc1/ Yeo+lr/38b/4mj+w9R9LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/wDfxv8A4mj+w9R9LX/v43/x NdLvo30fV6fYPbz7nNf2HqPpa/8Afxv/AImj+w9R9LX/AL+N/wDE10u+jfR9Xp9g9vPuc1/Yeo+l r/38b/4mj+w9R9LX/v43/wATXS76N9H1en2D28+5zX9h6j6Wv/fxv/iaP7D1H0tf+/jf/E10u+jf R9Xp9g9vPuc1/Yeo+lr/AN/G/wDiaP7D1H0tf+/jf/E10u+jfR9Xp9g9vPuc1/Yeo+lr/wB/G/8A iaP7D1H0tf8Av43/AMTXS76N9H1en2D28+5zX9h6j6Wv/fxv/iaP7D1H0tf+/jf/ABNdLvo30fV6 fYPbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8TXS76N9H1en2D28+5zX9h6j6Wv8A38b/AOJpg8O6 gBhWjUdgtzIAPwArqN9G+mqEFsHtps5f/hH9R/56J/4FSf4UHw7qBGGaNh3DXMhB/Aiuo30b6PYx F7aRzB8PagWLAwqT12TuufyFJ/wj+o/89E/8CpP8K6jfRvo9hAPbSOX/AOEf1H/non/gVJ/hR/wj t9hQBbrt6FZnB9+QM11G+jfR7CAe2kcv/wAI/qP/AD0T/wACpP8ACj/hH9R/56J/4FSf4V1G+jfR 7GIe2kcsdCvogzHyCSOS0zMT+JFS6VDH/ZNlkSZ8hM4mkH8I9GrfnOYz9DWHpXOlWYYD/Upjv/CK 3oUopsic3JK5Y8mL0k/7/wAn/wAVTXt42RlDTIxGAyzvlfcZOKmppDFlIbAzyMda6eSPYzuMEEYw MTN7+fJ/8VS+RF6S/wDf+T/4qljlEm7AI2ttOeKXepcxhhvABIB5APQ/oaOSPYLjfJi9JP8Av/J/ 8VR5EXpL/wB/5P8A4qgnyotzF32LyQMk/gO/4U8cKMknA6mjkj2C43yIvSX/AL/yf/FUU+ijkj2C 5d30b6kaBQM7m/T/AAqEYOcJKQCRn5a5Sh2+jfTcf9M5fzSjH/TOX80oAdvo30qIrx7wzDIBGQP8 KTy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2 j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfR vo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KA DfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5 D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cj y/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+ Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgB GOY3+lZGl/8AIJs/+uCf+githl2xvyTx7VjaX/yC7L08hP8A0EVrS3YMtg5JA7Uue2cZpoVQQdoy AQDjoDTs1uSQ20csceJpvOcnJO0L+QFTUgIIIFIxbK7VBBPJJxgUAQyzCBk3lAjcZZ8EtxgAd881 Pn3qrc2UN3IpuIo5FQq6buoYZ5qwyKVxgdc8jIBHSgBQSoAO5uOpHWinUUAabHIqurFYsgZJcgZO OrYqQNk1Cc+TkAnEoJwM8B+a4ZXs7Frcf5vrsP0fn9cU5HDEjGCBnqD/AC+lUL2+aC3Zo0eMZAJ8 ogDJAyeO1Ns55P7TaE3H2lGhD7iOVwRx0HXcfyrnp1JOVmOdo6GjB/x7p/uin1HCf3Mf+6P5VJXU SFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADJP9W30NYulf8AILs+v+oj4/4CK2pP9W30 NYulH/iVWeQP9QmPf5RWtLdgyyWGSNygggYNMaRklCsBschU2gk55Jz6DjrTmdR1xmlDgnityRSA OeeKUDGff0o60hUbg5JGARjPH5fhQAuT+FIE2liufmOTkk//AKqU9vSloAKKKKALi5DDIOPpSKXU EBQRknqe5+lRf2HF/wA/d5/38H+FH9hxf8/d5/38H+FcgyYs7KQ0akHggk8/pUcESW4IgtoYgeSE G3P5Cm/2HF/z93n/AH8H+FH9hxf8/d5/38H+FKyAnjBVY1/ujB49qkqoNEjByLy8B9pR/hTv7HX/ AJ/r7/v7/wDWpgWaKrf2Ov8Az/X3/f3/AOtTJtNWFVc3t6RvRcGXIOWA9vWgC5RWRKgN5feZcXix QeWFWFmY8j0AJNJaJbXjEQXmqHGcl96Dg4IyygZz2osBsUVR/s1f+fy+/wC/3/1qP7NX/n8vv+/3 /wBagC9RWathm4kj+2Xu1UVh++5yS3t7CpP7NX/n8vv+/wB/9agC9RVH+zV/5/L7/v8Af/Wo/s1f +fy+/wC/3/1qAL1FUf7NX/n8vv8Av9/9aj+zV/5/L7/v9/8AWoAvUVR/s1f+fy+/7/f/AFqP7NX/ AJ/L7/v9/wDWoAvUVR/s1f8An8vv+/3/ANaj+zV/5/L7/v8Af/WoAvUVR/s1f+fy+/7/AH/1qP7N X/n8vv8Av9/9agC9RVH+zV/5/L7/AL/f/Wo/s1f+fy+/7/f/AFqAL1FUf7NX/n8vv+/3/wBaj+zV /wCfy+/7/f8A1qAL1FUf7NX/AJ/L7/v9/wDWqKO1glmmhj1C8aWEgSL53K5GR29D/nFAGnRWdDZR XEEc0V9fNHIodT5uMgjI7U/+zV/5/L7/AL/f/WoAvUVR/s1f+fy+/wC/3/1qP7NX/n8vv+/3/wBa gC9RVH+zV/5/L7/v9/8AWo/s1f8An8vv+/3/ANagC9RVH+zV/wCfy+/7/f8A1qP7NX/n8vv+/wB/ 9agC9RVH+zV/5/L7/v8Af/Wo/s1f+fy+/wC/3/1qAL1FUf7NX/n8vv8Av9/9aj+zV/5/L7/v9/8A WoAvUVR/s1f+fy+/7/f/AFqP7NX/AJ/L7/v9/wDWoAvUVR/s1f8An8vv+/3/ANaj+zV/5/L7/v8A f/WoAvUVR/s1f+fy+/7/AH/1qP7NX/n8vv8Av9/9agC9RVH+zV/5/L7/AL/f/Wo/s1f+fy+/7/f/ AFqALcn+rb6GuU0+9zp9vGvylYVGT3woroNNLPo0Ujszu4clmYknkjv9K8tXU5mEa4OyJSnBHHb+ laUt2D2OyN8AM7uB+tXLW4EnYgY71xEV60zqPMIAIHH61tWM7LKo3HGOBW4jqo2LDJGKQBnMgkAC 5wpVzkjA69MHNVbG6Scbgwxkr17g4NXu2MdaAA8Y6+lNRw6kqc8kfkcUixKDjcSoAG3sMd/8+lPK glSQCV5BI6UAKBx1oqNFlDyF3VlJ+QBcbRgcH15zRQBv0UUVxlBRRRQAUUUUAFVr7/UL/wBdYv8A 0Nas1Wvv9Qv/AF1i/wDQ1oApW3/IV1L/AHo//QTUEFo02mTQtmKQzzOjFfut5rMjY784PoakijWT U9SDbvvw/dcr1GOxHrVgwW4cKRc5zjPmS4/PNNiRg3Z+3XFjeXds5RJjCIUO4j92/m9MbhuG0jnI jOM7sF81u7WreRBssvte4RPbMyiPysf6oYOPM5xjr83vW1Bp1rtSMxsPJxs2zPhRggbeeOMirH2C D1m/7/v/AI0hmbo6eWjrvL/IpGYmiwN8mAFbkAdAPQCtKobmGzs4HmmM4UlVJV5GYnOFAwSTy3Qe tRI2ntFJJvukEeNyyNMj88DCnBOTwMDk8DmmBboqh5+ndP8AiYBuylLjcR6gYyQOMnoMjPUU5pdP RUZ/tyKw3bnW4VVGSMsTwvTvjjnpSAu0VHPbWtvBJPK8yxxKXdvOkOABknrTbaC1uYy8Yu1AOP3j TRn8mwaAJqKqQtp885hR7reGZAWaZVZlJBAY8EjB4B7H0pyfYHuTAslxvyVBMkoViOoDZ2kjByAc 8H0NAFmiqH2jTeu69KdnAn2N6Yboc9sHnIxnIqSJrCV0QG9RnbYol8+PccFsDdjsp/yRQBboqOC2 tbiCOeJ5mjlUOjedIMgjIPWpPsEHrN/3/f8AxoAKKPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo+wQe s3/f9/8AGj7BB6zf9/3/AMaACskW8y3l5dRRnzknGwHgSRmOLeBnj+Hg8cqOcZrW+wQes3/f9/8A Gj7BB6zf9/3/AMaAOVu4Zl0e1X7MRPHYoI2Nu8riQL0XH+qYHHzHrkf3auS2gne7uVhmEkl3D5b4 ZXWMiIMV6FeNwJGDxg9ON77BB6zf9/3/AMaPsEHrN/3/AH/xoA5+6tZEjliihC2iXgPlmAyR+X5I 6RjG4bznjvz2NamlJ5enxrvL8sRmJosDccAK3IA6AegFXPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo +wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAaPsEHrN/3/f8AxoAKKPsEHrN/3/f/ABo+ wQes3/f9/wDGgAoo+wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAaPsEHrN/3/f8AxoAK KPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo+wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAa PsEHrN/3/f8AxoAoaX/yAoPo/wD6Ea8abMkzANt+YjjvXtkKJHYeXEpVEaVQCc4wxrw8K32xgpxl /wAK1pfExdC1bs6qu1Mjsx7Guisz5U0PmsMjG48DPFZaxt5ITcRk5LHtWhaKjzRszFyPmPBxW4jp bSSN5QYySQcZ54FbC8jNZVgVaYlQQMYxg4+taqZ2gHqKAALh2bcSD0XjAp1JRQAoooooA26KKK4y gooooAKKKKACq19/qF/66xf+hrVmq19/qF/66xf+hrQBRt/+QpqX+/DViaAM7HYDk/3R/wDEmo7E A6vqeRnmP+RrSpsSIIF2uVxjEa/1qxSYGc45paQyhrO77CGVHfZPC5CIWOBKpJwOTwDVadory4W5 khuPssMLxtmCRXLMyEbVxu42ZyBxkYPBxsUUAYYl3Q77h74MrkW9ylqxlKYXduUJgfNkYKjO0HGQ DTrq6llghtL+CaMSwK1yYYHkBJGGjUqDjvk5zjGOTldqigChrG6XSdQgjR3kNs+FCE7iVYAD1PHQ c9PUVPAjW6qktxNcM7cO6LkcZx8qgAcHk9z9KsUUAZOmWDAmaeSY7LmeSOFwoVCXcBhwCcqx6kj5 vpiGGOQ6dZaZ5UouLcweYxQiPEbKSQ+MHO3gDnkZAwcblFAGGjxZkjWO7bTgmWje2kUwtuXYIxtD f3jxnbtGNoxTovtM0tkziaWOO8YpJLHscp5LjLDAx8xI6Dt65O1RQBS0ZHj0WwjkVkdbeNWVhggh RkEVdoooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KAM9P+PR/wDrpN/6G1eGSHFwwA6sTXuaf8ej/wDXSb/0Nq8dtIGa4YhRy351rS3YnsWNOtpJ4y8j ZfPyr6D34rpbBZNqcbYumODk1TiRoxGAMLkZPetq12yZ4IIIyMcVuIv2qKoG3P4ire4CQJhskE9D j8/xqKLgjH5VMDxQAgABJAwSefelIBGCAaB6c0dqAD9KKrXk11Fs+zQxy5zu3SbMfoc0UAdLRRRX GUFFFFABRRRQAVWvv9Qv/XWL/wBDWrNVr7/UL/11i/8AQ1oAq2H/ACGNT+sf/oJrTrMsP+Qxqf1j /wDQTWnTYkFFFFIYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAZ6f8ej/APXSb/0Nq84stOmktonRdsgO9SRw wPY49a9HT/j0f/rpN/6G1c3pX/IPtD32KM/8BrWluxPYzoIN8bGRCpLAlc9OBmtW0hESrnk+tOu1 VVfaAOnQe9WIAAcAAAdPatxEkSOGUgqFwdy45J4xz+dTc5Pp6VHCSQ+SThjUp6mgBozvOSNuBgd8 /wCcUkhZQCoycgYyemeT09KX1PenCgBjuExkE59BminUUAf/2QplbmRzdHJlYW0KZW5kb2JqCjM1 IDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCA1NTAK L0hlaWdodCA0MDAKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVjb2RlCi9EZWNv ZGVQYXJtczw8L1ByZWRpY3RvciAxNQovQ29sdW1ucyA1NTAKL0NvbG9ycyAzPj4vTGVuZ3RoIDE2 Mzk3Pj5zdHJlYW0KeJzt3QlcFHXjx/GZ3YXdBZZbUA5BQFHDW9EQLbw1NY8K1Kw8y8wOy3w6/PdU lqZlmaV5dJtWlpZHpuVjeWR55F2IFygqKsgNy17z/+2Obtses8ty/Bbm+3568QzLzG+GFfbD7PVj OY5jLEwY0pkBAACoDR//8Kflp6w5OTNGdiur0r/+zERfpZyVetE4NgAAaCQ4vba8sur5Nz/yk0uX bDjAX3gzOeTk5qUZ4wJVPgZ1ib6y2KAupnqoAADQsLEyOStTSJUBRVfOvrr2IH+6Y0wO6c1b/5mk VxcbKotIb2gfJwCAWKzYcqyGI0y9q72HjyZThV++eH7xxpOkOsbkpPfr+P6LE7U3stEbAIB6s3Lr iQHD7+3UNt7tEQ7/dXb7xnVTBid5+GiVGt2LXxz96ucjbFq31l/Om6qvLNIUZLs9NAAAVNeqH/96 9tlZldn73B5BGXv7ggULJw9q6+GjkeQYDMxjH/5pTM7a1yap8/42aNVuDw0AjHeXZvfPVDB/X109 t0JD+2CgIfhwe+YzT88sP7vH7RF841PffGvRpAGtPXw0oqJKN+PjY2zntnGbF00tv/Cn1dpLfimW yJVOB1XpC8alNJVKWLcPCzydV9uw9Jf8lSUlmx+/dqXSfLGk2cMxQ/tIK/936avllVqGVXUJ6jbK v3mCzIthtPnqC/8rPLCxvFTLr8z6dg3u/UBAVLiEfMKp9Td25W36sFJL5xu6ybtr5IOzbH7E/7ry 6cvl7gXj5oD75/SZ3mF0XEfvGh8hNHYf/ZQ186knS7N+cXsEVas7F739zsT+rRyNtvaXLIHNx9zZ qlqjncguOJ5dYLUhv4t2sSFJsSGORmNMyZmw7IgxORsXTi7LOWh1KE/uDLpS4fyXJqhw/zv3RSm8 pU7XhAZL5t1hQYuUGPWuJ97eeWFUmMR0ob/f4A8iY+UXlt41+csbT0568I6xj/gyR/cueHHZz3lc 0vhZCx/vyO3/c/VCX52BkYQF3v1+eNOiY/PHvbQ5X94qbfiYzpnLlnS/s2kCxWfjeydHT5rtYyzE g3vLLL/g+8i4mA5uBOOfASeVRASP6B4aIautY4XG6eMdp5964vHizB1ujxDQuu/bi9+d0Lelo9G+ 2nV2zuf77W776vjk9N7/eqjG9dHM29peYnc0xpScyStPGJPz3RsTyrIPWB3NXsWwgQMGsBIj1vh/ txb//f/z/vPI6BaFSE4jp0hRPTg7Snpo0dhp/u2b9vRnGb/+sQ8+ptTumXv3w39Im457ZVNGZ/np uX2nbbnRMkoRoZTKu7339IwuVTsf/2h3dt+mXaMn/5+f5NR7I+7dL1Ek+LBajTb3hiGsRdDQLv27 PPK8D3Mu/7fTPu37+Ph5Merskj9X5B0+qb/5gjGpd6dF8T1jjYu6gspz31/dtbFSbfoa66dMejCs U6qPvw+jyS7+fUne8TMG8hVJkG/nKWEdeiiUUqbqQumRD/MOHSHhs+bdPWbq87cK4dtEcutySUji 1NX3pvhX7n0y5/AFjvGWd369RUpL/al553dzkZMdH+2/Bgy6Ozmh5e2PhLXvJpezTFVu2bGP8w4e 1OrNq50vOHDZr0NPudeJ3JUvlOocHLPdlXGvXWPxyf/OPjFjeuHJ7W6PEHTbgMVL3n+oT7yj0dbt zf7v2sN2t/3vmE738r9Zbo1GNjd+tPhUYDTGlJypH2Uak7N+3gOl560z+IffKFeS8/qzU0fE5CM5 jZ2C7b7yth7BOUuHLzpW8UBrX//kJS1TmhdvuH/s/KNxbXtOe/+Dtj6Z7959z6+MT8cg79ZxvtHB Q+Ife6JJ8fqZ495I6dO777SFQUqG0V46fej3ihuZsnO/nTxdqmbY6Fb9kqfP8WWY8r0Lvvtuy94z Tds8s2pGT9/c9ZMuX7jmw5IAhAUk9y7a/tmz2yoiBs1798U+0v3P/bLraJSXt7zrwpY9W+pOLXn7 /z77X3FM2gOD/Q+u7dpcFdjjnYQeMVV/vDjnvzvVoz98d3LrK99Pzjl/xc/q3l95jxaPkF3zhQgc 1tm/qfmn2KuV5O6320Ze/HnRU+GxDyWOGup95eMZYxbmtBj1+cdzAxwdrcJywPCxMz7p3j2q7OcZ sxcc85u0+o306Gubp545fclfya/GXN/0n/Xbdu46XHJFFzDr7a8Gp9g7ZoXtysop9zZrh9dqNwqf /XJ+xqOP5B/b6vYIoe0HL1n6wQN3tnA02vrfL7667sSce5OsNuQvHNUjulqjmQe0utB2KKvRGGNy 9NM+PW1Mzrdzx5Wc+8Nq7QMB9w0aPOhmWcyhseyPaeG1WVOGR+UpvJCcxs5/dLMpU5tc+2zmw0vv TE1OefjdUL/TK+4dtb5EcXuLtOlLF4RKDv6334N5TVQd4/1TglhG0avF9BdV+r0vDHpU2zJsXO/7 pb3HJkWYbylLr/34VN7Ji4z89rjH/uvHnP/ovru/zJelxMjloeMnLnw0PP+L/zy9fEQ7pbE6Bt3+ Q0VZUqmfX5/7l8+PK9/67LhX7uzdrfvD74b4XvgkfeiafFnHpl5+jOFqoS66U+rkF5aE+mR/dN/w dUVeXVuNmPrenOiCtf95ctnwDsp/Vefmrq0cy35vVonakF81MHLWM4nMxetsdBPmwMqMSWuvSbq0 GTBjxYLmjo62a5+kGWRAU3Jie85674Mon6z3R476Ua3o2nbc1Leealb49ezH3hvWo09H42rGQm+t UKREyqSypIFvreoSYO+Yk/u0t1rZwBgYWXKSb1P8zjV8n/+aM33alGuHN7s9Qlinoe8vWzn+jhhH o3134PLrG049PzJxRLcI4QtdGc1yc/OntuPYjsaYkjP9i/PG5KyZM7ro9F6rtU9ETBw8ePCt1tyM Dmv6n+Ulr8ycMDA0W+ElsdkdNC5ssHzkNx1v0+x4csiBxP97Zlp/7veZGU9uD471axnZ6aFXl4UZ z3LSz/j59I6XRHsxbODo22bM9C1e/8Twl9gYv8Et2ItZmt26+Ojb0yfOGBVH0lO6ccEzr/eMv7Pd s/P9mYMv93vwYogqPkjSOaZPl+fmhhr2vTDoEe82/kO7PdCi78iAZqH/3MByf8zpP0V926AX3lkQ yB56ud8DF0JVCQFsxyastpwp804dOH9BiNUJDff7iwMflrbxGxTK/POTKu/Vxrhr28dyvMYPUrWV Kop7fjmgXxPy+Y11GePePNkizjci9I5Hl7wR7OhoOw9+aj4/4KSShEFzli8MZQ++1PehvDC/VjF9 Hpr/eghZbeAjks6DZ73BrzbherhffIi0S1Rq19kL/O0ec+fBT8//98pNWF/8tjUWa3+7POXhRy7u /97tEaKT7165/IMxKRGORtt65OriH84+MSR+cMdw4QtdGc1yc/OntuPYjsYYnyetf3r9dWNy1v4f Sc5vVmsfbzZhyOAhrPRmY2zac/Ms55WnJgxsguSIAtt0ZuvJoxQH5n+pfHp8UvHmyQMWn2Nuj/RO igvumP5tq7beR17uvyKzckgbaZhE4t3+3Q7DO6p3Tst44beW8T5pCdIAjSHruuFyma44ZMKTS6ZH anc9N+gxZfJdT86b5288bxh1xEuREi+Nb/Zg0rQpyvw100fN82qd+uziZRHKa/tefuCNHy+U+g9d sm1BW/42vUX3pxevau6X80n6iD9lipQ4aZzcdJRet8VOXx7md+q9EaPXX9ZbHL6sfWvVXS0lAeZb dnmv1rPm+ds+lmMk6Zo6pffUCT439h8xJHcMPbN2xqTTJZq2iXcOeN7x0bYd8tIHbwTdPMtJeWbJ 8mjfU++PvC/L16d31zGDn3zcp/Drx0a8Kmsz5P8+IN3i9+vXO14a7eP4mDtbjMmvjLvUGpE1e8nN +sO5+7+zvPCHI9cENhnSMczy06jkESuXLx/bM0JgNL4ulhvavdCV0czbWl1oO5TVaIwpOTO/vWZM zpcv3WsvOQ8NGTLkn9JIrNpz8/9NZzk5SI4oSCJ9xq29rblp+ezCB8Z/zET6tw6V3RElkQfcHTrl 6Vj972vmz/fxVsfF3RN7z2R/bt87Yx/+ocg7JTF16qwh3PEtheczy0tYdYsnut4/WHFkzrhHv2/W fvAc4+0vU7533uJPt3VIbJU0fFFMS99zS4dNW32xw209n1iyNFJx6ZtHM7YWh/R/aHFGf3KSfvMp YaMeXN67f2v1gbfe/WhLu4QWrXvcofltVanGS9lj2W19WxVtn/Peul9kkuAmbdI63Rl3atnr59SS TvGyMPPpkjy19TOvq27dmg9o5fXPlxSdYya/E+af+fX4sZ9IJ77/8WMtrn256LWlt8ekJhk3cXC0 7QbNXv5GyM0Bm9w3fU3P25te/nLq4m1XRj3yQffukVc+vWfiB6fbkdVWmFfj9+v4mNk7pn1gtTKF f3moI2v2XpoydWrugX9H4vC1d2xu03lPklv2Tv+ORLcRK1esGNszUng0sqHVUPyF7o1mPhh+HFeO jaggyfkmz5Sc/95XfMYmOU3/nZybD+r8c88af7bz8lMPDQq7gOSIg0QSNzcpvac3o973n34v/lbe PUbRuoVXWyXLcGxhRZeitIfu7NmuiYJhtNdLTm74bO7SDbn6xFjf6Gbtxk9/1jc8Jkhleuqx/kbJ 0bVvvLDs9wrvlDb9nzIm5+/PlpzsOnZE2xAZU3nuzLpXn132uyFY1TlckdZ3SpN+Ga3DvZjys+d+ +y2w//hb5weqga2DqsImJgwb3K6ZD6M+m/+/17d8edSnpW8LmV9uk8kJdw1KaqYkdVDn7Dq3beVX W8637urf0vJZy/LUxJmvqay/xyNn3nmZHfhpfBvv0wuHTf/mSkxMYFK/hY9Mvb1qxzNf7JPf/yLZ xMHRxvaZ8f78IPPh3RYrue2JDv27G4+i6uLlrQtmLvy5zN8vuUXfGUstVmvNV8TBMfccMvTZ11TW K0Mj8cWe3KlTpl769836lsPX3naQnKeGxN/175v1yG4jVqxcMS41qp5HM29re4nd0RhTcp76+oox OV+/nF58xvpdDY6FPzjkriG2j+LcXLj1+ctPTRgcloOnD4gFx50+dmPlWa2BYUIjVe1D5XfEyXxN d1UZtLrDpyv3X1LnluuryJel0mA/r+hQ72C5NCnOO4bVrNldeqpMX64zPb9ZIglUecc1kQeF93ns 7dcDjDepEy/7SG8UaYo1ZFtJeIhPq2BpSJg8JYQ5crT4x4tVN7QM4yVrHSG9nFNVwsjatVINaiNX FVdtP1V+PF9brOXIV9s29+3RVNa0iZe8WL0ts+KvfE2R8dWmbHCQvEWId0KgV4sor1DLv46qKt7c UpJn/U16PzQ00HA4/7NLhpBmqnYB0sTm0st/FW/J1Ukj7lr93ZtNBI5WpV5kHJA/PG9FgXrz3+WZ hbpK4xUiaRKsaBXsFdRE3itA/fY/q8nDTb895YUOjrmJ9pOt1itD47B6z8WpU6bY3qwLbGLvZn3l /anR9TNa1pXy03nlVhvyu2jZ1LdVM19HozGm5Dzx1SVjcta9klF81jo5HxzggkONjwiR5Nz6yC8y lhcW5Pw1Plklx1mOWHCaMs2+XAMpB8ewYdGKrgHmHwpSHcOFa5rzJZxaz5leBsP6qWStm3mFk3Mb zpB9WXO+2KA2PuGKx/qqZLfF3Zny9Kt+tx5QiVMwFVrG+BoXiSQs1Kt9E6mcZTTl2hOXddc0nPFy VqKQGjQ6MoikaxtFuJQrKdZmXtXduLkV2yxc3j5EIuO44mJd5jVdoZbjX98jV0hjw7xbqFip5aP0 Bv3RM5orZGTrb1PSKoS5UEiOlg2NVCQHsVUlmj8u68q9e4//YEFzgaPlzAOaDk9iuHpde+oGCa3p u2bZkFDvDmFSpdVqfEUcHbOv4cRZm5WhUVi9++LUyZMvH7R+vMR1EV1HrFi16v5e0R4+GmNKzuNr c03JeXVMydnfrdbW6Ax6A2cziDVyeyOXSVm83w24R56S8Pgrt5LjPyRJ6dE3qQ3raMHjfb7rwsOT J9XwZn35qg/H927u4aMxpuTMWHOBf13O2JKz1q/LAagnVWXzvy803XHkf1c7j3+5ScM6WvBsn+/K SUkbmBQf6fYIJ85e+m3ntvG9Yzx8NIZ/Xc6abFNyXhtXavNSUIB6YtD+mVl52XjHkay759+IN6yj BY+3fNsp5ysJenhgYoMYjSTn0dWml4Kuf308kgMAAHXH+IY3n591+O4DAAAAtejRL02vyxnZpQnt IwEAgEZuw6HrbK+UHrv27ivKv/niBE4qp3tMAADQaLD6Kn7ham72lOlPWScnMLQpvWMDAIBGxRwX +8nxD7Z+azYAAAD3lNy4+fYH9pPjFxhK79gAAKBRKSvK5xfsJ8fHP5jesQEAQKNSUXKDX7CfHKUq iN6xAQBAo1JZWsgv2E+O3DfAdptevXpZXbJ7927+QrJgXoFfrgm7O7JdwelOa+t4hI/T9tisrhYA AJGrKi/mF+wnx0tpM4EIw9xxxx3k46+//upoUKcruMjtHdXWAbjOao/k0/rcOwBAg6CtLOUX7CdH Kve13SYtLY183Llzp6MLrVbgP7XdxCm7O7Ic0HJY88qWXxU+HtsLzZvX8FDJp65cFXa/ajsIAEDj oK8q5xfsJ4f1Utpu07dvX/Jxx44dji60u2x3K2Hu7ch2Q9c3qa1DJZ+6clUIHKflIAAAjQOnreQX 7CeHkSlst+nXr5/lpz///LP5QoFlywtd5N6OrJbd2MSNQ7X6ToV3LXCh5eXVPQAAAE+nU/P/bz85 Bom37SYDBgwgH7dv3+7oQttlM6uthLmxI9tlNzaxu1/Xj5YsCOzazGpf/FZ2BwEAaBwkBg2/YD85 OkZmu82gQYPIxx9//NHRhY6Wq8vtHVltWN1N3Dtm81ZkwemuHW1ldxAAgMZBRqpiYj85GoPEdpsh Q4aQjz/88IOjCx0tV5fwjvgFV3bqyrHVyjHbbujKsAJHCwDQmHhLDPyC/eRU6Vnbbe666y7yccuW LY4utFqB/5RntZUwyw0tNzeP78pOrVZzdDwCQ1X3gC03rO6ua7J3AAAPJ5dy/IL95FRqOXrHBgAA jYrS6+ZpjP3klFfprTa4++67bUf5/vvva/3I6m1HNWf3UBlPPVoAAFp85VJ+wX5ySiu19I4NAAAa FZXSi1+wn5ySCg29YwMAgEbF3+fmC2/sJ6eoTE3v2AAAoFEJ9Lv59gL2k8NJ5fSODQAAGhVWX8Uv 2E/O2ZxL9I4NAAAalfiYSH7BfnICQ5vSOzbwIIWFhbQPAQAaPCdnOf7BYeRjcXExtQP0PAEBdqat M6u764rufvEzAAA15yQ5qqAm5GNJSQn/6bFjx2plr+3bt7e6pAGN7O/vL7Ba3V1XdPdrHh8AwG1O kuMXGEo+lpbenMeN3JzZ3qZXl91BGtDIKpWdmVLN6u66ortf8/gAAG5zkhzfgBDysaysjP+0AYWh 7kb28/MTWLPuriu6+zWPDwDgNifJUaqCyMeKigr+0wYUhrob2cfHR2DNuruu6O7XPD4AgNucJEfh F0g+VlbenDq0AYXBxZENeq2uophcDzIff4nUy5WRlUo7k3ObVfe62nZ2S/+4wRLWziQRdbpfYbb7 NY8PAOA2J8mR+xqfraRW33wPAorJyc3NZVk2MjKyFkcmvTn0brq+qkwiY+V+ge2mrHZUHctBFAo7 k3ObVfe6mrP92eaq2Cm3P1rP+xVmu1/z+AAAbnOSHG8f47OVqqpurkQrORcvXtTpdBzHeXl5RUdH 18rIpDcH3x7hExTgHxnHSmXl1y6qy4vbT1prtzqWg8jlQu/IIHBdlWiLTtw4+nfByezC84WlBVVq rUatiQyO1Gi0iaq2U+6YVkf7dYPtfs3jAwC4zUlyvJTGZytpNDff3LP+k0MyQ3qj1+slEuNdTyQ8 ZCE2Npac8dRkZNKbP98dpQwMDIhuSa4ERiJlpd7FeWcqim90nvSFbXUsB/H29hb47hxdVxfLc369 8nNx1Y0AeaCPt6+EZbUGrVanIx/V2qpDR/9MDrt9ct+Ha32/hUcf8ZL5sv/cccdpNSX+bd9gJRaj ketSomBZqcB+zeMDALjNSXKkcl/GdEPPf2r35ptUIS8vr1mzZi7uslrJuXz5Mn+XjlQqJTsyGAzk YJRKpd1zHRdHJr05/N4oZVBwQGSr0qvnywqvchJWGRihCk8suJRZdqMg9THrcx3LQWQymcB3Z/e6 KtYUbcxep2d1Yb5hZZoyCSvV6rWm5Gg1Bq1Grz108M9u4T1mDHlC4ODd2C9RsG94/OBfjYU2TrbH MSyrU+dfOzqXu9VsiRf5q8Kb9WsnD71DYL/m8QEA3OYkORJv47OVyEkG/6nd23RyFqLVauPi4lzc pRt3rJ0+fdrLy9gA8rc2iY2jB9JdGZn05uj79yiDQlRRrUrzzlWUFTS7azG5/PyGJ+Q+oX5N466f P1V0vWDIC99IZF52ByHxE/ju7F5Xuy/vPHT99/iQeK1eV6wuyczOPH3+tIac3ag1URGRpDwdQzo/ M2K28Hfkxn6Jgr2j4gdv1eQt02ukjMSfZVWKiL6kM+QvBXJlMJyBdIiV+J37eVxQt+UC+zWPDwDg NifJYb2MN+7k3IL/1PY2PTc3l/SGP//g/s3yEsut3EhOVlYWf/cOOeNp3bq1o9WcjmzszfJ7lQGh qsjE4qtnKooKgvvNbxEXL5FICvKv7V85WeETGBDR/NLpMzeuFI9b9L30VnUsB+Hv4nPE7nX1wZHF Ui/WT6kqV1f8efxw18jkialT+S/d/86YVk1b/V/Gy06/Izf2SxTsHBk3bKM693POwBmqbmjLr+pZ iZeiGcNpGYOG48i5i07Venb29ntCev0zh6ntfs3jAwC4zUlyGJnx2Uqc8S9iI6ubs0uXLpHTDvNN Ib+a5Ud+oaysrEOHDuat3EjOqVOnzMlp06aNo9Wcjpz51ZOMoVwVkVicd7aiKD9s0ILmMS3MDwvl X7/284IHFX5+wVFNL2Zmc9KwcfNW2Q5i92EkM7vX1TPbZpSUF5PTGkbL9k8cOK7Hg+b1P/xp5UN9 Jx7M+12vNxiM/xGGtFb9amW/jDE5d8UO3lB27htOU6Ytva5qfZ8ipI3p0Rv+LIcznuXIAk+v7xWa tsnulcbv1zw+AIDbnCTHYHqQ2XxjZ5ucqqoq/lEW/hK71al5cjIzM/nnTVVWVrZt29bRak5HLrlw 6PSW/8qDooqv5bV74ENVQJDVqUNZSdFHjw4nZ0HXcgpGz1nUotPttoMI3/java52ndtJcsJHhSRl QLtBe/N39mrS17zVxlPrt2duLSsvq6qs8jJ4fTblq1rZL1GwfVhC+m5yQsMHhiOnK5pLuqKfOX0x pyP/lXD6MkXUC+c2TgodtNnulcbvVzh4AACucJIcPWu8Z8l8u2x7m37x4kVyokNuj3Q6HX9PmtU9 bIzpNqtjx47mTdxIzt9//61QKMg4JDm33Xabo9VcGbko51DOH18eq2w75eFppJevvfYa+e5Yk9mz Z3t5eS1fttRw/Nc+Dz5q7o3VIMJ3MQlcV2bf5359oSR7Rttn+U+/Pv7F7+d/a9+qHSuVXLl2peRS +ev3Lait/RZsGRY/5idDxTFjY/SlnK7IoC0ky4yu6H+nC3/N1hdXVmp16i6yG2Mf2ibw/QrfrQcA 4AonydExxmcrmR+4tnszev78ea1WK/CovhU3kvPXX3/xL0isqKhISkqq+ciffvrpxIkTyY3p/Pnz 4+LiyDeYnZ399NNPk+S88sor5EthYWGOBhF+IF34uiJ+uLQhp+ycTqs7e/VslVqjUWsjgiJiw2Nl 3jLjU9eO/tmn+YD7bs+orf0WbBgeN/4HfemvxnMa45lNkWmhcFtm4XG1qkubrlHBLXee/O73E7s7 hw+dMmiWo/0KP3kBAMAVTpKj5Yw3NOan5zp6knRubq7AKzStuJGckydPkp6RHZHktGvXruYjr1q1 aurUqWTAN998Mz4+nk/O448/TpIzZ84c8qXw8HBHgwg/XVj4utp2adOZ4syEkJbkdlxr0BmfKm16 tnSJukQqkZ3LPi8rkj855OnwwPDa2m/+l0MTJm/RFm40xabo5v1p+uLHNxbdPWQoI5UMbzPjrR1T pYzk200/bnzpsKP9Cj9FGwDAFU6SU6U33oNvfhEirXcfOHHiBH8KVV5eLrCa05GvVl6+VJq769wv WZlZQ7uMGNph+KJFi1q1aiWRSMi52vTp03+8/P32Uz+qdP7tmnSK8I3qEZ9iO4jwiyKFr6ttFzaf LDgaHxqvNxg0BmNvyJlNRWX59cLrly5dbsI0HddrfLsY+8/uc2+/BV+lNx/zgbbgAGOo4Dg1Y1Az nJrTV41du/HRMdMH3zaJX23T8aWvLZ+79dWTjvYr/EJUAABXOEmO2vSHtfmtVmgl5/jx4/z7GVs9 E6G6I7/6x/Oc3qDy9SsqLyo/q3v1nnkffvhhYmIiOcs5e/bsmDFjVmW9F+TvX1xZdO5izqmjZ7c+ 97PtIMJv/eL0ulr315qT+cc0Gu2ZnDMataZKrfWV+rQIie/SoltaUl/z+U1t7bfi2Ne6/ExN7iGD 9l9vBT31wtVhwwboGMN/+n88f/sEhVTu6CyH36/w2+0AALjCSXIqtcbH/81vKEkrOeSrdp+JUN2R F+2bn33lvLdOceV8XpA+JNY7TqVSSUxYlj19+nRlk7Iin4LggNCzl85G+EUte2S57SDCb3DpynW1 ct/Svy/9veieJQLj1MV+LX3687t7LnyZ0j61ZdNOp/MO/3ZsT3LESLuP5fD7FX5TUQAAVzhJToXG +Gwl8/MCaCXHo0YWfht/V64rA2f49uDX93bLqOf9Wvlo+6LN+7+srCpXyn2HJmdMHDBTYL8uPjcE AECAk+SUme5Z8/X15T9tQGGou5HLy8sF1qy764rufs3jAwC4zUlySiu1jMUUyA0oDHU3svCUzHV3 XdHdr/A02AAArnCSnJIK47OVVCoV/2kDCkPdjVxaWiqwZt1dV3T3ax4fAMBtTpJTXG78sr+/P/8p uSWqlb3aDUNDGbmkpERgtbq7ruju1zw+AIDbnCSnqMz4bKWAgABqB+h5iouLBb5ad9cV3f3iZwAA as5Jcm6UVDjeFkQkKCiI9iEAQIPnJDmcFC8ABACA2uEkOWdzLtE7NvAgrs/6CgDgiJPkLPx4I71j g8bsmcn3vrlqHe2jAID689qsqea4IDlQT0hsgoKCCgsLkRwA8SC9IR9dSg6/KkDNvbBwBf/jZE5O nf50mXcHALSQX0MGyQEqSGn4J79ZJocs19HuyC7qdHwAcMryj0skB+qV3bMcJAegEXMnOTm7x0pY BctKbg3C6XVlUT2WsRKLmbtYhpUqWRYzFoNDjpLTv39/25V/+umnGu4OyfFA5N/a6l/W9hJoTNxJ zpkfesUP/pVlWcY0bQ3Dsjp1/rWjczmW5deUevuzrNynSbIqws5tBwDP6VlO7d76IDkeiP/zwvJf Gclp3NxJztktfeIG/aDJW6bXSBkJqYtKEdGXkXgxxpnTDAxnIB1iJX45Ox+I6buW0vcFDUB1k2P3 L2LGdINlPjGyWt/yQiTHA/H/ppb/slbL/ILVVy1DZTdaVluB53ArORvSWgz9Xp37OWfgDFU3tOVX 9azES9GM4bSMQcNxOobRqVrPzvnp3vhhv1L6vqABqK3kMDY3SYzNLRdZRnI8kEByHF3I2IuN8Fbg Ody6Y219SuzgDWXnvuE0ZdrS66rW9ylC2hgfvWH4sxzOeJYjCzyzoXfCyN2Uvi9oANy4Y832BsVR lpCcBsH238tuJ5wWBclpKNxKzlepCem7yQkNHxiOMRg0l3RFP3P6Yk5H/ivh9GWKqBfOb5qckLGH 0vcFDUBdJ8dyQyTHMwn/g1r+I7qeHMvxkRxP41ZyVqfGj/nJUHHM2Bh9KacrMmgLyTKjKzJdQpJT rox98/yG6QnjkRxwyL2nD1jdMLlylsNDcjyQQHKqdRIjfJIEnsOt5HzUK278D/rSX43nNMYzmyLT QqHp/Ib/r9wnYVX2V08kTEZywKHaSg7j7LEcHpLjgWz/YmAET2iQnIbOreR8kBo/abO2cKMpNkU3 708zfizle8MZ1L6Jq7O/eCrhESQHHHL7SdJ2/zTmP7X7zCUGd6x5Kqf3nVp+Sfi5bQJ3x4HncCc5 51YMis5YpsnfzxgqOE7NGNQMp+b0VQyn4bgq42M8nF4eOebiujkJj/5C59uChsDtdx9w7yFiJAeA OneSU3jgc3XeifLzvxu0DuYJ5RhW5hXQdmjYgOfr4XuABsq95Dh95rQjSA4AdXiPNaDGNjl1PXEO JuYB8ARIDlBQz5MXAIAnMP/iu5+cbUcuD+wYUV8HDI2Eo+QcOnQoKSlJKpWyt961z0yn0+3fvz86 Orp58+YSicR2TADwcOZZS5AcqFeOkkOi0rlz56qqKnNySGkMBoNGowkJCbl+/fqZM2eioqJQHYCG CGc5QIfd5HAcd+DAgS5dumi1WlIUUhrGlBy9Xk+SExwcTD6SC48ePRoREREbG0v3WwCA6qrX5GCu HTATTg5pzL59+zQm2lvS09PNmx86dKhbt262d7451bVrV8tPDx48KPAl4Usst3W0C9t1BL5q/pIb R8VvYl6wu1PLNQGoqNfk1GSuHfyqNDLCySELfE7Igt6EnOuQ6pBTHLIQFhZWk+RY3aA7urF2+iMn cPsusKHlV50uu3hUwslx/UKAulavycFcO2AmnBzyKVkgjSGBISc6/H1rBElOWlpaQEBAbSXHfAnd 5NTwqITH4RcsV7A9nbJ7ggVQ6+o3OTWYa8fql8p8RwFjcaeB5cr8gqM7KIR/0/DrVw+cJscSf65D ekM+kmUfH59aT47wl1wcqrpbubJrV47K9bMcu2vijAfqTf3esVaDuXYsf1UYe7ER/l1y70KoO06T c+zYMZ2J/hbyVVKd1NRUb2/vukgO4/jPl2rdMeXGYzk1PCokBxqK2kmOwA4sa1STuXac/qq4focD kuMJqnWWw5hOdPgnsJEFmUxWR8lx8RL3zn4EvlrDo6phchjHZQWoXfV7llODuXaqlRzbPyQd/dZZ 7kLgj0qodU6Tk5WVxT9rwGBClsmFZKFz5850k+P2YzwCX6WeHBe/NYAaqt/k1GCuHdeTU1snNPj1 q1MunuUYT4ZvfTSTSCS1/ow1gXUYl39mBMZ0+lXXT9kFjgrJAQ9Xv8mpwVw7tZUcuw//2IVfvzrl NDk5OTkGC+bqJCYmktLU+uty7J4ZC6/GOHgwxu2TpK6On0jm9KhceUTT0bLtfgHqSL0mpyZz7bh9 xxpj81wDp3fBWX4KdaS6j+VYIclJTk6u86MEgFpVr8nxkLl2cPriCRy9xxr5p2nfvr1UKvT2E3q9 /vjx466UCQA8iljeY83u3RFAESYvABAhsSQHPA2SAyBCSA7QgflyAEQIyQE6MF8OgAghOUAH5ssB ECHMlwN0YL4c26/afYK+i0flUW/XZPcFCQBMA5ovxynhV9i5+HOP35B6g/lyXFl28ag8Kjl4XwMQ IIr5cpAcD4T5chgX0lK7yRF4dwNH51WWw1q9cwcjeA5nu6HT/YIYNLD5cgR+6O2+p4CjXxi7qzFI Tj3CfDku7tqVo3IlOS6+DY/AO+K4+JZRrg8LItSQ5sthXJsmx+6vlsD6wttCHcF8OYzg3zrVOqp6 SI7TOwPdGBZEqOHNl+No2cW/CpEcD4H5cmrxqKp1x5rtnQG8ekuO7ZGAeNRCclxXK/PlOFp2IzmW 6yA59Qzz5dTiUVXrbybhlesnOQKbQ+NWv8mpjflyHC3X5CzH7ppQpzBfjsDlbh9VLSbH7t3R1T1O /LqBlfpNTm3Ml+NoGclpWDBfjsCxuXFUTpNjO7jw93jQwct93D4Nsr2DAb9rIlSvyamV+XIcLVtd yC84/X0wj4871uoZ5supU3Zb4sYg+HWA2lWvyfGQ+XLAE2C+HM9UK60CcKRekwNghskLAEQIyQE6 kBwAEUJygA7MlwMgQkgO0IH5cgBECMkBOjBfDoAIITlAh9P5cvjV+FfkkOqQ856goCDz5nX67gOu f9WNrVwfEM9RhsYHyQE6PGS+nFpfvxYHRHKg8UFygA7XXwpqro55ypy6mC/HvNDVwZs0C68pvBW/ ILAX29XsHipAQ4fkAB2eOV8O49qkGI5i4+LbLwmsL7wtQEOH5AAd1X3DG/5BHf4xnjqaL0f4hMbR m4HW+jv+ITnQiCE5QIfT5KjV6r179544cSIoKKigoGDkyJGBgYGffvop+ZRsQj5mZGQolcrq7teN 5PCX1HVyLNdBcqCxQnKADqdPkl6zZk1ZWVl6enp5eXlubu6RI0cUCkVaWppUKr1y5Qo5y1GpVBMm TKjuft07y3H01Wpt5cr6wocK0NAhOUCHcHJ27dq1Y8eO0RkZ2zZv/u2335o2bdquXTtSmvz8/Ly8 vJSUlF69em3dunXu3LnV3a/byXF6od0VkBwAS0gO0CGcnCVLllRWVg4aNiwxLm706NGzZs0KCgoi Jz3Xr19fuXLlt99+e/jwYZKl5557rrr7tb0Lq1oPqNg+tIOpNABch+QAHcLJWbdu3R9//PHApEmb 1q/fs2cPy7K+vr5knfLycrJOz549+/XrR8KzaNEiyt8GAFQHkgN0CM+Xk5OTQ3KSlJQUFRVlMBiu Xr2alZUll8tjYmLCw8NJgS5cuJCZmbl06VLK3wYAVAeSA3Rg8gIAEUJygA4kB0CEkBygA/PlAIgQ kgN0YL4cABFCcoAOzJcDIEJIDtDhdL6cffv2aUy0t6Snp5s3r8l7rFl+ipfFANQnJAfooDJfjqOK 4MX/APUDyQE6nL6tJ1kgjSGBISc6/H1r/PwFaWlpbs+XU620IDkAtQ7JATo8cL4cp2sCQA0hOUCH 0+QcO3ZMZ2KeD5R8lVQnNTW1JvPlMIIzeFqthuQA1C4kB+io7hRtfG/4BZlMVpPk8JzOhIbkANQ6 JAfocJqcrKws/lkDBhN+PlCy0LlzZyQHoIFCcoAOF89yyCXmj2YSiaQWk8PgGWsA9QXJATqcJicn J8dgwVydxMREUhq3n7FmXrZ9EoHVl5AcgFqH5AAd1X0sxwpJTnJycp0fJQDUKiQH6BCeL0cqlQps q9frjx8/7kqZAMCjIDlAByYvABAhJAfoQHIARAjJATowXw6ACCE5QAfmywEQISQH6MB8OQAihOQA HRTny3H0apvaekGowKt/AEQOyQE6qMyXI6wuXvuJ15MCWEJygA4q8+UwNu9zwy9Yvt2AwPtM2z19 sRpEYHcAgOQAHdTny7E7cQ5j8243dtcXvtDu7gCAQXKAFlrz5QgnRyAqbiQHvQGwguQAHbTmy6m3 5KA3ALaQHKCD1nw59ZMc9AbALiQH6KA1X07Nk2P3IR/hkQGAh+QAHVTmy2FceMaa1Wq26/PPahN4 xprlE9sYvDQHwAKSA3Q06PlycB4D4B4kB+hocPPl4D0FAGoOyQE6MHkBgAghOUAHkgMgQkgO0IHk AIgQkgN0IDkAIoTkAB2OkpOze6yEVbCsefo1Tq8ri+qxjJV4/7Mxy7BSJcsKPcUAADwQkgN0OErO mR96xQ/+1fiCG9NrQBmW1anzrx2dy916CY7U259l5T5NklUR/d3YL57fDEARkgN0OErO2S194gb9 oMlbptdIGQmpi0oR0ZeReDHGl4IaGM5AOsRK/HJ2PhDTdy3l7wEAqgnJATocJmdDWouh36tzP+cM nKHqhrb8qp6VeCmaMZyWMWg4TscwOlXr2Tk/3Rs/7Fc39mv1tgJW717D/Ps1N3bnwnF91hzhqXQA RAjJAToc3rG2PiV28Iayc99wmjJt6XVV6/sUIW2Mj94w/FkOZzzLkQWe2dA7YeRuN/br6K3SGMcz 5dT8QgDgITlAh8PkfJWakL6bnNDwgeEYg0FzSVf0M6cv5nTkvxJOX6aIeuH8pskJGXvc2K97bwKN 5ADUCiQH6HCYnNWp8WN+MlQcMzZGX8rpigzaQrLM6IpMl5DklCtj3zy/YXrC+DpPju19aI7qYrkL 27cBdeM4ARolJAfocJicj3rFjf9BX/qr8ZzGeGZTZFooNJ3f8P+V+ySsyv7qiYTJdZuc2jqhwekO gBmSA3Q4TM4HqfGTNmsLN5piU3Tz/jTjx1K+N5xB7Zu4OvuLpxIeoZkcR7PmCOwRAJAcoMNRcs6t GBSdsUyTv58xVHCcmjGoGU7N6asYTsNxVcbHeDi9PHLMxXVzEh79xY39un3HGmPzXAOnd8FZfgoA DJIDtDhKTuGBz9V5J8rP/27QVtjfkmNYmVdA26FhA56vx+O1A6cvANWF5AAdDfQ91jBrDkBNIDlA RwNNDgDUBJIDdCA5ACKE5AAdSA6ACCE5QAeSAyBCSA7QgflyAEQIyQE6aM2X45TAU59df1Y0nj8N YBeSA3Q0xPlykByAGkJygA668+UITJNj9z0FHE2xY3c1BskBcADJAToozpfDuDZNjm023JtWBwDM kBygg/p8OY6WhZODyXIAagLJATqoz5fjaNmN5Fiug+QACEBygA7q8+U4Wq7JWY7dNQHADMkBOqjP l+NoGckBqDtIDtBBfb4cR8tOn7Fmd1vz+LhjDUAAkgN0NIL5cgCgupAcoAPvsQYgQkgO0IHkAIgQ kgN0IDkAIoTkAB2OknPo0KGkpCSpVMreeh9PM51Ot3///ujo6ObNm0skEtsxAcDDITlAh6PkkKh0 7ty5qqrKnBxSGoPBoNFoQkJCrl+/fubMmaioKFQHoCFCcoAOu8nhOO7AgQNdunTRarWkKKQ0jCk5 er2eJCc4OJh8JBcePXo0IiIiNjaW7rcAANWF5AAdwskhjdm3b5/GRHtLenq6efNDhw5169bN9s63 mqvd+XJsX7IDIGZIDtAhnByywOeELOhNyLkOqQ45xSELYWFhdZccATWcLwevDwVAcoAO4eSQT8kC aQwJDDnR4e9bI0hy0tLSAgIC3E4OxflykBwAJAfocJocS/y5DukN+UiWfXx8apIchtJ8OUgOAJID dDhNzrFjx3Qm+lvIV0l1UlNTvb29a3iWI7BcR/PloDcADJIDtFTrLIcxnejwT2AjCzKZzKOSY7mO 3W3RGwAekgN0OE1OVlYW/6wBgwlZJheShc6dO3tacoTvQ0NvAMyQHKDDxbMc41TUtz6aSSSShpIc 9AbAEpIDdDhNTk5OjsGCuTqJiYmkNPWQHKY25suxe7cbgGghOUBHdR/LsUKSk5ycXOdHCQC1CskB Ohy9xxo5D2jfvr1UKhXYVq/XHz9+3JUyAYBHQXKADkxeACBCSA7QgeQAiBCSA3RgvhwAEUJygA7M lwMgQkgO0IH5cgBECMkBOpzOl8Ovxr8ih1SHnPcEBQWZN6cyeQEA1BCSA3TQmi/H6dsB4P0CAOoO kgN0uP5SUHN1zFPmuD1fjt2JbSwvcboCANQEkgN0UJwvp1pveIN35wSoRUgO0FHdN7zhH9ThH+Op n/lyBJYBwD1IDtDhNDlqtXrv3r0nTpwICgoqKCgYOXJkYGDgp59+Sj4lm5CPGRkZSqWyuvtFcgAo QnKADqdPkl6zZk1ZWVl6enp5eXlubu6RI0cUCkVaWppUKr1y5Qo5y1GpVBMmTKjufpEcAIqQHKBD ODm7du3asWPH6IyMbZs3//bbb02bNm3Xrh0pTX5+fl5eXkpKSq9evbZu3Tp37tzq7hfJAaAIyQE6 hJOzZMmSysrKQcOGJcbFjR49etasWUFBQeSk5/r16ytXrvz2228PHz5MsvTcc8+5sWuBGXFcXAEA 3IPkAB3CyVm3bt0ff/zxwKRJm9av37NnD8uyvr6+ZJ3y8nKyTs+ePfv160fCs2jRIsrfBgBUB5ID dAjPl5OTk0NykpSUFBUVZTAYrl69mpWVJZfLY2JiwsPDSYEuXLiQmZm5dOlSyt8GAFQHkgN0YPIC ABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQI yQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfo QHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kB ECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQ HKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAO JAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwA EUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJ ATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hA cgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQ ISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAc oAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4k B0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAAR QnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkB OpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EBy AEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAh JAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkByg A8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQH QISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEqpecZybfy986ANScVXLw0wUgBq4mh9wi BAUFUTtMaKT45OAUB0BUnCcHNwpQF5AcABFykpzF7y+nd2wAANCoPDH9YX7BfnI4qZzesQEAgEcw PbxSZlr0M1+o06llsorKSoVaXeXiOKz+5ppIDgAA2BEU5EVKo9aVK2QkGMHmy4vKrvlLdQavMJlM Vl5RqHGhO0gOAADYx3GVcoXym282DR82NCgo+NjhA+07ddPpdORLJDM5F48VFVV2aNe9ouLcn/t+ Se07sbCwUHhAJAfAo+3Zs2fYsGFOf5MBat2KFSumTBkfHBxBGkMCQy4hjYmJbm/+lGEuk5Oegqts adWO2IghjIy5fnm7TNlNYEwkB8Cj8S9RQHKgnpEfPEMls/DdN2bPnl1ZWfHZZ5/17ds3IaFFUdkN Pz//t95YnDF2sCrAW+nVXOpV5C1TkPYc2Pe1WnuiV+9XBH5ckRwAj4azHKDip60LRt03j2F0337z TVr/lLCQCP7y7t1Tfvzxx+7du0dERm1Y/+3GTZvvTOsYFpqQdeZ4TCzrL0uWKHWGSlmx2v5PLJID 4NGQHKh/KlXQV598PWpkwMpPlj3+xHdffPL1pp++OXbqzxaxsbmZf2xY/6KPotXAIQ8Eh6b8fTrz /Pnsn3ZuCgtR9OjRh9HJDMz2rCNbi7Tpia0TbUdGcgA8GpID9UylUsoYhU7G6HTln374fsbYDgGq vjGxLZuEyndvW5x/+X2yjlLhq/TxqeLCu3R/u3vqsEFDej304LTCvCuB4bpNG/YNHz62Ulth95nT SA6AR0NyoJ79tHVB/tX/hYSNSB/3nI5Rv7d4yZtvz0/t3nfNF5PVF79VV+kqDAYfBSuXs4ymskIX 3an/qm/Wbpk25clP1i7u0K47P4iOYUrt/dAiOQAeDcmBeqZQGG/213+xrGm0/tCfWVMmvNRzUFoz X82m1YPVHDl54ULCB2aMefSN1x9sGVmirQguNUj46vS4vQfZ8NSpA9HRIUolW1QUaDs4kgPg0ZAc qGcqlUomk1VWViiVPuR0ZdTQ8Zm5B04cXEpOcSp0JX2Hba40NNVVSDWy6xf+eo4rzlarb6QOO3c+ 9+Rnn3xZqb40fPgUpTdrHEhm55mWSA6AR0NyoJ59svp5X6+AP/bv7nBbk+atkr5cncUaVB8uaKnm cuXsjU4DD5QUa4b0H7Jv//4/983y1vykY0LadNs4782Z6RkTTQPIzEMhOQANDJID9SwoKKiygvPy YUk6ym/oU3v3DItULX4tKazpFUMl2+3O75RNIi9nXw0La/rHr1P8mVMMo+zS/6fCMk3GfYPeWLAE yQFowJAcqGckOSf/zPr4k5kB/pLiEkP2Ze702atM5al9O8dXFcoU4WVXriaf+LuoY8fL0YGMQWO4 Vpbdrf++2dMXTnkqXSGTIzkADRiSA/Vs7SeD/jxQKfNPnjdvQZAqmBSkV1oyuXzX/z6qOvepXnKp igtWKA2coUomCeEquDa93wtr1lOp0m/9YYtS6VNUdo2sHOgXXFhYajs4kgPg0ZAcqGdBQRzHFevZ EBmje/XFhwxekV9t+Oly9tU+qUO/3fT6pb/f8VGU+ipDyZoV+qJ70n+8URxx5fqVvKunGEah0+l+ 2Lwt0D+wXac2pC+2gyM5AB4NyYF6pgpSMYxs6VsjruQeTxvweu+B9/Xv2/30X1fVVTfu7NX74PHf d+1/tUWTwX8d1k6cdn/e1etNQuVPPfLKHX3ujIg5V1nczddfahxFdrmwUGk7OJID4NGQHKh//9vy 7Oj7V+pMD8s88/jQBx5e2P62NmmpA8/lZhUX5SckRCpV/pWlJSUlerLyfaMnDBys7tntFbJ8Mf9Y THSoaU4dhd0fWiQHwKMhOVD/FPJApQ/L6Jinn+yRMW5mUod7N26Yn9an78ef7Vzz5TqFNFCjLgsM DFi/ae3IUaN/2PHNx2/PHpMeFhz1OsOUbd+2t/+AyKKiSLsjIzkAHg3JASoCFNxrrz308PQXw5ol b/5mWd71Q5Onrfrqi3np457b+O38ASNnf/j2lOlPr9q+9av2id6qpneuW7e6V0pIfMux/OaOfmKR HACPhvlygBb+Z49hdKtX3HP/xO8M2opdO1+9c8i8zINPte769ldfrkjPGKpjIrQF27xCBspM5zcd Es55B2cIjInkAACAfaQ6e3Z81KnTg/Jg6Z5dGy6f/mXUg6/nZz0f1fatY4cPq8t3tE+ZffbI6biY QjYoWSFhMRE1AAC478jvM9MGf0wW9u+Zn5w6lWF8cv+aTZJTWam5/vfiiM7PkS9JtSs43VSJ0vnp OJIDAABC+HvYrmYt8I+apfSpupr1bkjcTJmMqSz4xiskQ8YwWSfym0RKXRnKTnJ+3rGjoqyEvxTJ AQAAM5KfiqsfeIdMlslkbjzEaJ0cjuMG9L1j85at5uoAAADUooKrl6Y9PnP7jl9vJue77zZqqipp HxUAADQ22ip1SVHBP8khFw0d2HfZ++/KvLyVvirahwcAAI0EOb8hH5+Y+ezmbTvIws3kEORch3yc //ILJDxyuYLiIQIAQOMw4+nZ5CM5v+E//Sc5vN49b6dwUAAA0Bjt2rvP8tP/B5z/uaUKZW5kc3Ry ZWFtCmVuZG9iagozNCAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9JbWFnZU1hc2sgdHJ1ZQovV2lk dGggNTUwCi9IZWlnaHQgNDAwCi9CaXRzUGVyQ29tcG9uZW50IDEKL0ZpbHRlci9DQ0lUVEZheERl Y29kZQovRGVjb2RlUGFybXM8PC9LIC0xCi9Db2x1bW5zIDU1MD4+L0xlbmd0aCAxMTQ+PnN0cmVh bQo4BsDMhB06fp////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////+17VqGFAB ABAKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago8PC9SMTEKMTEgMCBSL1I4CjggMCBSPj4KZW5k b2JqCjQ3IDAgb2JqCjw8L1I0Ngo0NiAwIFIvUjQ1CjQ1IDAgUi9SNDQKNDQgMCBSL1I0Mwo0MyAw IFIvUjQyCjQyIDAgUj4+CmVuZG9iago0NiAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggMzg1Ci9IZWlnaHQgMTk3Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMg Mzg1Ci9Db2xvcnMgMz4+L0xlbmd0aCA3MzY1Pj5zdHJlYW0KeJzt3QlYVFXDB/A7+8DMAMOOQCgg oiIqIhImqYQCGpqmZmquIC64o36pqZm7maXmWr22afq+ZlbaZpZlmpqaqaG44Ia4IIuyMzPfHQbG y+wDA2cY/r+eh+49c+5Z7sz8OXe4AkuhUFAMoxPCKACAevPRgdPMXZY6g1Jf6vykVLZs1hiRnYDF 4ZEYGwDYMoWsvLC49PU1H4oFnPVfnlQVVmUQvfxZmDrMSWIvLymQFefLS/KJDhUAbBCLK2BxhRw7 x7y7V5fsPKVaECkziA6gt+eOlZXky4vz6AAiPU4AsFJbvz1XxxaS+4TSX7kSj6xb19/df4GOIWUG DXmhw8b5Y8ofZSKAAECfbQfP90oc1LFNQK1bOHPx6g/79yTFh9DbxWUV8z/7+4ufzrJ6dA7etTxZ VpxXlpNpscECgM3Z/t3F2bPTijOP1boFu+bPrlq1elxcG6oyg+RyavIHp5UZtHPp2JLsf+XlJZYb LTQpXG7AGI/I5/kCevvfe7sPOg6eIaQ3Pn2rqIz00Oobv5PX8KYy2Q9+SJ81c0bh1d9r3YIo4Lk1 b68d2ytYtVtUWpH60TlWWBv/b9YmF948rVF7/S/5bIGd0UYlspxhUZ4cNqvWw7IK/HDvkWnq2SrK HpXnpBdmHMzLuCyTVxWyROHO0a85+niwlTVKZI+OZH/9QXG5vnIe17OrQ3A3sXcrvj2PouTygozC jK8e/X26XKYw3Hu1i3d3LC4s01tHUXKnOGPvw1NHyyqqGmRJOkk7D3B4JpBLd1j+sOTmz7kn9xc+ Lq/V+NU9Vg6DYmxrv9O4we5DFzsIb+0b02/9+WKFuM8XP69xo04s6Dmp/dDBfZL0H2jyM6JzvgTw tc5DVUnlZAf6d+ATG1oD+PDHyzOmT3t8+Rdm4fnMnH8yc+iNod2D1IU7f7lMf23X3CWkuQuzsiSo +9p31o2JrapJZ9DoTWeVGbR/9bgnN05p9DftsPRukfEzKs09sW6wj5DPqc2crAc/wnfsHHv6lRQz 8o9SicszHaJfmTE+MZi6/vGVQ/vZ5QqK7e7Ub6OHZ965FcMWfvNQENQjcWhY+qb1XXqGhr+sq7xX fLf+vYrOHjz849Gfzt67KwyOmbR2ZoJ30clF50/848jW03vPkUefMB8QpQzza8/XrsPmOwfHTHs/ Lc6j6M/5Z07+68qhWA6x3oNTRNTfR1fN3/RTtiJkRNrqKR0UJ05/ulpUITd7/N09A0XqHie2Gzyo b0r1dr/qIekY/+i7rhI/IcWSy89ffnyf4rbrkLh461InfQea8ozomS8ZfMY5UU+nOGfxrnvZ9GSD nPt3cW3GJTS2+vfRoYzpU6fkpx9iFn5x5OqCT07QG0tGRAyJDtBZouYYHPPOu++Njmmp2qUzaNy2 88oM2rdy9JPMkxr9HRW+2LtXLxZbiaX8X/Vmzf8vn5sysEVu48+gLn7Jr1e+tsYWeIncWIrSCoHD oJ1pA70ffpV8/Oq9AHEn33FviNmXNvQfdIItDLRnlZeV334kd28TN3fdCql2eQtp3yDOVz8/kkm4 Ej6bx6Lk4t6vbVrcouyXBSPeiImSenD09N5M5FYjofhRYVIvro46CsfEketff6b00Lzhi194zjew 73bfAH7GWzETvn3U0kfYzI4j6LxhZmqn0sNTPvwtM8Yz3Ozxd4rtlFLdY+CLi7Yuk1b1Lu0XXjmk GoNXO3Ns84H2KfPsqdP/nb6r8zur/BgPndu0iCdjc58Z4tk1QeziwKLKyu8ezf1rV25mtpyqyfB8 Y+K6KMd2Pedklrh9VwHv/O1t8x5XuIg7p7iHdhYIWFTp7SfnPso+dapcpm7q2sM/MuxDe9qLeVRJ ZsHprdlnLlQtSdlSUViSe/tIoR2HKr35+OwH2X+dpXO7+sDqXjQDtHI6HFWd0/9NmZhexI8K9w+M 0NUUZdqsrdt/fr46NXVS7oUfmIV7jmYu2nlGtb1oaEflV8buoK7NmZWlbXu9u37jqJ5VwURnUPKH 6coM2rv8tcfXT2j096d4gCkZtGx2cn+/h40+gwSRLVIWiKpe8U59O0qk5eX3qAERcye45e6ZOfbd hB5RYeNWSelrg/I7GX8dL3qUzr32x4WMxyX80Ng3N3hpl1MsXx/BvVvFD4oVEmeBn1TgEpTWekAP 3oPPJr68QhTqOTSQz9fT+4thDp7ap1OzjsRd3MsveZpj6aHZcdOosNg5S9e6CNPf6/fyr5R9Byk/ 2F/k65wQMHmqW/7eGcNWRvWMjpmw2rzxB70QMam6x8C+i7Yul+obIbsDP3VpkHodJ47f9fNad+Vu Sps+8Z1mMh6i7JKGvRA3fpVUmPPnkuFLf8qXhvQaNLx96cFN/s48Hsvk+XYesGDVYglFPfh67t7v Dx85U3C3wmn2u3viIn2e/JQ6Z9U58dhPVw7xvf9N8pWMOw52qqaowqOr9u379ugVz9aztqd2Fd3e Ozbr5n17Fl/YZV1gpF/pn/MXLDpcMvCD98YF3/1q3I3rd8XCqgOf9iKIWfvzhg7M6Yx4KTFVNc6U Ngl+nZ/T0xS/rfcYE2Zt3T7+5XrqxJSH5w5qlO89fmvJnvMahQsGhQyI9NUodA2NX//+5te6t1Dt FpXKJuzIUGbQ/94aVnDtT43aJx0Hx8XHVUWNOnmYgVS5sTQtKdEnW8hr7Bn0rP/kReKqV7xjn1CR 8j0mjPabNM9RfmxeXAqrjccrzw6jur0a0kx9B/nj+99Nz76QxfMZItNRfovROovtHOMzJM3JPu/I vP5LDud2DHToFWLvztHoXcO5zA1pBaU6R+j0YmRoq5jFvq1dC3+YMHzh7y3aJ8x/f6Uz+9SiF0Zm u0k6BDhESVmUsFuLSfMlsqPz4iaWt3QfFj2cE23O+Jk9BvZduHW5s8b5UeNFuE9Z4qles4ijR2ym lz+qAxPmbF3ZjLnEEz6bvPEdd865bZNmn87J9eRTpSXld/MVoRGu3aVsDsvE+fZdsJnORGXmHiwS RnlzOdx2cWu3hTlc3vjSgO9KhOFthiW/Pd0rd/ecyRtejOzZIZVu6vqHg/vtesiN8hMIXEeMWT3R 4+Fnc2du6R8W1jJpnYt95oeDE/fk8cKD+idvWOCbs3PutE2JET1DlQcyehFGD1NPTTUd+x4TN1ef meZRs9Zv8RXpaqpz17YTljsanbV1++TXG5MmJN0/8432Q/tOZi378pJ69/WXWvXv3Ey7mnvHvhs3 bRvxfNXimM6gSZ9dV2bQ5wsG5mUc1ah9vtmY+Pj46vCpSiFW5X/MkjdnjO7tminksbW6a1QE3VrP XuFQ9doSxway3TgUy2VEu4kpdrl7Uvu/yfETJ/izbl4q+60iwPfZIWNSB/jT79nH+1fNWta1Gfvf dF3lPhzl9QpLIg6fHRjXU0DlX3h72Kzd15y8xG2cuZF+LAe2du8anwfxRsRJ2vCYdRiKb9z8adPC t/dnce0j/TsnrdvkY0+/W4ZcEdtHB7B9eRTLaWDb1Bmi/L1TExey/MTxLVi3Lpsz/oDu7dTnJDDh ja0rXWqeH71nL+T56LkGDrQTRS5vHttZlbll949lHVz++/EHxRTl48l21jwneuYbGDNls6rZ0Q88 xAEunE4+z4XPWeXAOrUwZlS2uzjIr+eoFctc6O8fvVPYYfFpK+mmTi1+YeQtF0mAlB3m17PT/73l WvndhR/We9ryVY4aKaA4Pr/3eE5Y/MwVqomoe4kOn1vzdWLPmHtg3IItq111NtXGbWCf5f5GZ23d dv6RlTQ+5daJr7QfOnj23rsHrqp3pyYExHfw0K7mG9Fv25bNQ6Oq4qm4TDZz7wNlBu18g86gPzRq /+M1OiE+gcWpCh2tMKpaB705fXRvN1vIoOC05erXVq+WHDeOSNJrR+sIz5zdQ0e8c7FtgH33lhzH MvnlB/KsJxX5LqOnrZ/kXX7k/+Im24U6dLeXX9FV3rtFpG/iG82aO8izvv5g3tIvLhS4eIrbOnG8 vDihEoqlu3eNz4NYHQM4yjf80zqMnOJy3Bz5/i58RyenxIlftmnDP7s4dmt6cUJrjjubzQ99r31i h5LDE16Z90fLAPsegWaOP6LPtOXLdUZJ5fnRf/ZCuneba/BAmfzYRbuL4gC/LsNTk6Mlj7/esWh5 Kym7xrwNz9fz+QlrVjpWNxsdwPG1b9di8iY30aWNLw2+LLKPDh8aP22Kfe7uyf2XcFsnvLF5pbNy HTTgLE8YFcAJ8BoZMiHJ7uHnkwYs57WKnPXONh/xpQ39B+7NkjFGwA0NS1i4eaWU2YtY63Vizyhp HjnjvW1+OpsKlvTxpy7+a2zW1u3zo3QGjb99Yp9G+YGz95kBpELHUEIHd41Cn4j+27ZsebXr0wya 8b/7ygzatXCQrgwalZCQ8DR62BphVPX/ynXQjcafQc8Fz1omUf5cbOxjX48Xn+0YGJH8TMeW8svr p4zfdI0vigzompSWoPjn29zr6YUFrJIWU8OHxwvPLhiW9mDGupecrxwoyaxZPunHjiNfnzg2UcLJ Sv/w9fnb/8zj8II87bzsWG4evA7u3dqm0d2dyVgzNa+U0bvqlR3EU16mVRXqrMPIKRbl7MRt48oW S/u5Js1sLjv++YoV9vwSf/+Xm788zkFxbN2r4w/k8aNaPZds1vgnfuUVGr9A+dbVipKq7eqBUVrj b9cjek71rn+Pue+/58XP2DL4lYt8vnJq9p384jvl/LLv1zPZDz3Hjn9rtBu90nzpLb8Ix2hHZi4b nK93dKfZGmdMKI75uHWkZ9au5He/vzsgZXOXLt53d7w8ZnNGu3Zxc5QDpgqPLn93x/ftWwWFJK71 aym69v6LEz691T7Ase/I7d1eCMr7YcGGPb9w2c5urXt07O5/adOya6znJ2xmBCjdi1144NS10hrT YY5TOnCUvqYiRkyOKPrV2Kyt2+dH7yQlJ98+WSODDpy5v646gKYlKD9sZu4mdKwRQz6d+2/buvXV rt6q3SI6g/6bXZlBiwbnX9HKIM+aGVT1wdDTizHVemjx9FFx7jdtIINazVgqqd5TlD0qzj53+Ycd Kz46nsMTdvQRuHu1Gzp+tr2Hn1RS+VGy7FHB3ztXztt0XN5h/qqF7f39nDXKWb22H1jbQkdPZ6+s nZpHqbqjX7hJgd2d2orVu/TrWNI7uCqDjNdhUrByizrl9RjVvWs7NyFFlT8ouPDlx2+9/+VtWavm Il+vdiMmzRaZPv4iflTr2OmGMqh6YDzmUCvH1r5Ht7TqXW+PwaNWhPQIr7wd4fRfq6crKoTCgEHy joltW9IzkJXePrJ72fwdZ590bCmODeIyrsUMzlfnoxzvh8FT28d2UX7EXnor6+CqGat/euIgjmgR k/r+Cin178frL4S/2r+NC5cqvnZlz5LZ9OydJWEevKgApyce4wL7xIUojywsuXHk2vfbvvj2enDX hL6zNXqxF0UuafY8YzocjZFIyzx1NRXu3q6VCbO2bp/9fjs5KflOzQz69sz9dypDZ3pCQJ/KxNEu UfPu3H/rtq3DnvNR7dIZNH33XWUG7V48JP+K5v3X5zxGJvRJ0P4kqGqjen/x9NHx7jca/WfStNKi Nd8WZFfvcbhsiR3HScz3ceAK7XmRflwnWennvz2+9ERWqLpHjs12kvD93QRSMZWTWZihXS5SXPm7 4IaOnvijXnQOkau647YLksS1FnhU1NzlMIdksA6DvLziTEbxiTsltwtlpXJ6DhxnMc/Xle8s4IT4 8/1YZeaN34Hf3bN044HqHv1ln3yna1s1EgNDDeJe/iv3u+yKUkX13NmyU5eeHLtVertQTl+xCIQ8 H3fhMxJeVBBfylwSlBqcr45HFfn3S775tzA9t6JYOX22m7MwyJkn9Y1JWqaKiTFZ9pxHeWX5ZcpH PVzsg5w5Lu6CKFd2cW7J9+lFFx+W5Snv6GQ5SwUtXPiBTrwWbuX/OVizF5nstxM1p1PzqRQX6GnK i52ZYcKsrdinv99KTkrSyKDLdwszsgvpDWbc0DFEf23pKQryEjErV2bQtuHPVf28jM6gqV/cUWbQ njdfyb+qmUGbTyqcXZWfKtEZVP1VtUkxC3NuXBwRIRE09nUQTS77+0rZ3TLF0+t4FovHY3u58Fo6 s4X0dBXyzKyy6/nyEjn19N5pCbdtM07hfV3lXuyszJoNPsUOb8XLvq56lB3eWujBUvdeucvRGJL+ OhqTKJffpAdToCiRKSoHwxJLuMFePA+++eP35rmxGT0yB6wxeI7BoQYL7QvKzt6reCyjVCEXHixw KKnIuF+RXaworyzi8LmB3vxAkcZkDM5X56MK+b0H5Zce0XlaORcWy8WV3943OnTakuofsYn8hVRR OaW8M4jNdnflhbpxBMonV5GfX5F+vyK3XKG6aUgg5DR357cQyc9frdmLgnqcW3M6GmeDracpMVVW ZMKsrdinv91KHjcu65Tm50Gmaxbef+v27cO7Pc2gKTtvV2bQkqEFV49r1C6rkMvkxm+Kp7NIwOWw GkmQQ1MkiAqc8mZ1BjkkhNjpjG8w6pMjN8ePG1vHDNqy/YMR0c+odukMSv38pur+oFcLrmreHwRg O0qfrPgqt/JyyaFPO5GOW0DBBJ8cuRHVo3dIgHetWzh/9c4fh78fEc24P+jzzMoMWjrssdY9igC2 Q15+Or04S3m5xO2CDKqDLd9fMl7JoPG9W6m36Qya+GnlPYp7l41ABgFAA1P+W41Pruq9TxoAoL5N 3FV5f9BLndxIjwQAmqIv/3rA6hYVeeTosbyHVXfGKDgCsmMCANvGklX9U+x7tzOTJk1HBgFAg6pl Bq3ZvqeBBmgFZo0bxNxN2/A3qZFYm9WT25MeAjR6tckgOoA03pY2TGOydABtX9Cd3HCsS25uLukh QKNndgY1qQCias5XFUDjlvxCdERWBOsgqDvzMqipBRDFmLI6gJKGdSI9KKuw7bO/kEFQd2ZkUBMM IKp61gggbcggsAhTM8hoAMXGxjJ3f/zxx3oYrXGqYViwd3ri90qCjAbQpME91Nsbdx+2VO+qZrUb ZJbr2zaxqVpDBoFFmJRBpqyAmG9+iweBif3WB1NWQBpvb3rXUm91U4LDlJyqD8ggsIj6zSDmBvMh FXVwaNfXaNZAZY3WNFrQPlzfGPQxmkFGlx4qzIRS7Wonl7mVDayDtFvT1x1z5Gat5pBBYBENkUHa 5Tq3Ka0Y0plNBto0PIzardHqkkE66zDf/DqPNaWyudv6HjLxOk4nZBBYhIUzSM30gDBl20CI1C6D KJNjqJ4yyMDbvi5ZU/cMMjoXNWQQWES9rIP0FdYug9Rql0Eah1NmxlAdM8jwNZHRy7F6zSCNvigz YwgZBBbRCDLI9DZNOZxZTd+jTHX/PMjcy6iGXAfpG7O+R5mQQWARTTSDjD6qVpefizXGDDL6qBoy CCyiQTOIqnl9pH1xpFGus77hn53p+7mYxuHaHelj4t2J+n6ipH3Vo+86yKzKZuUOpRVtOgds7i1O yCCwCItlUF005P1E5rL4HdL1fdtOg0EGgUUgg4xABumDDAKLsIoMsmb4t/IGIIOg7pBBRqgy6M9r j0kPxOpgHQQWYSSDZm1KJzc2K4J/Lq+NziDSQ4BGz0N4OW10ompbbwbh1wbSsA7S1sVfQnoI0OjN W73VeAZhCQAA9WT//3YigwCAGFMzKEhaQW6QAGCDLudyKWQQAJCCDAIAkpBBAEASMggASEIGAQBJ yCAAIAkZBAAkIYMAgCRkEACQZMkMWrN9T30PFwAal6Vpybm5uQYqWDiD6P4sNHIbN2/1VpwrsG30 i5wikkGG+wMVnCuweaoLI2SQlcK5ApvXFDMoNjZW40/9GP07q6R+fz7xc9WIaDx9lMl/9aB2zy/B V4WNQQbVyCBTyhsS8XPViNT6aaqP5xcJZTpkEDLIRuh8mlSFRv/OJfOJ1vl3vbULdR6lsaBGDJkC GaQ7a/RtNzDi56oR0ZdBFCMadD7RlJ4/yWv4haFxCW+gCzAMGaT78yCdFRoe8XPViOj8OM9wfNSi XGcGGe0CDEAGGXlVae82JOLnqhExcC2msY0MsirIIFyL2QhkUCOFDMJn0jaidhlkkc+DkEF10RQz iNLz0Y/260b9Iw9kkPXTeX+QgbWtdp26/FxMZxeIIVM00QxqLHCuGhJSgwhkkFXDuWpIyCAiyGTQ rHGD8Bs8TIRzBU0BfneHlcLv7gCbR+x3d1hm+LYOGQQ2j36R04t9qVSKDLJGyCCweSTXQeHh4adO narduOtybCOizqCGPFfa9eu7d7qOelu7a41CA5V11tfXkXYLho+tj/EYrqPdssb4DTRr7jjVddQP GT5XlOXeg431WqypZVBdWHkGaVTQeBvQ2wZa0HesiQPW7svwsfUxHn1t6jzErHmZPk51IWVaPGmU 1PHNaBXrIPUpo7TyXmeQa5xfnZVtg/Y6yLLnypSXvs5QsEjvGvPSeYjOIRkYmylH1fHY+hiPiZXN KjcrgwzHluEAUpXU+t1nLRlE6XpdatTReClbJIOtnM4MourzXBnNIAv2rn2IzneCiW8MC77nrSSD DFxPmbvKM6U7fYcYLbSddZDh6dVx1d1I6VsHqStY/FyZsg6yVO8aiWPKHNUllLGPJ8zNEX0pb8qx Fm/T6HeO2j2V+voynCbIIJPqULZ4IUZZOoOoWr3BLJVB2r0zM0j9kOEBGCg3PYMMNKhvDEYPt2yb pszF6DvfxKPUays1cxehyCC9JTbA4hmkr8TEmpbtXWNDXz6amCZ1zyATK9TutWcNGWSpQ8xachrV KDPIlKW4bah7Bpl1riyeQUZ7r+O7V9946i+ADHRqwTYpY3OpRacWPMT2M4hirA81pqouZB6rXdNm GM0gqm7nytwVU308U8xrAcOXCRrRpl1f/VAt1hQ6x6B9rPZ4jA6yFm0amIt2tTqO03A75n6v0vcN xkBONdb7g5qIhrxPurFc3lrnqJoOi59/ZJBVQwaBtUEGNS3492Jg88hkkGXGDgC2AusgACBGtd5H BgEAGcggACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQ AJCEDAIAkpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEA ScggACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCE DAIAkpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScgg ACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCEDAIA kpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScggACAJ GQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCEDAIAkpBB AEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScggACAJGQQA JCGDAICkumbQT4cOFT0pUJUigwDAXHXKIIVC0Svm+W++PaiOIQCA+pZz786EKTN+OPRrVQbt27e/ rLSY9KgAoEkoLy0pyMt5mkF0Ud/eMZs2vsfl8e1EEtLDAwBbRq+A6K9TZ8z+5vtD9EZVBtHo1RD9 dcXieXQSCQRCgkMEABuWOnMO/ZVeAal2n2aQSnTXZwkMCgCajCNHjzF3/x9zfvxFCmVuZHN0cmVh bQplbmRvYmoKNDUgMCBvYmoKPDwvU3VidHlwZS9JbWFnZQovSW1hZ2VNYXNrIHRydWUKL1dpZHRo IDM4NQovSGVpZ2h0IDE5NwovQml0c1BlckNvbXBvbmVudCAxCi9GaWx0ZXIvQ0NJVFRGYXhEZWNv ZGUKL0RlY29kZVBhcm1zPDwvSyAtMQovQ29sdW1ucyAzODU+Pi9MZW5ndGggNjM+PnN0cmVhbQo4 BmBPCDp0/T//////////////////////////////////////////////////////////////a9q1 DCgAgAgKZW5kc3RyZWFtCmVuZG9iago0NCAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggNDg4Ci9IZWlnaHQgMTg5Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMg NDg4Ci9Db2xvcnMgMz4+L0xlbmd0aCA4MTQ5Pj5zdHJlYW0KeJzt3QlcFHX/B/DZe4FdTrkUQgER L7wQCZVUQgHNTFMz9fEET7yvf2pq5l1mqXlWT6emz2NmpZWZZZmmpuajpuKBF+LJodzs7n+WhXWY nZmdXRZ2Bz7vXi+c/c3Mb76/Yfezs8PMJtLpdATFiKS2BAAAOJKP9p6kPhQZgzv1pfZPijRLZ4x0 cVKIJDJ71AYAAJXoNCV5BUWvvfWhSiFZ+9VxQ2N5cJMH2gtSB7urnbWFuZqCHG1hjl1LBQAAPZFU IZIqJU5u2XeuLN52wnDorQ9uMrXfnjNKU5ijLcgmU9vedQIA1B6bvztTxR5SekaQP6Vq34yb197d c47Mbn1wD3y+9fp5I0sepSO1AQBsaMu+s91792/TLMTqHk6dv/Ljnp3JiS3I6YLi0nmf//3lT6dF XduHb1+WoinILn6YbrNiAQCAILZ+f37WrJkF6Ues7sGp4bMrV64andCMKAturZaY+MFJfXBvWzKq MPMfbUmh7aoFcARSachI3+jn5Apy+p+7O/a5DZimJCc+ezO/2N6lVTd5O/8hdWawDuyDHy/MmD4t 78rvVvfgEtLprbdXj+oebniYX1Sa+tEZUdtmwd+uTsm7cZK29NpfcsQKJ7OdqjUPB8f4ScQiq8sC LvLIBsNmGn8NuuJHJQ8v5KXty067pNGWN4pcIj1j/+UW4CvWL1GoeXQo85sPCkrY2mVSv46u4Z1V DZrInWUEodXmpuWlff3o75MlGh331iucv/Pxorxi1mV0hbcL0nY9OHG4uLS8Q5G6nUf7vq7PhErJ DZY8KLzxc9bxPXmPS6yq37jFsjIIyrRpPEnDfQYtclXe3D3yxbVnC3Sqnl/+/JY3cWx+twmtBg3o mcy+Iu/fCON47UBush/KW8oG2y+4tdxupdVxH+6/NG3qlMeXfqE2nk1/+L/0h+TEoC5hxsZtv1wi f7Zs6NWioRd1YXVYl9XvrBkZX74kGdwjNpzWB/eeVaOfXD9B296Ugx538s3/tj2yjq0ZEKCUS6wZ E5gljwocNduZfPnFDfujSO31TOvYV6aN6R1OXPvk8oE94hIdIfZxf3G9r1/2meWDF3z7QBHWtfeg thc2rO3QLSLyZab27omd+3TPP73v4P7DP52+e0cZHjdh9fSkBvnHF5499j83McvWuw07/IQ6w2Xs 4KBWctNlxHLP8Lgp789M8M3/c96p4//UkxAi1/gGA8a6EH8fXjlvw0+ZuhZDZ66a1Fp37ORnq1xK tRbX38Uv1MW4xfEtB/TvNbZi+sWKkhjqH3GnnjpISYi02rOXHt8jpC1b9160eYk724p8fiMs47UP OWWfGIdT8HDR9ruZ5GDDPPt0qFdfaqfa6raPDqRNnTwp58IBauOXh67M//QYObF4aNTA2BDGFiO3 8Lh33n1vRFxjw0MyuEdvOasP7t0rRjxJP07b3mHlCz26dxeJ9UT6fyomK/+7bM7Yfo2yENzVRd4h KOW1shfkqFx/F2+RrqhU4dp/28x+DR58nXL0yt0QVbvA0a+rxBfX9el/TKwMdRaVFJfceqT1aZYw Z81yD9P2Rh69wiRf//xIo5aq5WKZiNCqevxrw6JGxb/MH/p6XIyHr4Rl6/VdvCvFujymrYe/lGEZ nVvvYWtfe6bowNwhi57vFBjaa2tgiDztzbhx3z1qHKCs7yRRtF83PbVd0cFJH/6WHucXaXH97eLb ja3YYugLCzcv9SjfuseLkWUlVSre6NSRjXtbjZ3rTJz8z9Tt7d9ZGUSZdWbDQplGLH1moF/HJJWX q4goLrlzOOuv7VnpmVqiMu7xxiV00Nd27eHxDFWrjgrZ2Vtb5j4u9VK1H+sT0V6hEBFFt56c+Sjz xIkSjbGrqw/+SHOO6OaskhGF6bknN2eeOlf+4Ufs4dI22adVtNJJQhTdeHz6g8y/TpNvdhUrVmyF /q5TNhyJYZmT/xk7/kK+PCYyODSKqSuC36jBWv/++crk1AlZ536kNu48nL5w2ynD9MJBbfQ/KQ/7 d2xIXdijefd3164f3q08zcngTvnwgj64dy371+Nrx2jb+1PVl09wL52V0ifoAYK7uiiiG42d71Ie E+692qg9SkruEn2j5ozzzto5fdS7SV1j2o5e6UF+dC+5nfbX0fxHF6RX/ziX9rhQHhH/xjp/03ZC FBiguHuz4H6BTu2pCPJQeIXNbNq3q+z+5+NfXu4S4TcoVC5n2foLbV39TH/P9GXUPqruQSlT3IoO zEqYQrSNn71ktZfywnsvvvwr4dzaQx4e7BLomRQycbJ3zq5pg1fEdIuNG7fKsvrDno+aULHF0F4L Ny/zYKtQ3FqeuiTM+IlBlbj959U++odjm/VMbDedMotwSh78fMKYlR7Kh38uHrLkpxyPFt37D2lV tG9DsKdMJuI93vZ9569cpCaI+9/M2fXDwUOncu+Uus96d2dCdMCTn1JnrzyjGvXZioGB975NuZx2 29XJ0BWRd3jl7t3fHb7s13TG1tSOLrd2jcq4cc9ZJFd2WBMaHVT057z5Cw8W9vvgvdHhd74eff3a HZWyfMWnW1HErf55XWvqcIa+1DvVUOfYZklB7TuxdCVv3mAkj1GDtT755Vrq+LEPzuyjte86enPx zrO0xvn9W/SNDqQ11otIXPv+xn91aWR4mF+kGfdxmj64//vm4Nyrf9KWPu42ICExoTyfjXFNTfGy iSUzk3sHZCplCO7qoXg2eOJCVXlMuPWMcNEHkzI2aMJcN+2RuQljRc18X3l2MNH51Rb1jTe7Pr73 /dTMcxmygIEahvablN5FYs+4gIEz3Z2zD83ts/hgVptQ1+4tnH0ktK3TnElfNzO3iLFC9xeiI5rE LQpsWi/vx3FDFvzeqFXSvPdXeIpPLHx+WKa3unWIa4yHiFB2bjRhnlpzeG7C+JLGPoNjh0hiLamf usXQXgs2L/Ok7R8jWZTPpMV+xqNjVezQjeSBtmHFpNmbV9SnfphQPpuy/h0fyZktE2adfJjlJyeK Ckvu5Ogioup18RBLRDzH22v+RvKNRP9GtS9fGdNAKpG2TFi9pa3rpfUv9f2+UBnZbHDK21P9s3bM nrjuhehurVPJrq59OODF7Q+kMUEKRb2hI1eN933w+Zzpm/q0bds4eY2Xc/qHA3rvzJZFhvVJWTc/ 8OG2OVM29I7qFqFfkbIVZexg49AMw3HuOn5jxZ5pGDNj7aZAF6au2ndsPm6Zm9lRg7U+/fX6hHHJ 9059azpr9/GMpV9dND587aUmfdrXN13Mp02v9Ru2DH2u/CMiGdwTPr+mD+4v5vfLTjtMW/ps/ZGJ iYkViV0e3aKy/6gtb0wb0aNeulImNtkc2IKic9NZy13LX5Cq+FCxt4QQeQ1tOX6sU9bO1D5vSIJU ScGiGxeLfysNCXx24MjUvsFk0D3es3LG0o71xf9cYGoPkOhPJ4jUqshZoQndFETOubcHz9hx1d1f 1cxTGh0kchWbbp12jls2NEHdTEZdhqLg+o2fNix4e0+G1Dk6uH3ymg0BzmTEDLysco4NEQfKCJF7 v+ap01xydk3uvUAUpEpsJLp5yZL6Q7q0NO6T0KTXN6/wqrx/WPdei+di53Cs6OQSvaxhfHvDG1Xx vSMZ+5b9fvR+AUEE+Ik96fuEZbyhcZM2Grodcd9XFeIlaRfQKXL2SlfRiQVxwzN9VGFB3YYvX+pF vun2GCtumzhzBdnViUXPD7vppQ7xELcN6tbu/96sV/aWLG/bY8qylW606NQdnddjjKRt4vTlhoEY txIbOafy88SZMvbQhPmbVtVj7KqZd7+ey4LNjhqste2PjOQxY28e+9p01r7Td9/de8X4cHJSSGJr X9PFAqNe3LJp46CY8kwvKNZM33VfH9zbXieD+w/a0v/zH5GUmCSSlCe1SYKXH3G/MXVED28Ed7VR dA6fucz4guzeWOItcVF3/7hplN/DHYOGvnO+eYhzl8YSt2LtpfvajCelOV4jpqyd0KDk0P8lTHSK cO3irL3M1N6jUXRg79frN3TVZnzzwdwlX57L9fJTNXeX+PtLItSEiHnrtHPcojYhEn1KPl2GEu5S ibebPNhL7ubu3nv8V82ayU8vit98oSCpqcRHLJZHvNeqd+vCg+NemftH4xDnrqEW1h/Vc8qyZYz5 W7Z/2Pdeiy6d53CuqNEeOe90XhUS1GFIakqs+vE3Hy9c1sRDXGnc3OP1e27cWyvcKrqNDZEEOrds NHGDt8vF9S8NuOTiHBs5KHHKJOesHRP7LJY2TXp94wpP/RF339MyZUyIJMR/WItxyU4PvpjQd5ms SfSMd7YEqC6u69NvV4aGUoE0om3Sgo0rPKhbUZk8T5wpLQ2jp723JYixq3B1z2Di/D/mRg3W+uIw Gdxjbh3bTWvfe/oeNbUNyOxOau1DawyI6rNl06ZXOz4N7mn/vacP7u0L+jMF9/CkpKSneS2mJXj5 v2VH3NcR3NVF0Sl8xlK1/qqSUY8DfV94tk1oVMozbRprL62dNGbDVblLdEjH5JlJuv99l3XtQl6u qLDR5MghicrT8wfPvD9tzUuel/cWpldun7C/zbDXxo/qrZZkXPjwtXlb/8yWyML8nPydRN6+stY+ nZvPJDd3Ku2tydlFlK0b4iBMpj+LUt7IuAwl3EWEp7u0WT2xyuPFesnTG2qOfrF8ubO8MDj45YYv j3bVHVnz6pi92fKYJp1SLKp//Nf+EYnz9Xlnkr/l0xWFESb1t+waO7viYXDXOe+/5y9P2zTglfNy uX5ozu2CEts9/GX3r6cyH/iNGvPmCG/yM81LbwZFucW6Ud/MOMfbILbdLNoeU6riPmka7ZexPeXd H+70HbuxQ4cGdz5+eeTGtJYtE2brCybyDi979+MfWjUJa9F7dVBjl6vvvzDus5utQtx6Ddva+fmw 7B/nr9v5i1Ts6d20a5suwRc3LL0qem7cRsq7DrkVp8jQyas9Kg2HWqdHv+FsXUUNnRiV/6u5UYO1 vjh8Ozkl5dbxSsG999S9NRWpPSVJ/1dH6sOkNpWyO6B9ny2bN7/asYHhYT4Z3P/JLAvuhQNyLpsE t1/l4C4/2f30XInhyHvR1OEJPjcQ3NVF0anJtCXqike64kcFmWcu/fjx8o+OPpQp2wQofPxbDhoz y9k3yENd9jdFzaPcv7etmLvhqLb1vJULWgUHedLaRd237l3diGFLpy+vnpxNGDZHvtqTQ7u4N1cZ H5IvfnWP8PLgNr8MlU6Uld8uu+vwLh1beisJouR+7rmvPnnz/a9uaZo0dAn0bzl0wiwX/vXny2Oa xk/lCu6KwmTUUstqa9W188yKhw18Bwxf3qJrZNkVkCf/WjVVV6pUhvTXtundvDE5Ak3RrUM7ls77 +PSTNo1V8WFSyqkSzvEyzpU0eBA+uVV8B/3fWotuZuxbOW3VT09cVVGN4lLfX+5B/PPJ2nORr/Zp 5iUlCq5e3rl4Fjl6T3VbX1lMiPsT39GhPRNa6NfMK7x+6OoPW7787lp4x6Res2hbcXaJXlz/Ocpw JLRKPIr9mLqK9GnZhMeowVqf/34rJTnlduXg/u7UvXfKknpqUkjPspg2bTFq0L7P5i2bB3cKMDwk g3vqjjv64N6xaGDOZfodmWd8hyX1TDI9u10+UfF40dQRiT7X8cfJalSU/9Z3uZkVjyRSsdpJ4q6S B7hKlc6y6CCpu6boi98eX3yiyTPcACIWu6vlwd4KDxXxMD0vzbTdRXf579zrDFuSD3/Bs4XWsDlp yzB1QlOFb2nlhxJqSZzLUGhLSk+lFRy7XXgrT1OkJccg8VTJAuvJPRWSFsHyIFGxZfW7yrv4Fa3f W7HFYM2n3zNNGyrhKDVMeumvrO8zS4t0FWMXa05cfHLkZtGtPK2GDGGlLMBH+YxaFhMm96AefBZx jpdhri7nXuG3/+RdyCot0A9f7O2pDPOUeQTGJS81ZOvIDGfJo+zinGL9XF8v5zBPiZePIqaeuCCr 8IcL+ecfFGfrb1cSeXooGnnJQ91ljbxL/r2v8lY0mt+OVR5O5V+lKpelK39xehqPUYNVPvv9Zkpy Mi24L93JS8vMIyeoGU1mN/mzsZ9LmL8LdeGy4N4ypFP51SZkcE/+8rY+uHe+8UrOFXpwbzyu86yn P1NOBnfFT8MkQW18eP380Ci1Akfc1Uer+fty8Z1i3dNzkyKRTCb295I19hQryd+DTpueUXwtR1uo JZ7eTamWNq8vybvH1O4vzkiv3OFT4sgmssxrhrniyKZKX5Fx62UPJbSS2JehDaJEe4MsJldXqNGV FSNSqaXh/jJfueX1N5B5iylbpBZMK17CWWq40jm3+PTd0scawvDOEBmucC0sTbtXmlmgKylrksil oQ3koS60wXCOl3GuTnv3fsnFR+SbUNlYRCKvevJWgbERUxZXXKDiEqwk8ksI/RXcYrFPPVmEt0Sh /+XqcnJKL9wrzSrRGS7uViglDX3kjVy0Z69U3oqOeJxVeTi0vSFm6UpFFOfzGDVY5bPfbqaMHp1x gn6Om7/6kX02b906pPPT4J607VZZcC8elHvlKG3p4lKtRmv+Fl4ywBVSiQjvzACWUsSETnqjIrhd k1o4Mb7ngaB9eujGmNGjqhjcm7Z+MDT2GcNDMrhTv7hhuI771dwr9Ou4AaDaFT1Z/nVW2dkM154t XRjubwKB+/TQ9ZiuPVqENLC6h7NXbv9x8IehsZTruL9ILwvuJYMfm9yAAwDVTlty8kJBhv5shrQD gruW2vTDRfMLcRrTo4lxmgzu8Z+V3YCza+lQBDcAgOPT3/L+6RXWOycBAMABjd9edh33S+287V0J AADw8tVf90WdY6IPHT6S/aD8QmGdRGHfmgAAgEakKf9et7u30pMnTEVwAwA4OiuDe+a6v2uoQAew amIr6sO3tu60VyWOZsbo/vYuAaAusia4ydTeOr9LjZVoX6MX/0INbjK1kVYAYF8WB7chtck4q8kq 7csY3EhtKuwNAHuxLLiNqZ08uF1NV2oPWz7/i6gIbuQUDXYIgL1YENx1LbUJSnAjpExhnwDYC9/g NpvaEwZ0pT5cv+NgtdXMxVCGrbZuCG5f5SWzCRUfH2+c3r9/v022buzWtENqO9s0z66shuAGsBde wc3nWJuamLZNT27Vui3qqRIOtEwkH9oqH/mkLZ9wrw4IbgB7qd7gpk5QZxkY09Z0eVq3HAvTeqP1 YLo6Ww2M+AS32YNcA2qsGx6axr2lC3MccZv2xrY5auUWfW5AcAPYS00Et2k74zRhkt2Mgc7RJ3cZ VnwaqGJwMy5DTUzGdfksbOk02yyep1kYIbgB7MXGwW3EP1X5THMkr3XBTfDL7uoLbo6srEpAVz24 zY7FCMENYC/VcsTN1mhdcBtZF9y01QlLsrvqwc19ysLs2ZJqDW7atggLsxvBDWAvAghu/n3yWZ26 GNtcI5uc47b0LEdNHnGz1cw2lwrBDWAvdTS4zc41qOJVJUIMbrNzjRDcAPZSo8FNVD59YXrugtbO uDz3lSdsV5XQVjfdECOewU2wX49helKC7TSFRQtbFNaEyfsBY8GWXoqO4AawF5sFd1XU5HXfFuEf 3PxV9+XVNQbBDWAvCG4uCG4OCG4Ae7EsuO1VpX3ZNrhrDQQ3gL1YENx/Xn1stzLthzzoRnAzQnAD 2IuZ4J6x4YJx0brzpYBUhrMlAAAOwld5aeaI3oZp1uA2/s9u6uYRd4dgtb1LAAB4au6qzeaDu24e aAMAOKY9/92G4AYAEBK+wR3mUWq/IgEAQO9SlpRAcAMACAiCGwBAYBDcAAACg+AGABAYBDcAgMAg uAEABAbBDQAgMAhuAACBQXADAAiMLYP72PWC6i4XAKAuiApy4phr4+Dm3hgAAJhlNksR3AAAjgXB DQAgMAhuAACBQXADAAgMghsAQGAQ3AAAAoPgBgAQGAQ3AIDAILgBAAQGwQ0AIDAIbgAAgUFwAwAI DIIbAEBgENwAAAKD4AYAEBgENwCAwDh0cMfHx+/fv5+7BaqC3J+0Furupc41tjM2crRbuiGe3fKv zdBoeEidZiyPnMW2DIDjcPTgJkxernhF2RBtD3NknGHPMzYSlX8vjMHHnYZs2+Uzzac2thXN1oYQ B8ckgOAm2F+NpnMJykETwXIAZdotbVbdeaGy7Ry2A08++8dWwW2r2riD2/Rg3/RZRJg8x2iNADXM 0YOb9iplPHlCVH5ZEpzZXfVgqk3MhiPjXIJzF9VYcPOszdIjbu5De+6xA9SMWhjcPKfxIiQ4g5tg Obo0e8jJeDqL4yw221xb1Wbz4GYbOECNEUBwE5XTluNVyj+4aSvWWdzhSG3h00iw/xGC/xG3zWuz YXBzDBygJgkjuAn2V2MV/65Vx/EJR/6NbKnN1oMV/VtRm22Dm0B2gwMQTHATPM54VD2461qsc2eW aTtjo/GhRSeX+fxSOH6J/Guz6GljRWEANU9IwU0wvWKNeIY4bUU+h2+1GG0fEiynBQhze4+xn6oH N9vmrKjNuuCm9rmf5ToTgJrn0MENAACmENwAAAKD4AYAEBgENwCAwCC4AQAEBsENACAwjhvcpleY GeAyLACo4xw3uI3q2rXVAADchBfcbDfsMd5bQV2FwC1wAFAr1LbgJtjvi+P/TRcAAI5MeMFNVM5i 676eAgBAuOpKcBshuAFA6OpKcCOvAaDWEGRwMzbie1wBoI6obcFtZPYrQDk6BwBwZAIIbkY8//co AAC1jyCDGxf2AUBdJsjgBgCoyxDcAAACg+AGABAYBDcAgMA4dHDXwN8b8SdNA+qtTADg4OpccCOp GSG4AQREkMHNdkMNrd10MbYW2n3ztJ7Nfk2V0N8MkNoAwiK84Lbi1naOxfj0xvaFsdx1CgiCG0BY ENx8g7sWf2UVghtAWGp5cPM8N1KXgxupDSA4tTm4Gc9NI7hpENwAgoPgtkFwCzrNEdwAgiOA4KZi uzjEdHmO//0Nxx8bua8qIRDcAOAAHDq4obohtQGECMFdpyG4AYQIwQ0AIDAIbgAAgUFwAwAIDIIb AEBgHDq4zV6cBzbBsZ9pjdRZbL8Cxgvqrbh9ibZWFcvjfwmp2f45tmJD+LsxcHDc4Da9whrP4+pg xV1OBjyDm/qL4x923FlvaXkcy1t0KxbHMM0Oh//C1LXwnAdGggluxnbG+2uo7bXvK1hti/9OZstB 7j5p0cN4LytHD7Yqz9Igtmh57vty9zN9vTDB8hSlLYnnKrBx9OAmLPkgTHvx1L67HG2O+52vKsFN 65A2y6JQrnp51RfctLGwfdpg+6KF2n1TLlQfxw1ugvc5bj6vCmBk3dezVDG4qx6g1RTcPN8YeNbJ cY6II7jNjgWAcPDgNqA9odleA6bLU9cCRtUX3IxvnPYKbsLcs4LtlE5V6jQb3KbFmGY3ghsYCSC4 Cc4XkqWxAlTVGtymS9oxuDnmxpv8DbDGjrjZyjO7dajjHDe4+Xx0teK0IF4JVDWQjNadO66m4OaT 2lWsk09JVr/zARg4bnATPM5xm/3ISVgY63UQ277i2PlU3IlGa+F5FovtV2x1eXw64eiK+9CYrVu2 czVsJbG14LkKphw6uKHOYjwQFgpbBa6gdwJUKwQ3OCiBxhZSG2oAghsAQGAQ3AAAAoPgBgAQGAQ3 AIDAOHRwW3GZNncnbDewMd7mZ2lhQmTd5X2m69pkV5i9iJN7W3wuuOa/IvcWufcb/2ppyzB2y33h IFsN3JXYqh3sRQDBTXDeE8yzEytez1b0KThWD8T0LbCKe8O6+wypCxhYFDfcK3Lf5FWVO7zY9h6f O3csuhPKotugrLvdCexC8MHN894K2tPOdC7HwTh3n7S5wnpOc3+miad8Kyn/wbL9jvh/rLEuKXi+ Q/O505KxAFojzzszLVqGT22Wbo5jRFWcBjty9ODeT/nOB9McseFTkM9rlW1d0x6Egv89ftzLmHZo urtM2/lUxf1maXYspu38g5u2UT5V8anWiuC2oiuOJa2b5h4U1DBhBDfBcgDoUMEtRGYTyvQh47rc B9eW7jo+n/HZxmI2uHmuyPZJjnt1PtXy+bBC3S5HJRYFt9ldavbVwVgD2AWCm/XZbFTrg5s7DvjE JWG7XRdv+TesctdpRXDT3n74r26T4ObOdO7PCmwV8tmlZqf57A2oGQIIbqJ6ztDxOeKmFcO9gBBV PbgJm+66eKu+YZW7zqoEt6WrV19wm62Tozyeu9SKVw3YSy0PbsbjwSoGN9txhxCf01YHt0VnM3i+ 8k0jhv+6HHPNDodncNMaLTrzYLYktlXYNsQ9ZMbVuUdnxTTYkTCCm9ZI8Dj7xvZ6Y5zm2S1jn2yF CUJVjri59zy1ndrC2JXpMqYFWLEuY7vpc4DnRtmeIYx7j6NajsU4CubYFvc7Ga037iItbQd7cejg htpBiG9pAI4MwQ3VDsENYFsIbgAAgUFwAwAIDIIbAEBgENwAAAKD4AYAEBgENwCAwCC4AQAEBsEN ACAwCG4AAIFBcAMACAyCGwBAYBDcAAACg+AGABAYBDcAgMAguAEABKamg9tGZQMA1Gk1F9wAAFAD ENwAAAKD4AYAEBgENwCAwCC4AQAEBsENACAwCG4AAIFBcAMACAyCGwBAYBDcAAACg+AGABAYBDcA gMAguAEABAbBDQAgMAhuAACBQXADAAgMghsAQGAQ3AAAAoPgBgAQGAQ3AIDAcAX3TwcO5D/JNbQi uAEAHARrcOt0uu5xz3373T5jdgMAgAN6ePf2uEnTfjzwa3lw7969p7iowN5VAQAAs5Kiwtzsh0+D m2zq1SNuw/r3pDK5k4va3uUBAEAl5LE2+XPytFnf/nCAnCgPbhJ53E3+XL5oLhnfCoXSjiUCAABV 6vTZ5E/yWNvw8GlwG8R2fNYORQEAALtDh49QH/4/mybw4wplbmRzdHJlYW0KZW5kb2JqCjQzIDAg b2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0ltYWdlTWFzayB0cnVlCi9XaWR0aCA0ODgKL0hlaWdodCAx ODkKL0JpdHNQZXJDb21wb25lbnQgMQovRmlsdGVyL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJt czw8L0sgLTEKL0NvbHVtbnMgNDg4Pj4vTGVuZ3RoIDYxPj5zdHJlYW0KOAag0Qg6dP0///////// //////////////////////////////////////////////////9r2rUMKACACAplbmRzdHJlYW0K ZW5kb2JqCjQyIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9X aWR0aCA2MTMKL0hlaWdodCA0MjAKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVj b2RlCi9EZWNvZGVQYXJtczw8L1ByZWRpY3RvciAxNQovQ29sdW1ucyA2MTMKL0NvbG9ycyAzPj4v TGVuZ3RoIDE5NzU1Pj5zdHJlYW0KeJztnXd8FFX3/1cIhhIg0luo0kFAeuhdpJcAAkqv0kKXXhUC JBBalA4PCIhI7x0BAYWASGiCoZeg9JKQfH/nxTzOb5/dyU7Yudm9c/bz/mNfs3fK3nPuZ85n7rZ5 7//+7/8sAAAArHjvvffc3QXTw89c3qOQoAzj8FNGQoByjOOZypEcCFsUzOQNWQiDmTJ0QU0Rhacp R34UbWNcjMAyh/8tecyicjEslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsB sFSGLp4ZtViQQznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5 hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJyYa F2m7Km3HjAC/FABLZejimVGLBTmUE5eNS4YMGR4+fHj37t3MmTNbt1NL1qxZ06dPHxUV5fgI0kpI 2o4ZQaRf5suX7+rVq8ePHy9XrpzSQssVKlTImzfvn3/+qbQ8ffp03Lhx69atI0FkyZIlICCAnvr4 +Fgfp1evXmFhYfQ4b948471yASyVoYuRqI1L5ezZs5MnTz548CCVG1pbq1atbt26VapUSURkrsMz lSM/LhsXUuzRo0dJxlWrVrVup5bq1avT2p9//tnxEaSVkLQdM4JIv+zZs+e33347adKkkSNHKi20 PHr0aGqfP38+PY2LiyMRHD582HovEsr+/fuTJEmitijFlB6vXLlivFcugKUydDEStUGpUHvdunVf vXplc1jTDYFnKkd+XDYunTt3XrJkCZ0L3bt3t26nFjoXaO2iRYscH0FaCUnbMSOI9Msff/yxZcuW 1apVO3DggNJCy4cOHaL25s2b09M1a9a0adMma9asP/zwQ5kyZU6ePEnb37t3j9pbtWql7ELTiw8/ /FBZJtfMkyeP8Y4lNiyVoYuRqA1KpXz58idOnKhfv35QUFChQoUeP35Ml+Fz5szZvXu3uPhcgWcq R35cNi5Tp04dPnz4wIEDZ8yYYd1OLSEhIbR26NCh9PT169e0wcqVK6k8pkyZsk6dOt98803evHnV rj579qxHjx4//fSTt7d37dq16bzInTt3YnfeMSy1LdIv//nnnwwZMnh5ef3999+pUqWiIUyXLh1N FKKionx9fWmDgICAdevWWV9M0WSid+/eVAqpLFq3qMt0kfX/+/p2AJ4/f96rVy86jqKMadOm5cqV S3etwurVq5ctW3bmzBnqEk1TcubMSWW6U6dO/v7+RgJnqQxdjERtUCo0uNHR0Q8fPqS9HPTNgRiO HDmyYMGCffv23b17N23atJUrV6aZLhmzeoSYmJjZs2evWrXq4sWLsbGx5NBUwho1aqSsdVC/3gnP VI78uGxcNmzY0KxZswYNGmzZsqV///6hoaH9+vWbNWvWp59+un37dlrbpEkTkmLdunXVK0uFzJkz nzp1Klu2bEpXW7duTZeS6lq60AwPD8+UKVNi998BLLUt+Ps+yoX/1q1babzpsWHDhtTyyy+/KGtp 4kj15dKlS/nz51daqBjR/IDaL1++rLSQekgltNfx48dpef369f+/r28HgKYdZHtqY/bs2UkZVHwd r6VlulKjiqnZbYPhs1SGLgajNiIVutC5ceMGORyVmIwZM8bXNwdisL+5Cnnqzp076fqJlsmMP/nk k/3799tsowTruH69UxI8Uzny47JxiYiIKFKkiPLZU9myZc+dO1esWLGTJ08qn0nRWtL89OnThwwZ Urp06bCwsJIlS96+fTswMJAKo/LhhdJVOsiKFSuKFy/+xx9/tG/fnh5pm+Dg4MTuvwNYaluwX44e PXrSpEkDBgwICQmhR7pQopYJEyYoa2km8eItKVKkUFpoOdVbaIZBT9+8eUPl7PHjx4cOHapatSpd +NMcImnSpP/tazzKGDx4MBmh47W0KnXq1PQqkydPpnaqazRpuH79OlW9JUuWHD161EjULJWhi8Go jUiFpobKvJP6UKBAATJamneS46ouqCuGGjVq9OjRg9yRrsHv3Lkzfvz4hQsXqu8PBwUFDRs27IMP PqDrfbr2pxelQjZlypS1a9fSWsf1y5U5BImEy8aFrsxSpkxJC1FRUXTl16tXL5LQ/fv3qQwmSZKE NJ8sWTLS2JkzZ6yvHWkDuj7LnTv3tWvXlK7StV316tWVtcp3hei8oEvMxO6/A1hqW7Bfks9R0Sla tCjVF3o8f/48tVSpUkVZS84XFxdHRqV+u4eeUiM9pUZ6Sr5VqVKlggULXrhwgR5JItRSsWLF//Y1 HmXQJRhdiDleS0/z5s1L8qpcubKfn1+OHDmyZs1KlZTqpurHTsNSGboYjNqgVPbs2UNGS8P98uVL ZQO6wNq4caPydq6uGGx4+vRpmjRpaN9//vmHnioVyvpjdWsc1693SoJnKkd+XDkupCKaXM6bN69v 376RkZG5cuWia8c+ffpQO2mMNiBDVUVujZeXV0xMjNJV2iB58uRK+6tXr+gq09vb2/4Lca6EpbYF +yWNX7p06WgGcPLkybJly/r4+Pz99990iaSs1Z1fjhs3jq70STd0XU+Pc+bMoZaxY8f+t6/xKIOe UqPjtZa3H1l17NjR5ju3VKm3b99ODmokapbK0MVg1Aaloh6E/O/w4cPBwcFXr17t2rUrTT0telKx vP0ke9GiRWR79KKKAROqGdOWtD2ZqM0vnRQc1693SoJnKkd+XDkuDRs23Lp1a5kyZehFT5w4QecC ve5vv/1G7Zs3b7bErzelh7pSdxcstS3+/wqU4a9Zs+a+ffvUIVew/1CKlmkeqX5+6e/vf+zYMeuj UQv53H/76vBKKiHXWRQmlcizZ8/SPCA8PHzXrl1UhW066QQslaGL8aiNSMUG5QdIGTJkePDggUVP KhMnThwzZoxml5RwFL8kYyZ7tt/Gcf1KePgWT1WO/LhyXAYNGqR80Kh8WECPyndlqX369Om0UKpU qfPnz0dFRaVOnTq+rlq/laK8cxPfWykug6W2xfslTQ379++vLtM0UV3VsmXLH3/8kWYANA9QWpT/ JVC+9Pj48eP06dOrF/sKdM1OQkmbNq0lfmUo79Q7XqvZVaXIUvl7/vy5kZBZKkMX41E7LRX7Qykf /9D0NDo62qInFdqStp8zZ07z5s0zZcqUNGlSmmWS9tRwHL8f67h+vROeqRz5ceW4fPfddz169KAF ul5UrhobN26stHfr1o0WQkJCBg4cSOodP3586dKl6RLwxo0bdIm5cOFCml3YfFRPHtm+ffvff/9d tVt3wVLb4v1S+caXukyXOeqq77//vm3bttmyZbP+Ud3du3eVwrR+/foWLVpUrVr14MGDyvbKb/Ko vVmzZha7L3GoylC+M+J4La0iqdGr02yGiiZp7ubNm3PnzqULOjLjR48eGQmZpTJ0MR6101IpX758 586da9Soofw+hLxt+PDh5I7FihWjEbfoScXHx4eukOhQDRo0IIs9d+7cyJEjd+zYoYZj/X0fKmE0 yySDnDp16qpVqyx69cvFOQSJgSvHRflkPUmSJA8fPvT19aVaRJducXFx6p/+vHnzpkmTJtu2bbPf V30/1v73JHRSaH513GWw1Hai/H9sjhw5bt26RY9UR6zbSQSkAPX9VQX1T1t0//NFGYCAgADrGUaW LFnCw8MzZ87seK26uz3WH5E6B0tl6CIkauekojmUNE1ct25d06ZNLXpSUf5UxXpfmubOmjVLDYcm qfXq1bP5xYi61nH9SnjsFk9Vjvy4clyUv4otWbLk6dOnlZZSpUqRUK3/VDY2NnbBggV08UfXdi9f vvTz86Pr/i5dulSoUEHp6tOnT2kyunHjRm9v7zp16uD/ChKJRPHLTp06LV26lB4XL15ss+rJkyfk T1TF7t27R2qguQI9Vd7X0v1PUWUA6AikjE2bNpEyatWqRcqw/p+L+NYSp06dovnB3r17L126RAUx Q4YMH3/8cdeuXZXJqxFYKkMXIVE7JxUSxrJly8jPrl27RqUkU6ZM/v7+gYGBNl+ljk8Mr169ouuw 1atX37lzh0oVaWDUqFFeXl7W4Sj/V7By5coLFy5QY9myZQcPHqz+X4GD+vVO4XumcuQH42IcljlM FL9MJBwPgBuHh6UydJE5apn7Zo1Z+ulpYFyMwzKH8EsBsFSGLjJHLXPfrDFLPz0NjItxWOYQfikA lsrQReaoZe6bNWbpp6eBcTEOyxzCLwXAUhm6yBy1zH2zxiz99DQwLsZhmUMz+aW0sFSGLp4ZtViQ QznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHM qMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyV oYtUUdv8o6wkvdJFqhwCFSPjYi3FpEmTpkuXrkyZMn369Pn000+F9c8MsNQ2/FIALJWhyztFHd+f 3Sf8CO90fLOMhWcqR35E+aU18+fP79mzp6FumQqW2oZfCoClMnSRyi9tXsgsY2Gu3noOxv1S2Tcu Lu7+/fthYWHjx4/38/O7fv262H7KDEttwy8FwFIZujjhly5IkbnGwly99RxE+aXCq1evUqRI4e3t TQv2m40bN2727NlJkiQZOXLkgAEDqPHmzZtjxozZsWNHVFRUhgwZPvnkk4kTJ2bPnp1W5cyZ88aN G2fPni1evLj1i1JLiRIlFEtevXr1smXLzpw5Q7vTYWmXatWqderUyd/fX9n49evXM2bMWLly5Z9/ /pkyZco6dep888036n2cHPfNSB4YAL8UAEtl6CLWLzt27EgneZEiRU6ePEnn8IsXL8qWLXv+/Hlq X7JkibL78+fPe/XqtW7dOio9tWvXnjZtmnK/6IS8kIMaZL+vfZnQLTGOd3c6LcAtCJxf3r17NyQk ZPr06aSZXbt22WxGOunbt6/aSHvRfPTjjz++deuW9TFJqKdOncqUKVPbtm2///77efPm0YlgvQG1 fPnll5999lmOHDnovNDsmNKlmJiYunXr2tzbNXPmzHT8bNmyOe6b03lgA/xSACyVoYtYv1QNskOH DkuXLqXH5cuXFy1a9MSJE+RPyu5t2rSha2d1Fyoi4eHhZH66L+S4Btnsa18mElJiHOxuJC3ALYj9 /DJ16tQNGjQIDg7OmjWrzWak8BEjRjRp0uTp06d0ATd37tzAwMCZM2dS+4oVK+jxjz/+aNeuXURE BLXTERRfJNekSzfrl1B8lHYfNmzYs2fPJk+e3L59exJnbGwszThJunTRefToUdqSnHvIkCGlS5cO CwsrWbLk7du36cjr16/v2bPn/PnzHffNiTww0zb8UgAslaGL8M8vySzJMsk4W7Ro8eOPP6ZKlYrm moULF1Z3p9knFZHixYtTEaFyQI+DBw+2uZrW7JXjGmSzr32ZSEiJcbC7qBwClyHWL728vFq3br1g wYIUKVLYbBYaGmp9dUUUKFDg8uXLBw8erFq1qtJCblejRg1qv3jxovK+a86cOSMjI+nakSaUP/zw Q8uWLXPlykW+eObMmaZNm167dq1y5cp+fn401ySHpvOFdk+aNKlyNBIwbXbp0qX8+fMrLXQ1SRd/ uXPnph0d982JPDDTNvxSACyVoUtifN9n2bJlHTt2VJe/+OIL6933799fvXp1pYUKCi0XKlSIbE+3 V45rkM2+9mUiISXGwe4O8EzlyI/A92OvXr1Kcz66uhowYEBISIjNZjdv3rT5UCB58uSvX79++fIl LSgttJwyZUp6Sgt0wPTp0z969OjGjRujRo3asGEDmeW4cePIHX19fR8+fHjs2DE6g65cuWJ9TLqG 2759O21Dy3QoOo59t8nUY2JiHPfN6TywAX4pAJbK0CWRvu9Dl8zKhfOqVatsdrcuIsp3KJQiovtC jmuQzb72ZSIhJcbB7g7wTOXIj9jv+zx48CBTpkxZsmS5c+eOzWaxsbFJkiSx3l1Xq59++imZH50d gwYNGjJkyIwZM6ZNm9a2bdv69etv27ZNeWm6vKOZKF3MhYeH79q168WLFw0bNty8ebMlfjFb9zm+ vhnMAwPglwJgqQxdEsMvnz9/TpM5ujr+8MMP6Zync9t6d3u/tPnOYXwv9E5+aV8mElJiHOzuAM9U jvyI9csnT56kTZs2WbJk0dHRui+hvBdy6NChKlWqKC0274V8/fXXI0eOrFy58qVLl+jijGyYpo+H Dx+ePHnyiBEj7PtDE9x8+fKRhunkoqelSpU6f/58VFRU6tSpEyN8sQeRDfilAFgqQ5fE8MtevXqF hYWpy/PmzbPe3fr9WCoo1apVs3lDlSAHpar09OlTHx8ftVG3BjnuZEJKTMJjNLgLcAEC348lSxs3 btySJUsKFy5MKtJ9CeWz9uLFi69YsaJIkSLqR/XqZ+2K8mnhiy++WLZsWbt27ZR3YpSPG0qXLk1z zZo1a5K26XKQXn3u3Lk0ASXDfvToEW0WEhIycOBAOsL48eNpY9rmxo0b+/btW7hw4bFjx4yHrxug qYFfCoClMnQR7pc7duyoX7/++++/v2jRoi5dupDtUUu9evXU3dXv+0RERFAR+f33320+EyJo7blz 52bNmtW3b1/1Q1PdGuS4kwkpMe+aEKd3AS4gMf7fZ+XKleRkui+h+13uV69ekfnR2bF69erWrVuT WZJl0lnz+PFjUmZ8r06ePXbsWFp48+ZNkyZNlHdubbB5PxZ+aQ/8UgAslaGL2O/7/P333+Rnt2/f DgoKGjJkCD0OGzYsW7ZsZH4ffPCBsntAQMAPP/yg7pglS5bw8PDMmTNbH418kVzQ5uDv9HsS+4gS UmIc7O4Az1SO/IjyyyRJkij/H9uvXz+6FkzgS9CkcPTo0Ta/Fc6RI4e6gb+//4kTJ2itr6/vP//8 kzFjxnLlyik/FyFJk4Pu3bv30qVL5Km0Oym/a9euzZo1U3ePjY1dsGABXTvSyfXy5Us/Pz+aj9IV aoUKFYyHn5AAzQv8UgAslaGLWL9s06bNmjVrqlSpcuDAAaoycXFx1atXP3z4MLV///33yu5Pnjzp 1q3bpk2bvL29a9WqRZ5q848BlrfvgNGl9HfffXfv3j3r7unWIMcR6ZaYd02I07sAF4BxMQ7LHMIv BcBSGbq4MmquGeYal9nBuBiHZQ7hlwJgqQxd4JfG4RqX2cG4GIdlDuGXAmCpDF3gl8bhGpfZwbgY h2UO4ZcCYKkMXeCXxuEal9nBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7l BONiHJY5hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQAh/wbi4+NT qVKl0NDQAgUKUGN8R6O19Hjp0iW15datWwMGDNizZ8/Lly/LlSs3dOjQRo0a2e9IB7Q57LZt20aM GBEREeHn5zdq1Cj1Rlrv1HMoxwjIoZxgXIzDMofwSwEY9Etlx6ioqJCQkJ07d/7666/x+eXRo0e7 dOlCC4sXL65YsaLSWKVKFTLawMBAX1/fX375JSgoaOvWrTYHt39Kh2rRosXSpUtr1Khx48aNSZMm LVmy5F17boFyjIEcygnGxTgscwi/FIAQv7S8/SflNGnSREdHx+eXPXr0yJMnD62KjIxU7+Oh/NWy 9a3bNQ9u87RJkybNmzfv0KGDE31Wj2aBcoyBHMoJxsU4LHMIvxSAqPnlzJkzd+zYEd/88vXr19mz Zw8PD6flkiVL3rp1y9vbm5Zpolm+fPl+/frZ/5mqA7/MkCFDRERExowZneizejQLlGMM5FBOMC7G YZlD+KUAhHx+mSpVKn9//9DQ0EKFCmn65dq1axcuXLhr1y5arlOnTvfu3QMCAmj59u3bY8aM2b59 +9OnTz/55JMZM2b4+fmpB4/PL728vMiAkyZN6kSfrXsO5RgBOZQTjItxWOYQfikAUe/HOm5s0KBB 27Zt27VrR8v/+c9/Vq9evWXLFusNaIY6derUI0eOKHf2sT8O5peygRzKCcbFOCxzCL8UgAv88t69 ezly5Hjz5o3aQhPEmzdv2tz98cWLF76+vtHR0ZrHsX7auHFjmp5+/vnnTvRZPZoFyjEGcignGBfj sMwh/FIALvDL4ODgs2fPLl26VG3p0qVLsWLFAgMDGzZsOGTIkPLlyz979mzmzJm7du06ceKE5nFs vh9LfkkHrFat2o0bNyZPnrx48eJ37bkFyjEGcignGBfjsMwh/FIAieGX1k9pgxIlSsyaNat69epq 48GDB/v37x8eHr5169apU6eSR3p7e1etWpUsM1++fJoHj+/3lzlz5hw1atS7fleW5fngYpBDOcG4 GIdlDuGXAmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJBDuUE42IcljmEXwqApTJ08cyoxYIc ygnGxTgscwi/FEAClWEiASWkqyYKR1qQQznBuBiHZQ7hlwLQVYb193dMkeqEdJjl+eBikEM5wbgY h2UO4ZcCcKAM+2+6uqhPhtHtOcvzwcUgh3KCcTEOyxzCLwWgqQwbv1EwUZ51+8/yfHAxyKGcYFyM wzKH8EsB2ChD02ksJkyy40BYng8uBjmUE4yLcVjmEH4pAFUZ8RkMY6AcI7CsKQzAuBiHZQ7hlwLw QJtUgXKMwLKmMADjYhyWOYRfCiCB80vTJTkh1wGmC0oqWNYUBmBcjMMyh/BLAeDzS+AcyKGcYFyM wzKH8EsB4PuxwDmQQznBuBiHZQ7hlwLA7y+BcyCHcoJxMQ7LHMIvBYD/9wHOgRzKCcbFOCxzCL8U AP4/FjgHcignGBfjsMwh/FIALJWhi2dGLRbkUE4wLsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BL AbBUhi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEgh3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyW OYRfCoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZUYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcY F+OwzCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQ QznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHM qMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyV oYtnRi0W5FBOMC7GYZlD+KUAWCpDF8+MWizIoZxgXIzDMofwSwGwVIYunhm1WJBDOcG4GIdlDuGX AmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJBDuUE42IcljmEXwqApTJ08cyoxYIcygnGxTgs cwi/FABLZejimVGLBTmUE4yLcVjmEH4pAJbK0MUzoxYLcignGBfjsMwh/FIALJWhi2dGLRbkUE4w LsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BLAbBUhi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEg h3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyWOYRfCoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZ UYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcYF+OwzCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgq QxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQQznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIv BcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY 5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyVoYtnRi0W5FBOMC7GYZlD+KUAWCpDF8+MWizIoZxg XIzDMofwSwGwVIYunhm1WJBDOcG4GIdlDuGXAmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJB DuUE42IcljmEXwqApTJ08cyoxYIcygnGxTgscwi/FABLZejimVGLBTmUE4yLcVjmEH4pAJbK0MUz oxYLcignGBfjsMwh/FIALJWhi2dGLRbkUE4wLsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BLAbBU hi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEgh3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyWOYRf CoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZUYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcYF+Ow zCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQQznB uBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHMqMWC HMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyVoYtn Ri0W5FBOlHEBxmGmbchCGMyUoQtqiig8TTmmAPI2Dj9hv0chQRnG4aeMhADlGMczlQMMgncm3MJ7 yDhgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbg l4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4Bf As6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4J OIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXg DMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4Az KCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6g rACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOy AlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoK YAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuA JRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACW QNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgC YbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE 7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2 W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grLgLJfP2 xDcW2B7by7z9f/dCKZEE2fSB7bE9tsf22P5/9oJfSkJ842cxj6SwPbYHrgFvnLgF+CXgDMoKYAmE 7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2 W4BfAs6grACWQNhuAX4pHYsXL54zZ05ERASdEvny5atZs+bnn39epkwZd/fLlKCsAJZA2G4BfikX M2fODAwMnDp1as+ePZMnT3769OlevXrRI4bJOVBWAEsgbLcAv5SLXLlyXb9+PTY2NkmSJErL+fPn ixYtimFyDpQVwBII2y3AL+XC29s7Ojr64MGDVatWjW+b3bt3T5o06bfffiNb/eijj0aMGNGkSROL 1d+V7dy5c8iQIRERETExMepeS5Ys6dixY1RUVMaMGZUWGvp3OpQZpYKyAlgCYbsF+KVcNGvWbMOG DbRQuHDhunXr+vv7V65cOVu2bOoGu3btql+//tixYwcNGkRjN23atAkTJmzduvXTTz+1/HsWtWnT Zv78+WfOnKlevfqRI0cqVaqUOXPmmzdvenl50dqLFy/WrFmTZrF79+59p0OZUSooK4AlELZbgF/K xePHjwcOHLhy5crXr18rLXRi1KpVa8GCBblz56anZJ9kgS9evEiRIgU9ff78uY+PT7Vq1Q4cOGD5 9yyi6WChQoXUYxYtWvT8+fM//fRT06ZN6SnNF5MlS/b11187cSjTgbICWAJhuwX4pYw8e/bs2Ft2 7979888/UwtZ5p49e2ghZcqUL1++tNmefO7p06eWf8+iN2/eJE2aVF0bHBxMM8gGDRps2bIlOjra z8/v6NGj+fLlc+JQpgNlBbAEwnYL8EvZmTt3bp8+fWgKSBNBy79+SbPP999/335jzbMoKioqe/bs sbGx169fpwnl/Pnz9+3b59yhTAePKACwAcJ2C/BLuaDT4OTJk9a/tlTeJs2aNevt27fpqb+/P807 f/vtt48//ljZ4OzZsy1atLh8+bIl/rOoVatWP/zww+TJkw8cONCxY8e2bds6fShzwSMKAGyAsN0C /FIu6DTImTPnjBkzatas6evre+/eveDg4OnTp0+ZMmXYsGG0wdatWxs1alS5cuVFixblyZPn3Llz 5H8932KJ/yzatWtXvXr1smTJEhMTc/PmzeTJkzt9KHPBIwoAbICw3QL8Ui5OnTq1atUqmgVeunTp xYsXadOm/eijj7p27dquXTt1m+3bt5N90rwwOjr6ww8//PItFqsfgVjsTqS4uLi8efNGRkb27ds3 NDTUyKHMBcoKYAmE7Rbgl4AzKCvAOawvGcG7wvWMg18CMaC+vCs49aQFYjYOS3nDL4EAUF+cA2ef nOBtCSMwzh78EgiA8RmSSCBjMoPRMQLj7MEvgQAYnyGJBDImMxgdIzDOHvwSCIDxGZJIIGMyg9Ex AuPswS+BABifIYkEMiYzGB0jMM4e/BIIgPEZkkggYzLj+tHRfEW1MUOGDA8fPrx7927mzJmtN6CW rFmzpk+fPioq6uzZs5MnTz548CBtmSVLllq1anXr1q1SpUouC8G+265/6cQGfgkEIPYMKV68+Llz 5zZt2tSoUSOlZfPmzY0bN6Z2Kgr09Pr162PHjt25c6dyO8+6detOmDDBz8+PVt25c6d379579+59 /vx52rRpc+XKdfr0aSG9EgvjmsIA2fySbO/o0aP2t8WllurVq9Pab775hs6CV69e2RzWLQJjrG34 JRCA2DNkypQpX331VZs2bb7//nulhZbXrFmj/ClgZGRkuXLlkiRJQi3ly5c/fvx4q1ataJuTJ0+S ZdavX3/Hjh0bN26sV68emS5dca9fv15Ir8TCuKYwQDa/7Ny585IlS7799tvu3btbb0AtPXv2pLUk 9RMnTpD4g4KCChUq9Pjx459//nnOnDm7d+92WQj23Xb9Syc28EsgALFnCE0fc+fOnSJFinv37vn4 +Dx79ixz5swvX77866+/cubM2bFjx2XLli1fvvzzzz9XtqflDh06UDvVlOTJk79+/frWrVvWN9lW e6iQMmXKtm3bzp07V7kxy8yZMwMDA8mAM2XKRDPa6dOnp0mThtoXL148e/bsiIiIDBky0HS2W7du FGBISMi8efOoh1myZPnyyy+HDh3q3G9PGdcUBsjml1OnTh0+fPjAgQNnzJhhvQG1kCBp7ejRo6Oj ox8+fJguXTqX9Tk+GGsbfgkEIPwMqVKlCl0gr1ixon379vT4xRdfUMuhQ4doVdasWe/evXv//v2M GTMqG9MyGSoZJNmksjZ9+vQNGzasVKlSgwYNFONUekj1ZdKkSaNGjQoODqbHiRMnUiNVIpqhFilS ZNWqVV26dFF8l5yyX79+dJCFCxcmTZp0woQJoaGh06ZNI4MkbybLpAv58ePHk7kOGjTIiQAZ1xQG yOaXGzZsaNasmXIL2/79+5MUSZyzZs369NNPt2/fTmv79u1748aNkSNH0lr1vHAXjLUNvwQCEH6G hIWF9erVq379+tu2bVPeYqWWHj160KpkyZK9eYt6I2taTvYWusTetGlT9+7daWKqrKJG2rFz585K D2/fvq3cGS179ux+fn40TbR+0djYWC8vL5pNPnjwIG/evNeuXbty5Uq+fPnUDfLkyUNz3MuXL3/4 4YePHj364IMPqOXq1atOBMi4pjBANr+MiIig6zmSIgmybNmy586dK1as2MmTJ6mF5EdrDx8+rLxV S7sUKFCgfPnyLVu2pKs9t/zxFmNtwy+BAISfIQ8fPiRjowOGh4eXLFmSjk+zRuW9pvjml+otQsk+ jx07dvDgwaVLl/7555+ZMmUi+1R6SI6YJEkSxReJmJgYKjR0VU6v8uzZM6X/tGVcXJy9K1v+tWrr fipHcyJA/IOg/Mjjl3QhmDJlSsvbe7+T7OlScv78+SR7urYjBb548YKUuWfPnpCQkP379798+VLZ vWrVqhs3bvT19XVZFA5i4QH8EgggMc6QRo0abdmypUSJEmfOnKFlmjgq7R06dFi+fLnyVq3Sorxh q7yPan2Emzdv0iQyefLkVEGs55d37tzJli2bMr+kBXq6efPmevXqkRcqVYkC0ZxfKo32X+t3Avil /Mjjl/SYP39+UuO8efP69u0bGRmZK1euWbNm9enTh9ovXbqk7kKXgMp0Mzg4mKaeXbt2XbBggcui sO82M+CXQACJcYasXr36s88+U5dbt26tLP/1119ly5al2eHatWvLly//yy+/0CqaEZ48eTJnzpzV qlXr3bt39erVP/jgA3LBli1bKl5r/fnl6NGjZ8yYMWLEiMmTJ5Pz0XX6oUOHaBY7ZsyYmTNnKoFY f35JF++0Je1CFWrAgAFk2LQZzTt//vlnWti5c6cT0TGuKQxw/eh4e3vTJJJkrF5I0avT3JHalV+J kBS3bt1apkwZ2uDEiRN0CtAGv/32G7WTzu0PSGZJl3rKhwsui0KBsbbhl0AAiXGGvHjxgszs2bNn Pj4+ZGkpUqRQV5Fljh07dteuXVFRUVQRaGo4fvx4uuK2vC0rf/zxB00BqfrQqvr160+fPp0WrOdz dChyYrpUp2K0Z88e8sULFy5Yd15ZXrRokfL92IwZM44bN44u1anxu+++mzt3Lm1P09ZKlSqRfdat W9eJ6BjXFAa4fnSyZ89++/Zt8jbSqtJi/S02ejpo0CCaMtLC4MGDp02bRo/Kd2WpnRRuf0DlnVvl Q32XRaHAWNvwSyAA+c8Q2XooW3+ANa4fnYCAgHXr1jVt2pRcMGfOnJGRkQMHDty0aVOLFi2o3fL2 Qk35vhvNJpU5ZePGjZX2bt26lS9fvnPnzjVq1FCuGs+cOTN8+PD9+/cXK1bs999/d1kUCoy1Db8E ApD/DJGth7L1B1jj+tE5d+5cxYoVnz17Zt3o4+Nz5MiRjz76yPLvX/kkSZLk4cOHvr6+jx49Sp8+ fVxcnPKnP5ofhydNmlTxYBfF8C+MtQ2/BAKQ/wyRrYey9QdY45bRuXjx4vjx4/ft26d8ylCzZs2x Y8cWLFhQWav8VWzJkiXV/3csVapUeHi48u2z48ePL1u27MCBA9euXYuNjc2UKZO/v39gYCB5sCtD UGCsbfglEADjMySRQMZkBqNjBMbZg18CATA+QxIJZExmMDpGYJw9+CUQAOMzJJFwfcZat269Zs0a m8ZWrVrVrl27e/fuW7ZsGT58+OXLl/Pnzz916tQGDRooG9y6dWvAgAF79ux5+fJluXLlhg4d2rBh Q9d0uECBAvRo/eNC9VM6Hx+fSpUqhYaG0jbUKDyN0LMRGGcPfgkEwPgMSSRcn7Fs2bIdPXo0d+7c astff/3l7+9/9erV8PDwZs2arVy5kkzoyJEj7du3/+mnn8qXL295+0e+1BgYGOjr6/vLL78EBQVt 3brVBb2lrnbp0sXy9l/v1Q/hVGuMiooKCQnZuXPnr7/+Cr+UDcbZg18CATA+QxIJ12dswoQJ//zz D9mM2kITx3Tp0o0ZM6Zp06ZNmjTp1KmT0k4WtXnzZrJMWn7//fcfP35s/eNXpfM0B50xY8azZ89o 2jp//nxvb2/L29/I0zH3798fExNTo0aNZcuWZcqUiZaHDRu2YsWKN2/ejBo1atCgQbGxsbSwaNEi 2r1x48YLFixInTq1TW979OiRJ08eyk9kZGRYWJj6umrGXr16lSZNmujoaPilbDDOHvwSCAD/7uYc rjz7aE5WrFixixcvpk2blp4+evSoYMGCf/zxR4YMGTJmzEgL5G3Klvfu3StevPj9+/dpmeZ2NNHs 169f3rx51UPRcDdo0IBslZbJZemwZJ+0XLRo0dmzZ9MuZGNjx46lV/zPf/4zcuRImgWSO/r4+Iwf P54Me+LEiYcPH6bdqSd0ZDLjefPmWXf19evX2bNnp1kvLZcsWfLWrVuKH1vPL2fOnLljxw7MLyWE cfbgl0AMsMx3xfWnXu/evWnSNmTIEFoOCgr666+/FKPy8vIii7K+3wt5GM0LLW//cZcmoNu3b3/6 9Oknn3xCc0o/Pz8aa+UmLbQBLdSsWfPGjRs2r/XixYvcuXOT6dL2e/fuVT6MVKD2nTt3Kr+UIG8u UaLE3bt3rfddu3btwoULd+3aRct16tTp3r17QECAxUpjqVKl8vf3Dw0NLVSoUOL5JTACS2eBXwLm ML7afVeuXLlSu3ZteqRskNuRjSme52B+qUJTOppEHjly5OjRo5RS9c4t1uZKq4YNG3b69Onnz59b /r3TC5nxq1ev6FE9VLJkyZThoEflH1Pp0fq1aPLatm3bdu3a0TLNUFevXr1lyxbL/74fq5IYfmmB ZRqD6+kGvwTMgV9a07x58xYtWlA21r9FaWzSpEnTpk2tP7/ctGnThg0bbPalKaOvr6/ykaE6vyT3 rV69+s2bN2k5R44cNAGlaWiaNGloPpo2bVp6Ifv5Zc6cOY8dO5Y9e3bNHpJb03Gs75tGXkvHz5w5 syv9UnKgarfgiVIDHgUqizU0BezTpw9lY+7cuf7+/mojmejKlSsrV65MM0ia25GVKt9Kbdiw4ZAh Q8qXL//s2bOZM2fu2rXrxIkTlNJGjRotWrSINujcuXPhwoWDgoJoOX369OS15Je3bt0aMWLEmjVr 6IVGjRp18uRJ688vv/76a3qV0NDQXLlyRURETJ48mWaQag+Dg4PPnj27dOlStaVLly7FihULDAyE X6pA1W7BE6UGPApUFhsUmySPtG6kCeVXX32l/P5yypQpZIdK+9atW6dOnUoe6e3tXbVqVbLMfPny WX8/NiAgICwsLHny5LQxTUkHDRoUGRlJc8fBgwf369eP0h4TE0OOu2LFCloePXo02V5cXBzt/u23 396+fbtgwYJkqOrN2ogSJUrMmjWL5qxqy8GDB/v37x8eHg6/VIGq3YInSg14FKgswvFMi5IKqNot QPeAOagswoFfuh2o2i1A94A5qCzCgV+6HajaLUD3gDmoLIAfULVbgF8C5qCyAH5A1W4BfgmYg8oC +AFVuwX4JdAG/28iLThnnQaqlhZTqBp+CTRAWZEcnLZOAFVLjvyqhl8CDfBuj7RgaJwGqZMWswwN /BJoYBb5eiAYGqdB6qTFLEMDvwQamEW+HgiGxmmQOmkxy9DAL4EGZpGvB4KhcRqkTlrMMjTwS6CB WeTrgWBonAapkxazDA38EmhgFvl6IBgap0HqpMUsQwO/BBqYRb4eCIbGaZA6aTHL0MAvgQZmka8H gqFxGqROWswyNPBLoIFZ5OuBYGicBqmTFrMMDfwSaGAW+XogGBqnQeqkxSxDA78EGphFvh4IhsZp 3J46mz/kwyCquH1oEgj8EmigK1+z6JsfyLzTuCZ1kZGRU6dO3bVr182bN5MnT16hQoX+/fvXr1/f 4iq/NKNCzNJn+CXQwDm/tC4HyZIly5YtW7Vq1YYNG1akSBGl8enTp+PGjVu3bt3du3ezZMkSEBBA T318fGx2T5kyZfbs2atWrUqFpnjx4uoxz549O3ny5IMHDz58+JB2r1WrVrdu3SpVqpTAoAzunkAS +8w3S2WREBekbv/+/U2aNCGd27RrninwSxWz9Bl+CTRwTr6a939IkSLF3r17K1asGBcXV7169cOH D1uvJVOkEpMkSRLN3b28vBYsWNCxY0daph3r1q376tUrm20S2EmDuycc+KW0JHbqHjx4ULhwYboa a9269VdffVWoUKEXL14cOXJkzpw5O3bscFlPzKgQs/QZfgk0MOKXyl7R0dF//PHHkCFDyCyrVKly 6NChNWvWtGnTJmvWrD/88EOZMmVOnjzZsmXLe/fuUXurVq2sd3/58uXly5cXLlxIhYbmqTQvLFiw YPny5U+cOFG/fv2goCCqRI8fP/75559pg927dyekbwZ3dy4JiYFZKouEJHbqJkyYMHbs2IYNG27e vNmJniSkcfXq1cuWLTtz5kxUVBRdZebMmbNatWqdOnXy9/d3cLcydffXr1/PmDFj5cqVf/75Z8qU KevUqfPNN9/kzZvX/uXGjRs3e/ZseomRI0cOGDAgwTlwErOoGn4JNIhPvo4/gLHfi+wwS5YsNMWk C+2AgIB169Z9++233bt3V9bOnz+/d+/e5JrkoJq701rapn///jNnzvT29iYPpov3dOnSORGR7u5l y5b99ddfly9f/vnnnystGzZsaNasWYkSJcLDwy0OS5V9Zuyz5LhUKbtTHnr06JEvX75t27aFhoYG BwfnyZPn999/tz6aWSqLhCR26ipUqHD8+PE9e/bUqlXLiZ7oNg4dOnTatGmaB6QNdBUYExNTt27d AwcOWK/KnDnzqVOnsmXLZv1y5JR9+/a12T1RMYuq4ZdAA1F+SdaSMWPGDz744O+///7www/JKi5d upQ/f35l7cWLF2mqR+00m9TcnWaENC8sWbLk6dOnyZ9u3LhBV7tkn3TMd41Id/fFixd36dKFSt6x Y8eUlqZNm27cuDEkJISurx2XKvvM2GygW6qU3SlR//zzDy3Url2byq718VXMUlkkJLFTR8P36NEj kjotONET3cbUqVM/e/Zs8uTJ7du3J9nExsZev36dRLVkyZKjR486Pg4xffr0IUOGlC5dOiwsjM6p 27dvBwYGrl+/vmfPnnRVar1v0aJFR4wYoXwQO3HixLlz5zqTjnfBLKqGXwINjHzfR2mkk5mscfjw 4Zs2berWrdt3332XKlWqF2+h6aayPS2negtVAc1jPnnyJO1bqAwtWLBAmZjSZgUKFCAfpYlpw4YN HRiVNbq7v3z5Mnv27GRX5GGlSpUip6eSRJ25detWpkyZEliq4suMbqlS9tq6dSs9NmjQgB43b96c LFmyTz75BH4pisROnZeXFwnjzZs3SZMmdaInuo158+a9du1a5cqV/fz8cuTIkTVr1uLFi9eoUcPm 5eILk4R35swZ6wvW+/fv00Vb7ty56bDW+4aGhlrPL12AWVQNvwQaGP9+rAJV/M8++2zevHlkinRW x8XFUUFRvt1D0FNqpKfUqHlMaqcaRNtQDaKnNOWi2d7+/fvJ25QNqlatSlNAX1/fhASluzt52MyZ M7t27UrmOmvWLJpWNmrUiPzekuBSFV9mdEuVshddztOC8oVhdRl+KQqzzy+PHDnSsWPHK1euWG9A c8Ht27eTLB0fx/L2a+eq8q2hUywmJsZ635s3b9K1o+MQxGIWVcMvgQai/JIMZunSpfny5aNlg/NL tZHO7YiIiMOHDwcHB1+9elWxt4SH5mB38rNChQpR92hOWbNmzdOnT//444/Nmze3JLhUxZcZ3VKl 7kUo1xPqsm6SExVO9SGxi7LynTKBn1++fv06efLk1o20QBdeZ8+epcus8PDwXbt20Ulk8w2jd/VL 642Vfa0val2DWVQNvwQaGPHLuLfQ/InmakFBQWSWdHrTuWr/+SUtFyxY0MHnl8ePH69QoYL6jRsb yO3o4BkyZHjw4IETMWruXrt27b1793bu3Hnx4sXp0qW7c+fO+++/r6xKSKmKLzO6pcp6L5tl9/ql hZFlJrZfjhkzZuLEiY0bN964caPjLZVvnz19+lT98TGRJk0aarlx40aOHDmUFpIiCdJBnxUNk7qe P3+uNipv5Ni/LVyqVKnz589HRUWlTp06vo65a55nFlXDL4EGxj+/VGjQoMG2bduojowfP75ly5Y0 XaPJHE3plLVhYWG9evVy8P1YWkvb9O3bNzQ01L4PypeJkiVLRqXHiRg1d1+/fn2LFi2U5d69ezv4 poNmqbLEU610S9W7+qVrTluzvEuWQBI7nLt37xYuXPjRo0dt27YdNmxYoUKF6CLpl19+mTVrFp0F 1lsWL1783Llz1E7aVq2iUqVKR48ebdWqFV1o0mXcsWPHevToceHCBbXPpUuXpiPXrFmzQIECNO+8 efMm6XPatGk2b8BkzZqVevLtt99+8cUXyvRUISQkZODAgdWqVaOTkQ5Fq8ib9+3bt3DhQvU7bu71 S/lVDb8EGojyS+ULrunTp6dz+6effqKzPVu2bNa/v6QT2/73l69evVJ+fzl79mwvLy+a1VEZouPQ tK9GjRq5cuWizahx+PDh+/fvL1asmM0vLjRJ4O7kc7lz57516xYtHzx4sGrVqkp7AkuVJZ5qpVuq 4JcuwAXh7Ny5s3nz5i9evLBpt3lRcsTAwECbtcuWLVP+mkNl1KhRkyZNsvyvMOwZN27c2LFj1afK Vab9q5O2mzRpYuPcNt2DX+rsy+ZkAAJJ4O9JVOwLvUq5cuXIGpcsWUL+QfZz5MgR67WO/9+Hpmhk PF26dInvpWmDdevWNW3aNIERJWR3sjQqQGR7ZIrqpzgJLFWWeKqVbqmCX7oA14Tz559/BgUF7d69 m666lP+PHTBggPL/sSpxcXGknO++++7evXvWXSIfDQ0NVd6S/fLLLwcNGqR+mE2Pp06dWrVq1d69 ey9duhQdHU1z0I8//rhr167NmjWzPvizZ89GjBixcePG27dvK1+UU48fGxu7YMGCFStW0OyW5r5+ fn50Caj8jMqVKbLHLKqGXwINBPrl8uXLO3ToULZsWZprPnnyhMoEzS+pTGTOnJmmlfRUfYtSPXiK FCloGkpW2q9fv5IlSyqNx48fpwvwAwcOXLt2jU77TJky+fv700V6xYoVExJRwnf/6quvpkyZQtVq zpw5amMCS5Ul/mrluFTBL10As3A4YRZVwy+BBh5bWejCP2/evJGRkeSs1apVc3d3NDBLZZEQZuFw wiyqhl8CDTyzslC88+bN69OnT/bs2a9fv+7ir9QnELNUFglhFg4nzKJq+CXQwDMri/qG8KRJk0aO HOnezsSHWSqLhDALhxNmUTX8EmjgmZWFok6RIsVnn302f/589WeXsmGWyiIhzMLhhFlUDb8EGqCy SItZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJi lsoiIczC4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWy SAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLC LBxOmEXV8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhQsJ58+ZNu3bt1qxZY3Nkpw9rs28C D2XkFY3vbs/XX389YsQII/2xmEHV8EuggUD5atYXm9cSK0LlgO96WHX7ROqPwKNZzFBZJERIOKtW rbp169aQIUNsjmwuvxROxowZHzx44PTuZlG1XEkHkiBQvpr1xea14nsh54qC4710jym8YMEvJUFI OI0aNRozZkzZsmVtjuzhfml8vmsxg6rlSjqQBIHy1awvNq8Fv0w4ZqksEiIknMyZM1+6dClt2rQ2 R1YO+9tvv3Xu3Pn8+fNFihRZunRpqVKl1NfNnj37/Pnz6XSg5ePHj3/++ed0Hdm3b9+pU6fa+OWw YcNmz55N269YsaJ8+fLWnVcPYi0q+1UTJkyYMWOGl5dXcHDwF198QWtPnz7dpUuXs2fPxsbGWr/7 ornxsWPHaOH27dv23XMQIPwSeCgC5atZX+KrF9ZnfuPGjdXt1XPb8r91x8EB1Yowfvz4OXPmREVF 2XRM2Ya2DwsLi46Otq4g9gXLvjxZHyciIoKK0a+//ponT57FixdXqlTJQUE0iFkqi4QICSdZsmSv Xr1KmjSpzZGVw3700UfdunUjRyEZLFy48MyZM8oGcXFxhw8f7tSp09WrV5XNevbs2bFjx0WLFvXr 18/GL+fOnausWrBgATmcusr6IDYXYTarSL0kyIMHD5Lt3b9/nzYoUaIE9Ype1Nvb27rDmhsXL178 yy+/pKfkiLRg/ULxBYj5JfBcBMpXs744qBcOioLFru44OKC6b6pUqWbNmtWuXbsUKVJY7Jxv2bJl tIq6Z11B7AuWzV42n4+WK1eOykqbNm327dsXGBh44cIFBwEaxCyVRUJcML8ktT958oSU9vz5c19f 35iYGNIezd7oyomkS5vRo/VmL168IH3a+CU1KqvoVegI1Gh/EPUVNVfRJDJJkiQ2HXv8+HHKlClt Oqy5Mc01nz59qtk9+wBtDugcZlE1/BJokNjzS8164aAoaK51fEB131WrVtEVNE0BybcmTJhg43x0 wlN1sPxvBbEvWOpael0yVxu/pFd/8+aNekzaxkFBNIhZKouEuODzS3VmRtdJyvSLNLBp06bKlSvv 2bOncePG6jS0d+/eHTp0WLJkic0Ejg41f/58ZVVYWJhyuWZ/EPUVHayy7ljJkiXpKlNzfmm/sRKF ZvfsA7TZ1znMomr4JdAgsT+/1KwX9mf++++/HxkZmTVrVs21jg9ocwKHh4dXrFjx5cuX1sfULBaa BStjxowrVqyoVq0alYm+ffva9I2i69OnT0BAgHr97qAgGsQslUVChISzcuXKO3fuDB482ObIymFP nDjRpUuXCxcuFC5cmIa+dOnSY8eOpUs9WhUYGDhu3Dhls3f9/NL+IOorOlhl3bFTp06RX/7+++// 9xbHfql+ftm1a1c6BV6/fq12zz5Am32dwyyqhl8CDQTKV7O+aNYL+zOf1pI/kcnRsmbdcXBA64pA jxkyZKD55ejRo62PGZ9f2hesZcuWDRo0iCaRQ4YMGTVqlE3fLl++3KtXryNHjrx69UrJGz6/lBAh 4cTExLRv397B76PYEB0dTWfB2rVrScyJ/VpmUTX8EmggUL6eU19cg1kqi4QwCydRee8t+fPnX758 ufod3UR9OYsZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWy SAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4S4IBwHP6sw+IsLITjdh9atW69c uVL5pXJiYBZVu38IgYQwK5QGSexi8U6YpbJIiHvDcZdfCnndoKCgHDlytG3bVkiX7DGLquGXQAPJ C6WLS09iF4t3wiyVRULgl05z4sSJiRMnbt68WUiX7DGLquGXQAPJC6WLS09iF4t3wiyVRUJc+X6s /X08NP8HQ8X+L/t79epVs2bNgICAtWvX7t+/v1+/fjYbWOK/64jak/es7g1gvYFm9+xvVKLy6NGj QoUK3b17N/HyZjGDquGXQAPZCqWDe4xonvnqXUcs/8ZifVcT+9sV2Vcr61dJ7GLxTpilskiIK/3S /j4e78V/4xGL1l/2x8TENGjQoEmTJhs3bty6dStp0mYDS/x3HbFe1mzU7J79jUpU3rx5kyJFCvXf 1RMjbxYzqBp+CTSQrVA6uMeI5pmv3nVE2cbmrib2tyuyr1bWr57YxeKdMEtlkRBX+qX9fTze0/of fxX7v+ynhb1799auXfvIkSP+/v6aG8R31xH1rgCWePxSs3v2NypRwfzyv/uyORmAQGQrlA7uMaJ5 5qt3HdG8q4n97Yo0i5EK5pcueC0X4Eq/tL+Px3ta/+OvYv+X/aTnevXqjR49esqUKdu3b69SpYrN Bha7u47Y3xWAGjVvMKDZPXtbVTl58iSdd/j8En4JNJCzUGreY8Txma95VxP72xXZVytrErtYvBNm qSwS4kq/tL+Ph+PPL+3/sp92b9OmTZ06dbZt2/bTTz8NHTrUZgOL3V1H7O8KQNto3mBAs3sO/HLa tGnUbXw/Fn4JNJCtUL4X/z1GHJ/5mnc1sb9dkX21sn71xC4W74RZKouEJHY4V65c+fjjj588eZJI x3cj+P3lf/dlczIAgTArlJok/HZF+P2lC17LBSR2OClTpqRZIF2WJdLxGWMWVcMvgQbMCqU9773F ZbcrEohZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQao LNJilsoiIczC4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0 mKWySAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWap LBLCLBxOmEXV8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouE MAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC 4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhh FlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV 8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwS aIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBqg skiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhhFlXDL4EGqCzS YpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV8EugASqLtJil skgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwSaIDKIi1mqSwS wiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBqgskiLWSqLhDAL hxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhhFlXDL4EGqCzSYpbKIiHMwuGE WVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV8EugASqLtJilskgIs3A4YRZV wy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBL oAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBookgLSIn9lkRCoWnLkVzX8EmiD 4iItLjtnmfmlBaqWGFOoGn4J3Ay/oswGDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiFPkCaUGJcAKoWnLgl8CsoLhIC+qD00DV0uK0quGXAAAAgD7wSwAAAECf/weaRxVqCmVu ZHN0cmVhbQplbmRvYmoKNDggMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNTQgMCBvYmoKPDwv UjUzCjUzIDAgUi9SNTIKNTIgMCBSPj4KZW5kb2JqCjUzIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UK L0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCA1ODcKL0hlaWdodCAyNjIKL0JpdHNQZXJDb21w b25lbnQgOAovRmlsdGVyL0RDVERlY29kZS9MZW5ndGggMjAwNjg+PnN0cmVhbQr/2P/uAA5BZG9i ZQBkAAAAAAH/2wBDAA4KCw0LCQ4NDA0QDw4RFiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIy SGJJTlZYXV5dOEVmbWVabFNbXVn/2wBDAQ8QEBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVn/wAARCAEGAksDASIAAhEBAxEB/8QAHwAA AQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIh MUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpT VFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAA AAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEI FEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm Z2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0GSITQ7JBwRzg1G5EShQO AKmY4H1qpcSAMODQBBdhZFBYZ2nPNQyhJBu7LRdNwCmST2qhcSsBsAI+lAE4PnIwTAx0rMugsIDT kHecCrassKqCfmajyVnyJMEKcjIzQBl39pHc2pSIupyDuHWsyJ54G3NE5jX2rrLGBlaTOOT1pdUl W3sX2Rq7gcAY5oAxbbVEkVvKDFF65HSsPW7v7SoW3Uhz6+ldHZ6b9utVn8t7ZnHK96wtZ0uS0QgS lm6DjNAHNi3unw+8nb1GamaYwRbdp5/vd6sQ2lwEIUkt1NOltS6AyHnuKAIYplKAtjNQXUyOQo69 frUN1aNG3yEiq7GdVG4HHQUAWdyhSZSABVW4VAEZOjLn9SP6VMfLdAHR2PfDY/pR5QCgOrMuPkAb BAyeDxVpItJW3K0ZzxjJp/TBxxSHbuzGrKB6nP8ASnZwc9frUEMccFcHO6rFmWQnnA9TVTc3UDIF S7sx529qANWS8UZAbD9sd6jF28uFjLAnqccVlI8gcCNS5B6EZrr7a1DWSt5ABxk4oApWcMSDGCzN 1yK6Gzi8oAnaq44FZSr5KAk4WtZbmGRI1IJHY+9AGjDNbqwVsbjzxVhVhkJI5z2rFXzRKCq8dMmt 2yiQKTxvPJoAbDFJFJwgZT39K0bdChBIIJoSMqwORzVryz65oAdGuGDVP2qGMHJDc1N7UALjPag5 ozzRnnigBCOMVBa2726vvlMm5iee3tVjpRQA1ZVYgKRk807P51G0YDK6qNw4p+0FgT1FAC4xUc0K zIEkGQDmpM880pP5UAMMYxjpj0peaXmigA5o70Zo60AFGcZJPFFIQCCvrQA1JUkzsYHHHFPFUdP0 yKwkmeNmYytuO45q9zQAYGfemz/8ekv+438qUEnrST/8esv+438qAK0P3D9akqOH7h+tVNT1JLCL Aw0zD5U/qfapGLf6lFZMEODIV3YJIBH1APJpl1q0MEcZAy0kfmBWyOOwyAef85rHdFtkN1qA867l +ZIm7e7f4fh9L+n6UZmN1qIMkrnIRu31/wAP8hgafmCa3jlUEK4DDPXkVDp3/IOtf+uSfyFWZvuD 61W07/kHWv8A1yT+QoQiaUuIXMQDSBTtB6E9qrwXt5BCkSaYSFGMm4XJ9zx1PWrdRrF9quNhLiKI ZYqxXLHoMj25I/3aYDP7Svv+gZ/5ML/hR/aV9/0DP/Jhf8Kt/wBnW/8A02/7/v8A40f2db/9Nv8A v+/+NAFCe9vJ4XifTCAwxkXC5HuOOo61YiLmFDKAshUbgOgPekaL7LcbAXMUoypZi2GHUZPtyB/v VJQAUUUUAFFFFABRRRQAUUUUAFFFFABVS7+9+Kf+hVbqpd/e/FP/AEKkxokp8n3h/uj+QplPk+8P 90fyFIbLrEd6qXLL61YkcKvNZF9N5g2JnJ71RI6dVypU/MB2qvI8ahhLx3zVO3uJIpiGG8H3qtd3 /wBoZowu0g96AJIQlxM7HJUHAqwWER2D7vSq1q/l4VkwMdqJ5N0uAaALP2xLcoxOATjFLIjzXcb7 lEajJBrCu3lnlKMh8uMggg9TWik29RgnpQBpXF9HBEV3BRjHFYl032ojDHn9akmweDz9aoyq8G0o M8+vSgBbm3NvZyGEbnxxn1rIgMk8INygSQ9hWnLNOQRnjtWVqLvHb7x8rAUAQzmOP7xHHrWTdSNI DtUBR6U4iSdA7P1pBhRt9aAK8BbBB7+tWOSiDPKjH6//AF6ZIu049qbuO7IJJHancd7Egi52g0xh tJzjFIzTZ4xzSNG8oG44pCIUyZfl6E9atxQ+Znc2farNtaqiAEZz1q/BaRMQwTBXvigA0rZDL5jo oA7kVuRyyOhMQGCeMUy2tIWQZGRirlvELeM7VG3+dADHty0QDKORTrawjZwA5PqD0FWrJ1uN394H pVz7Mv3ivT0NAEkVt5A7PkVLGqueFxinROSvPQUsSAy5TJz60ATwb84H61bjdh8rCo4kwTn9KnTb kdz70ASpnOalFNWlFAGfrEl9HHGbCNXcuA27sKvx7jGpYYYjmlP50vSgBCoOD6Uv4U0PmQptIx3p 3egAPNLkUh6ZoHegBNwBAJ5p3TpTGRWYMRkjoad2xQAHnpTVUjJyTzTvWgUAHel6U3dkkd6U0AKT WDrXiK30q6gt5AxeVsDAzW72qpdada3bxvNCrshypI6UATxyB0Vh0IzUme9IqhVCgcDtS0ANZcsG JPHaif8A49Zf9w/yp2efemz/APHrL/uH+VAFRd/kP5e3fzt3dM44zWLZWsmDfXCmW6lP7hWxgnGQ ev8AhjH0rch+4frUYtVESxrI48s5jPGU4xgcc8ZHOaQzGsIgsz3t6Hlm8vzxgAhV5wfrxwO3H4b6 NvQNtZc9mGDUJtIvLdBuVXiEWAeijOMfnU+DuJycY6dhQAyb7g+tVtO/5B1r/wBck/kKszfcH1qt p3/IOtf+uSfyFCETSyCKF5GyVRSxx14qC01fToIAr3IMjfM5CNyx69unYewFWqjPmSTLDCyq2NzM ylgo/Ajkn+R9KYB/b2m/8/P/AI43+FH9vab/AM/P/jjf4VJ9kuv+fmH/AL8n/wCKo+yXX/PzD/35 P/xVAFW71fTp4CqXIEi/MhKNww6dunY+xNTxSCWFJFyFdQwz15pB5kczQzMrNjcrKpUMPxJ5B/mP WpKACiiigAooooAKKKKACiiigAooooAKqXf3vxT/ANCq3VS7+9+Kf+hUmNElPk+8P90fyFMp8n3h /uj+QpDZNPyOtZbkpIQcEdq1Zl/dnPYVizSR7zucBvTNUSR3SK8RZcBh0rAvUKTJJIuC3vXQTx7o 8o2CetY2pJ5gELEH3oAIt0sfyMcDuaryxzmUIznnuKlImWAIgwo7gVELrywOWZvVhxQAXiyIFVTj A656moVuWjAyQKrPdPcyPkgc8AGoV3SyEE8jrQBpC6aRx6D9aivJ3cbY/vHpVe4M8FvvgQSMTjFP EwDK0mFJHSgCJLoxgrM+WHYVn6jLNcxkKpVB68ZrSkREdpMZLetU7iXcpUCgDFtkcq3OeenpT2i7 kdKieYwzlV4yamZyx5NAFaRstzx70qgNk46VZaBZE4IB9acLfavWgCvtO3PWnI/zjJHoKupaMkeW HGM5pv2XhGHTNAD4GO/nB9K1LcnIB6VWSDyyOnrWrawllB70AWVjESggjBpl1cywlFUKY2OCfSrK okuI3GJF5GOlMuLdVVQ4GR0wM5oAsWUR5ljYZ9q04ZBJ8u8Me9ZFmzK+QAsRHNWdjo2+L7p/nQBs JEVUlcE0+FMyDIwKgtDK8IYnnqRVuPccAjj1oAtoFVcCk2fNuFIo44OalSgByNzjpT6aFAangUAL 1ooBDZI5oxxyaAD0FHaimBGEu7cduPu0APxQRkY7UZqOZC6gK5U56igCQDAwOBSEEsCDgDtSjPSg CgBAQTikZgoJJ4FOAApGXK4oA5uHxXZy622nqTvHGeozzXSKwYcd6xI/DdimqtfiMece559P8K2l UrxxxQA6g9DRmg84oAaMbs5p1NCBSSOpp1AC0y4/49Zf9w/yp2M02f8A49Zf9w/yoArQ/cP1qIg3 E0iF3WKMhSFOCxxnr1xgjoR3qWH7h+tV7wSwq8tuyq0m1CCONxO0N+ozwcgAUhkOH+2+V50v2bPl 7d3zb9u773XGPfr7VZANvNGgd2ikJUBjkqcZ69cYB6k9qqf2c/2j7R8m/bt2b2z16+Z1z+HTirFm JZlSW4ZWaPcgAHG4HaW/Q44GASKALE33B9arad/yDrX/AK5J/IVZm+4PrWTb6ilvaW8bBciFOrY/ hFVGLk7ITNVmCqWYgKBkk9BU1hGViMrgiSY7iCOVHYe3HUepNYzapDMjRlFYOCCA/UVl3txptmIw dPkleQkKkcvOAOTyRx059x61bpTSvYVzt6K86fWtLjiWR9JnWNvus1wgB+h31BH4j0iVA8eiai6H oygkH/x6o5WM9Cv4y0QlQEyQncAByw7j346D1AqFWDKGUgqRkEdDXK6bfaVqSSGKxdGiba6SS/MO M8gE4/xB9K2Y9QSONUSHCqAAN3QVoqM2rpCujSorP/tIf88v/Hv/AK1H9pD/AJ5f+Pf/AFqfsKnY Lo0KKz/7SH/PL/x7/wCtR/aQ/wCeX/j3/wBaj2FTsF0aFFZ/9pD/AJ5f+Pf/AFqP7SH/ADy/8e/+ tR7Cp2C6NCis/wDtIf8APL/x7/61H9pD/nl/49/9aj2FTsF0aFFZ/wDaQ/55f+Pf/Wo/tIf88v8A x7/61HsKnYLo0KqXf3vxT/0Kov7SH/PL/wAe/wDrVLbst653AqBjofTmpnSnFXaGmSU+T7w/3R/I VL5Uf+1+f/1qoWd6L+AzrGY18x4wCcn5GKZ/Hbn8axGzRkO5CCOtcnqmhy3GoRTi6ZVQ8oO/+ea6 44xjrVSSINJnHaqEczd29ykeEuSoxWZ9muhOkszll9K6ma1RpiGJIqG7tR5Yx0FAGdbSxOG+Ugr1 zSzbTF8ygZ9KpXqbQWRWCHqR0qFri5EtuLRQ8Y+/u9KAIE05bd3l5OecGmTRvCDNEu49MVr/AD3m 7YCqVGIsLsTOB1zQBnAytGuRsz1xUX2Q+YSSXPv0rXnWJIxuYKPWn2qqVIOPrQBjSxugGULA8YFR PZkruweldIvlk4UAn6VAUBYoy49DQB53cQuL0K3UtxWq9iwjBUE5HpV7XNOJ2XCcPGeg71bsLgXc QDAKQMUAYFtE8YIkBLVY2nYducetbE/lW5Pm4JxnNQmMSossPCd1PegCHl7L0+lOsNNa5tx5b5Xu TUyaa+xirOqOOlRaezW9ysMZYAfe4zmgBJT5TbGxuj6nPWt6xxJGCqgjHWqur6clykboMuetV9Ov 3s5Ps0pVABjJFAF9pWW5IORjvVyVmMW5F3P2BNQ3Ue+SNo2BU4JNXmhPyqoGO9AGbHM6ybPL4rQt VW4XKkgCpUgCxseMmktLeSOcucBT2FAFmyWRZGOeOmK0UJPBGMelMTb2GP61YQAjPTNAEZDdmIz3 qaEu5OVwB3z1piYLFRzg1T1q9u7C3jaztjOzMAQO3agDYHXjtS1Fau0kCPIuxmGSKmoAaFAzgYye adUBE/2oEFfJxyO+amPA460ALmjqc0dxVGa9li1CG3WBmRwSZB0FAF4kZo+lGcdRR7UAL1poPz4w aFYEHGRVa4uobCLfPJtUnAJoAtGlpitvUFehGQaXqRQA1YwsjMM5an9KQjKkA4PrVa+knt7J3gTz ZQPlHqaALQINBrM0YTSQfabhWSWXloyc7fatJmwtACnnFBOCKM0frQBCTL9pxgeVjr3zUk//AB6y /wC4f5U6mz/8esv+438qAK0P3D9agvDK7C3jEZEsb535xxgdvr/noZ4fuH60/aNwbA3AYB7/AOeK kZlGW5uDCILkohcAOyDfzGW5wcEYI7fy50LQq1nAUXYpjUhc5wMdM054IpE2PEjLndgqCM+v6mpK YEc33B9a5i51WXR9Dvb23SN5ooLbaJASvOAc4I7Gunm+4PrXOLaXrpFJbq4VoY+Vk25wo9/rWtKP M2r29RMknur27t/tV3GLaGSVfs9sV+eNQrfM5/vNkfL2wO+a5tryKa9aWSRRu/dwgn+HPUe7HOPU KPQ1uXWm6ncW8kWZVLKQrGXO0kYyOfesf/hFtc8ry/tq+Xjbt+zx4x6Yz0reUGociafzRKMXUre7 iNzMpBkLApcFkGxDkbPmI24z1HXNJphuy0ASdp5A585vMZ49mAcEnjeM8bfxrU/4QrUv+etv/wCA kX+NWv8AhGtf/wCgh/5Bj/xrD2UvL71/mO5Xhu44bszRzCTym8q4GR8qk5BOMfdPc9Bu71e1DUJL S4ssBDBNL5L8HcCR8uO2Mjmqx8La4Q4N6pD/AHh9nj+bjHPPPFaLaBdTWC2l1CZ12qrkyAFyMc9c 9RmuuheMXFtLtqiWZ7arcO2nRxCJGvd7h2UsFQDcoIyOcEZ565qu2v3B0myvPKSOOVis8u0usWDg HaCDgn349zitq40K4uTG0tsd0ZJRll2suRg4IINRt4cka2S3FsywopUIk20EHrnDc/jWza1tNff6 f8EDNvNXuorh4oDbSKlkbkyEHDEHsAeh+vfOTjBbf689tZwXUbRZeJJTbFGZsEjPzg4Uc4BI61em 8LTz3omeIiIQeR5SPsGM56hhx2xUtz4ZN0FEtkCFTYAsgX5cggcEcZA4qW97SX3gV47+4uNWuraM xRxW3l7tyFmfcMnByMenQ1S0/X7u5R5Xs2aIx70Mcb/Kd+3aTg7uMEkDseDWwPD0wnEy28iyYUFl nI3bem75vm/HNLb6BPakmC3dAc/IJvkGTk4XOB+Aqrq/xrr1AyNKupLjVNUhmnnkUrHt3K8YXKnO B/D1478ZyetNsmnmbUbmzmmMao0Nqrys4dgOX+YkHnABzjGa3I9EuIriadLbEs2N7eYOcDA702DQ ri3tRbQ2xSIAgAS8jPXnOe9CUNLyXXqBztjNdSXD2cc1ykkmnZbz2cFZs43AtyOvbj8qv2kpj1GS zdZYpzB5iut08ygZx0fgHOOxrSh0CaFZQtru87/WF5A5fjGCSSSMdqI9Anj3Fbdy7KVMjTbnx6Bi cgfQ0oqKt7y+8DIn86H+0ZLa4l+yJaMvzSsxEwzypJJ4HBwevuDjpPCCudHjZJWM0kQffKzSfMU6 4J6Z7Aj8Kz4/DkscTRLBKYmQxlGuCw29MAFuPwrZ0G0XSLaRJcwxIC/7yXcFUL6knAGKwr8vLo19 40TfZNZ/6C9t/wCAB/8AjlQaEqJpgVJTKBNNlzHsyfNbOBk4Gc456Vi2tv4RtdbfUo9QtezRwbxs jfuwH5YHbn2xr+G3WTR1dGDI085DA5BHmvzXAWbrMAm6qjO7tuBwDUznAAJzVZkmW5Lbx5JA+XHS qEPAHmncOveop48njgZq55QcA/limSxBhtZiAPSgDLv7WOaDYgwfWsX+z50jQI20HhjjtXT+WuTk 4FZUpWS4njYkxRsFK5wGbAJz6jBHH1yOlTOSgrsqMXJ2RZhijgtkSIq2Bg1m6haLKrFSY2AySDTm +wIxVobNSOxjT/Ck3ad/zzsv++ErD6wuxt7DzMJ5lEJiOXbPfvWha28zWwKJgnj6CtLybX/n1t/+ /S/4UeTa/wDPrb/9+l/wpfWl2H9XfcNNsTFHmRsk1cFskjH5RVPybX/n1t/+/S/4UeTa/wDPrb/9 +l/wo+tLsH1d9yo9kwDyXA2gNwD6ViLZSpcySRL+7PIHrXTeTa/8+tv/AN+l/wAKPJtf+fW3/wC/ S/4UfWl2D6u+5z5trm+RVKBUB9Ke1q8MYxHyDgHORW75Nr/z62//AH6X/CjybX/n1t/+/S/4UfWl 2D6u+5nRTSXMQjVdr4wDjio7XS5opnaUASN0PrWr5Nr/AM+tv/36X/CjybX/AJ9bf/v0v+FH1pdg +rvuRpBdPIHePCrwR61FrOlR30KyIu2QDH4VZ8m1/wCfW3/79L/hR5Nr/wA+tv8A9+l/wo+tLsH1 d9ylHbFLSGGFNr5HL9Petrym8sdAQKpeTa/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWl2D6u+5PCr MduOAa0Ng2ggc+1ZHk2v/Prb/wDfpf8ACjybX/n1t/8Av0v+FH1pdg+rvubbggKR1FTqf3eRxXO+ Ta/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWl2D6u+50kQ/ixVjaGAyK5PybX/AJ9bf/v0v+FHk2v/ AD62/wD36X/Cj60uwfV33Oux2proWZSHK7TyPWuT8m1/59bf/v0v+FHk2v8Az62//fpf8KPrS7B9 Xfc6+j0rkPJtf+fW3/79L/hR5Nr/AM+tv/36X/Cj60uwfV33Ow6UmBmuQ8m1/wCfW3/79L/hR5Nr /wA+tv8A9+l/wo+tLsH1d9zryenNFch5Nr/z62//AH6X/CjybX/n1t/+/S/4UfWl2D6u+513BPWq uomAoiXERkVmAAxnmueNlEqbzYRBP7xgGP5UzybX/n1t/wDv0v8AhR9ZS6C+rvudag2qAAAoHFOz iuQ8m1/59bf/AL9L/hR5Nr/z62//AH6X/Cj60uw/q77nURSu8sivGUCnAPrUwGeM1yPk2v8Az62/ /fpf8KPJtf8An1t/+/S/4UfWl2D6u+51wwDgUp6VyHk2v/Prb/8Afpf8KPJtf+fW3/79L/hR9aXY Pq77nUWqzqjCdg5JJBAxxU461yHk2v8Az62//fpf8KPJtf8An1t/+/S/4UfWl2D6u+512Rk46imS Z+xS7jk7W/rXKeTa/wDPrb/9+l/wo8m1/wCfW3/79L/hR9aXYPq77nSQ/cP1rM1OS9sV89pf3Lyb VVWXIB57p6BvXqOuOc7ybX/n1t/+/S/4UeTa/wDPrb/9+l/wpfWV2D6u+5siz1bjNxGemcMPbP8A yz/3vzHpzVifUZNRksvPHmxKGY7lCkfL0+T3P5j05oeTa/8APrb/APfpf8KPJtf+fW3/AO/S/wCF P6zHsH1d9zpJvuD61WVAihVyqgYADEACsTybX/n1t/8Av0v+FHk2v/Prb/8Afpf8KX1ldg+rvubm P9pv++jRj/ab/vo1h+Ta/wDPrb/9+l/wo8m1/wCfW3/79L/hR9ZXYPq77m5j/ab/AL6NGP8Aab/v o1h+Ta/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWV2D6u+5uY/2m/76NGP9pv++jWH5Nr/AM+tv/36 X/CjybX/AJ9bf/v0v+FH1ldg+rvubTSRqcNLg+hf/wCvSebF/wA9h/38/wDr1jeTa/8APrb/APfp f8KPJtf+fW3/AO/S/wCFH1ldg+rvubPmxf8APYf9/P8A69Hmxf8APYf9/P8A69Y3k2v/AD62/wD3 6X/CjybX/n1t/wDv0v8AhR9ZXYPq77mz5sX/AD2H/fz/AOvR5sX/AD2H/fz/AOvWN5Nr/wA+tv8A 9+l/wo8m1/59bf8A79L/AIUfWV2D6u+5srJGzBVlyScAB+v61N5Mn92X8zWB5Nr/AM+tv/36X/Cm PDblo0S2tQXJG4wqQMAnp36U1iU+gOg+50Xkyf3ZfzNIYnAyRIB6kmuea2t1IDfYgScDNovP/j1H 2a337P8AQt2M4+yLn/0Kn7dE+wZv4/2m/wC+jSgYOeSfc5rn/KWCVRH5SMykrJBH5RBGODgnI5HB 446VsWFybuzjlYAMcq2Om5SQce2QcVcKinoROm4liiiitCC4FVhTXj42nGKmxxUSmRy4ZAAOhz1q hEUMTq5x92neWzNlqV51QqhOGbpinjIBOc0AVbiEtGc9RXMyuy3l5kc+cP8A0XHXVSM7HCg4Ncpd vHHqN6ruqt5wOCf+mcdYYj4Dah8Zq6VY2t1A0k9rBK5fG54wx6Duas32lWCabdMtjahlhcgiJcg4 PtXOrdKmfLu3QE5wkpA/IGla83oyNfSsrDBBnbBH51nHEJRSsy5UG5N3Q4SnHSjzT6VH50H/AD1T 86POh/56p+dcVmdl0SeafSjzT6VH50P/AD1T86POh/56p+dFmF0SeafSjzT6VH50P/PVPzo86H/n qn50WYXRJ5p9KPNPpUfnQ/8APVPzo86H/nqn50WYXRJ5p9KPNPpUfnQ/89U/Ojzof+eqfnRZhdEn mn0o80+lR+dD/wA9U/Ojzof+eqfnRZhdEnmn0o80+lR+dD/z1T86POh/56p+dFmF0SeafSjzT6VH 50P/AD1T86POh/56p+dFmF0SeafSjzT6VH50P/PVPzo86H/nqn50WYXRJ5p9KPNPpUfnQ/8APVPz o86H/nqn50WYXRJ5p9KPNPpUfnQ/89U/Ojzof+eqfnRZhdEnmn0o80+lR+dD/wA9U/Ojzof+eqfn RZhdEnmn0o80+lR+dD/z1T86POh/56p+dFmF0SeafSpbeZVuYjIPkDDd9M1W86H/AJ6p+dHnQ/8A PVPzpq6dxOzNGCN4NYv9QvWP2U7/AN6W+Ro8fKB69uKjha8k0nSXtYI2kl3+axjDHAPGc9vest4r GSTewiL+uadeSR3YtIZHt/s1uGAXud3/AOoV0qrHqjndN9Ga6ywSXOqx2vzvCQIdiCQnP3tqkgMQ c96IrkGa9JtGQxWJlxOig7x32gnGf8ayFWzWIxAx7D1GaasNgqMgEQVuozU+0ja3KP2cu5fubh/s WlSMqeZcLJvKqFzgjHA+tR+afSq4FoHVw0e5BtBz0FSedD/z1T86ym+Z3SNYLlVmyTzT6UeafSo/ Oh/56p+dHnQ/89U/Oosy7ok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR 50P/AD1T86LMLok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T 86LMLok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok8 0+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok80+lHmn0q Pzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok80+lHmn0qPzof+eqf nR50P/PVPzoswuiTzT6UxpSJYjjoW/8AQGpPOh/56p+dMkliJVlkjJUk4LYzkEdfxpxvcT2L2lyy PqCgCPYEbzvNI2eVxvzn8Pxx2zU2qSxC2tmsNhsN5553+bg/e3c/d6e3/Aaxy8TY3JCccjM/T/x2 jfFu3bId3TPn8/8AoNbKVo8pk43lzE5mZnhJHZ//AGStnQDnSkP/AE1l/wDRjVhJLGXUs8aBQQAJ N2c49h6VueHyDpKEHI8yX/0Y1aYf4mZ1/hRpUUUV1nKaRHtTWUlcKcUxp8SogViGGdw6CpOc+1UI jaIHtk0bGAxUp9qr38ssVnI8CF5AuVHqaAJAmBVGzGLnUQP+fkf+io6safLLNZRyTpslZclfQ1V0 5nebUGkXa32rp/2yjxQwLtFFFSMKKKKACiiigAooooAKKKxrb+1dQutQFvf29vFbXBhVXtfMJ+RW zneP73p2oA2aKzv7O1v/AKDFr/4An/45R/Z2t/8AQYtf/AE//HKYGjRWd/Z2t/8AQYtf/AE//HKP 7O1v/oMWv/gCf/jlAGjRWd/Z2t/9Bi1/8AT/APHKP7O1v/oMWv8A4An/AOOUAaNFZ39na3/0GLX/ AMAT/wDHKP7O1v8A6DFr/wCAJ/8AjlAGjRWd/Z2t/wDQYtf/AABP/wAco/s7W/8AoMWv/gCf/jlA GjRWd/Z2t/8AQYtf/AE//HKP7O1v/oMWv/gCf/jlAGjRWd/Z2t/9Bi1/8AT/APHKP7O1v/oMWv8A 4An/AOOUAaNFZ39na3/0GLX/AMAT/wDHKP7O1v8A6DFr/wCAJ/8AjlAGjRVO2sdUjuY2utSgmhz8 yJabCePXecflV3I/uj9aAEopcj+6P1pssgjid9gO1ScZPNIBaKqaXcve6VZ3UgVXngSRgvQFlBOP bmrdABRSrjkkZwKiRpHRW/djIz90/wCNMCSim/vPWP8A75P+NNdpERm/dnAz90/40ASUUkj7Vyqr nIHOe5+tJ+89Y/8Avk/40AOopuX9Y/8Avk/40m51ZAwQhjjgEdj70APopkzHYAvykuq5HUZYDvTp H2rlVXOQOc9z9aQC0U3956x/98n/ABo/eesf/fJ/xpgOopm51ZAwQhjjgEdj70TMdgC/KS6rkdRl gO9IB9FJI+1cqq5yBznufrSfvPWP/vk/40wHUVG0hX7zwr9Qf8aBIcocxsrHGVB9D7+1AElFLkf3 R+tGR/dH60gEopcj+6P1oyP7o/WgBKKXI/uj9aMj+6P1oASilyP7o/WjI/uj9aAEopcj+6P1oyP7 o/WgBKKXI/uj9aMj+6P1oASilyP7o/WqmnXL3du8kiqpWeaMBc4wkjKP0UUAWqwbCGFrd2eCB2M8 3LRqSf3jdyK3qxNO/wCPV+/7+b/0Y1a0km9RMn+zW/8Az62//flf8KQwW+f+PW2/78r/AIVL271k 3UWsm4f7JPaLBxtEiMW6dzmujlj2JN2+F6bi3+ybPKDfvM+ntV/nFL0xxRXIUU727lt3iEUDSh22 nH8PvVzOV5ox69aRs44GTQAoxis61/4+9R/6+R/6KjrQVg3QjIrPtf8Aj71L/r5H/oqOhgWqp2U0 kt1qCO2VhuAiDHQeVG2PzY/nVys02V9Fd3Utrd2yJcSCQrLbs5BCKvUOP7vpSGSpqSPIo8mZYXO1 JyBsY9sc557EjB/EUJqSPIo8mZYXO1JyBsY9sc557EjB/EVDDpkkaQ273CvZQFTHF5eG+U5UFs8g EDsOgoh0ySNIbd7hXsoCpji8vDfKcqC2eQCB2HQUAGmah9oLQuWlmE0wbaBiNVldVz+AAHc/mat3 MyxT2iFnBmlKAKBgnYzYbPb5e3OQO2arW2li1k82GXbK0sjyHbxIrOzbSM9RuwD/AEOKs3Nt589p Jv2/Z5TJjGd2UZce33s/hQBWg1aKe5WIQTqGlkgWRlAUum7IHOeik5xj8eKuyS+W8S+W7eY+3KjI X5Sct6DjH1IqnHpvl/Zv3ufIupbn7vXf5ny9e3mdfb3q5IkjPEUl2Kr5ddud42kY9uSDn2x3oAkq h4e/1+s/9f5/9FR1frL0ZpFXXmgTfKLxii5xubyY8ChAXV1ERQSTy75BJcNFBHGuWbHy4HrnazZP Y+lSw6gHliiltp7eSQsAJQvUAHGQSDkEkYz0PpTH03/QLSCKYxy2m1opcbsMFKkkd8gkH61FfwXf 9mMzSrPepIskLRxFVDZAAxknaeQST0JpiJP7WiN8lrHBPI7s6hlA2/IUDHJPQF8fVSPTMX25nksP JkkKS300EnmKuSFWbjjsGQY74Az3qe201bee0kWQn7PBJEcjly7ISxPrlD+dNi0vy/s377PkXc1z 9372/wAz5evbzOvt70AaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUANbqv1/pWVqhv1sXbTBA1yvIS YHa49MgjB9+n8xqt1X6/0qtSYzziDxt4guL5bKKwtWuWfZ5XluGBHUHLcY756V3gFwNLb7Y0TXHl neYgQmcdskn/AD26U9LK2jvpL1IEW5lQI8oHzEDoP8+g9BT7r/j1m/3G/lSAp+Hv+Rd0v/r0i/8A QBWjWd4e/wCRd0v/AK9Iv/QBWjQAq9G+n9ajh/1Mf+6P5VIvRvp/Wo4f9TH/ALo/lTAymkl/tQRi XEm/buxxjbuxitWb/Uyf7p/lWSba6/t8TeSfs4k3eZuXGPK29M56+1a03+pk/wB0/wAqiCtczgrX CX7g/wB5f5iqGo3cgf7LAG8xupHXnsP8e1X5fuD/AHl/mKpXbXYvYWitBIkbZ3hlyQRg9SPWiabV kaqSi7tFCRZ9GCThVMZwH28D6H+hrWhuEuobeePOyQ5GRg9DWNBYXUFtJCLQt5uzdymPlJPPPOeP 1rZgaV4YDPEIZNxygIOODjp7UoxUXZbA582+5YKhsZzgMG49jmmy/cH+8v8AMU+mS/cH+8v8xWgh rFjI4G8hVU4QDvn2PpTgHBALYz/eC5/n/SmSLKJGaIIdwA+ZiMYz7H1rLu0dbkm7tXnhaMhREC+1 ue236c4rllzqRbaUbmoH8xYH6bjn/wAdNSlQ2M5wGDcexzVLT0ljsrZJgwYM2AxyQvzbQfoMVero jsrkbjJfuD/eX+YrP1PUXs5EVUL7s/xYxgD2PrWhL9wf7y/zFZ2qWgkKyEMx3cbQxK5Az9057ela Rtf3hSvbQoNqTyIxJMW0jkuMEEN/s+1a9q26GM/9NZP5tWVb6dcOWeNECh/+WhdGbAOPvA8fMfxr WtYXghiSTbv8x2O05AyWPXA9aJNN6bCjfqW6KKKgoKKKKACiiigAooooAKKKKACiiigArO0P/jxl /wCvu5/9HvWjWdof/HjL/wBfdz/6PegDRrDsObOUbin76bDccfvG5rcrD08BraRWUFTNNnPIP7xq 2pfEJloAKSwX5m5OO9OpOcjgY9aBg+9dBJsHntR6Udjg1XaOaWHaX8t8/eWuMosetA6035gnHLe9 OGe9ACbQCSByaz7X/j71H/r5H/oqOtLtWba/8fWo/wDXyP8A0VHQwLVFFFSMKKKKACiiigAooooA KhsrZLNrlkZybmYzPkjAO0Lgceij9amooAk80+/6f4Ueaff9P8KjopgSeaff9P8ACjzT7/p/hUdF AEnmn3/T/CjzT7/p/hUdFAEnmn3/AE/wo80+/wCn+FR0UASeaff9P8KPNPv+n+FR0UASeaff9P8A CjzT7/p/hUdFAEnmn3/T/CjzT7/p/hUdFAEnmn3/AE/wo80+/wCn+FR0UASebyCQTj3rFNrrRJI1 W0HsLI8f+RK1qKAMn7Jrf/QWtf8AwCP/AMcpGstZdCraralWGCPsR/8Ajla9FICtp9r9i061tN+/ yIki3Yxu2gDOO3SrNFFAEc4mMDrbvHHKcbWkQuo57gEZ/Os5bXWVUAanZ4AwP9Cb/wCOVq0UwMv7 NrX/AEE7P/wCb/45SNa6yykHU7PBGD/oTf8AxytWigDMe31d1x9vsRyDkWT/APx2k+za1/0E7P8A 8Am/+OVqUUAZf2bWv+gnZ/8AgE3/AMcoFrrG4E6jZNg5ANk3/wAcrUooAzvJ1j/n+sP/AACf/wCO 017fV3XH2+xHIORZP/8AHa06KAMv7NrX/QTs/wDwCb/45R9m1r/oJ2f/AIBN/wDHK1KKAMsWusbg TqNk2DkA2Tf/AByn+TrH/P8AWH/gE/8A8drRooAzHt9Xdcfb7Ecg5Fk//wAdpPs2tf8AQTs//AJv /jlalFAGX9m1r/oJ2f8A4BN/8coFrrG4E6jZNg5ANk3/AMcrUooAzvJ1j/n+sP8AwCf/AOO0eTrH /P8AWH/gE/8A8drRopAZ3k6x/wA/1h/4BP8A/HaPJ1j/AJ/rD/wCf/47WjRQBneTrH/P9Yf+AT// AB2jydY/5/rD/wAAn/8AjtaNFAGd5Osf8/1h/wCAT/8Ax2jydY/5/rD/AMAn/wDjtaNFAGd5Osf8 /wBYf+AT/wDx2jydY/5/rD/wCf8A+O1o0UAZ3k6x/wA/1h/4BP8A/HaPJ1j/AJ/rD/wCf/47WjRQ BneTrH/P9Yf+AT//AB2ptNtXs7TypJVlkMkkjOqbQS7s5wMnH3sdat0UAFYmnf8AHu//AF3m/wDR jVt1iab/AMez/wDXeb/0Y1bUviEy1S5xTGdEZFJALZCj174p30P6V0EmxR29qOp4o7VxlBwKRjjm hiAOelGBj2oAAcgelZ9r/wAfWo/9fI/9FR1ojCjgVnWn/H1qP/XyP/RUdDAtUUVm29pBcSXTzKzM J2UfvGGBgHsfc0hmlRVT+zbT/nk3/f1/8aP7NtP+eTf9/X/xoAt0VU/s20/55N/39f8AxqnYQW11 Lfq0G0W9yYVxLJyAiNk/N1yx/SgDXoqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zy b/v6/wDjR/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/ AL+v/jR/Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6 /wDjR/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v /jR/Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDj R/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/ Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Zt p/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/ zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zy b/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/ AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zyb/v6 /wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/AL+v /jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zyb/v6/wDj QBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/AL+v/jQB borH1SG3soIXjgy0lxFD80r8BnCk/e64JrWSCO3jRIl2rjPUk/maAHViad/x7P8A9d5v/RjVt1ia d/x7P/13m/8ARjVrS+ITLPylhnBYcjPanc9qTcN2OM0hRCclFJ9SK6CTZ796CMg0DletHtXGUNVM LjOQPWndBxQScVl2V7dTajcQy2xSFPuOT97/ADxQBoyZMZAbax6Gs+xDLPqAY5YXAyf+2UdaXBHN Z9p/x9aj/wBfI/8ARUdDAtVUsOt3/wBfLf8AoK1bqpYdbv8A6+W/9BWkMpW8V3/bEsD6pdPFDFFL tZIvmLM4IOE6fIOmDyea2KrpbbNQmut+fNijj246bS5zn33/AKULFcDy91zu2yu7/ux86HdtT2xl ee+33oAsVlaL/r9Y/wCv9v8A0VFWjCkiIRLL5rb2IbbjALEgfgMDPfGaztF/1+sf9f7f+ioqQC6X eTSNIt0wYPPMsLYA4SRl2/UAA+/PpUdhqznTtPkuYZ2M0cIe4CqE3uFx3B5LDoMc1bisAlm8HmEs ZZJlcDBVmdnH5Zx7/jWWPDTKkAFzEzQLD5cklvuZGjC42ndwpK5IHPJ5pgXp9Zhgnmja3uWWCRYp JFQFQzBSo65OdwHA6/nUiapE0TM0UySrL5PksBvL7QwAwcfdIPXp1pJNN8z7T+9x591Fc/d6bPL+ Xr38vr7+1RXeixXYuPNZHMlwtwgkjDqpEapgg/eGAfTr7ZoAu2l0t0jkI8bo2x43xuQ4BwcEjoQe D3qxVPTbP7DbtFttVy5bFtB5K9B1GTzx1+lXKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQBk+If+PWz/wCv62/9GrWxJ/D/ALorH8Q/8etn/wBf1t/6NWtiT+H/AHRT AbWJpv8Ax7P/ANd5v/RjVt1iad/x7P8A9d5v/RjVrS+ITLQHufxpaa27Hy4zkdemKd+VdBJrUvfm jqM0ySEO6MWPynsa4yh/UUmMGlB9qB1oARkDDB6Vn2vF1qI/6eR/6JjrRrOtf+PvUf8Ar5H/AKKj oYFqsN7q9hN2LG3gl2zs8rTzeWFG1cdj6H0xitysNv8AUa5/ut/6CaS1dhvQY1/rqqWay00KBkk3 ZwP/AB2nrd+IHRWTT9PZWGQRdEgj/vmt8Qxz2SRyruRkGR/nofes6xWS3uru0d/MWNhKj9yHyTn3 yCc+/bpT5VYnm1KX2nxF/wBA2w/8Cm/+JqG0TW7SO5dLG0aa5uWmYG5IVRsRQAdvJyp9Mcda6Gs/ Wi39nhVd033ECExuVbDSoCMjkcEipKKn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1P5R0++s1h mneK4do3SWVpMYRmDAsSR93HXvVazWdVuLczXCar5Df61y0Tt2kQcgAHsMYzyOlADvtPiL/oG2H/ AIFN/wDE0fafEX/QNsP/AAKb/wCJqSwSOaK5txLfQyrtEqSzFnT3VjnhvUHHHGDU2mKVln8p5Xs8 L5RlkZyW53EFiSV+7j6HHFAFX7T4i/6Bth/4FN/8TR9p8Rf9A2w/8Cm/+JqII1zrF+kkOoyotwiC SG7MccY8uM42iRT1JPAPXvUVnKZZysMl4bw3su5neTyvLWYggbjtPycYXocdMUAWvtPiL/oG2H/g U3/xNH2nxF/0DbD/AMCm/wDiau6sk726eSJWRX3SpC+x3TB4U5GDnB6joRWVPIs82nLb/wBoXdu0 E7bYrgxvkPGPmJZc7ckYJzQBY+0+Iv8AoG2H/gU3/wATR9p8Rf8AQNsP/Apv/iaqzPDBqDRTf2kF FrEY41nlYqzPJncwYrnoMscccHAq7HHPdXEdneTyAwWsby+TIY/MkYsCcrg4Gw8D1oAZ9p8Rf9A2 w/8AApv/AImj7T4i/wCgbYf+BTf/ABNa8MfkxLHveTb/ABOcn8TXM2ZkHhO4vMX8Vx/Z5YTTXRcO xjzuUbzjkZ6A8/WgC/8AafEX/QNsP/Apv/iaPtPiL/oG2H/gU3/xNP1S0R9QsG826Tz7gpII7qRF IETnGAwA5UHim6kn2eaN55btLFI1RZIpWzE2Tln5ywxt5ORwc9c0AJ9p8Rf9A2w/8Cm/+Jo+0+Iv +gbYf+BTf/E1t0UAYn2nxF/0DbD/AMCm/wDiaPtPiL/oG2H/AIFN/wDE1t0UAYn2nxF/0DbD/wAC m/8AiaPtPiL/AKBth/4FN/8AE1t0UAYn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2nx F/0DbD/wKb/4mj7T4i/6Bth/4FN/8TW3RQBifafEX/QNsP8AwKb/AOJo+0+Iv+gbYf8AgU3/AMTW 3RQBifafEX/QNsP/AAKb/wCJo+0+Iv8AoG2H/gU3/wATW3RQBifafEX/AEDbD/wKb/4mj7T4i/6B th/4FN/8TW3RQBifafEX/QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAGJ9p8Rf9A2w/wDApv8A4mj7 T4i/6Bth/wCBTf8AxNbdFAGJ9p8Rf9A2w/8AApv/AImj7T4i/wCgbYf+BTf/ABNbdFAGJ9p8Rf8A QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAGJ9p8Rf9A2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2n xF/0DbD/AMCm/wDiaPtPiL/oG2H/AIFN/wDE1t0UAYn2nxF/0DbD/wACm/8AiaPtPiL/AKBth/4F N/8AE1t0UAYn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2nxF/0DbD/wKb/4mj7T4i/6 Bth/4FN/8TW3RQBifafEX/QNsP8AwKb/AOJo+0+Iv+gbYf8AgU3/AMTW3RQBifafEX/QNsP/AAKb /wCJo+0+Iv8AoG2H/gU3/wATW3RQBifafEX/AEDbD/wKb/4mj7T4i/6Bth/4FN/8TW3RQBifafEX /QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAHO3UeuXxt47ixtI4o7iKZmjuCzYRwxwCo9PWukfOEyC DtHB7U2pJvvj6UwI6xdN/wCPZ/8ArvN/6Matque0oTj7QXaMwGaTywAQw/eNnJ71rS+ITLgkVrlo 8SBkUHJBCnPv0J4qXmimNJGrYZlB9Ca6CTapGZVxkdfelx3prxrJtLgHByK4yhRg9KdwR1o+lIRx zQAVnWv/AB96j/18j/0VHWj2rOtf+PrUf+vkf+io6GBarFVRIusx70TfldznAGVPJ9q2qwJv9VrP 0b/0E1LdtSrXNxbsRQjcYgqLyxkwOO/SoIhvvZrrfGY5o4wu1s9N3P6irohjnskjlXcjIMj/AD0P vWRbJJbXl1aO/mBCJEfuQ+Sc++QT+PbpTqScYtomCvJJmnuX1H51XvbZb22MJleP50cPHjKlWDA8 gjqvcUVQ1rd/ZoCu6b7iBC0bFWw0qgjI5GQSOtcqrtu1jd0kkXYLLypRLNcTXMiAhWlCjbnrgKoH amRaasbs73NzK/ltEjOwzGp6gEAHsOTk8daoeUdPvrNYZp3iuHaN0llaTGEZgwLEkfdx171Ws1nV bi3M1wmq+Qf9a5aJ27SIOQAD2GMZ5HSq9t5C9maraSrQXCPdXLSThVeY7N+1SSFxt24+925yalSy lWNklv7qX5kYFtildrZx8qjg4wc9s1l2CRzRXNuJb6GVdolSWYs6e6sc8N6g444wam0xSss/lPK9 nhfKMsjOS3O4gsSSv3cfQ44pOv5B7MtPpr/aZ5odQurfz3DuiCMrkKFz8yE9FHftUo0+JbfyQ0gx M8yvkblZmZjjj1JH04OaxbdWn1298yO+dYrhQsiXJWJAIkbaUDjPJP8ACRz9am111T+z1ke5WJ7k q4tzIHYeVIQPk+Y8gHj0p+21tYPZmq9mxg8tbq5jYSNIJAwLDJJxyCCBkgAjgAelV20hVMDQXVzb vCsi702EvvYMxbcpGSVzxjvWTbiaW5WyaS6S0kMksZd2WUoojG0sfmHzMx9cAVK6XKm9sLaWV9iR SoWkJcKzMGQMec4Q4J6butHtvIPZmvDYLG8rzSyXLyxLFIZQvzKpc8gAD+Mj8PrTX00ERFLm4imi UoJlKlivocgg9O4z+tZHM2mj7G168ccx8+FpSJwAvKBic5ztPXkdDgipLOdXvtPFvPNJbvbTt+8Y 5JDxj5s9xkjnnrR7Z9g9n5mzFa+U0TGedzGjKd75DZIOT7jacegJqP8As6L+x/7M3SeR9n+z7sjd t27c9MZx7VU0R3l0PT5JGZ3e2jZmY5JJUZJNYdmZB4TuLzF/Fcf2eWE010XDsY87lG845GegPP1o VZ9g9mdbPbJNLbyOWBt5DIuO52svP4MfyqG9sBeEiSedImXZJEpG2Recg5GR36EVlapaI+oWDebd J59wUkEd1IikCJzjAYAcqDxTdRT7PNG88t2likaoskUrZibJyz85YY28nI4OeuaPbeQezOjoqtRU /WPIr2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5 lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9 Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZ oqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmpJvvj6VTX74+tXJvvj6Vr Tqc6ZnOPKR1g2Kl7SVQzJmaYBh1/1jVvViad/wAez/8AXeXp/wBdGrqpfEZstcggfw46k80HGen6 UAhhkEEZxTsV0EmqeFJ6mmpIGXoQKeAKMYNcZQdzR3qCW6WOQxgEuBnGOKkRcDOSc+tAEM92sFxF EysTIcAgZxVe1/4+tR/6+R/6KjrQK5xntVC1/wCPvUf+vkf+iY6GBZrE8ozDV03omcjc5wBlTyT6 Vt1ht/qNc/3W/wDQTU2voO9tTZW7EUI3GIKi8sZMDjv0qssTS3st0GjMc0aBdrZ6bufpyKviGOey SOVdyMgyP89D71nWKyW91d2jv5ixsJUfuQ+Sc++QTn37dKuUVKLRMW00yx5TeoqC8sBe2pgeV4vn Rw8eNylWDDqCOoFXao6u7x2cbRsyE3MC5U44MqAj8QSK51RijV1GJb6b5cqyzXU1zIoIVpQo25xn AUAf596ZFpCo7O91cyuYzGjOwzGpxkKQAew5OTwOasXcwiuLFCrEyzFAQ5XH7t2yR3+70PrntVS3 1WWW5jV7UJDJcS26yeZklk384x0IQ9+vbvT9lEOdg2iK8E6PeXLSThVeY7N+1TkLjbtxy3bnJ9ak j02RYykuo3UuWRgSEUrtYHA2qOD0Oe3pmodHv2neW3G6V4p5/Ndm+4vmuFA9eB06AD6CkGsXLOoS wBWS4ktoz5wBZkL8kY4XCHnr7HrR7KIc7LsFikEtxIrsTcSCRs9jtVePwWo/7MQtAzzSuYJnmUsc 8sGGPoA5AHsKZHfiYWLNEyvLcyQECQ4VkWQH/eGUPX1B6in2V7cXnlTLaKtnKNySGX58YyCVxwD9 SeelHsoh7RjrrT1ugh82SKSM5SSPG5fXrkH6EY6VHHpSpBKguZ/NlILz5G8kYx2x+GMe3JqjpOrS R6ZaG+jKr9g+0ecZN7OEVdxYY4J3Ajk574qO511LrTtRjhkhEq2Us0bW9yJCuF/ix91gSPX68Uey iHOzRXSQkDIl5cpK8nmPONu9mwByMbegxjGOBTrfSYbeWGRHfdEkic87t7KzE++Vz+J/DQoo9lEO dlC10xLWO1jjml2W0PkqpPDD5eSO5G3r7n1pv9kw/wBj/wBmeZJ5H2f7Pu43bdu3PpnHtWjRR7KI c7Kk1ik8tvI7sDBJ5i47kqV5/Bj+QqK80tbwkSXM6RMuySJCNsi9wcjPc9CK0KKPZRDnkReV/tfp R5X+1+lS0UvYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv 9r9Kloo9jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8A a/SpaKPYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv9r9K loo9jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8Aa/Sp aKPYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv9r9Kloo9 jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8Aa/SpaKPY wD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIjWPBB3dKsTffH0qOpJvvj6 VcYKOxMpN7kdYemgi2kPJzPNgf8AbRq3KxNO/wCPZ/8ArvN/6Mauil8RLLY6Aml/GmbVMgYgFgCA ccgd/wCQp2K6CTXPAzQOmTQDTW6cVxlC4U84p2KjjUomGYsfWn0AFZ1r/wAfeo/9fI/9FR1on0rO tf8Aj71H/r5H/oqOhgWqxkTzF1mPcqbsruY4Ayp5J9K2aw2/1Guf7rf+gmktwexsrdiKEbjEFReW MmBx36VDEhe9mugUMc0cYXa2em7n6cirghjnskjlXcjIMj/PQ+9Z1islvdXdo7+YsbCVH7kPknPv kE59+3Sr6Mnqi9Ve+tVvbYwtI8Xzo4ePG5SrBgeQR1A7VYqrqEwgt0cqzAzRJhXK/ekVc5H16d+n esyyNNPYSwyT3tzcmGTzE8wRjB2sv8Kjsx/Ifi5NOhTyMM/7m4kuFyRyz78g8dP3h/SojqExmvlS 2Ty7Rgm9pgu4lUb04ADHJ9uM54gi1sSaZdXSxxSG3kEbeTNvjPCnIcDoA3Jxxg0wLcWmwxMjRs6y LI8gcEZO9yzKeOVyen0780qadCnkYZ/3NxJcLkjln35B46fvD+lS2kzT2scr+Vlxn9zJ5iY7YbAz x7ViWUtwIJb29Ri7XggUR3khX/j42fdwAAMDt8wznGSKANZNOhTyMM/7m4kuFyRyz78g8dP3h/Sk ttPW1kXy7i48lc7ICw2L9OM49icCoItQvPN1My2sTQ2bEJ5UhMj4RWA2kYyQ3r14weps6bdte2on YQYY/L5MpkGPclRg9eMUAMi0q3jitozvdLe2a1CsQQyHbnPHX5B+Zpp0svbT20t7dSwTRNDscodo IxkHbnOPUmtCigAooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVJN98fSo6 km++PpTAjrE04f6M/wD13m/9GNW3WHp5ItZCBuImm4/7aNWtL4hMuUY96aXUNt3Dd1xnmkjEgT5y pbJ+6OMZ4/Sugk2RkDk5pCSvbP0p2aM4rjKGjdu6DFPNJnB60GgBT0rNtf8Aj71H/r5H/oqOtIkD k1m2pzdaif8Ap5H/AKKjoYFqsZE8xdZj3Km7K7mOAMqeSfStmsNv9Rrn+63/AKCaS3B7Gyt2IoRu MQVF5YyYHHfpUMSF72a6BQxzRxhdrZ6bufpyKuCGOeySOVdyMgyP89D71nWKyW91d2jv5ixsJUfu Q+Sc++QTn37dKvoyeqL1Q3Vul1EschYASJJ8vqrBh+oFTVV1CYQW6OVZgZokwrlfvSKucj69O/Tv WZYybTIZortGaQC5kWViCPlZQoGOP9gHnPemxacYUuPLvbkSXDK7SfIWDAAZGVxyAB0xxximnUJj NfKlsnl2jBN7TBdxKo3pwAGOT7cZzxBFrYk0y6uljikNvII28mbfGeFOQ4HQBuTjjBpgXbewS3hg jjklCwu0n3seYW3Z3YHIyxOOOQPSk/s6H7L9n3Ps+0faM5Gd3m+Zjp03fp+dNOL3TkkuJhCh+dmt rg7SvP8AGADjGDxil0xZFhl3mQwmT9x5pJfZgdSeeu4884IoAcLLZc3M0VxNGbgfMq7SA2AocZB5 wB7e1OsrNbNJAJHleV/Md3xlmwBngAdAOgrGspbgQS3t6jF2vBAojvJCv/Hxs+7gAAYHb5hnOMkV ei1C883UzLaxNDZsQnlSEyPhFYDaRjJDevXjB6kA1KKqabdte2onYQYY/L5MpkGPclRg9eMVbpAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFSTffH0qOpJvvj6UwI6xNN/49 n/67zf8Aoxq26xNO/wCPZ/8ArvN/6MataXxCZb7UUfXrSEHP3iPpXQSWhcSjps/75P8AjS/aZv8A Y/75P+NFFcRRXlWaSeOQTsmz+FR8rfXNTtPM2PmVcHPC/wD16KKAAzynOdnP+yf8ag04lpb8nGft I6f9co6KKBl6seKJrj+2IUIDSZQE9MlSKKKFuJ7GzHK6RquxTtAGd3/1qrpE/wBvnuG2hZERQAck Fd2f5iiirezJW5PUN1bpdRLHIWAEiSfL6qwYfqBRRWZZBNpkM0V2jNIBcyLKxBHysoUDHH+wDznv TYtOMKXHl3tyJLhldpPkLBgAMjK45AA6Y44xRRQAjaUn2KK2iuJ4RHJ5u9dpLMSScgqR1OenUDHS porR0EfmXlzMY5C+W2ru+UrtIVQCOc/UCiigBv8AZ0P2X7PufZ9o+0ZyM7vN8zHTpu/T86UWWy5u ZoriaM3A+ZV2kBsBQ4yDzgD29qKKAHWVmtmkgEjyvK/mO74yzYAzwAOgHQVZoooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKkm++PpRRTAjrnrGwhnhkkczZM82dtxKo/1j dlYD9KKKcZyi7xdgZYGlwf3rj/wKn/8Ai6X+y7f1uP8AwLn/APi6KK09vV/mf3isj//ZCmVuZHN0 cmVhbQplbmRvYmoKNTIgMCBvYmoKPDwvU3VidHlwZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VS R0IKL1dpZHRoIDU2MQovSGVpZ2h0IDMzMwovQml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRmxh dGVEZWNvZGUKL0RlY29kZVBhcm1zPDwvUHJlZGljdG9yIDE1Ci9Db2x1bW5zIDU2MQovQ29sb3Jz IDM+Pi9MZW5ndGggMTI3ODM+PnN0cmVhbQp4nO3dCWAMZ+PH8ZndRCIXIRJHFImzr6KEKqWukMN9 VlVdEddL6aEHWq06ql5taSmCKkrrVupsHS3VHKV60BKibhI5JZFkd99nd2JtZnZmZ2dndjbJ7/P/ d7s7meMZbzpfs8csbTAYKAAAABdAo0kAAOAi0CQAAHAVvE0aFdXSyUMBACir1n73q9pDKB2sNGly v9Y5D3TzXh3tXdGD1rqrMiwAgLLBoCu8n/fgrUVrfDy0S3ckqD0cV8duEjk9emfysMq+Xvr8LF1e pj4/U62RAQCUAbSbB+3mqa1YKeNm8pxNiQ3a4IRJSIkmkSD9740xuvxMfV4GCZKKwwIAcBEr9551 cA2x0c3IrZtv0I2rlz/Z/SeyJKBEk4Z0a/HZzNGF91IQJAAAYtW+P7r3HvTk46GS13D6r+SDu7eM jWxK7ucVFM3c+FvzZ87IN8Cy5lGTurRpsnl+rC4voyAtRdUhAQC4irj9f02f/lpeys+S11Cx7tML F34YE/E4ZWqSXk/9d/Wv3aLOyTfGMqVEkzbNHZN/65y+MF/dMQEAuIjVB8+/+srL95N/krwG79Bn Fv1v8ZjujZmHuQ+KJq89iybxedSkVv8J3bM49v6/7Cc6lx7N1HhUtLkiX13asHbVtRpa/jFC+UD7 tvJv3d/vsfpu7hRVmJr/7w/pCbvvZxeqPS4o19Yc+uflaVOz/zlqOfGPlLTfU9LInaGdGponbjr6 D7l9om7VpnWrWs7s27DT4o8+Hh1ePCdp0qjlZwYMSlZ65KVUiSbt/jAm50oia46pR/xv5lawuSL/ 9PiPBwd7VtDKP0YoB2i/8FqDx3tTv51YOHP54VuGpsNf+3BKC0P8rxs+9C7Sqz06KL/Wfn9h2ktT Ms9/bznx6+PJs9bHkztzhrcZ0jHU6hSzSo27fvTJklFdGzAPSZNiVv2BJvEp0aSdH4zKSWG/ff6E Z68e3bvTGiPa+K+Hd0v+e/4b4wfUS0eTQBIfn8i42qEVLrzfdcLeew2CPWtW1Hq0/vSVya0eHJmy 5seUrtXb1ol9y4u6lHryglezLl4+7lR+StavK2+d/lPH/P5q/L1bjg1s3tazopZ68G/2mdW3ks4Y W1bhqYcLJns371LRW2vI/i3tyP/u/ot38YAoX/yQ/NLkSel/HrScuOVEyuxNp5n7s4c+aby1eDio fV3Lmf3/0/2TpZ+N7FIcKtKk2DXn0SQ+JZq0ff6L2ZfjWXP84tNfTJPmTY/tWycVTQIp3P9Ta/RC f8/zS/oMPEZ5tfCv0DjEu3aVqND/vlQtc/vLwz5o1y06curb3hR1/8TCnTv3nrhYvcmrcZPbe1/b PubGv3e86AqeT31cv22dB7/MnDX7SP6A1UtiGt/cFXPl8k0fz7b1xs8iC6Z998bOg6f+rvL6rLcj fdM2rft4XcsALZ5oBpu+PHp58sTxqWf3saZvP3V1zpY/WBNnDWrav21t1sSAZpFLl33+Yqd6zMPc B7oJ6y6gSXxKNGnb+8OyLv3CmiOh0uCIyIji9JhLZBko0525r43tHXzL0x1NAvt5PFVv4nu+msTZ 3UbcqubbItSvnT9NeXaoN2mmr+7EjIiJhc16z/rfHF/q8prBfTanurWr4+ERMHz0hxODUje+8cqK vi1bNhj7cVWvlDWDe2/JcA9r2Df201m10za9MXV57zZdmk2e7UOdX9p34N4cj2caRwz/dG4dw6mZ EROqP1WtYyVUCWxYf+zKpAlj75zew/3RzoQb83b8bX74Vr9GfVvX5M4W+GTPz5avGv5sHeYhadKk jZfRJD4lmvTVrAEZF06w5vij5ujIyMiHMSquEm36P8sp7708qkdAiqe7xum7AKWfe/OQKcuqeZHz pCEXfbw6hmpqu1N05QH/mfyyd+b2l3q/QzeJevvzD6pQie92G3G1qm+ov6ZlnS6t3nw/QP/zjIjx FVr2mDp/IbsvJDw9xmlbRr6yYIEfFf9219F3An1Caj0bs4isJ35WlzHZtX2iQjSV8AsLgjadvDF2 3Pir8bu4P9p35vYn3z1Ky0tRoZEtgriz1W7TZ9WKz4e2K85VXoHule130SQ+JZq06W3SpJOsOX6v MSoqMorWFkeIE6fi86T3po3qUQ1NAmn8Kvff1vDxCmfeDV95Pi+qiTZQo6nQbEnz3i3yj0x4bsbJ Bk9EvLnig6rG86T+Z9w924VqQ2uMaDphbMXUryb1n+/eqO2rH60K9vn7074Dtt/QWazWrVnLqHc+ /8DfFKGsGj4dmnbq/uZ8P+ZhTZ/uDbTVcGIPgr46QZo07lr8Ttb0787csQwSg2QpqkUga2Jwm76r Vqx4vv2jJr287Q6axKdEkza/M8hak0ZGRUU9SpGGFafif5vOk66gSSANXalPwNhX6upOfbVggVeF /JCQgXUHxvgZfv74+XHfZVRo16jrlGXk/Ia6f2L+J+sONG/UsGnvxXUaeF9a1mvChqvNQyv1HBHX oVvDjIOzPt1y1E1TpVqTzk92Cvl7+bxL9LMTPicxexihZp07Tp/na37Y0D0QTQJBX524PjY29lpC iSZ9d/rOxw+DNDXK+OYFy4dRT5bIUnDrvqtWrny+fS3mYS5p0tZbaBKfkk2aPTjzIqdJ1Us2qfiF pUdP3jHnS+9OGxkR+C+aBBIZ6PTcVhmdR3Zq/0Q1T4oqvJv1544v31+245quUV3v2sGdJy0i5zfn vlz6Z9jzfR+v6kblXbq4Zc705af0VXxbBrm3C62cExRTPzqiaY2KpFz5V45fOrDq672XG7eP6jl9 7sMI+fZo3rnDaxYPG6NJYMPGn67Fjo29XrJJe0/f+cgUoWlRodGmAnGnmNVq3XflqpXDnglmHpIm TfvmJprEp0STvnl3SOZF9iU0zgaNiIqO4r6SVHzn4eN3p42KDLyC9ziAZPrCotMX8uKv51+7r3ug pyittoqPe+2AClU8tE2bdO72OtOS0Te8tPcyCjILyAyaoKpeDatoqwZ6tAvQ5KXnHzif+1dqQYbx U7Z0FX+PelUr1K/sXq9a4Rf7sm5Rbk809I1o4hFUlLtor8VD/MKCoA0/XY0dO5bVpH9u3r9w6z65 Y5kfkiVy26C6d8Ma3pYzm5q06oVnit+PR5r00tfX0SQ+JZq05b3nMpPZTfo8wVAlwPjCHWnSw1vm LmU5Me3KX8Pb+HrgPAkcoC/U/3un4HKWIV9nMH1QlvbxdWtcwz3It32Dl+b4FJ/feId4UrmFlPGT SRpNYIB7s2paD/JraDBkZhadv1OUXmhgPrTk4amtG1ihnrf+j+SCmwUGHaUJa+IZROt+u2jxEE0C QRt+vBobE3Mjkf16kng1w/qujIt7ocOjJk3ZdA1N4lOySXOGZiWfYs1RUKTX6W1/Pzppk4eblsZ7 a0EJHu3qT3nvYZP8oppWREvAOdYf/3dczBgHm7QibvXwjo8xD0mTJn/1L5rEh/X5pOezktmfTwJw CQ9yFuxKNz3n5hf9hHd1NAmcYv3xK+0692gaWkvyGv5Ivn7yyIHhHS0+n/RVCprEp2ST5g7L5nxm FsAl6At/PZ93w/icm9tTaBI40YoDf9ueSdC4Ho3M90mTJm7AZ2Z5lby20LzhaBIAgHKM1xZan4wm 8bF9HQcAAJDRxM34fBKvEk3q16qauqMBACjzdiTh2kK8HjWpY/unj5/4OSP1FvPQoPVQb1QAAGUK rXvA3Ll9LWXspGkR4dK/TL1sQ5MAABSHJomEJgEAKI7VpDotl6o7HpeFJgEAKI7VpHnT16o7HpeF JgEAKA5NEglNAgBQHJokEpoEAKA4NEkkNAkAQHFokkhoEgCA4tAkkdAkAADFoUkilccmLYrbovYQ AIxejRkk8FN/f3+njQQcl56eLvBTNEmkctqkjuE91R4FlBHHD+2JHTlMwoIrv9go3KRKlSqR28zM TIkjUw8zcj7K7ZG62xVeP5okUvltUps6FdUeCJR68VfySJMmjnlBwrLLVm8QbpKfnx+5zcrKYh6e PXtWwla4mjVrxpoi+5qZkfNRbo/U3a55/VahSSKhSQDSMU2aMna4hGWXrFov3CRfX19ym52dzTwk R1JuTuxldSWyr5kZOR/l9kjd7ZrXbxWaJBKaBCAd06SXx4+QsOziz9cJN8nHx4fc5uTkMA9LUZOY kfNRbo/U3a55/VahSSKhSQDSMU16beJICct+uOwL4SZ5eXmR29zcXOZhKWoSM3I+yu2Ruts1r98q NEkkNAlAOqZJb04eJWHZ+UvXCjepYkXjr2heXh7zUK0m6XWFRbmZ5Fjh5uWn0bqLWTMzcj7K7ZGM 201NTc3IyCgoKCgqKio0IferVKnStGlTvu2a128VmiQSmgQgHdOkWS+NkbDsnE9WCzfJ09OT3Obn 5zMPbR5J16Z8Ruk1o0ImCMxjb5NIkJKWDNE9yNG40R4+lZ8Yu4EvS5YrYUbOR/weiSH7dvV6/d27 d93d3T08vB4UFpLHxkOkweDvX/nAgX2RkZF82zWv3yo0SSQ0CUA6pknvvhwjYdl3FscJN8nDw/jf 4IMHxccy4SPpykufUHqDTq8rKtBNbjqdbza7mkSClPhRXy//Sn61Qmit2/07V/PvZzYbs8lqlixX woycj8g9Ekne7ZJznTt37lSuXNnb2/tyynVykkSSRP6P/NkGVa928sTxvn378m3XvH6r0CSR0CQA 6ZgmzX0tVsKyMz5cKdykChUqkNuCggLmId+RVGcoWpH8sZbS1PUJIX/HP596Lvd+/utPveOmcePO LL5JJEi/LulfsXLlSrUbkAMFpdHS2gqZty7mZt5rOWYjN0uWK2FGzodvj9J/G+/u5k3TmocTDIUF WX6Pf0BrLNZGU5TGk6a1cm339u3bJDw6na7IpLCw0PxkHfN8Hbm9dy+d/MGGd488fuz7wYMH823X vH6r0CSR0CQA6RQ9T3JzM0aFHCKZh3xN2pCyKiUr2b9C1bp+9cjf6K9nXP/r6rkQv9Cp7V7nziyy SSRIpz/tX9G/SqVaDbNvX85Jv23Q0BUr1/QNapR2/XzOvbRn/ss+W7JcCTNyPnx7lPZz79DIYzRN U6YnyyiaLspPvfPb+wYyxUTj7kuO/7TPEx4Bz8q13evXrwcHP5aRkWnapPFwaDAh/9JTVBX/St/u 3lW3XiOdXl+zRtDhQ/uGDx/Ot13z+q1Ck0SS3qTw8HBye+jQIUc2L2YlsmzIktUmka3IuC+yjxlc k6KvJ2m1xrMB8ld45qHwM12vn5zc7rH25ND5y8VfxrWYHFKlvtXZxDSJBOm3zwZW9K/qG9ww+9al 3Jy0GtGfkOmXd7zk4RXgUz3k7uW/M+6mRc3YqnFzt7oSZuR8+PYo7UT/0Mh9BbeW6wrIWZ8fTft6 1uxKQkQZj1F6ytgIA63xuXR4mH/rFXJtNyUlxd8/4PW4X8nBkLSv+B+T7KyshbGtjx09fP/+fbJs VHSffd/tHjNmDN92zeu3Ck0SqRQ0SXYKNYm1NgpNKgcevu9utIRl5y9dI9wkjcb4LJZer2ceCjdp 2pHx7UM66A26/Yn71wz8im82m00yBmnFoIqVAnxrNcq8fTE3I61KtwX1QkLJYNJS78SvivH0qlyp 5mPXL1y8dzNz2OJd2odZslwJM3I+fHuUdqRfSK/d+dfWG1/AeXCv8P5tHa1x96xBGQopfYHBQM5C inwbv55ycGDVDrusDl7Cdi9evBhQLejN1Wf8q1Qli9OaYuRO8j9/fxATdujQd40fb0GGVKtm0K5d 2yZOnMi3XfP6rWI1qU7LpQIzl2fyN4mZzrD8qdXprJVYDYPV8w/hrQvHgNsk7nYtR8sdM3cwrCGh SeUE9/NJ3Z5tJzD/4WMnzfdtfj6JNj1nZf4vVLhJk/aPfqZhR9KkfT/v2/DCVr7ZbDbp/NdTKf19 35qNMm8l52akBkYsfKxOPfrhs2epd+8cXjjC08enSnD1q+dTDNrAYfPjuCsxz28V3x6lHYmuG7kj 59JWQ0FOYfZd38aDPas2Mb2CxJwnGYznSW6VL2zvEND5W6uDl7Ddc+fOBdUInrn2bNWAAHOTmNt/ zv01f0xLcm5Uo0O13Vd2znh8/rYtm6ZOncq3XfP6rWI1afOJXQIzl2cyN4nvuCzyvtWDOHd+ij9L sjSJW0qKv0k29wvKMKvXcejRub3VmQ8cOWH50OZ1HJj/Ns3HWeEmjd35QsemnXQG3d5je7fE7Oab zWaTsv5NurB3tod/cOadW0+8uNq3kj/r5CMnK2PNxN7kPOrOlbQBsxbXe/Jp7kpsHJ159ijtYK/6 Q34kp0RMgQzkxKPgelHGYYMu01BE/j/LoMvxDJ5xafeYgIg9VgcvYbvkfnBwnVnr/6wWGPQoSGRW jeb8H7/PG91i185tP9Tedz+7aEWHtZs3fTl9+nS+7QoXEU0SyVWaJPDUmZj12MXeJvGNUyBdaFI5 8fB6dy+ypkd3e4Y1Ze/hn1hTlqz6UrhJzHNB5iQIN+nFTUM6tTQ2ac/hPbv+u59vNjGvJ2VcSbry y+azeY+PHTfhwYMHc+fOZY7SxOuvv+7u7r5i+TL978e6jJhoDhJrJcLPYvHtUdreXqFDD+lzzxoj pMs2FGXoC9PJfaoo44cL6cdSdJl5eYVF+a3c7j0/8oBc201MTKxXr/47G88FVq9RL9CLKu4KfSOz 6K+zv70/qgU5N2rdpoPeQD1Wu8aG9WtnzJjBt13hZw7RJJFcokkMtZrE98QdmgQ2CVwXvE/3jub7 uw4e585g87rgzGvm5tfthZv03Np+ndt20et1u/Z9u//V7/lmE/9e8HXr1o0ePZocbRcsWBASEkKG kZKS8sorr5Amvffee+RHgYGBfCsRfrWfb4/SdvQOGf6dLvuY8azIeG6UYbqTfuB8+u/5vq2ahAVX aXDkz52n/vixZVDPsRGvybLdkydPNmnSdOpnP1tdZP6YVhvWr3m6XRe9wVDnsVpr16x49913+bYr /A4LNEkkl2iSwOtDItdjFzQJ5MI0ie/7kwZEGt+yvG3fMas/tfn9Scx7i83vbxZuUr/l0V07dNMb dDt37fph5o98s4lvUlxcXGxsLDk+LFq0KDQ0lGnSlClTSJNmzZpFfhQUFMS3EuF3RfPtUermnvVj 9ham7zbVKKP4KTtd5pTdGX2ielJaTe8mk//3fayW0mz7dv/ud07Lst2jR4+GhbXJzs7W6fWFhUW5 uQ8MBn2FCu4a2nhk9PXxWb06rn3HcHIqVKdO8KqVn82bN49vu8LvREeTRHKVJvGt0N75JbyeJKZJ VieiScA0acyLz0tYdvWXXwk3ifkMpvlzoMJNiv4oPLxrd9KkHVt3/jjnFN9sNpt0O+/G9exrxy8d /ef8Pz1b9e3ZvPfixYsbNmyo0WguX748adKk/Td2Hfx7v2+R3xPVnqzpHdw2tB13JcKfHuXbo7Sv hzw29PPCtARKn2sw5FP6fMqQb9A9eH7T7olDJ0X+p/hN2N/+vmzuivf3zflTlu2eP38+NTWV+ahs Tk4OTdPkzt27d8mBUaPVkqNjzZq1mjV7ksxZPajaO+/MXLhwId92hT+xiyaJ5GiTLAk/HSfyfXeU pM5ZnZmPzSZZHS2aBFxMk0YMe07Csus2bhZuEnOtGvP1coSbFD7/2R4RPfSUfvvmnac+SOSbzWaT 5vzylkGn9/X2ybifcT+5aM7A+atXr27UqBE5T0pOTh46dGjcP5/6+/ll5mVcunrl79+S9715mLsS 4avs8O1R7tlvilLPF1xL0heWuMB27L+3e/XqXkTp3whfu+DgKE+tB995krTtMs6dO0dOBINr1/H1 rbxr5xaS4du3b9+4ccN8cQeiatWqb7zxBt92ha9shCaJVN6v4yD+Y0nIDHAxTXph6BAJy27Y9LVw k5hrepqvKyrcpGdntysq1BUVFumKdImLz/DNZrNJi39ekHLzcoUiz5uXb/nrqtatEOLr61v8kR2a vnDhQl61nAyvtCqVApKvJ9f0CV4+fgV3JcJXIxW5R2brDi/56d/N7Zo906D6kxdunT559qc2NftZ fT1J8nbJglu3bu3cuauPr29Rkc5Nq1m27NM333xTYG3c7QpfARZNEglNEtUkBAmsYpo0dMhgCctu +vob4SYx331g/v4Ftb6rQsKahb+1QcIerTm4eE/85rwH9yt6ePds89zo7i/Lu11yGCRNun79OnOZ O3JKFBgYOH78eIG1cbcr/E0Z+Mws1wdLH+NOLO9NAnAE06TBg4TSwuebLVuEm3T//n1y6+3tzTws RU1iRs5HuT1Sd7vm9VvFahI52Do4gNJu+ORENKkYmgRyYZo0YMBACctu27ZVuEnMd2mbv8+7FDVJ +FvAldsjdbcr/M3raBILmvQImgRyYZrUt98ACcvu3LFNuEnZ2dnk1tfXl3lYiprEjJyPcnuk7nbN 67dKoEkHztxwcDClS48WNSk0yRKaBHJhmtSrTz8Jy367a4dwk7Kyssitn58f85AcBCVshctqk+Rd MzNyPsrtkbrbNa/fKuEmkd8iWYbk+sixF01iQ5NALkyTonr1lbDsd9/uFG5SZqbxS30qVaokcXDq YUbOR7k9Une7wuu32SRyUFJoeK6D2U00iQ1NArkwTeoR3UfCsgf27hJuUnp6utRxgQr8/f0Ffiqm Sa3rV1V2iKpKuJiGJlnHNEntUUAZQf4z6xbZW8KCh/ftFm4SlCVimtS+cTWVRucMJ87fRZOsI01S ewgARsJNunTpktNGAo4LCQkR+KmYJnVuGsSzdFlw5I/baBIAgEsQ0yTmYC1SWFiY5cPERN4LSrkI 1m6iSQAAqhF3nlRd/ArbtW1Dbk+eimfdd1lH/riFJgEAuARxrycF8ixtRadn2pLboz+d4rtP7lhO YXDnt/qQb0HLieYpIp04fwdNAgBwCWKa1KZ+gPgVhncyfkvIoaMnmfvMHfN0yx9x71tOZM1jXhtr ImtOqz8VFn8xFU0CAHAJYprUom4V8SuM7vaM+f7ewz+xppunWD60et+8HvN0yxn4Vs7aihhnUu6h SQAALkFMkx4Prix+hf0iOpLbHfuPM/eZO6zp3Nm495llWQ8tl+Wuzcw8XYy/rmWgSQAALkFMkxrU ELo6Ecvg6E7k9pu9RwXui5mN3GFuLR+ytsK3crtcuJmFJgEAuAQxTapbTejK4izD+nQhtxt3/SBw X/yPuA9tbsheKXdz0CQAAJcgpkm1qniJX+HI/t0sH36x/bDldPND1pzc6XwLCi/FnW7T9Xu5aBIA gEsQ06SgSkLfnl7a3c7MR5MAAFyCmCZV8SnLR917OQ/QJAAAl4DvqqDwXRUAAC4C3+nHQJMAANSH 7z43Q5MAAFQm0KTyCU0CAFANmsSCJgEAqAZNYkGTAABUw2pS1+4R6o5HdRdTo9EkAAB14DyJBedJ AACqQZNYZG7Sorgtsg8RAKCUmvtabHp6usAMaBKL/E0i/xvIPkqzGR+uVHT9AACyIAcrCk2ynyJN Ev7fwBFKrx8AQBbMk0Zokr3QJAAA+aFJ0ijVpPDwcO5PDx065OBw0SQQg/z6sX7ZuFMAFIUmSaP4 eZK8xwI0CcRg/kpk+YuHJoGToUnSOLtJVv8CS5kOH+ZTK9b8lhPRJBCD+TWz/GVj3WfusH5qWTKr VWMtBSAATZLGVZpEcQ4QFOc4Qu6jSSCGQJP4JlLWaiS8FIAANEkaFZ674/7nzdctNAmk4f4KWQ2J zeSgSSAZmiSNqzfJckE0CUQS/h2z/L0S3yTL9aNJYBOaJI0673FgHSbEnCfxrR+AS6BJdp0GCZ9m AQhAk6RxlSZRtl5P4ls/ABf3bzmU4CkRmgSyQ5OkUe294Fb/Jss8tPpmJwrP3YFoNp8xtvyR8Dv0 BJ7xAxCAJkmj2nUcpL1ojCYBQKmAJkmjTpNsvkHcwfUDAKgLTZJG/ia9GjNI0W+sUHr9AAByQZPs Vcq+qwIAoLRgvlsHTbILmgQAoAhSI39/fzTJLio0acycoxrj+mkDXUDT7gaDbvWsLpIGDwDgunCe JIGzmxTz3g80bQwSyZKOJpvQ0wZN3NudJA4fAMBVoUkSKNWkVmFtKEMhOQ0yTdaTCFEa8k/RS3Pj tHqNQUPr9UVaSqujdEtmTEpIird33GFhYYmJifYuBQDgNGiSBIo0iQQpKSGeosncOgNFzohomlnW QLVuHWY6STLeGOgiMtFd734q6RdZdwoAQH1okgTKNKnVk0lJpzNzC9krpSifiu4ashLjc3Z6rZ4m p06tnwpLjE+yd9zm8yTmDrkl981TzPfNMzN3rE60nC48J87MAEA8NEkCRZoUFtYmMeFnitaKGUGr Vq2SkhxqEmWtRqxocZeSMBEAQDw0SQKlmpSQ8EtWXtGj1T28Y7DchvHJPKprx7aJib/aO27hkFA8 LUGTAMBp0CQJFGpSWEJiYvLNbON6KMsbY5Po4lva9AITPbhPx9PxyjaJ+zQdX34sN8FaHGUCALug SRIo2KSTf6fSvDMWv+mB/DNlWISEw734Jsl1SoQTJgCwC5okgWKvJyXG7zt9U8wI3o7plZCkWpOs vgQlvEUAADHQJAmUa9KpfadvixnB22OjExR+Pcnqk3LmGtl8ls/yIQCASGiSBAo1qWVCQtL+M7fE jGDm2D5JiXZ/ZlZGOAECACWgSRIo9ZlZWq+jNDRN6fXGKzjQtIFvCT2ZJyHxjAO7IIXVDycBAMgI TZIA1wUHAFAEmiQBmgQAoAg0SQIFmxQ2buXc8VF6WmO6ELjBjdbo9QY9Rc36/Fvy08QVSBcAlGVo kgTKNun9ib16NK9BG3QUrTV+PpY2TpwzISqyeXDY+JXIEgCUYWiSBIo3KaJ5kHEpSmOapqcMhtbj V5Pzpxmff4cmAUAZhiZJ4IQm1TBdSYjUSGO8wp3pR63HrZw3Ifqt5XslZ0neN3Bb/awSAIAj0CQJ lG3SvAm9ureoYcyRgdZTlKb4UnfGu+SnlGu8qiR8tVYAAGnQJAmUfo9Dz+4tapIIGb9l1mDQ07Sm +FJ3er1B02a89CzZ/P4kStx3ILGmW66NsvW9SgAAAtAkCRRu0sQ+PZpXo0yvJ9EGSk8bjN8wazxf 0pPbA2duzVy+2/EmUSXj4cjFVW1esggAQCQ0SQKFX0+a0DuCNMl4GQdjkwy0+YUlvcFAH/rt1lvL v5XlPEnyPBSaBADKQJMkcMbrScYTJNP77orI0qan7gz6IlqjOfDbzZnLJL7NQaA3Al9qbjUtYk6t 8BVKAGAvNEkC5zSJeniS9Og9DmT1B8/cmPH5HnmbJHx+Y/PtDMKnVjhhAgDx0CQJlG3SnAk9I1vU ZL0XXEcZ3Ciyevrg77dnfCbD60loEgC4IDRJAmd8Zta4KlprmqY3nSqZPj9L6/f/dnvmMvlfT+J+ W5LV99GJv4833QGABGiSBIqfJ/VoXlNjerKueA6DzkBpadMJ06HT197C1RwAoIxCkyRQ+vWkaB1F M9dgNb27wVgnA025kTLpNXoNLfm94AAALg5NkgDfVQEAoAg0SQI0CQBAEWiSBGgSAIAi0CQJVGjS mDlHNcb10wa6gKbdDQbd6lldJA0eAMB1oUkSOLtJMe/9YHrLA02ypKMNlOkaeHFvd5I4fAAAV4Um SaBUk1qFtaEMheQ0yDTZeHU7SkP+KXppbpxWrzFoaL2+SEtpdZRuyYxJCUnxsu6UHfg+BouPxwKA g9AkCRRpEglSUkK88b3fxk8jaYzvBmeWNVCtW4eZTpKMNwa6iEx017ufSvpF1p16xGZa0CQAUAia JIEyTWr1ZFLS6czcQvZKKcqnorvGdNE7Pa3X6mly6tT6qbDE+CS7Bs130SDulyFZPuSbIuZCD6yf 8k0EADBDkyRQpElhYW0SE35+eD0hG1q1apWUZF+TKGsXAbLrKydsfv2S8BpwFgUANqFJEijVpISE X7Lyih6t7uEdg+U2jE/mUV07tk1M/NXecUtoktXF+S7hiiYBgIPQJAkUalJYQmJi8s1s05dUWN6Y vqqi+JY2vcBED+7T8XS83U2iOCkS/zVIDPFNstyomC9kAgCg0CRJFGzSyb9Tad4Zi9/0QP6ZMixC 2pHd3iaJjJbAeRLfGCQMHgDKPDRJAsVeT0qM33f6ppgRvB3TKyFJzSZRol9P4huDhMEDQJmHJkmg XJNO7Tt9W8wI3h4bnWD/60kMvqfmBL7lz3Jxc9JEvu+O4n9HHwAAC5okgUJNapmQkLT/zC0xI5g5 tk9SomqfmQUAUAiaJIFSn5ml9TpKQ9OUXm+8ggNNG/iW0JN5EhLPOLALAACuCE2SANcFBwBQBJok AZoEAKAINEkCNAkAQBFokgRoEgCAItAkCdAkAABFoEkSoEkAAIpAkyRAkwAAFIEmSYAmAQAoAk2S AE0CAFAEmiQBmgQAoAgJTarTcqlThubS0CQAAPlJaNLmE7ucMrTSB00CAHAImiQjNAkAwCEu0qQv ZgfKtaqRs+84c+WW0CQAAIe4QpNkbAbDshyKrpwFTQIAcIjqTZK9GQymHIqunAtNAgBwCJokeeVc aBIAgEPKapMoUzkUXTl3IpoEAOAQNEnyyrkT0SQAAIegSZJXzp2IJgEAOKTUNMmTGjaVSviY+idf 7JrRJACAUgZNkgZNAgCQH5okDZoEACA/V28SSdEbVB3O5K0LbMfJjiZZbEXMmik0CQBACa7eJDOc JwEAlHlokjRoEgCA/NAkadAkAAD5lZom2Q9NAgAoZdAkySvnTkSTAAAcUlabhGuwAgCUPqo3iVKm HOZsKLpyFjQJAMAhrtAkCt8ziyYBAFAu06SyAU0CAHAImiQjNAkAwCFokozQJAAAh6BJMpLepFdj BpFbxQcIAODy7G1SnZZLnTKu0kdik/z9/RUfGgBA6YHzJFlIbBIAAIiHJomEJgEAKA5NEglNAgBQ HJokEpoEAKA4NEkkNAkAQHFokkhoEgCA4tAkkdAkAADFoUkioUkAAIrDZ2a5Plj6GHcimgQAoDhW k8jBVt3xqG745EQ0CQBAHWgSC5oEAKAaVpNeiJnv4ApjR3VydEyqQpMAAFQj73nSyrVH0SQAAJAI TWJBkwAAVIMmsaBJAACqQZNY0CQAANWgSSxoEgCAatAkFjQJAEA1aBILmgQAoBo0iQVNAgBQDZrE giY526K4LWoPAQCc5NWYQcIzoEksaJKzkSbNfS1W7VEAgOLS09P9/f3JrcA8aBILmuRsaBJAOTHj w5XkP3Y0yS5okrOhSQDlBJokAZrkbGgSQDmBJkkgf5PCw8NZUw4dOsRMJHfMMzD3bSIzs+bkTild 0CSAcgJNkkCpJglkw94msWZGkwCgVECTJHBSkwTOk8znVVZLw/2puUmWJ2SstZnPzCjOWZrNjdqV TAnQJIByQkKT8J1+KjeJlRCrheA+9Wdz5ZRgloQ3iiYBgCycf55UBij+epJAhyjFmuTgRhWFJgGU E2iSBC5xnmTG1ySqZEi4z/sJrFzCRhWFJgGUE2iSBC7RJOE3RPC98mT1dMfe+86HJgGUE2iSBKWp SXzLytskvJ4EALJAkyRwoffdcZeibH0+ifssnMgOCWwUTQIAWUhoUtfuEU4Zmuu6mBqN6zg4FZoE UE7gPEkCXFvI2dAkgHICTZIATXI2NAmgnECTJECTnI006dWYQfhmP4DyAE2yF5qkAn9/f7WHAABO gibZBU1yNpwhAZQrwl9/jiaxoEnORprUMbyn2qMAADscP7Rn3KhhEhZcsXYjmmQXNMnZmCa1qVNR 7YEAgCjxV/JIk/4bM1zCsp/GrUeT7IImORuaBFC6ME2aNm6EhGU/WrEOTbILmuRsaBJA6cI0afqk kRKWXfjZF2iSXdAkZ0OTAEoXpkkzpoyWsOzcJWvQJLugSc6GJgGULkyTZk+LkbDs7I/i0CS7KP6d fpTgpVFlZ/VLzblD4s7jNGgSQOnCNEna5VdmfLgSTbKLk64LbtcMkqm4afGsNok7MJEVt/n97srs BEA5gvMkZ3Kh76rgO7MRPhazVitmKdamLR/a/HJ0q6MV2HEuGZtks1VoEoDj8HqSM7nKd/rZ+0V/ wmsTOTbhJgkMzOY+CuA2idmuwNgENmcm/GcoLfwAQFl7313Xju0E5v/++Enzfbzvzl6Kv54k8itf uRMp/gOlXE1iDcBmD4SbJJJcTeJOlzf8AMCw+vmkiC7trc68/4cTlg/x+SR7ucR5kpnw3+tFrk3p JnFHaxdWk7hPGAqPQWB35A0/ADD4ruPQK7wDa8q3h35kTcF1HOzlEk2y+eq9wCZUOU8S/hMQxm0S awbx27WrSaz1U8gSgDhMk6xe765/xLPm+9v3H+POgOvd2ct1myTwUxmbZHWivKNlsWySZQglbNfe 8yS+MYsZNkC5xTRpzIvPW/3p4OhO5PabvUet/nT1l1+hSXZxoffdUdb+Xi8cANY88jbJ6hgExlYa myR+2ADlFtOkEcOek7Dsuo2b0SS74DoONs6TZGduEitIrE3L2CRKavgBgHrYpGFDh0hYduOmr9Ek u5T3Jok8c5IRruMAULowTXpusFBa+Gz+ZguaZJfy3iTnQ5MAShemSQMHDpSw7NatW9Eku6BJzoYm AZQuTJP69hsgYdmdO7ahSXZBk5wNTQIoXZgm9ezTT8Kye3btQJPsgiY5G5oEULowTYrs2VfCsvv2 7EST7IImORvTJLVHAQB2IE0Kj+otYcFD3+1Gk+yCJjkbaZLaQwAA50GT7IImAQCoBk1iQZMAAFSD JrGgSQAAqkGTWNAkAADVoEksaBIAgGrQJBY0CQBANWgSC5oEAKAaNIkFTQIAUA2axIImAQCoBk1i QZMAAFSDJrGgSQAAqkGTWNAkAADVoEksaBIAgGrQJBY0CQBANWgSC5oEAKAaNIkFTQIAUA2axIIm AQCoBk1iQZMAAFSDJrGgSQAAqkGTWNAkAADVoEksaBKAi1oUt0XtIcjj1ZhBAj8tM7vJR3j30SQW NAnARZGD9bhRw9QehaNWrN1os0llYDf52Nx9NIkFTQJwUeRg/d+Y4WqPwlGfxq232aQysJt8bO4+ msSCJgG4KHKwnjZuhNqjcNRHK9bZbFIZ2E0+NncfTWJBkwBcFDlYT580Uu1ROGrhZ1/YbFIZ2E0+ NncfTWJBkwBcFDlYz5gyWu1ROGrukjU2m1QGdpOPzd1Hk1jQJAAXRQ7Ws6fFqD0KR83+KM5mk8rA bvKxuftoEguaBOCiyMF67muxao/CUTM+XGmzSWVgN/nY3H00iQVNAnBRjpxAPN22jfn+z6fiZRqR FIqeJzltN5kNSdgEzpPshSYBuCjJL7R0bN+W3B4/cYp1XxXKvZ7E2jXyULndlPzHiNeT7IUmAbgo aW9I69qxHbn9/vhJq1PM9/lms5woMLN4Cr3vTmBI5h2hxO0Ld36BPwp7x4n33dkLTQJwUdI+uBPR pT253f/DCatTmPvMQ+50qxO50+2i0OeTxIzHrh3nLiU8m0j4fJK90CQAFyXtAge9wjuQ228P/Wh1 is37Yma2i0LXcRAzHrt2nLuUc3YfTWJBkwBclLQLwfWPeJbcbt9/zOoU4ftmwjPbRaHr3QmPx3J3 xOw4949LYHG74Hp39kKTAFwUOViPefF5e5caHN2J3H6z96jVKWLu21zQLqu//Mpmk2TZTe6PpO24 zT8Ku9jcfTSJBU0CcFHkYD1i2HMSFny+dxdy+9XuH1j3BX7Ems3mesRbt3GzzSY5vpvMQ9ZQxews d79s/lHYxebuo0ksaBKAiyIH6xeGDpG27PC+Xc331+/83up0gR8x05kp3Pt22bDpa5tNcsJuCuwL 345zpyix+2gSC5oE4KLIwXrokMHyrnNk/27k9ovth+VdrYBNX39js0my76brsLn7aBILmgTgosjB etDAgfKuM2ZQd3Ibt+WgvKsVsGXrVptNkn03XYfN3UeTWNAkABdFDtb9+w9QexSO2r59m80mlYHd 5GNz99EkFjQJwEWRg3Xvvv3VHoWjdu/cbrNJZWA3+djcfTSJBU0CcFHkYB3du5/ao3DU3t07bDap DOwmH5u7jyaxoEkALoocrCOi+6g9Ckft37vLZpPKwG7ysbn7aBILmgTgosjBultkb7VH4ajD+3bb bFIZ2E0+NncfTWJBkwBcFDlYqz0EedhsktNGogo0yS5oEgCAalhNqtNyqbrjcQVoEgCAOlhN2nxi l7rjcVloEgCA4tAkkdAkAADFOaFJX8wOlGtVI2ffcebKLaFJAACKU7pJMjaDYVkORVfOgiYBAChO 0SbJ3gwGUw5FV86FJgEAKA5NsrpyLjQJAEBxpbFJlKkciq6cOxFNAgBQHJpkdeXciSWadPj773Nz spiHaBIAgFzQJKsr50581CSie9dn9+zdZ84SAADIKO329QlTXv7ie5kvsyQ2G57UsKlUwsfUP/li 16x+k3bu3F3wIE+hEQAAlFuFD/KzMtLQJMuVcyeWaBLRs0fX5Z8tcXOvUNHbV6FxAACUN+QMidy+ 9PL0lQc2yb7ystwkynS2RG4XvDuDlMnDw1Oh0QAAlB+TX3md3Mp+hsSwkQ2SojeoOpzJWxfYjpMd TbLYipg1U+KbxOjY/mlR4wAAAFsUvcBdGT9PcrJ5s423wldAAgAAPmiSnNAkAABHoElyQpMAABxR Zj+fpAo0CQDAEWiSnNAkAABHlM1rsKoFTQIAcJAS5TAflhVdOQuaBABQFpS175lVC5oEAAAMNAkA AFwFmgQAAK4CTQIAAFfhKk06l5ao7jAAAEB1rtIknCcBAACaBAAArgJNAgAAV4EmqWbP2r/UHsIj PUc9rvYQAADQJPWQJsWO6qT2KIxWrj2KJgGAK0CTVIMmAQCwoEmqQZMAAFjQJNWgSQAALGgSR07O iXY30swPaa3P035NZgbUCKYLT9/7dWba7avGPzH30EptNgZV9eLMb1Sxzcna1X1sbAdNAgBgQZM4 ihtj6oqnPuPrGyc+yNXVD+jypffVgVcu3HCvv65Oo+CCa2tzvCcFBHiXnN9WhyyhSQAALGgSB6sx GTk/dbxxT+P11D7/y1HX7+gqNPrmsUaNNbzzi1mnCZoEAMDyf1W97K0KZW5kc3RyZWFtCmVuZG9i ago1NSAwIG9iago8PC9SMTEKMTEgMCBSL1I4CjggMCBSPj4KZW5kb2JqCjYzIDAgb2JqCjw8L1I2 Mgo2MiAwIFIvUjYxCjYxIDAgUj4+CmVuZG9iago2MiAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9D b2xvclNwYWNlL0RldmljZVJHQgovV2lkdGggNDcxCi9IZWlnaHQgMzY4Ci9CaXRzUGVyQ29tcG9u ZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0Nv bHVtbnMgNDcxCi9Db2xvcnMgMz4+L0xlbmd0aCAxMTIzOD4+c3RyZWFtCnic7d0JXBTl48fxWRZ2 l1NRBG8ERM37PlDxRBBM8b5BFFAzNM/qZ5ZaHmllSoW3aXmbV5IaHUZeqZWdf8u8b/PCA5DzPzC4 DXPt7Ozx7C7fd68Xzc7OPPvMIB+GZQFVYWEhxRIX2ZwCAACLWffFT+ybKn2Fk/q2evw0f/600e6u WpXahcTcAAAcWWF+7pOsp/97Z62HVp286ySzsqTC9CXwG0nDy3u6FWQ/zM/KKMjOIDpVAAAHpHLW qpx1atdyD26ce3PzKeaiuKjCdILffWVMfnZGQdYDOsGk5wkAYKNWpv5q4giJUY3pt86eftevXFi6 9w86xEUVHty96Yevjc69dxEJBgAQs2r/7z16D2xWP0jxCD//ee7LvdsTejakl7Ny8l7b+MvWr06r urSqt2VBYn7Wg5y7F802WQAAh7P6wJ8zZkzPunhM8QiutdotWrQ4PqI+VVzhggLqxTU/FVV487wx 2Tf/ryA323yzBXujaVFlxBQd9X+3Pn0rM4e+7ewcNNqvbSeNll7WrwRyuO8gIGDNl2emTZ3y5Nxh xSO4B3V45933xvSox9zMfJqXtO5XVfP6gfveS3xy+SfO1smHMpy0rgYH9cy/OzykstpJpXhaIEHl 3rJCaEy56n5O9I3C7Px76Tc/X5OVa4FH0rSsFjvdlToxq+uEJv0Dm7rV8x06x0t3ZffoPsm/ZxVS Hi/EBjbVmOmxXOr7Dn7Dy/Xhw30Tb9/I0q92qjLWv1dXddY317auoI9R5dnCu1U/r5q1nV0oKvdO 9uVv7p/c++RRycFb78zYCM47yFzvCzDG2rS/p0x+6dHfh9grf79497eLd+mFoZ3r6FduPvQ3/bZR rYoNa1Vkb+xZp/N7S94fHVayJV3huJTTRRXeuzj+8aVTnMd76VvvG5mG39Xe90+8P6i6TqNWckwg zcm3fJ8P/So/+HXh8Df23dHW6dJ7aPMzKcltOleubYlXEmbdnbPl1k3KuVGdCtEdI9uMfdmt6GM+ 7oaPp7+OUlHa9q18qjqb5ZGcNU0WBYT4Z6dPWvLt5X6+TsUrvTx6Lq9WS3v5o6j4LfdeGhPbadg4 d+qXI4teS/nqZmHDkdMXT2xaeOKnTxe75xVY+8zYCPY7qI253hdghHVfn508aWLGma/ZK7emn5v1 yQl64c2RrQeHBgmu0StXr9uSpcviugUzN+kKx6/6vajCu9+Oe3zxJOfxjuieD+/RQ+VURFX0v2eL pf+/4JVx/QPuo8IWoWlRI/51D6e/PogeeMJJV9tNlZuTe/VegW+Ad68WYS3G/c+NOn/n6Fm3xl3d PFyo7IsPf1p58+c/8pnXfzt5uzdP8G3SVueqpp5efnR6zc0fT9P5KqLycG0Y69usg5uXG5VzMeN4 8s3f/ilwaeOfSA/4045xL5yhuk5YPt+bM5n8n6+tn/Mws3h0TZOqsXPLaW/c2Zz0713O9ada0+y9 oPa1ihbz7mad33MrfW9WdiFnMEoX4hn7cnX1j+8NG+/VuHJ7LxXlEVYr9kXX3MNv9Rn7g7ry8Lmf D2muPftWt/Gp94Kr66q6qrWtPpia1OLptxPXfn+xW+WWys+MxAwFz0yh5Mksxcm55uDK7SM9KtLH k5N748j9H7fcv3izQOLdoWFO+4W7J697NGmvLbnsOX9rw7R7D/OLZuT1fK2YeF3B79e37Cs/7JWS d1CmJqRFjcCmpkwVlPj4m3OTkibc/+NL9srtRy7O3vwzszx7aLOit6ybA5l/ac94N+ixNPnDUV1L 0kxXOHHtmaIK71wQ8+jCCc7j/eDRT06F589IjPa/gwpbhEuDanGLvF3pr8evnf3xeOa9M87nj/5x 9lE2papRp3vrCbPcKerJkUW7d6ce+afyc9NWJ7V3v7pzzPXLt91UGl2b92u39X/6w2uzZn+b3X/N svh6N/bEX7pww0Plom25OLh9cN5fyUte3/BNhn+XmJ5epza3DO703Hh6QPrid1z9yCqNtE01SfPq FN2MPZJZqdvStJlttH+92/tEXl4znZO61qt1+7SnTr82dNye5j1rRJVnPR/l5FuudeiDLzfMOJhZ NWLBste6qk+8eij9l+ounOesdKo2qxq0rXDpo97v/ZoZU8/dq3VycEjNjF0jhi38JbB++/EfLq/v dmZZnwHfUW5NvTX1At1rVIgMenFSpYydU4a/HdI1tNv4xYrOjMQMNcJnpqZn+bZiJ5P3/hq9yFt3 94c3R8z7KsO7YY+BI5o83Z8SWMHdU2wEXduAcUWz/ffzV3Ye/Db9dGH1WV+/He55KSX6i3u5HT2c 6c89wSE1Mg8mDFnsseKrJVVK3kE1W7YzbaqgyIZDF5JeGHfn1/2c9TuPX3lz+++clbMGNuzXtgZn pU/jnskfLY/pHMDczHyaP3792aIKf/bW8Ifnf+BsfbLcoIieESWx1beXneTihXnTE3pXv6lzQYUt Qe1SfXB+x2ENq+q/zH50+8Dkm39cobTtAl+c7UFdWDuoz5Y7ziH+Wq3PyNGLX/C7s/GVqSuimzcP Tni/otvFtYN6b3/g0rJOdOIHs2rc3fzKSym9WzarG7+0ovvljwf32nTHuWllFw+q4Nb9vBotn58w d65n0Qf5mIdVy0W16NJ48puVS266V60zbdzrA8pdTZk0cUN462r1B22sFZj9TVLY/N/y2tXUNarj WY/9HYSCvBM/Pvhbrfbw6DpixcLAJ/tnDJ/buZ1ndefSJfDqXyUhsdLtDVPGftS5Q+uQsct8PM6u HNhv50Ndu4AuEz5a5ON0anb32JuVPJsGeYV4qyhdx4AJr3nmH5kZ8UJusO/w0BHqUOPPTCPXohAL zjC0VZuxywTOTLMO8TOTfQRPZhPXUnXTNPcft6Cc+tdVE2b8dPd+ZQ31NDv3RkZh4/YdR85YJjxC 666Nk+jZFn2+2Z+pC6nmrK35YsLcEd7XViRNWNulXbMO45b7lru+ZWTk2ofdVu55txbzHqnVblry yhqmTBUU+eS7SxPGJ9z+eR//rt0nr8/f9Zf+5v/61o1uVZW/mW+zXh+mrBrZyZ+5SVd4wsYLRRXe NKv/g7NHOFv/XnV0z549n+W3pMOq4v/Ya+ZOiQv3uahzcTLfkQJLQeFvZ3K+zwuq0W7w6KR+gXRz Hu1dNG1++6DOjWYs9KJOzekee6WiZ5C3U3P/ri1efcun4NjMiHGa5uEvLVhUjvNRV3j8tfCx6ubh U4ru+nFO95jLPp61y6maVlLlPqEeazpGvP12hZLseoQ17BT6Cj3+s5vB1WrEbG8ScC91Qu+fK3RL mj233K2U+EHJmX5e9Ss6dayu0pU8lpNLQEytbn3LVfH579Ny4Q+zwhKyAz1611CV+j6DqoK2746m DXK+finyZN3Xp40PKzw+ZchLX1ao5RFcrdmoN1N8i66FB//j4RYa5FTDhVKV798gaYp7xs5Jvd9Q +Xv0DFBd+dv4M/OcV69WMQGCM2wQMfP9ReUFzkyH8IWLKgqezOc8Inwo1j99V/e2C2qFtfIovpFz +9j1/QsOH/83y7VDv3cXC4/QvOfUhcx5jvvXzyOoorqFb1W/kTsaBNz8bEyfM/WnTp86SHPmreFx mzV1I+d8vLgm8x6pHTFrxWIfk6YKSmw+ej1h7LgrJ/bw79p/+tbSL87pb06KDOrZ1I+/WY3WfVat WD40pCTQWTn5U3f+W1Thza/TFT7K2fq3KnGRPSNV6pLs8nJcci08d3JceCVU2IJysgr+/rfg+uO8 jIpxLyVPqJab/mrEi66to15asMCr6Iqv32kXXUiQOqhKbMPxCa53Nk3ot8ClbttpS1ZV9/jrg+j+ O6/nswZzbty47dT3V9XwuPTx4OifnHUhgepAbfE92o71pi/QZ7dHw84dX2HdDHb2DZjVMKaH6rtJ c/8cNW9847/f6j7hwP2WtXR1aqobuj37uHdpEjjxQx/X28fmxLx94PIjr17JBxfVZwap5tEzWF2h 9D8TVeUp9eL76U4u3OI6dWTDjH3xPZaep9pV0zQMrNB08Gd16mtOzwlbeSYr8jm1r5OTpvGyJr2b Zn87fsjMo8FBbl1qq8vlGH9m6nWYsTSlquAMA9pMXbq6Jv/MuDSoNWGFr+DJrOcZFexU6rNdfsGx P13/9AjybzMiKTHU89Hn62cvqOvbKFBshOaRbyx/2/vZeQ4NUtdwcVIHzW80tEPmnrGrvRZO66L7 YUb3//2Q1fa57hOXL/IruRZuM2XZan8TpwrG23SErvDYqyd2c9Z/cfo2O8EMOsSRTX05K6u3jl61 YsWw9v9VeMpnt4sqvOWNgUIVHhUZGflffJ04OS75f/G18CVU2CK0rQL6hz/9LfX+hTNPHqqyAya1 HNFTd3rW8Bf2VGncc9Zy+tKVenJkwdL1B5vUrdOw93v+we7nP3p+/KdXmgSV6xW7umP3Og++nPXB 9kPOThUqPdelWefAv1Lmn8/WdhyxIjSsXvbJd5etTW1UO6Be2045R1c/UnWoN22+pz67jbqEvsy6 WcfFVxPgFru+QZVrf9yu1sD98+nPv3ze06Opj0v7ALWn/mNb0zQwaVlF3bUdLwzZn1ExbNTSIWH0 V17MIJ496jj7cp64cqrmNnxzg5rFy+cWx4xcR1Xzqufj3Km6k7ZcH5+EqbXyj29auNBNkx0YOKDW gHivwmPvDxv7xQNNSN0OidMjCxWcmQbtJyV/VE14hhX6xQqdmRwX17YpDboJnkynZkGsg9K28O/Z 4u6h3d/9fPNO5TFj34qrdH97Ut+3/Fv7hIenNBQcQdVp/PK3K7LPs7oopt6JKbU9btymqvg+2pwU PfdWBc/GNbu+uHRh+ZItvfvFrjRpqqDIpiPXEhITr54sVeEvfr79/rMEvxRZ9G039s3IZqVCXL1V 9KqVK4e1r8bczKQrvONmcYVnD8r4h1fhyqUrXPIE8X9PSTDXxHMmj4rwvYwKW4RL3arR0139/L09 i7+Uz7/38JfNb89MOZ6pCXkubHJRa/5vQ/IfLYdF16/oTGWd/2f7mzNSjhdU8Gzu5xISVP6xX3zt qIiGVVzpImVfSj9/cNXW1Av1WnoFO3tcqTi69vM9G1Vxo7LP3flmfuqWX9wahkfMmPcsu57hTbp0 nM66WY+ug5MqaEHjQW3pL/1vrOszauWFBkFutatpWrO/NUepXfzjtN2G1PNzoZ6cO3/0aPmwkRVK DcI5QienwLcaDm6vobKPvdL9taNP2vjr6gW41HdVUYWq+5ktHnQZ1bl9o0o6isr99+Efuza89dGu q/l1a7nXqNJo5IQZ7krOjK5Lt4RK3cVm6P3Ul3dmgt0DnD2uVhI7mezD0emCBhY0690gmD7Q/KdX 07fNf2396cfNgj3C6pTPFHx3tI/sNYNznove8c7NVzYND6SXLn0UmfDptSaBbsF1ug59nb2liVMF JTYevpqYkHitdIVTf769pDi7kyODooqby1+jV61V9MpVK4d3qM7cpCs8eduNogpvmzM44x/uz+T9 6hcbGRXJf0a4ZOHZ7TmT43r6XsJ35ywl9+mm7x/99Tj/SV7xS6mcnMp7agIrab39ur64ZH65oo/J 0dfd1Pce5GTk0A108qvoVqeCuqKvNsTHKet+9sEzmX/eyXlQ9FoyVQVvbUBFTe3yLgHVXdwePP3y rye/3cnNyC2kP+Tr13RvW9m5slfu2v0Pi1+O6hnxnNYvL/OdVNZNddEPDlQcv9hfc3JRn7j0AtfW vpq2wRofznu+sOCnXzIOXHl6L7coJvWqqq9fevqQPQhHYeHZX++tOpdbQFE+1Twb+2g7BTq7F4e9 IDfv57NZJ65lX32S/5S+W62u4OFSw0dTQatuGKjxV+UoPDMVqdPiM/TMEDozlVy0GaIn04d9BZKf f+qvx8euPL36pCCfvjjWuVT31dX0dAmpo9E8EBmhUu7H+0uf56KDLzh58s7Wa0UvMXOv5NnaTxNS 28U7t9R7xNSpgvE+PXwlMSGBU+G/bzw5e/MJvcAOLh1i+m1wZfc6VdzZGxdXeNWIDiWvnaArPGnr taIKb587JOMct8LLTxZW8Cl6dpmu8LO3zCLFXnn30p8jW3tqcS1sIYUFF6/nXMgoyC6gnr3oU+Xu 6dwgsHPI1Dc9nr2GIVBHZeZSRa+HdXLy9XFpXEmtVRUFLiMj78ztvPu5hcxLZbU6dS1fTYCnSq0q fJiRe+ZW3r2SvVRV/LSNvQv/+CfnRk5hPuXU8jmdnyr/F/ZNZ62m7rQ6vbtl7o4ZvuBnf/pCuKpb qK+K/47PeZL7+/W82znFD6py0qkLcvLoyRcPIvDJujDncc6xqwV0TAsplW8NXcty+n9ldIgLLt/O ufCwMDu/sPjwVR6ezvWquPhpTDozkjMUOjMVnZylTib7aAqznuSdvZ13M6swt3gztcaZ/oqhtrv4 u8O94PdzrPNccooKM+/n/HArPzOv6IZHZV1HHyengtLvEROnCsb79PsrifHx109xnxeWr2rL6JWr V4/o+F+FJ26+WlzhN4c+PHecs3VOXkF+Ae/F9jz0R4zWWa3Ce9fKtCG1J8591hqvyIauQoEzH5fn qick+7hT+Vc2zY6fd6rQtW0VbfO6rjVs8AfVrHxmoCz5JP3y2PgxJlZ4xeo1I0OZb4YUVThp02Xm 9cLDHp7jvl4YbN3Txwv33C/++tQrqpF7ZUu3Jj9nR+qtw9mUs6u2UTVdZV/3btXUzrb52dfKZwbK jE/SL4V0CW8YVE3xCL+fu3b024MjQ1mvF950sbjC84Y/4v3UBti6gtyfzmRdL/r61LmNFVpTkP/X uSfnnhTm0l9lu2paB+l8bbTBVj8zUJasOPiX4Y0kjQ2vq1+mK/zCp8U/tbFz/khUGADAyop+gvmT c6I/OwcAAJb2wpbi1wv3bVGJ9EwAAMqiXT/+q+oY0jb9yLEHd24yqwrVWrJzAgBwbKr8p8zCrasX EyZMRoUBAKwKFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYA IAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJ FQYAIMkiFQ4LC6PfpqWlcVbq1zAbMNibia23KPM+qOCxAwCIsdS1MCdG/AQzN8WWObtYDpEHBQDQ s3aF+ZeK+jViV5FiG8i/oNavkRhc7BD4j6ifiZwDNGoyAFAG2VyFKaGnMvTrxZ7roEQuqPnjSwwu OCZ/cMHRBA9QwaccAChrzFDhE5ey2Ddb+7syC+ziCD4dwV8jeHkr3TWDG8i81hZ7UOnnTKQPUOZk OCcQAByGvocSzFNhwUdSUGH2GkqoZTK/3hd7goISv/wUfFDpwRVX2OBkAMABiLWRwxYrTIm3THBZ 5uWnwQMx6qJbzgGaMhkAsHfkK0wZX1ijXkdhlgrLD6jMwVFhAGDYboX16xnSL2/grJTYnirdPuk1 yiZjbIUVTAYAHIZNVNgscP0IAPYIFQYAIMlxKgwAYI9QYQAAklBhAACSUGEAAJJQYQAAklBhAACS UGEAAJJQYQAAklBhAACSUGEAAJJQYQAAklBhAACSUOGy653V20lPAaBMmxY/kEKFyzK6wqFhvUjP AsC+paftGxc3XMGOy9dtRIXLOqbC4U2rkp4IgL06ePo6XeGJCSMV7Lts1SeocFmHCgOYiKnw1PGx CvZ9N2U9KlzWocIAJmIq/GpSnIJ9FySvQ4XLOn2FW7ZsSd88deqUhR6IHp8/uOBKsd0pS07Ppphy sMy+0rvLP+2OzcTzrN+RqfAbk8coGGfOkjU2WmGxv2os8YcypdfbESv/0SaDFeasV/wPtyxU2FyT NOUky9kRFTYdv8LzpicqGGfm4pU2WmFK6O8TG/wr9BK7gBh+hdkfyfoLK/Zd+psU68Oevxf741xm gsXG56wUm5jYpwr9A/HH5zy02PwFGXVyBDeQPmr+cUmcEMG7OBPgnA3+kfLvMmW2xo5AyTjnYsPy R+DMSvAwDU5YbGKcf7rProXjDU6eb86S1fZXYYm/Jy92FSm2gbF/1l5wcImh+HtxZiLnAI2ajILr aE6FKUNJFfuHy/mYp3gfeAYrLFYc/jSktxS8KTgrzmQkxpfeXnoa0ptJjENJvi8UT0BOhRU8KH+2 Mo9X4p8Nn/T4ghcQgp8ejPpHZfDf87PnhUfr13Tu0FbiKA4dPq5fXpC81gErTAk9laFfL/ZcByVy Qc0fX2b7BPeSmIngARo7GdMrbPBfp8RNiY8iS1RYbGPOvfwLYbEZyjkQzvYSE5YYR/6xyFw2agJi p12szopnK3MDBRWWM4LYqZBzmAYnJljhaeNHsaca1jlE8BDSDh1l33wn5WPbrTBVujiCT0fw10hc k4p1zeAGMissZy/B61yJA1QwGWNZocJyEiy4u8FpCM6Ec+XL/6gTm6TE4evxpyfz5HB2kXksMpfF zqHBfPDPm/QEjJqt4PFKnxPKhNMu/UCKK8yfA/8cPnu9cAxVWlT3Dpw1qV8d5qxZtmqDo1WYvYYS apnMr/fFnqCgRMIn9uSD9OCKKyw9GaPYaYUp3kejnArz95L5WGLE5iB4RNLXVmLj2FqFFcxW5iWn 6FnmkT7t0qdCwbUw/9EFKzwubgR/qn0jQvXLuw6k8zdYvu5Tx6wwJd4ywWWZl59yZisxDn+lKdfC 0pORzxIV5m9jYoXlpNPgTbFhBScvuKMgBefKYDVkdk3iKMTOgNj7gr+Z2JiKZ2vGChs7Q2WHaWyF x8QME5zqoKjO9NttqYcE712zYZNNV5gyvrBGvY7CvBWWeCCJoeQ8wSJ/MpZ4Xlh/k3MvVToH/A2M rTB7ZP5Q/OmxN2PvLh1B6XnyH0uM9BzExuGfLsFxxL4WFpykJSosdoDKZsu5S+wdwd+dz+Bpp0RO hZw1MicmVuGYYUMkZi5mw6YtdllhinXhSQlFirNe4qt4iecNpNcom4yxFTZ2MqZUWP4ubAaDJT/B YBRlX8hb4rQru5i1U4LnkKnw0MGDFAy4ees2W6+wWZj9q3hHggrbF/mXjYL7osImkqjwwAEDFAy4 fccOVLisw++RADARU+Hovv0V7Lt712dlosIgARUGMBFT4ajefRXsm7p3Fypc1uG3vAOYjq5weFQf BTseTN2DCpd1+ItHAGShwgAA5KHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIA ACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwmUXfr8wAFn4/cJlHf7WBoDp0tP2jYsb rmDH5es2osJlHf7uHICJmL87NzFhpIJ9l636BBUu61BhABMxFZ46PlbBvu+mrEeFyzpUGMBETIVf TYpTsO+C5HWocFkns8ItW7ak3546dcoqkzIbY6dtp4cJZDEVfmPyGAX7zlmyBhWWEhYWRr9NS0uz 2o5m2d0otllhcz0cKgxWwFR43vREBfvOXLwSFZYiv4acLc2YUUsXmV1hpkEMpkTsNRQrT/wt9dgh kxk1zmhi02DuEtxAbFbsHSU2Nrg987jSxy7/0Y0dgcInBtv27Fo4XsG+c5asRoVF0fmj2yeRV/0y s8AQvIvdUP7GnO3Ze3E25k+GU2cFydZXWKxT/J5Kt9XYCgtuI5YtY4vP3lHO4RissFHnROzRZc5f 4lMI2JRnzwuP1q/p3KGtxPaHDh/XLy9IXosKi5JfYUrkWpjipVN6WeZmNlJhSqQLyios8dAS4xic lVHlFVvmXwjLPCcyM40K2zumwtPGj2KvDOscIrhx2qGj7JvvpHyMCgvTB86UCstPqszdKd5Vs+lH qqDClGSIDXaKvyN/NIMVFvyiXnoci1bYqEcXnL/M50zABj17vXAMZ31U9w6cNalfHeasWbZqAyos jP1UAMMsGXWYClPiIVbwvDB/NOkKy3m218TyUsZXWMGjy7wWNnj2gCymwuPiRvDv6hsRql/edSCd v8HydZ+iwgI4gTNjRu20wgaDK5EY/l5iDF45yqmwxDgKJmnsZyZlj44K2zumwmNihgneOyiqM/12 W+ohwXvXbNiECguQU2GJZ3LFdpG5LH2X4Bo5d4mR8xoJwV4IbsasNOoJTcHnFqjS15VyvlqXfo5C bHzpFEp0VuKB5D865y6xE8vfHWwKU+GYYUMU7Lth0xZUmEvwGlMixEZ9R469GX+l9E2xAcXmKRN+ ds5yl5y4mC0jmAoPHTxIwb6bt25Dhe2PeV9BXGYrbIXLTFS4jGAqPHDAAAX7bt+xAxW2M2b/IY4y W2EAc2EqHN23v4J9d+/6DBUu61BhABMxFY7q3VfBvql7d6HCZR1+yzuA6egKh0f1UbDjwdQ9qHBZ h794BEAWKgwAQB4qDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQJJV K2zKRAEAHJWVKgwAAIqhwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIA ACShwgAAJKHCAAAkmVThd1Zvt/gEAQDs3LT4gRL3mlrh0LBe5pooAIDNSk/bNzZuuIIdV6zbaPEK /3vrhoKZAQDYi0p+VegKvxg/UsG+H6z+BBUGADAJU+HJY2MV7LtkxXpUGADAJEyFZ0wYpWDfRR9+ jAoDAJiEqfDMiaMV7Dtv2VpUGADAJEyFZ0+OV7Dv7CWrUWEAAJMwFZ43PVHBvjMXr7RGhd+fOZa+ +dK8Fcx6/k16mbOSTeIuzjZ60hsTJOdYAMC+2MG1sJwKs3eU3l4QextbLp0tzw0AlLGP54XFKqlP sH4l+6pW8C6D18sSQ7E35qznrJT5mUNiKGYQ/mZihwAAdor/GoluoSES23+dflS/bL3XSHDCJNYp wYtZfcIkQix9LWzwSll6F8GbnMnwlyXuQoUBHIng64UjurYX3PjAN0fYN633emHTKyxdMemLTYlE cnYXDDG/qtJzVjB/ALBfYj8793xYR86az9O+56yx3s/OWafC0nUWvLjmbyn2xIL8OaPCAGUKU2HB 3yPRL6KTfnnnge/4G1j190gY/BqfMneFJZ5QlhNiVBgA5GAqPCZmmOC9g6I602+3pR4SvHfNhk1l tMIGdzFlzmKbCaYfAOwdU+HY4UMU7Lt+4xZbrDBV+rLUXM9IUKVTKPhwnEGkJym2o8T3+nAtDOB4 mAoPHzpYwb4bN2/Fz84BAJiEqfCQQVIxFbNl23ZUGADAJEyFBwwYoGDfHTt2oMIAACZhKhzdt7+C fXfv+gwVBgAwCVPhXn36Kth3355dqDAAgEmYCvfsFa1g3/37duOvfwIAmIqucFhkbwU7pn2x17IV VjAnAIAyxYIVBgAAE6HCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAA JKHCAAAkocIAACShwgAAJKHCAAAkWbzCYWFh9Nu0tDSr7Sh/TOYms8b0h7PEhAHA4dlQhQUTaWLU JAZBdgHAFli2wnSn+JeZ7Jv6Zf1lqdhd7Nixr2E5Y/IHlxiTfa/YZbL09AQHFxxBYp4AUJbZSoUp 2U8XSAdXbGPph5a+i3NExo4gZ54AUGaZocInLmWxb7b2d2UWmARTimolZzP51bO1CvOXOecQAByD vocSzFNhwUfifNVPmamY/CcTTB9T+i7+4Zi9wgDgeMTayGGpCusvhPU3KbNWWDCRlquwwQtwBceI CgM4NjuoMOebbKgwADgSkhXmJFi/kjL0+gejvsmm31JscAVjGnwIsZUSxyL2KKgwgGMjfC0MAFDG ocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHC AAAkocIAACShwnbjndXbSU8BAMxmWvxAZgEVtht0hUPDepGeBQD8Jz1t37i44Qp2XL5uIypsf5gK hzetSnoiAFDk4OnrdIUnJoxUsO+yVZ+gwvYHFQawKUyFp46PVbDvuynrUWH7gwoD2BSmwq8mxSnY d0HyOlTY/qDCADaFqfAbk8co2HfOkjWocClm+Qublv4znagwgE1hKjxveqKCfWcuXokKl2IXf+cY FQawKc+uheMV7DtnyWpUuBSxCgv+mXpK8s/dc5alRzaq+6gwgE159rzwaP2azh3aSmx/6PBx/fKC 5LWocCmCTRSsqlHLlHiIUWEAe8dUeNr4UeyVYZ1DBDdOO3SUffOdlI9R4VIsVGH+silQYQCb8uz1 wjGc9VHdO3DWpH51mLNm2aoNqHApqDAAGIup8Li4Efy7+kaE6pd3HUjnb7B83aeocCmoMAAYi6nw mJhhgvcOiupMv92Wekjw3jUbNqHCpSirMPvJXznbG3xEaagwgE1hKhwzbIiCfTds2oIKl8J5zQPF +yYbVbqYgi+BQIUByhSmwkMHD1Kw7+at21Bh87DmC41RYQCbwlR44IABCvbdvmMHKmwSsWtki0KF AWwKU+Hovv0V7Lt712eosP1BhQFsClPhqN59FeybuncXKmx/8FveAWwNXeHwqD4KdjyYugcVtj/4 i0cAjgQVBgCwCagwAABJqDAAAEmoMAAASagwAABJqDAAAEmoMAAASagwAABJqDAAAEmoMAAASagw AABJqDAAAEmoMAAASagwAABJqDAAAEmosN3A7xcGcBj6Xy5MocJ2hK7wvOmJpGcBAKa6f/++t7c3 /Za5iQrbDVQYwDHMXLyS/lhGhe0PKgzgGFBhe4UKAzgGVNheocIAjsFxKhwWFsa+mZaWZsbBzYiZ p+nTQ4UBHIOjVZipm7lKZwmoMACwOXiF2RfI7PAJrues5OSSf5P9WIJDMYPwN6N4FVaQZlQYwDE4 eIVl3mtwF8GbnFLzlyXuQoUBgOFoFdaTyBwnkZzdBUPMr6p0XiUKjmckAIDN0SrMr5v0kw/SIeY8 sSD2PAMqDACKOXiFORezMi9+KV4xUWEAsJCyW2GDuxh7U06FBdMvNhNpqDCAY3DwClOln5GgxF84 If1qCrEKi+0o8b0+fHcOANgcp8JlDSoM4BhQYXuFCgM4BlTYXqHCAI4BFbZXdIWnxQ/EX9wAcACo sL3y9vYmPQUAMA9UGADAJqDCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACSh wgAAJFm1wqZMFADAUVmpwgAAoBgqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioM AEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABA EioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIq DABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgxg Ke+s3k56CtYzLX6gxL0OfyqkD18aKgxgKXR6xsYNJz0La1ixbqPBCjvwqTB4+NJQYQBLodPzYvxI 0rOwhg9Wf2Kwwg58KgwevjRUGMBS6PRMHhtLehbWsGTFeoMVduBTYfDwpaHCAJZCp2fGhFGkZ2EN iz782GCFHfhUGDx8aagwgKXQ6Zk5cTTpWVjDvGVrDVbYgU+FwcOXhgoDWAqdntmT40nPwhpmL1lt sMIOfCoMHr40VBjAUuj0zJueSHoW1jBz8UqDFXbgU2Hw8KWhwgCWouwCsF3b1vTbY8dPmHcyzLAM sw9u0Wthi86c/0AKHgLXwgA2StmToaHt29Jv048cN+NM2GNaYnzLPS/MmS1907wzl3gs+fC8MICN UvbCgG6hIfTbr9OPCq5nsO9lr5fYkb8Ls0a/LPa4cljoNRISUxI8GxLHwt9ev4a/u7HzxGskAGyU shfJRnRtT7898M0RsZVylqUH5O/F3BQbwSALvV5YznzkHIvEGZBzAg3C64UBbJSyHxh7Pqwj/fbz tO/FVspZlh7Q2BEMstDPzsmZj7Izo19jncOXhgoDWIqyX57QL6IT/Xbnge/EVspZlh7Q2BEMstDv kZCeD3Mvw9gzw95XYjOZ8HskAGwUnZ4xMcOM3WtQVGf67bbUQ2Ir5SxLD2jsCAat2bDJYIXNdSo4 dyk7MwZPslEMHr40VBjAUuj0xA4fYuxew3p3pd9u2vuN2ErBZWaBv6P07tJ3ybd+4xaDFVZwKgRn K3jgEmeGP4jgGrGVchg8fGmoMICl0OkZMXSwsXuNjO7GWfPJ7q8565k17O3pNfoFg8MK7s5ZNsqn m7carLCCU8GeIYM/c/ZdEsfCH0RsjSUOXxoqDGApdHqGDh5ktYcb1a87/fbjnV9Z7RH1Nm/dZrDC 1jwVVmbw8KWhwgCWQqdn4IABln6U+IE99Murt39p6YcTtH3HDoMVtsKpIMXg4UtDhQEshU5Pv379 Sc/CGnbu/MxghR34VBg8fGmoMICl0OnpHd2P9CysYe/unQYr7MCnwuDhS0OFASyFTk9U776kZ2EN qXt3GaywA58Kg4cvDRUGsBQ6PRFRfUjPwhoOpO4xWGEHPhUGD18aKgxgKXR6uvfsTXoW1vDV/r0G K+zAp8Lg4UtDhQEshU4P6SlYj8EKW20mRKDCAAD2ChUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkV BgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYA IAkVBgAgSaDCX339debjh8xaVBgAwKK4FS4sLOzRrdO+1P36EAMAgKXdvXVt/MQpX379XUmFd+/e m/M0i/SsAADKhNyn2Q8f3P2vwvSqXuHdUj5c5uyicXX3JD09AABHRl8F028nTZmx7+DX9EJJhWn0 FTH9duGcmXSLtVodwSkCADiwpKkv02/pq2Dm5n8VZoS2b0dgUgAAZUb6kWPsm/8P95F+4wplbmRz dHJlYW0KZW5kb2JqCjYxIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0ltYWdlTWFzayB0cnVlCi9X aWR0aCA0NzEKL0hlaWdodCAzNjgKL0JpdHNQZXJDb21wb25lbnQgMQovRmlsdGVyL0NDSVRURmF4 RGVjb2RlCi9EZWNvZGVQYXJtczw8L0sgLTEKL0NvbHVtbnMgNDcxPj4vTGVuZ3RoIDEwNT4+c3Ry ZWFtCjgGoJCDp0/T//////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////a9q1DCgAgAgplbmRz dHJlYW0KZW5kb2JqCjY0IDAgb2JqCjw8L1IxMQoxMSAwIFIvUjU5CjU5IDAgUi9SOAo4IDAgUj4+ CmVuZG9iago2OCAwIG9iago8PC9SMTAKMTAgMCBSL1IxMQoxMSAwIFIvUjgKOCAwIFI+PgplbmRv YmoKMTAgMCBvYmoKPDwvQmFzZUZvbnQvSGVsdmV0aWNhLU9ibGlxdWUvVHlwZS9Gb250Ci9TdWJ0 eXBlL1R5cGUxPj4KZW5kb2JqCjExIDAgb2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkL1R5 cGUvRm9udAovRW5jb2RpbmcgNzAgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNzAgMCBvYmoK PDwvVHlwZS9FbmNvZGluZy9EaWZmZXJlbmNlc1sKMTQ3L3F1b3RlZGJsbGVmdC9xdW90ZWRibHJp Z2h0XT4+CmVuZG9iago1OSAwIG9iago8PC9CYXNlRm9udC9LUFNIQk8rV2luZ2RpbmdzL0ZvbnRE ZXNjcmlwdG9yIDYwIDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDEvV2lkdGhz WyA0NThdCi9FbmNvZGluZyA3MSAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVuZG9iago3MSAwIG9i ago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRGlmZmVyZW5j ZXNbCjEvc3F1YXJlNF0+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EvVHlw ZS9Gb250Ci9FbmNvZGluZyA3MiAwIFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iago3MiAwIG9iago8 PC9UeXBlL0VuY29kaW5nL0RpZmZlcmVuY2VzWwoxMzMvZWxsaXBzaXMKMTQ3L3F1b3RlZGJsbGVm dC9xdW90ZWRibHJpZ2h0CjIzMy9lYWN1dGVdPj4KZW5kb2JqCjE3IDAgb2JqCjw8L0Jhc2VGb250 L1RpbWVzLVJvbWFuL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMT4+CmVuZG9iago5IDAgb2JqCjw8 L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkT2JsaXF1ZS9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+ PgplbmRvYmoKNjAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9LUFNIQk8r V2luZ2RpbmdzL0ZvbnRCQm94WzYyIDAgNDM3IDcyMl0vRmxhZ3MgNAovQXNjZW50IDcyMgovQ2Fw SGVpZ2h0IDcyMgovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViA2NQovTWlzc2luZ1dp ZHRoIDUwMAovRm9udEZpbGUyIDY5IDAgUj4+CmVuZG9iago2OSAwIG9iago8PC9GaWx0ZXIvRmxh dGVEZWNvZGUKL0xlbmd0aDEgNTIyOC9MZW5ndGggMjUzOT4+c3RyZWFtCnic7Vd9cFTVFT/33ve1 mw3ZfBDSrMpbnolIsoSAmPBhWJLdNcmOdUOC7KKW3XxgIkEiMBmilFkLCG6Csy3UGa1KUNGARN8S 1MDQDkXBdGzHOqMdLVTbThwdaxydinQ6A9tz301SYlunM/2nznjP/u7v3nPOO/ee+7FvFwgAZEIc GIRubSybD1bJPoLVbS3rY12i72wCIEtbujfrL5QdOoSK8wDy4rVdd61/7cslJoBSACCtuauzZ63w n+bEamt7W6z1V7vW4rN5N2D/xnZU5OTaHwawb8H+te3rN28R/jkSAHV2bmiJjT/fh+OdXR/b0sVu U+ag/+Oo1O+JrW8bn18SK1fXhk2bRT8vj9u7NrZ13fr6dWvQ/yQAa4L/t/LWf7SUo7SQMH2ArsbW z6AZ68cQrYhHYR/so0PCBxYgTGzVw0fyCMyHjZZ+AWzF2gd/IwPwoKVZCs1ob0bvM8hVaGtBJlaM faTP4h/CDoz9BR2ip+lpy7oM49ZzDyF0SB5BPY+3HV6A98kp9Lkf9qLtOLzFn8LI+2AQLpLZKL3k QzJGQ6glfHyMsw699+F8fwHvwV9JHqkiCXISfXLoA9ZcxGhx9DmD8pYVhcstpJNsIBvJQxhzlDK6 EKNuoLtpPzXpaRaRquQRJUepUDsxCgGKpzcbM+TRvg+NOHIz3DsZVchvCSUNpIm0k0dIP87hDBlD +ZJ66DJcdS4/ZVHJIX0sr5OfQhlRVqpPaArGlkGBQtChCG7ArPw4RgPOuRXuhvssuR9lK67lj2A/ 9MMBOAQpOAG/5GPCOXgfLuLqZKHwvCrIIrIKJYKykWwjO3A9eq+QPeRxMkRO4PzeIO/QmZi1kE7M XsxyO32MHqNv0F/TD+go/YR+wYDZ2BrWzDaxg+wwe5O9KdVK/dIB6bx0Xiayaa1UjpKn3Kn0ovSp NnWdukP9sfqE+rJ9LszAvEoxr3pYhVn1YCZbYTckrF1LoRyDl1BG4BOeB0p6PBMui4iPBMhKlAhZ TaJkPdlEtkxm9Ax5lgyQY5jLOyjvknPkT+Qv5DNLLlKF5tOSyfxCtJGuouvoI/RR+jh9Hk/kED1J 36XvY46j9ALmmMFy2HR2DfOzAEoTu51tYdvZIDvNzrEx3DeHdJNUJa2U7sTcz0qj0se4k1RmcpG8 UF6M0i7fI2+Te+Un8USPyWOKw1qVHCVXWaLsUvYrQ8p7yiV1upqvzkKZq5arjWqn2q0eVkfVj7Qj tuW2DttGeykchnnwytdu70t4ul+ldyplUEjO4Wm4l2Whl87vHnWonbYOOsRnpzaS2bhTf4CLzAZB 6SysYrdDp9zMMtRPYYBskh4gz7MAHIGDajc5yaJsjB2Ui5QlYj3pY+yw2qNG1Y9wpl+yvXK7Opcs l3vJAF2GN3ojaYCvyAX4AY68mc6Bs/AQ7CbdoME+7QjJxLt2hs4kvfJT7KjUz/zyNnI97qBLHmE7 YSFMBwfMhll41mXIQ4C3orLihgXzy+eVzfWUlsy5fvZ1xUXXGrPc+sxrrr7KVfi9ghn50/Nyc7Kd WdMyHRl2m6YqssQogVK/EYjqZnHUlIqN2loP7xsxVMSuUERNHVWBqT6mHrXc9KmeXvRc+zVPr/D0 TnoSp74UlnpKdb+hm7/xGfowWd0QxvYenxHRzTGrfYvVloqtTiZ23G58QvcXtPt0k0R1vxnobk/4 oz6Ml8qw1xg1bXZPKaTsGdjMwJYZMLpSJFBFrAYN+BenKGiZOCuz3vD5zTrDx6dgsiJ/rNUMNYT9 PpfbHfGUmqSmxWg2wag2s0osF6ixhjGVGlO1htE7eDrQq6dKTyX6hp3QHC1xtBqtsTvCJotF+BjZ JebNhs+8+b7RAk/pMHm2KWzaaoYJNIWPQ306nqqL+3wRPlpOTXiX5T4D3WfcN+piCX9Bh867icQu 3exvCF9pdfM6EsGgntLgirAbZ234+3SexoqwlQEGJQVlOEmu42mKhNsMP9dE79ZNm1FttCfujuJm FSZMWNHjPlpY7z2e/iPU+/VEU9hwm8tcRiTmuyqVB4kVPUN1Xr1uqsVTmnJmi5VOTcsabzgyr2y0 TdqsluXOWzjriaUmfEZGHR4RU2/RcSZhw6RFlbxqq4RESyW6YYkQXNEOXL9owrmYb4Rc5DT0xAXA g2CMfTpVExvXKEXOC8Cb/LhMHjm0T7TNkhJzzhx+UtQa3FqcWZXVX+gp7TaDRpdTN4O4ZBAK40OR xWW45G433+XeYS80Y8eMN4RFX4dm11HwlpVETBrlllMTlukruSU+YZl8PGrgcT4G/AfddFMrnvxk OfNz/e2LTZL/DeY2Ycfr49dTklyUCIWLY4leV3E00RfBrQngVUwkAoYeSEQTseF0vNnQnUYiFQwm uvzRiZSG06d6Xaa3L9JOcFHNBWI1zNyaMHPRiGhRF4t4gM9DLb8cAsjA33rpN+0fWDO7suywNH8m DiiDPTAN38RObC3CRz9Np/l73+uAQABdcrI1b60+TG88WjsfabtF5Iig5wUdEjQg6DlBTws6IGi/ oDpBtYJuFlQtyCuoStBSQYsEKYIkQUwQ8d6KfB5xDvF7xO8QryJeRryEeBExiDiCGEA8h9iPeBLx BKIPsR3RglhjxXxRhB4UdFjQs4IOCnpG0JOCfIKWC7pJUKUgVZAsiAoCrxf5PcQ7iBHE64iziDOI VxDHEEOIFxD9iJ8gehCttfPzbHm2iuQw6fbWqckDanKvmtyjJjeoyU41uVZNtqnJO9TkajUZUZNh 9VptlqZr12hXaYVagZav5Wk5mlObpjk0u6ZpiiZpVMNXmJnLgjTYWE2C5qkWCDbr5leNxjCxN6w2 ZaOamDlBCDZVF5iVJSbdbX0jDpN0ipCHd7r4l+FxICS9c49rnCMRyC/511IwpRcM9ZyEmaQCVKwX DKkzX1O5thG1SUub5NqkpS0gR0MwPxjrjV4N/ybwPwv5RusUT38HTzcUTmlQHam5Q/AQzbBjPlGX O1Kd7+yqspJb4i7Y5johAf70z8DvBAe+ZDIR3ORZ7lnOTfj3ipum8ffPuKlg2xK36wQZGDc5UZ2N S4m3LI7/neL4q59hkoY3S32bSG+Tp/EPXhrkNDtOPgQouzzmHINln2FdPm9Btju7yJ3tjjO4FKdw GeSRv1fGpRF+xwfJSXpJcmCsvJ8DoRV4WxlpwQBj+Cmfl4uPDtIQOoUumfzOF38nKFXfauGFjn+b 5+HOYyGFCAUb2//Hf9Df9iLhb2xeS3x9Pif4HhuvsY830VofAjm4fhRbCtgAVnXcc1crYpP1ziRJ /uv8vyza1O7n8Hl6ioJMTAri3+E7cLBDMCju7DcUfm5oHFLmiyfWZC29oLnEQTs4uPcy59Qb6tsA l0P2D9Ry7Domztk/AJ+WFd4KZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iago8PC9MZW5ndGggMTQ2 OT4+c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3pr YzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+Cjx4OnhtcG1ldGEgeG1sbnM6 eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdv cmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIy LXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4K PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0 ZDMyNDJkMCcgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6UHJv ZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA4LjU0Jy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PScwMjkzMWRlOS1hNjA5LTExZGQtMDAwMC1lOGJiNGQzMjQyZDAnIHhtbG5zOnhhcD0naHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOk1vZGlmeURhdGU9JzIwMDgtMTAtMjYnIHhhcDpD cmVhdGVEYXRlPScyMDA4LTEwLTI2Jz48eGFwOkNyZWF0b3JUb29sPkdQTCBHaG9zdHNjcmlwdCA4 LjU0IFBERiBXcml0ZXI8L3hhcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0ZDMyNDJk MCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRv Y3VtZW50SUQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0ZDMyNDJkMCcvPgo8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0nMDI5MzFkZTktYTYwOS0xMWRkLTAwMDAtZThiYjRkMzI0MmQw JyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0n YXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1k ZWZhdWx0Jz5cMzc2XDM3N1wwMDBuXDAwMG9cMDAwdFwwMDBlXDAwMFZcMDAwT1wwMDBTXDAwMHBc MDAwYVwwMDBjXDAwMGVcMDAwaVwwMDBSXDAwME9cMDAwRFwwMDBTXDAwMC1cMDAwdlwwMDAxXDAw MC5cMDAwMDwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2Vx PjxyZGY6bGk+XDM3NlwzNzdcMDAwQVwwMDBuXDAwMGRcMDAwclwwMDBlPC9yZGY6bGk+PC9yZGY6 U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0 YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVu ZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC41NCkK L0NyZWF0aW9uRGF0ZShEOjIwMDgxMDI2MjMyOTA1KzAxJzAwJykKL01vZERhdGUoRDoyMDA4MTAy NjIzMjkwNSkKL1RpdGxlKFwzNzZcMzc3XDAwMG5cMDAwb1wwMDB0XDAwMGVcMDAwVlwwMDBPXDAw MFNcMDAwcFwwMDBhXDAwMGNcMDAwZVwwMDBpXDAwMFJcMDAwT1wwMDBEXDAwMFNcMDAwLVwwMDB2 XDAwMDFcMDAwLlwwMDAwKQovQ3JlYXRvcihcMzc2XDM3N1wwMDBQXDAwMERcMDAwRlwwMDBDXDAw MHJcMDAwZVwwMDBhXDAwMHRcMDAwb1wwMDByXDAwMCBcMDAwVlwwMDBlXDAwMHJcMDAwc1wwMDBp XDAwMG9cMDAwblwwMDAgXDAwMDBcMDAwLlwwMDA5XDAwMC5cMDAwMykKL0F1dGhvcihcMzc2XDM3 N1wwMDBBXDAwMG5cMDAwZFwwMDByXDAwMGUpCi9LZXl3b3JkcygpCi9TdWJqZWN0KCk+PmVuZG9i agp4cmVmCjAgNzQKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDI0NzI0IDAwMDAwIG4gCjAwMDAx NjA0MTMgMDAwMDAgbiAKMDAwMDAyNDYwMCAwMDAwMCBuIAowMDAwMDIzMTExIDAwMDAwIG4gCjAw MDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMzAxNSAwMDAwMCBuIAowMDAwMDI0ODE5IDAwMDAwIG4g CjAwMDAxNTU3NDggMDAwMDAgbiAKMDAwMDE1NTk5OSAwMDAwMCBuIAowMDAwMTU1MjcxIDAwMDAw IG4gCjAwMDAxNTUzNDQgMDAwMDAgbiAKMDAwMDAyNDc4OSAwMDAwMCBuIAowMDAwMDMyNjM3IDAw MDAwIG4gCjAwMDAwMjMyNzcgMDAwMDAgbiAKMDAwMDAwMzAzNSAwMDAwMCBuIAowMDAwMDA3MDg5 IDAwMDAwIG4gCjAwMDAxNTU5MzIgMDAwMDAgbiAKMDAwMDAzMjY5OCAwMDAwMCBuIAowMDAwMDIz NDIxIDAwMDAwIG4gCjAwMDAwMDcxMTAgMDAwMDAgbiAKMDAwMDAwOTk0NyAwMDAwMCBuIAowMDAw MDMyNzYxIDAwMDAwIG4gCjAwMDAwMzM2MDUgMDAwMDAgbiAKMDAwMDAzMzU0MSAwMDAwMCBuIAow MDAwMDMzNTczIDAwMDAwIG4gCjAwMDAwNDE2NjQgMDAwMDAgbiAKMDAwMDAyMzYxNiAwMDAwMCBu IAowMDAwMDA5OTY4IDAwMDAwIG4gCjAwMDAwMTQ0ODUgMDAwMDAgbiAKMDAwMDA0MTcxNiAwMDAw MCBuIAowMDAwMDIzNzYwIDAwMDAwIG4gCjAwMDAwMTQ1MDYgMDAwMDAgbiAKMDAwMDAxNTk4NyAw MDAwMCBuIAowMDAwMDczMzEzIDAwMDAwIG4gCjAwMDAwNTY3MTMgMDAwMDAgbiAKMDAwMDA0MTgy MCAwMDAwMCBuIAowMDAwMDQxNzY2IDAwMDAwIG4gCjAwMDAwNzM2MDcgMDAwMDAgbiAKMDAwMDAy MzkzNiAwMDAwMCBuIAowMDAwMDE2MDA4IDAwMDAwIG4gCjAwMDAwMTY2MzIgMDAwMDAgbiAKMDAw MDA5MDEyNCAwMDAwMCBuIAowMDAwMDg5ODg0IDAwMDAwIG4gCjAwMDAwODE1MzMgMDAwMDAgbiAK MDAwMDA4MTI5MSAwMDAwMCBuIAowMDAwMDczNzI0IDAwMDAwIG4gCjAwMDAwNzM2NDggMDAwMDAg biAKMDAwMDExMDA4MiAwMDAwMCBuIAowMDAwMDI0MTEyIDAwMDAwIG4gCjAwMDAwMTY2NTIgMDAw MDAgbiAKMDAwMDAxNzQ4NiAwMDAwMCBuIAowMDAwMTMwMzcxIDAwMDAwIG4gCjAwMDAxMTAxNTUg MDAwMDAgbiAKMDAwMDExMDExMiAwMDAwMCBuIAowMDAwMTQzMzU3IDAwMDAwIG4gCjAwMDAwMjQy ODAgMDAwMDAgbiAKMDAwMDAxNzUwNiAwMDAwMCBuIAowMDAwMDIwMTExIDAwMDAwIG4gCjAwMDAx NTU1MTAgMDAwMDAgbiAKMDAwMDE1NjA3NSAwMDAwMCBuIAowMDAwMTU0ODgyIDAwMDAwIG4gCjAw MDAxNDM0NDEgMDAwMDAgbiAKMDAwMDE0MzM5OCAwMDAwMCBuIAowMDAwMTU1MTY3IDAwMDAwIG4g CjAwMDAwMjQ0NTYgMDAwMDAgbiAKMDAwMDAyMDEzMiAwMDAwMCBuIAowMDAwMDIzMDkwIDAwMDAw IG4gCjAwMDAxNTUyMTkgMDAwMDAgbiAKMDAwMDE1NjI3MiAwMDAwMCBuIAowMDAwMTU1NDMwIDAw MDAwIG4gCjAwMDAxNTU2NjAgMDAwMDAgbiAKMDAwMDE1NTgyOCAwMDAwMCBuIAowMDAwMTU4ODk0 IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgNzQgL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lE IFs8RTlEOEM4OUFEQjZCNTk3NkQyNTE0REFBOUM4MEVGNUI+PEU5RDhDODlBREI2QjU5NzZEMjUx NERBQTlDODBFRjVCPl0KPj4Kc3RhcnR4cmVmCjE2MDg1NgolJUVPRgo= --=_201c2at93vy8-- From grid-bounces@ivoa.net Sun Oct 26 23:41:34 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 3E5231AC002 for ; Sun, 26 Oct 2008 23:41:34 +0100 (CET) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m9QMfamL000560 for ; Sun, 26 Oct 2008 23:41:36 +0100 (MET) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 9DAA9ECA37A; Sun, 26 Oct 2008 23:41:36 +0100 (CET) X-Original-To: grid@pat.hq.eso.org Delivered-To: grid@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 7B850EC8141; Sun, 26 Oct 2008 23:41:33 +0100 (CET) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m9QMfXxm000551; Sun, 26 Oct 2008 23:41:33 +0100 (MET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwEABePBEmCT8iYZmdsb2JhbACGaowJgQcNCwgIEqpFg08 X-IronPort-AV: E=Sophos;i="4.33,489,1220220000"; d="pdf'?scan'208";a="11852542" Received: from mailhost.u-strasbg.fr ([130.79.200.152]) by clavius.hq.eso.org with ESMTP; 26 Oct 2008 23:37:00 +0100 Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m9QMfROk070908 ; Sun, 26 Oct 2008 23:41:27 +0100 (CET) Received: from localhost (www-data@astron [130.79.128.15]) by newb6.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id XAA24643; Sun, 26 Oct 2008 23:41:09 +0100 (MET) Received: from 72.4.254.58 ([72.4.254.58]) by astron.u-strasbg.fr (Horde MIME library) with HTTP; Sun, 26 Oct 2008 23:39:07 +0100 Message-ID: <20081026233907.1ide941oua0448k4@astron.u-strasbg.fr> Date: Sun, 26 Oct 2008 23:39:07 +0100 From: schaaff@newb6.u-strasbg.fr To: interop@ivoa.net, grid@ivoa.net, vospace@ivoa.net Subject: last version of the VOSpace-iRODS note MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_201c2at93vy8" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-MailScanner-Astro: Message analyse non infecte par sophos sur astro.u-strasbg.fr X-MailScanner-SpamCheck: ORDB-RBL X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [130.79.200.152]); Sun, 26 Oct 2008 23:41:28 +0100 (CET) X-Virus-Scanned: ClamAV 0.94/8497/Sun Oct 26 22:30:29 2008 on mr2.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mr2.u-strasbg.fr X-BeenThere: grid@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Grid and Web Services Working Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: grid-bounces@ivoa.net This message is in MIME format. --=_201c2at93vy8 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The final note concerning the VOSpace-iRODS implementation. Andr=E9 --=_201c2at93vy8 Content-Type: application/pdf; name="noteVOSpaceiRODS-v1.0.pdf" Content-Disposition: attachment; filename="noteVOSpaceiRODS-v1.0.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nMVa3XJctw2+36c4d92TmaVJ8D93buxJ3ck0ibPjXDi5WGtXllJ5JevHbp6j fcm+RQCeQxLUUpZV200zTbk8AIi/DwCpvh2kUDBI+icvjt4s3g4qgE2/lIQweIgiRjdYJZ1wnkge PffDk/PFjws5fIv/fb14uwhC038SG18fvRn+ukaGMCiF3DEM6+OFRIHR6PmQQZPgwSkQ+PXNYjmM 698WT9dJvhTagrQKF05pCGp4/m13+/JjtIiD0sI5a6sWkJUAKQJaiwTBkBovUY+VFsoZqZfPxl/X f0cBSnIJXrhgDJmx3iL9fkQbwbiwvK6cu3HlhAYb1fJyXNEZymmPtCCMk0YvNz2uU+IyRoe4PC+U nCevzkYAEFIq0m/22WeJSYzkh+qOPzUq6GZh3UFUhtEKB6Chv/lidM734gZGgDUqx405+3L0Ikrj FQUDvROtNMubEqH/g9+9Ec4wg/9cv1uLXn2o37/vggWsCKpg5VXx5NW4isJJHwGxkh3NofIurUFZ b1kAGFgqQmr4fh+tlCU2bxfaqDhYa1IJe4M/XSg/z+afmAH5JxGXnyeLn4f9Z4qvUVIAdyyLL+kJ zpvBkvuTnuAxC/LPs/mnivlnIi4/Jz0/S9wpWFMxftyod5/oNuS3ZGspPDDZLwlFQhswlq1Oy2pT S2ctfUcsG3ajte5/ACBpeTcCXRSmcUGK0K2wasxTFfSUzhPFCoIVBL4VaOFd/YAeMVhDv6Off5n+ 9UXwrNSgorDSQjXLuNmsgM2KMh71nnz/FF2qIgD1ohVVG3BAzQjZ8HQEaNk8G0kWtgLqS14oC95R sxM2aqmWrzOlR9MK5YZ2lQOlcDcxJXwqPNNahZjN7K/K6qasrirz9eiEtwB2Fo7F4QVBPzqIEUsN JkvEOWX502SOM8uLImbWQWmHaUOGGbR2VzerYsco20bn8Pt5NfySltHJZANGUUs0vDl9RZE2TmXl dACmcTUShSLwPU5WszcT5VVRirFvxiCUidiMWFy2dTmM4EPuPNiDNFBqrb96yb22K3EsNgAWUmXQ BhMwjCVOR4VyV9knxZKHPnN/m9IQv8svPVXcjwaDhTN3tzmqGm1mfqB+olFbnT2CbmK+q/Hd1/jO mRLUUlVBojLJ1repHHvBtVSq0dLNgH02rkDE4I1HbUEAGCyMKQUhAMp7nLDgEwxnSrf8R9kkZdGL NmKCGiF1lGQq1lIfDFQWv4SyKceVFdGbSFp74bXyfhnmz1pxplkPBDdmVOavB52TpCBlhIR3mUC3 KzIxSYMwFJ8s0znNFLH8zC+RkTj9UdEvGdkp2VNGVTEU5QK9NUELKwEsT8hSH61LQzwO0drbgOlD fdVIXA51990IigbPSDkXMU7oFvIFHqK9SzBUNOO4LAr7HrrSoKoGPbmfj8L8+zpBG1OiZFUYcKqi 5lvTKnCLsWqmpMujnaZpx1DOKkx57ylnsf0GrzxFP+1iAJYrWhplFSVKoZXdZSD9JaAAEoulEr3O vzMBtpBmA1pv94KmsQ7Og8R3k1MgYvksnr4mA0B7badEn3avOAHmpwHrc1DIv++K02cmF1wblLJL pcAY5ZWdEnyKxaeFxTkRD8NyUj11XcNCd5SIVxkchS5GHDqM0gHPLN8f4UhulUFFHtXN94Q1zD5s Je9HnNXAK75iUT+lUQudjldc9Ar2Hy9t6o9ZlU03WfZ1d9dV+1FV+0k5l4nFEc/TXQFT7GZKi7B8 QwECLbWZbgm0t2+kJ5ERw0ONkmrOo7J3RhzGgOYazwppMFzNyn6dnIdd/JPlZHYGnXeTic7Fas5l /XxVP5+WM89TCoHFnHOuvjn0kLnvxmj2oQo2H/owuOHwKGe8/UBSVcTelKHhYihVDKFRS9sEEtBG c5DclCrG8ES1H1uyCi0K8+pyupIrzJu7QNgpjb8s5zIQAyuov4x19+upDJjw8Sg109x1C6UP8CXE ud+8pL6NHc9ZemhYKSckXvJ47Topte28rFg9au0rbmkNfHAZwpHEHxr4mI4NgI16euyitN3WBGMZ /N+6O1Tk/1T5GchPutnKlse1YBwnVGKV5GIZKcv87YEKIOPym1Jxfh/R2alRo97ghAo4JVW4nbHq x876YcRBzxLXrva0q2pMvxxkYdrDHAN66QhlwviIEQXih0aUaSASWtHTLWIQCwIGFGcqUHiLxYHZ azkAAJ2BSMbpW+nhcrc4/mpBrwfWhzRf4z3BOlrQ/+rKpxMf4D/Ec9cmlE08QeZ9MtxqPA4XOPYM lKLOq0jS0dFwKOnDGvV5Zvtg2owfffQBx/3OmF5j4GPs6zJMjpo2uaOyRi11f/fT514rA5VzvDHP VX1+xTCQLjIDXWhoEtl+6UsaAlpTJpf3oqYS4c2G/jgxV0rSSUmPlwhKcunSzQznGWwvMrVij8Y4 IEgDig3SUHHI39PbEea+9zT7oaZGy6i/0JUCqJT38Er3hRe1f36PtyApbXRTdZw2L+qQuik96ygV nIgli4+mWJtwJIhUHF/WVqgrwa91l9GepssptupUvbCOYY4HTnBd2U6qsNqNqSYqajAGb6aF9MUY 0WqLfaHa9Xi2K/oqP6KyZeSOReikK9VpRvk+VVdvLXXARKlp7KCmrWH5z0l7lwJZeI75hYm013R5 LEyM8sDORLkrBzHSLf9eluwo5tR9JWC715TBHlODNrEpY5V2zKj9NOIhJJWJecRjClTK4zoqsZht mKQUMhU4e1895oBdx1XMvE39fDQ6eo+KkfPgUYbKlHdc6HlDkHXZ9Bz8rsaS+aeowoTeFHam1Fm1 L6sSOuFxyhBpEu/aUIMPFIFVDsFqRi3F4WqGn6PRATxWJV2w44of06DLrptp6I52nliU1ogEn2+p Lk3KBX0bft/P1jOjGNerQsq+t1Uhn3UAhflGS06l9xpG+iJN2IYejib4Yqqm7/Q84j1T8KI+WFxw VbLWLNWOalBr0Fko70BCiepVA/DWg4mA0W6bXMu0TEIvw9usyxly1GW6SnmvYHrSK2U1wdYbimOG 7bPq9mtOWrTaFmMfUkwOdCEMMqnnU2CcidOIng7AwAAphze/NPWmOwSL6wdroGl8yaK1Z9EsWj+0 hFjbVpCCwNmbHIHsbWdfl9vmbQ2HEAogXQTyXfS8JCjTk5Gy3abTtfdSovW8Vx6UuPxSlK9dDK6v 7+iggNOP0f4w1omU+a3ClUntK1NJb/jokJO5KaIlV0qsdqVxNAleHLCe76jIc1Liz5KiScps3nkX rG3nyAfcJ+vmDuBPEPTCRp8huDucFpigg7AfNn4Ai17zt71zuyxdVD/2Lb06qDAU6Vc9/52NNO8q aBzBYtbgN/uMnXrcpnixtQ/wLvAmH3Lg/bs8lLJ+18yoZXlUCXKm11Ex8L5R87QClDVD5qhtZWpe gzLQ/lMktTmbD2Xz6b5BdSboz7qHI7IxmrPtizKsAByMU/kwr4SlP3a8p79lYzaZNteyUBaUf+WJ I+Ymqw1vshueQJ1ewaSyDLnpouJQu4nFRqPuGLanWRUVlGVWZeX9FQdFPpGB9/ogVKaNQ2HfdS1i JrMZq+un3fwYqTnljiO1M5ZsuqqyU/tQb3zOpnUGyvx9U03kk+fkUA6/z3tbzE2/uS3WC9j016mg 27mvCGAA2nbFHsawxS2RWkwim0v53Mqo1Bswt5WdSWuJaH2ZT2XF8nnJ4MlZxi+flK3steku2nGF raGsl9G2rGSudXluZjX1tNTvW3PrzMTxVXGYSpnzBDA+0x0ax1tiwl/A+7bUGX9s/m3Sk2GJz3RV fr963Dcf9mgPhhYNHEsNAln5y+x3trKuLp0JmkFp9s29UFrXv9k+rd+/SZGiV4e/ldVQUoKljLnj rSWTXnSnQ9Yyfute4Y4KJJjJguOTrLz1/yn6cfEHGdX05GVuZHN0cmVhbQplbmRvYmoKNiAwIG9i agoyOTMwCmVuZG9iagoxNSAwIG9iago8PC9MZW5ndGggMTYgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJy9XEmX3EQSvvevqNtUzaOFck9xYzAzMM9spod584wPvZTdxu4FNzb0v59I SZnxpRTqqjI2cJFVuUTG+kVkqH9dtY3Sqzb9nx/Or47Sv4zTrVP04JXRUa2e/Et8/ebF0a9HsTHp v346Pp9frf5xcvTpE6VWyjXOWLs6eX7UNl3XWR37IWoVQ+NXQasm+NXJ1dHT9Y8b3ejolV7/tqF9 rGlbvT7dHMdGG9sqekt7BK3N+u3mONB20Zr13ea4bVxrQ4jrVXrWTnUqrG9oCdO1RO36+bCaDTaN CE0XlXLrEx5wyY8vecDSyo82x7Zx9FrjJucwOpPn9fqKRigTgtPr7TDCRGPX1zwxn7UztMuzk38f fXly9AOxPLF9Hx7HlVKND11kFhtXsbglFuuBxScb29hoddefOUbbupjObBvlInGbzmyaoLxRREzb WEuc75miaJ4JHQ3wjfOGTkYs6ZpoolYkIyJBeevzpLZbf0vCpNVd1zOJdvLR92e1VgXi7nZ4q+K6 4ZcrfjzZHLsmdI7kflmW3/JSMPQ5U5IppQFv6KitVV0SpPJNJLJo/zIS5vNIWP/1yBSf3ub9T/l3 4pQyxG3n8+/G4qLDqYl7CumDAUDLZVkA6B84rbsOJ13wqrDBeRn6ll9epfU7ZzwSeM2//4ZsT3qn HZ3HJuU6uSBV+b0XIJnNeOp+EhLVkx+iWWv+vRUfY5E1HOUbpg82uB9kZTzql0qPpvO2W9tRFqpW m0T/cT5AEkzyOOkUX7MWX7PG09q0RtOarJL9gKxni/o+zAnrd4OVOB9RY1Dh0iSrK3neFC26Ri0u i/5eDGYL5lR+vkJ25d9fTQlxnVX9LGJFcAEVFtYSFf5WVK1hqJmYTlnptGgWKDkMZc0rC8FsUByg +VbY/UbU25GlxDLaUpOjVbFoELm4W1YbNNFe14Mjqfis6yCm6zIy+8LO4J6gq+Ai4PFUJPUlD4Cz XC9YFrMXhma6LgSudeszPKzkem7motjWK42bAtWX4qKrjQ5xsLiRjWhxt2xmbzbHnmJ3MEVUifp+ SeIEOavx3Tmrcc2yHbYDHnzYqItgPK95/p4e3FYO+uf1uKqt7OR6PIBOZ6njHjj+fqjs+DUPaMsC LXM6FmJ+3gwUeIIaM3c3svzxEf37bwNoILRFGk3ILJh25bQ3hAtWhKg0QQS9erM9er4nplDtLlBB etTYAVN8URwXYIob8RHghRzKb5i513LUn+qzXWJzpcZlgcq35llzK6nV5zXZptJKBxTu4K99rGwb 1POFpBxFp0hTT/GsxbguJDDxhvVgy4qSsKXRXvsAxv1u1GpfOz3BDSzZObuJsungnJzDhW7LQHB+ gD/uRkdraGGbHS2c6X5GqPITlzoxf9qKQQlQwuIR/fh2IzhZMq3RCX7GQAbwd21KBNp7U2ot2YU6 xJJ2onPfBiJzsKQZZk42AwAF3VSidGqo2ve51OOjk78fCPUHFgwDROiTo+spOkI0yzzga5bwT7RW ozpLHv67TWja1nV+/Tm/pFkmpUE0C0+ezWaeLEw8ALz9IyvoLRuViHIYmt1x0KkMuFjCCzSfTOid BLVfiI/bHUiiim8Q5wsBFSTI/AVfNRzQBTTqq42idLKdCq2seT1aZWySzoxWWSOKPAuIYlsXLWwe qetUQzxIlSBBbCusFhOkrUgq4CQQi+zgBBw0yqeztg6zoNQAbonBQStfwaCBnQiDFi2NQnHjTcAB 1wvWXt6CqV1gLJPepi20blKlooLK1YCRBrCBSzYczi8qXCXtcDalpk9A2MgmWcM461baADwL57Mw H4z0nO1JNLJPKiHyrpDgCLPgEfY6wzDHeLICzuMGp8yBW7QdSGdKRL0Z7NB35Lx1tkPOps45OIq6 zxb1Sc1hY8i5BknJgdAqmxKNrFgLkCyzUsjw7pj4aiDUKxb8YWb6OzbImYCtNWh6IwfR9G7QcMYU IxEfbZMi0L6GN+T0RT85MEGM2e7Q5LPy+0uEk+Wg8BY4cV/sJ5EdbGMU1geAUeyNLmv77Cd5Qbwz PJ3XT9FaNTZYjxsMQm19h/SBjz2VzKMwO4yB3wawozvJeovyAH49FdUUVbvo5n2O/7X/zlR8PVqb alodsrVNfNPIBqDuUnIYcHaQ4yQnH9e6xgXkwlsh8WwhxOXfpaQd4mZlsvOR16LxwYB8gErlbmau q9O18Q0MXTC+qrRW3kJYGyjVbkG578Qy20r0GBAhZdwI9imGn+3CAg8n+5DDVe4JBgj5phgfeSRA QM4GTwUBY64Iixf5im76XAxzz3cFWjb0papWDfz6MNhbYyr2LKZWJP2Uv6yMDh+hSuEI53RjcnVc lE1+KqWq6nHHyPrnlGscs0otvBR/l552DNy15J/bZ3l1UryPt01yMJNt+ofi6aUfpVHShL5s1kUK cgVy/Ym9FBmx8v49qbRkae9xhP22kn7c993BP34QSvbj7+GyMh3FzvF+KIue8rV0593Lvy5HREV5 XCiBnRCinMaNsKsPhnlSVfeFCD8Gy/FWN12lx7YN5WKd/73fjfpDPk8ZvbLRNXGszEJd/S3EvGx9 WCARyq41PhpOGQ6s7+RZT+ByC9K8Qh4wD6qa8FhhGQiPAEQPuXYRsChQW9VLZhDJVPzAeipgbSnt wVQsT5+BlQqj9UsBLULBhXNl+WYK9qouj3tA3KkUqbMvhGhf3SODEARafkPo4dqW47xqKb63po/v OnTdyufovm9vw4Pabn0gGiuFh8OK0OW6EmGnmzYEPxYxptJimGsiyahzFcx9ztgWEO/bWckmPV5A EtpXlALiwjodmGdr8DuwmjHsZ/z7p/z7p/yWsbX01GykguQ70TShwAHTAHrLIBpoeTSpcGdtzynf kt493L8AVgx7NVmAkyq8VmOPA/H75JeZlpnGeNXVI6r5x5Ru0xiMI8O47OL/4hYq+mejRwP4PAWm TrW9/ue+qVf8CH1HN5tIqtjFdKlCWSY9t33kK31OW+houuB5L/gRR1ylnifXta5+PWyonPO50Sm1 YY2tVc6Zj9X0ZNvYtPE9mp5KCa1YLRhA1lTnIaBWjTbS7cgk4S/ri1WkHJIrY8zp4hbTTawR9Wv2 N6G5ZM0r3UiUAiGzi9JJwpiGWvJ8IaXpqXAce6c3T0dfVcE01wovsPQuFSQm9Y6RKjmelwFuvHZO V4GPytOPFfjIS4l3FmMfCMWAaEsE3HUlCovOWG00BJqZTkyPt9QedpBUxqGPkunFwOhqLBGXGuqo 615ZvJ+qgmEp6YwMSXpuRowMXIWSDsQ66Om43/RO0TgOsGtT1RsnwMlWWisjo6XSZR4qAlFoIPyS f+dmha/K/X1eiR6f8qaWt3pWKeCwa66uQOtX36eU5fPLrPukrr3A8YZYmpom4UzfcPg7FWXGfU4V 0wBBFAUWAdCrAhxlEDy7PJoi338PFhSJjdl+QP1mRKf2P8jX/rdRRJ53uu5YkO8M85bfFkt/KbG3 tqSgKH8MYX5jWveTAc6ASXDjx5vqstP3rFFGNKOeKwv3gXUjonZ0UAooj/ntfbl5L21Tk8t2S2wM leXcCDEEVt+jGyYP5chWFWCn1hoK3B3bZaH6n+njmqlc1j0vQQyWqq7kshIcdsU8nkQ2nMlt90jq nZj8yPd4cn9kdXE8p+BMnP92NKJkC0YIQ7AWsPBJUclyv1IHwf4ip8PzPS03RY53f4aeh2lm/gqF aBhZ9U2JaW7eHUIYBCNoK2LDGTixu6Mwa6TQVDa5Mp91b07fzqoEQn9LHbjn7X2INmoxpWDDYWkM 1paQbxEUbODrSw1sBB7Xh1lwBDZ6Fh+o9BmCML7KmmO43LWWMjzpdFVYkqok91UfawEzUmlENs+l uJQxKN44DrZD+X8sBV12BHXUEnAVYFgYwLZVRTNoC8rRTOzOBUqBVzcLzgPa+naA4AVbZLsZuIB2 c8gnHnLfSa5S1JmD9OEFmAXGnwe+dlhs7ORQAxYImRds9Vbq9oIqxQsp1FXYfFr3rO+3Kg2cXvrV ZbAqqsjHllF8DuAQX8AwxfaTeTC1/PnCUpPWCyRwaALT5MULdrtBGMV4fHqTOa2iSVwR7/orZ1X0 HjRc7PoRO1dlAsU7egxGeSFuIpWi1ivOm8TN5bRp5CWa39L1NxcDoekyW6ccMvK7Kr/N8fy/RDDt 3um0UO6EhS9Dxpfe4HmAb5DzKLYXU+zlGc/CTGWhB/2vr38ZYoTTuRedHGdUTuGnedf8OR7UoOoq lTQifwDoYj7vh65S6Y6I7O+nhwoiDW+tRy9OIhlqlAHX8o1vCQQ9UKTUpomdKYUNuLURL3iwWlRU 4AIdbZ60x7cagKAG9xpyucWQmZhMtpFPRujPP1R9tW1HJqCQR/qD8Og/xczuoOAm9Z0AD7iOX31O kiHCRz32wkoHHnsnXp06n3KhWh3Lvu+xTON93Tpr2Fs27EPVhlKOseu92iRV43WnH9iF1o5tKO3O X5UjQToArUBQmf0dhu5qip2ihkln+bxxl/XDp28Awl/FSY31h0L1Y6Tv4V5gwGW7v32R+op2K1pJ YHv+dOSdW/tn+TMzoIWVDjQgsfoIkRrqhKfoRqcfny19RfZOGloVeaYcNhWDSRl1MBWHS4eu+sim bBdMWVJAiFEA0fmiU/yeb+nyRbg9Xcz9xcglGfZCyRrQft2N2+cgonhFhF59NzsHppBtVah50s4J buXDmM2+UtUfzEFD8VWUpNzWOfuAYGiwPOB7UsgQ+nsut9SgfSn5t91+AArye8nvvcMCaaFNkLig TpU7hAhL65UKbbkxtpvYWO96cH9Mp3Y6pg+zhZeLAXjWhRRT0yVvshdhjvBwrCj7PHHGOtUOJRFK H2z/UVRC2q7/0xrHrmm9SQ0emdzXPbk+ucDXm67xXavSbBJRKqfAit/z49fDz6VJlVINsmz/ENsn J3ZtAvMHHniQhIuHimHRzBbEMOxwiAwyTT+RFgedGsG/6wNLZ1rXK7RtvHaaFDqTxwIgddbJHvpg RY+hjV1kCXzJbP+DR95W8kt39W0qmZXpb9Kj1l4lx5iHvqGnzg4tTnOxuf3FdgCDBplZV/5kzf5i MweKrWxyiOSAMtl6UKS+/zs3dkmihfuVSBUZleksrvnPtJOL7fCNyyg9ECSL7IukRqavT1yWlyBn eLwbNu0ro/tJPOwvcYm3C0hRL2vTwUARYsFWyqffYliDPhD+2KfEmvvyJ22qL7LLfPEz9rqxP2NK /IsrMygYPxTWfjpeOwHo60EDBM3q02MpgzrbaNIpa6uoLH78PfuWyoSMdG1LeqXjYefr6z4/HP0f WJltVmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKMzk4MgplbmRvYmoKMjAgMCBvYmoKPDwvTGVu Z3RoIDIxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicxVvbchy3EX3fr5i37FZl x4M7kLdITrmcSlVimfGLrAdquSQV8SJRomR9R/LBAWYA9MFMj5cuKxWpVBrO4NJo9OnLAfi+G3oh uyH9LQ+H283QfRf/XW3eb3yv0p/xAz4fbrtnZ5tvXvhOiN664Luzy83QhxC0MmML0QXfW905aXpl u7Pbzdbuzv4V+wiHnWxvB+XSqGcXm203NWmGlar3YRw1tni5fb6TvR6MCdv7XWwlrLbbu93Qe6+t t9vDzvbGaqm3N7u90L1W8eVjbflht1e9E8b67ZvdXvfCeGviSPvQq2BirzyU8FGWV2d/3Sgne1XE 8/wKlI0rXF/AXg+hF0F0e6F6radl/DlKJ3rtokzvsnTxYRIjSnyEtVXZLurLN7S2X+qCu9TSKy/F OHqcUsdB/xQXpLWIa44N6uO/d7oftAiGBAlVkCRSVeiRHkHNTxflLM6kvQ4SFf6RJLmhtzDVf0b5 pC7boAfZe+mzlsPv3wclp314sdu73jutVNX59nKS3hmPIj1UlfEqOZBpHdHe4mQhWPFVFyKHXioH BjW1+8vZ5odNwrIycjAiPlihpBfdi+/Y1w9PwbgQnTC9UWmiAvJxAQnk3vW2s8ZmjL/cit1+6M2g nUtbtzfC90KI7ffptTRS+TDqTIUhyhDtIGp/8MYl9co4iR90RGP9fkGPj/QYNe3j+vUgRkOyWkXz TeaVpogb7BKgXVyKt7LMFlWXdyAr6Wu4uGn1KvRyWvxPBLu/7+LCBhPs9kd6mWE1RMM6ryZyyCZi GqxlBDmvti8JLIoavEJc17aAxg+Axtr0IwHzukqwnDZ9/556sesCDwa9AOSADcA7i6hLGiArRukC KBtU7qS0EjgXjHrPNrioYy30IkNAZUyiqMZJvaYxH+tA0OdYX8KUH0joRrxkedLEVtKVSFbnPKeJ ruiRhu9peH5/Pja2EJ2DEL7ZClozr77rcVoT9GxVZahPtX+jSGF7r2VolVa6Q/w9pSnof8EpACS5 ry8vWa0sFrUYSjqfNmNfdgOjcpFJlYGil1E10Yg7trfJ8SqT92yE8hUXttuFFoB/qZgkdC4tKna/ TS+DUdbG3Z8DfQqre9O7YAYBeRDo6Ta5PWmldVHUmkG8HWc1ZgXya/5Lit4ZV/KDqEWw2F9F6eS+ 6viKGvDu65EagHnAbIDJNftizP/ulPu4nlRkYxLE2urDhF/n+xQIMn6P1Omcs3roD0kOiHWJO09p Z335eSdkb71WrVAqBbS4wDu0b0b+i2bVRS2gzDu2AeziJWkIHsEFHBZ+wSLYYIKPOzH0TgqLCMz6 /N8hUPaDcw2ajhh3S752TQg5Z3O7xpXWboCxmYse55UROiFlN9LHNLNULc8yxoJDCQEkoko4rEb7 PP7P2xJCIMkAfwJRMSvOuvVw02Aky5XT4yQ4bWtNagO440cywRrYGt+AsMqjPyOpo3wxmhgRt4jG fEsTHScEBtsH6RcR9OddtgttcPzltiVRYgMRs3BFWVgrVRO366Lu1yCe9wKtHvzCiucCb1DGuqsD XLFbsRbZoG0FVlYTAuuC4FLUMsgVuE16ldHlQ9PXNADV02BsTT0NIGLwCBGJvl+0ISmrtUlYoSiF UWkzuVpsrSwrL+FxzQaWcll0rufo5Wq3kuCLpYhj009k22SFoEOwMvrOG1EbPKqOZylriq/NAmjS EVo2VlK2JqeN65+FqexQMvZW3P3SX1mUGVzTASM9Cc3Fm3turlPQBjxeLPEuEeR33HeIHrA/v0yz at3kPThBRWPWLKKRiUgrCIUwF2WyInm56vkTQXLJQpCnVbAmzGP5VbSW7wBMPg6+pcc/NvtOI0B8 JdcBWKnfX9fv5yg2lMgzDOdtdyIGD6efsO1TS9fOXzfwHVc0QMCLkSbbfc8sVSeig8kvQRfX6Dhg AlrLhMb4sw8FjVRVNZneSiY3U3ubFX7iYvINQgx0cTKrLMoEx/QFa80iyulcO6OlUFhdHG8YXOWu 6OcnkVa/xtpoZxIOjR//G4mbH4nL+HbM1HSUCXKq55QGtZLGdchOe5sm66STnesejpvLr8ErGSdJ uJrbQUpc/QKF6wKkuI9Xxa0cCVzJPdrYVjlISJdkpbHoEx45wubAIRKGbzK70glodq4QfdhFHVXN OjV0iZVOihVChqLZr8PcSaliZk46BtE/zsPdKBz5LXDd0Kspq3jHU5oeuPQZEAiuu8kfS9O1rJ6h qGj8Gq6Lq4lfWw9WxAMfD9n/xAdoN8NHPjmA7sBWmjr7q6Y8Kk2pfGHT4MVGzEuWU6tv4jJ6LWHU SGjA+oB5yPq3Qpeqwydbzs54u09M+17HaiV2bM4SIEMu5kKhQ2KgryhNFHk0TeNUVGw9icAgOSdG NXQKlZyJdc+XiY7TEkMzT7zWwjVQ5RQ8jssHemjQSFOiAKUP4HQ+V08D3Z+QPnMR7Wppz2A6DdrK TE2xCswGF6Y/V9s+Z63seGICCn1IMk/UkUspOFFHZaDWm5QxXy9ipF4jtK6oKa9fQAHRuJBG8En5 Oy7jaBRc9gRkbUJ/EWUt9HN1a9bSCiFUQdVkz5Ae1+AIcfK0D+fS0NWyNBdSZNRQlcIGNeTSjBOe +o/Unmmqmxu2+gMB2SNIOrXlA8cKCVMHhdznRbX/hqWqTcG3C5pgmLv5tMAmtoybMYSc2+bN/Vs6 tPzD/+vM0gxqivySP7D8Z9Kl0an++wAtjm3reuB4gPfn8Mz1Nb5o4msfReqY0paMhgj8R8wUK31a GF9XuN0RLVB4Qls8rMCUoTDRBCyAALCj0JQM/xzzTogwhYdepWBKA8DYAwUxSkcnDIyHWnxO17Di ANIiK3tGgykVpB/VsV2B4zzBvzeRhYuHdY+aKr/J/3IUhJZw94N3CBeV73G+RqQmuMwPG1yT1tmV tK4IQJkqJFX8ESVIdcNytfesDk8r4+nHgXXQOzY40RkMKON59ZNMNtyccGQlY0D7B+0PW8NB7ALu p6gHODzA0m8LQjGddcExlwWUE/TdFUofrkVNV3+Ahi3E40OTRc44xvaKwSckZOvbRRYyi21NyGf4 Otjo9iymLAaOyxmWz85gV3q15FrRFhRTlOahfZfu7F0Dsr53QNxOmIw60JX1oXSUPT2BbIrKn4be 4Y4RTmeGHCSBIz2dGTIqZVW+5qmYUeF4EYcinE2Kw2rsJeHIEo5e0VtIx94tgRYjIATOK4xws1K1 Pe2/YqEIRs/fkLniAhCdIUBLNmq1Bx6rZClz4LF2l2Z+N+A3nJaDiiijXCEQ8v7z9wWQQFiED+fb bKP6BzJQ9orAbYZaTJiUWBZk/CEGX6QujryAjJ2d5T+BH5pfXFAtamabvnqZBgB8YAMprLClRWaD aa2W/MGcJEcMThrFWAex7JrAVImQRMU43Sth16/O1UuyUMZx53xtXjcN69q7cwUMPBvFApu9nAPB 7nK+w+tXQUEqisbtIQceY2WpGiaAgV3L/JcJztkt5l0/nBLACPd8RGFyX16FJ4A/Xq0eZC9FhSC/ a4YEbX1AaUskIo+BY7u8Jcl7vZKwl6aX3OWzG/akjb5T6H5DbOIaa1MQVBSCCGprs1G7LhC539R2 JYOs+MJrEU1BvlKGv++kG6ZfA5BS2M7JkIitTkgzJB7+cBurUKm6b+9T4993CBM/eR2r9CHx8OnX A+gG8w+b/wLUVwCQZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iagoyNzY1CmVuZG9iagoyOCAwIG9i ago8PC9MZW5ndGggMjkgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzNXFtz5cQR fvevOG85pyoWmtGMLo8QIIGiCth1bVLF8uDLsRdYX1h7Dfs7kh+cHml6+mupZXu32AR44CDNpdXT l68v4183deX8pk7/8o/Ty4P0f030dXT0o3WN793m2d/Nx28uDn496Ksm/TNOx9+nl5vPjg4+eebc xsUqNiFsjs4P6moYhuD7cYjb9F3Vbjrvqq7dHF0e/LBtdod1FevQdf12szuMrq+cc9uf0mMffdMP 22e7w1BFGuG33+5iVXdd7befy8PnO1/5vnUDLfDj0dcHXxwdfE/kp094Cr39xrmq7YZeyG2iIrcO Vab2aBeq0Ac/bF/t6qrvQx377X5HC7g2JPqHqm86ena/O2yqzrWNo9fjyLZvt29oeh3cELe30/vY 9ulTQ+Vi38btdVqgGaIP26u8aEur1lUIjgZvnSxVTXv13m1reQpjX8nTY/kJ+25khZOy2V4oyJ8V B6IFNiiT5GPgC1/Lx8BSx9NSTeD926HJs5pALDqTn/AFxBhH7G5o2auyALz/WtY6nvZqAxM7rvVW fh7Lzze7w7byTUuS805WgHX9ODYOgVk7ToOfvUnu8Sh8vmsTISQ9R2ckMEK4/Y13u0NPyuh6RwfG Q/fmUPW51tdcCBOuy1pXs7XoQPrtD3KKTt67MulH2RUO3CbgHp/qU/L1sP2UDtFVoSPZ+o5+Vm4I pClf4Qa+6xPnDpl1h66pkvFI/NuLml3Jz2P5yaKbJG+Ulm4QhWRp8260LaTckV4fF2nXgs3vl4Ib RsUhsoYhtiQ1viP7GcZFW0fcJ9v11hq5ByU+DGRGaSDo+Hm2F30Sv8OG7O3QOxT7u52rK7KWSd2Z obLSt7uuqus4tFnQZyYGvujGlBcRkjs5jmsZeidH/27XVrH1g1oKxPQWFYnpe4XqV0TzviylxJwn ncjIPSgEqPekZckPRNYy+NQzpI/n3+cjadWmr9Hwlqf2B56BaJe9fts5X7V9aPSZFa69siYBr+U9 zL8t/OFJMdhMm4668cz9IQR2Jq0L+E3KCIi6TTxEdTsRxWKBzgR7mo0ODp4qV2i5ohsReRHPaxl6 Jj9FjU7FUwHLgFGwwJW57eMO6gEPGUKj1ZcP9TdCG/St5BbBcb9WP5lCoOXEEkuxkieoKuArDalV kshEqbOeiHb4Hkh9NtIfaP5kP0JHWIofPRcTvUEfMemcI0DYsM5Vcx8SXJ8B2CEPFdGiN0c/MzL7 Y/HmsKFd2jZGgJsI39qmqwKDTfrQlr40Ud8Ql/yQQBU/TEa4Hwia+u0/kuVt6nY0XeSWfBySwiXW 9mSlzohPvuqTQv5GUtbXyYEfl4XejAwlGaKDg8Vp9hDIRN6mdXyYsB+TcZaOiAZGz5Oa7iMB2pYg Rwa0X4kag3/dZFTSRXS18PRcDAGLFmHySeF87BBmig8DHzcZueADmktRtxtRx78qKDLt34MSKosD WMpS7Xuhypg2Hmt5CgNuTOsBfvzdzrVVT2xER6X0dPzurvtAPeTZPwgvImC1wkD4kjXjXzjkzaeX abEhNm1b4KxS+lPx86bzukIzB+gAXBqLwLFJ4RlaLz10si+FVIAcwFX4gJtCIJjkvXUqxZG+fXSK FrAVgz1qu7jZuS1UbnZv/mQjPgKjpD8xMoZKAndWNOVsEa8F5U9HYEVS00XUtGtzAODeK1N/Th5w o2O4pHazItG9sXGHogAhmw1KL+ln41vfqmkaITBlpzNUOlFWThuU1ZQVe6XjEhbfmf516YonyeHt 4f1kRUOtB9yNitfQ/7mO9W4lNixzxNgophT64KmOJLJsfbobqrqPvmfLniYtTXMThHtKMo3vPBdl AVA6Ta8J0gDOutt5RxZwdBGsNvn7V2LBCQ835KjBP70WT/Q2i/IovwrHLlGkHQy6BO3JA6OnATTo ak9anWIcI1a8xwhQLTrO6pZCPIfBe7R4vJdSKUPtF1QnTwLiVo7uF6UXPEdOERIJx7aVh/OWLc1g yAh24JOOlTTzUlcg7YUS+SSYfzs5qYHgVF+iQRFW2B6WX2ggO09ZFZJUC8G/N1NYEFeLu6uM5bsx JSLOnTeV7Au45pxvHPz2M2NSt325nbYdfEPTCq/A+2TWJIFs/MSfXzHIs3IqZ+B96D9V3YzhGMu0 qEz+aIKac0EfZ3WA88wsqFIUWdRIkqY1u1A1rghaVKZ+4W7YHzElvVKT/PDvJYMyY29+D2hCBAEe Xpvnn+GgH3CpNbij5D9/YatUJS8wiUJH+vWZpNTS+0g8ijOpVmKfF4C9gHEg679kx0O22EFmheeD sItVMAHhy50wo1A44NhrTOjwtHPlT9mEXJT3bw1Tdgy6/j7emD8KXNMkqzEqJzTyAp0QaMwVaoyF 4iQeSjsOFCd2ClWAx7k1sx3iUgCWAPQC52EjIJUjYWQ9s0p9qOLQUSQIjh9CtolurXZt5bzznaaK H8IcrCso85Dfm+5BIxweem5+3zwFlmRrZvTz/BtDeCQBeiby+NaS7Qexw5hlH/1QpLi79ag7mblg HewEpKlcdgIIln2KUfF1pD3QP0thx3y9mtbin4WrAxJgQtCbNVdsCQBDHqWTBSSCT8tsRrXks2pc cU+on3a+4gIdoeHTRP3eLwM5g93jU4Wry2KmV1QLgNdiOH1uWro3OyKr8W5Y2hI/dDi/tdKaC6+G RkOf3yslX7zAjZW4L6q24NpcUlVYwmse7Q5j1Q2xVgH3HoHOrBzZeK1Kk1oSj/rAaqklmZliZy7s GqXKZ/ACqia3JMXeyizBQOZjD0pVPhpsnYIahnxdmwQAWVJYAPqBQ2+tUEAFhlZlITMcFRTgpe03 01cPRODAYA5rC22/KKZNUeaNpUAgwJCyUI63hE8X9qpGPVzWXzjYEWyeWSs9oVoAwjgxoLOdIQy9 UcfKbHu7IqFGSuYasdAyiQC7ZmMTuyVwWVQzSkJHpUmNSvQFhLdTAEdM9gNr6MJAaq2C6BmofyEI viRUIY0KLFPoVRwsw6NDw2ZhspaUz3e+c2vpWgm9po9a0QIBh+C7oJQGfgr0AdClXSBTjoyMQ3Qd pi7QzCYqM23fpALNX/4/9ZnQk799oD7jpQCz2cWq9U0zbL+ZqiWhbqHEggUYrtRcSVnlpzIbHl7I T1kdyjLPdo54mGzxt6XQ83kpDj1PbUpdS/z8WLWa0A5cvYK8wa2ITCktN1tdq+GnD9VqZlG2dkLS D1Fs6O8yFm2kYYPtnDwMvbLAFTRUzEs8HNDze1XiMTNvYI55kuoOACdoZXSe0B5gF3t4M53c4qdm qlmCjgv5WNvgwsEAELzO1ZqGCCpIB3O1PAeEaBFIznGOImAk0CluQhuRpCx0PWoaGuzwYhVTMrE/ WxxaDfWk28UI5mwhUwGUeZpSxplYi4k0iB9Ky5HdLXEK+eqSmb5BCQbEwnL7kxnzm+1BwFRQMcm+ raFDIxCw8xPKJS8zdUD/Keb1geflp8rfrSeKNVW2qNiNcit+++EiK7tFVWMtq+uGOC6yrtUdp6CD 5CQ0EHQs64lmehFUXWWCHql1mYmuChvMMjSfyPqfdGY83gkckrXOrQjB7gR+kWJAkibnoPv3eZL8 2sWE6xpHvnjsVJD5JIQ9aXioRys9Po79CIZTV7EbXMqXHhJxdeo5u0+hM51DynGWeW/SFoQxGzWL ON5VhAZcXGtLJuDQuzjWp2HfjwENyFiRej+xMZllFopkABcW/Ri5J1GC+6XOX6N1sErLi/7BtD4Y PVXkMszPY73KqjnTaOzQZXCDwCvb0kD/nm1prObZSrTSIRhgvosl+lsSob5LyMZZvVqQG9eJfB7w QvL/dqQjOQPuSO5i6Ug+XRS39Pbg1Btw6mwfdfKYf0I/7x0mcpa9zWDIzDTKiRWE7tG4WQeBoevD RX2wk+844a+AnJXPyBxE379QnuTciaIuhQvdrGdl7G0lS/JP+unp7H2HcnqCYjjNnw40H7LlcKGV admmsGxwYhhmO3fY9iiZwq4NPeoJBNywg118gLVWMJ/dHsuTAJ/+y+wX161RPM0juxndnc+1PuN6 KV/wL9A5k2qVuwCqe1d1wzyPPSndkKZKSRqllol+NGVh5N5OzVilLBoQwDQIYFBtJ3lskzw2vqLI usV9BSF9Y+7wcstxhY3KljW1wC7wkPmCSRF1VyZ7rEUrYQvxSO1ZOrFXyqiGzjPvMADk7HdTlxR4 5lmn5SFI/6xxJDRjDgwyj3uLQtAkswflwWpoaM1q6NqVmrLpampYqJ5n8YNaQNzYF8JAsFUZh+SS Z54EIgke06+EjEzK6aRI/Zh1YUWyO8FuLO0Grh2vo+vkqF7umIGVMmRMvypDrJQpM9Ggs1BmtNwL nN9pcYTLIvaTOvkzj1CpRIEgZQjgD56WDqlSb/RaZNk3m50Xa8nsWev7QhHgvX3dRjyZ0fe4QUGe X5qLa+UQCS3tiwpryCo/Uzlk4/Q+GCTyUBMkNvORdKZPug8ya43lFFFfxVgaC69mxI3XwzaoBdls T7P+FA39DcVtg+eg0ezoNzLGX8n7yzF/25KY3xDLOopJfZJdfr2X6Zcp+0shWDeJ7tizD8njuxTj 9X0dxxRamXVHsjPUsVP9/ddlq7yADxHIu5ZVz8v0jUyXNV/NLgrEfir/pZGhbnKa2zfeoNS1Y5Cr 7ymkPphzeC9p9NPyq/CESzZ/dDCbqiU+J7q/LMEs2/BuWLFdgLglx8Yl/AaTVR/SK9NuP8ECMzS7 8Xu7bH5fYMKyazK0nDdMI2F9tRTbMRvnA0y4sIKHVxZyVFnuyWR2CkOrO0qPx16Mfc3YyzRQH3zh jre6L5Cg7gskMP08fNbXUuST9+9xbVZjAl4VDLSZelOlRTDRZVsZanbWXpgRg4qeAKmtgILEJQQF Uz5hTE4Dll7VLNc0YzlaNAtgNyRychdC86QaOy+qckbG+0VwlNo0l9FR1Fh8NQJ23lcpgbdMb9C2 P6qkFw/l5tqk8XB32axECC48GsuudafE6VFgYbR5mLhCX4diXinqLHWDBMiXpaUYAOpUhCe77Evx COC1Rb0kb9Yq60aYmhpDx5p0O7/YxV8ivYV35vu1ezfYz56HnhQjujdVxYbSmQmoNdCkosJOM886 9fC2a13K8+RHlvnc+HusRTaHH3Z2E3NB7G2WVYbQYkZ3Ft6UzuJ5eLNs2MwEyqp2bQhMGQSlGEfq vttZbkVVmZaBFITET8DfxlYzQSkDWOaefnvsMoNpwkdN2CwuHqx909y9Bae5W97/Xj7K1qSbx5h2 hgkx/tJ/Cycf/isbEKf+B4rIsxb8YN0CbPlE4qyqK9nUiWkr7ZslGmUHAtAJ9W9ZaJ2qA3bWhUNY 9WcaHqsZzHLakDZZXjW3LkLc4QCjMQKG3j9y6/zY3Na+rKYK5NLJbWV+VG6Mh6rME7R6G73K8Ac2 lG35k7QWedeTr3sgUvTW3W+IFFUExQHYPH5K97ytmAmjw4cCwan3qLwn5Wqq2PdTA1q+Mm6GfxI9 vtj1VU3y1+YuJd8P3JvUtHFMS/EkiFMxvNM3zqfaLem4g9JtUKVbN3jCl8xbgrrkOseKc1dFsqCJ t/KQvqINfcqFpKKrq7up5kNmKRJJn+4crUiHO0LdPP2WhzZkbEnI+sYn4sc12xG08sjXZfnRRBH2 InGUNb9LNd3e1X2kkx1Hth8phnVdrGJOTHBq3c/gQcEx+dna9XQDEQO2Nf+0hR3hrqTPSsZyhjky 9uWgKc4u0Bvpb6AQkuprf+ynjIX7ofMLGUEFwypmsLtAIOrD8KFg1rFlM3q/2hAKYGKlvMLrqvLK SgI73zPkat9YtOL7tZ9Pl6ym9gUGDt+YW60n6/Mh2RfvH762awKnO01/loz369ky4rqVZHm5XZWZ gEAADkiivplYlbtvTbrbSIQ8oazKJMH6j5dVmblS9ZGWBeXuHvd83x/8F1y2UwxlbmRzdHJlYW0K ZW5kb2JqCjI5IDAgb2JqCjQ0NDUKZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAzMyAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nKVYS28cNwy+z6+YW2cCrKL345ikQdEggBN34R6M HDbrtddN7HVs59F/X0ojidTOGA0Q+yKTIsXXR3L8pedMyJ7H33LY3nTxL2UkNwIOVijpRX/6xyL5 /qr70nmm4k8Sp+ftTf9y3T0/FaIXEiR0v77sOAshaO3TDdF7x2zvpGZG9uub7nzQo2JBBq4HNq4c M0ZZM0hCFCxY7QXQVsIwwV0Y+nElLagwcjgbOXPcWTGcAJEZofXwV6XdgbQXXothM64MM957PWzx uJvesTKqTI97O7yu4j/wJmr6XC06RBnHOTfDPRjHpHGSqMw0Gwxo/7B+071ed+8hqjGyPxNG3wvB rAsew6hME0bumNdTGP8eVwrcD9KDBSAnLJgKTgXmlTN+2INT4AeH46byv4EQc8LYIyEFiQ/g4MUk ZCEoOzx+Gy0zVktNiZ/HlWbCeEjeIb6qgpEpaklrlK/Ei0osTzlXjbL0/TOIoGDaAfVkFI5JbwJk txJR/QYt2U5O2aCyfUqr5JWEmhfOQ34hLyJoq2OCy92sS+noitBMx1I4VCIk0zKpbMpw1Xo/asa1 klT9NYrfVnHi1Bt8c4OapqDKECixaAWpR6BqLSBZYBS9UNQSsW3VtU11Jz1UgdZQOOsLKJVdteoB TSHHRmm5ejvlz+qQq+LYwBugKmmljbmsd2/xLjHwCo87GiJ0th73lb+QTOBfTiXupYDAW2hqClJQ MmjF3FmtU1MBiEthMzBXJUIroSDKU5j+TBGX8GC0p+AInvaCueBinlPFc1mDN5kWJONQ0aU4c75S bT5U6Dwg9K4ROh8XAUVgVtXbeUUcX0CcLfOJgj0FOgFiubotsVMFEsC/iVEJ0K+b44GUDE1YUYUl RYBKTLleQh9R9VCLmyglkFh+tfG1rSgTdHO1qaiagyYdCVTWsNSOU7EQ+DB8qhaLy9WUqOSBxbgQ 4hm2qpPRMc61o+w1tB/tdZA0AIelRkYswQB+RaG7xSPRWjvdI1q/mIqLYxluA+0IVzQ/0vkJf1Mw I/yUnCK6wYF1i8cLPPaIT0Kd3oRJ3I4hUv+00kpKH5ucLaQfgUsUELWHOj4JsFGIFPXHih+SnhZ0 +fkG4At8Yt5t5ZP0oNI8vGCVaMfEEv6If7MG0VYCqY6vi/ndk5ImShd6exNpMoiq1PdRMg2vanAg oc9wJqUo8Pu3qcTs//cxbqEe6qPJdOU/Zd6c346eo/iqozWiXm1WotppmkUCt4scU5bUa56MmqCR PcXRBJz1P2WZjL+wlDuY2DrYXskYXNcrLngvlQTmrrt81sFG3k/be2SJJAZsAas4NO4kKAIsm/Fz 4Pmp0v3vB1D/c5fNdPnXl1oNrsKHgvKw2tu41k6erpRVjPvYHuA7xGMIckTexj9/69bPzuf90gSb FsZMvJtvwWm4gaYQjD2atMBlXLm0MOaN80eFNAH/LNGJSkC3iETywHxlPEZy1Xo1IQ22s1w0Aj4v Nv8jRHoSefUduvW2VuILDBZZtHHQkDn2qmIyKnWaKeGGc+R7hMKHpr+Wu09sl4loAr1J9gvSwD5V 1BOANkOpyD8mLCkOVtSeQVpai++nswKWzgLc9kQy6HALf1zs2U8tSsVm/CA5UO/Ixl70Z0O1EGW6 kOFvj9wrIzcHg268uWEaXMJcyEMgjdl92WjJd2WZTHRHbrZJgodSrk/NuNk0baDVFHGVIkOUxPbT /MO2GZ0vxhA7ivT0AfINiUW4CE3y/jkqtZXflnvhH+btnnDX8X8NLhgucNV7h2BEsBGEEpnGpHp0 ixCcNlTJQ54xeevKfbTtqmnMwBzQQU9dOh7KHBBckTlg89D4pRlguIfM9ELK/K+NPAPAXEioTzPA H03B991/pUHdW2VuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTQwOQplbmRvYmoKNDAgMCBvYmoK PDwvTGVuZ3RoIDQxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVRNbxMxEL37 V/iGXbFTe2b8xREVISEkaLo3xAFCUkCNQlI48O8Z7252XRGkSiWrSBP7zdd7L3vQDjxqV59TsN4p p1/L91YdVAaqn+Gijdc7/bJXl6usvYeYStb9VjkopTCFAeF1ThB1wgAUdb9TRtv+u/IEzLp/q/qL D6a3DJwZi/lqHeTMLmSzsVLSRxZ8VyBTkrM72zH4kB2aTwvy3kYIkZHNzxGa0UuWkw4++SDQsVI0 R2nk2Jdg1raTEUoJ8dQz5mi+TfVjkFJz/mYBrM+1+tXU7yIgCQ9t0ouhFLoiQ33s39TdCevu8vuZ etWra3XQFNxAv0aXSegqMlzUJP2F1yrG5YpRX+0r+ElyBJcgoWYOkBpBOhkQKGTdeQdREr+cU+q9 0Aa+sMgycokhmf0ixY9WvzlcoA2rwrUX2UkI2swE3tuOQG5jngSsrO0XKrf/EHgGNKfbB71Out4t YSPR8wWrz6atLILsEop5Z30CzBJd2S5BTkxkbhZezs+1eLS5P5kwlglKTH7icAib088jR8Qtcc0y f1m3Mtcc/rY+QmaKBtpdqx8XG44OPN6qRIIR/yGSdE0aS2TxFCd93KjthfK6PgI81KvJWp7zbFxJ dItxaTLuo8A8gp/+4mEmYU9jTEJ943QKUV43fnB6Y/TzDBQUBuX/gIR16kJnGCD001KF56UKEkRJ HJcKMwOPAMf/xQDFDINw7sHLd9j0Wv0BJO817GVuZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoKNTUy CmVuZG9iago1MCAwIG9iago8PC9MZW5ndGggNTEgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJytVdtOHDEMfZ+vyFszlSbETuwkj5QCUlUJla76gvqwYpdL1eWOyufXmZ1NAmwlpAJC Cie+HNvHmVtlDaCy+XdzOF11Vh3K33l320Xj8s940Z5PV+rTrNs5jgrAcEhRzc46a1JK3tFoASoG wyogGcdqtuq06me/uv1Z963L2RyhJZADg8MI6vhwK3z3FhYAClA8fGXhY8uCUzIOM4sT7XtnEibr temHYIgck8YGBJPYR9CuH4AM2JCE+oDsxRb1bg8SURhkcOP+ox+iiWAj6SMxNQTe6++9NcEGBn2T LYO1lvS8H8hQjNHr03VORr0spybmgRCJED3oywr+LuyWNdCeEDXeOtYXxee6prwewURB31efmvIu eyNxIsn+c/ZlM6J3kwBHNKGRADjjZVJfu9nHE72fs0Py7PVTPzgTgB1IlyQmCLbqh2SSlM7SRGuE OUeWLgzeAEVpyHKNQpTYVuJCgLHi0Z31mUxDlA3SsOb+oR4vatRl8WpMZbKC+iDoUR+M9DOxTLaQ vilO80zVJcI82bES4rg96EGeQ0hkx9luSpGqwBvvnlHZ61FG652fmDrv8nC3He97NsSYUtZGpsI+ yXS9EXds01/WRCtBHTJymPo7RnrV3xFtbCd+wuqq3j/krNFFhOZ+Ue9VvZ9vY/3sPgsRE4rYWZQ0 W8jiXrWhSjG77SyKwU0h8LqrAjYCMGNW2R4/yX/YpB0moS7ap+tWObLje6nQspP3TfSZWDkX5c0K +fXcOSZUn6+z8X8tD1nZYFQy/bo7g8f8RkYhJ7VWbmWn5N8P42JVta6LRemLaGit0UZik0JQngc1 LUugRoBPVcvzAr51LTPajPVPn5/pSNTKvpHNxbZlmW8N9VjRtYLoX0nnLy09+im+jY7avX2lMLSp FVhTYKPgRZFVs1hXBWyobFXlYwHPa8xnkQpqCqm1VMdhy+jzp20a/UakGPxaRl6+phuRgiOqInXv IVL5FIkOgaHRqEtCHd2oUY4vFuhb9xdvbLesZW5kc3RyZWFtCmVuZG9iago1MSAwIG9iago3NjIK ZW5kb2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nMVaTXMbxxGtXPEr9paFq7Da+dzZ3BzLSTmlimMa5QvtA0iApCJSoAmRivLr07O7M/0G 2xApp5xIl+V8d0/369c9+LVqG6WrNv5PH5d3i/iXcbp1ij68Mjqo6uyvYvPD9eLXRWhM/DdMx+/L u+rP68WrM6Uq5RpnrK3WV4u26fve6jAMUVXoGl91WjWdr9Z3i/PaLVdt41rbdaGuliunQqOUqn9c 6kYHr3S9gwGXy1VotLGtqh+Xq442D17XD0vVNtp3pn4bx2qnetXVH+KANrjO15+WXaO19Tbu0DV9 UMrV90uSr29JsnrPn7ewAq4GO3+aDuRCT+v9sv7b4tv14gfSV9TZSxQUKqUa3/WB9WNcoZ/WNpN6 viE92Na5vr6hQ4ZA34HOSwsoEodOqGxjTdfTAX3jvPFRYcNAH3wUt2+CCVoNMk6tV9xaUau1qiN9 fODPGx67m7Yq1trkxkce+YH7b3L/Ljaa3mlbv8+NMJIEsI1ywbuoYdPQ7j6k9Uloeeg+L/UeZc3n v4uzeme8n5RhrFGThnQfVTmcyts+bWXstNQwErY6jKfyvcFVx71029cXeT7sBKf+ONyfLfvhcxJA hfpPfP7Rql6duR4tRXWNo9NXK2Wa6FvbRf2H5fqfxwblaD/TRnuiEeeDxXsy406jsvbyteb+R7ws TWihwguuNQuQ7DJo4VpPDPXza1XhhCpWScjfrIv1kjYNttf1G5b6RzpLo/oRKPIJP2YXBLuQvQVm 3XMr6PXA2oBP3gG89GG58oQ4JEm9BXXkDX6ueQBr9mkZVdL3Lm1bGPSAb0kE6GcrvuXr2OXGn5ek LTJiXQJK6n446u1onzVBedP1jvDyTR4Y9asa21lf6lfpxgdrSv0eo4kpLuWS/XLH3jzpzNMFFybm Kdwp3SHyFcgTbYwCSOONSrbCwABH2UlHoYuI8msbUKVPfEBeCoy9uIjUf8HzoR/ggoEHgGnP/XvW xXu8vtFSbIKWle5M0xqL/lNF/5kiWfxPsb4ztFvvK2NaWqqrdCD9aNJk9bBbXH21oEBfjaQgdo2E groNBXhCynEicYcusoxXZ15Vr/e0/MsG63Hwfx9RLS2vbWV6S4QiBtVR0pWxim7VkApIe6wBUggd bv0m/vnHrI//MUGKZzMyQYqMRBuiHj8tKSB0lnzpLbQeYDTylwumOG+ZA51iOye40+/BdYwm5wmj qBMo64LsJAYShbeO7qyz9XejG5DJ13+PR6U2Y2qdUfAfDDQGI904352A2WsRsjnAgff+e+AS5PMY CgHR4150h663gM0FWZn6HQLR2ShLDATfk9pbusb6dSYQBXrm6eD8wGAKyMhinyAjCSfejee3pFXY AGjPoxQmylhOoviWuMKKkXiL8CfwKoByGHCPUBgNz6ieDDvjM1wGIx3gL4SCT0vlm8GsQKyPrGsh kr3jM8FJb0SgvYeggLc6HM8X11ItdRcGAE7SMACf13/J5r9j87/gz2SqxiXeHVs3oi1PMtshKHsV WwM5SB7aip99YaGO/NV1Be15Lw4ACvUpO8YeXSj7CMwaD04uosDHtsUG6eBMkDACQ7fAIG7FT9gf DHtz7AMjrxC22mBjWukezW6yIJ59YLfaSeEZHAjst3CrgZ90IWZ6yf5lvy/Uy6wi78qm/ihuBfML hpsXEJUCax1O6C+tCscu0tCVjbE/oFufZbQawVCrvkDDPkYoHcCpkopWUxCfcGK4+zbnP9FpKg4g H/iziDrS2J84QQBLG+9c9QVr5QwKHLQwxKzeUTzX++TsU6aQiDzn4LxTwfOFxHoPcwAIk3M2w+5t MIkRTjD0/6U92rlGj1TAy2Whb6ICHbVqkjA29WHM3CducwnTbpnnPPKII4KURkAJaFououjvQ3nI Z5p+khPM8yyDHBvE64nduDI3XWlN2RURtXO+cZdv/JecJMDIIvYmM4j9xtEROzAyOV0tAkqaBBix LzBe2PUuqlV7SrMwN56lOUNrUcARCjQlYqXTiLWcLaJQGnkPET97B0DTk0hJtjPSZAvAA7k3BSSn ba+RP0ifW5w2kB5KvJjzyDkfqPARgopcOIOgIeiluM9CgkmunbRAgirfZ9Qb+BcZjFPFFcpb3aBe Ja40KgGp0giE2nXZ7oJPVQyL7OiQy6KpkNU5oBs7tPXkFSWPLyPXvIB6xGeOuRGEDHZrcOaiTpSO dYmUYWjUxVnA7Y3g9o14Pi553cwMuQzSIrcG45MZS0m40gIbiecURT9NSU1M32QaM8OtWMCF/gO6 6ljH0Y1qQ/IZgJJ78azP0LxTUJL2v5TqPLIoF0ijpAFbBAVeSyZfaRIndbPypCW3RfJ2gv2BsWQm NSkRfW6eCNosvVFInlIdkD7nJNsW+cB9boQAMqP7BfVpuMoI5cjv2LqOosNUvZ4nn6ODQ8WWjyIX bBNAgPle5EnzymlZXZ+Ts/EeU+Mp/4Li5pRayPIVSZCQnN8UJnf0lDMexUTiExQ4WnF94D2poHo7 uRwRHp1dDg7Fby5i6JHrsdeSmUKgPpUlPR/mplMVmWfW71a6ledu7YpX5f5bsczL/eyyxU4vDohJ 3+idkLA85Zi358ZbJpoQHiH5ASZapO5gykeS2uNIKIoihFpwOigo7PAzY8E2L5AchDZo0AOOns1y JrP+6rz+umDNCZSgPPgmIRmMhEIbx0zAF36ThQePc+4PEJKP1ROHwpMYa7KIU4ApyXr4EUOsTQqY 0IU5n5se/+SENN8v+zc4VVEZOYaSKNaM6dhuTnSGSQw6lyfKBUmAb3n+v3joveRpQhVvh/CR36jG YgqxUOWhmCgUJsGin6twXIlDk3bNlyCKVEwqUpOEqADzDF3zq+GX3ePWg7TU3A5HNUdBvLInAGlS JwLShlGGf5sAfCHX9Q/cJgdm2YqLAfBY+PmfLnAQL+4BSqiJZogYBJteIbXgeJi+iswC6uo4/7P7 w1DJs6D7a8YrvjKZ7MJFc2j+bfEU/KCAYyBn0TaGetIRFMONv6AQlzJKuEWoJQAanqpTHz8al8AL Q6G/SKqFHLHIYACPpW2LcJls5tlf3nyOr2pKoJnvwfXAAwbkSkwR+f1HeMgW39zFXPCdCJIygxEf 0iu0swGQXdfALzWOa7/5IcwHd+JnBKcwXEpVofVJgvNZzXRUZJ50LeVU8CQkUsmDxIVndvbltDaD 8KRCBOErJj3ABbl68mL3Q0GKop7MWuaZ0Ow3WacJDLj0C38oJDscETTZ4TZSZGDk5eUhY3+UgK9k XWmlLyFC+XPOhOwRz82SAJKyHWxF654FmQklRg4Unchw1ib9fm6DNpc/RacA2iX8vA6KhFjbkGgV qHL6bQ0t+n3sJ56hNQQ58T0te8RQt/9h8R+iy9tLZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iagoy NTMzCmVuZG9iago2NiAwIG9iago8PC9MZW5ndGggNjcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJzNWktzFEcSvs+v6NtOR2hK9X5wwzaBTbDhNSi8B9uxoReItYSwQCAue9tfsPuD N6u7qjJ7JnskEWO0EBA91fXM/PLLR/UfnRRKdzL/rQ/HFwvZPYV/rxd/LKIw+c/wgj4fX3TfHCz2 X8ROKeFDit3Bq4UUKSVr3NBDdTEI3wXthPHdwcXil+X7fmVEUN6o5WUP45S3y+t+lYRJLvrlVW+F tNqF5TF2PK0d93oprFVBuWWXx0QTdX4tRYzWw/BDfCwLOR+Xn3svnLfawqg2wQd8vMRRZNprOled gKw12Ux7fNWvNIhRRbU8h1FKKx3oqJthKueWb/qVssIaaDsq5/MwpDWetkYy+6/LQT4queVJEVrb lLEgqle4f1jACgVCdcu341zG0sYPvZIiaOXpVi5bz7c4abcuqvWlSIcLeDTaax/oWsfDqXVKRcFG V6GruFz1vx08W2jrRTAJUHNwQnCSDD1eG/0RX0+WIYPqQchMv/Z1PI8kciQUBNHJOS5FBPGpV1r4 aE3BST4mmZQA7QwHnbLiJa3khGQtsoNrbCVLvGG3OKfMekaC2q7XIWaFrKpGVsrAiFEt40oaZiqH sdJFNNBy7ABth/h6w6izUZ41fBP4fVgXxWAzx838PrDmedWMYs48Oa4ga5FtCWJsfZtX9Jyt19NG A49ZZE8OFj8tMo0ap6VT8OCV0VF1L56yzVd3oVelOuWEM1kFlV91pPzqoxHajvz6OFt1UjIs32VL TBKWgsdVgJmj1yCAVRSgPzmConQ4wUfQhhTaqaQCkFXrDLDQIhnQ5uNee6DzpJeP8rQyujDwZhv1 H9BnENHFAH2NAFA5VXajnPN0Y5PdRABgipbZjI5e5c1I4aQBGNflhvaDHsQTbRoYL4gUtUyDcr01 Ngz22/qekjn+C5iHdVKKU+3tzO1570E6o1r+3WvYYxjsL69VTOr5An7/ZfzvocADeHF63OWLpq4i KBtCBHIYZCnlBD1XcCJnorQzkDomM9DZ3pdnF9OfJHeXqjnAAgf/HIeAq7P5mG2ImgyJ+YijEH4B +IKwrU1LlSESZASI/NaDqasUMvSA7gFOEcTlAeYaeEngmK52/B7anLAJfP0hYNt6p0eUj0+Z9YQF ggxZJDrzk8tU1x7Phq4WZtqjsxd2BtVKeqqQz6xCdZ8vshswJfhohyALXWLrda+S8CZZ0Ck0au2V ohs5bXvucCN/7VdOSG8Mef0BXx/i9CftPWksXV2kwumw8dUo5ez7mM2RjmSiM5x+Y8v5/c99gHjH qEBlT2YlU13jVIdtA+fDnrwb6D4rOcLpfxz8bTLSQRi3LuigyU6u4CnZKGN27eUtL5FLMqbt7nPv pBRSqlH7E0hrDRZhfVX+XttdhkvIeKfeCSgkShkas+DvO1HK7cbkgQ4K751tHDCjgzy+a2d9hI37 7OOnZm7lCVwQPhETJOr9yCIeISeqNQdimiyiyUa+Q+Mikx73WVoQ/gF66viL0UpUstQM307mL8u/ zzhzEl6Tlc7xJCNUFKCXIGVi23m8UrpOamCiioMXTUxot6J2O2sIJzNftH7n4Pl1w08wsrMhDwid ihqSu+7qdPHqfvw9ix8jIeTUBEEjg680LKit6/KOIUUdUE54Wj88T+eue8zsU3mvv+WRRLTOouZ9 Q9rvQ+gs8/jPDT+TbRDChmxUae0o5sn75w1fCP9LbnUikBmiWfdNKjqhfaOnbebjIXfaMJ/BycxY T4ErofmXjeabIVC9Er/E8AEh3BMi78rXyPuo10Nua6TxNXVL1dJmTkbIsi70iD3kU3Q71xPNFAd1 wpDZOczpk1STjm/p7rgDQ7xRvc6qKjKPzgWdrE32+ES2BGJ/y2mWdUo2OTtriLebxBxM/HDNqem0 h5yC8YkBIlEvVQVdM7k9iv6v5BYVZAIJaM0a0fwi42Jud4vlDPt4hk+9Av3ooP58p8iAc79a2MSm K8iPG4wmJq08ZAvBEbyxJo0g3MdGxDAfOk0cYiUU8h5d4m0s9BLBSsYjGKdgzvmclIY9vKAhKh4U NqKV9CCRofzlIJVGjpw6XQWZcwdr2ex1tfJ6t17XDgk9wrM4XWMgYHVmYu3E6ZptTjeQaPtHgGOK Slkq03cUeEwMdcp71ZL9fA2bdTan6M6oIVMfjZYGSuWc9zLaL7PFMmrGFjdX+g4jGpZceQfLuMiJ NVbDQBMiCdHhxIIHSqDuhFriWmg6g5OMde00kekEJpheVZWQcJYhk7lwVoEKO2uHigLEs07uOJ4N fgqiGs/GBE7VzZmWvb9pHWTTchH45El7+23zA98j2T2YOZkcuTtQl+Ryw3LKiTW1148Yx0fMiZgD W8sghvWxEcwla0OnnL2UjSY9cahslk6Cvf2N3BvE7ztrZMxgiwCInWJNZ8IiAi5Qy7FHTLNQc9uh 9mb0tyGRJApBR4gGo+6HAphVIoETGzNIhq+5IItHGMn4t0ZZtU1QeXGVJYK1k/UAJWORTDCDqhLj jjAC3gSfDQcFGIUYdwwj43M9GOVYcWSRsrTdwJHfjqPHDR4luTVmpkhIJEg80R7O+RUhBQEQHNUm MKxbOKsc884RADn6Ro3nTgIhRHTdCsWrVmIkpQoCeAKpQ4rD1veorfqaRCBl+60mS6ZhSE6BLK2S Q6yavOn8bkkux6ioEUJyep7kwgw4y+vRd4aUFOE2Et+jH0UYHwwhSnD2obDpVE4pbRwLYrvEJqW4 FjawbMejjEALa94Er0fce1KSmPJiuyVgcrQW86Hb/53LGv/Va5FviRKJA4+4MBHD0kk5vi39jtsF E/tyvh+SO0gR5RBoOrXrwqkBu7AEDjXQtJDaxTnSjttJm5jA83ZGNIGX1BhK8PlDnebb/5eI03rY 0a4jTrQlnr0RwmT6N612QWJLYhdzt3NMQMDlyeTKbHtgetrT5HIYsuXuYzQLNpQ1MNsAZ2XDjoOQ BK880V2FszQirzzD8wkD9Vbv+2F73vR4Ere2wuDXDDLyZzCddaFdw39hcXDLndmkKPil5UESexTZ ssXjSUWCylHJZCAjTm6IW0PaMWS0zVf4KMcaGpiQP2yagwy54pfbowRSvMLrtG8eHj7526jOWpdR tOva8hpkZpIeQlwblyZrl2UEcTMlfpI/E2asdEcY7Yh2rW57crPB3EaQRW/ahWmjQZTMGevzcR16 /YOBeuV3Yhf/oAXjWtQ6JGE22do0yQO3DeGFGQtTxu04XnB+INgGm0qwwLhGmbmAgVjL3Lcxpecz 1PkkHiQOaest44NVEcKQ8hmdo+vt5tTi6hp7EsjfEj/QesL2EJsAelJQYLC9ETePVartwidRMovf E47ib7i7DWInE+up0ml3Rc9I5HwPZEysQ+sAGE5j2dZZvdss04D6dSQoaNG0zVq9gy+Z+yKh9HyM vuSmaY1NgcggzX2Hha7oCc5JI3NwhylnPg/ln4ITOlerspfaUXRT5In28p51MIcshyP3blZ4Z6Lj 2yu9XJp602C++QkJWI7mTFBxjkNxPSc34NvvPFfYFT069vzCixPrZWdsHBOAAE5ktxYY1ZC8NdxU C8wOMYY7+Ke568nS82e0ltvvJ9kPFLDo1sSLDEq+v5yUy2sjWijJt3EhLE7cp5CHWSHp2rG+4G3b fjeJnQpMZ7ZfwUPkBFySVafd8u8wexSQdQciByzHYNseoutrf59oQNQBYCVhIHtJMBgCft8wqQgw VaLm0/g8a82fm7tcD2x+g0N4iLncmvDQF4XBSATMsZEU3rGER3Pq9knSNjvSdnp/65wDHYUGAO2l BwcchyxRebnjyoKTbsiXGgIKsVjQlUo0TRxflJ/0Q/1CPRvf7v+0+B9UpUpUZW5kc3RyZWFtCmVu ZG9iago2NyAwIG9iagoyODg2CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvSW1hZ2VDIC9UZXh0XQovWE9iamVjdCAxMiAwIFIKL0ZvbnQgMTMgMCBSCj4+Ci9Db250 ZW50cyA1IDAgUgo+PgplbmRvYmoKMTQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRm9udCAxOCAwIFIKPj4KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoKMTkgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUMgL0ltYWdlSSAvVGV4dF0KL0Nv bG9yU3BhY2UgMjQgMCBSCi9YT2JqZWN0IDI1IDAgUgovRm9udCAyNiAwIFIKPj4KL0NvbnRlbnRz IDIwIDAgUgo+PgplbmRvYmoKMjcgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRm9udCAzMCAwIFIKPj4KL0NvbnRlbnRzIDI4IDAgUgo+PgplbmRvYmoKMzEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL0ltYWdlQyAvVGV4dF0KL1hPYmpl Y3QgMzcgMCBSCi9Gb250IDM4IDAgUgo+PgovQ29udGVudHMgMzIgMCBSCj4+CmVuZG9iagozOSAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvSW1hZ2VDIC9UZXh0XQov WE9iamVjdCA0NyAwIFIKL0ZvbnQgNDggMCBSCj4+Ci9Db250ZW50cyA0MCAwIFIKPj4KZW5kb2Jq CjQ5IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VDIC9UZXh0XQovWE9i amVjdCA1NCAwIFIKL0ZvbnQgNTUgMCBSCj4+Ci9Db250ZW50cyA1MCAwIFIKPj4KZW5kb2JqCjU2 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VCIC9JbWFnZUMgL1RleHRd Ci9YT2JqZWN0IDYzIDAgUgovRm9udCA2NCAwIFIKPj4KL0NvbnRlbnRzIDU3IDAgUgo+PgplbmRv YmoKNjUgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA2OCAw IFIKPj4KL0NvbnRlbnRzIDY2IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMg L0tpZHMgWwo0IDAgUgoxNCAwIFIKMTkgMCBSCjI3IDAgUgozMSAwIFIKMzkgMCBSCjQ5IDAgUgo1 NiAwIFIKNjUgMCBSCl0gL0NvdW50IDkKL1JvdGF0ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlw ZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDczIDAgUgo+PgplbmRvYmoKMTIgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNyAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggMzAwCi9IZWlnaHQgMTY5Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9EQ1REZWNvZGUvTGVuZ3RoIDc2NzI+PnN0cmVhbQr/2P/uAA5BZG9iZQBkAAAAAAH/ 2wBDAA4KCw0LCQ4NDA0QDw4RFiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIySGJJTlZYXV5d OEVmbWVabFNbXVn/2wBDAQ8QEBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVn/wAARCACpASwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEA AAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJx FDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJ ytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQF BgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3 eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0miiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKY7rGheRlVR1LHAFZz6/pwYrHObhh2t42l/9BBFAGpRWT/bYP3dO1Fh/1wx/MilG uW6/663vYR6vbPj9AaANWiqdpqVle8Wt1FK3dVYbh9R1FXKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqKaeK3QvPKkSD+J2Cj9aw7rxloluSq3Ru XH8Nuhf9Rx+tAHQ0Vwtz8QQCVtdOb2NxMqfoMmqM3i3X54nljSCCNQSTHbSPtHrk8U7MV0ejEhQS TgDkk1iy6vNeEppSI0XQ3cudn/AB1f68D3NYejWuraxD9p1e9lls5ACluVCCQerAfw+3fvXSrBgA ZAA4AApDKA02GRxJes99L1DTnKj6J90flV9flUKuAB0AGBThEP736Uoj9xQACnrSbT6UooAiubG1 vAPtNvFKR0Zh8w+h6ioBb31iM2U5uoh/y73L5bH+zJ1/Bs/UVfFPFAENjqMN7vRd0U8f+sgkGHT6 j09xwau1m6hpyXyhlke3ukB8q4j4dP8AEeoPFceNQ8S2F3JaT6jG0sS7v3tuCHXswIwSD+h4ppX2 E3bc9CorhIfF+rxf6+wtLgesMpjP5NmtKLxraJgX9le2Z/vNHvX81zQ4tApJnU0VnWOuaXqOPsd/ BKx/hDgN+R5rRpDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAoopjusaM7sFVRksxwBQA+mS SJCjSSuqIoyWY4ArnZ/Ekt6Xi0C3W5C8PeTHZbx/j/F9BWBeT6O0m/XdVn1qdTkW9uCIVPsBx+JN AG5eeNdOjlNvp0c+qXP9y2Ukf99f4Zqmz+MtX+7HBpEB9wZMfXn+QrO/4TP7LF5Ok6Tb2kQ6bz/7 KuP51nz+KdauTg3vlA9oY1X9Tk1SgyeZHQR+AluJBLqupXF3J3PX9Wz/ACFaUfhnw/YqPOijbHe4 lJH5E4/SvPZry7uCfPu7mUejzMR+WahCJjJjQnPdQarkfcnnR6lHeeHrHiKfTYMdkZAf0qldXUHi G7W2t5Vl0y3Ie4ZTlZn6rH9B94/gK88yqKSIxnsF4yfSvQ9Hsxp2mQ2+MyAbpD6ueSf6fQVMo2Kj K5reYO1JvqHn2FOB9P1qSiTNOBqMcdc59O9OHPpj17UASKaeMHr+dRZ7U/P/ANegB2KcKaDTqAHA 1m67pUeqWynykkuIDviDHAb1Un0PT24PatDNLmgDm4fDen39olzZTXNtvH3C28Ke4IbPIPHXtVa7 8PanGSUMN2g6bP3bj8DwfzFbtsfsetywdIb1TMg9JFwHH4jafzrXqlNolwTPMJrS3e6ZNQtAjkEh Zk2sfoe/4GpLdr/T1B0/U7mJRyI5T5sePo3I/A16LcW0F1CYriJJYz1V1BFc1qPhl4UZ9MYun/Pt I3/oLHp9Dx7irUov4kQ4yXwsrW3i6+tgo1PTxMh/5a2ZyfxQ8/rXRaXrmnasP9CukkcdYz8rr9VP NcQ7bmPDLsO0qwwVI7EdjUb2cFxmSWP94n3ZFJV1PsRzTdLsJVe56bRXn9jrmr6YQrP/AGnbD+CQ hZlHs3Rvx5rrdJ1yx1dG+yykSp9+GQbZE+oP/wCqsnFrc1Uk9jTooopDCiiigAooooAKKKKACiis LxL4hh0K0HAlu5c+TDnr/tH0AoAn17X7LQbXzruTLt/q4l+859h6e9ec6n4judXkD3SB4gcpakkQ r7tjlz+QrIup5r68e7vJWnuH6segHoB2FNzWih3M3PsWru8ur0KtzM0iL92PhY1Hso4FQgcDp+dN q7p91b2sm64sY7xfR2ZcflxWm2xG4t3YyWkVq8hGLiISr7Ak8f59agVTnt+ddh4k1jTnsdPH9mwz mSAOm5ivlKeMcc9v0rD0jQNQ1hvNt4Vhtj0mkyFx/s92/l70lLTUfLroZgVvQ0oOSqLln/uqCx/I V6FYeCdNtwDdtJeSd952p/3yP65roba0t7RNltBFCnpGgUfpUup2Godzy/TdMujqlgLi0niiaXdm RCobaC2OeewrvfmPtnPtTNWJbXbFR0SCV/1QUKMbMkfnWbdzRKxIMcc5yKcCT0HXqBUYI29zg08E k+xpDJBxwTz2pQSen4imAdj1HQU4EkcdaAJAQBxzTh79OxqMcc9+4pwJPT8qAJAcntTgeajyBx29 adn86AHn1pM0A8fWm5oApaufLitrroba4Ryf9ljsb9GrZrF1v5tEvh38liPqBmthTlQfUUAOoooo A5zxPp37htSt1xNCuZQB/rIx1z7jqD9RWBmNoV6KW5z2ru7x4orKeScgRLGxfPpjmvOowywQo4IZ Y1BB9cVvSfQwqrqWEjYSLnp61XuLdJ5RNl4p0OY5o22uv0P9K0NMaJZgbhnCbgOADnnv7U69jtmv ZBas33yCGAAznt7Vo9dGZrTVFrS/E8tq8dtrhXa2BHeqMK3s4/hPv0rrgQwBByD3rz64VXLxuoZS NpVuQRU2j6tJ4faOC5dpNKfhWbJa1PofVP5VjOnbVG0Kl9Gd7RTVYOoZSGU8gjoadWRqFFFFABRR RQBS1bUYdK02e9uD8kS5wOrHsB9TXjd/ez6jfS3l02ZpTkjso7KPYV1HxG1MzajBpqH93bqJpB6u fuj8Bz+NcfWkF1Im+g4U4A4puQPSpriCS2k8uYYbargezAEfzrQzG46cin4HHI/Ko/4RTv4RTEdN 4Q0iPWL5nuz5ttZquIz0YnJAPsOTjvkV6UAFAAGAOABXm/gXUkstVkt5mCx3gVVJ6BxnA/EE/iK9 KrCe5tHYKKKKkowdYQrrVlKfuPDLFn/a+VgPyDflSDAVeR+Fat/Zx31q0MmVyQyuvVGHRh7isJnk tHW31DEchOElA/dy/T0P+yfwzQBbGNxGDz604MWXHp2FMyAQcHPvTt2Gx2/pQA/tkn607djleKYo IOGwAeKcpA4x+JoAkHHPQUucdOhqNckkHNOUgcd/60ASDjr0pRknBP41GvPX86bNcQwpmWVIgO7s FoAsA5OaGPQ1QGoxycWsM90T1MUZ2/8AfRwv6012nlH+mXlvp0XdUkBkP/AjwPwB+tAC37faydNh +aWYYlI6RRnqT6EjgDv9BW50rEi1XQ9NiEUN1DhiTiMmRnPckjJJ96guPFUKbfs9lcy7skM4Ea4/ Hn9KaTewm0tzo6qX2oWunxCS7mWMHhQeSx9AOp/CuU/t/Ur+by/Mjs4sEnyRubH+83H5Cqum25uL h2eaPzXOGe4clzj0J5q1TfUh1F0J9T1iXVpNmxoLJDu8tvvSEdC3oPb8/SqIl3f6wbvfvW3remxQ sXjnhj3Ko2M2CcDHArCWNt4DD8a2ha2hjO99Sd4/3ahDnuR3psX3ix/h5qNnJkLDI9KlaaMRqkhA lk6BRlm/AcmqIFVw/wAr/ge9VtUuFt/3W0TSy/JHF/f+voPU0+RZ4Ww6mF8ZEeAZSPXb0Qe7fkaS zt1jmMkgDSP1brgemT1+v8hxSvfYq1tzU8I38mnTpod3JvRl3Wsp9erR/h1HtXa15tqMEkkXmW7Y niYTQuOzLyP8K7zSb5NT0u2vY+FnjDY9D3H4GueceVnRCXMi7RRRUFhRRRQB4lrtwbrxBqUxOd1w yj6Kdo/lVMdP0qbU0MesahGw5W6lH/jxqFelbR2MXuTW1xJazLLFs3r03oGH5GtbXdal1eVcrGsS xqP9WobcAM89cZzxWKOPqeaXPIaqsFx4C7Tz+lPG3b/F1pi/eK/hSr0b6UyR/wAhjPDdR3rsvD/j Iwqttqpd41AC3OMkf74/r+frWd4U0T7depLNJbmAAkx+aC54P8PbrWXfabJpsjxyTW8p6AxShj17 jqKh2ehSutT12CeK5iWWCRJY25V0OQfxqWvGtOvbqwm32dxJbk5JCH5W47g8Gun0/wAdXKbUv7RZ h08yE7W/FTx+tQ4NFqaZ31RyxRzRtHKiyRsMMrDINY1p4s0e5IU3Qt36bZ12fqeP1rZiminTfDIk iH+JGBFQWZMuiNFzYXLRKOkMoLx/h3X8Dj2qvI19b48+xcgcF7Y+YPy4b9DXRUUAc0moWsrhftCL J3ST5G/JsGrnGA33s9x0rVmhinTZNEki+jqCKoNoWmk7kthCfWFmj/8AQSKAIiS2P5e9O4xk9e4p f7FVf9VfX0Y9PMDf+hA0z+ybtfuam5H+3Ah/ligB+ScEVQfRdKabzm0+3aUnJfbzmrn9naiBgX9u frbH+j0n2DUx/wAvdmfrA3/xdAEP9laeDzZwse25c/zqaOys4gfLtLdDjOViUUosNTyCby0/8B2/ +LoOnaiVIOpRLkYyltyPzY0Acprl39r1fy4z+6tR5S46bz94/hwPzpi3G0MsnzRv8oz2x3rei8Hx IiK+oXTBOhCoD+ePxqceEtOHMst3IB/emI/litlNJWMZQbdzm9ix275yjudo7jA70yV44pFMk0QJ XB+Yde9dHNZ+F7PH2g2pK9FllMhH4Emm/wBu6RZoWsLBnAON0UAjGfqcU/aN7IXs7bswriS51O48 yG1uZsKqgrEccD1OBV600XV2U7oIYFI6zSZIH0XP86fL4ov7htsEUFqp6FsyN/QfzrMv3ublv9Lu ZrlPRmwmf90YFC535CfIvMtvaaZBJsn1Ca+n/wCeFkAq/Qtnj8WFQNeSR7orKCLTYjwfJ+aVvrIe fy/OoIgIosqAvZQBgVYtbh0lVlYq46OOoquTvqJz7aFmOxMGjCcRNh5TuGDnGPve/Peq23ahcHIP ANbEutXI0wFZB9oMpXdtH3cdayJbh3k/esXJ+8TTjfqTK3QIWwp3dDx+NbHgVyumXloeltdyIo/2 Thh/M1jSLt2qOQea1/A4Ji1aT+Fr1lB+iqKirsXS3OqooorA6AooooA8n8aaXND4rm8iGSQXaCZV RSxyOG6fTP41kJpeoZ/48Lvn/pi3+FeqeJbCe4tYryxz9vsW82EDjeP4k/EcVBY6l9vs4rmCZzHI M4LHKnuD7jpVqVlYlxueaf2ZqHX7Bdev+pb/AAp40q/wf9Busdv3Lf4V6h50v/PV/wDvo0edL/z1 f/vo0+cXIeY/2deghv7Puz9Ym/wp66dfB8f2fcYPfyWr0vzpf+er/wDfRo86X/nq/wD30aOcOQ8+ 0uPUtPvkuY9PuN6BgP3LDqCKgj0+9+bOnXHIPPlMK9I86X/nq/8A30aPOl/56v8A99GjnDkPOY9O u8n/AEC7Xg/8sm9PpTotLuzIv+i3I5/ihYf0r0Tzpf8Anq//AH0aPOl/56v/AN9Gj2guQ86bS9QH Jsrgg+kZNPGnXkVwGjs7pNuBmONlP5ivQvOl/wCer/8AfRo86X/nq/8A30aPaeQcnmctZXGqWU5F 1PqgtmP+sAL+Vj13A/L79R9K30utQADRaikqHkGSFWBHrlSKtedL/wA9X/76NZz2TRSNLZOsTMct E2TE59cDlT7j8Qahu5aVi5/aGqq2P9Ck/wCAuv8AU1J/aepKfmtLRvpcMP8A2Ss5tQ8rAvIntT0L H5oz/wACH9cVajZZo1eN0df7ykEfpSGTnVr4f8w6I/S5/wDsaUarfYz/AGamPX7SP8KjyNvAyR60 4BmUnnjvQA7+1b//AKB0Qz63X/2NDajqX/PpaLn1nY/+yVUl1C1g+RplMvZF+dz9FGTURkvLrAjQ 2cXd5AGkI9l6D6nP0oAffaxqtv8Au4Y7SW5YfJBGrufqTxtX3/Kqd1qXiLH7vAI4by7Q9fbJORWl axLaKwhLgucu5YlnPqT3NT+dL/z1f/vo000ugmm+pzc02uyW4aW41DzGPSOPYAPwFQiwup4vMuIb qZ14ImLvkeuD37V1XnS/89X/AO+jR50v/PV/++jVqaXQjkfc5e3s5V+T7DLH5gO4pERgdv8AGn3N jciONY4JmH3j+7PX0rpfOl/56v8A99Gjzpf+ej/maftfIXsvM5SKzulyxtZ8joPLPWiO1vA3FtPz 1zGcV1fnS/8APV/++jR50v8Az1f/AL6NHtfIXsvM5qSznk4S2mXb22HBpos7pI/+PabJ/wBg9K6f zpf+er/99Gjzpf8Ano/5mn7XyD2Xmc3DbXK/ftpio7eWetH2K5D5+zzEdf8AVmuk86X/AJ6v/wB9 Gjzpf+ej/maPa+QeyXc5mUS2tvNcXEMqxRKXJZCMYrpfCVk9l4dtVlGJpQZpP95zn+oFZdz5muav HpQdntLcrNenOQccpH+J5PtXXVEp8xcYcotFFFQWFFFFABXJ6tZyaHeS6naRtJYTnddwIMmNv+eq j+Y/GuspOtAGBDLHPCksLrJG4yrLyCKdVO90e50mZ7vRY/NtnO6awzjnu0fofboafYX9tqEJktnJ 2nDoww6H0YdjQBZooooAWq1vNeXUCTQ6bM0TjKt5sYyPXrVkdat+H/8AkA2P/XJaAMaTUDFaSTtb SZikMcke5cpg4JznGB61YH28jI0yYj/rtH/8VTbfBlvgRkG6kyD+FT6XcGxnSwlP+jv/AMezn+E/ 88yf1Htx2oAjt51ni3qGUglWRuGRh1B96kqTVrR4ZTqFshY4AuIlHMij+If7Q/UcelRI6yRq8bBk YAqw6EetAC1As000ki2lpJcrG21nV1Ubu4GSMkd6VxLc3AsrVisjDdLIP+WSev8AvHoB+PatWaS2 0fTlCIRHGAkca8lmPRR6k/8A1zQBjPdXEN1DBNYyxtNnH7xGwB1JwelQzW9lNcNHFYm4uR94QIFK n/abgA/jmnzedDaXl7MwN40TMSOQmASqj2H6nmuh062jtLKGGFcKFBJ7sT1J9SaAObGl3A+7p1+o 9BfD/wCLoOlSt/rNIuZf+ut0rj8i9XBfX19mWK5FrBuYIqRhmIBIyxbI7dAPxozf/wDQUm/79R// ABNADIbe7gXbBo7RL6I8Sj9DRJPNbjddWVxAnd8B1H12kkU/dqA6anLn/ahjI/QCtLSbyS8tnMyq JYpGicp90kdx9RjigCgjrIiujBkYZBU5BHrS1EYlttWvIIgFiISYKOilt2cfXbn6mnTzJbwtLISF X0GST2A9SemPegBJ7iODZv3FnOERAWZz6ADrQF1BhldNcD/bmQH8uau6TYvFuu7pR9rlGNvXyk7I P5k9z+FQT6xcGd2s4EmtYTtc87pCPvBO3Hv1PHvQBXS4/f8AkTRSW85BISQD5gP7pBINTVoTw22r 6epV90bgPFKnVD2YehH/ANY1kwSSb3t7kBbqHAcAcMOzj2P6HigCaiiigAoopaAErPv72b7Qmn6c ol1CYZAP3YV/vv6ew70xr241Kd7PRAsjqcS3bcxQ/T+83t+db+kaRb6TAyxFpJpDulnk5eRvUn+n agB2jaXDpNiLeIl3Yl5ZW+9I56sa0KKKACiiigAooooAKKKKACsbVfD9vfzfaoJHs79RhbmHqfZh 0YfWtmigDjZb690k7NbtsRdBe26loj/vDqv8q0YZY54llhkSSNujoQQa3yAwIIyDxg1g3fha1MrX GmTSaZcNyTB/q2P+0h4P6UAPHWrfh/8A5ANj/wBclrCkfWtN/wCP6wF9CP8AlvY8tj3jPP5VFpGs sYI7O01Oz3RDYI5rdlkGOxBYfpQBftv9de/9fcn8xUk8KXELRSZ2t3HBB7EehHXNMtoZIVk851eS SRpGKrtGT2xk1NQBa0m+ebda3RH2uEAk9BKnZx/Udj+FVLnT7q0uHOnwpLDMSwjZ9oic9T/unqQO QenXiOeASmN1d4pYzmOROGQ/1B7g8GpFvdVQY3WcuP4mVlP5DIoA0LO2h0uydpJcnmSeZ+Nxxyx9 B/ICsoSPf3IvZlKoARbxN1RT/Ef9o/oOPWiVbm8ZTfTI8akEQxKVQkd2zkt9OntU/WgCvfo0un3M aAlmiYKPUkHit2ymjuLKCWJgyOgII+lZNQrDLbyPJZXDW5c7mTaHjY+u09D7gjNACLb3dhug+xzX EasxjkhKnIJJ5BIIIzj0pfMuf+gbe/8AfKf/ABVSfatV/wCfm0/8B2/+LpftWrf8/Nn/AOA7f/F0 AR+Zcnppt5n6IP8A2atHRrWa2tpTOoSSaVpSgOdmcYGe/Aql9q1b/n5s/wDwHb/4umPJqM67Zb5Y 0PX7PFsY/iScfhQAszq+t3zKQVSONGPYMNxI/AEfnT9Lt/t06X8o/wBHjObZT/Ef+ehH6D2571Su bJmtUt7UxRxBsyLICRIPQkHPJ6nvVv7Zq2zar2C8YGI34/WgC9e6nYwySWs8rltuHWNHYqD7qOD+ tZCJ4ejRUT7YqqMAL9oAAqe3hFvFtDMzElndurserH3qXJ96AEsdQ0bT4jFbvLFGzFiZI5cAk8kl hx/Krmq2LXSLPb7Vu4cmMno47ofY/oeapnDAhsEHggjII9KrrcXmmW2xbq0W0T7huQcov93ORkDt 7UASW863EQdQykEqyN1Rh1U+4qWufTVrm81NptPgGoM67ZRaxMkbEdCXY4BHTPOR9BWpHomrahzq V6tlCf8Al3sj8xHoZD/SgBl7q1raSiDL3F233baAb5D+A6D3NLDouoav82rv9jsz/wAucD/M4/6a OP5CtzTdJsdKi8uxtkiB+8w5ZvqTyav0AQ21tDaQJBbxJFEgwqIMAVNRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAVR1DSdP1Ndt9Zwz+7LyPoeoq9RQBzTeFWtx/xKtVvLQdo5CJox+Dc/rUL2/iO 1+9bWWoL6xSGF/ybI/WurooA41tZNv8A8f2majaY6sYfMT81zT4df0mc4TUIA39122H9cV19Vrix tLoYubWCYf8ATSMN/OgDIjkjlGYpEkHqrA0/B9DSy+EdClOTpsKH1iJT/wBBIqE+D7BceRdajb+0 d02P1zQBJRUP/CLSr/qtd1RfZnVv5rTT4c1Efc8Q3P8AwKCM/wBKALFFV/8AhHtV7eIZP/ASOj/h HdUPXxDN+FrGKALFLUA8NXh/1niC+P8AuJGv9KUeE42/12ratL/28bR+gFAE2COoNVZ9Qsrb/X3l vF/vSAVMvg7RiczQzXB9Zrh2/rV628P6PakGDTLRSP4vKBP5mgDnv+Ei01m22zzXb/3baFn/AJDF Spc6vc/8eehzIv8Afu5FiH5DJrrURUUKqhQOwGBTqAOXTRdbuubvVIbNT1Sziyf++2/wq1beE9Kh kEs8T30w/wCWl25lP5Hj9K3qKAGoqooVFCqOAAMAU6iigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKAP//ZCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKPDwvUjEwCjEwIDAgUi9S MTEKMTEgMCBSL1I4CjggMCBSL1I5CjkgMCBSPj4KZW5kb2JqCjE4IDAgb2JqCjw8L1IxMAoxMCAw IFIvUjExCjExIDAgUi9SOAo4IDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjIyIDAgb2JqClsvSW5k ZXhlZAovRGV2aWNlR3JheQoyNTUKKFwwMDBcMDI2XDAzMVwwMzRcMDMwXG5cMDAzXDAwN1wwMjJc MDAyXDAyNVwwMTZcZlwwMzJcMDIwXDAzNVwwMDZcMDEzXDAxN1x0XDAyNFwwMDRcMDA1XDAzN1xi XHJcMDI3XDAyM1wwMzZcMDIxXDAzM1wwMDEgLzw/LS43Pj0zOCMmKjA0JTU7NixcKScrIToxIiQ5 XCgyW1xcSU1MWlRTTl5SR0hYVktXUEJRWVVfQURFT0BDSl18dXBcMTc3enFlb3lpc31idmthe2pt fnhkbnJoYHRsZ3djZlwyMDFcMjI3XDIwNFwyMDBcMjA2XDIyNlwyMzRcMjMxXDIzNVwyMjVcMjEz XDIwMlwyMTVcMjExXDIzMFwyMjBcMjIyXDIxNFwyMTBcMjEyXDIyNFwyMjNcMjAzXDIxN1wyMzZc MjM3XDIwNVwyMjFcMjA3XDIzMlwyMzNcMjU0XDI2MlwyNTZcMjQ2XDI1MlwyNTVcMjcxXDI1N1wy NzdcMjQxXDI3MlwyNDNcMjczXDI2MFwyNTNcMjQwXDI0NFwyNjRcMjY1XDI2NlwyNDJcMjQ3XDI2 M1wyNjFcMjc1XDI1MVwyNDVcMjY3XDI1MFwyNzRcMjc2XDI3MFwzMjJcMzE1XDMyMVwzMzZcMzI3 XDMzMlwzMTJcMzIwXDMxMFwzMDBcMzM1XDMwNFwzMDVcMzA2XDMzM1wzMjRcMzExXDMwM1wzMDFc MzAyXDMyNlwzMzBcMzM0XDMzN1wzMTNcMzMxXDMxNFwzMTZcMzIzXDM0NVwzNDFcMzQzXDM3Mlwz NjVcMzc0XDM1N1wzNzBcMzc1XDM1NVwzNjNcMzczXDM2MFwzNDRcMzUxXDM0MFwzNzFcMzc2XDM2 MVwzNDJcMzU2XDM2MlwzNjdcMzQ2XDM1MlwzNTNcMzQ3XDM2NlwzNTRcMzUwXDM2NFwzNzdcMDAw XDAwMFwwMDBcMDAwXDAwMCldZW5kb2JqCjI0IDAgb2JqCjw8L1IyMgoyMiAwIFI+PgplbmRvYmoK MjUgMCBvYmoKPDwvUjIzCjIzIDAgUj4+CmVuZG9iagoyMyAwIG9iago8PC9TdWJ0eXBlL0ltYWdl Ci9Db2xvclNwYWNlIDIyIDAgUgovV2lkdGggNTY4Ci9IZWlnaHQgNDY3Ci9CaXRzUGVyQ29tcG9u ZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzkxMz4+c3RyZWFtCnic7Z17fBTV2ccf CAmEayBsDEGJFyIoFhQiLwi2XlBbRfBepPoqliqIl2K9YH37qlQRqYJVaq3VYr2CiGKx9daCVxCj eMEbL5eELAQ1iIAYyPPXe87M7O5ssnF3T87sPCfn+X4+mT1zzjPnueSX2Zk5mwSRYRijgezM17dL 3t/QPvUMTe2y98QQZyMA5P0NcdNFHfKPq3Y7Cg68uUa0bjmoY6fjl3t2KwovRlxwQvLBj5yYYrYO f29mx7Q5Hh2DNX8Xp4eTTt6w+ZRJXsfygy9CvOinr9W+fuvPPLtDThRauOSi5IN/ObP5bNHHOjez Y9oUW7ogTv494tau+Hj/OsTXu6HbgW/kIXbf5jN9rOLNHohjnkB8EqDo0Lfwy1N7tr/ttKfEDFt6 LRxQ3Pl2x8yZLV/Yfdlb7H3VCd8e2LFiQXvpyW/GGM3KwxAPfxK/+tWlePIisV8XEZvDV8lWCeJ+ F30dt6wf9PT2nt9g+x2Il8369ps7jtj8o9k7d4wtfULMsLLj6e/ULe7j2MnZpowTdo+NF3urD13f 45ldywefKD35zRijWXQG1haJK5JTothht9jf3QGxtqe8yPmuDPHtcX3LTnrDtbxTyGDIu4nL3S5T Lxfbd9uLGXBRhbgY2thJdsvZ+k7bJuyumCN2lxx35Z3iZfLN0pPPjDEbcRlSNRhrHum4ByPyQvjZ UxCrDpMji890DDZccqTzuqe30M9Vs+Tl7pbJR3QE2G//jaJ7yYnyQuYSKaHnzpJ2YjaJsDvkcfF6 9cw8KcdxS6UnnxljNictwT/8Wrwe9RR224BYM3gh4h+mi466Q593Lb7p6bxMAcl0qZKhd31di7ed HdmKGD10ppgBT/qHsLjmN9LOmc3RY/fvEbcf9GykAXFvr33Sk8+MMZth7+LJz4rXmdfideds23Du eaJ98jKsrTrrKsTT7369/r0znNup99t9K7aP/1xeFnd9ctOXcw+4tf9ljV8fX/SCmAGHVYnBsY9I Q2c25/K5y+3131/XcU3lXQ3vD8hzPPnMGLM54Cvs97p4feto3HpOftllm0S7H0DXo2ZHxcXLcT0i ZVc2SrvT5snt+s7ysvip/YuOvueQ56uGl/zXok67xQx4wHdisO+X0sSZDeXl8+29S4c+3mXLByNK J/zyVMeTz4xh0nM+33sz2bFt+pY9k4fXhh0GYxg1U7t0OWVj2FEwDMMwDMMwDMMwDMMwpgCMubBu GBVC1U2IzpnWwLphVGDdMCqwbhgVWDeMCqwbRgXWDaMC64ZRgXXDqMC6YVRg3TAqsG4YFVg3jAqs G0YF1g2jAuuGUYF1o4wlH5JKDetGlVzKhl6hWDeq5DL4QH2ZJ3/WDQFfuZSNpjxYNwR8GZgH64aA LwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPNq8bjwb8dIX9jnN76Ev Lj+jLJJ33mrNvlRh3eSW7HQzEj50mk/C0I9Ks350yroJYppwyE43V8Esp3kLTBsGY5dv2rt4gmZf qrBuckt2uvkjXO80J8G9RbA3CF+q/ODcP3RiTCSnx1fOpwmH7HTzBIzHX8OlOBb+2QOu2B2AL1VS zn0DTPEGWTeayU43H8MgPKb0UDwQ1t5eDjDq+MVRzb5USTn3KBFuOt8KQbFustVNfUHBloLpRZsL S+pw1cSu4qd46Ba9vlRJNfcnIr7X0/lm3SiRnW5wNNxX8GXBbTBcdtQsnz8KZuj1pUqquW8Turml yfjq83qUdD57hWx+Ou6A/OMb5UDifQxg+10Hlgyan7UvTSEbQybBFzk226Ej4ngYchQOGQYTvaFP oK9eX6qkmvtMOArObjLuPjwo/QDxq/aydUZT3Vzm7CzK1pemkI0hk+Dbwx6x3Qf9EK8HuBGnAlzh De2FEr2+VEkxd10vWAW9apLHf7Hs+5qN18LP5T1h/7c3fTY8+boYYPiq+t3nwtAsfWkK2RwyCX4i nPlO3XsnwimIswBewAUAd+Cwuz+vrf1sAlTq9aVKirnfhSPwSKhKMb4TuqMY+kg0/9VUN/8S243Q JUtfKrR53bzd1Tl3d30NcRUUbsbNhfCud8KHgif0+lIlxdyXwG/xtzAzeXzZhM4FIuxCxI6wS+w3 NNWN/D+K26E8S1+aQjaHjIJfe05ZQdk5b6BcmJL/zH0w7MWVU44uLck7t0q3L0VSzH2sI+yRSeNz Ep8sb0E3GUTKujHy+XyGc28rcAQS2ebsFcFW+dIb7ttdg1uk9fDU71MZRMq6acu6eQwGiO0AeMTZ q4S528VLT3ixsX7FWGl9vbwu/uLHrBsl2q5uboJbxfZPcIOzd7/75jTNOQdNlk33Pvz0+H04uK0M ImXdtGXdjII1YrsSRjl70cvLpMmuK/IK8uZEHevXT+5efFIj60aJtqsb8r5YNwR8GZgH64aALwPz YN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP43VTNy4jy2xmTXkQ6yaIacJBBv/SvW57ASz4IUul 6Zv6CgrWTW6RwY95y22fdvrYH7JUmr6pr6Bg3eQWGXw7d8n4k4qaincQZ/YWfe/+OIrbB62FW3v1 fQrXHVMgH8E7bZhegl9URCrWefuxHTmVe6gza7z/4uLRK/2+gswjV7Bu3OAjNU5z6jP4zI2IPZfI jy6d+iJ+dCLC/IaXO2PFXNnjtmFJDfaf1zivwtuP7UgD71CnGeufXT2vv99XkHnkCtaN/3zT0AkA Ou3CV0Z2ugjx88O2X7sKISo1EKl2LJ021AmdNWB1xNuP7SBGwTsU/f3O1ucryDxyBevGDX68c33z 5xPE5oQHxGZFqdhc+eIF6J1GvPON8yW3lbc03Bc7xXg7vRfuug1ih/r6QWxzfb7xbg8zdpbOcFxd y75ag/G6eelO2RqyVGyWHiV6es8Rre96/z2mlRUVheDXzZrKSP8vYrpxd5b07TIHYof6+mFq7q9v YreHurjrpZZ9tQbjdZPy+U30nKY/ZpnzXp8WfQWFb+7Y7aEu1oxp2VdrMF43Kfvzl6pPWnJ1Vr50 4Jvbuz2Up8i/dG/34tXdOy2S4/0WYNXo/CtE98fHlhwh/97T2vYN2ND+80RPh/VPw9Pr23m78tZR srksmDzapG5M8+Wb27s9BOcWcGHJ/IZX24nd6L9HiGuu6tmie8gDtc87v6g88UGcezYmei788MLf jF91gbcrbx0ldU1/tZB10yZ14zvfRGO3gfN6FEI5Foi7O3mrJ24cnV+QejdvZ7+VmOi5/OIjo4Mu nuTtgvdGzeebFLRB3bi3hxi/lJdfpQsbFoC8x3PON0uqPdORAwc4Fl7PE0V/xVuL7vB2YzO+NTGY PFg3BHz576fudHv8urmmV/eZgFWD8q8rQnzzglLPfDE851h4PTtK9uH6gjXebmzGe5cFk4c9umlF ovIhSG6f36Sk/p4hWU/Nz29SkHHwGdq1ZCYfgoT/vBjKj8zmF5Nb5StX04RDrnQjH4KErxtSvtqK btynFjc8isumeM8znIVw7zkxuO/4SWvh6K6ee4vnsumYeY8/Eg9P0L0pYd0EMU04+IJ3n1psOv/B 8zd5zzOchSnv4tJ7SVoLR2/13F08d5oQn8j/8MR9CMK6CWKacPA/L3MfYrwKq2PNiHc7Gk3oJmkt XOAsgbuL504T4hMlHp5I+HwT1DTh4D/fOE8tGoc+d3CD9zzDOd94S91F6/3L3Ji4kpFL4M7iudOU ZonHHwk7+RCEdRPENOHgC959ajFtIb5wrfc8w1kId5e6cXIx+Ja5MaYHdwncXTyXTWmWePyRsJMP QVg3QUwTDnqCT794nsPnN4HDutEUfIaL56ybIKYJBwPrnfO5A/LFuiHgy8A8WDcEfBmYB+uGgC8D 82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDLwDxYNwR8GZgH64aALwPzYN0Q 8GVgHmA2WmqQYaHMnDsgX2F/41uJlhpkWCgz5w7IF79PEfBlYB6sGwK+DMyDdUPAl4F5sG4I+DIw D9YNAV8G5sG6IeDLwDxYNwR8GZgH64aALwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0B Xwbmwboh4MvAPFg3BHwZmAfrhoAvA/Ng3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubB uiHgy8A8WDcEfBmYB+uGgC8D82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDL wDxYNwR8GZgH64aALwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPFg3 BHwZmAfrhoAvA/Ng3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubBuiHgy8A8WDcEfBmY B+uGgC8D82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDLwDxYNwR8GZgH64aA LwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPFg3BHwZmAfrhoAvA/Ng 3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubBuiHgy8A8WDcEfBmYh+G6ySVB5hHc3AH5 Mlo3ORVOoGkEOHkwvszWjRL0Us6l/Fk3qhBM2TjZUCxi0FiYsn4sLKKFKevHwiJamLJ+LCyihSnr x8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqY sn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyi hSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fC IlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+ LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp 68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJa mLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiws ooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevH wiJamHJmgEfyLu81KUwQHoyGxDeH7p63H4QHe+CUGRUsLKKFKevHwiJamLJ+LCyihSnrx8IiWpiy fiwsooUp68fCIlqYsn4CL+Kff1JaXHndZwF7yQbWjQaCLuL9cO/O+pWDKX2rWDcaCLqI+0NUbP+P 0reKdaOBoItYBKvi7VcP6Vk6bLHzbP7l/iXy8fy5uEc+pG8yEGxErBsdBF3EMwGOnvTobtl8unBO 486rYal0evrmJ2ENlNUhru1X03Qg2IhYNzoIuojbpnUUZ5Hy0zYiHgwNiFvhEOn0DTlWCY8gTr26 +UCwsG40EHwRtz5+8wCAsYjF7tJxV+lUXvSIa+bxWN/u9eYDwcK60UBuijgb8qVu6pOd7i0q+PLF CSkGgoV1o4Ggiwgr5LYRuiGOdNpvjE44HQd/mvBKqoFgQ2LdtJ7AdXPgY1uiu2+EexCfLx/4Xt26 w25JOF0IZZ3rUw0EGxLrpvUEXcQVUw/rU9DprBdl+z8DepYcfZ/7GTlnMLofTE45ECisGw1YWEQL U9aPhUW0MGX9WFhEC1PWj4VFtDDl9MQuLYN+NRjjEwgAyIluzK682dEHQ25qYnblzY4+GFg36TE7 +mBg3aTH7OiZsGDdMCqwbjKmEhaI7QLoj7jjqm4l3WbsQNx9Zp+C3seEHVkIsG4y5vdwutieAX/E HWXdPqj/sEPZDhwL/6xdMzHsyEKAddOcFmryaXn+VtyaX74BZ8BLYv8fMAM7wm7vEID8abXy43eF HX71DeLtB3XsNwu3/2FQSY8/bs/GiyGYHX0wtFSTkbBIiGUgYgf4Tux+Bd2wDDpPe2i9PGRS9WS4 DPF/VjQ8JPQ0Dy78fs90vBd+V32N/NhMFl7MwOzog6GlmsyGE8Qb092IEagRuzVQgovLxImm6A5x yG5cD3mOWR30xhHwnmzuB5/itzAqKy9mYHb0wdBSTfZEIu9HSrbI880esfud/Nxm3Qe/HwTtnM+C 10AEPxrYpxyg3FOWeJEUZOXFDMyOPsecAAfBieJ1BiwT20VwldO7EUqd881u6IHtYWldg6jpKHhT Do2AjSGGGySsmyxYJE4er4jXHWX9Vtd/0F7cTw18ZV/9M0JLANc3XA+/xM7wUeMkUdP5cOG+vZNw Lhy3eefS88OOOwBYN1mwNR+6NsjGjhkdIh3k85vTDiwtbHfeHud+qviqWnx5eLm76P3wQUX9Hkac 1b+oy4ULw447AFg3WrCujNYlnAEKNcnNIYQwO/pgYN2kx+zog4E/R5Ees6MPBtZNesyOngkL1g2j AuuGUYF1kwL+/am0GJ9AELBu0mJ8AhSwsIgWpqwfC4toYcr6sbCIFqasHwuLaGHK+rGwiBamrB8L i2hhyvqxsIgWpqwfC4toYcr6sbCIFqasHwuLaGHKTQAqcMYmEXbtfHDGBkEm+BzqJkeO0kEmEBXI BM+6MQoywbNujIJM8KwboyATPOvGKMgEz7oxCjLBs26MgkzwrBujIBM868YoyATPujEKMsFT1E2w iwFkSq+CL/hw8yCkm6+nDOrYa+zLmeimNVG3Md3IWpXs/9/vi+bO6/cv2n/qVrczf/S01+T48jPK InnnrU6eJmVnS46UxrWR1tG/+/hWHVk3qWkevLdWW1yF0YFOa0A01hl5APGj0hRruSk70znKblwb 6Rx91xfOeK128/MnZGLNuknqqV93AQzEV6D96toPyuBFp7Nh+aTyorU4DMYu37R38YSkY1J2pnOU 3bg20jm6GcY0t/a/vHJC+5KOR/5udeITGaKz9i9Hd+x07iee0SWdes9tdSCkiQXf9My8D4rxZJgl WrfBybHOK+FSLIK9zWfxdQ6BRWL7BBzkK7C/wokCAzzW6dAtl/esTAokcNI5OhRebW7te7kxnosv q02/cBqdNzpG8zO6nm6TutkDB+Ag569Xr4XRsc63YDD2gCt2N5vF13kHjBTbiXC/r8C+CvsKDHAA wPkZXkjoI52j7vBtc2vfS0+4dUNd7ZsPHeuf7E447LO6DafCTU5f5bLq73/d6kBIk+q6GLHmjYnw K8wH+deKq6FnbOwb6IW3lwOMOn5xNGkWX2d1d3gNvyuJfJVc4NjsvgIDLF0K8MJ/iOmmwP0fAcnW vpcD4RfHXTz3yWjSZAc5P2JfwX5O331aAiFN6vspcUf1s0YsBFmcKBTGxmrk/1pYNbGrGB+6JWka X+ckuAHvl3+PP6nAsdl9BQbY2uh8NQ0kWFp7vvlohFOg/jv8kxV759OI07deSyCkaUk3Q8UVSMrz jaBm+fxRMKPJRPHOtdB152B4rEmBY7P7Cgywfbvz5XObBs0Zp2RYy9c3tc5LdMWSmWfmu1fPTXUD Tl/yybjlQHKUcRCkfp/aczUMqvaubz5PXN+skVe7Dp9A3+ZzeZ1nwU3QqR6TC9xUN+D2OF/eeI7K mG6SS+Cnvr0ikI+vsI/zH0r+lTj2HciXL4Xem9rgop0ZO0jYGSyc1LpBHA/X4KnwsGjd7b+fmu7Z 7oWS5nN5nX8T2SauCr0CxyrsK3BT3WQVrDrpJtl3AJy0vH7bf9znN5UwV/6/vmNh3O5NH/xIHvuT e9Y11nx6sXvq7QCzdsnXuXDIqp11n95+eBZR5izjIGhJN2ug765noV9V/eoO3vObXcsnl5d8jMPu /ry29rMJUOmfJamzrhvAh9ikwLEK+wpMVDf4dE/fT/r9busBp+cy/73hJXL4fz3LujGJ04NVukl+ +xAcBQ/UHO50JZ4XFzwcNyx4InkWf+c10D6KTQocq7CvwFR1g+/cNKKo12kvO+3o5WXOAfePiOx3 13bZ/OLSyuJIhwsfcYZ3Xtkj4l70PDS0S8mI31VlEWXb1M1TcBRuuzSvJO/6ne5w8aAZ60Rr5ZSj S0vyzq1KmiW58zdwpXxJKnC8wokCk9VNjmgTutFItIfzNhVAIKwbMugPLPog5KX+18+tDoR1Qwb9 gYm3tL8EFAjrhgwB6KZ42qaAAmHdkIFMYKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCs G1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgEFrZu6sa5o6mOaDaQ coofCG5OFoFkbRMKLQbm1dGx+YHDmw1CGvusA8nSRnWSl+51R1Md0Wwg2zh6ZxFI1jah0GJgXh0d m2aN5kP+sR8oMV3djHnLHU11RLOBbONIfX5qk7rx6ujYNGs0HzJeN+22uaOIX1REKtZJu34LEFeO zr/C1c3FxaNXotcN8catvfo+hbjumALnzOvtVsUOik+lmo15uvHqGKubrFLsc6SynvEh0TOzt/cZ U5he4lTPLbF7mOz/+NiSI1YnvgXZBZKljeokkRp3FLH/vMZ5FaIZ/fcIsTO7ep6rG9Hoj143xBvz G17ujFgxt9Z9h3Z3K2+pnu2YxKaySDdeHeN1i5fLrWd8SPT1XFLrqWRJjVM9t8ROj7Md8kDt88MT U2UXSJY2qpMkzjeRBqyO4LwehVDu7ri6cXq9bog3ou4h1e6h3m5B7CB3Kqt049XRq1u8XLF6xodE 3ysjO13kqqTOrZ5bLZC/I+z0R8RJpzzxLcgukCxtVCcZH7++qbyl4b4KLF3YsECefMSOqxvRED8M bjf4GvIrfr6Jz+Ceb9yprNKNV0evbm6VitbHWokhp72i1BnzyuaVuPfCXbe5xwxZUo2+b0F2gWRp ozrJS3e6o4hrKiP9v8BrenWfCfLNuPhGVzdTnTdftxt8Dfm1oqIQfLqpGpR/XZE8yJ3KKt14dfTq 5lZpcjHE6hkfcq54es9xxmK6cUu8pG+XOe4xb15QKvzEvwXZBZKljeokvucOGqi/Z4hqIFnbhEIm z29yQti60QqUH1mV3qhN6ibXtCndZATrRgesG1WbUCATGOtG1SYUyATGulG1CQUygdHRDTRrZDJr 865xda0MJEObUAgusHRlawId3SQsW2d310utD6Rt6SajY9KVTSEQs3SzZkzq/mwCsVA36cqmEEjO 3qfcdezYEjh6C7M3PIrLprjN+Ao4un/+2neQuyQu2FzWykAytAmFbAOLr317VZpegt4KufvhAa+s mL5sCoHkTDfuOnZ8CdxbmN10/oPnb3Kb8RUp3+qCd5C7JC6oS/EnELMKJEObUMg2sPjat1elJTXo rZC7Hx7wyorpy6YQSM50465je+uzGFuYxVdhdawZWwGPJnTjHRSNnY/5fOMjvvbtVakuvkLufnjA Kyuafb5x17G99VmMLcw2Dn3u4Aa36Z5v3JXb2JKudxDGdPPWxFYGkqFNKGQfmLf2naiSt0LufnjA KyumL5tCIDnTjbuO7a3PCtyF2WkL8YVr3aa7Au6u3MaWdL2DMKabe5e1MpAMbUIh28Dia9+JKnkr 5O6HB7yyYvqyKQSSE92810eDEwk/v8mQ5A8PmPr8puRqDU4ygXXjTZXJhwdaFQivM5CBTGCsG1Wb UCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFM YKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFu VG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFMYKwbVZtQIBMY60bVJhTIBMa6UbUJ BTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgE xrpRtQkFMoGxblRtQoFMYKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG 1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFMYKwbVZtQ IBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CAeiQ SbCcMRXCrl2cjGLljA2CTPA5C8S+jIOATPCsG6MgEzzrxijIBM+6MQoywbNujIJM8KwboyATPOvG KMgEz7oxCjLBs26MgkzwrBujIBM868YoyATPujEKMsGzboyCTPCsG6MgEzzrxijIBM+6MQoywbNu jIJM8KwboyATPOvGKML+HK4Pztgkwq5dHM6YYUzm/wH20LcVCmVuZHN0cmVhbQplbmRvYmoKMjYg MCBvYmoKPDwvUjExCjExIDAgUi9SOAo4IDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjMwIDAgb2Jq Cjw8L1IxMQoxMSAwIFIvUjgKOCAwIFIvUjkKOSAwIFI+PgplbmRvYmoKMzcgMCBvYmoKPDwvUjM2 CjM2IDAgUi9SMzUKMzUgMCBSL1IzNAozNCAwIFI+PgplbmRvYmoKMzYgMCBvYmoKPDwvU3VidHlw ZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VSR0IKL1dpZHRoIDQ2OQovSGVpZ2h0IDIwMgovQml0 c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRENURGVjb2RlL0xlbmd0aCAxNDc0NT4+c3RyZWFtCv/Y /+4ADkFkb2JlAGQAAAAAAf/bAEMADgoLDQsJDg0MDRAPDhEWJBcWFBQWLCAhGiQ0Ljc2My4yMjpB U0Y6PU4+MjJIYklOVlhdXl04RWZtZVpsU1tdWf/bAEMBDxAQFhMWKhcXKlk7MjtZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWf/AABEIAMoB1QMBIgACEQED EQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0B AgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEB AQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFR B2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AOVuHjCcsAeg qmvPykD61X8yUKQ6bsHOcU5X3R+9AE0sINu205UspLdhwaoo3OCc1IsZBwCSrc496aUw2OhpJWNJ yUkklsO6g9TUikFcE8U0EnHNBbsFzTMyW2d0lGCTWulwEQZYIfXNY8cgI7jFRvKQTkkj0NAGydQP PzAP2FPt4/Ol86d+ewp+i28N1bmRoTv6VdSEKxKrlR69qALdhbgENGoIJ6mtqGOANl1VSO9Z9pNF 9lKsRnocdqJW2kbAZFHIyKANswwuRhhgDmmeSY5AVQsme1M0+PzSrvhfQVrLGQOBwKAGQ8kNyo7V fA3YxTURio4GKemQwB4BoAsL0peo6GkUYFLQAuSOlJ2pScCj+VAFZY7j7azlx5G3AXHOasblGeRm lqKSFXBOMHOeKAJaTmm8uo6rmn57ZoARxuQr6jFRxQ+XGF3MSO5NTE8dKTPpQA1QQOuTTqBRQAf1 oz6UZo7UAHek3DdjPNLjHWs06dKdWF39pcRhdvl9v89aANGgj3pfwpNxJxigByd6ox/66T/eb+dX 1qhH/rpP95v50mBNUVxPHbx75WCjOBkgZPpzTpZUhiaSVgqKMkmuellfV5WklYwafCckn/PLfy/m DNhNRt2tmm3bVD7MEj73pnOPxzipLe6ju4HePOFJUg44I9xwfwrAtbZtSdYoVaGwiPXux9T6sf0/ n0EFtFaW3lQrhQOvcn1NAEFn/rbv/rqP/QFq1VCB3WeZIkV3kuNoDNgf6oH0PpViY3cMMkrQQ7UU scSnOAM/3aaERQ6gLeacvaXbuzbcpFkbR0wc89z+PtU/9tJ/z433/fr/AOvUOoyyrCkNu225uXEM TYB2kgktg8HaoZsHrtx3rM1R5dOkaAanqFxdFGljija3GI1XJeRmjAjXdkZJPtnkAA2f7aT/AJ8b 7/v1/wDXo/tpP+fG+/79f/Xri4NTvLm5uv8Aiq47e3hdE3JafaEQk7fnl8pFAJ6Hp+WTuxx6rpV/ EL7VI9Qtmwkp2JE8Rc7YzsVc4LArndzu6DaSQDTsX3wkCKSNEYqgkXadvbj26fhVmo7ieO2t5Z5m 2xRIXdsZwAMk8VSm1vTYdLTUpLuMWcmNkgydxPYAc568YyMHPQ0AaNFV7u9t7LyPtMmzz5Vhj+Un c7dBx9KY2o2iakmntOq3bx+asZBG5ckcHoeh468UAW6KqW2o2l3dXNtbzrJNakLMFB+QnPGeh6Hp 0xT7S9t73z/s0m/yJWhk+Uja69Rz9aALFFZ0mtWUd5Na7p5J4NvmLFbSSbMjIyVUjkU1Ne06S6Nu s7BxObfLROE80fwbyNueOmeaANOiqV1qdpaXCW8ryNO6FxHFE8jbQcZIUEgZ4yajm1qwiuEg82SW WSITqsELy5jJwG+QHigDRorKk8Q6ZFM8Uk8iNHs8wtBIFj3427yVwucjrirF1qdpaXCW8ryNO6Fx HFE8jbQcZIUEgZ4yaALtFNjkSWNZI3V0cBlZTkMD0INFAHi13IiqUjTJ6Eis+Nz5nPIqyilDljTW TA3DHNACjdlvTtmkKEnd3NN3HA5705pW42p0oARkKnBXrzUEp2yfKamLySKeME96ktLTJLvzQAyN XfA4GfSrtpboZl3ruwec1NFZRvjkhq17SyQrgn60AXIZI4ztgQBQOcHvUqxmVWZkxk80ltaLbynY Mgj1q5DIjzeX932PegChDYkfddVBP3fWtq1smiRS3zL70fZVJHykH1FW4G2qEJLfWgAVYwQqAqc9 Ksxs6ttyT9ahZQXDBuR2q5GhyDg0ATxysv3lOKnHOMVEAO5zjpU6AAcCgCQVDeyPDaySRoXdRkKO 9Td6XqOaAKWl3Ut5ZJNNC0Lt/A3arhGRgkigcDjikaQKVByC3SgBaXt0pD9aXrQADGKCaTvTZEEi 7Tx9KAH0fQUg470vegBhDb+vFO/Gl70MQDgigAo460dqBQBT1PUYNNtmnuH2oB1pbG9hvrZZ4WDI 3Qg5pupaZb6nbNBcoHT0p9hZQ2NqkEK4RBgUAWs0jAsMA7felxx7UcUAOQYFUI/9dJ/vN/Or61Qj /wBdJ/vN/OkwMe7juNR1F4ZyYbSAkk9vrnpnB/AfrBMjXdwsDhrWxhbYq7SCxxnpjJYj+fqed1rb d56l/wB3ODuGOQcAcH6D0pFtiHV3cFxJ5jYXAPy7cAZ44xQMdamARmK3wEiO0gA4BzyPr/8Ar71K /wBxvpTIojEu0MCN7Mcj1JOP1p7/AHG+lIDLVjHcPIFYhLnJ2qWI/cgdvrUt3dmW0mjVJyzoygeS /OR9Kr/aXt5pwi7y82AApJ4jT0pzX9wqlmt3CgZJMT4AraMG1fQllUatajUbi4F/psc0BNtHHc3I QgA5kOOoLMqpyONm4ZBwampavpV/Ok0n7q6jRommtr20ZZEIwyHe/wA6E8gMoPfA5pNQOnxQzXUu k6fNKTn5oFzI7HABOO5I596yJtQtLeNnm8P6JGqnBLcZOM8fu+fwolTcHaQXE0TTdNht5EGoabpq 3UbxXDyailxOYyVyi4CxqCFPzYY811Mmq6UGg0uO70ltFNq0MpN+A68BVUDOSMZ5z68jA3ciuqRu 7LH4Q09wuPmKKgP03IDVqxvbOe9S3u/DWnWpkB2HylcEjnGQuOm49e30qVG7smM3nuTqXhXUo4pV vJ44ZbdnhwwlYIcMNvHzAqcDON2OorB1zRL9dI1S2SBpbWCQvZRxIDnzJEYhVXkbMOM9w5xgcV0V rPHZxmO1tba3QncVij2gn1wPpU39pSf3U/I/41t9WmK6MzxBpV7rlvfeUyxokZhhjeM7pMFXJB3D buZVXkHhMjhqrzQ6jfT2+rW9owv4ILZ/LaLy95zKssYL/d4b36D2Nbf9pSf3U/I/40f2lJ/dT8j/ AI0fVphdGJpdje6bqOswwpKZZxaxR3JiOGfYd8vPBwdzHJ5PGcmi2huvDWsXMjW0t5aXNtGB9jtm JV48IqAbmx8pzljz26Yrb/tKT+6n5H/Gj+0pP7qfkf8AGj6tMLoyIxLa+LdXuJW1CGGQwFDBatIk 21OQSEbp04I6n8M6PT72K6lu5YLmW1i1uSZrbyzyp4WZcDccE9BkH8DXUf2lJ/dT8j/jR/aUn91P yP8AjR9WmF0Y2rlrpE1iyi1Ww1NbdkhH2Yv5gDH926ANj1BOB8wPOMBs63o8S213dC9tC2lqksln bmUCXfkp91x6/kOfXb/tKT+6n5H/ABo/tKT+6n5H/Gj6tMLo5fVNPvby9165hguZLZzaSm2MZT7W iqCygkbgRjtz2xnFbNszaf4i1G8mguWttRjheJ4oHfbsXBV1A3Kec8j17jFX/wC0pP7qfkf8aP7S k/up+R/xo+rTC6NKNi8asyNGWAJRsZX2OCR+RorN/tKT+6n5H/Gij6tMLo8ldCw5BqKRtqhecCp/ PLIDwM+lIIhIvPWucZWABwM04A/UCporZl5PaporZiScZGe1AFUHAxjHNXI25AwNv1pr2pbcVGat W9tiMMRQBbtyBggfjWtBFhN68etUrSLdxgVpxIoj8tzsDdCKAEluGt4TIELeuKW0U3DpMgCt160r 2xETK3C+ueKZakwOvlDcQcHnigDchlYj58KfSrMcR3bqy5VYuJE+Zu+O1XbGeWXIx045oAsgZYHb tYnBrQjQDknNVVY55XrVmMHHWgBzJk8GpVbFNXrT9o60ASUo5HTmkAp3GfegApCB1xS89ulJQAo+ lFRyCTI2EDnnI7VJxigAA4pqjbn39aVwSh2nntTIt4QeYQW7kUAObOPl6+9LnHXrRjmgqM5NAAcg 1kaprtlp1xFHcShGc4Ga1yAc/wA65vXPC1vq17DcSEhoz24zyKAOhilWVA6kEH0qQ1XtoBbxLGo4 AwKnz7UAL3ppyRwcc07qPSmFPmDZPHagB9GBSDp6UtADlqhGcSzEdQXP6mr6DAqgn+sn/wCB/wAz QtwMnWtebSrdG2LNNI21I8hc9yScHgeuDyQO9c/F401ONws1tbXG4jmMGIRjuzZ3fKOMnjH41f8A FOmzXkENxbI0stvuBjBGWRsZx6nKr36Z6nFedTX07u/kHajK0Zwv3kPXr64HSrdGvUq8tFdDrtQW ElL/AJeN2W56Umv39swe+NvJASAzxRlDGOmSCWyOcnkYAJ5rWubiU3Nku8hWlYMBxkeW5wfxA/Ku F0u8udftpbRbciQ4SWReEVG6nk5BwGA68gV2s/8Ax+WH/XZv/RT1jh1WUZwrrVen6aHjYOdZpqtu hkb7NXQ/9N2/9FLWXpM+uahpQuNYd7dYIpR5ewI9wxDDc4wMKAcBe5G49q0LixkvZZvLKDZMc7vd E9qg/sO4/vQfmf8ACuuEIyim5JHY7mDf3PmXgG13jtjyEXJ3kf0U/ju9QBWZeyQS3KTx3kAcRtGY 5JdhTP8AEvdW7citq78JPBHcXUmpXEMS75nCTEKo5Y4AX61T/wCEfP8Az+63/wB+Lj/41RUXPJyu ho5ywsXkSV0JupZgSsgRlVGBHz+YwByDngZziugkI3x2rySG5eMMsuw7QyEENjoDnnH0B7VVuLfT bWdobnXr+GZcbkk85WGRnkGP0q1puj22qybLHW72U4Y53yKDjGcEoBkbl49xUez80Fy7d3X2nw/d SY2s0EgZc52sAQRnvggjNZaJHa22hy2caRXUrRq5jUBpEK5fIHUdDk9K6S08LzWsEkJnWdZWLOZn LE5AGDx0wKkh8NG3cvBFaRMRglF2nH4Cu7nhKzclcnU5S2X7Ey2s5iD3KStFqUTYYjBOX7ng56kd PTNWtIAtrg6bPaxw3C24Jmt2IEq5xk4wd3v164xnnoo/DjxStLGlqkjZ3OowTnk5OKSPw0YkdI4r RFkGHCrgMPfjnrSi6aa95BqYtrHb219LfwtFa2RhEeAAiOd2d/pjnAPfJ7YzVihW48R6nvtLa4UG HJm6oNvYbTn9OgroR4VRQwW3sQGGGATqM55+X1AqddBmWR5F+zq743MM5bHTJxzVc1N295Bqczqz x3mqaQYlgu0bzsK7ZRvlHfB9PTtUVratFf2On6g4uIYrVmRXGUaTdyBn72FOBnoOcCuoTw46eXsS 1Xys7MDGzPXHHGadN4ekuECTrbSqDkB/mGfxFK9Nu7kr/wDDBqcdBDPdQp5JiuIbW5m8m2mOVmiA AGCeuM4BOcZ69qc7rcQQanDbwz20Vu2+ymbPljccsucgdCOg4XA9B1snhx5YlikS1eNcbUYZAxwM DFJJ4aMqIkkVo6xjCBlyFHtxx0qf3f8AMg1OVu5kmvJ5I9+x9GYrvOWwTxk+tbmkvjSLIf8ATBP/ AEEVov4ekd2d1tmZk2EnklfTp09qcmh3CIqI0CqowACQAPyrSEqcXdyQalfzKKtf2Ldf34f++j/h RWntaX8wrM80tbVntUfrTY0cTkNwnatjR51a3WCRAHTgkmrs1sitmQAL2NeMaGMoA+7yPSrVico4 xz2NTmKN9/2bBdetNjtpS4aI7f7wxxQBBa20ss0gRsknlaneF7ZfKmzuPIpieZY3TPvw7n8MVs3d qL6x80nEgHVetAEembHiHGW71aum8tlXGPQ1j6fcNpsoSVc7zkFj1reuf31sJl2lumBQBIjCWHnB /rVPzxG+fLZS3GCKu28RFqpI+Yj1qaO2DOCy8e9AEVuwkO2M4J6irkIlimVQfqfWqohdbkNGmAOp 9a2YlU4OPmx1oAlU84I5PcU8lgcg0sYB/CnMNr4J60AEcjbgjDLHuBwKtKPl5qncz/Y7SWcIzlVz gdTTNF1FdVtFn8p489AwwaANKm7Rv385xin96guXlQL5UYfLYPOMCgCbtzR0oHTnrRyRnp7UALnN HaqmoXyWEAlkVmBOPlGaso4dA/YjNADuPWjPFJ05o3DdjvQAjNgj3pxqMnYWd2Gwe3SiOVJk3Rsr j1BzQBIKjeMmRWDEAdvWnnpS0AFFR5dVYtyO2KybC/m1G9kwkkMcDbSrD7/vQBtUdRzRnA68UgOV yKAAnAqOeV0ClEL5OD7VLnj2o47UAKmcc1RT/WT/APA/5mr6d6zW83M/kIryEsArMVHX1AP8qOoF G9u47K2M8quyBlXCLuOWYKOByeT25rzLUtHuIJZ3trdhADIwjZl3whckhhuPAGOckEMvOWAr0y5s NRuYlje2twBIkny3DdVYMP8Aln6gVVuNCup3una2hDXMTRORctwGAViP3fUhU9vlHqc91LFyotyp slxvuZXgrTJtPivWuSFuGdUeIc+XtGRk9DkODx6/gOgn/wCPyw/67N/6KemWmnalarJ+5hlkkbfJ I9wcucAZ4jA6ADgDpUjW959qtXuUtokSRiNsxYsfLYYAKj1z+BrOrW9peUnqxpWBEje6Kyorobrl WGQf3NWb62sVsbgpbRKwjYghBwcVDFCJpLj52QpOGBXGf9Wo7g+tSvZmRGRrqcqwIIwnT/vmuZWs DI7gpcalb20jqsMJS4mLHAJ3YhX6lxnj/nngj5qp+J7e6a6CCGRtNnhk3i2V8yXG3avn+X85j2gD 5e4GeMVVks/ECzXaxw6HPBNO8oN0sjMQRsGQOPuYXjtnrkk1f7L8SDhDpsa9kjvbxEUegUOAB6AD ApDMrSL3WdPjvbieGPSWk+a1gS0ij+0SKwxD5e3zHB34DA/Lzya7W/tGu1gvTb28erxwrNDF8plB X/WR784KkPszjALbueMYWmaZr2kqBYWPhuBgCu8LMXIJzgseSM+p7Cpnt/E0moRXz23h1ruJDGkp WbcqnqP5/mfU5ANTUL3/AIp66v7OT/l1eaF9v+wSpwfw61jx6hf2VpoV7LeSXaag8UMsMiIoUyLk MpVQRgg8HOQe3WtGw0+8k0q+tNVa3U3TycWhbaiuPmxu5yWLHnPX04C22gwwtZ+dc3N1HZAC3imK bEIAAbCqMkAcE5xk96AMnTNW1CTzoLqeSPWwkrLYTwqsUmM7fLYYJGcDJY5Ab/eFrw7qUt7G0Ml/ L/aKQAzW13bhWifswChcr3xycFeV73v7Dhe8iuJ7m7nMCOkKvIB5QcYOGUBiccZJJ79eadDo6xXk t493czXbweQsz7AY0yTwAoXrzyD0oAhsnv49fntWuJLuxS3VmlkVA0cxb7nygfw4JBBxx0zzRF9c 3HifU7F769ghhMIhW3t1cDcmTuby2xz3JHf0rQXRGWye0Gq6gI2GAVaNXU7gxbcqA5JzkknOTnnm nHRQupXd9b313bS3ezzRGIyp2jAxuQ4oA5+21zUJNa+zpdSSynVZLcW7RKI/s6gliG2j5l/3s9OD nnS17Ubmw1WHz5rm00kwEvc28Kvtl3cB8q2BjGOOS35Wm8OWZhlQSTqz3v29ZAw3Ry+o4xj2IPWn Poe/T/sZ1LUCjRtFIzyK7SqSepZTj7xGRg4xnOBgAzbvU7g+IYLX+0J1tX09Z91jbCTe5fG4Da5C kf059aOpa1qNrq2oWkF7K80ElrFaQtCmyZ3A3B228Z5PVe+OnHQNoMK3kN1a3NzaPDbLaKIijDyw cgfOrfn7U2bw5Z3C6iLiSeU6gkazMzAHMYwrDAGD39M9scUARrc3eo+IL+yiupLOCwSMHylRmlZx uySwIAAGMAd857VtxhxGokZWcAbiq4BPfAycfmazn0dTdC6hu7m3uWjEcssWz9/joXBUqSPUAdSO nFaMaCONUUsQoABZix49SeT9TQA6iiigDzW8sjFeobdfZsVIzvLG0AhLN6ntW5FDIgObRyScn54/ /iqeqyKS32JgT6PH/wDFVHtI9yuSXY5+Cya3jIZWUkZ4FXrS5QRmNk2t6+taMi3Bk3JbSbduCC8f /wAVUUds45a0fd7PH/8AFUe0j3Dkl2MuSxmmvUeWPCDowrSVZQghWLBB6gda0PNcxhDaTY7/ADR/ /FVLHduibRZzfXfH/wDFUe0j3Dkl2M690yC+siNm2Vec4qhplqba2kWVnLdlroo7vBJeymOfRo// AIuq0rF9220mAP8AtR//ABVHtI9w5JdhbCOQ2ieYm1/TOcU7LLKRg5NNjmmTaPs020dfnj/+Kp7z vjKWc2/1Lx//ABVHtI9w5Jdi5DEPL5BqYLmMkc1Qt72YL+/tJd3+y8ZH/oVTnUWwALKf/vqP/wCL o9pHuHJLsX4DuXOMGnKAz9OazxqRHSznH/Ao/wD4upU1RV/5crjP+9F/8XR7SPcOSXY0wFdcEceh FOSNY0CqAF9qzRrC4x9iuf8AvqL/AOLoOs+llcf99Rf/ABdHtI9w5JdjScOUIQgN2Jpy5AAYjPfF Zn9sjP8Ax5XP/fUX/wAXSDWR/wA+Vz/31F/8XR7SPcOSXY1D0pay/wC2R/z5XP8A31F/8XR/bI/5 8rn/AL6i/wDi6PaR7hyS7Gk6K33gCPen9FwO1ZB1ng4srj/vuL/4ugaxn71nc/8AfUX/AMXR7SPc OSXY1uMUmOe2ay/7ZGP+PK5/76i/+LoOsA/8uVz/AN9Rf/F0e0j3Dkl2NC6EZtnEv3MfNx2qDToY La0SO15i6g5zVZtXRlKtY3BB7Fov/i6F1dFUKtjchRxgNF/8XR7SPcOSXY1agkuQtwkRVssM5xxV L+2R/wA+Nz/31F/8XSf2wuc/Yrn/AL6i/wDi6PaR7hyS7Gpj8jSBFQ5AAz6Vmf2yP+fK5/76i/8A i6P7YXvZXP8A31F/8XR7SPcOSXY1eDVdWn+1MpRfI28Edc1T/tlf+fK5/wC+ov8A4uj+2R/z5XP/ AH1F/wDF0e0j3Dkl2NPmgn161mHWQf8Alyuf++ov/i6Q6upYN9iusj/ai/8Ai6PaR7hyS7GrGWLt kYGBiqSf6yf/AIH/ADNVYtXKSSM1rdMGIwN0XH/j9RLqRDSH7HcfNux80ff/AIHTVSN9w5JdjP1f VLnTpB5di08ATfJNiTbHyAclY2GACW69FPHTNC18SX15BHNb6PJJDJjDp5zL1UHkRHOCWzj+43+z nYvbx7jRL6yS0mEtxDJGpLx4BZcDPzVD4WuJNG8PWthc2krzQ79xjeMqcuW4yw7GtJV1fRh7OXYy pfFF3BLbx3OlNbyXBCxrKZlLE7OAPK5I39s/dPXK7ti3nluV0uae3a2leRi0TBgU/dycHcAc/h9M jmqPiRbjVtX0O7t7V1jsJ/NlEjxgkbkPy4Y8/KeuK0by9ee9gmSzmCxyFiC8ecbGX+96kUvbppps PZy7F9U2M5Riu87m9zgD+QFOy/8Az0b8h/hVL+0G/wCfOf8A76j/APi6P7Qb/nzn/wC+o/8A4usv aR7j5Jdi7l/+ejfkP8KMv/z0b8h/hVL+0G/585/++o//AIuj+0G/585/++o//i6PaR7hyS7F3L/8 9G/If4UZf/no35D/AAql/aDf8+c//fUf/wAXR/aDf8+c/wD31H/8XR7SPcOSXYu5f/no35D/AAoy /wDz0b8h/hVL+0G/585/++o//i6pX5N9cWYktbkW8cjNMqTqjMuwgAFXB+9tPXtR7SPcOSXY2sv/ AM9G/If4UZf/AJ6N+Q/wrH+yaT/0D9U/8D2/+PUfZNJ/6B+qf+B7f/HqOePcOSXY2Mv/AM9G/If4 UZf/AJ6N+Q/wrLgsNEklWOSDULdnIVPMvJSGJ7ZWQgfjjOeK0f8AhGdL/uXX/gbN/wDF1Sd9iWrb j8v/AM9G/If4UZf/AJ6N+Q/wpn/CM6X/AHLr/wADZv8A4ukbwzpgUkLddP8An9m/+LpiJMv/AM9G /If4UZf/AJ6N+Q/wq8/yNtX5VAAAHAFN3N/eP50DKeX/AOejfkP8KMv/AM9G/If4VD4juJrfw9qE sMrxyLAxVlOCDjqDU1ABl/8Ano35D/CiiigRhebR5tVMH1NGD6mvHuerYt+bR5tVMH1NGD6mi4WL fm1LIVS0jnDkhn8thj7p7fnWfg+pqxbXEcKSpcxyTQOASiY3ZByCM1cLN2ZM7pXRbZVW6S3aTD+Q biQkcRp7+9QxTw3Fm1zA7mJXCN5ibTz0PU8GqVpcySXl9eXMTH7WGjaPOCEPAA/DFRS3H/EuOn2k FxiRlMksyheFOQAAT371vy03sY3mal+6WEjRyi4LqFO4Q/Ic+jZ7fSpPJmBjBCgyDcgLqCw9hnmq MmptBb3cEAv5/NQoizBdiH+8Dknj6Cpb6aC31HTZ54riWeK0jYJEoIPJ9SMc/Wn7OD1FzzWhIrFg SWRQCAS7hRn05NPCSl5E24MfL7iAF+pPArNjuv8AQpWuLdxcS3BlykKS7VJztw/A+tSz3yXkuqh7 e5S2u/Lx8o3gqBzjODyOmalU4W1ZXPK+iLce6TfsKMqDczhxtA9d2cUkjNG21xg4z1zkVStLmKG0 u4UtpUjmCjLRIzZHfa3yn6ZqESy3FyHd7gqsYjHmxpHwCcYC8Dr71MoRUbp6jUpc1mjTuporSC2k lM7tcbtqxRhsbTz1YetEJkniSVIpArvsUOAGz7gE4qtd3uba0gWXUofJDbzajh8njneOn9aSy1Nr FFWCG6meaT969wcEJ9QT8x9e1XyQdieaauXfLk2SPmMJG5jdjIuFYdQTmnBCkd2ZQwaCBpQARzgZ HPpWe8donh0RtHcrD9v+T5QXPy5GRnB/P3obUWke9cWs6Qmy+yxJgbiexPOO56U/ZwWtxe0k9LFy ISSwxyhcCRN6qWAYjuQM5NEgaK3W4lZI4WzhndVBx9TVRL9IJLS7NrcPcwWvkqiqNhODgk5yOvoa qyu01rpVs8Uha2V97EfLyeP5VLhBa3Gpz2sa7JKiksAMKGK7huAPQkdcU2fdbojTskYcArukUFs9 MDOTVPUr95pZ3iFxG00XlssdvEQeMcufmx7YqG8cXl7bkxSbYbVIi0gGGYZzjn3pShBK6Y1Obdmi 95tHm1UwfU0YPqa57m9i35tHm1UwfU0YPqaLhYt+bR5tVMH1NGD6mi4WLfm0ebVTB9TRg+pouFi3 5tHm1UwfU0YPqaLhYt+bR5tVMH1NGD6mi4WLfm0ebVTB9TRg+pouFi35tHm1UwfU0YPqaLhYt+bR 5tVMH1NGD6mi4WLfm1HCYPs8JaCFmMaszNGCSSASSTUGD6mqzb/sybCd3krj67RVxbsS1qambb/n 2t/+/S/4VHMYPs8xWCFWEbMrLGAQQCQQRUedM9dX/OGqa7/sz7yd3ktn67TV6prUjRp6GjG0TGVp Yo5G8zaC6hsDapwM/U1LHHC8SyMulQhi21ZnVWIDFc42+oNZvOH5P+tP/oK0gKNHEGadHRSh2xK4 PzuwOd4/velOL7ikuxosIUleN7ezJUj5o0VlYFQwIOB2NQxmMzlHRXjTzdqsMgYcAcH0BxVRm3SE pvCBUQbwATtRVzgE46etAz50vJ/5a/8AowUm9XYaWiuacMSTtIIbO2fy1DlRGu5hnnaMc47/AFHX NE0SQNGJrO2TzFLhTGu5RnjcMcZ7fQ9MVUsboWc7TmNpJkX9xk/IrHIJbnJ4PAHqenBBfXQvJ1nE bRzOv7/B+RmGACvORwOQfQdeSauuS99RWfNa2g+Tyi8kaoqxyRDcqjAOSwPT2ArU0a7u57XTzdSy i1dVYTNw0kmB8rH+7nOD/FgD/ewhkydT/ql/9Ceuv0OVBoOnAkcW0fcf3RW2Her+RjXWi+Zp01/u N9Kb5yeo/wC+h/jSNKhUjI5H94V1nMQ3KJL5kciq6ONrKwyCCOQRXAXXw/3a2n2ebZpj5ducvH/s DPXPY9uc5wM9hf6zb2128RhvJSMZaG1kden94DB/Cq//AAkNt/z6al/4BS//ABNIZFr1rBZeD762 to1ihjtmCqvbj/PNaNYeuatHfaJe2sFnqJllhZUBspRk4/3a3KQBRRRQBlf2HqPpa/8Afxv/AImj +w9R9LX/AL+N/wDE10u+jfWX1en2Nfbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8AE10u+jfR9Xp9 g9vPuc1/Yeo+lr/38b/4mj+w9R9LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/wDfxv8A4mj+w9R9 LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/8Afxv/AImmDw5erM0oS1EjDBbzG5/8drqN9G+j6vAP bzOa/sPUfS1/7+N/8TR/Yeo+lr/38b/4mul30b6Pq9PsHt59zmv7D1H0tf8Av43/AMTR/Yeo+lr/ AN/G/wDia6XfRvo+r0+we3n3Oa/sPUfS1/7+N/8AE0f2HqPpa/8Afxv/AImul30b6Pq9PsHt59zl 5PDl7KyM6WpZDlT5jcf+O0/+w9R9LX/v43/xNdLvo30fV4B7eZzX9h6j6Wv/AH8b/wCJo/sPUfS1 /wC/jf8AxNdLvo30fV6fYPbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8AE10u+jfR9Xp9g9vPuc1/ Yeo+lr/38b/4mj+w9R9LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/wDfxv8A4mj+w9R9LX/v43/x NdLvo30fV6fYPbz7nNf2HqPpa/8Afxv/AImj+w9R9LX/AL+N/wDE10u+jfR9Xp9g9vPuc1/Yeo+l r/38b/4mj+w9R9LX/v43/wATXS76N9H1en2D28+5zX9h6j6Wv/fxv/iaP7D1H0tf+/jf/E10u+jf R9Xp9g9vPuc1/Yeo+lr/AN/G/wDiaP7D1H0tf+/jf/E10u+jfR9Xp9g9vPuc1/Yeo+lr/wB/G/8A iaP7D1H0tf8Av43/AMTXS76N9H1en2D28+5zX9h6j6Wv/fxv/iaP7D1H0tf+/jf/ABNdLvo30fV6 fYPbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8TXS76N9H1en2D28+5zX9h6j6Wv8A38b/AOJpg8O6 gBhWjUdgtzIAPwArqN9G+mqEFsHtps5f/hH9R/56J/4FSf4UHw7qBGGaNh3DXMhB/Aiuo30b6PYx F7aRzB8PagWLAwqT12TuufyFJ/wj+o/89E/8CpP8K6jfRvo9hAPbSOX/AOEf1H/non/gVJ/hR/wj t9hQBbrt6FZnB9+QM11G+jfR7CAe2kcv/wAI/qP/AD0T/wACpP8ACj/hH9R/56J/4FSf4V1G+jfR 7GIe2kcsdCvogzHyCSOS0zMT+JFS6VDH/ZNlkSZ8hM4mkH8I9GrfnOYz9DWHpXOlWYYD/Upjv/CK 3oUopsic3JK5Y8mL0k/7/wAn/wAVTXt42RlDTIxGAyzvlfcZOKmppDFlIbAzyMda6eSPYzuMEEYw MTN7+fJ/8VS+RF6S/wDf+T/4qljlEm7AI2ttOeKXepcxhhvABIB5APQ/oaOSPYLjfJi9JP8Av/J/ 8VR5EXpL/wB/5P8A4qgnyotzF32LyQMk/gO/4U8cKMknA6mjkj2C43yIvSX/AL/yf/FUU+ijkj2C 5d30b6kaBQM7m/T/AAqEYOcJKQCRn5a5Sh2+jfTcf9M5fzSjH/TOX80oAdvo30qIrx7wzDIBGQP8 KTy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2 j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfR vo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KA DfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5 D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cj y/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+ Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgB GOY3+lZGl/8AIJs/+uCf+githl2xvyTx7VjaX/yC7L08hP8A0EVrS3YMtg5JA7Uue2cZpoVQQdoy AQDjoDTs1uSQ20csceJpvOcnJO0L+QFTUgIIIFIxbK7VBBPJJxgUAQyzCBk3lAjcZZ8EtxgAd881 Pn3qrc2UN3IpuIo5FQq6buoYZ5qwyKVxgdc8jIBHSgBQSoAO5uOpHWinUUAabHIqurFYsgZJcgZO OrYqQNk1Cc+TkAnEoJwM8B+a4ZXs7Frcf5vrsP0fn9cU5HDEjGCBnqD/AC+lUL2+aC3Zo0eMZAJ8 ogDJAyeO1Ns55P7TaE3H2lGhD7iOVwRx0HXcfyrnp1JOVmOdo6GjB/x7p/uin1HCf3Mf+6P5VJXU SFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADJP9W30NYulf8AILs+v+oj4/4CK2pP9W30 NYulH/iVWeQP9QmPf5RWtLdgyyWGSNygggYNMaRklCsBschU2gk55Jz6DjrTmdR1xmlDgnityRSA OeeKUDGff0o60hUbg5JGARjPH5fhQAuT+FIE2liufmOTkk//AKqU9vSloAKKKKALi5DDIOPpSKXU EBQRknqe5+lRf2HF/wA/d5/38H+FH9hxf8/d5/38H+FcgyYs7KQ0akHggk8/pUcESW4IgtoYgeSE G3P5Cm/2HF/z93n/AH8H+FH9hxf8/d5/38H+FKyAnjBVY1/ujB49qkqoNEjByLy8B9pR/hTv7HX/ AJ/r7/v7/wDWpgWaKrf2Ov8Az/X3/f3/AOtTJtNWFVc3t6RvRcGXIOWA9vWgC5RWRKgN5feZcXix QeWFWFmY8j0AJNJaJbXjEQXmqHGcl96Dg4IyygZz2osBsUVR/s1f+fy+/wC/3/1qP7NX/n8vv+/3 /wBagC9RWathm4kj+2Xu1UVh++5yS3t7CpP7NX/n8vv+/wB/9agC9RVH+zV/5/L7/v8Af/Wo/s1f +fy+/wC/3/1qAL1FUf7NX/n8vv8Av9/9aj+zV/5/L7/v9/8AWoAvUVR/s1f+fy+/7/f/AFqP7NX/ AJ/L7/v9/wDWoAvUVR/s1f8An8vv+/3/ANaj+zV/5/L7/v8Af/WoAvUVR/s1f+fy+/7/AH/1qP7N X/n8vv8Av9/9agC9RVH+zV/5/L7/AL/f/Wo/s1f+fy+/7/f/AFqAL1FUf7NX/n8vv+/3/wBaj+zV /wCfy+/7/f8A1qAL1FUf7NX/AJ/L7/v9/wDWqKO1glmmhj1C8aWEgSL53K5GR29D/nFAGnRWdDZR XEEc0V9fNHIodT5uMgjI7U/+zV/5/L7/AL/f/WoAvUVR/s1f+fy+/wC/3/1qP7NX/n8vv+/3/wBa gC9RVH+zV/5/L7/v9/8AWo/s1f8An8vv+/3/ANagC9RVH+zV/wCfy+/7/f8A1qP7NX/n8vv+/wB/ 9agC9RVH+zV/5/L7/v8Af/Wo/s1f+fy+/wC/3/1qAL1FUf7NX/n8vv8Av9/9aj+zV/5/L7/v9/8A WoAvUVR/s1f+fy+/7/f/AFqP7NX/AJ/L7/v9/wDWoAvUVR/s1f8An8vv+/3/ANaj+zV/5/L7/v8A f/WoAvUVR/s1f+fy+/7/AH/1qP7NX/n8vv8Av9/9agC9RVH+zV/5/L7/AL/f/Wo/s1f+fy+/7/f/ AFqALcn+rb6GuU0+9zp9vGvylYVGT3woroNNLPo0Ujszu4clmYknkjv9K8tXU5mEa4OyJSnBHHb+ laUt2D2OyN8AM7uB+tXLW4EnYgY71xEV60zqPMIAIHH61tWM7LKo3HGOBW4jqo2LDJGKQBnMgkAC 5wpVzkjA69MHNVbG6Scbgwxkr17g4NXu2MdaAA8Y6+lNRw6kqc8kfkcUixKDjcSoAG3sMd/8+lPK glSQCV5BI6UAKBx1oqNFlDyF3VlJ+QBcbRgcH15zRQBv0UUVxlBRRRQAUUUUAFVr7/UL/wBdYv8A 0Nas1Wvv9Qv/AF1i/wDQ1oApW3/IV1L/AHo//QTUEFo02mTQtmKQzzOjFfut5rMjY784PoakijWT U9SDbvvw/dcr1GOxHrVgwW4cKRc5zjPmS4/PNNiRg3Z+3XFjeXds5RJjCIUO4j92/m9MbhuG0jnI jOM7sF81u7WreRBssvte4RPbMyiPysf6oYOPM5xjr83vW1Bp1rtSMxsPJxs2zPhRggbeeOMirH2C D1m/7/v/AI0hmbo6eWjrvL/IpGYmiwN8mAFbkAdAPQCtKobmGzs4HmmM4UlVJV5GYnOFAwSTy3Qe tRI2ntFJJvukEeNyyNMj88DCnBOTwMDk8DmmBboqh5+ndP8AiYBuylLjcR6gYyQOMnoMjPUU5pdP RUZ/tyKw3bnW4VVGSMsTwvTvjjnpSAu0VHPbWtvBJPK8yxxKXdvOkOABknrTbaC1uYy8Yu1AOP3j TRn8mwaAJqKqQtp885hR7reGZAWaZVZlJBAY8EjB4B7H0pyfYHuTAslxvyVBMkoViOoDZ2kjByAc 8H0NAFmiqH2jTeu69KdnAn2N6Yboc9sHnIxnIqSJrCV0QG9RnbYol8+PccFsDdjsp/yRQBboqOC2 tbiCOeJ5mjlUOjedIMgjIPWpPsEHrN/3/f8AxoAKKPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo+wQe s3/f9/8AGj7BB6zf9/3/AMaACskW8y3l5dRRnzknGwHgSRmOLeBnj+Hg8cqOcZrW+wQes3/f9/8A Gj7BB6zf9/3/AMaAOVu4Zl0e1X7MRPHYoI2Nu8riQL0XH+qYHHzHrkf3auS2gne7uVhmEkl3D5b4 ZXWMiIMV6FeNwJGDxg9ON77BB6zf9/3/AMaPsEHrN/3/AH/xoA5+6tZEjliihC2iXgPlmAyR+X5I 6RjG4bznjvz2NamlJ5enxrvL8sRmJosDccAK3IA6AegFXPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo +wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAaPsEHrN/3/f8AxoAKKPsEHrN/3/f/ABo+ wQes3/f9/wDGgAoo+wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAaPsEHrN/3/f8AxoAK KPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo+wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAa PsEHrN/3/f8AxoAoaX/yAoPo/wD6Ea8abMkzANt+YjjvXtkKJHYeXEpVEaVQCc4wxrw8K32xgpxl /wAK1pfExdC1bs6qu1Mjsx7Guisz5U0PmsMjG48DPFZaxt5ITcRk5LHtWhaKjzRszFyPmPBxW4jp bSSN5QYySQcZ54FbC8jNZVgVaYlQQMYxg4+taqZ2gHqKAALh2bcSD0XjAp1JRQAoooooA26KKK4y gooooAKKKKACq19/qF/66xf+hrVmq19/qF/66xf+hrQBRt/+QpqX+/DViaAM7HYDk/3R/wDEmo7E A6vqeRnmP+RrSpsSIIF2uVxjEa/1qxSYGc45paQyhrO77CGVHfZPC5CIWOBKpJwOTwDVadory4W5 khuPssMLxtmCRXLMyEbVxu42ZyBxkYPBxsUUAYYl3Q77h74MrkW9ylqxlKYXduUJgfNkYKjO0HGQ DTrq6llghtL+CaMSwK1yYYHkBJGGjUqDjvk5zjGOTldqigChrG6XSdQgjR3kNs+FCE7iVYAD1PHQ c9PUVPAjW6qktxNcM7cO6LkcZx8qgAcHk9z9KsUUAZOmWDAmaeSY7LmeSOFwoVCXcBhwCcqx6kj5 vpiGGOQ6dZaZ5UouLcweYxQiPEbKSQ+MHO3gDnkZAwcblFAGGjxZkjWO7bTgmWje2kUwtuXYIxtD f3jxnbtGNoxTovtM0tkziaWOO8YpJLHscp5LjLDAx8xI6Dt65O1RQBS0ZHj0WwjkVkdbeNWVhggh RkEVdoooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KAM9P+PR/wDrpN/6G1eGSHFwwA6sTXuaf8ej/wDXSb/0Nq8dtIGa4YhRy351rS3YnsWNOtpJ4y8j ZfPyr6D34rpbBZNqcbYumODk1TiRoxGAMLkZPetq12yZ4IIIyMcVuIv2qKoG3P4ire4CQJhskE9D j8/xqKLgjH5VMDxQAgABJAwSefelIBGCAaB6c0dqAD9KKrXk11Fs+zQxy5zu3SbMfoc0UAdLRRRX GUFFFFABRRRQAVWvv9Qv/XWL/wBDWrNVr7/UL/11i/8AQ1oAq2H/ACGNT+sf/oJrTrMsP+Qxqf1j /wDQTWnTYkFFFFIYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAZ6f8ej/APXSb/0Nq84stOmktonRdsgO9SRw wPY49a9HT/j0f/rpN/6G1c3pX/IPtD32KM/8BrWluxPYzoIN8bGRCpLAlc9OBmtW0hESrnk+tOu1 VVfaAOnQe9WIAAcAAAdPatxEkSOGUgqFwdy45J4xz+dTc5Pp6VHCSQ+SThjUp6mgBozvOSNuBgd8 /wCcUkhZQCoycgYyemeT09KX1PenCgBjuExkE59BminUUAf/2QplbmRzdHJlYW0KZW5kb2JqCjM1 IDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCA1NTAK L0hlaWdodCA0MDAKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVjb2RlCi9EZWNv ZGVQYXJtczw8L1ByZWRpY3RvciAxNQovQ29sdW1ucyA1NTAKL0NvbG9ycyAzPj4vTGVuZ3RoIDE2 Mzk3Pj5zdHJlYW0KeJzt3QlcFHXjx/GZ3YXdBZZbUA5BQFHDW9EQLbw1NY8K1Kw8y8wOy3w6/PdU lqZlmaV5dJtWlpZHpuVjeWR55F2IFygqKsgNy17z/+2Obtses8ty/Bbm+3568QzLzG+GFfbD7PVj OY5jLEwY0pkBAACoDR//8Kflp6w5OTNGdiur0r/+zERfpZyVetE4NgAAaCQ4vba8sur5Nz/yk0uX bDjAX3gzOeTk5qUZ4wJVPgZ1ib6y2KAupnqoAADQsLEyOStTSJUBRVfOvrr2IH+6Y0wO6c1b/5mk VxcbKotIb2gfJwCAWKzYcqyGI0y9q72HjyZThV++eH7xxpOkOsbkpPfr+P6LE7U3stEbAIB6s3Lr iQHD7+3UNt7tEQ7/dXb7xnVTBid5+GiVGt2LXxz96ucjbFq31l/Om6qvLNIUZLs9NAAAVNeqH/96 9tlZldn73B5BGXv7ggULJw9q6+GjkeQYDMxjH/5pTM7a1yap8/42aNVuDw0AjHeXZvfPVDB/X109 t0JD+2CgIfhwe+YzT88sP7vH7RF841PffGvRpAGtPXw0oqJKN+PjY2zntnGbF00tv/Cn1dpLfimW yJVOB1XpC8alNJVKWLcPCzydV9uw9Jf8lSUlmx+/dqXSfLGk2cMxQ/tIK/936avllVqGVXUJ6jbK v3mCzIthtPnqC/8rPLCxvFTLr8z6dg3u/UBAVLiEfMKp9Td25W36sFJL5xu6ybtr5IOzbH7E/7ry 6cvl7gXj5oD75/SZ3mF0XEfvGh8hNHYf/ZQ186knS7N+cXsEVas7F739zsT+rRyNtvaXLIHNx9zZ qlqjncguOJ5dYLUhv4t2sSFJsSGORmNMyZmw7IgxORsXTi7LOWh1KE/uDLpS4fyXJqhw/zv3RSm8 pU7XhAZL5t1hQYuUGPWuJ97eeWFUmMR0ob/f4A8iY+UXlt41+csbT0568I6xj/gyR/cueHHZz3lc 0vhZCx/vyO3/c/VCX52BkYQF3v1+eNOiY/PHvbQ5X94qbfiYzpnLlnS/s2kCxWfjeydHT5rtYyzE g3vLLL/g+8i4mA5uBOOfASeVRASP6B4aIautY4XG6eMdp5964vHizB1ujxDQuu/bi9+d0Lelo9G+ 2nV2zuf77W776vjk9N7/eqjG9dHM29peYnc0xpScyStPGJPz3RsTyrIPWB3NXsWwgQMGsBIj1vh/ txb//f/z/vPI6BaFSE4jp0hRPTg7Snpo0dhp/u2b9vRnGb/+sQ8+ptTumXv3w39Im457ZVNGZ/np uX2nbbnRMkoRoZTKu7339IwuVTsf/2h3dt+mXaMn/5+f5NR7I+7dL1Ek+LBajTb3hiGsRdDQLv27 PPK8D3Mu/7fTPu37+Ph5Merskj9X5B0+qb/5gjGpd6dF8T1jjYu6gspz31/dtbFSbfoa66dMejCs U6qPvw+jyS7+fUne8TMG8hVJkG/nKWEdeiiUUqbqQumRD/MOHSHhs+bdPWbq87cK4dtEcutySUji 1NX3pvhX7n0y5/AFjvGWd369RUpL/al553dzkZMdH+2/Bgy6Ozmh5e2PhLXvJpezTFVu2bGP8w4e 1OrNq50vOHDZr0NPudeJ3JUvlOocHLPdlXGvXWPxyf/OPjFjeuHJ7W6PEHTbgMVL3n+oT7yj0dbt zf7v2sN2t/3vmE738r9Zbo1GNjd+tPhUYDTGlJypH2Uak7N+3gOl560z+IffKFeS8/qzU0fE5CM5 jZ2C7b7yth7BOUuHLzpW8UBrX//kJS1TmhdvuH/s/KNxbXtOe/+Dtj6Z7959z6+MT8cg79ZxvtHB Q+Ife6JJ8fqZ495I6dO777SFQUqG0V46fej3ihuZsnO/nTxdqmbY6Fb9kqfP8WWY8r0Lvvtuy94z Tds8s2pGT9/c9ZMuX7jmw5IAhAUk9y7a/tmz2yoiBs1798U+0v3P/bLraJSXt7zrwpY9W+pOLXn7 /z77X3FM2gOD/Q+u7dpcFdjjnYQeMVV/vDjnvzvVoz98d3LrK99Pzjl/xc/q3l95jxaPkF3zhQgc 1tm/qfmn2KuV5O6320Ze/HnRU+GxDyWOGup95eMZYxbmtBj1+cdzAxwdrcJywPCxMz7p3j2q7OcZ sxcc85u0+o306Gubp545fclfya/GXN/0n/Xbdu46XHJFFzDr7a8Gp9g7ZoXtysop9zZrh9dqNwqf /XJ+xqOP5B/b6vYIoe0HL1n6wQN3tnA02vrfL7667sSce5OsNuQvHNUjulqjmQe0utB2KKvRGGNy 9NM+PW1Mzrdzx5Wc+8Nq7QMB9w0aPOhmWcyhseyPaeG1WVOGR+UpvJCcxs5/dLMpU5tc+2zmw0vv TE1OefjdUL/TK+4dtb5EcXuLtOlLF4RKDv6334N5TVQd4/1TglhG0avF9BdV+r0vDHpU2zJsXO/7 pb3HJkWYbylLr/34VN7Ji4z89rjH/uvHnP/ovru/zJelxMjloeMnLnw0PP+L/zy9fEQ7pbE6Bt3+ Q0VZUqmfX5/7l8+PK9/67LhX7uzdrfvD74b4XvgkfeiafFnHpl5+jOFqoS66U+rkF5aE+mR/dN/w dUVeXVuNmPrenOiCtf95ctnwDsp/Vefmrq0cy35vVonakF81MHLWM4nMxetsdBPmwMqMSWuvSbq0 GTBjxYLmjo62a5+kGWRAU3Jie85674Mon6z3R476Ua3o2nbc1Leealb49ezH3hvWo09H42rGQm+t UKREyqSypIFvreoSYO+Yk/u0t1rZwBgYWXKSb1P8zjV8n/+aM33alGuHN7s9Qlinoe8vWzn+jhhH o3134PLrG049PzJxRLcI4QtdGc1yc/OntuPYjsaYkjP9i/PG5KyZM7ro9F6rtU9ETBw8ePCt1tyM Dmv6n+Ulr8ycMDA0W+ElsdkdNC5ssHzkNx1v0+x4csiBxP97Zlp/7veZGU9uD471axnZ6aFXl4UZ z3LSz/j59I6XRHsxbODo22bM9C1e/8Twl9gYv8Et2ItZmt26+Ojb0yfOGBVH0lO6ccEzr/eMv7Pd s/P9mYMv93vwYogqPkjSOaZPl+fmhhr2vTDoEe82/kO7PdCi78iAZqH/3MByf8zpP0V926AX3lkQ yB56ud8DF0JVCQFsxyastpwp804dOH9BiNUJDff7iwMflrbxGxTK/POTKu/Vxrhr28dyvMYPUrWV Kop7fjmgXxPy+Y11GePePNkizjci9I5Hl7wR7OhoOw9+aj4/4KSShEFzli8MZQ++1PehvDC/VjF9 Hpr/eghZbeAjks6DZ73BrzbherhffIi0S1Rq19kL/O0ec+fBT8//98pNWF/8tjUWa3+7POXhRy7u /97tEaKT7165/IMxKRGORtt65OriH84+MSR+cMdw4QtdGc1yc/OntuPYjsYYnyetf3r9dWNy1v4f Sc5vVmsfbzZhyOAhrPRmY2zac/Ms55WnJgxsguSIAtt0ZuvJoxQH5n+pfHp8UvHmyQMWn2Nuj/RO igvumP5tq7beR17uvyKzckgbaZhE4t3+3Q7DO6p3Tst44beW8T5pCdIAjSHruuFyma44ZMKTS6ZH anc9N+gxZfJdT86b5288bxh1xEuREi+Nb/Zg0rQpyvw100fN82qd+uziZRHKa/tefuCNHy+U+g9d sm1BW/42vUX3pxevau6X80n6iD9lipQ4aZzcdJRet8VOXx7md+q9EaPXX9ZbHL6sfWvVXS0lAeZb dnmv1rPm+ds+lmMk6Zo6pffUCT439h8xJHcMPbN2xqTTJZq2iXcOeN7x0bYd8tIHbwTdPMtJeWbJ 8mjfU++PvC/L16d31zGDn3zcp/Drx0a8Kmsz5P8+IN3i9+vXO14a7eP4mDtbjMmvjLvUGpE1e8nN +sO5+7+zvPCHI9cENhnSMczy06jkESuXLx/bM0JgNL4ulhvavdCV0czbWl1oO5TVaIwpOTO/vWZM zpcv3WsvOQ8NGTLkn9JIrNpz8/9NZzk5SI4oSCJ9xq29rblp+ezCB8Z/zET6tw6V3RElkQfcHTrl 6Vj972vmz/fxVsfF3RN7z2R/bt87Yx/+ocg7JTF16qwh3PEtheczy0tYdYsnut4/WHFkzrhHv2/W fvAc4+0vU7533uJPt3VIbJU0fFFMS99zS4dNW32xw209n1iyNFJx6ZtHM7YWh/R/aHFGf3KSfvMp YaMeXN67f2v1gbfe/WhLu4QWrXvcofltVanGS9lj2W19WxVtn/Peul9kkuAmbdI63Rl3atnr59SS TvGyMPPpkjy19TOvq27dmg9o5fXPlxSdYya/E+af+fX4sZ9IJ77/8WMtrn256LWlt8ekJhk3cXC0 7QbNXv5GyM0Bm9w3fU3P25te/nLq4m1XRj3yQffukVc+vWfiB6fbkdVWmFfj9+v4mNk7pn1gtTKF f3moI2v2XpoydWrugX9H4vC1d2xu03lPklv2Tv+ORLcRK1esGNszUng0sqHVUPyF7o1mPhh+HFeO jaggyfkmz5Sc/95XfMYmOU3/nZybD+r8c88af7bz8lMPDQq7gOSIg0QSNzcpvac3o973n34v/lbe PUbRuoVXWyXLcGxhRZeitIfu7NmuiYJhtNdLTm74bO7SDbn6xFjf6Gbtxk9/1jc8Jkhleuqx/kbJ 0bVvvLDs9wrvlDb9nzIm5+/PlpzsOnZE2xAZU3nuzLpXn132uyFY1TlckdZ3SpN+Ga3DvZjys+d+ +y2w//hb5weqga2DqsImJgwb3K6ZD6M+m/+/17d8edSnpW8LmV9uk8kJdw1KaqYkdVDn7Dq3beVX W8637urf0vJZy/LUxJmvqay/xyNn3nmZHfhpfBvv0wuHTf/mSkxMYFK/hY9Mvb1qxzNf7JPf/yLZ xMHRxvaZ8f78IPPh3RYrue2JDv27G4+i6uLlrQtmLvy5zN8vuUXfGUstVmvNV8TBMfccMvTZ11TW K0Mj8cWe3KlTpl769836lsPX3naQnKeGxN/175v1yG4jVqxcMS41qp5HM29re4nd0RhTcp76+oox OV+/nF58xvpdDY6FPzjkriG2j+LcXLj1+ctPTRgcloOnD4gFx50+dmPlWa2BYUIjVe1D5XfEyXxN d1UZtLrDpyv3X1LnluuryJel0mA/r+hQ72C5NCnOO4bVrNldeqpMX64zPb9ZIglUecc1kQeF93ns 7dcDjDepEy/7SG8UaYo1ZFtJeIhPq2BpSJg8JYQ5crT4x4tVN7QM4yVrHSG9nFNVwsjatVINaiNX FVdtP1V+PF9brOXIV9s29+3RVNa0iZe8WL0ts+KvfE2R8dWmbHCQvEWId0KgV4sor1DLv46qKt7c UpJn/U16PzQ00HA4/7NLhpBmqnYB0sTm0st/FW/J1Ukj7lr93ZtNBI5WpV5kHJA/PG9FgXrz3+WZ hbpK4xUiaRKsaBXsFdRE3itA/fY/q8nDTb895YUOjrmJ9pOt1itD47B6z8WpU6bY3qwLbGLvZn3l /anR9TNa1pXy03nlVhvyu2jZ1LdVM19HozGm5Dzx1SVjcta9klF81jo5HxzggkONjwiR5Nz6yC8y lhcW5Pw1Plklx1mOWHCaMs2+XAMpB8ewYdGKrgHmHwpSHcOFa5rzJZxaz5leBsP6qWStm3mFk3Mb zpB9WXO+2KA2PuGKx/qqZLfF3Zny9Kt+tx5QiVMwFVrG+BoXiSQs1Kt9E6mcZTTl2hOXddc0nPFy VqKQGjQ6MoikaxtFuJQrKdZmXtXduLkV2yxc3j5EIuO44mJd5jVdoZbjX98jV0hjw7xbqFip5aP0 Bv3RM5orZGTrb1PSKoS5UEiOlg2NVCQHsVUlmj8u68q9e4//YEFzgaPlzAOaDk9iuHpde+oGCa3p u2bZkFDvDmFSpdVqfEUcHbOv4cRZm5WhUVi9++LUyZMvH7R+vMR1EV1HrFi16v5e0R4+GmNKzuNr c03JeXVMydnfrdbW6Ax6A2cziDVyeyOXSVm83w24R56S8Pgrt5LjPyRJ6dE3qQ3raMHjfb7rwsOT J9XwZn35qg/H927u4aMxpuTMWHOBf13O2JKz1q/LAagnVWXzvy803XHkf1c7j3+5ScM6WvBsn+/K SUkbmBQf6fYIJ85e+m3ntvG9Yzx8NIZ/Xc6abFNyXhtXavNSUIB6YtD+mVl52XjHkay759+IN6yj BY+3fNsp5ysJenhgYoMYjSTn0dWml4Kuf308kgMAAHXH+IY3n591+O4DAAAAtejRL02vyxnZpQnt IwEAgEZuw6HrbK+UHrv27ivKv/niBE4qp3tMAADQaLD6Kn7ham72lOlPWScnMLQpvWMDAIBGxRwX +8nxD7Z+azYAAAD3lNy4+fYH9pPjFxhK79gAAKBRKSvK5xfsJ8fHP5jesQEAQKNSUXKDX7CfHKUq iN6xAQBAo1JZWsgv2E+O3DfAdptevXpZXbJ7927+QrJgXoFfrgm7O7JdwelOa+t4hI/T9tisrhYA AJGrKi/mF+wnx0tpM4EIw9xxxx3k46+//upoUKcruMjtHdXWAbjOao/k0/rcOwBAg6CtLOUX7CdH Kve13SYtLY183Llzp6MLrVbgP7XdxCm7O7Ic0HJY88qWXxU+HtsLzZvX8FDJp65cFXa/ajsIAEDj oK8q5xfsJ4f1Utpu07dvX/Jxx44dji60u2x3K2Hu7ch2Q9c3qa1DJZ+6clUIHKflIAAAjQOnreQX 7CeHkSlst+nXr5/lpz///LP5QoFlywtd5N6OrJbd2MSNQ7X6ToV3LXCh5eXVPQAAAE+nU/P/bz85 Bom37SYDBgwgH7dv3+7oQttlM6uthLmxI9tlNzaxu1/Xj5YsCOzazGpf/FZ2BwEAaBwkBg2/YD85 OkZmu82gQYPIxx9//NHRhY6Wq8vtHVltWN1N3Dtm81ZkwemuHW1ldxAAgMZBRqpiYj85GoPEdpsh Q4aQjz/88IOjCx0tV5fwjvgFV3bqyrHVyjHbbujKsAJHCwDQmHhLDPyC/eRU6Vnbbe666y7yccuW LY4utFqB/5RntZUwyw0tNzeP78pOrVZzdDwCQ1X3gC03rO6ua7J3AAAPJ5dy/IL95FRqOXrHBgAA jYrS6+ZpjP3klFfprTa4++67bUf5/vvva/3I6m1HNWf3UBlPPVoAAFp85VJ+wX5ySiu19I4NAAAa FZXSi1+wn5ySCg29YwMAgEbF3+fmC2/sJ6eoTE3v2AAAoFEJ9Lv59gL2k8NJ5fSODQAAGhVWX8Uv 2E/O2ZxL9I4NAAAalfiYSH7BfnICQ5vSOzbwIIWFhbQPAQAaPCdnOf7BYeRjcXExtQP0PAEBdqat M6u764rufvEzAAA15yQ5qqAm5GNJSQn/6bFjx2plr+3bt7e6pAGN7O/vL7Ba3V1XdPdrHh8AwG1O kuMXGEo+lpbenMeN3JzZ3qZXl91BGtDIKpWdmVLN6u66ortf8/gAAG5zkhzfgBDysaysjP+0AYWh 7kb28/MTWLPuriu6+zWPDwDgNifJUaqCyMeKigr+0wYUhrob2cfHR2DNuruu6O7XPD4AgNucJEfh F0g+VlbenDq0AYXBxZENeq2uophcDzIff4nUy5WRlUo7k3ObVfe62nZ2S/+4wRLWziQRdbpfYbb7 NY8PAOA2J8mR+xqfraRW33wPAorJyc3NZVk2MjKyFkcmvTn0brq+qkwiY+V+ge2mrHZUHctBFAo7 k3ObVfe6mrP92eaq2Cm3P1rP+xVmu1/z+AAAbnOSHG8f47OVqqpurkQrORcvXtTpdBzHeXl5RUdH 18rIpDcH3x7hExTgHxnHSmXl1y6qy4vbT1prtzqWg8jlQu/IIHBdlWiLTtw4+nfByezC84WlBVVq rUatiQyO1Gi0iaq2U+6YVkf7dYPtfs3jAwC4zUlyvJTGZytpNDff3LP+k0MyQ3qj1+slEuNdTyQ8 ZCE2Npac8dRkZNKbP98dpQwMDIhuSa4ERiJlpd7FeWcqim90nvSFbXUsB/H29hb47hxdVxfLc369 8nNx1Y0AeaCPt6+EZbUGrVanIx/V2qpDR/9MDrt9ct+Ha32/hUcf8ZL5sv/cccdpNSX+bd9gJRaj ketSomBZqcB+zeMDALjNSXKkcl/GdEPPf2r35ptUIS8vr1mzZi7uslrJuXz5Mn+XjlQqJTsyGAzk YJRKpd1zHRdHJr05/N4oZVBwQGSr0qvnywqvchJWGRihCk8suJRZdqMg9THrcx3LQWQymcB3Z/e6 KtYUbcxep2d1Yb5hZZoyCSvV6rWm5Gg1Bq1Grz108M9u4T1mDHlC4ODd2C9RsG94/OBfjYU2TrbH MSyrU+dfOzqXu9VsiRf5q8Kb9WsnD71DYL/m8QEA3OYkORJv47OVyEkG/6nd23RyFqLVauPi4lzc pRt3rJ0+fdrLy9gA8rc2iY2jB9JdGZn05uj79yiDQlRRrUrzzlWUFTS7azG5/PyGJ+Q+oX5N466f P1V0vWDIC99IZF52ByHxE/ju7F5Xuy/vPHT99/iQeK1eV6wuyczOPH3+tIac3ag1URGRpDwdQzo/ M2K28Hfkxn6Jgr2j4gdv1eQt02ukjMSfZVWKiL6kM+QvBXJlMJyBdIiV+J37eVxQt+UC+zWPDwDg NifJYb2MN+7k3IL/1PY2PTc3l/SGP//g/s3yEsut3EhOVlYWf/cOOeNp3bq1o9WcjmzszfJ7lQGh qsjE4qtnKooKgvvNbxEXL5FICvKv7V85WeETGBDR/NLpMzeuFI9b9L30VnUsB+Hv4nPE7nX1wZHF Ui/WT6kqV1f8efxw18jkialT+S/d/86YVk1b/V/Gy06/Izf2SxTsHBk3bKM693POwBmqbmjLr+pZ iZeiGcNpGYOG48i5i07Venb29ntCev0zh6ntfs3jAwC4zUlyGJnx2Uqc8S9iI6ubs0uXLpHTDvNN Ib+a5Ud+oaysrEOHDuat3EjOqVOnzMlp06aNo9Wcjpz51ZOMoVwVkVicd7aiKD9s0ILmMS3MDwvl X7/284IHFX5+wVFNL2Zmc9KwcfNW2Q5i92EkM7vX1TPbZpSUF5PTGkbL9k8cOK7Hg+b1P/xp5UN9 Jx7M+12vNxiM/xGGtFb9amW/jDE5d8UO3lB27htOU6Ytva5qfZ8ipI3p0Rv+LIcznuXIAk+v7xWa tsnulcbv1zw+AIDbnCTHYHqQ2XxjZ5ucqqoq/lEW/hK71al5cjIzM/nnTVVWVrZt29bRak5HLrlw 6PSW/8qDooqv5bV74ENVQJDVqUNZSdFHjw4nZ0HXcgpGz1nUotPttoMI3/java52ndtJcsJHhSRl QLtBe/N39mrS17zVxlPrt2duLSsvq6qs8jJ4fTblq1rZL1GwfVhC+m5yQsMHhiOnK5pLuqKfOX0x pyP/lXD6MkXUC+c2TgodtNnulcbvVzh4AACucJIcPWu8Z8l8u2x7m37x4kVyokNuj3Q6HX9PmtU9 bIzpNqtjx47mTdxIzt9//61QKMg4JDm33Xabo9VcGbko51DOH18eq2w75eFppJevvfYa+e5Yk9mz Z3t5eS1fttRw/Nc+Dz5q7o3VIMJ3MQlcV2bf5359oSR7Rttn+U+/Pv7F7+d/a9+qHSuVXLl2peRS +ev3Lait/RZsGRY/5idDxTFjY/SlnK7IoC0ky4yu6H+nC3/N1hdXVmp16i6yG2Mf2ibw/QrfrQcA 4AonydExxmcrmR+4tnszev78ea1WK/CovhU3kvPXX3/xL0isqKhISkqq+ciffvrpxIkTyY3p/Pnz 4+LiyDeYnZ399NNPk+S88sor5EthYWGOBhF+IF34uiJ+uLQhp+ycTqs7e/VslVqjUWsjgiJiw2Nl 3jLjU9eO/tmn+YD7bs+orf0WbBgeN/4HfemvxnMa45lNkWmhcFtm4XG1qkubrlHBLXee/O73E7s7 hw+dMmiWo/0KP3kBAMAVTpKj5Yw3NOan5zp6knRubq7AKzStuJGckydPkp6RHZHktGvXruYjr1q1 aurUqWTAN998Mz4+nk/O448/TpIzZ84c8qXw8HBHgwg/XVj4utp2adOZ4syEkJbkdlxr0BmfKm16 tnSJukQqkZ3LPi8rkj855OnwwPDa2m/+l0MTJm/RFm40xabo5v1p+uLHNxbdPWQoI5UMbzPjrR1T pYzk200/bnzpsKP9Cj9FGwDAFU6SU6U33oNvfhEirXcfOHHiBH8KVV5eLrCa05GvVl6+VJq769wv WZlZQ7uMGNph+KJFi1q1aiWRSMi52vTp03+8/P32Uz+qdP7tmnSK8I3qEZ9iO4jwiyKFr6ttFzaf LDgaHxqvNxg0BmNvyJlNRWX59cLrly5dbsI0HddrfLsY+8/uc2+/BV+lNx/zgbbgAGOo4Dg1Y1Az nJrTV41du/HRMdMH3zaJX23T8aWvLZ+79dWTjvYr/EJUAABXOEmO2vSHtfmtVmgl5/jx4/z7GVs9 E6G6I7/6x/Oc3qDy9SsqLyo/q3v1nnkffvhhYmIiOcs5e/bsmDFjVmW9F+TvX1xZdO5izqmjZ7c+ 97PtIMJv/eL0ulr315qT+cc0Gu2ZnDMataZKrfWV+rQIie/SoltaUl/z+U1t7bfi2Ne6/ExN7iGD 9l9vBT31wtVhwwboGMN/+n88f/sEhVTu6CyH36/w2+0AALjCSXIqtcbH/81vKEkrOeSrdp+JUN2R F+2bn33lvLdOceV8XpA+JNY7TqVSSUxYlj19+nRlk7Iin4LggNCzl85G+EUte2S57SDCb3DpynW1 ct/Svy/9veieJQLj1MV+LX3687t7LnyZ0j61ZdNOp/MO/3ZsT3LESLuP5fD7FX5TUQAAVzhJToXG +Gwl8/MCaCXHo0YWfht/V64rA2f49uDX93bLqOf9Wvlo+6LN+7+srCpXyn2HJmdMHDBTYL8uPjcE AECAk+SUme5Z8/X15T9tQGGou5HLy8sF1qy764rufs3jAwC4zUlySiu1jMUUyA0oDHU3svCUzHV3 XdHdr/A02AAArnCSnJIK47OVVCoV/2kDCkPdjVxaWiqwZt1dV3T3ax4fAMBtTpJTXG78sr+/P/8p uSWqlb3aDUNDGbmkpERgtbq7ruju1zw+AIDbnCSnqMz4bKWAgABqB+h5iouLBb5ad9cV3f3iZwAA as5Jcm6UVDjeFkQkKCiI9iEAQIPnJDmcFC8ABACA2uEkOWdzLtE7NvAgrs/6CgDgiJPkLPx4I71j g8bsmcn3vrlqHe2jAID689qsqea4IDlQT0hsgoKCCgsLkRwA8SC9IR9dSg6/KkDNvbBwBf/jZE5O nf50mXcHALSQX0MGyQEqSGn4J79ZJocs19HuyC7qdHwAcMryj0skB+qV3bMcJAegEXMnOTm7x0pY BctKbg3C6XVlUT2WsRKLmbtYhpUqWRYzFoNDjpLTv39/25V/+umnGu4OyfFA5N/a6l/W9hJoTNxJ zpkfesUP/pVlWcY0bQ3Dsjp1/rWjczmW5deUevuzrNynSbIqws5tBwDP6VlO7d76IDkeiP/zwvJf Gclp3NxJztktfeIG/aDJW6bXSBkJqYtKEdGXkXgxxpnTDAxnIB1iJX45Ox+I6buW0vcFDUB1k2P3 L2LGdINlPjGyWt/yQiTHA/H/ppb/slbL/ILVVy1DZTdaVluB53ArORvSWgz9Xp37OWfgDFU3tOVX 9azES9GM4bSMQcNxOobRqVrPzvnp3vhhv1L6vqABqK3kMDY3SYzNLRdZRnI8kEByHF3I2IuN8Fbg Ody6Y219SuzgDWXnvuE0ZdrS66rW9ylC2hgfvWH4sxzOeJYjCzyzoXfCyN2Uvi9oANy4Y832BsVR lpCcBsH238tuJ5wWBclpKNxKzlepCem7yQkNHxiOMRg0l3RFP3P6Yk5H/ivh9GWKqBfOb5qckLGH 0vcFDUBdJ8dyQyTHMwn/g1r+I7qeHMvxkRxP41ZyVqfGj/nJUHHM2Bh9KacrMmgLyTKjKzJdQpJT rox98/yG6QnjkRxwyL2nD1jdMLlylsNDcjyQQHKqdRIjfJIEnsOt5HzUK278D/rSX43nNMYzmyLT QqHp/Ib/r9wnYVX2V08kTEZywKHaSg7j7LEcHpLjgWz/YmAET2iQnIbOreR8kBo/abO2cKMpNkU3 708zfizle8MZ1L6Jq7O/eCrhESQHHHL7SdJ2/zTmP7X7zCUGd6x5Kqf3nVp+Sfi5bQJ3x4HncCc5 51YMis5YpsnfzxgqOE7NGNQMp+b0VQyn4bgq42M8nF4eOebiujkJj/5C59uChsDtdx9w7yFiJAeA OneSU3jgc3XeifLzvxu0DuYJ5RhW5hXQdmjYgOfr4XuABsq95Dh95rQjSA4AdXiPNaDGNjl1PXEO JuYB8ARIDlBQz5MXAIAnMP/iu5+cbUcuD+wYUV8HDI2Eo+QcOnQoKSlJKpWyt961z0yn0+3fvz86 Orp58+YSicR2TADwcOZZS5AcqFeOkkOi0rlz56qqKnNySGkMBoNGowkJCbl+/fqZM2eioqJQHYCG CGc5QIfd5HAcd+DAgS5dumi1WlIUUhrGlBy9Xk+SExwcTD6SC48ePRoREREbG0v3WwCA6qrX5GCu HTATTg5pzL59+zQm2lvS09PNmx86dKhbt262d7451bVrV8tPDx48KPAl4Usst3W0C9t1BL5q/pIb R8VvYl6wu1PLNQGoqNfk1GSuHfyqNDLCySELfE7Igt6EnOuQ6pBTHLIQFhZWk+RY3aA7urF2+iMn cPsusKHlV50uu3hUwslx/UKAulavycFcO2AmnBzyKVkgjSGBISc6/H1rBElOWlpaQEBAbSXHfAnd 5NTwqITH4RcsV7A9nbJ7ggVQ6+o3OTWYa8fql8p8RwFjcaeB5cr8gqM7KIR/0/DrVw+cJscSf65D ekM+kmUfH59aT47wl1wcqrpbubJrV47K9bMcu2vijAfqTf3esVaDuXYsf1UYe7ER/l1y70KoO06T c+zYMZ2J/hbyVVKd1NRUb2/vukgO4/jPl2rdMeXGYzk1PCokBxqK2kmOwA4sa1STuXac/qq4focD kuMJqnWWw5hOdPgnsJEFmUxWR8lx8RL3zn4EvlrDo6phchjHZQWoXfV7llODuXaqlRzbPyQd/dZZ 7kLgj0qodU6Tk5WVxT9rwGBClsmFZKFz5850k+P2YzwCX6WeHBe/NYAaqt/k1GCuHdeTU1snNPj1 q1MunuUYT4ZvfTSTSCS1/ow1gXUYl39mBMZ0+lXXT9kFjgrJAQ9Xv8mpwVw7tZUcuw//2IVfvzrl NDk5OTkGC+bqJCYmktLU+uty7J4ZC6/GOHgwxu2TpK6On0jm9KhceUTT0bLtfgHqSL0mpyZz7bh9 xxpj81wDp3fBWX4KdaS6j+VYIclJTk6u86MEgFpVr8nxkLl2cPriCRy9xxr5p2nfvr1UKvT2E3q9 /vjx466UCQA8iljeY83u3RFAESYvABAhsSQHPA2SAyBCSA7QgflyAEQIyQE6MF8OgAghOUAH5ssB ECHMlwN0YL4c26/afYK+i0flUW/XZPcFCQBMA5ovxynhV9i5+HOP35B6g/lyXFl28ag8Kjl4XwMQ IIr5cpAcD4T5chgX0lK7yRF4dwNH51WWw1q9cwcjeA5nu6HT/YIYNLD5cgR+6O2+p4CjXxi7qzFI Tj3CfDku7tqVo3IlOS6+DY/AO+K4+JZRrg8LItSQ5sthXJsmx+6vlsD6wttCHcF8OYzg3zrVOqp6 SI7TOwPdGBZEqOHNl+No2cW/CpEcD4H5cmrxqKp1x5rtnQG8ekuO7ZGAeNRCclxXK/PlOFp2IzmW 6yA59Qzz5dTiUVXrbybhlesnOQKbQ+NWv8mpjflyHC3X5CzH7ppQpzBfjsDlbh9VLSbH7t3R1T1O /LqBlfpNTm3Ml+NoGclpWDBfjsCxuXFUTpNjO7jw93jQwct93D4Nsr2DAb9rIlSvyamV+XIcLVtd yC84/X0wj4871uoZ5supU3Zb4sYg+HWA2lWvyfGQ+XLAE2C+HM9UK60CcKRekwNghskLAEQIyQE6 kBwAEUJygA7MlwMgQkgO0IH5cgBECMkBOjBfDoAIITlAh9P5cvjV+FfkkOqQ856goCDz5nX67gOu f9WNrVwfEM9RhsYHyQE6PGS+nFpfvxYHRHKg8UFygA7XXwpqro55ypy6mC/HvNDVwZs0C68pvBW/ ILAX29XsHipAQ4fkAB2eOV8O49qkGI5i4+LbLwmsL7wtQEOH5AAd1X3DG/5BHf4xnjqaL0f4hMbR m4HW+jv+ITnQiCE5QIfT5KjV6r179544cSIoKKigoGDkyJGBgYGffvop+ZRsQj5mZGQolcrq7teN 5PCX1HVyLNdBcqCxQnKADqdPkl6zZk1ZWVl6enp5eXlubu6RI0cUCkVaWppUKr1y5Qo5y1GpVBMm TKjuft07y3H01Wpt5cr6wocK0NAhOUCHcHJ27dq1Y8eO0RkZ2zZv/u2335o2bdquXTtSmvz8/Ly8 vJSUlF69em3dunXu3LnV3a/byXF6od0VkBwAS0gO0CGcnCVLllRWVg4aNiwxLm706NGzZs0KCgoi Jz3Xr19fuXLlt99+e/jwYZKl5557rrr7tb0Lq1oPqNg+tIOpNABch+QAHcLJWbdu3R9//PHApEmb 1q/fs2cPy7K+vr5knfLycrJOz549+/XrR8KzaNEiyt8GAFQHkgN0CM+Xk5OTQ3KSlJQUFRVlMBiu Xr2alZUll8tjYmLCw8NJgS5cuJCZmbl06VLK3wYAVAeSA3Rg8gIAEUJygA4kB0CEkBygA/PlAIgQ kgN0YL4cABFCcoAOzJcDIEJIDtDhdL6cffv2aUy0t6Snp5s3r8l7rFl+ipfFANQnJAfooDJfjqOK 4MX/APUDyQE6nL6tJ1kgjSGBISc6/H1r/PwFaWlpbs+XU620IDkAtQ7JATo8cL4cp2sCQA0hOUCH 0+QcO3ZMZ2KeD5R8lVQnNTW1JvPlMIIzeFqthuQA1C4kB+io7hRtfG/4BZlMVpPk8JzOhIbkANQ6 JAfocJqcrKws/lkDBhN+PlCy0LlzZyQHoIFCcoAOF89yyCXmj2YSiaQWk8PgGWsA9QXJATqcJicn J8dgwVydxMREUhq3n7FmXrZ9EoHVl5AcgFqH5AAd1X0sxwpJTnJycp0fJQDUKiQH6BCeL0cqlQps q9frjx8/7kqZAMCjIDlAByYvABAhJAfoQHIARAjJATowXw6ACCE5QAfmywEQISQH6MB8OQAihOQA HRTny3H0apvaekGowKt/AEQOyQE6qMyXI6wuXvuJ15MCWEJygA4q8+UwNu9zwy9Yvt2AwPtM2z19 sRpEYHcAgOQAHdTny7E7cQ5j8243dtcXvtDu7gCAQXKAFlrz5QgnRyAqbiQHvQGwguQAHbTmy6m3 5KA3ALaQHKCD1nw59ZMc9AbALiQH6KA1X07Nk2P3IR/hkQGAh+QAHVTmy2FceMaa1Wq26/PPahN4 xprlE9sYvDQHwAKSA3Q06PlycB4D4B4kB+hocPPl4D0FAGoOyQE6MHkBgAghOUAHkgMgQkgO0IHk AIgQkgN0IDkAIoTkAB2OkpOze6yEVbCsefo1Tq8ri+qxjJV4/7Mxy7BSJcsKPcUAADwQkgN0OErO mR96xQ/+1fiCG9NrQBmW1anzrx2dy916CY7U259l5T5NklUR/d3YL57fDEARkgN0OErO2S194gb9 oMlbptdIGQmpi0oR0ZeReDHGl4IaGM5AOsRK/HJ2PhDTdy3l7wEAqgnJATocJmdDWouh36tzP+cM nKHqhrb8qp6VeCmaMZyWMWg4TscwOlXr2Tk/3Rs/7Fc39mv1tgJW717D/Ps1N3bnwnF91hzhqXQA RAjJAToc3rG2PiV28Iayc99wmjJt6XVV6/sUIW2Mj94w/FkOZzzLkQWe2dA7YeRuN/br6K3SGMcz 5dT8QgDgITlAh8PkfJWakL6bnNDwgeEYg0FzSVf0M6cv5nTkvxJOX6aIeuH8pskJGXvc2K97bwKN 5ADUCiQH6HCYnNWp8WN+MlQcMzZGX8rpigzaQrLM6IpMl5DklCtj3zy/YXrC+DpPju19aI7qYrkL 27cBdeM4ARolJAfocJicj3rFjf9BX/qr8ZzGeGZTZFooNJ3f8P+V+ySsyv7qiYTJdZuc2jqhwekO gBmSA3Q4TM4HqfGTNmsLN5piU3Tz/jTjx1K+N5xB7Zu4OvuLpxIeoZkcR7PmCOwRAJAcoMNRcs6t GBSdsUyTv58xVHCcmjGoGU7N6asYTsNxVcbHeDi9PHLMxXVzEh79xY39un3HGmPzXAOnd8FZfgoA DJIDtDhKTuGBz9V5J8rP/27QVtjfkmNYmVdA26FhA56vx+O1A6cvANWF5AAdDfQ91jBrDkBNIDlA RwNNDgDUBJIDdCA5ACKE5AAdSA6ACCE5QAeSAyBCSA7QgflyAEQIyQE6aM2X45TAU59df1Y0nj8N YBeSA3Q0xPlykByAGkJygA668+UITJNj9z0FHE2xY3c1BskBcADJAToozpfDuDZNjm023JtWBwDM kBygg/p8OY6WhZODyXIAagLJATqoz5fjaNmN5Fiug+QACEBygA7q8+U4Wq7JWY7dNQHADMkBOqjP l+NoGckBqDtIDtBBfb4cR8tOn7Fmd1vz+LhjDUAAkgN0NIL5cgCgupAcoAPvsQYgQkgO0IHkAIgQ kgN0IDkAIoTkAB2OknPo0KGkpCSpVMreeh9PM51Ot3///ujo6ObNm0skEtsxAcDDITlAh6PkkKh0 7ty5qqrKnBxSGoPBoNFoQkJCrl+/fubMmaioKFQHoCFCcoAOu8nhOO7AgQNdunTRarWkKKQ0jCk5 er2eJCc4OJh8JBcePXo0IiIiNjaW7rcAANWF5AAdwskhjdm3b5/GRHtLenq6efNDhw5169bN9s63 mqvd+XJsX7IDIGZIDtAhnByywOeELOhNyLkOqQ45xSELYWFhdZccATWcLwevDwVAcoAO4eSQT8kC aQwJDDnR4e9bI0hy0tLSAgIC3E4OxflykBwAJAfocJocS/y5DukN+UiWfXx8apIchtJ8OUgOAJID dDhNzrFjx3Qm+lvIV0l1UlNTvb29a3iWI7BcR/PloDcADJIDtFTrLIcxnejwT2AjCzKZzKOSY7mO 3W3RGwAekgN0OE1OVlYW/6wBgwlZJheShc6dO3tacoTvQ0NvAMyQHKDDxbMc41TUtz6aSSSShpIc 9AbAEpIDdDhNTk5OjsGCuTqJiYmkNPWQHKY25suxe7cbgGghOUBHdR/LsUKSk5ycXOdHCQC1CskB Ohy9xxo5D2jfvr1UKhXYVq/XHz9+3JUyAYBHQXKADkxeACBCSA7QgeQAiBCSA3RgvhwAEUJygA7M lwMgQkgO0IH5cgBECMkBOpzOl8Ovxr8ih1SHnPcEBQWZN6cyeQEA1BCSA3TQmi/H6dsB4P0CAOoO kgN0uP5SUHN1zFPmuD1fjt2JbSwvcboCANQEkgN0UJwvp1pveIN35wSoRUgO0FHdN7zhH9ThH+Op n/lyBJYBwD1IDtDhNDlqtXrv3r0nTpwICgoqKCgYOXJkYGDgp59+Sj4lm5CPGRkZSqWyuvtFcgAo QnKADqdPkl6zZk1ZWVl6enp5eXlubu6RI0cUCkVaWppUKr1y5Qo5y1GpVBMmTKjufpEcAIqQHKBD ODm7du3asWPH6IyMbZs3//bbb02bNm3Xrh0pTX5+fl5eXkpKSq9evbZu3Tp37tzq7hfJAaAIyQE6 hJOzZMmSysrKQcOGJcbFjR49etasWUFBQeSk5/r16ytXrvz2228PHz5MsvTcc8+5sWuBGXFcXAEA 3IPkAB3CyVm3bt0ff/zxwKRJm9av37NnD8uyvr6+ZJ3y8nKyTs+ePfv160fCs2jRIsrfBgBUB5ID dAjPl5OTk0NykpSUFBUVZTAYrl69mpWVJZfLY2JiwsPDSYEuXLiQmZm5dOlSyt8GAFQHkgN0YPIC ABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQI yQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfo QHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kB ECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQ HKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAO JAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwA EUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJ ATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hA cgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQ ISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAc oAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4k B0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAAR QnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkB OpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EBy AEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAh JAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkByg A8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQH QISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEqpecZybfy986ANScVXLw0wUgBq4mh9wi BAUFUTtMaKT45OAUB0BUnCcHNwpQF5AcABFykpzF7y+nd2wAANCoPDH9YX7BfnI4qZzesQEAgEcw PbxSZlr0M1+o06llsorKSoVaXeXiOKz+5ppIDgAA2BEU5EVKo9aVK2QkGMHmy4vKrvlLdQavMJlM Vl5RqHGhO0gOAADYx3GVcoXym282DR82NCgo+NjhA+07ddPpdORLJDM5F48VFVV2aNe9ouLcn/t+ Se07sbCwUHhAJAfAo+3Zs2fYsGFOf5MBat2KFSumTBkfHBxBGkMCQy4hjYmJbm/+lGEuk5Oegqts adWO2IghjIy5fnm7TNlNYEwkB8Cj8S9RQHKgnpEfPEMls/DdN2bPnl1ZWfHZZ5/17ds3IaFFUdkN Pz//t95YnDF2sCrAW+nVXOpV5C1TkPYc2Pe1WnuiV+9XBH5ckRwAj4azHKDip60LRt03j2F0337z TVr/lLCQCP7y7t1Tfvzxx+7du0dERm1Y/+3GTZvvTOsYFpqQdeZ4TCzrL0uWKHWGSlmx2v5PLJID 4NGQHKh/KlXQV598PWpkwMpPlj3+xHdffPL1pp++OXbqzxaxsbmZf2xY/6KPotXAIQ8Eh6b8fTrz /Pnsn3ZuCgtR9OjRh9HJDMz2rCNbi7Tpia0TbUdGcgA8GpID9UylUsoYhU7G6HTln374fsbYDgGq vjGxLZuEyndvW5x/+X2yjlLhq/TxqeLCu3R/u3vqsEFDej304LTCvCuB4bpNG/YNHz62Ulth95nT SA6AR0NyoJ79tHVB/tX/hYSNSB/3nI5Rv7d4yZtvz0/t3nfNF5PVF79VV+kqDAYfBSuXs4ymskIX 3an/qm/Wbpk25clP1i7u0K47P4iOYUrt/dAiOQAeDcmBeqZQGG/213+xrGm0/tCfWVMmvNRzUFoz X82m1YPVHDl54ULCB2aMefSN1x9sGVmirQguNUj46vS4vQfZ8NSpA9HRIUolW1QUaDs4kgPg0ZAc qGcqlUomk1VWViiVPuR0ZdTQ8Zm5B04cXEpOcSp0JX2Hba40NNVVSDWy6xf+eo4rzlarb6QOO3c+ 9+Rnn3xZqb40fPgUpTdrHEhm55mWSA6AR0NyoJ59svp5X6+AP/bv7nBbk+atkr5cncUaVB8uaKnm cuXsjU4DD5QUa4b0H7Jv//4/983y1vykY0LadNs4782Z6RkTTQPIzEMhOQANDJID9SwoKKiygvPy YUk6ym/oU3v3DItULX4tKazpFUMl2+3O75RNIi9nXw0La/rHr1P8mVMMo+zS/6fCMk3GfYPeWLAE yQFowJAcqGckOSf/zPr4k5kB/pLiEkP2Ze702atM5al9O8dXFcoU4WVXriaf+LuoY8fL0YGMQWO4 Vpbdrf++2dMXTnkqXSGTIzkADRiSA/Vs7SeD/jxQKfNPnjdvQZAqmBSkV1oyuXzX/z6qOvepXnKp igtWKA2coUomCeEquDa93wtr1lOp0m/9YYtS6VNUdo2sHOgXXFhYajs4kgPg0ZAcqGdBQRzHFevZ EBmje/XFhwxekV9t+Oly9tU+qUO/3fT6pb/f8VGU+ipDyZoV+qJ70n+8URxx5fqVvKunGEah0+l+ 2Lwt0D+wXac2pC+2gyM5AB4NyYF6pgpSMYxs6VsjruQeTxvweu+B9/Xv2/30X1fVVTfu7NX74PHf d+1/tUWTwX8d1k6cdn/e1etNQuVPPfLKHX3ujIg5V1nczddfahxFdrmwUGk7OJID4NGQHKh//9vy 7Oj7V+pMD8s88/jQBx5e2P62NmmpA8/lZhUX5SckRCpV/pWlJSUlerLyfaMnDBys7tntFbJ8Mf9Y THSoaU4dhd0fWiQHwKMhOVD/FPJApQ/L6Jinn+yRMW5mUod7N26Yn9an78ef7Vzz5TqFNFCjLgsM DFi/ae3IUaN/2PHNx2/PHpMeFhz1OsOUbd+2t/+AyKKiSLsjIzkAHg3JASoCFNxrrz308PQXw5ol b/5mWd71Q5Onrfrqi3np457b+O38ASNnf/j2lOlPr9q+9av2id6qpneuW7e6V0pIfMux/OaOfmKR HACPhvlygBb+Z49hdKtX3HP/xO8M2opdO1+9c8i8zINPte769ldfrkjPGKpjIrQF27xCBspM5zcd Es55B2cIjInkAACAfaQ6e3Z81KnTg/Jg6Z5dGy6f/mXUg6/nZz0f1fatY4cPq8t3tE+ZffbI6biY QjYoWSFhMRE1AAC478jvM9MGf0wW9u+Zn5w6lWF8cv+aTZJTWam5/vfiiM7PkS9JtSs43VSJ0vnp OJIDAABC+HvYrmYt8I+apfSpupr1bkjcTJmMqSz4xiskQ8YwWSfym0RKXRnKTnJ+3rGjoqyEvxTJ AQAAM5KfiqsfeIdMlslkbjzEaJ0cjuMG9L1j85at5uoAAADUooKrl6Y9PnP7jl9vJue77zZqqipp HxUAADQ22ip1SVHBP8khFw0d2HfZ++/KvLyVvirahwcAAI0EOb8hH5+Y+ezmbTvIws3kEORch3yc //ILJDxyuYLiIQIAQOMw4+nZ5CM5v+E//Sc5vN49b6dwUAAA0Bjt2rvP8tP/B5z/uaUKZW5kc3Ry ZWFtCmVuZG9iagozNCAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9JbWFnZU1hc2sgdHJ1ZQovV2lk dGggNTUwCi9IZWlnaHQgNDAwCi9CaXRzUGVyQ29tcG9uZW50IDEKL0ZpbHRlci9DQ0lUVEZheERl Y29kZQovRGVjb2RlUGFybXM8PC9LIC0xCi9Db2x1bW5zIDU1MD4+L0xlbmd0aCAxMTQ+PnN0cmVh bQo4BsDMhB06fp////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////+17VqGFAB ABAKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago8PC9SMTEKMTEgMCBSL1I4CjggMCBSPj4KZW5k b2JqCjQ3IDAgb2JqCjw8L1I0Ngo0NiAwIFIvUjQ1CjQ1IDAgUi9SNDQKNDQgMCBSL1I0Mwo0MyAw IFIvUjQyCjQyIDAgUj4+CmVuZG9iago0NiAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggMzg1Ci9IZWlnaHQgMTk3Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMg Mzg1Ci9Db2xvcnMgMz4+L0xlbmd0aCA3MzY1Pj5zdHJlYW0KeJzt3QlYVFXDB/A7+8DMAMOOQCgg oiIqIhImqYQCGpqmZmquIC64o36pqZm7maXmWr22afq+ZlbaZpZlmpqaqaG44Ia4IIuyMzPfHQbG y+wDA2cY/r+eh+49c+5Z7sz8OXe4AkuhUFAMoxPCKACAevPRgdPMXZY6g1Jf6vykVLZs1hiRnYDF 4ZEYGwDYMoWsvLC49PU1H4oFnPVfnlQVVmUQvfxZmDrMSWIvLymQFefLS/KJDhUAbBCLK2BxhRw7 x7y7V5fsPKVaECkziA6gt+eOlZXky4vz6AAiPU4AsFJbvz1XxxaS+4TSX7kSj6xb19/df4GOIWUG DXmhw8b5Y8ofZSKAAECfbQfP90oc1LFNQK1bOHPx6g/79yTFh9DbxWUV8z/7+4ufzrJ6dA7etTxZ VpxXlpNpscECgM3Z/t3F2bPTijOP1boFu+bPrlq1elxcG6oyg+RyavIHp5UZtHPp2JLsf+XlJZYb LTQpXG7AGI/I5/kCevvfe7sPOg6eIaQ3Pn2rqIz00Oobv5PX8KYy2Q9+SJ81c0bh1d9r3YIo4Lk1 b68d2ytYtVtUWpH60TlWWBv/b9YmF948rVF7/S/5bIGd0UYlspxhUZ4cNqvWw7IK/HDvkWnq2SrK HpXnpBdmHMzLuCyTVxWyROHO0a85+niwlTVKZI+OZH/9QXG5vnIe17OrQ3A3sXcrvj2PouTygozC jK8e/X26XKYw3Hu1i3d3LC4s01tHUXKnOGPvw1NHyyqqGmRJOkk7D3B4JpBLd1j+sOTmz7kn9xc+ Lq/V+NU9Vg6DYmxrv9O4we5DFzsIb+0b02/9+WKFuM8XP69xo04s6Dmp/dDBfZL0H2jyM6JzvgTw tc5DVUnlZAf6d+ATG1oD+PDHyzOmT3t8+Rdm4fnMnH8yc+iNod2D1IU7f7lMf23X3CWkuQuzsiSo +9p31o2JrapJZ9DoTWeVGbR/9bgnN05p9DftsPRukfEzKs09sW6wj5DPqc2crAc/wnfsHHv6lRQz 8o9SicszHaJfmTE+MZi6/vGVQ/vZ5QqK7e7Ub6OHZ965FcMWfvNQENQjcWhY+qb1XXqGhr+sq7xX fLf+vYrOHjz849Gfzt67KwyOmbR2ZoJ30clF50/848jW03vPkUefMB8QpQzza8/XrsPmOwfHTHs/ Lc6j6M/5Z07+68qhWA6x3oNTRNTfR1fN3/RTtiJkRNrqKR0UJ05/ulpUITd7/N09A0XqHie2Gzyo b0r1dr/qIekY/+i7rhI/IcWSy89ffnyf4rbrkLh461InfQea8ozomS8ZfMY5UU+nOGfxrnvZ9GSD nPt3cW3GJTS2+vfRoYzpU6fkpx9iFn5x5OqCT07QG0tGRAyJDtBZouYYHPPOu++Njmmp2qUzaNy2 88oM2rdy9JPMkxr9HRW+2LtXLxZbiaX8X/Vmzf8vn5sysEVu48+gLn7Jr1e+tsYWeIncWIrSCoHD oJ1pA70ffpV8/Oq9AHEn33FviNmXNvQfdIItDLRnlZeV334kd28TN3fdCql2eQtp3yDOVz8/kkm4 Ej6bx6Lk4t6vbVrcouyXBSPeiImSenD09N5M5FYjofhRYVIvro46CsfEketff6b00Lzhi194zjew 73bfAH7GWzETvn3U0kfYzI4j6LxhZmqn0sNTPvwtM8Yz3Ozxd4rtlFLdY+CLi7Yuk1b1Lu0XXjmk GoNXO3Ns84H2KfPsqdP/nb6r8zur/BgPndu0iCdjc58Z4tk1QeziwKLKyu8ezf1rV25mtpyqyfB8 Y+K6KMd2Pedklrh9VwHv/O1t8x5XuIg7p7iHdhYIWFTp7SfnPso+dapcpm7q2sM/MuxDe9qLeVRJ ZsHprdlnLlQtSdlSUViSe/tIoR2HKr35+OwH2X+dpXO7+sDqXjQDtHI6HFWd0/9NmZhexI8K9w+M 0NUUZdqsrdt/fr46NXVS7oUfmIV7jmYu2nlGtb1oaEflV8buoK7NmZWlbXu9u37jqJ5VwURnUPKH 6coM2rv8tcfXT2j096d4gCkZtGx2cn+/h40+gwSRLVIWiKpe8U59O0qk5eX3qAERcye45e6ZOfbd hB5RYeNWSelrg/I7GX8dL3qUzr32x4WMxyX80Ng3N3hpl1MsXx/BvVvFD4oVEmeBn1TgEpTWekAP 3oPPJr68QhTqOTSQz9fT+4thDp7ap1OzjsRd3MsveZpj6aHZcdOosNg5S9e6CNPf6/fyr5R9Byk/ 2F/k65wQMHmqW/7eGcNWRvWMjpmw2rzxB70QMam6x8C+i7Yul+obIbsDP3VpkHodJ47f9fNad+Vu Sps+8Z1mMh6i7JKGvRA3fpVUmPPnkuFLf8qXhvQaNLx96cFN/s48Hsvk+XYesGDVYglFPfh67t7v Dx85U3C3wmn2u3viIn2e/JQ6Z9U58dhPVw7xvf9N8pWMOw52qqaowqOr9u379ugVz9aztqd2Fd3e Ozbr5n17Fl/YZV1gpF/pn/MXLDpcMvCD98YF3/1q3I3rd8XCqgOf9iKIWfvzhg7M6Yx4KTFVNc6U Ngl+nZ/T0xS/rfcYE2Zt3T7+5XrqxJSH5w5qlO89fmvJnvMahQsGhQyI9NUodA2NX//+5te6t1Dt FpXKJuzIUGbQ/94aVnDtT43aJx0Hx8XHVUWNOnmYgVS5sTQtKdEnW8hr7Bn0rP/kReKqV7xjn1CR 8j0mjPabNM9RfmxeXAqrjccrzw6jur0a0kx9B/nj+99Nz76QxfMZItNRfovROovtHOMzJM3JPu/I vP5LDud2DHToFWLvztHoXcO5zA1pBaU6R+j0YmRoq5jFvq1dC3+YMHzh7y3aJ8x/f6Uz+9SiF0Zm u0k6BDhESVmUsFuLSfMlsqPz4iaWt3QfFj2cE23O+Jk9BvZduHW5s8b5UeNFuE9Z4qles4ijR2ym lz+qAxPmbF3ZjLnEEz6bvPEdd865bZNmn87J9eRTpSXld/MVoRGu3aVsDsvE+fZdsJnORGXmHiwS RnlzOdx2cWu3hTlc3vjSgO9KhOFthiW/Pd0rd/ecyRtejOzZIZVu6vqHg/vtesiN8hMIXEeMWT3R 4+Fnc2du6R8W1jJpnYt95oeDE/fk8cKD+idvWOCbs3PutE2JET1DlQcyehFGD1NPTTUd+x4TN1ef meZRs9Zv8RXpaqpz17YTljsanbV1++TXG5MmJN0/8432Q/tOZi378pJ69/WXWvXv3Ey7mnvHvhs3 bRvxfNXimM6gSZ9dV2bQ5wsG5mUc1ah9vtmY+Pj46vCpSiFW5X/MkjdnjO7tminksbW6a1QE3VrP XuFQ9doSxway3TgUy2VEu4kpdrl7Uvu/yfETJ/izbl4q+60iwPfZIWNSB/jT79nH+1fNWta1Gfvf dF3lPhzl9QpLIg6fHRjXU0DlX3h72Kzd15y8xG2cuZF+LAe2du8anwfxRsRJ2vCYdRiKb9z8adPC t/dnce0j/TsnrdvkY0+/W4ZcEdtHB7B9eRTLaWDb1Bmi/L1TExey/MTxLVi3Lpsz/oDu7dTnJDDh ja0rXWqeH71nL+T56LkGDrQTRS5vHttZlbll949lHVz++/EHxRTl48l21jwneuYbGDNls6rZ0Q88 xAEunE4+z4XPWeXAOrUwZlS2uzjIr+eoFctc6O8fvVPYYfFpK+mmTi1+YeQtF0mAlB3m17PT/73l WvndhR/We9ryVY4aKaA4Pr/3eE5Y/MwVqomoe4kOn1vzdWLPmHtg3IItq111NtXGbWCf5f5GZ23d dv6RlTQ+5daJr7QfOnj23rsHrqp3pyYExHfw0K7mG9Fv25bNQ6Oq4qm4TDZz7wNlBu18g86gPzRq /+M1OiE+gcWpCh2tMKpaB705fXRvN1vIoOC05erXVq+WHDeOSNJrR+sIz5zdQ0e8c7FtgH33lhzH MvnlB/KsJxX5LqOnrZ/kXX7k/+Im24U6dLeXX9FV3rtFpG/iG82aO8izvv5g3tIvLhS4eIrbOnG8 vDihEoqlu3eNz4NYHQM4yjf80zqMnOJy3Bz5/i58RyenxIlftmnDP7s4dmt6cUJrjjubzQ99r31i h5LDE16Z90fLAPsegWaOP6LPtOXLdUZJ5fnRf/ZCuneba/BAmfzYRbuL4gC/LsNTk6Mlj7/esWh5 Kym7xrwNz9fz+QlrVjpWNxsdwPG1b9di8iY30aWNLw2+LLKPDh8aP22Kfe7uyf2XcFsnvLF5pbNy HTTgLE8YFcAJ8BoZMiHJ7uHnkwYs57WKnPXONh/xpQ39B+7NkjFGwA0NS1i4eaWU2YtY63Vizyhp HjnjvW1+OpsKlvTxpy7+a2zW1u3zo3QGjb99Yp9G+YGz95kBpELHUEIHd41Cn4j+27ZsebXr0wya 8b/7ygzatXCQrgwalZCQ8DR62BphVPX/ynXQjcafQc8Fz1omUf5cbOxjX48Xn+0YGJH8TMeW8svr p4zfdI0vigzompSWoPjn29zr6YUFrJIWU8OHxwvPLhiW9mDGupecrxwoyaxZPunHjiNfnzg2UcLJ Sv/w9fnb/8zj8II87bzsWG4evA7u3dqm0d2dyVgzNa+U0bvqlR3EU16mVRXqrMPIKRbl7MRt48oW S/u5Js1sLjv++YoV9vwSf/+Xm788zkFxbN2r4w/k8aNaPZds1vgnfuUVGr9A+dbVipKq7eqBUVrj b9cjek71rn+Pue+/58XP2DL4lYt8vnJq9p384jvl/LLv1zPZDz3Hjn9rtBu90nzpLb8Ix2hHZi4b nK93dKfZGmdMKI75uHWkZ9au5He/vzsgZXOXLt53d7w8ZnNGu3Zxc5QDpgqPLn93x/ftWwWFJK71 aym69v6LEz691T7Ase/I7d1eCMr7YcGGPb9w2c5urXt07O5/adOya6znJ2xmBCjdi1144NS10hrT YY5TOnCUvqYiRkyOKPrV2Kyt2+dH7yQlJ98+WSODDpy5v646gKYlKD9sZu4mdKwRQz6d+2/buvXV rt6q3SI6g/6bXZlBiwbnX9HKIM+aGVT1wdDTizHVemjx9FFx7jdtIINazVgqqd5TlD0qzj53+Ycd Kz46nsMTdvQRuHu1Gzp+tr2Hn1RS+VGy7FHB3ztXztt0XN5h/qqF7f39nDXKWb22H1jbQkdPZ6+s nZpHqbqjX7hJgd2d2orVu/TrWNI7uCqDjNdhUrByizrl9RjVvWs7NyFFlT8ouPDlx2+9/+VtWavm Il+vdiMmzRaZPv4iflTr2OmGMqh6YDzmUCvH1r5Ht7TqXW+PwaNWhPQIr7wd4fRfq6crKoTCgEHy joltW9IzkJXePrJ72fwdZ590bCmODeIyrsUMzlfnoxzvh8FT28d2UX7EXnor6+CqGat/euIgjmgR k/r+Cin178frL4S/2r+NC5cqvnZlz5LZ9OydJWEevKgApyce4wL7xIUojywsuXHk2vfbvvj2enDX hL6zNXqxF0UuafY8YzocjZFIyzx1NRXu3q6VCbO2bp/9fjs5KflOzQz69sz9dypDZ3pCQJ/KxNEu UfPu3H/rtq3DnvNR7dIZNH33XWUG7V48JP+K5v3X5zxGJvRJ0P4kqGqjen/x9NHx7jca/WfStNKi Nd8WZFfvcbhsiR3HScz3ceAK7XmRflwnWennvz2+9ERWqLpHjs12kvD93QRSMZWTWZihXS5SXPm7 4IaOnvijXnQOkau647YLksS1FnhU1NzlMIdksA6DvLziTEbxiTsltwtlpXJ6DhxnMc/Xle8s4IT4 8/1YZeaN34Hf3bN044HqHv1ln3yna1s1EgNDDeJe/iv3u+yKUkX13NmyU5eeHLtVertQTl+xCIQ8 H3fhMxJeVBBfylwSlBqcr45HFfn3S775tzA9t6JYOX22m7MwyJkn9Y1JWqaKiTFZ9pxHeWX5ZcpH PVzsg5w5Lu6CKFd2cW7J9+lFFx+W5Snv6GQ5SwUtXPiBTrwWbuX/OVizF5nstxM1p1PzqRQX6GnK i52ZYcKsrdinv99KTkrSyKDLdwszsgvpDWbc0DFEf23pKQryEjErV2bQtuHPVf28jM6gqV/cUWbQ njdfyb+qmUGbTyqcXZWfKtEZVP1VtUkxC3NuXBwRIRE09nUQTS77+0rZ3TLF0+t4FovHY3u58Fo6 s4X0dBXyzKyy6/nyEjn19N5pCbdtM07hfV3lXuyszJoNPsUOb8XLvq56lB3eWujBUvdeucvRGJL+ OhqTKJffpAdToCiRKSoHwxJLuMFePA+++eP35rmxGT0yB6wxeI7BoQYL7QvKzt6reCyjVCEXHixw KKnIuF+RXaworyzi8LmB3vxAkcZkDM5X56MK+b0H5Zce0XlaORcWy8WV3943OnTakuofsYn8hVRR OaW8M4jNdnflhbpxBMonV5GfX5F+vyK3XKG6aUgg5DR357cQyc9frdmLgnqcW3M6GmeDracpMVVW ZMKsrdinv91KHjcu65Tm50Gmaxbef+v27cO7Pc2gKTtvV2bQkqEFV49r1C6rkMvkxm+Kp7NIwOWw GkmQQ1MkiAqc8mZ1BjkkhNjpjG8w6pMjN8ePG1vHDNqy/YMR0c+odukMSv38pur+oFcLrmreHwRg O0qfrPgqt/JyyaFPO5GOW0DBBJ8cuRHVo3dIgHetWzh/9c4fh78fEc24P+jzzMoMWjrssdY9igC2 Q15+Or04S3m5xO2CDKqDLd9fMl7JoPG9W6m36Qya+GnlPYp7l41ABgFAA1P+W41Pruq9TxoAoL5N 3FV5f9BLndxIjwQAmqIv/3rA6hYVeeTosbyHVXfGKDgCsmMCANvGklX9U+x7tzOTJk1HBgFAg6pl Bq3ZvqeBBmgFZo0bxNxN2/A3qZFYm9WT25MeAjR6tckgOoA03pY2TGOydABtX9Cd3HCsS25uLukh QKNndgY1qQCias5XFUDjlvxCdERWBOsgqDvzMqipBRDFmLI6gJKGdSI9KKuw7bO/kEFQd2ZkUBMM IKp61gggbcggsAhTM8hoAMXGxjJ3f/zxx3oYrXGqYViwd3ri90qCjAbQpME91Nsbdx+2VO+qZrUb ZJbr2zaxqVpDBoFFmJRBpqyAmG9+iweBif3WB1NWQBpvb3rXUm91U4LDlJyqD8ggsIj6zSDmBvMh FXVwaNfXaNZAZY3WNFrQPlzfGPQxmkFGlx4qzIRS7Wonl7mVDayDtFvT1x1z5Gat5pBBYBENkUHa 5Tq3Ka0Y0plNBto0PIzardHqkkE66zDf/DqPNaWyudv6HjLxOk4nZBBYhIUzSM30gDBl20CI1C6D KJNjqJ4yyMDbvi5ZU/cMMjoXNWQQWES9rIP0FdYug9Rql0Eah1NmxlAdM8jwNZHRy7F6zSCNvigz YwgZBBbRCDLI9DZNOZxZTd+jTHX/PMjcy6iGXAfpG7O+R5mQQWARTTSDjD6qVpefizXGDDL6qBoy CCyiQTOIqnl9pH1xpFGus77hn53p+7mYxuHaHelj4t2J+n6ipH3Vo+86yKzKZuUOpRVtOgds7i1O yCCwCItlUF005P1E5rL4HdL1fdtOg0EGgUUgg4xABumDDAKLsIoMsmb4t/IGIIOg7pBBRqgy6M9r j0kPxOpgHQQWYSSDZm1KJzc2K4J/Lq+NziDSQ4BGz0N4OW10ompbbwbh1wbSsA7S1sVfQnoI0OjN W73VeAZhCQAA9WT//3YigwCAGFMzKEhaQW6QAGCDLudyKWQQAJCCDAIAkpBBAEASMggASEIGAQBJ yCAAIAkZBAAkIYMAgCRkEACQZMkMWrN9T30PFwAal6Vpybm5uQYqWDiD6P4sNHIbN2/1VpwrsG30 i5wikkGG+wMVnCuweaoLI2SQlcK5ApvXFDMoNjZW40/9GP07q6R+fz7xc9WIaDx9lMl/9aB2zy/B V4WNQQbVyCBTyhsS8XPViNT6aaqP5xcJZTpkEDLIRuh8mlSFRv/OJfOJ1vl3vbULdR6lsaBGDJkC GaQ7a/RtNzDi56oR0ZdBFCMadD7RlJ4/yWv4haFxCW+gCzAMGaT78yCdFRoe8XPViOj8OM9wfNSi XGcGGe0CDEAGGXlVae82JOLnqhExcC2msY0MsirIIFyL2QhkUCOFDMJn0jaidhlkkc+DkEF10RQz iNLz0Y/260b9Iw9kkPXTeX+QgbWtdp26/FxMZxeIIVM00QxqLHCuGhJSgwhkkFXDuWpIyCAiyGTQ rHGD8Bs8TIRzBU0BfneHlcLv7gCbR+x3d1hm+LYOGQQ2j36R04t9qVSKDLJGyCCweSTXQeHh4adO narduOtybCOizqCGPFfa9eu7d7qOelu7a41CA5V11tfXkXYLho+tj/EYrqPdssb4DTRr7jjVddQP GT5XlOXeg431WqypZVBdWHkGaVTQeBvQ2wZa0HesiQPW7svwsfUxHn1t6jzErHmZPk51IWVaPGmU 1PHNaBXrIPUpo7TyXmeQa5xfnZVtg/Y6yLLnypSXvs5QsEjvGvPSeYjOIRkYmylH1fHY+hiPiZXN KjcrgwzHluEAUpXU+t1nLRlE6XpdatTReClbJIOtnM4MourzXBnNIAv2rn2IzneCiW8MC77nrSSD DFxPmbvKM6U7fYcYLbSddZDh6dVx1d1I6VsHqStY/FyZsg6yVO8aiWPKHNUllLGPJ8zNEX0pb8qx Fm/T6HeO2j2V+voynCbIIJPqULZ4IUZZOoOoWr3BLJVB2r0zM0j9kOEBGCg3PYMMNKhvDEYPt2yb pszF6DvfxKPUays1cxehyCC9JTbA4hmkr8TEmpbtXWNDXz6amCZ1zyATK9TutWcNGWSpQ8xachrV KDPIlKW4bah7Bpl1riyeQUZ7r+O7V9946i+ADHRqwTYpY3OpRacWPMT2M4hirA81pqouZB6rXdNm GM0gqm7nytwVU308U8xrAcOXCRrRpl1f/VAt1hQ6x6B9rPZ4jA6yFm0amIt2tTqO03A75n6v0vcN xkBONdb7g5qIhrxPurFc3lrnqJoOi59/ZJBVQwaBtUEGNS3492Jg88hkkGXGDgC2AusgACBGtd5H BgEAGcggACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQ AJCEDAIAkpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEA ScggACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCE DAIAkpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScgg ACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCEDAIA kpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScggACAJ GQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCEDAIAkpBB AEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScggACAJGQQA JCGDAICkumbQT4cOFT0pUJUigwDAXHXKIIVC0Svm+W++PaiOIQCA+pZz786EKTN+OPRrVQbt27e/ rLSY9KgAoEkoLy0pyMt5mkF0Ud/eMZs2vsfl8e1EEtLDAwBbRq+A6K9TZ8z+5vtD9EZVBtHo1RD9 dcXieXQSCQRCgkMEABuWOnMO/ZVeAal2n2aQSnTXZwkMCgCajCNHjzF3/x9zfvxFCmVuZHN0cmVh bQplbmRvYmoKNDUgMCBvYmoKPDwvU3VidHlwZS9JbWFnZQovSW1hZ2VNYXNrIHRydWUKL1dpZHRo IDM4NQovSGVpZ2h0IDE5NwovQml0c1BlckNvbXBvbmVudCAxCi9GaWx0ZXIvQ0NJVFRGYXhEZWNv ZGUKL0RlY29kZVBhcm1zPDwvSyAtMQovQ29sdW1ucyAzODU+Pi9MZW5ndGggNjM+PnN0cmVhbQo4 BmBPCDp0/T//////////////////////////////////////////////////////////////a9q1 DCgAgAgKZW5kc3RyZWFtCmVuZG9iago0NCAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggNDg4Ci9IZWlnaHQgMTg5Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMg NDg4Ci9Db2xvcnMgMz4+L0xlbmd0aCA4MTQ5Pj5zdHJlYW0KeJzt3QlcFHX/B/DZe4FdTrkUQgER L7wQCZVUQgHNTFMz9fEET7yvf2pq5l1mqXlWT6emz2NmpZWZZZmmpuajpuKBF+LJodzs7n+WhXWY nZmdXRZ2Bz7vXi+c/c3Mb76/Yfezs8PMJtLpdATFiKS2BAAAOJKP9p6kPhQZgzv1pfZPijRLZ4x0 cVKIJDJ71AYAAJXoNCV5BUWvvfWhSiFZ+9VxQ2N5cJMH2gtSB7urnbWFuZqCHG1hjl1LBQAAPZFU IZIqJU5u2XeuLN52wnDorQ9uMrXfnjNKU5ijLcgmU9vedQIA1B6bvztTxR5SekaQP6Vq34yb197d c47Mbn1wD3y+9fp5I0sepSO1AQBsaMu+s91792/TLMTqHk6dv/Ljnp3JiS3I6YLi0nmf//3lT6dF XduHb1+WoinILn6YbrNiAQCAILZ+f37WrJkF6Ues7sGp4bMrV64andCMKAturZaY+MFJfXBvWzKq MPMfbUmh7aoFcARSachI3+jn5Apy+p+7O/a5DZimJCc+ezO/2N6lVTd5O/8hdWawDuyDHy/MmD4t 78rvVvfgEtLprbdXj+oebniYX1Sa+tEZUdtmwd+uTsm7cZK29NpfcsQKJ7OdqjUPB8f4ScQiq8sC LvLIBsNmGn8NuuJHJQ8v5KXty067pNGWN4pcIj1j/+UW4CvWL1GoeXQo85sPCkrY2mVSv46u4Z1V DZrInWUEodXmpuWlff3o75MlGh331iucv/Pxorxi1mV0hbcL0nY9OHG4uLS8Q5G6nUf7vq7PhErJ DZY8KLzxc9bxPXmPS6yq37jFsjIIyrRpPEnDfQYtclXe3D3yxbVnC3Sqnl/+/JY3cWx+twmtBg3o mcy+Iu/fCON47UBush/KW8oG2y+4tdxupdVxH+6/NG3qlMeXfqE2nk1/+L/0h+TEoC5hxsZtv1wi f7Zs6NWioRd1YXVYl9XvrBkZX74kGdwjNpzWB/eeVaOfXD9B296Ugx538s3/tj2yjq0ZEKCUS6wZ E5gljwocNduZfPnFDfujSO31TOvYV6aN6R1OXPvk8oE94hIdIfZxf3G9r1/2meWDF3z7QBHWtfeg thc2rO3QLSLyZab27omd+3TPP73v4P7DP52+e0cZHjdh9fSkBvnHF5499j83McvWuw07/IQ6w2Xs 4KBWctNlxHLP8Lgp789M8M3/c96p4//UkxAi1/gGA8a6EH8fXjlvw0+ZuhZDZ66a1Fp37ORnq1xK tRbX38Uv1MW4xfEtB/TvNbZi+sWKkhjqH3GnnjpISYi02rOXHt8jpC1b9160eYk724p8fiMs47UP OWWfGIdT8HDR9ruZ5GDDPPt0qFdfaqfa6raPDqRNnTwp58IBauOXh67M//QYObF4aNTA2BDGFiO3 8Lh33n1vRFxjw0MyuEdvOasP7t0rRjxJP07b3mHlCz26dxeJ9UT6fyomK/+7bM7Yfo2yENzVRd4h KOW1shfkqFx/F2+RrqhU4dp/28x+DR58nXL0yt0QVbvA0a+rxBfX9el/TKwMdRaVFJfceqT1aZYw Z81yD9P2Rh69wiRf//xIo5aq5WKZiNCqevxrw6JGxb/MH/p6XIyHr4Rl6/VdvCvFujymrYe/lGEZ nVvvYWtfe6bowNwhi57vFBjaa2tgiDztzbhx3z1qHKCs7yRRtF83PbVd0cFJH/6WHucXaXH97eLb ja3YYugLCzcv9SjfuseLkWUlVSre6NSRjXtbjZ3rTJz8z9Tt7d9ZGUSZdWbDQplGLH1moF/HJJWX q4goLrlzOOuv7VnpmVqiMu7xxiV00Nd27eHxDFWrjgrZ2Vtb5j4u9VK1H+sT0V6hEBFFt56c+Sjz xIkSjbGrqw/+SHOO6OaskhGF6bknN2eeOlf+4Ufs4dI22adVtNJJQhTdeHz6g8y/TpNvdhUrVmyF /q5TNhyJYZmT/xk7/kK+PCYyODSKqSuC36jBWv/++crk1AlZ536kNu48nL5w2ynD9MJBbfQ/KQ/7 d2xIXdijefd3164f3q08zcngTvnwgj64dy371+Nrx2jb+1PVl09wL52V0ifoAYK7uiiiG42d71Ie E+692qg9SkruEn2j5ozzzto5fdS7SV1j2o5e6UF+dC+5nfbX0fxHF6RX/ziX9rhQHhH/xjp/03ZC FBiguHuz4H6BTu2pCPJQeIXNbNq3q+z+5+NfXu4S4TcoVC5n2foLbV39TH/P9GXUPqruQSlT3IoO zEqYQrSNn71ktZfywnsvvvwr4dzaQx4e7BLomRQycbJ3zq5pg1fEdIuNG7fKsvrDno+aULHF0F4L Ny/zYKtQ3FqeuiTM+IlBlbj959U++odjm/VMbDedMotwSh78fMKYlR7Kh38uHrLkpxyPFt37D2lV tG9DsKdMJuI93vZ9569cpCaI+9/M2fXDwUOncu+Uus96d2dCdMCTn1JnrzyjGvXZioGB975NuZx2 29XJ0BWRd3jl7t3fHb7s13TG1tSOLrd2jcq4cc9ZJFd2WBMaHVT057z5Cw8W9vvgvdHhd74eff3a HZWyfMWnW1HErf55XWvqcIa+1DvVUOfYZklB7TuxdCVv3mAkj1GDtT755Vrq+LEPzuyjte86enPx zrO0xvn9W/SNDqQ11otIXPv+xn91aWR4mF+kGfdxmj64//vm4Nyrf9KWPu42ICExoTyfjXFNTfGy iSUzk3sHZCplCO7qoXg2eOJCVXlMuPWMcNEHkzI2aMJcN+2RuQljRc18X3l2MNH51Rb1jTe7Pr73 /dTMcxmygIEahvablN5FYs+4gIEz3Z2zD83ts/hgVptQ1+4tnH0ktK3TnElfNzO3iLFC9xeiI5rE LQpsWi/vx3FDFvzeqFXSvPdXeIpPLHx+WKa3unWIa4yHiFB2bjRhnlpzeG7C+JLGPoNjh0hiLamf usXQXgs2L/Ok7R8jWZTPpMV+xqNjVezQjeSBtmHFpNmbV9SnfphQPpuy/h0fyZktE2adfJjlJyeK Ckvu5Ogioup18RBLRDzH22v+RvKNRP9GtS9fGdNAKpG2TFi9pa3rpfUv9f2+UBnZbHDK21P9s3bM nrjuhehurVPJrq59OODF7Q+kMUEKRb2hI1eN933w+Zzpm/q0bds4eY2Xc/qHA3rvzJZFhvVJWTc/ 8OG2OVM29I7qFqFfkbIVZexg49AMw3HuOn5jxZ5pGDNj7aZAF6au2ndsPm6Zm9lRg7U+/fX6hHHJ 9059azpr9/GMpV9dND587aUmfdrXN13Mp02v9Ru2DH2u/CMiGdwTPr+mD+4v5vfLTjtMW/ps/ZGJ iYkViV0e3aKy/6gtb0wb0aNeulImNtkc2IKic9NZy13LX5Cq+FCxt4QQeQ1tOX6sU9bO1D5vSIJU ScGiGxeLfysNCXx24MjUvsFk0D3es3LG0o71xf9cYGoPkOhPJ4jUqshZoQndFETOubcHz9hx1d1f 1cxTGh0kchWbbp12jls2NEHdTEZdhqLg+o2fNix4e0+G1Dk6uH3ymg0BzmTEDLysco4NEQfKCJF7 v+ap01xydk3uvUAUpEpsJLp5yZL6Q7q0NO6T0KTXN6/wqrx/WPdei+di53Cs6OQSvaxhfHvDG1Xx vSMZ+5b9fvR+AUEE+Ik96fuEZbyhcZM2Grodcd9XFeIlaRfQKXL2SlfRiQVxwzN9VGFB3YYvX+pF vun2GCtumzhzBdnViUXPD7vppQ7xELcN6tbu/96sV/aWLG/bY8qylW606NQdnddjjKRt4vTlhoEY txIbOafy88SZMvbQhPmbVtVj7KqZd7+ey4LNjhqste2PjOQxY28e+9p01r7Td9/de8X4cHJSSGJr X9PFAqNe3LJp46CY8kwvKNZM33VfH9zbXieD+w/a0v/zH5GUmCSSlCe1SYKXH3G/MXVED28Ed7VR dA6fucz4guzeWOItcVF3/7hplN/DHYOGvnO+eYhzl8YSt2LtpfvajCelOV4jpqyd0KDk0P8lTHSK cO3irL3M1N6jUXRg79frN3TVZnzzwdwlX57L9fJTNXeX+PtLItSEiHnrtHPcojYhEn1KPl2GEu5S ibebPNhL7ubu3nv8V82ayU8vit98oSCpqcRHLJZHvNeqd+vCg+NemftH4xDnrqEW1h/Vc8qyZYz5 W7Z/2Pdeiy6d53CuqNEeOe90XhUS1GFIakqs+vE3Hy9c1sRDXGnc3OP1e27cWyvcKrqNDZEEOrds NHGDt8vF9S8NuOTiHBs5KHHKJOesHRP7LJY2TXp94wpP/RF339MyZUyIJMR/WItxyU4PvpjQd5ms SfSMd7YEqC6u69NvV4aGUoE0om3Sgo0rPKhbUZk8T5wpLQ2jp723JYixq3B1z2Di/D/mRg3W+uIw Gdxjbh3bTWvfe/oeNbUNyOxOau1DawyI6rNl06ZXOz4N7mn/vacP7u0L+jMF9/CkpKSneS2mJXj5 v2VH3NcR3NVF0Sl8xlK1/qqSUY8DfV94tk1oVMozbRprL62dNGbDVblLdEjH5JlJuv99l3XtQl6u qLDR5MghicrT8wfPvD9tzUuel/cWpldun7C/zbDXxo/qrZZkXPjwtXlb/8yWyML8nPydRN6+stY+ nZvPJDd3Ku2tydlFlK0b4iBMpj+LUt7IuAwl3EWEp7u0WT2xyuPFesnTG2qOfrF8ubO8MDj45YYv j3bVHVnz6pi92fKYJp1SLKp//Nf+EYnz9Xlnkr/l0xWFESb1t+waO7viYXDXOe+/5y9P2zTglfNy uX5ozu2CEts9/GX3r6cyH/iNGvPmCG/yM81LbwZFucW6Ud/MOMfbILbdLNoeU6riPmka7ZexPeXd H+70HbuxQ4cGdz5+eeTGtJYtE2brCybyDi979+MfWjUJa9F7dVBjl6vvvzDus5utQtx6Ddva+fmw 7B/nr9v5i1Ts6d20a5suwRc3LL0qem7cRsq7DrkVp8jQyas9Kg2HWqdHv+FsXUUNnRiV/6u5UYO1 vjh8Ozkl5dbxSsG999S9NRWpPSVJ/1dH6sOkNpWyO6B9ny2bN7/asYHhYT4Z3P/JLAvuhQNyLpsE t1/l4C4/2f30XInhyHvR1OEJPjcQ3NVF0anJtCXqike64kcFmWcu/fjx8o+OPpQp2wQofPxbDhoz y9k3yENd9jdFzaPcv7etmLvhqLb1vJULWgUHedLaRd237l3diGFLpy+vnpxNGDZHvtqTQ7u4N1cZ H5IvfnWP8PLgNr8MlU6Uld8uu+vwLh1beisJouR+7rmvPnnz/a9uaZo0dAn0bzl0wiwX/vXny2Oa xk/lCu6KwmTUUstqa9W188yKhw18Bwxf3qJrZNkVkCf/WjVVV6pUhvTXtundvDE5Ak3RrUM7ls77 +PSTNo1V8WFSyqkSzvEyzpU0eBA+uVV8B/3fWotuZuxbOW3VT09cVVGN4lLfX+5B/PPJ2nORr/Zp 5iUlCq5e3rl4Fjl6T3VbX1lMiPsT39GhPRNa6NfMK7x+6OoPW7787lp4x6Res2hbcXaJXlz/Ocpw JLRKPIr9mLqK9GnZhMeowVqf/34rJTnlduXg/u7UvXfKknpqUkjPspg2bTFq0L7P5i2bB3cKMDwk g3vqjjv64N6xaGDOZfodmWd8hyX1TDI9u10+UfF40dQRiT7X8cfJalSU/9Z3uZkVjyRSsdpJ4q6S B7hKlc6y6CCpu6boi98eX3yiyTPcACIWu6vlwd4KDxXxMD0vzbTdRXf579zrDFuSD3/Bs4XWsDlp yzB1QlOFb2nlhxJqSZzLUGhLSk+lFRy7XXgrT1OkJccg8VTJAuvJPRWSFsHyIFGxZfW7yrv4Fa3f W7HFYM2n3zNNGyrhKDVMeumvrO8zS4t0FWMXa05cfHLkZtGtPK2GDGGlLMBH+YxaFhMm96AefBZx jpdhri7nXuG3/+RdyCot0A9f7O2pDPOUeQTGJS81ZOvIDGfJo+zinGL9XF8v5zBPiZePIqaeuCCr 8IcL+ecfFGfrb1cSeXooGnnJQ91ljbxL/r2v8lY0mt+OVR5O5V+lKpelK39xehqPUYNVPvv9Zkpy Mi24L93JS8vMIyeoGU1mN/mzsZ9LmL8LdeGy4N4ypFP51SZkcE/+8rY+uHe+8UrOFXpwbzyu86yn P1NOBnfFT8MkQW18eP380Ci1Akfc1Uer+fty8Z1i3dNzkyKRTCb295I19hQryd+DTpueUXwtR1uo JZ7eTamWNq8vybvH1O4vzkiv3OFT4sgmssxrhrniyKZKX5Fx62UPJbSS2JehDaJEe4MsJldXqNGV FSNSqaXh/jJfueX1N5B5iylbpBZMK17CWWq40jm3+PTd0scawvDOEBmucC0sTbtXmlmgKylrksil oQ3koS60wXCOl3GuTnv3fsnFR+SbUNlYRCKvevJWgbERUxZXXKDiEqwk8ksI/RXcYrFPPVmEt0Sh /+XqcnJKL9wrzSrRGS7uViglDX3kjVy0Z69U3oqOeJxVeTi0vSFm6UpFFOfzGDVY5bPfbqaMHp1x gn6Om7/6kX02b906pPPT4J607VZZcC8elHvlKG3p4lKtRmv+Fl4ywBVSiQjvzACWUsSETnqjIrhd k1o4Mb7ngaB9eujGmNGjqhjcm7Z+MDT2GcNDMrhTv7hhuI771dwr9Ou4AaDaFT1Z/nVW2dkM154t XRjubwKB+/TQ9ZiuPVqENLC6h7NXbv9x8IehsZTruL9ILwvuJYMfm9yAAwDVTlty8kJBhv5shrQD gruW2vTDRfMLcRrTo4lxmgzu8Z+V3YCza+lQBDcAgOPT3/L+6RXWOycBAMABjd9edh33S+287V0J AADw8tVf90WdY6IPHT6S/aD8QmGdRGHfmgAAgEakKf9et7u30pMnTEVwAwA4OiuDe+a6v2uoQAew amIr6sO3tu60VyWOZsbo/vYuAaAusia4ydTeOr9LjZVoX6MX/0INbjK1kVYAYF8WB7chtck4q8kq 7csY3EhtKuwNAHuxLLiNqZ08uF1NV2oPWz7/i6gIbuQUDXYIgL1YENx1LbUJSnAjpExhnwDYC9/g NpvaEwZ0pT5cv+NgtdXMxVCGrbZuCG5f5SWzCRUfH2+c3r9/v022buzWtENqO9s0z66shuAGsBde wc3nWJuamLZNT27Vui3qqRIOtEwkH9oqH/mkLZ9wrw4IbgB7qd7gpk5QZxkY09Z0eVq3HAvTeqP1 YLo6Ww2M+AS32YNcA2qsGx6axr2lC3MccZv2xrY5auUWfW5AcAPYS00Et2k74zRhkt2Mgc7RJ3cZ VnwaqGJwMy5DTUzGdfksbOk02yyep1kYIbgB7MXGwW3EP1X5THMkr3XBTfDL7uoLbo6srEpAVz24 zY7FCMENYC/VcsTN1mhdcBtZF9y01QlLsrvqwc19ysLs2ZJqDW7atggLsxvBDWAvAghu/n3yWZ26 GNtcI5uc47b0LEdNHnGz1cw2lwrBDWAvdTS4zc41qOJVJUIMbrNzjRDcAPZSo8FNVD59YXrugtbO uDz3lSdsV5XQVjfdECOewU2wX49helKC7TSFRQtbFNaEyfsBY8GWXoqO4AawF5sFd1XU5HXfFuEf 3PxV9+XVNQbBDWAvCG4uCG4OCG4Ae7EsuO1VpX3ZNrhrDQQ3gL1YENx/Xn1stzLthzzoRnAzQnAD 2IuZ4J6x4YJx0brzpYBUhrMlAAAOwld5aeaI3oZp1uA2/s9u6uYRd4dgtb1LAAB4au6qzeaDu24e aAMAOKY9/92G4AYAEBK+wR3mUWq/IgEAQO9SlpRAcAMACAiCGwBAYBDcAAACg+AGABAYBDcAgMAg uAEABAbBDQAgMAhuAACBQXADAAiMLYP72PWC6i4XAKAuiApy4phr4+Dm3hgAAJhlNksR3AAAjgXB DQAgMAhuAACBQXADAAgMghsAQGAQ3AAAAoPgBgAQGAQ3AIDAILgBAAQGwQ0AIDAIbgAAgUFwAwAI DIIbAEBgENwAAAKD4AYAEBgENwCAwDh0cMfHx+/fv5+7BaqC3J+0Furupc41tjM2crRbuiGe3fKv zdBoeEidZiyPnMW2DIDjcPTgJkxernhF2RBtD3NknGHPMzYSlX8vjMHHnYZs2+Uzzac2thXN1oYQ B8ckgOAm2F+NpnMJykETwXIAZdotbVbdeaGy7Ry2A08++8dWwW2r2riD2/Rg3/RZRJg8x2iNADXM 0YOb9iplPHlCVH5ZEpzZXfVgqk3MhiPjXIJzF9VYcPOszdIjbu5De+6xA9SMWhjcPKfxIiQ4g5tg Obo0e8jJeDqL4yw221xb1Wbz4GYbOECNEUBwE5XTluNVyj+4aSvWWdzhSG3h00iw/xGC/xG3zWuz YXBzDBygJgkjuAn2V2MV/65Vx/EJR/6NbKnN1oMV/VtRm22Dm0B2gwMQTHATPM54VD2461qsc2eW aTtjo/GhRSeX+fxSOH6J/Guz6GljRWEANU9IwU0wvWKNeIY4bUU+h2+1GG0fEiynBQhze4+xn6oH N9vmrKjNuuCm9rmf5ToTgJrn0MENAACmENwAAAKD4AYAEBgENwCAwCC4AQAEBsENACAwjhvcpleY GeAyLACo4xw3uI3q2rXVAADchBfcbDfsMd5bQV2FwC1wAFAr1LbgJtjvi+P/TRcAAI5MeMFNVM5i 676eAgBAuOpKcBshuAFA6OpKcCOvAaDWEGRwMzbie1wBoI6obcFtZPYrQDk6BwBwZAIIbkY8//co AAC1jyCDGxf2AUBdJsjgBgCoyxDcAAACg+AGABAYBDcAgMA4dHDXwN8b8SdNA+qtTADg4OpccCOp GSG4AQREkMHNdkMNrd10MbYW2n3ztJ7Nfk2V0N8MkNoAwiK84Lbi1naOxfj0xvaFsdx1CgiCG0BY ENx8g7sWf2UVghtAWGp5cPM8N1KXgxupDSA4tTm4Gc9NI7hpENwAgoPgtkFwCzrNEdwAgiOA4KZi uzjEdHmO//0Nxx8bua8qIRDcAOAAHDq4obohtQGECMFdpyG4AYQIwQ0AIDAIbgAAgUFwAwAIDIIb AEBgHDq4zV6cBzbBsZ9pjdRZbL8Cxgvqrbh9ibZWFcvjfwmp2f45tmJD+LsxcHDc4Da9whrP4+pg xV1OBjyDm/qL4x923FlvaXkcy1t0KxbHMM0Oh//C1LXwnAdGggluxnbG+2uo7bXvK1hti/9OZstB 7j5p0cN4LytHD7Yqz9Igtmh57vty9zN9vTDB8hSlLYnnKrBx9OAmLPkgTHvx1L67HG2O+52vKsFN 65A2y6JQrnp51RfctLGwfdpg+6KF2n1TLlQfxw1ugvc5bj6vCmBk3dezVDG4qx6g1RTcPN8YeNbJ cY6II7jNjgWAcPDgNqA9odleA6bLU9cCRtUX3IxvnPYKbsLcs4LtlE5V6jQb3KbFmGY3ghsYCSC4 Cc4XkqWxAlTVGtymS9oxuDnmxpv8DbDGjrjZyjO7dajjHDe4+Xx0teK0IF4JVDWQjNadO66m4OaT 2lWsk09JVr/zARg4bnATPM5xm/3ISVgY63UQ277i2PlU3IlGa+F5FovtV2x1eXw64eiK+9CYrVu2 czVsJbG14LkKphw6uKHOYjwQFgpbBa6gdwJUKwQ3OCiBxhZSG2oAghsAQGAQ3AAAAoPgBgAQGAQ3 AIDAOHRwW3GZNncnbDewMd7mZ2lhQmTd5X2m69pkV5i9iJN7W3wuuOa/IvcWufcb/2ppyzB2y33h IFsN3JXYqh3sRQDBTXDeE8yzEytez1b0KThWD8T0LbCKe8O6+wypCxhYFDfcK3Lf5FWVO7zY9h6f O3csuhPKotugrLvdCexC8MHN894K2tPOdC7HwTh3n7S5wnpOc3+miad8Kyn/wbL9jvh/rLEuKXi+ Q/O505KxAFojzzszLVqGT22Wbo5jRFWcBjty9ODeT/nOB9McseFTkM9rlW1d0x6Egv89ftzLmHZo urtM2/lUxf1maXYspu38g5u2UT5V8anWiuC2oiuOJa2b5h4U1DBhBDfBcgDoUMEtRGYTyvQh47rc B9eW7jo+n/HZxmI2uHmuyPZJjnt1PtXy+bBC3S5HJRYFt9ldavbVwVgD2AWCm/XZbFTrg5s7DvjE JWG7XRdv+TesctdpRXDT3n74r26T4ObOdO7PCmwV8tmlZqf57A2oGQIIbqJ6ztDxOeKmFcO9gBBV PbgJm+66eKu+YZW7zqoEt6WrV19wm62Tozyeu9SKVw3YSy0PbsbjwSoGN9txhxCf01YHt0VnM3i+ 8k0jhv+6HHPNDodncNMaLTrzYLYktlXYNsQ9ZMbVuUdnxTTYkTCCm9ZI8Dj7xvZ6Y5zm2S1jn2yF CUJVjri59zy1ndrC2JXpMqYFWLEuY7vpc4DnRtmeIYx7j6NajsU4CubYFvc7Ga037iItbQd7cejg htpBiG9pAI4MwQ3VDsENYFsIbgAAgUFwAwAIDIIbAEBgENwAAAKD4AYAEBgENwCAwCC4AQAEBsEN ACAwCG4AAIFBcAMACAyCGwBAYBDcAAACg+AGABAYBDcAgMAguAEABKamg9tGZQMA1Gk1F9wAAFAD ENwAAAKD4AYAEBgENwCAwCC4AQAEBsENACAwCG4AAIFBcAMACAyCGwBAYBDcAAACg+AGABAYBDcA gMAguAEABAbBDQAgMAhuAACBQXADAAgMghsAQGAQ3AAAAoPgBgAQGAQ3AIDAcAX3TwcO5D/JNbQi uAEAHARrcOt0uu5xz3373T5jdgMAgAN6ePf2uEnTfjzwa3lw7969p7iowN5VAQAAs5Kiwtzsh0+D m2zq1SNuw/r3pDK5k4va3uUBAEAl5LE2+XPytFnf/nCAnCgPbhJ53E3+XL5oLhnfCoXSjiUCAABV 6vTZ5E/yWNvw8GlwG8R2fNYORQEAALtDh49QH/4/mybw4wplbmRzdHJlYW0KZW5kb2JqCjQzIDAg b2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0ltYWdlTWFzayB0cnVlCi9XaWR0aCA0ODgKL0hlaWdodCAx ODkKL0JpdHNQZXJDb21wb25lbnQgMQovRmlsdGVyL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJt czw8L0sgLTEKL0NvbHVtbnMgNDg4Pj4vTGVuZ3RoIDYxPj5zdHJlYW0KOAag0Qg6dP0///////// //////////////////////////////////////////////////9r2rUMKACACAplbmRzdHJlYW0K ZW5kb2JqCjQyIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9X aWR0aCA2MTMKL0hlaWdodCA0MjAKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVj b2RlCi9EZWNvZGVQYXJtczw8L1ByZWRpY3RvciAxNQovQ29sdW1ucyA2MTMKL0NvbG9ycyAzPj4v TGVuZ3RoIDE5NzU1Pj5zdHJlYW0KeJztnXd8FFX3/1cIhhIg0luo0kFAeuhdpJcAAkqv0kKXXhUC JBBalA4PCIhI7x0BAYWASGiCoZeg9JKQfH/nxTzOb5/dyU7Yudm9c/bz/mNfs3fK3nPuZ85n7rZ5 7//+7/8sAAAArHjvvffc3QXTw89c3qOQoAzj8FNGQoByjOOZypEcCFsUzOQNWQiDmTJ0QU0Rhacp R34UbWNcjMAyh/8tecyicjEslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsB sFSGLp4ZtViQQznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5 hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJyYa F2m7Km3HjAC/FABLZejimVGLBTmUE5eNS4YMGR4+fHj37t3MmTNbt1NL1qxZ06dPHxUV5fgI0kpI 2o4ZQaRf5suX7+rVq8ePHy9XrpzSQssVKlTImzfvn3/+qbQ8ffp03Lhx69atI0FkyZIlICCAnvr4 +Fgfp1evXmFhYfQ4b948471yASyVoYuRqI1L5ezZs5MnTz548CCVG1pbq1atbt26VapUSURkrsMz lSM/LhsXUuzRo0dJxlWrVrVup5bq1avT2p9//tnxEaSVkLQdM4JIv+zZs+e33347adKkkSNHKi20 PHr0aGqfP38+PY2LiyMRHD582HovEsr+/fuTJEmitijFlB6vXLlivFcugKUydDEStUGpUHvdunVf vXplc1jTDYFnKkd+XDYunTt3XrJkCZ0L3bt3t26nFjoXaO2iRYscH0FaCUnbMSOI9Msff/yxZcuW 1apVO3DggNJCy4cOHaL25s2b09M1a9a0adMma9asP/zwQ5kyZU6ePEnb37t3j9pbtWql7ELTiw8/ /FBZJtfMkyeP8Y4lNiyVoYuRqA1KpXz58idOnKhfv35QUFChQoUeP35Ml+Fz5szZvXu3uPhcgWcq R35cNi5Tp04dPnz4wIEDZ8yYYd1OLSEhIbR26NCh9PT169e0wcqVK6k8pkyZsk6dOt98803evHnV rj579qxHjx4//fSTt7d37dq16bzInTt3YnfeMSy1LdIv//nnnwwZMnh5ef3999+pUqWiIUyXLh1N FKKionx9fWmDgICAdevWWV9M0WSid+/eVAqpLFq3qMt0kfX/+/p2AJ4/f96rVy86jqKMadOm5cqV S3etwurVq5ctW3bmzBnqEk1TcubMSWW6U6dO/v7+RgJnqQxdjERtUCo0uNHR0Q8fPqS9HPTNgRiO HDmyYMGCffv23b17N23atJUrV6aZLhmzeoSYmJjZs2evWrXq4sWLsbGx5NBUwho1aqSsdVC/3gnP VI78uGxcNmzY0KxZswYNGmzZsqV///6hoaH9+vWbNWvWp59+un37dlrbpEkTkmLdunXVK0uFzJkz nzp1Klu2bEpXW7duTZeS6lq60AwPD8+UKVNi998BLLUt+Ps+yoX/1q1babzpsWHDhtTyyy+/KGtp 4kj15dKlS/nz51daqBjR/IDaL1++rLSQekgltNfx48dpef369f+/r28HgKYdZHtqY/bs2UkZVHwd r6VlulKjiqnZbYPhs1SGLgajNiIVutC5ceMGORyVmIwZM8bXNwdisL+5Cnnqzp076fqJlsmMP/nk k/3799tsowTruH69UxI8Uzny47JxiYiIKFKkiPLZU9myZc+dO1esWLGTJ08qn0nRWtL89OnThwwZ Urp06bCwsJIlS96+fTswMJAKo/LhhdJVOsiKFSuKFy/+xx9/tG/fnh5pm+Dg4MTuvwNYaluwX44e PXrSpEkDBgwICQmhR7pQopYJEyYoa2km8eItKVKkUFpoOdVbaIZBT9+8eUPl7PHjx4cOHapatSpd +NMcImnSpP/tazzKGDx4MBmh47W0KnXq1PQqkydPpnaqazRpuH79OlW9JUuWHD161EjULJWhi8Go jUiFpobKvJP6UKBAATJamneS46ouqCuGGjVq9OjRg9yRrsHv3Lkzfvz4hQsXqu8PBwUFDRs27IMP PqDrfbr2pxelQjZlypS1a9fSWsf1y5U5BImEy8aFrsxSpkxJC1FRUXTl16tXL5LQ/fv3qQwmSZKE NJ8sWTLS2JkzZ6yvHWkDuj7LnTv3tWvXlK7StV316tWVtcp3hei8oEvMxO6/A1hqW7Bfks9R0Sla tCjVF3o8f/48tVSpUkVZS84XFxdHRqV+u4eeUiM9pUZ6Sr5VqVKlggULXrhwgR5JItRSsWLF//Y1 HmXQJRhdiDleS0/z5s1L8qpcubKfn1+OHDmyZs1KlZTqpurHTsNSGboYjNqgVPbs2UNGS8P98uVL ZQO6wNq4caPydq6uGGx4+vRpmjRpaN9//vmHnioVyvpjdWsc1693SoJnKkd+XDkupCKaXM6bN69v 376RkZG5cuWia8c+ffpQO2mMNiBDVUVujZeXV0xMjNJV2iB58uRK+6tXr+gq09vb2/4Lca6EpbYF +yWNX7p06WgGcPLkybJly/r4+Pz99990iaSs1Z1fjhs3jq70STd0XU+Pc+bMoZaxY8f+t6/xKIOe UqPjtZa3H1l17NjR5ju3VKm3b99ODmokapbK0MVg1Aaloh6E/O/w4cPBwcFXr17t2rUrTT0telKx vP0ke9GiRWR79KKKAROqGdOWtD2ZqM0vnRQc1693SoJnKkd+XDkuDRs23Lp1a5kyZehFT5w4QecC ve5vv/1G7Zs3b7bErzelh7pSdxcstS3+/wqU4a9Zs+a+ffvUIVew/1CKlmkeqX5+6e/vf+zYMeuj UQv53H/76vBKKiHXWRQmlcizZ8/SPCA8PHzXrl1UhW066QQslaGL8aiNSMUG5QdIGTJkePDggUVP KhMnThwzZoxml5RwFL8kYyZ7tt/Gcf1KePgWT1WO/LhyXAYNGqR80Kh8WECPyndlqX369Om0UKpU qfPnz0dFRaVOnTq+rlq/laK8cxPfWykug6W2xfslTQ379++vLtM0UV3VsmXLH3/8kWYANA9QWpT/ JVC+9Pj48eP06dOrF/sKdM1OQkmbNq0lfmUo79Q7XqvZVaXIUvl7/vy5kZBZKkMX41E7LRX7Qykf /9D0NDo62qInFdqStp8zZ07z5s0zZcqUNGlSmmWS9tRwHL8f67h+vROeqRz5ceW4fPfddz169KAF ul5UrhobN26stHfr1o0WQkJCBg4cSOodP3586dKl6RLwxo0bdIm5cOFCml3YfFRPHtm+ffvff/9d tVt3wVLb4v1S+caXukyXOeqq77//vm3bttmyZbP+Ud3du3eVwrR+/foWLVpUrVr14MGDyvbKb/Ko vVmzZha7L3GoylC+M+J4La0iqdGr02yGiiZp7ubNm3PnzqULOjLjR48eGQmZpTJ0MR6101IpX758 586da9Soofw+hLxt+PDh5I7FihWjEbfoScXHx4eukOhQDRo0IIs9d+7cyJEjd+zYoYZj/X0fKmE0 yySDnDp16qpVqyx69cvFOQSJgSvHRflkPUmSJA8fPvT19aVaRJducXFx6p/+vHnzpkmTJtu2bbPf V30/1v73JHRSaH513GWw1Hai/H9sjhw5bt26RY9UR6zbSQSkAPX9VQX1T1t0//NFGYCAgADrGUaW LFnCw8MzZ87seK26uz3WH5E6B0tl6CIkauekojmUNE1ct25d06ZNLXpSUf5UxXpfmubOmjVLDYcm qfXq1bP5xYi61nH9SnjsFk9Vjvy4clyUv4otWbLk6dOnlZZSpUqRUK3/VDY2NnbBggV08UfXdi9f vvTz86Pr/i5dulSoUEHp6tOnT2kyunHjRm9v7zp16uD/ChKJRPHLTp06LV26lB4XL15ss+rJkyfk T1TF7t27R2qguQI9Vd7X0v1PUWUA6AikjE2bNpEyatWqRcqw/p+L+NYSp06dovnB3r17L126RAUx Q4YMH3/8cdeuXZXJqxFYKkMXIVE7JxUSxrJly8jPrl27RqUkU6ZM/v7+gYGBNl+ljk8Mr169ouuw 1atX37lzh0oVaWDUqFFeXl7W4Sj/V7By5coLFy5QY9myZQcPHqz+X4GD+vVO4XumcuQH42IcljlM FL9MJBwPgBuHh6UydJE5apn7Zo1Z+ulpYFyMwzKH8EsBsFSGLjJHLXPfrDFLPz0NjItxWOYQfikA lsrQReaoZe6bNWbpp6eBcTEOyxzCLwXAUhm6yBy1zH2zxiz99DQwLsZhmUMz+aW0sFSGLp4ZtViQ QznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHM qMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyV oYtUUdv8o6wkvdJFqhwCFSPjYi3FpEmTpkuXrkyZMn369Pn000+F9c8MsNQ2/FIALJWhyztFHd+f 3Sf8CO90fLOMhWcqR35E+aU18+fP79mzp6FumQqW2oZfCoClMnSRyi9tXsgsY2Gu3noOxv1S2Tcu Lu7+/fthYWHjx4/38/O7fv262H7KDEttwy8FwFIZujjhly5IkbnGwly99RxE+aXCq1evUqRI4e3t TQv2m40bN2727NlJkiQZOXLkgAEDqPHmzZtjxozZsWNHVFRUhgwZPvnkk4kTJ2bPnp1W5cyZ88aN G2fPni1evLj1i1JLiRIlFEtevXr1smXLzpw5Q7vTYWmXatWqderUyd/fX9n49evXM2bMWLly5Z9/ /pkyZco6dep888036n2cHPfNSB4YAL8UAEtl6CLWLzt27EgneZEiRU6ePEnn8IsXL8qWLXv+/Hlq X7JkibL78+fPe/XqtW7dOio9tWvXnjZtmnK/6IS8kIMaZL+vfZnQLTGOd3c6LcAtCJxf3r17NyQk ZPr06aSZXbt22WxGOunbt6/aSHvRfPTjjz++deuW9TFJqKdOncqUKVPbtm2///77efPm0YlgvQG1 fPnll5999lmOHDnovNDsmNKlmJiYunXr2tzbNXPmzHT8bNmyOe6b03lgA/xSACyVoYtYv1QNskOH DkuXLqXH5cuXFy1a9MSJE+RPyu5t2rSha2d1Fyoi4eHhZH66L+S4Btnsa18mElJiHOxuJC3ALYj9 /DJ16tQNGjQIDg7OmjWrzWak8BEjRjRp0uTp06d0ATd37tzAwMCZM2dS+4oVK+jxjz/+aNeuXURE BLXTERRfJNekSzfrl1B8lHYfNmzYs2fPJk+e3L59exJnbGwszThJunTRefToUdqSnHvIkCGlS5cO CwsrWbLk7du36cjr16/v2bPn/PnzHffNiTww0zb8UgAslaGL8M8vySzJMsk4W7Ro8eOPP6ZKlYrm moULF1Z3p9knFZHixYtTEaFyQI+DBw+2uZrW7JXjGmSzr32ZSEiJcbC7qBwClyHWL728vFq3br1g wYIUKVLYbBYaGmp9dUUUKFDg8uXLBw8erFq1qtJCblejRg1qv3jxovK+a86cOSMjI+nakSaUP/zw Q8uWLXPlykW+eObMmaZNm167dq1y5cp+fn401ySHpvOFdk+aNKlyNBIwbXbp0qX8+fMrLXQ1SRd/ uXPnph0d982JPDDTNvxSACyVoUtifN9n2bJlHTt2VJe/+OIL6933799fvXp1pYUKCi0XKlSIbE+3 V45rkM2+9mUiISXGwe4O8EzlyI/A92OvXr1Kcz66uhowYEBISIjNZjdv3rT5UCB58uSvX79++fIl LSgttJwyZUp6Sgt0wPTp0z969OjGjRujRo3asGEDmeW4cePIHX19fR8+fHjs2DE6g65cuWJ9TLqG 2759O21Dy3QoOo59t8nUY2JiHPfN6TywAX4pAJbK0CWRvu9Dl8zKhfOqVatsdrcuIsp3KJQiovtC jmuQzb72ZSIhJcbB7g7wTOXIj9jv+zx48CBTpkxZsmS5c+eOzWaxsbFJkiSx3l1Xq59++imZH50d gwYNGjJkyIwZM6ZNm9a2bdv69etv27ZNeWm6vKOZKF3MhYeH79q168WLFw0bNty8ebMlfjFb9zm+ vhnMAwPglwJgqQxdEsMvnz9/TpM5ujr+8MMP6Zync9t6d3u/tPnOYXwv9E5+aV8mElJiHOzuAM9U jvyI9csnT56kTZs2WbJk0dHRui+hvBdy6NChKlWqKC0274V8/fXXI0eOrFy58qVLl+jijGyYpo+H Dx+ePHnyiBEj7PtDE9x8+fKRhunkoqelSpU6f/58VFRU6tSpEyN8sQeRDfilAFgqQ5fE8MtevXqF hYWpy/PmzbPe3fr9WCoo1apVs3lDlSAHpar09OlTHx8ftVG3BjnuZEJKTMJjNLgLcAEC348lSxs3 btySJUsKFy5MKtJ9CeWz9uLFi69YsaJIkSLqR/XqZ+2K8mnhiy++WLZsWbt27ZR3YpSPG0qXLk1z zZo1a5K26XKQXn3u3Lk0ASXDfvToEW0WEhIycOBAOsL48eNpY9rmxo0b+/btW7hw4bFjx4yHrxug qYFfCoClMnQR7pc7duyoX7/++++/v2jRoi5dupDtUUu9evXU3dXv+0RERFAR+f33320+EyJo7blz 52bNmtW3b1/1Q1PdGuS4kwkpMe+aEKd3AS4gMf7fZ+XKleRkui+h+13uV69ekfnR2bF69erWrVuT WZJl0lnz+PFjUmZ8r06ePXbsWFp48+ZNkyZNlHdubbB5PxZ+aQ/8UgAslaGL2O/7/P333+Rnt2/f DgoKGjJkCD0OGzYsW7ZsZH4ffPCBsntAQMAPP/yg7pglS5bw8PDMmTNbH418kVzQ5uDv9HsS+4gS UmIc7O4Az1SO/IjyyyRJkij/H9uvXz+6FkzgS9CkcPTo0Ta/Fc6RI4e6gb+//4kTJ2itr6/vP//8 kzFjxnLlyik/FyFJk4Pu3bv30qVL5Km0Oym/a9euzZo1U3ePjY1dsGABXTvSyfXy5Us/Pz+aj9IV aoUKFYyHn5AAzQv8UgAslaGLWL9s06bNmjVrqlSpcuDAAaoycXFx1atXP3z4MLV///33yu5Pnjzp 1q3bpk2bvL29a9WqRZ5q848BlrfvgNGl9HfffXfv3j3r7unWIMcR6ZaYd02I07sAF4BxMQ7LHMIv BcBSGbq4MmquGeYal9nBuBiHZQ7hlwJgqQxd4JfG4RqX2cG4GIdlDuGXAmCpDF3gl8bhGpfZwbgY h2UO4ZcCYKkMXeCXxuEal9nBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7l BONiHJY5hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQAh/wbi4+NT qVKl0NDQAgUKUGN8R6O19Hjp0iW15datWwMGDNizZ8/Lly/LlSs3dOjQRo0a2e9IB7Q57LZt20aM GBEREeHn5zdq1Cj1Rlrv1HMoxwjIoZxgXIzDMofwSwEY9Etlx6ioqJCQkJ07d/7666/x+eXRo0e7 dOlCC4sXL65YsaLSWKVKFTLawMBAX1/fX375JSgoaOvWrTYHt39Kh2rRosXSpUtr1Khx48aNSZMm LVmy5F17boFyjIEcygnGxTgscwi/FIAQv7S8/SflNGnSREdHx+eXPXr0yJMnD62KjIxU7+Oh/NWy 9a3bNQ9u87RJkybNmzfv0KGDE31Wj2aBcoyBHMoJxsU4LHMIvxSAqPnlzJkzd+zYEd/88vXr19mz Zw8PD6flkiVL3rp1y9vbm5Zpolm+fPl+/frZ/5mqA7/MkCFDRERExowZneizejQLlGMM5FBOMC7G YZlD+KUAhHx+mSpVKn9//9DQ0EKFCmn65dq1axcuXLhr1y5arlOnTvfu3QMCAmj59u3bY8aM2b59 +9OnTz/55JMZM2b4+fmpB4/PL728vMiAkyZN6kSfrXsO5RgBOZQTjItxWOYQfikAUe/HOm5s0KBB 27Zt27VrR8v/+c9/Vq9evWXLFusNaIY6derUI0eOKHf2sT8O5peygRzKCcbFOCxzCL8UgAv88t69 ezly5Hjz5o3aQhPEmzdv2tz98cWLF76+vtHR0ZrHsX7auHFjmp5+/vnnTvRZPZoFyjEGcignGBfj sMwh/FIALvDL4ODgs2fPLl26VG3p0qVLsWLFAgMDGzZsOGTIkPLlyz979mzmzJm7du06ceKE5nFs vh9LfkkHrFat2o0bNyZPnrx48eJ37bkFyjEGcignGBfjsMwh/FIAieGX1k9pgxIlSsyaNat69epq 48GDB/v37x8eHr5169apU6eSR3p7e1etWpUsM1++fJoHj+/3lzlz5hw1atS7fleW5fngYpBDOcG4 GIdlDuGXAmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJBDuUE42IcljmEXwqApTJ08cyoxYIc ygnGxTgscwi/FEAClWEiASWkqyYKR1qQQznBuBiHZQ7hlwLQVYb193dMkeqEdJjl+eBikEM5wbgY h2UO4ZcCcKAM+2+6uqhPhtHtOcvzwcUgh3KCcTEOyxzCLwWgqQwbv1EwUZ51+8/yfHAxyKGcYFyM wzKH8EsB2ChD02ksJkyy40BYng8uBjmUE4yLcVjmEH4pAFUZ8RkMY6AcI7CsKQzAuBiHZQ7hlwLw QJtUgXKMwLKmMADjYhyWOYRfCiCB80vTJTkh1wGmC0oqWNYUBmBcjMMyh/BLAeDzS+AcyKGcYFyM wzKH8EsB4PuxwDmQQznBuBiHZQ7hlwLA7y+BcyCHcoJxMQ7LHMIvBYD/9wHOgRzKCcbFOCxzCL8U AP4/FjgHcignGBfjsMwh/FIALJWhi2dGLRbkUE4wLsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BL AbBUhi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEgh3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyW OYRfCoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZUYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcY F+OwzCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQ QznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHM qMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyV oYtnRi0W5FBOMC7GYZlD+KUAWCpDF8+MWizIoZxgXIzDMofwSwGwVIYunhm1WJBDOcG4GIdlDuGX AmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJBDuUE42IcljmEXwqApTJ08cyoxYIcygnGxTgs cwi/FABLZejimVGLBTmUE4yLcVjmEH4pAJbK0MUzoxYLcignGBfjsMwh/FIALJWhi2dGLRbkUE4w LsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BLAbBUhi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEg h3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyWOYRfCoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZ UYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcYF+OwzCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgq QxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQQznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIv BcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY 5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyVoYtnRi0W5FBOMC7GYZlD+KUAWCpDF8+MWizIoZxg XIzDMofwSwGwVIYunhm1WJBDOcG4GIdlDuGXAmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJB DuUE42IcljmEXwqApTJ08cyoxYIcygnGxTgscwi/FABLZejimVGLBTmUE4yLcVjmEH4pAJbK0MUz oxYLcignGBfjsMwh/FIALJWhi2dGLRbkUE4wLsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BLAbBU hi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEgh3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyWOYRf CoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZUYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcYF+Ow zCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQQznB uBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHMqMWC HMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyVoYtn Ri0W5FBOlHEBxmGmbchCGMyUoQtqiig8TTmmAPI2Dj9hv0chQRnG4aeMhADlGMczlQMMgncm3MJ7 yDhgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbg l4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4Bf As6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4J OIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXg DMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4Az KCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6g rACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOy AlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoK YAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuA JRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACW QNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgC YbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE 7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2 W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grLgLJfP2 xDcW2B7by7z9f/dCKZEE2fSB7bE9tsf22P5/9oJfSkJ842cxj6SwPbYHrgFvnLgF+CXgDMoKYAmE 7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2 W4BfAs6grACWQNhuAX4pHYsXL54zZ05ERASdEvny5atZs+bnn39epkwZd/fLlKCsAJZA2G4BfikX M2fODAwMnDp1as+ePZMnT3769OlevXrRI4bJOVBWAEsgbLcAv5SLXLlyXb9+PTY2NkmSJErL+fPn ixYtimFyDpQVwBII2y3AL+XC29s7Ojr64MGDVatWjW+b3bt3T5o06bfffiNb/eijj0aMGNGkSROL 1d+V7dy5c8iQIRERETExMepeS5Ys6dixY1RUVMaMGZUWGvp3OpQZpYKyAlgCYbsF+KVcNGvWbMOG DbRQuHDhunXr+vv7V65cOVu2bOoGu3btql+//tixYwcNGkRjN23atAkTJmzduvXTTz+1/HsWtWnT Zv78+WfOnKlevfqRI0cqVaqUOXPmmzdvenl50dqLFy/WrFmTZrF79+59p0OZUSooK4AlELZbgF/K xePHjwcOHLhy5crXr18rLXRi1KpVa8GCBblz56anZJ9kgS9evEiRIgU9ff78uY+PT7Vq1Q4cOGD5 9yyi6WChQoXUYxYtWvT8+fM//fRT06ZN6SnNF5MlS/b11187cSjTgbICWAJhuwX4pYw8e/bs2Ft2 7979888/UwtZ5p49e2ghZcqUL1++tNmefO7p06eWf8+iN2/eJE2aVF0bHBxMM8gGDRps2bIlOjra z8/v6NGj+fLlc+JQpgNlBbAEwnYL8EvZmTt3bp8+fWgKSBNBy79+SbPP999/335jzbMoKioqe/bs sbGx169fpwnl/Pnz9+3b59yhTAePKACwAcJ2C/BLuaDT4OTJk9a/tlTeJs2aNevt27fpqb+/P807 f/vtt48//ljZ4OzZsy1atLh8+bIl/rOoVatWP/zww+TJkw8cONCxY8e2bds6fShzwSMKAGyAsN0C /FIu6DTImTPnjBkzatas6evre+/eveDg4OnTp0+ZMmXYsGG0wdatWxs1alS5cuVFixblyZPn3Llz 5H8932KJ/yzatWtXvXr1smTJEhMTc/PmzeTJkzt9KHPBIwoAbICw3QL8Ui5OnTq1atUqmgVeunTp xYsXadOm/eijj7p27dquXTt1m+3bt5N90rwwOjr6ww8//PItFqsfgVjsTqS4uLi8efNGRkb27ds3 NDTUyKHMBcoKYAmE7Rbgl4AzKCvAOawvGcG7wvWMg18CMaC+vCs49aQFYjYOS3nDL4EAUF+cA2ef nOBtCSMwzh78EgiA8RmSSCBjMoPRMQLj7MEvgQAYnyGJBDImMxgdIzDOHvwSCIDxGZJIIGMyg9Ex AuPswS+BABifIYkEMiYzGB0jMM4e/BIIgPEZkkggYzLj+tHRfEW1MUOGDA8fPrx7927mzJmtN6CW rFmzpk+fPioq6uzZs5MnTz548CBtmSVLllq1anXr1q1SpUouC8G+265/6cQGfgkEIPYMKV68+Llz 5zZt2tSoUSOlZfPmzY0bN6Z2Kgr09Pr162PHjt25c6dyO8+6detOmDDBz8+PVt25c6d379579+59 /vx52rRpc+XKdfr0aSG9EgvjmsIA2fySbO/o0aP2t8WllurVq9Pab775hs6CV69e2RzWLQJjrG34 JRCA2DNkypQpX331VZs2bb7//nulhZbXrFmj/ClgZGRkuXLlkiRJQi3ly5c/fvx4q1ataJuTJ0+S ZdavX3/Hjh0bN26sV68emS5dca9fv15Ir8TCuKYwQDa/7Ny585IlS7799tvu3btbb0AtPXv2pLUk 9RMnTpD4g4KCChUq9Pjx459//nnOnDm7d+92WQj23Xb9Syc28EsgALFnCE0fc+fOnSJFinv37vn4 +Dx79ixz5swvX77866+/cubM2bFjx2XLli1fvvzzzz9XtqflDh06UDvVlOTJk79+/frWrVvWN9lW e6iQMmXKtm3bzp07V7kxy8yZMwMDA8mAM2XKRDPa6dOnp0mThtoXL148e/bsiIiIDBky0HS2W7du FGBISMi8efOoh1myZPnyyy+HDh3q3G9PGdcUBsjml1OnTh0+fPjAgQNnzJhhvQG1kCBp7ejRo6Oj ox8+fJguXTqX9Tk+GGsbfgkEIPwMqVKlCl0gr1ixon379vT4xRdfUMuhQ4doVdasWe/evXv//v2M GTMqG9MyGSoZJNmksjZ9+vQNGzasVKlSgwYNFONUekj1ZdKkSaNGjQoODqbHiRMnUiNVIpqhFilS ZNWqVV26dFF8l5yyX79+dJCFCxcmTZp0woQJoaGh06ZNI4MkbybLpAv58ePHk7kOGjTIiQAZ1xQG yOaXGzZsaNasmXIL2/79+5MUSZyzZs369NNPt2/fTmv79u1748aNkSNH0lr1vHAXjLUNvwQCEH6G hIWF9erVq379+tu2bVPeYqWWHj160KpkyZK9eYt6I2taTvYWusTetGlT9+7daWKqrKJG2rFz585K D2/fvq3cGS179ux+fn40TbR+0djYWC8vL5pNPnjwIG/evNeuXbty5Uq+fPnUDfLkyUNz3MuXL3/4 4YePHj364IMPqOXq1atOBMi4pjBANr+MiIig6zmSIgmybNmy586dK1as2MmTJ6mF5EdrDx8+rLxV S7sUKFCgfPnyLVu2pKs9t/zxFmNtwy+BAISfIQ8fPiRjowOGh4eXLFmSjk+zRuW9pvjml+otQsk+ jx07dvDgwaVLl/7555+ZMmUi+1R6SI6YJEkSxReJmJgYKjR0VU6v8uzZM6X/tGVcXJy9K1v+tWrr fipHcyJA/IOg/Mjjl3QhmDJlSsvbe7+T7OlScv78+SR7urYjBb548YKUuWfPnpCQkP379798+VLZ vWrVqhs3bvT19XVZFA5i4QH8EgggMc6QRo0abdmypUSJEmfOnKFlmjgq7R06dFi+fLnyVq3Sorxh q7yPan2Emzdv0iQyefLkVEGs55d37tzJli2bMr+kBXq6efPmevXqkRcqVYkC0ZxfKo32X+t3Avil /Mjjl/SYP39+UuO8efP69u0bGRmZK1euWbNm9enTh9ovXbqk7kKXgMp0Mzg4mKaeXbt2XbBggcui sO82M+CXQACJcYasXr36s88+U5dbt26tLP/1119ly5al2eHatWvLly//yy+/0CqaEZ48eTJnzpzV qlXr3bt39erVP/jgA3LBli1bKl5r/fnl6NGjZ8yYMWLEiMmTJ5Pz0XX6oUOHaBY7ZsyYmTNnKoFY f35JF++0Je1CFWrAgAFk2LQZzTt//vlnWti5c6cT0TGuKQxw/eh4e3vTJJJkrF5I0avT3JHalV+J kBS3bt1apkwZ2uDEiRN0CtAGv/32G7WTzu0PSGZJl3rKhwsui0KBsbbhl0AAiXGGvHjxgszs2bNn Pj4+ZGkpUqRQV5Fljh07dteuXVFRUVQRaGo4fvx4uuK2vC0rf/zxB00BqfrQqvr160+fPp0WrOdz dChyYrpUp2K0Z88e8sULFy5Yd15ZXrRokfL92IwZM44bN44u1anxu+++mzt3Lm1P09ZKlSqRfdat W9eJ6BjXFAa4fnSyZ89++/Zt8jbSqtJi/S02ejpo0CCaMtLC4MGDp02bRo/Kd2WpnRRuf0DlnVvl Q32XRaHAWNvwSyAA+c8Q2XooW3+ANa4fnYCAgHXr1jVt2pRcMGfOnJGRkQMHDty0aVOLFi2o3fL2 Qk35vhvNJpU5ZePGjZX2bt26lS9fvnPnzjVq1FCuGs+cOTN8+PD9+/cXK1bs999/d1kUCoy1Db8E ApD/DJGth7L1B1jj+tE5d+5cxYoVnz17Zt3o4+Nz5MiRjz76yPLvX/kkSZLk4cOHvr6+jx49Sp8+ fVxcnPKnP5ofhydNmlTxYBfF8C+MtQ2/BAKQ/wyRrYey9QdY45bRuXjx4vjx4/ft26d8ylCzZs2x Y8cWLFhQWav8VWzJkiXV/3csVapUeHi48u2z48ePL1u27MCBA9euXYuNjc2UKZO/v39gYCB5sCtD UGCsbfglEADjMySRQMZkBqNjBMbZg18CATA+QxIJZExmMDpGYJw9+CUQAOMzJJFwfcZat269Zs0a m8ZWrVrVrl27e/fuW7ZsGT58+OXLl/Pnzz916tQGDRooG9y6dWvAgAF79ux5+fJluXLlhg4d2rBh Q9d0uECBAvRo/eNC9VM6Hx+fSpUqhYaG0jbUKDyN0LMRGGcPfgkEwPgMSSRcn7Fs2bIdPXo0d+7c astff/3l7+9/9erV8PDwZs2arVy5kkzoyJEj7du3/+mnn8qXL295+0e+1BgYGOjr6/vLL78EBQVt 3brVBb2lrnbp0sXy9l/v1Q/hVGuMiooKCQnZuXPnr7/+Cr+UDcbZg18CATA+QxIJ12dswoQJ//zz D9mM2kITx3Tp0o0ZM6Zp06ZNmjTp1KmT0k4WtXnzZrJMWn7//fcfP35s/eNXpfM0B50xY8azZ89o 2jp//nxvb2/L29/I0zH3798fExNTo0aNZcuWZcqUiZaHDRu2YsWKN2/ejBo1atCgQbGxsbSwaNEi 2r1x48YLFixInTq1TW979OiRJ08eyk9kZGRYWJj6umrGXr16lSZNmujoaPilbDDOHvwSCAD/7uYc rjz7aE5WrFixixcvpk2blp4+evSoYMGCf/zxR4YMGTJmzEgL5G3Klvfu3StevPj9+/dpmeZ2NNHs 169f3rx51UPRcDdo0IBslZbJZemwZJ+0XLRo0dmzZ9MuZGNjx46lV/zPf/4zcuRImgWSO/r4+Iwf P54Me+LEiYcPH6bdqSd0ZDLjefPmWXf19evX2bNnp1kvLZcsWfLWrVuKH1vPL2fOnLljxw7MLyWE cfbgl0AMsMx3xfWnXu/evWnSNmTIEFoOCgr666+/FKPy8vIii7K+3wt5GM0LLW//cZcmoNu3b3/6 9Oknn3xCc0o/Pz8aa+UmLbQBLdSsWfPGjRs2r/XixYvcuXOT6dL2e/fuVT6MVKD2nTt3Kr+UIG8u UaLE3bt3rfddu3btwoULd+3aRct16tTp3r17QECAxUpjqVKl8vf3Dw0NLVSoUOL5JTACS2eBXwLm ML7afVeuXLlSu3ZteqRskNuRjSme52B+qUJTOppEHjly5OjRo5RS9c4t1uZKq4YNG3b69Onnz59b /r3TC5nxq1ev6FE9VLJkyZThoEflH1Pp0fq1aPLatm3bdu3a0TLNUFevXr1lyxbL/74fq5IYfmmB ZRqD6+kGvwTMgV9a07x58xYtWlA21r9FaWzSpEnTpk2tP7/ctGnThg0bbPalKaOvr6/ykaE6vyT3 rV69+s2bN2k5R44cNAGlaWiaNGloPpo2bVp6Ifv5Zc6cOY8dO5Y9e3bNHpJb03Gs75tGXkvHz5w5 syv9UnKgarfgiVIDHgUqizU0BezTpw9lY+7cuf7+/mojmejKlSsrV65MM0ia25GVKt9Kbdiw4ZAh Q8qXL//s2bOZM2fu2rXrxIkTlNJGjRotWrSINujcuXPhwoWDgoJoOX369OS15Je3bt0aMWLEmjVr 6IVGjRp18uRJ688vv/76a3qV0NDQXLlyRURETJ48mWaQag+Dg4PPnj27dOlStaVLly7FihULDAyE X6pA1W7BE6UGPApUFhsUmySPtG6kCeVXX32l/P5yypQpZIdK+9atW6dOnUoe6e3tXbVqVbLMfPny WX8/NiAgICwsLHny5LQxTUkHDRoUGRlJc8fBgwf369eP0h4TE0OOu2LFCloePXo02V5cXBzt/u23 396+fbtgwYJkqOrN2ogSJUrMmjWL5qxqy8GDB/v37x8eHg6/VIGq3YInSg14FKgswvFMi5IKqNot QPeAOagswoFfuh2o2i1A94A5qCzCgV+6HajaLUD3gDmoLIAfULVbgF8C5qCyAH5A1W4BfgmYg8oC +AFVuwX4JdAG/28iLThnnQaqlhZTqBp+CTRAWZEcnLZOAFVLjvyqhl8CDfBuj7RgaJwGqZMWswwN /BJoYBb5eiAYGqdB6qTFLEMDvwQamEW+HgiGxmmQOmkxy9DAL4EGZpGvB4KhcRqkTlrMMjTwS6CB WeTrgWBonAapkxazDA38EmhgFvl6IBgap0HqpMUsQwO/BBqYRb4eCIbGaZA6aTHL0MAvgQZmka8H gqFxGqROWswyNPBLoIFZ5OuBYGicBqmTFrMMDfwSaGAW+XogGBqnQeqkxSxDA78EGphFvh4IhsZp 3J46mz/kwyCquH1oEgj8EmigK1+z6JsfyLzTuCZ1kZGRU6dO3bVr182bN5MnT16hQoX+/fvXr1/f 4iq/NKNCzNJn+CXQwDm/tC4HyZIly5YtW7Vq1YYNG1akSBGl8enTp+PGjVu3bt3du3ezZMkSEBBA T318fGx2T5kyZfbs2atWrUqFpnjx4uoxz549O3ny5IMHDz58+JB2r1WrVrdu3SpVqpTAoAzunkAS +8w3S2WREBekbv/+/U2aNCGd27RrninwSxWz9Bl+CTRwTr6a939IkSLF3r17K1asGBcXV7169cOH D1uvJVOkEpMkSRLN3b28vBYsWNCxY0daph3r1q376tUrm20S2EmDuycc+KW0JHbqHjx4ULhwYboa a9269VdffVWoUKEXL14cOXJkzpw5O3bscFlPzKgQs/QZfgk0MOKXyl7R0dF//PHHkCFDyCyrVKly 6NChNWvWtGnTJmvWrD/88EOZMmVOnjzZsmXLe/fuUXurVq2sd3/58uXly5cXLlxIhYbmqTQvLFiw YPny5U+cOFG/fv2goCCqRI8fP/75559pg927dyekbwZ3dy4JiYFZKouEJHbqJkyYMHbs2IYNG27e vNmJniSkcfXq1cuWLTtz5kxUVBRdZebMmbNatWqdOnXy9/d3cLcydffXr1/PmDFj5cqVf/75Z8qU KevUqfPNN9/kzZvX/uXGjRs3e/ZseomRI0cOGDAgwTlwErOoGn4JNIhPvo4/gLHfi+wwS5YsNMWk C+2AgIB169Z9++233bt3V9bOnz+/d+/e5JrkoJq701rapn///jNnzvT29iYPpov3dOnSORGR7u5l y5b99ddfly9f/vnnnystGzZsaNasWYkSJcLDwy0OS5V9Zuyz5LhUKbtTHnr06JEvX75t27aFhoYG BwfnyZPn999/tz6aWSqLhCR26ipUqHD8+PE9e/bUqlXLiZ7oNg4dOnTatGmaB6QNdBUYExNTt27d AwcOWK/KnDnzqVOnsmXLZv1y5JR9+/a12T1RMYuq4ZdAA1F+SdaSMWPGDz744O+///7www/JKi5d upQ/f35l7cWLF2mqR+00m9TcnWaENC8sWbLk6dOnyZ9u3LhBV7tkn3TMd41Id/fFixd36dKFSt6x Y8eUlqZNm27cuDEkJISurx2XKvvM2GygW6qU3SlR//zzDy3Url2byq718VXMUlkkJLFTR8P36NEj kjotONET3cbUqVM/e/Zs8uTJ7du3J9nExsZev36dRLVkyZKjR486Pg4xffr0IUOGlC5dOiwsjM6p 27dvBwYGrl+/vmfPnnRVar1v0aJFR4wYoXwQO3HixLlz5zqTjnfBLKqGXwINjHzfR2mkk5mscfjw 4Zs2berWrdt3332XKlWqF2+h6aayPS2negtVAc1jPnnyJO1bqAwtWLBAmZjSZgUKFCAfpYlpw4YN HRiVNbq7v3z5Mnv27GRX5GGlSpUip6eSRJ25detWpkyZEliq4suMbqlS9tq6dSs9NmjQgB43b96c LFmyTz75BH4pisROnZeXFwnjzZs3SZMmdaInuo158+a9du1a5cqV/fz8cuTIkTVr1uLFi9eoUcPm 5eILk4R35swZ6wvW+/fv00Vb7ty56bDW+4aGhlrPL12AWVQNvwQaGP9+rAJV/M8++2zevHlkinRW x8XFUUFRvt1D0FNqpKfUqHlMaqcaRNtQDaKnNOWi2d7+/fvJ25QNqlatSlNAX1/fhASluzt52MyZ M7t27UrmOmvWLJpWNmrUiPzekuBSFV9mdEuVshddztOC8oVhdRl+KQqzzy+PHDnSsWPHK1euWG9A c8Ht27eTLB0fx/L2a+eq8q2hUywmJsZ635s3b9K1o+MQxGIWVcMvgQai/JIMZunSpfny5aNlg/NL tZHO7YiIiMOHDwcHB1+9elWxt4SH5mB38rNChQpR92hOWbNmzdOnT//444/Nmze3JLhUxZcZ3VKl 7kUo1xPqsm6SExVO9SGxi7LynTKBn1++fv06efLk1o20QBdeZ8+epcus8PDwXbt20Ulk8w2jd/VL 642Vfa0val2DWVQNvwQaGPHLuLfQ/InmakFBQWSWdHrTuWr/+SUtFyxY0MHnl8ePH69QoYL6jRsb yO3o4BkyZHjw4IETMWruXrt27b1793bu3Hnx4sXp0qW7c+fO+++/r6xKSKmKLzO6pcp6L5tl9/ql hZFlJrZfjhkzZuLEiY0bN964caPjLZVvnz19+lT98TGRJk0aarlx40aOHDmUFpIiCdJBnxUNk7qe P3+uNipv5Ni/LVyqVKnz589HRUWlTp06vo65a55nFlXDL4EGxj+/VGjQoMG2bduojowfP75ly5Y0 XaPJHE3plLVhYWG9evVy8P1YWkvb9O3bNzQ01L4PypeJkiVLRqXHiRg1d1+/fn2LFi2U5d69ezv4 poNmqbLEU610S9W7+qVrTluzvEuWQBI7nLt37xYuXPjRo0dt27YdNmxYoUKF6CLpl19+mTVrFp0F 1lsWL1783Llz1E7aVq2iUqVKR48ebdWqFV1o0mXcsWPHevToceHCBbXPpUuXpiPXrFmzQIECNO+8 efMm6XPatGk2b8BkzZqVevLtt99+8cUXyvRUISQkZODAgdWqVaOTkQ5Fq8ib9+3bt3DhQvU7bu71 S/lVDb8EGojyS+ULrunTp6dz+6effqKzPVu2bNa/v6QT2/73l69evVJ+fzl79mwvLy+a1VEZouPQ tK9GjRq5cuWizahx+PDh+/fvL1asmM0vLjRJ4O7kc7lz57516xYtHzx4sGrVqkp7AkuVJZ5qpVuq 4JcuwAXh7Ny5s3nz5i9evLBpt3lRcsTAwECbtcuWLVP+mkNl1KhRkyZNsvyvMOwZN27c2LFj1afK Vab9q5O2mzRpYuPcNt2DX+rsy+ZkAAJJ4O9JVOwLvUq5cuXIGpcsWUL+QfZz5MgR67WO/9+Hpmhk PF26dInvpWmDdevWNW3aNIERJWR3sjQqQGR7ZIrqpzgJLFWWeKqVbqmCX7oA14Tz559/BgUF7d69 m666lP+PHTBggPL/sSpxcXGknO++++7evXvWXSIfDQ0NVd6S/fLLLwcNGqR+mE2Pp06dWrVq1d69 ey9duhQdHU1z0I8//rhr167NmjWzPvizZ89GjBixcePG27dvK1+UU48fGxu7YMGCFStW0OyW5r5+ fn50Caj8jMqVKbLHLKqGXwINBPrl8uXLO3ToULZsWZprPnnyhMoEzS+pTGTOnJmmlfRUfYtSPXiK FCloGkpW2q9fv5IlSyqNx48fpwvwAwcOXLt2jU77TJky+fv700V6xYoVExJRwnf/6quvpkyZQtVq zpw5amMCS5Ul/mrluFTBL10As3A4YRZVwy+BBh5bWejCP2/evJGRkeSs1apVc3d3NDBLZZEQZuFw wiyqhl8CDTyzslC88+bN69OnT/bs2a9fv+7ir9QnELNUFglhFg4nzKJq+CXQwDMri/qG8KRJk0aO HOnezsSHWSqLhDALhxNmUTX8EmjgmZWFok6RIsVnn302f/589WeXsmGWyiIhzMLhhFlUDb8EGqCy SItZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJi lsoiIczC4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWy SAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLC LBxOmEXV8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhQsJ58+ZNu3bt1qxZY3Nkpw9rs28C D2XkFY3vbs/XX389YsQII/2xmEHV8EuggUD5atYXm9cSK0LlgO96WHX7ROqPwKNZzFBZJERIOKtW rbp169aQIUNsjmwuvxROxowZHzx44PTuZlG1XEkHkiBQvpr1xea14nsh54qC4710jym8YMEvJUFI OI0aNRozZkzZsmVtjuzhfml8vmsxg6rlSjqQBIHy1awvNq8Fv0w4ZqksEiIknMyZM1+6dClt2rQ2 R1YO+9tvv3Xu3Pn8+fNFihRZunRpqVKl1NfNnj37/Pnz6XSg5ePHj3/++ed0Hdm3b9+pU6fa+OWw YcNmz55N269YsaJ8+fLWnVcPYi0q+1UTJkyYMWOGl5dXcHDwF198QWtPnz7dpUuXs2fPxsbGWr/7 ornxsWPHaOH27dv23XMQIPwSeCgC5atZX+KrF9ZnfuPGjdXt1XPb8r91x8EB1Yowfvz4OXPmREVF 2XRM2Ya2DwsLi46Otq4g9gXLvjxZHyciIoKK0a+//ponT57FixdXqlTJQUE0iFkqi4QICSdZsmSv Xr1KmjSpzZGVw3700UfdunUjRyEZLFy48MyZM8oGcXFxhw8f7tSp09WrV5XNevbs2bFjx0WLFvXr 18/GL+fOnausWrBgATmcusr6IDYXYTarSL0kyIMHD5Lt3b9/nzYoUaIE9Ype1Nvb27rDmhsXL178 yy+/pKfkiLRg/ULxBYj5JfBcBMpXs744qBcOioLFru44OKC6b6pUqWbNmtWuXbsUKVJY7Jxv2bJl tIq6Z11B7AuWzV42n4+WK1eOykqbNm327dsXGBh44cIFBwEaxCyVRUJcML8ktT958oSU9vz5c19f 35iYGNIezd7oyomkS5vRo/VmL168IH3a+CU1KqvoVegI1Gh/EPUVNVfRJDJJkiQ2HXv8+HHKlClt Oqy5Mc01nz59qtk9+wBtDugcZlE1/BJokNjzS8164aAoaK51fEB131WrVtEVNE0BybcmTJhg43x0 wlN1sPxvBbEvWOpael0yVxu/pFd/8+aNekzaxkFBNIhZKouEuODzS3VmRtdJyvSLNLBp06bKlSvv 2bOncePG6jS0d+/eHTp0WLJkic0Ejg41f/58ZVVYWJhyuWZ/EPUVHayy7ljJkiXpKlNzfmm/sRKF ZvfsA7TZ1znMomr4JdAgsT+/1KwX9mf++++/HxkZmTVrVs21jg9ocwKHh4dXrFjx5cuX1sfULBaa BStjxowrVqyoVq0alYm+ffva9I2i69OnT0BAgHr97qAgGsQslUVChISzcuXKO3fuDB482ObIymFP nDjRpUuXCxcuFC5cmIa+dOnSY8eOpUs9WhUYGDhu3Dhls3f9/NL+IOorOlhl3bFTp06RX/7+++// 9xbHfql+ftm1a1c6BV6/fq12zz5Am32dwyyqhl8CDQTKV7O+aNYL+zOf1pI/kcnRsmbdcXBA64pA jxkyZKD55ejRo62PGZ9f2hesZcuWDRo0iCaRQ4YMGTVqlE3fLl++3KtXryNHjrx69UrJGz6/lBAh 4cTExLRv397B76PYEB0dTWfB2rVrScyJ/VpmUTX8EmggUL6eU19cg1kqi4QwCydRee8t+fPnX758 ufod3UR9OYsZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWy SAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4S4IBwHP6sw+IsLITjdh9atW69c uVL5pXJiYBZVu38IgYQwK5QGSexi8U6YpbJIiHvDcZdfCnndoKCgHDlytG3bVkiX7DGLquGXQAPJ C6WLS09iF4t3wiyVRULgl05z4sSJiRMnbt68WUiX7DGLquGXQAPJC6WLS09iF4t3wiyVRUJc+X6s /X08NP8HQ8X+L/t79epVs2bNgICAtWvX7t+/v1+/fjYbWOK/64jak/es7g1gvYFm9+xvVKLy6NGj QoUK3b17N/HyZjGDquGXQAPZCqWDe4xonvnqXUcs/8ZifVcT+9sV2Vcr61dJ7GLxTpilskiIK/3S /j4e78V/4xGL1l/2x8TENGjQoEmTJhs3bty6dStp0mYDS/x3HbFe1mzU7J79jUpU3rx5kyJFCvXf 1RMjbxYzqBp+CTSQrVA6uMeI5pmv3nVE2cbmrib2tyuyr1bWr57YxeKdMEtlkRBX+qX9fTze0/of fxX7v+ynhb1799auXfvIkSP+/v6aG8R31xH1rgCWePxSs3v2NypRwfzyv/uyORmAQGQrlA7uMaJ5 5qt3HdG8q4n97Yo0i5EK5pcueC0X4Eq/tL+Px3ta/+OvYv+X/aTnevXqjR49esqUKdu3b69SpYrN Bha7u47Y3xWAGjVvMKDZPXtbVTl58iSdd/j8En4JNJCzUGreY8Txma95VxP72xXZVytrErtYvBNm qSwS4kq/tL+Ph+PPL+3/sp92b9OmTZ06dbZt2/bTTz8NHTrUZgOL3V1H7O8KQNto3mBAs3sO/HLa tGnUbXw/Fn4JNJCtUL4X/z1GHJ/5mnc1sb9dkX21sn71xC4W74RZKouEJHY4V65c+fjjj588eZJI x3cj+P3lf/dlczIAgTArlJok/HZF+P2lC17LBSR2OClTpqRZIF2WJdLxGWMWVcMvgQbMCqU9773F ZbcrEohZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQao LNJilsoiIczC4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0 mKWySAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWap LBLCLBxOmEXV8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouE MAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC 4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhh FlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV 8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwS aIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBqg skiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhhFlXDL4EGqCzS YpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV8EugASqLtJil skgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwSaIDKIi1mqSwS wiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBqgskiLWSqLhDAL hxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhhFlXDL4EGqCzSYpbKIiHMwuGE WVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV8EugASqLtJilskgIs3A4YRZV wy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBL oAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBookgLSIn9lkRCoWnLkVzX8EmiD 4iItLjtnmfmlBaqWGFOoGn4J3Ay/oswGDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiFPkCaUGJcAKoWnLgl8CsoLhIC+qD00DV0uK0quGXAAAAgD7wSwAAAECf/weaRxVqCmVu ZHN0cmVhbQplbmRvYmoKNDggMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNTQgMCBvYmoKPDwv UjUzCjUzIDAgUi9SNTIKNTIgMCBSPj4KZW5kb2JqCjUzIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UK L0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCA1ODcKL0hlaWdodCAyNjIKL0JpdHNQZXJDb21w b25lbnQgOAovRmlsdGVyL0RDVERlY29kZS9MZW5ndGggMjAwNjg+PnN0cmVhbQr/2P/uAA5BZG9i ZQBkAAAAAAH/2wBDAA4KCw0LCQ4NDA0QDw4RFiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIy SGJJTlZYXV5dOEVmbWVabFNbXVn/2wBDAQ8QEBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVn/wAARCAEGAksDASIAAhEBAxEB/8QAHwAA AQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIh MUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpT VFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAA AAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEI FEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm Z2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0GSITQ7JBwRzg1G5EShQO AKmY4H1qpcSAMODQBBdhZFBYZ2nPNQyhJBu7LRdNwCmST2qhcSsBsAI+lAE4PnIwTAx0rMugsIDT kHecCrassKqCfmajyVnyJMEKcjIzQBl39pHc2pSIupyDuHWsyJ54G3NE5jX2rrLGBlaTOOT1pdUl W3sX2Rq7gcAY5oAxbbVEkVvKDFF65HSsPW7v7SoW3Uhz6+ldHZ6b9utVn8t7ZnHK96wtZ0uS0QgS lm6DjNAHNi3unw+8nb1GamaYwRbdp5/vd6sQ2lwEIUkt1NOltS6AyHnuKAIYplKAtjNQXUyOQo69 frUN1aNG3yEiq7GdVG4HHQUAWdyhSZSABVW4VAEZOjLn9SP6VMfLdAHR2PfDY/pR5QCgOrMuPkAb BAyeDxVpItJW3K0ZzxjJp/TBxxSHbuzGrKB6nP8ASnZwc9frUEMccFcHO6rFmWQnnA9TVTc3UDIF S7sx529qANWS8UZAbD9sd6jF28uFjLAnqccVlI8gcCNS5B6EZrr7a1DWSt5ABxk4oApWcMSDGCzN 1yK6Gzi8oAnaq44FZSr5KAk4WtZbmGRI1IJHY+9AGjDNbqwVsbjzxVhVhkJI5z2rFXzRKCq8dMmt 2yiQKTxvPJoAbDFJFJwgZT39K0bdChBIIJoSMqwORzVryz65oAdGuGDVP2qGMHJDc1N7UALjPag5 ozzRnnigBCOMVBa2726vvlMm5iee3tVjpRQA1ZVYgKRk807P51G0YDK6qNw4p+0FgT1FAC4xUc0K zIEkGQDmpM880pP5UAMMYxjpj0peaXmigA5o70Zo60AFGcZJPFFIQCCvrQA1JUkzsYHHHFPFUdP0 yKwkmeNmYytuO45q9zQAYGfemz/8ekv+438qUEnrST/8esv+438qAK0P3D9akqOH7h+tVNT1JLCL Aw0zD5U/qfapGLf6lFZMEODIV3YJIBH1APJpl1q0MEcZAy0kfmBWyOOwyAef85rHdFtkN1qA867l +ZIm7e7f4fh9L+n6UZmN1qIMkrnIRu31/wAP8hgafmCa3jlUEK4DDPXkVDp3/IOtf+uSfyFWZvuD 61W07/kHWv8A1yT+QoQiaUuIXMQDSBTtB6E9qrwXt5BCkSaYSFGMm4XJ9zx1PWrdRrF9quNhLiKI ZYqxXLHoMj25I/3aYDP7Svv+gZ/5ML/hR/aV9/0DP/Jhf8Kt/wBnW/8A02/7/v8A40f2db/9Nv8A v+/+NAFCe9vJ4XifTCAwxkXC5HuOOo61YiLmFDKAshUbgOgPekaL7LcbAXMUoypZi2GHUZPtyB/v VJQAUUUUAFFFFABRRRQAUUUUAFFFFABVS7+9+Kf+hVbqpd/e/FP/AEKkxokp8n3h/uj+QplPk+8P 90fyFIbLrEd6qXLL61YkcKvNZF9N5g2JnJ71RI6dVypU/MB2qvI8ahhLx3zVO3uJIpiGG8H3qtd3 /wBoZowu0g96AJIQlxM7HJUHAqwWER2D7vSq1q/l4VkwMdqJ5N0uAaALP2xLcoxOATjFLIjzXcb7 lEajJBrCu3lnlKMh8uMggg9TWik29RgnpQBpXF9HBEV3BRjHFYl032ojDHn9akmweDz9aoyq8G0o M8+vSgBbm3NvZyGEbnxxn1rIgMk8INygSQ9hWnLNOQRnjtWVqLvHb7x8rAUAQzmOP7xHHrWTdSNI DtUBR6U4iSdA7P1pBhRt9aAK8BbBB7+tWOSiDPKjH6//AF6ZIu049qbuO7IJJHancd7Egi52g0xh tJzjFIzTZ4xzSNG8oG44pCIUyZfl6E9atxQ+Znc2farNtaqiAEZz1q/BaRMQwTBXvigA0rZDL5jo oA7kVuRyyOhMQGCeMUy2tIWQZGRirlvELeM7VG3+dADHty0QDKORTrawjZwA5PqD0FWrJ1uN394H pVz7Mv3ivT0NAEkVt5A7PkVLGqueFxinROSvPQUsSAy5TJz60ATwb84H61bjdh8rCo4kwTn9KnTb kdz70ASpnOalFNWlFAGfrEl9HHGbCNXcuA27sKvx7jGpYYYjmlP50vSgBCoOD6Uv4U0PmQptIx3p 3egAPNLkUh6ZoHegBNwBAJ5p3TpTGRWYMRkjoad2xQAHnpTVUjJyTzTvWgUAHel6U3dkkd6U0AKT WDrXiK30q6gt5AxeVsDAzW72qpdada3bxvNCrshypI6UATxyB0Vh0IzUme9IqhVCgcDtS0ANZcsG JPHaif8A49Zf9w/yp2efemz/APHrL/uH+VAFRd/kP5e3fzt3dM44zWLZWsmDfXCmW6lP7hWxgnGQ ev8AhjH0rch+4frUYtVESxrI48s5jPGU4xgcc8ZHOaQzGsIgsz3t6Hlm8vzxgAhV5wfrxwO3H4b6 NvQNtZc9mGDUJtIvLdBuVXiEWAeijOMfnU+DuJycY6dhQAyb7g+tVtO/5B1r/wBck/kKszfcH1qt p3/IOtf+uSfyFCETSyCKF5GyVRSxx14qC01fToIAr3IMjfM5CNyx69unYewFWqjPmSTLDCyq2NzM ylgo/Ajkn+R9KYB/b2m/8/P/AI43+FH9vab/AM/P/jjf4VJ9kuv+fmH/AL8n/wCKo+yXX/PzD/35 P/xVAFW71fTp4CqXIEi/MhKNww6dunY+xNTxSCWFJFyFdQwz15pB5kczQzMrNjcrKpUMPxJ5B/mP WpKACiiigAooooAKKKKACiiigAooooAKqXf3vxT/ANCq3VS7+9+Kf+hUmNElPk+8P90fyFMp8n3h /uj+QpDZNPyOtZbkpIQcEdq1Zl/dnPYVizSR7zucBvTNUSR3SK8RZcBh0rAvUKTJJIuC3vXQTx7o 8o2CetY2pJ5gELEH3oAIt0sfyMcDuaryxzmUIznnuKlImWAIgwo7gVELrywOWZvVhxQAXiyIFVTj A656moVuWjAyQKrPdPcyPkgc8AGoV3SyEE8jrQBpC6aRx6D9aivJ3cbY/vHpVe4M8FvvgQSMTjFP EwDK0mFJHSgCJLoxgrM+WHYVn6jLNcxkKpVB68ZrSkREdpMZLetU7iXcpUCgDFtkcq3OeenpT2i7 kdKieYwzlV4yamZyx5NAFaRstzx70qgNk46VZaBZE4IB9acLfavWgCvtO3PWnI/zjJHoKupaMkeW HGM5pv2XhGHTNAD4GO/nB9K1LcnIB6VWSDyyOnrWrawllB70AWVjESggjBpl1cywlFUKY2OCfSrK okuI3GJF5GOlMuLdVVQ4GR0wM5oAsWUR5ljYZ9q04ZBJ8u8Me9ZFmzK+QAsRHNWdjo2+L7p/nQBs JEVUlcE0+FMyDIwKgtDK8IYnnqRVuPccAjj1oAtoFVcCk2fNuFIo44OalSgByNzjpT6aFAangUAL 1ooBDZI5oxxyaAD0FHaimBGEu7cduPu0APxQRkY7UZqOZC6gK5U56igCQDAwOBSEEsCDgDtSjPSg CgBAQTikZgoJJ4FOAApGXK4oA5uHxXZy622nqTvHGeozzXSKwYcd6xI/DdimqtfiMece559P8K2l UrxxxQA6g9DRmg84oAaMbs5p1NCBSSOpp1AC0y4/49Zf9w/yp2M02f8A49Zf9w/yoArQ/cP1qIg3 E0iF3WKMhSFOCxxnr1xgjoR3qWH7h+tV7wSwq8tuyq0m1CCONxO0N+ozwcgAUhkOH+2+V50v2bPl 7d3zb9u773XGPfr7VZANvNGgd2ikJUBjkqcZ69cYB6k9qqf2c/2j7R8m/bt2b2z16+Z1z+HTirFm JZlSW4ZWaPcgAHG4HaW/Q44GASKALE33B9arad/yDrX/AK5J/IVZm+4PrWTb6ilvaW8bBciFOrY/ hFVGLk7ITNVmCqWYgKBkk9BU1hGViMrgiSY7iCOVHYe3HUepNYzapDMjRlFYOCCA/UVl3txptmIw dPkleQkKkcvOAOTyRx059x61bpTSvYVzt6K86fWtLjiWR9JnWNvus1wgB+h31BH4j0iVA8eiai6H oygkH/x6o5WM9Cv4y0QlQEyQncAByw7j346D1AqFWDKGUgqRkEdDXK6bfaVqSSGKxdGiba6SS/MO M8gE4/xB9K2Y9QSONUSHCqAAN3QVoqM2rpCujSorP/tIf88v/Hv/AK1H9pD/AJ5f+Pf/AFqfsKnY Lo0KKz/7SH/PL/x7/wCtR/aQ/wCeX/j3/wBaj2FTsF0aFFZ/9pD/AJ5f+Pf/AFqP7SH/ADy/8e/+ tR7Cp2C6NCis/wDtIf8APL/x7/61H9pD/nl/49/9aj2FTsF0aFFZ/wDaQ/55f+Pf/Wo/tIf88v8A x7/61HsKnYLo0KqXf3vxT/0Kov7SH/PL/wAe/wDrVLbst653AqBjofTmpnSnFXaGmSU+T7w/3R/I VL5Uf+1+f/1qoWd6L+AzrGY18x4wCcn5GKZ/Hbn8axGzRkO5CCOtcnqmhy3GoRTi6ZVQ8oO/+ea6 44xjrVSSINJnHaqEczd29ykeEuSoxWZ9muhOkszll9K6ma1RpiGJIqG7tR5Yx0FAGdbSxOG+Ugr1 zSzbTF8ygZ9KpXqbQWRWCHqR0qFri5EtuLRQ8Y+/u9KAIE05bd3l5OecGmTRvCDNEu49MVr/AD3m 7YCqVGIsLsTOB1zQBnAytGuRsz1xUX2Q+YSSXPv0rXnWJIxuYKPWn2qqVIOPrQBjSxugGULA8YFR PZkruweldIvlk4UAn6VAUBYoy49DQB53cQuL0K3UtxWq9iwjBUE5HpV7XNOJ2XCcPGeg71bsLgXc QDAKQMUAYFtE8YIkBLVY2nYducetbE/lW5Pm4JxnNQmMSossPCd1PegCHl7L0+lOsNNa5tx5b5Xu TUyaa+xirOqOOlRaezW9ysMZYAfe4zmgBJT5TbGxuj6nPWt6xxJGCqgjHWqur6clykboMuetV9Ov 3s5Ps0pVABjJFAF9pWW5IORjvVyVmMW5F3P2BNQ3Ue+SNo2BU4JNXmhPyqoGO9AGbHM6ybPL4rQt VW4XKkgCpUgCxseMmktLeSOcucBT2FAFmyWRZGOeOmK0UJPBGMelMTb2GP61YQAjPTNAEZDdmIz3 qaEu5OVwB3z1piYLFRzg1T1q9u7C3jaztjOzMAQO3agDYHXjtS1Fau0kCPIuxmGSKmoAaFAzgYye adUBE/2oEFfJxyO+amPA460ALmjqc0dxVGa9li1CG3WBmRwSZB0FAF4kZo+lGcdRR7UAL1poPz4w aFYEHGRVa4uobCLfPJtUnAJoAtGlpitvUFehGQaXqRQA1YwsjMM5an9KQjKkA4PrVa+knt7J3gTz ZQPlHqaALQINBrM0YTSQfabhWSWXloyc7fatJmwtACnnFBOCKM0frQBCTL9pxgeVjr3zUk//AB6y /wC4f5U6mz/8esv+438qAK0P3D9agvDK7C3jEZEsb535xxgdvr/noZ4fuH60/aNwbA3AYB7/AOeK kZlGW5uDCILkohcAOyDfzGW5wcEYI7fy50LQq1nAUXYpjUhc5wMdM054IpE2PEjLndgqCM+v6mpK YEc33B9a5i51WXR9Dvb23SN5ooLbaJASvOAc4I7Gunm+4PrXOLaXrpFJbq4VoY+Vk25wo9/rWtKP M2r29RMknur27t/tV3GLaGSVfs9sV+eNQrfM5/vNkfL2wO+a5tryKa9aWSRRu/dwgn+HPUe7HOPU KPQ1uXWm6ncW8kWZVLKQrGXO0kYyOfesf/hFtc8ry/tq+Xjbt+zx4x6Yz0reUGociafzRKMXUre7 iNzMpBkLApcFkGxDkbPmI24z1HXNJphuy0ASdp5A585vMZ49mAcEnjeM8bfxrU/4QrUv+etv/wCA kX+NWv8AhGtf/wCgh/5Bj/xrD2UvL71/mO5Xhu44bszRzCTym8q4GR8qk5BOMfdPc9Bu71e1DUJL S4ssBDBNL5L8HcCR8uO2Mjmqx8La4Q4N6pD/AHh9nj+bjHPPPFaLaBdTWC2l1CZ12qrkyAFyMc9c 9RmuuheMXFtLtqiWZ7arcO2nRxCJGvd7h2UsFQDcoIyOcEZ565qu2v3B0myvPKSOOVis8u0usWDg HaCDgn349zitq40K4uTG0tsd0ZJRll2suRg4IINRt4cka2S3FsywopUIk20EHrnDc/jWza1tNff6 f8EDNvNXuorh4oDbSKlkbkyEHDEHsAeh+vfOTjBbf689tZwXUbRZeJJTbFGZsEjPzg4Uc4BI61em 8LTz3omeIiIQeR5SPsGM56hhx2xUtz4ZN0FEtkCFTYAsgX5cggcEcZA4qW97SX3gV47+4uNWuraM xRxW3l7tyFmfcMnByMenQ1S0/X7u5R5Xs2aIx70Mcb/Kd+3aTg7uMEkDseDWwPD0wnEy28iyYUFl nI3bem75vm/HNLb6BPakmC3dAc/IJvkGTk4XOB+Aqrq/xrr1AyNKupLjVNUhmnnkUrHt3K8YXKnO B/D1478ZyetNsmnmbUbmzmmMao0Nqrys4dgOX+YkHnABzjGa3I9EuIriadLbEs2N7eYOcDA702DQ ri3tRbQ2xSIAgAS8jPXnOe9CUNLyXXqBztjNdSXD2cc1ykkmnZbz2cFZs43AtyOvbj8qv2kpj1GS zdZYpzB5iut08ygZx0fgHOOxrSh0CaFZQtru87/WF5A5fjGCSSSMdqI9Anj3Fbdy7KVMjTbnx6Bi cgfQ0oqKt7y+8DIn86H+0ZLa4l+yJaMvzSsxEwzypJJ4HBwevuDjpPCCudHjZJWM0kQffKzSfMU6 4J6Z7Aj8Kz4/DkscTRLBKYmQxlGuCw29MAFuPwrZ0G0XSLaRJcwxIC/7yXcFUL6knAGKwr8vLo19 40TfZNZ/6C9t/wCAB/8AjlQaEqJpgVJTKBNNlzHsyfNbOBk4Gc456Vi2tv4RtdbfUo9QtezRwbxs jfuwH5YHbn2xr+G3WTR1dGDI085DA5BHmvzXAWbrMAm6qjO7tuBwDUznAAJzVZkmW5Lbx5JA+XHS qEPAHmncOveop48njgZq55QcA/limSxBhtZiAPSgDLv7WOaDYgwfWsX+z50jQI20HhjjtXT+WuTk 4FZUpWS4njYkxRsFK5wGbAJz6jBHH1yOlTOSgrsqMXJ2RZhijgtkSIq2Bg1m6haLKrFSY2AySDTm +wIxVobNSOxjT/Ck3ad/zzsv++ErD6wuxt7DzMJ5lEJiOXbPfvWha28zWwKJgnj6CtLybX/n1t/+ /S/4UeTa/wDPrb/9+l/wpfWl2H9XfcNNsTFHmRsk1cFskjH5RVPybX/n1t/+/S/4UeTa/wDPrb/9 +l/wo+tLsH1d9yo9kwDyXA2gNwD6ViLZSpcySRL+7PIHrXTeTa/8+tv/AN+l/wAKPJtf+fW3/wC/ S/4UfWl2D6u+5z5trm+RVKBUB9Ke1q8MYxHyDgHORW75Nr/z62//AH6X/CjybX/n1t/+/S/4UfWl 2D6u+5nRTSXMQjVdr4wDjio7XS5opnaUASN0PrWr5Nr/AM+tv/36X/CjybX/AJ9bf/v0v+FH1pdg +rvuRpBdPIHePCrwR61FrOlR30KyIu2QDH4VZ8m1/wCfW3/79L/hR5Nr/wA+tv8A9+l/wo+tLsH1 d9ylHbFLSGGFNr5HL9Petrym8sdAQKpeTa/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWl2D6u+5PCr MduOAa0Ng2ggc+1ZHk2v/Prb/wDfpf8ACjybX/n1t/8Av0v+FH1pdg+rvubbggKR1FTqf3eRxXO+ Ta/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWl2D6u+50kQ/ixVjaGAyK5PybX/AJ9bf/v0v+FHk2v/ AD62/wD36X/Cj60uwfV33Oux2proWZSHK7TyPWuT8m1/59bf/v0v+FHk2v8Az62//fpf8KPrS7B9 Xfc6+j0rkPJtf+fW3/79L/hR5Nr/AM+tv/36X/Cj60uwfV33Ow6UmBmuQ8m1/wCfW3/79L/hR5Nr /wA+tv8A9+l/wo+tLsH1d9zryenNFch5Nr/z62//AH6X/CjybX/n1t/+/S/4UfWl2D6u+513BPWq uomAoiXERkVmAAxnmueNlEqbzYRBP7xgGP5UzybX/n1t/wDv0v8AhR9ZS6C+rvudag2qAAAoHFOz iuQ8m1/59bf/AL9L/hR5Nr/z62//AH6X/Cj60uw/q77nURSu8sivGUCnAPrUwGeM1yPk2v8Az62/ /fpf8KPJtf8An1t/+/S/4UfWl2D6u+51wwDgUp6VyHk2v/Prb/8Afpf8KPJtf+fW3/79L/hR9aXY Pq77nUWqzqjCdg5JJBAxxU461yHk2v8Az62//fpf8KPJtf8An1t/+/S/4UfWl2D6u+512Rk46imS Z+xS7jk7W/rXKeTa/wDPrb/9+l/wo8m1/wCfW3/79L/hR9aXYPq77nSQ/cP1rM1OS9sV89pf3Lyb VVWXIB57p6BvXqOuOc7ybX/n1t/+/S/4UeTa/wDPrb/9+l/wpfWV2D6u+5siz1bjNxGemcMPbP8A yz/3vzHpzVifUZNRksvPHmxKGY7lCkfL0+T3P5j05oeTa/8APrb/APfpf8KPJtf+fW3/AO/S/wCF P6zHsH1d9zpJvuD61WVAihVyqgYADEACsTybX/n1t/8Av0v+FHk2v/Prb/8Afpf8KX1ldg+rvubm P9pv++jRj/ab/vo1h+Ta/wDPrb/9+l/wo8m1/wCfW3/79L/hR9ZXYPq77m5j/ab/AL6NGP8Aab/v o1h+Ta/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWV2D6u+5uY/2m/76NGP9pv++jWH5Nr/AM+tv/36 X/CjybX/AJ9bf/v0v+FH1ldg+rvubTSRqcNLg+hf/wCvSebF/wA9h/38/wDr1jeTa/8APrb/APfp f8KPJtf+fW3/AO/S/wCFH1ldg+rvubPmxf8APYf9/P8A69Hmxf8APYf9/P8A69Y3k2v/AD62/wD3 6X/CjybX/n1t/wDv0v8AhR9ZXYPq77mz5sX/AD2H/fz/AOvR5sX/AD2H/fz/AOvWN5Nr/wA+tv8A 9+l/wo8m1/59bf8A79L/AIUfWV2D6u+5srJGzBVlyScAB+v61N5Mn92X8zWB5Nr/AM+tv/36X/Cm PDblo0S2tQXJG4wqQMAnp36U1iU+gOg+50Xkyf3ZfzNIYnAyRIB6kmuea2t1IDfYgScDNovP/j1H 2a337P8AQt2M4+yLn/0Kn7dE+wZv4/2m/wC+jSgYOeSfc5rn/KWCVRH5SMykrJBH5RBGODgnI5HB 446VsWFybuzjlYAMcq2Om5SQce2QcVcKinoROm4liiiitCC4FVhTXj42nGKmxxUSmRy4ZAAOhz1q hEUMTq5x92neWzNlqV51QqhOGbpinjIBOc0AVbiEtGc9RXMyuy3l5kc+cP8A0XHXVSM7HCg4Ncpd vHHqN6ruqt5wOCf+mcdYYj4Dah8Zq6VY2t1A0k9rBK5fG54wx6Duas32lWCabdMtjahlhcgiJcg4 PtXOrdKmfLu3QE5wkpA/IGla83oyNfSsrDBBnbBH51nHEJRSsy5UG5N3Q4SnHSjzT6VH50H/AD1T 86POh/56p+dcVmdl0SeafSjzT6VH50P/AD1T86POh/56p+dFmF0SeafSjzT6VH50P/PVPzo86H/n qn50WYXRJ5p9KPNPpUfnQ/8APVPzo86H/nqn50WYXRJ5p9KPNPpUfnQ/89U/Ojzof+eqfnRZhdEn mn0o80+lR+dD/wA9U/Ojzof+eqfnRZhdEnmn0o80+lR+dD/z1T86POh/56p+dFmF0SeafSjzT6VH 50P/AD1T86POh/56p+dFmF0SeafSjzT6VH50P/PVPzo86H/nqn50WYXRJ5p9KPNPpUfnQ/8APVPz o86H/nqn50WYXRJ5p9KPNPpUfnQ/89U/Ojzof+eqfnRZhdEnmn0o80+lR+dD/wA9U/Ojzof+eqfn RZhdEnmn0o80+lR+dD/z1T86POh/56p+dFmF0SeafSpbeZVuYjIPkDDd9M1W86H/AJ6p+dHnQ/8A PVPzpq6dxOzNGCN4NYv9QvWP2U7/AN6W+Ro8fKB69uKjha8k0nSXtYI2kl3+axjDHAPGc9vest4r GSTewiL+uadeSR3YtIZHt/s1uGAXud3/AOoV0qrHqjndN9Ga6ywSXOqx2vzvCQIdiCQnP3tqkgMQ c96IrkGa9JtGQxWJlxOig7x32gnGf8ayFWzWIxAx7D1GaasNgqMgEQVuozU+0ja3KP2cu5fubh/s WlSMqeZcLJvKqFzgjHA+tR+afSq4FoHVw0e5BtBz0FSedD/z1T86ym+Z3SNYLlVmyTzT6UeafSo/ Oh/56p+dHnQ/89U/Oosy7ok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR 50P/AD1T86LMLok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T 86LMLok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok8 0+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok80+lHmn0q Pzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok80+lHmn0qPzof+eqf nR50P/PVPzoswuiTzT6UxpSJYjjoW/8AQGpPOh/56p+dMkliJVlkjJUk4LYzkEdfxpxvcT2L2lyy PqCgCPYEbzvNI2eVxvzn8Pxx2zU2qSxC2tmsNhsN5553+bg/e3c/d6e3/Aaxy8TY3JCccjM/T/x2 jfFu3bId3TPn8/8AoNbKVo8pk43lzE5mZnhJHZ//AGStnQDnSkP/AE1l/wDRjVhJLGXUs8aBQQAJ N2c49h6VueHyDpKEHI8yX/0Y1aYf4mZ1/hRpUUUV1nKaRHtTWUlcKcUxp8SogViGGdw6CpOc+1UI jaIHtk0bGAxUp9qr38ssVnI8CF5AuVHqaAJAmBVGzGLnUQP+fkf+io6safLLNZRyTpslZclfQ1V0 5nebUGkXa32rp/2yjxQwLtFFFSMKKKKACiiigAooooAKKKxrb+1dQutQFvf29vFbXBhVXtfMJ+RW zneP73p2oA2aKzv7O1v/AKDFr/4An/45R/Z2t/8AQYtf/AE//HKYGjRWd/Z2t/8AQYtf/AE//HKP 7O1v/oMWv/gCf/jlAGjRWd/Z2t/9Bi1/8AT/APHKP7O1v/oMWv8A4An/AOOUAaNFZ39na3/0GLX/ AMAT/wDHKP7O1v8A6DFr/wCAJ/8AjlAGjRWd/Z2t/wDQYtf/AABP/wAco/s7W/8AoMWv/gCf/jlA GjRWd/Z2t/8AQYtf/AE//HKP7O1v/oMWv/gCf/jlAGjRWd/Z2t/9Bi1/8AT/APHKP7O1v/oMWv8A 4An/AOOUAaNFZ39na3/0GLX/AMAT/wDHKP7O1v8A6DFr/wCAJ/8AjlAGjRVO2sdUjuY2utSgmhz8 yJabCePXecflV3I/uj9aAEopcj+6P1pssgjid9gO1ScZPNIBaKqaXcve6VZ3UgVXngSRgvQFlBOP bmrdABRSrjkkZwKiRpHRW/djIz90/wCNMCSim/vPWP8A75P+NNdpERm/dnAz90/40ASUUkj7Vyqr nIHOe5+tJ+89Y/8Avk/40AOopuX9Y/8Avk/40m51ZAwQhjjgEdj70APopkzHYAvykuq5HUZYDvTp H2rlVXOQOc9z9aQC0U3956x/98n/ABo/eesf/fJ/xpgOopm51ZAwQhjjgEdj70TMdgC/KS6rkdRl gO9IB9FJI+1cqq5yBznufrSfvPWP/vk/40wHUVG0hX7zwr9Qf8aBIcocxsrHGVB9D7+1AElFLkf3 R+tGR/dH60gEopcj+6P1oyP7o/WgBKKXI/uj9aMj+6P1oASilyP7o/WjI/uj9aAEopcj+6P1oyP7 o/WgBKKXI/uj9aMj+6P1oASilyP7o/WqmnXL3du8kiqpWeaMBc4wkjKP0UUAWqwbCGFrd2eCB2M8 3LRqSf3jdyK3qxNO/wCPV+/7+b/0Y1a0km9RMn+zW/8Az62//flf8KQwW+f+PW2/78r/AIVL271k 3UWsm4f7JPaLBxtEiMW6dzmujlj2JN2+F6bi3+ybPKDfvM+ntV/nFL0xxRXIUU727lt3iEUDSh22 nH8PvVzOV5ox69aRs44GTQAoxis61/4+9R/6+R/6KjrQVg3QjIrPtf8Aj71L/r5H/oqOhgWqp2U0 kt1qCO2VhuAiDHQeVG2PzY/nVys02V9Fd3Utrd2yJcSCQrLbs5BCKvUOP7vpSGSpqSPIo8mZYXO1 JyBsY9sc557EjB/EUJqSPIo8mZYXO1JyBsY9sc557EjB/EVDDpkkaQ273CvZQFTHF5eG+U5UFs8g EDsOgoh0ySNIbd7hXsoCpji8vDfKcqC2eQCB2HQUAGmah9oLQuWlmE0wbaBiNVldVz+AAHc/mat3 MyxT2iFnBmlKAKBgnYzYbPb5e3OQO2arW2li1k82GXbK0sjyHbxIrOzbSM9RuwD/AEOKs3Nt589p Jv2/Z5TJjGd2UZce33s/hQBWg1aKe5WIQTqGlkgWRlAUum7IHOeik5xj8eKuyS+W8S+W7eY+3KjI X5Sct6DjH1IqnHpvl/Zv3ufIupbn7vXf5ny9e3mdfb3q5IkjPEUl2Kr5ddud42kY9uSDn2x3oAkq h4e/1+s/9f5/9FR1frL0ZpFXXmgTfKLxii5xubyY8ChAXV1ERQSTy75BJcNFBHGuWbHy4HrnazZP Y+lSw6gHliiltp7eSQsAJQvUAHGQSDkEkYz0PpTH03/QLSCKYxy2m1opcbsMFKkkd8gkH61FfwXf 9mMzSrPepIskLRxFVDZAAxknaeQST0JpiJP7WiN8lrHBPI7s6hlA2/IUDHJPQF8fVSPTMX25nksP JkkKS300EnmKuSFWbjjsGQY74Az3qe201bee0kWQn7PBJEcjly7ISxPrlD+dNi0vy/s377PkXc1z 9372/wAz5evbzOvt70AaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUANbqv1/pWVqhv1sXbTBA1yvIS YHa49MgjB9+n8xqt1X6/0qtSYzziDxt4guL5bKKwtWuWfZ5XluGBHUHLcY756V3gFwNLb7Y0TXHl neYgQmcdskn/AD26U9LK2jvpL1IEW5lQI8oHzEDoP8+g9BT7r/j1m/3G/lSAp+Hv+Rd0v/r0i/8A QBWjWd4e/wCRd0v/AK9Iv/QBWjQAq9G+n9ajh/1Mf+6P5VIvRvp/Wo4f9TH/ALo/lTAymkl/tQRi XEm/buxxjbuxitWb/Uyf7p/lWSba6/t8TeSfs4k3eZuXGPK29M56+1a03+pk/wB0/wAqiCtczgrX CX7g/wB5f5iqGo3cgf7LAG8xupHXnsP8e1X5fuD/AHl/mKpXbXYvYWitBIkbZ3hlyQRg9SPWiabV kaqSi7tFCRZ9GCThVMZwH28D6H+hrWhuEuobeePOyQ5GRg9DWNBYXUFtJCLQt5uzdymPlJPPPOeP 1rZgaV4YDPEIZNxygIOODjp7UoxUXZbA582+5YKhsZzgMG49jmmy/cH+8v8AMU+mS/cH+8v8xWgh rFjI4G8hVU4QDvn2PpTgHBALYz/eC5/n/SmSLKJGaIIdwA+ZiMYz7H1rLu0dbkm7tXnhaMhREC+1 ue236c4rllzqRbaUbmoH8xYH6bjn/wAdNSlQ2M5wGDcexzVLT0ljsrZJgwYM2AxyQvzbQfoMVero jsrkbjJfuD/eX+YrP1PUXs5EVUL7s/xYxgD2PrWhL9wf7y/zFZ2qWgkKyEMx3cbQxK5Az9057ela Rtf3hSvbQoNqTyIxJMW0jkuMEEN/s+1a9q26GM/9NZP5tWVb6dcOWeNECh/+WhdGbAOPvA8fMfxr WtYXghiSTbv8x2O05AyWPXA9aJNN6bCjfqW6KKKgoKKKKACiiigAooooAKKKKACiiigArO0P/jxl /wCvu5/9HvWjWdof/HjL/wBfdz/6PegDRrDsObOUbin76bDccfvG5rcrD08BraRWUFTNNnPIP7xq 2pfEJloAKSwX5m5OO9OpOcjgY9aBg+9dBJsHntR6Udjg1XaOaWHaX8t8/eWuMosetA6035gnHLe9 OGe9ACbQCSByaz7X/j71H/r5H/oqOtLtWba/8fWo/wDXyP8A0VHQwLVFFFSMKKKKACiiigAooooA KhsrZLNrlkZybmYzPkjAO0Lgceij9amooAk80+/6f4Ueaff9P8KjopgSeaff9P8ACjzT7/p/hUdF AEnmn3/T/CjzT7/p/hUdFAEnmn3/AE/wo80+/wCn+FR0UASeaff9P8KPNPv+n+FR0UASeaff9P8A CjzT7/p/hUdFAEnmn3/T/CjzT7/p/hUdFAEnmn3/AE/wo80+/wCn+FR0UASebyCQTj3rFNrrRJI1 W0HsLI8f+RK1qKAMn7Jrf/QWtf8AwCP/AMcpGstZdCraralWGCPsR/8Ajla9FICtp9r9i061tN+/ yIki3Yxu2gDOO3SrNFFAEc4mMDrbvHHKcbWkQuo57gEZ/Os5bXWVUAanZ4AwP9Cb/wCOVq0UwMv7 NrX/AEE7P/wCb/45SNa6yykHU7PBGD/oTf8AxytWigDMe31d1x9vsRyDkWT/APx2k+za1/0E7P8A 8Am/+OVqUUAZf2bWv+gnZ/8AgE3/AMcoFrrG4E6jZNg5ANk3/wAcrUooAzvJ1j/n+sP/AACf/wCO 017fV3XH2+xHIORZP/8AHa06KAMv7NrX/QTs/wDwCb/45R9m1r/oJ2f/AIBN/wDHK1KKAMsWusbg TqNk2DkA2Tf/AByn+TrH/P8AWH/gE/8A8drRooAzHt9Xdcfb7Ecg5Fk//wAdpPs2tf8AQTs//AJv /jlalFAGX9m1r/oJ2f8A4BN/8coFrrG4E6jZNg5ANk3/AMcrUooAzvJ1j/n+sP8AwCf/AOO0eTrH /P8AWH/gE/8A8drRopAZ3k6x/wA/1h/4BP8A/HaPJ1j/AJ/rD/wCf/47WjRQBneTrH/P9Yf+AT// AB2jydY/5/rD/wAAn/8AjtaNFAGd5Osf8/1h/wCAT/8Ax2jydY/5/rD/AMAn/wDjtaNFAGd5Osf8 /wBYf+AT/wDx2jydY/5/rD/wCf8A+O1o0UAZ3k6x/wA/1h/4BP8A/HaPJ1j/AJ/rD/wCf/47WjRQ BneTrH/P9Yf+AT//AB2ptNtXs7TypJVlkMkkjOqbQS7s5wMnH3sdat0UAFYmnf8AHu//AF3m/wDR jVt1iab/AMez/wDXeb/0Y1bUviEy1S5xTGdEZFJALZCj174p30P6V0EmxR29qOp4o7VxlBwKRjjm hiAOelGBj2oAAcgelZ9r/wAfWo/9fI/9FR1ojCjgVnWn/H1qP/XyP/RUdDAtUUVm29pBcSXTzKzM J2UfvGGBgHsfc0hmlRVT+zbT/nk3/f1/8aP7NtP+eTf9/X/xoAt0VU/s20/55N/39f8AxqnYQW11 Lfq0G0W9yYVxLJyAiNk/N1yx/SgDXoqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zy b/v6/wDjR/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/ AL+v/jR/Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6 /wDjR/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v /jR/Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDj R/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/ Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Zt p/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/ zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zy b/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/ AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zyb/v6 /wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/AL+v /jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zyb/v6/wDj QBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/AL+v/jQB borH1SG3soIXjgy0lxFD80r8BnCk/e64JrWSCO3jRIl2rjPUk/maAHViad/x7P8A9d5v/RjVt1ia d/x7P/13m/8ARjVrS+ITLPylhnBYcjPanc9qTcN2OM0hRCclFJ9SK6CTZ796CMg0DletHtXGUNVM LjOQPWndBxQScVl2V7dTajcQy2xSFPuOT97/ADxQBoyZMZAbax6Gs+xDLPqAY5YXAyf+2UdaXBHN Z9p/x9aj/wBfI/8ARUdDAtVUsOt3/wBfLf8AoK1bqpYdbv8A6+W/9BWkMpW8V3/bEsD6pdPFDFFL tZIvmLM4IOE6fIOmDyea2KrpbbNQmut+fNijj246bS5zn33/AKULFcDy91zu2yu7/ux86HdtT2xl ee+33oAsVlaL/r9Y/wCv9v8A0VFWjCkiIRLL5rb2IbbjALEgfgMDPfGaztF/1+sf9f7f+ioqQC6X eTSNIt0wYPPMsLYA4SRl2/UAA+/PpUdhqznTtPkuYZ2M0cIe4CqE3uFx3B5LDoMc1bisAlm8HmEs ZZJlcDBVmdnH5Zx7/jWWPDTKkAFzEzQLD5cklvuZGjC42ndwpK5IHPJ5pgXp9Zhgnmja3uWWCRYp JFQFQzBSo65OdwHA6/nUiapE0TM0UySrL5PksBvL7QwAwcfdIPXp1pJNN8z7T+9x591Fc/d6bPL+ Xr38vr7+1RXeixXYuPNZHMlwtwgkjDqpEapgg/eGAfTr7ZoAu2l0t0jkI8bo2x43xuQ4BwcEjoQe D3qxVPTbP7DbtFttVy5bFtB5K9B1GTzx1+lXKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQBk+If+PWz/wCv62/9GrWxJ/D/ALorH8Q/8etn/wBf1t/6NWtiT+H/AHRT AbWJpv8Ax7P/ANd5v/RjVt1iad/x7P8A9d5v/RjVrS+ITLQHufxpaa27Hy4zkdemKd+VdBJrUvfm jqM0ySEO6MWPynsa4yh/UUmMGlB9qB1oARkDDB6Vn2vF1qI/6eR/6JjrRrOtf+PvUf8Ar5H/AKKj oYFqsN7q9hN2LG3gl2zs8rTzeWFG1cdj6H0xitysNv8AUa5/ut/6CaS1dhvQY1/rqqWay00KBkk3 ZwP/AB2nrd+IHRWTT9PZWGQRdEgj/vmt8Qxz2SRyruRkGR/nofes6xWS3uru0d/MWNhKj9yHyTn3 yCc+/bpT5VYnm1KX2nxF/wBA2w/8Cm/+JqG0TW7SO5dLG0aa5uWmYG5IVRsRQAdvJyp9Mcda6Gs/ Wi39nhVd033ECExuVbDSoCMjkcEipKKn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1P5R0++s1h mneK4do3SWVpMYRmDAsSR93HXvVazWdVuLczXCar5Df61y0Tt2kQcgAHsMYzyOlADvtPiL/oG2H/ AIFN/wDE0fafEX/QNsP/AAKb/wCJqSwSOaK5txLfQyrtEqSzFnT3VjnhvUHHHGDU2mKVln8p5Xs8 L5RlkZyW53EFiSV+7j6HHFAFX7T4i/6Bth/4FN/8TR9p8Rf9A2w/8Cm/+JqII1zrF+kkOoyotwiC SG7MccY8uM42iRT1JPAPXvUVnKZZysMl4bw3su5neTyvLWYggbjtPycYXocdMUAWvtPiL/oG2H/g U3/xNH2nxF/0DbD/AMCm/wDiau6sk726eSJWRX3SpC+x3TB4U5GDnB6joRWVPIs82nLb/wBoXdu0 E7bYrgxvkPGPmJZc7ckYJzQBY+0+Iv8AoG2H/gU3/wATR9p8Rf8AQNsP/Apv/iaqzPDBqDRTf2kF FrEY41nlYqzPJncwYrnoMscccHAq7HHPdXEdneTyAwWsby+TIY/MkYsCcrg4Gw8D1oAZ9p8Rf9A2 w/8AApv/AImj7T4i/wCgbYf+BTf/ABNa8MfkxLHveTb/ABOcn8TXM2ZkHhO4vMX8Vx/Z5YTTXRcO xjzuUbzjkZ6A8/WgC/8AafEX/QNsP/Apv/iaPtPiL/oG2H/gU3/xNP1S0R9QsG826Tz7gpII7qRF IETnGAwA5UHim6kn2eaN55btLFI1RZIpWzE2Tln5ywxt5ORwc9c0AJ9p8Rf9A2w/8Cm/+Jo+0+Iv +gbYf+BTf/E1t0UAYn2nxF/0DbD/AMCm/wDiaPtPiL/oG2H/AIFN/wDE1t0UAYn2nxF/0DbD/wAC m/8AiaPtPiL/AKBth/4FN/8AE1t0UAYn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2nx F/0DbD/wKb/4mj7T4i/6Bth/4FN/8TW3RQBifafEX/QNsP8AwKb/AOJo+0+Iv+gbYf8AgU3/AMTW 3RQBifafEX/QNsP/AAKb/wCJo+0+Iv8AoG2H/gU3/wATW3RQBifafEX/AEDbD/wKb/4mj7T4i/6B th/4FN/8TW3RQBifafEX/QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAGJ9p8Rf9A2w/wDApv8A4mj7 T4i/6Bth/wCBTf8AxNbdFAGJ9p8Rf9A2w/8AApv/AImj7T4i/wCgbYf+BTf/ABNbdFAGJ9p8Rf8A QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAGJ9p8Rf9A2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2n xF/0DbD/AMCm/wDiaPtPiL/oG2H/AIFN/wDE1t0UAYn2nxF/0DbD/wACm/8AiaPtPiL/AKBth/4F N/8AE1t0UAYn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2nxF/0DbD/wKb/4mj7T4i/6 Bth/4FN/8TW3RQBifafEX/QNsP8AwKb/AOJo+0+Iv+gbYf8AgU3/AMTW3RQBifafEX/QNsP/AAKb /wCJo+0+Iv8AoG2H/gU3/wATW3RQBifafEX/AEDbD/wKb/4mj7T4i/6Bth/4FN/8TW3RQBifafEX /QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAHO3UeuXxt47ixtI4o7iKZmjuCzYRwxwCo9PWukfOEyC DtHB7U2pJvvj6UwI6xdN/wCPZ/8ArvN/6Matque0oTj7QXaMwGaTywAQw/eNnJ71rS+ITLgkVrlo 8SBkUHJBCnPv0J4qXmimNJGrYZlB9Ca6CTapGZVxkdfelx3prxrJtLgHByK4yhRg9KdwR1o+lIRx zQAVnWv/AB96j/18j/0VHWj2rOtf+PrUf+vkf+io6GBarFVRIusx70TfldznAGVPJ9q2qwJv9VrP 0b/0E1LdtSrXNxbsRQjcYgqLyxkwOO/SoIhvvZrrfGY5o4wu1s9N3P6irohjnskjlXcjIMj/AD0P vWRbJJbXl1aO/mBCJEfuQ+Sc++QT+PbpTqScYtomCvJJmnuX1H51XvbZb22MJleP50cPHjKlWDA8 gjqvcUVQ1rd/ZoCu6b7iBC0bFWw0qgjI5GQSOtcqrtu1jd0kkXYLLypRLNcTXMiAhWlCjbnrgKoH amRaasbs73NzK/ltEjOwzGp6gEAHsOTk8daoeUdPvrNYZp3iuHaN0llaTGEZgwLEkfdx171Ws1nV bi3M1wmq+Qf9a5aJ27SIOQAD2GMZ5HSq9t5C9maraSrQXCPdXLSThVeY7N+1SSFxt24+925yalSy lWNklv7qX5kYFtildrZx8qjg4wc9s1l2CRzRXNuJb6GVdolSWYs6e6sc8N6g444wam0xSss/lPK9 nhfKMsjOS3O4gsSSv3cfQ44pOv5B7MtPpr/aZ5odQurfz3DuiCMrkKFz8yE9FHftUo0+JbfyQ0gx M8yvkblZmZjjj1JH04OaxbdWn1298yO+dYrhQsiXJWJAIkbaUDjPJP8ACRz9am111T+z1ke5WJ7k q4tzIHYeVIQPk+Y8gHj0p+21tYPZmq9mxg8tbq5jYSNIJAwLDJJxyCCBkgAjgAelV20hVMDQXVzb vCsi702EvvYMxbcpGSVzxjvWTbiaW5WyaS6S0kMksZd2WUoojG0sfmHzMx9cAVK6XKm9sLaWV9iR SoWkJcKzMGQMec4Q4J6butHtvIPZmvDYLG8rzSyXLyxLFIZQvzKpc8gAD+Mj8PrTX00ERFLm4imi UoJlKlivocgg9O4z+tZHM2mj7G168ccx8+FpSJwAvKBic5ztPXkdDgipLOdXvtPFvPNJbvbTt+8Y 5JDxj5s9xkjnnrR7Z9g9n5mzFa+U0TGedzGjKd75DZIOT7jacegJqP8As6L+x/7M3SeR9n+z7sjd t27c9MZx7VU0R3l0PT5JGZ3e2jZmY5JJUZJNYdmZB4TuLzF/Fcf2eWE010XDsY87lG845GegPP1o VZ9g9mdbPbJNLbyOWBt5DIuO52svP4MfyqG9sBeEiSedImXZJEpG2Recg5GR36EVlapaI+oWDebd J59wUkEd1IikCJzjAYAcqDxTdRT7PNG88t2likaoskUrZibJyz85YY28nI4OeuaPbeQezOjoqtRU /WPIr2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5 lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9 Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZ oqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmpJvvj6VTX74+tXJvvj6Vr Tqc6ZnOPKR1g2Kl7SVQzJmaYBh1/1jVvViad/wAez/8AXeXp/wBdGrqpfEZstcggfw46k80HGen6 UAhhkEEZxTsV0EmqeFJ6mmpIGXoQKeAKMYNcZQdzR3qCW6WOQxgEuBnGOKkRcDOSc+tAEM92sFxF EysTIcAgZxVe1/4+tR/6+R/6KjrQK5xntVC1/wCPvUf+vkf+iY6GBZrE8ozDV03omcjc5wBlTyT6 Vt1ht/qNc/3W/wDQTU2voO9tTZW7EUI3GIKi8sZMDjv0qssTS3st0GjMc0aBdrZ6bufpyKviGOey SOVdyMgyP89D71nWKyW91d2jv5ixsJUfuQ+Sc++QTn37dKuUVKLRMW00yx5TeoqC8sBe2pgeV4vn Rw8eNylWDDqCOoFXao6u7x2cbRsyE3MC5U44MqAj8QSK51RijV1GJb6b5cqyzXU1zIoIVpQo25xn AUAf596ZFpCo7O91cyuYzGjOwzGpxkKQAew5OTwOasXcwiuLFCrEyzFAQ5XH7t2yR3+70PrntVS3 1WWW5jV7UJDJcS26yeZklk384x0IQ9+vbvT9lEOdg2iK8E6PeXLSThVeY7N+1TkLjbtxy3bnJ9ak j02RYykuo3UuWRgSEUrtYHA2qOD0Oe3pmodHv2neW3G6V4p5/Ndm+4vmuFA9eB06AD6CkGsXLOoS wBWS4ktoz5wBZkL8kY4XCHnr7HrR7KIc7LsFikEtxIrsTcSCRs9jtVePwWo/7MQtAzzSuYJnmUsc 8sGGPoA5AHsKZHfiYWLNEyvLcyQECQ4VkWQH/eGUPX1B6in2V7cXnlTLaKtnKNySGX58YyCVxwD9 SeelHsoh7RjrrT1ugh82SKSM5SSPG5fXrkH6EY6VHHpSpBKguZ/NlILz5G8kYx2x+GMe3JqjpOrS R6ZaG+jKr9g+0ecZN7OEVdxYY4J3Ajk574qO511LrTtRjhkhEq2Us0bW9yJCuF/ix91gSPX68Uey iHOzRXSQkDIl5cpK8nmPONu9mwByMbegxjGOBTrfSYbeWGRHfdEkic87t7KzE++Vz+J/DQoo9lEO dlC10xLWO1jjml2W0PkqpPDD5eSO5G3r7n1pv9kw/wBj/wBmeZJ5H2f7Pu43bdu3PpnHtWjRR7KI c7Kk1ik8tvI7sDBJ5i47kqV5/Bj+QqK80tbwkSXM6RMuySJCNsi9wcjPc9CK0KKPZRDnkReV/tfp R5X+1+lS0UvYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv 9r9Kloo9jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8A a/SpaKPYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv9r9K loo9jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8Aa/Sp aKPYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv9r9Kloo9 jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8Aa/SpaKPY wD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIjWPBB3dKsTffH0qOpJvvj6 VcYKOxMpN7kdYemgi2kPJzPNgf8AbRq3KxNO/wCPZ/8ArvN/6Mauil8RLLY6Aml/GmbVMgYgFgCA ccgd/wCQp2K6CTXPAzQOmTQDTW6cVxlC4U84p2KjjUomGYsfWn0AFZ1r/wAfeo/9fI/9FR1on0rO tf8Aj71H/r5H/oqOhgWqxkTzF1mPcqbsruY4Ayp5J9K2aw2/1Guf7rf+gmktwexsrdiKEbjEFReW MmBx36VDEhe9mugUMc0cYXa2em7n6cirghjnskjlXcjIMj/PQ+9Z1islvdXdo7+YsbCVH7kPknPv kE59+3Sr6Mnqi9Ve+tVvbYwtI8Xzo4ePG5SrBgeQR1A7VYqrqEwgt0cqzAzRJhXK/ekVc5H16d+n esyyNNPYSwyT3tzcmGTzE8wRjB2sv8Kjsx/Ifi5NOhTyMM/7m4kuFyRyz78g8dP3h/SojqExmvlS 2Ty7Rgm9pgu4lUb04ADHJ9uM54gi1sSaZdXSxxSG3kEbeTNvjPCnIcDoA3Jxxg0wLcWmwxMjRs6y LI8gcEZO9yzKeOVyen0780qadCnkYZ/3NxJcLkjln35B46fvD+lS2kzT2scr+Vlxn9zJ5iY7YbAz x7ViWUtwIJb29Ri7XggUR3khX/j42fdwAAMDt8wznGSKANZNOhTyMM/7m4kuFyRyz78g8dP3h/Sk ttPW1kXy7i48lc7ICw2L9OM49icCoItQvPN1My2sTQ2bEJ5UhMj4RWA2kYyQ3r14weps6bdte2on YQYY/L5MpkGPclRg9eMUAMi0q3jitozvdLe2a1CsQQyHbnPHX5B+Zpp0svbT20t7dSwTRNDscodo IxkHbnOPUmtCigAooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVJN98fSo6 km++PpTAjrE04f6M/wD13m/9GNW3WHp5ItZCBuImm4/7aNWtL4hMuUY96aXUNt3Dd1xnmkjEgT5y pbJ+6OMZ4/Sugk2RkDk5pCSvbP0p2aM4rjKGjdu6DFPNJnB60GgBT0rNtf8Aj71H/r5H/oqOtIkD k1m2pzdaif8Ap5H/AKKjoYFqsZE8xdZj3Km7K7mOAMqeSfStmsNv9Rrn+63/AKCaS3B7Gyt2IoRu MQVF5YyYHHfpUMSF72a6BQxzRxhdrZ6bufpyKuCGOeySOVdyMgyP89D71nWKyW91d2jv5ixsJUfu Q+Sc++QTn37dKvoyeqL1Q3Vul1EschYASJJ8vqrBh+oFTVV1CYQW6OVZgZokwrlfvSKucj69O/Tv WZYybTIZortGaQC5kWViCPlZQoGOP9gHnPemxacYUuPLvbkSXDK7SfIWDAAZGVxyAB0xxximnUJj NfKlsnl2jBN7TBdxKo3pwAGOT7cZzxBFrYk0y6uljikNvII28mbfGeFOQ4HQBuTjjBpgXbewS3hg jjklCwu0n3seYW3Z3YHIyxOOOQPSk/s6H7L9n3Ps+0faM5Gd3m+Zjp03fp+dNOL3TkkuJhCh+dmt rg7SvP8AGADjGDxil0xZFhl3mQwmT9x5pJfZgdSeeu4884IoAcLLZc3M0VxNGbgfMq7SA2AocZB5 wB7e1OsrNbNJAJHleV/Md3xlmwBngAdAOgrGspbgQS3t6jF2vBAojvJCv/Hxs+7gAAYHb5hnOMkV ei1C883UzLaxNDZsQnlSEyPhFYDaRjJDevXjB6kA1KKqabdte2onYQYY/L5MpkGPclRg9eMVbpAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFSTffH0qOpJvvj6UwI6xNN/49 n/67zf8Aoxq26xNO/wCPZ/8ArvN/6MataXxCZb7UUfXrSEHP3iPpXQSWhcSjps/75P8AjS/aZv8A Y/75P+NFFcRRXlWaSeOQTsmz+FR8rfXNTtPM2PmVcHPC/wD16KKAAzynOdnP+yf8ag04lpb8nGft I6f9co6KKBl6seKJrj+2IUIDSZQE9MlSKKKFuJ7GzHK6RquxTtAGd3/1qrpE/wBvnuG2hZERQAck Fd2f5iiirezJW5PUN1bpdRLHIWAEiSfL6qwYfqBRRWZZBNpkM0V2jNIBcyLKxBHysoUDHH+wDznv TYtOMKXHl3tyJLhldpPkLBgAMjK45AA6Y44xRRQAjaUn2KK2iuJ4RHJ5u9dpLMSScgqR1OenUDHS porR0EfmXlzMY5C+W2ru+UrtIVQCOc/UCiigBv8AZ0P2X7PufZ9o+0ZyM7vN8zHTpu/T86UWWy5u ZoriaM3A+ZV2kBsBQ4yDzgD29qKKAHWVmtmkgEjyvK/mO74yzYAzwAOgHQVZoooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKkm++PpRRTAjrnrGwhnhkkczZM82dtxKo/1j dlYD9KKKcZyi7xdgZYGlwf3rj/wKn/8Ai6X+y7f1uP8AwLn/APi6KK09vV/mf3isj//ZCmVuZHN0 cmVhbQplbmRvYmoKNTIgMCBvYmoKPDwvU3VidHlwZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VS R0IKL1dpZHRoIDU2MQovSGVpZ2h0IDMzMwovQml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRmxh dGVEZWNvZGUKL0RlY29kZVBhcm1zPDwvUHJlZGljdG9yIDE1Ci9Db2x1bW5zIDU2MQovQ29sb3Jz IDM+Pi9MZW5ndGggMTI3ODM+PnN0cmVhbQp4nO3dCWAMZ+PH8ZndRCIXIRJHFImzr6KEKqWukMN9 VlVdEddL6aEHWq06ql5taSmCKkrrVupsHS3VHKV60BKibhI5JZFkd99nd2JtZnZmZ2dndjbJ7/P/ d7s7meMZbzpfs8csbTAYKAAAABdAo0kAAOAi0CQAAHAVvE0aFdXSyUMBACir1n73q9pDKB2sNGly v9Y5D3TzXh3tXdGD1rqrMiwAgLLBoCu8n/fgrUVrfDy0S3ckqD0cV8duEjk9emfysMq+Xvr8LF1e pj4/U62RAQCUAbSbB+3mqa1YKeNm8pxNiQ3a4IRJSIkmkSD9740xuvxMfV4GCZKKwwIAcBEr9551 cA2x0c3IrZtv0I2rlz/Z/SeyJKBEk4Z0a/HZzNGF91IQJAAAYtW+P7r3HvTk46GS13D6r+SDu7eM jWxK7ucVFM3c+FvzZ87IN8Cy5lGTurRpsnl+rC4voyAtRdUhAQC4irj9f02f/lpeys+S11Cx7tML F34YE/E4ZWqSXk/9d/Wv3aLOyTfGMqVEkzbNHZN/65y+MF/dMQEAuIjVB8+/+srL95N/krwG79Bn Fv1v8ZjujZmHuQ+KJq89iybxedSkVv8J3bM49v6/7Cc6lx7N1HhUtLkiX13asHbVtRpa/jFC+UD7 tvJv3d/vsfpu7hRVmJr/7w/pCbvvZxeqPS4o19Yc+uflaVOz/zlqOfGPlLTfU9LInaGdGponbjr6 D7l9om7VpnWrWs7s27DT4o8+Hh1ePCdp0qjlZwYMSlZ65KVUiSbt/jAm50oia46pR/xv5lawuSL/ 9PiPBwd7VtDKP0YoB2i/8FqDx3tTv51YOHP54VuGpsNf+3BKC0P8rxs+9C7Sqz06KL/Wfn9h2ktT Ms9/bznx6+PJs9bHkztzhrcZ0jHU6hSzSo27fvTJklFdGzAPSZNiVv2BJvEp0aSdH4zKSWG/ff6E Z68e3bvTGiPa+K+Hd0v+e/4b4wfUS0eTQBIfn8i42qEVLrzfdcLeew2CPWtW1Hq0/vSVya0eHJmy 5seUrtXb1ol9y4u6lHryglezLl4+7lR+StavK2+d/lPH/P5q/L1bjg1s3tazopZ68G/2mdW3ks4Y W1bhqYcLJns371LRW2vI/i3tyP/u/ot38YAoX/yQ/NLkSel/HrScuOVEyuxNp5n7s4c+aby1eDio fV3Lmf3/0/2TpZ+N7FIcKtKk2DXn0SQ+JZq0ff6L2ZfjWXP84tNfTJPmTY/tWycVTQIp3P9Ta/RC f8/zS/oMPEZ5tfCv0DjEu3aVqND/vlQtc/vLwz5o1y06curb3hR1/8TCnTv3nrhYvcmrcZPbe1/b PubGv3e86AqeT31cv22dB7/MnDX7SP6A1UtiGt/cFXPl8k0fz7b1xs8iC6Z998bOg6f+rvL6rLcj fdM2rft4XcsALZ5oBpu+PHp58sTxqWf3saZvP3V1zpY/WBNnDWrav21t1sSAZpFLl33+Yqd6zMPc B7oJ6y6gSXxKNGnb+8OyLv3CmiOh0uCIyIji9JhLZBko0525r43tHXzL0x1NAvt5PFVv4nu+msTZ 3UbcqubbItSvnT9NeXaoN2mmr+7EjIiJhc16z/rfHF/q8prBfTanurWr4+ERMHz0hxODUje+8cqK vi1bNhj7cVWvlDWDe2/JcA9r2Df201m10za9MXV57zZdmk2e7UOdX9p34N4cj2caRwz/dG4dw6mZ EROqP1WtYyVUCWxYf+zKpAlj75zew/3RzoQb83b8bX74Vr9GfVvX5M4W+GTPz5avGv5sHeYhadKk jZfRJD4lmvTVrAEZF06w5vij5ujIyMiHMSquEm36P8sp7708qkdAiqe7xum7AKWfe/OQKcuqeZHz pCEXfbw6hmpqu1N05QH/mfyyd+b2l3q/QzeJevvzD6pQie92G3G1qm+ov6ZlnS6t3nw/QP/zjIjx FVr2mDp/IbsvJDw9xmlbRr6yYIEfFf9219F3An1Caj0bs4isJ35WlzHZtX2iQjSV8AsLgjadvDF2 3Pir8bu4P9p35vYn3z1Ky0tRoZEtgriz1W7TZ9WKz4e2K85VXoHule130SQ+JZq06W3SpJOsOX6v MSoqMorWFkeIE6fi86T3po3qUQ1NAmn8Kvff1vDxCmfeDV95Pi+qiTZQo6nQbEnz3i3yj0x4bsbJ Bk9EvLnig6rG86T+Z9w924VqQ2uMaDphbMXUryb1n+/eqO2rH60K9vn7074Dtt/QWazWrVnLqHc+ /8DfFKGsGj4dmnbq/uZ8P+ZhTZ/uDbTVcGIPgr46QZo07lr8Ttb0787csQwSg2QpqkUga2Jwm76r Vqx4vv2jJr287Q6axKdEkza/M8hak0ZGRUU9SpGGFafif5vOk66gSSANXalPwNhX6upOfbVggVeF /JCQgXUHxvgZfv74+XHfZVRo16jrlGXk/Ia6f2L+J+sONG/UsGnvxXUaeF9a1mvChqvNQyv1HBHX oVvDjIOzPt1y1E1TpVqTzk92Cvl7+bxL9LMTPicxexihZp07Tp/na37Y0D0QTQJBX524PjY29lpC iSZ9d/rOxw+DNDXK+OYFy4dRT5bIUnDrvqtWrny+fS3mYS5p0tZbaBKfkk2aPTjzIqdJ1Us2qfiF pUdP3jHnS+9OGxkR+C+aBBIZ6PTcVhmdR3Zq/0Q1T4oqvJv1544v31+245quUV3v2sGdJy0i5zfn vlz6Z9jzfR+v6kblXbq4Zc705af0VXxbBrm3C62cExRTPzqiaY2KpFz5V45fOrDq672XG7eP6jl9 7sMI+fZo3rnDaxYPG6NJYMPGn67Fjo29XrJJe0/f+cgUoWlRodGmAnGnmNVq3XflqpXDnglmHpIm TfvmJprEp0STvnl3SOZF9iU0zgaNiIqO4r6SVHzn4eN3p42KDLyC9ziAZPrCotMX8uKv51+7r3ug pyittoqPe+2AClU8tE2bdO72OtOS0Te8tPcyCjILyAyaoKpeDatoqwZ6tAvQ5KXnHzif+1dqQYbx U7Z0FX+PelUr1K/sXq9a4Rf7sm5Rbk809I1o4hFUlLtor8VD/MKCoA0/XY0dO5bVpH9u3r9w6z65 Y5kfkiVy26C6d8Ma3pYzm5q06oVnit+PR5r00tfX0SQ+JZq05b3nMpPZTfo8wVAlwPjCHWnSw1vm LmU5Me3KX8Pb+HrgPAkcoC/U/3un4HKWIV9nMH1QlvbxdWtcwz3It32Dl+b4FJ/feId4UrmFlPGT SRpNYIB7s2paD/JraDBkZhadv1OUXmhgPrTk4amtG1ihnrf+j+SCmwUGHaUJa+IZROt+u2jxEE0C QRt+vBobE3Mjkf16kng1w/qujIt7ocOjJk3ZdA1N4lOySXOGZiWfYs1RUKTX6W1/Pzppk4eblsZ7 a0EJHu3qT3nvYZP8oppWREvAOdYf/3dczBgHm7QibvXwjo8xD0mTJn/1L5rEh/X5pOezktmfTwJw CQ9yFuxKNz3n5hf9hHd1NAmcYv3xK+0692gaWkvyGv5Ivn7yyIHhHS0+n/RVCprEp2ST5g7L5nxm FsAl6At/PZ93w/icm9tTaBI40YoDf9ueSdC4Ho3M90mTJm7AZ2Z5lby20LzhaBIAgHKM1xZan4wm 8bF9HQcAAJDRxM34fBKvEk3q16qauqMBACjzdiTh2kK8HjWpY/unj5/4OSP1FvPQoPVQb1QAAGUK rXvA3Ll9LWXspGkR4dK/TL1sQ5MAABSHJomEJgEAKI7VpDotl6o7HpeFJgEAKI7VpHnT16o7HpeF JgEAKA5NEglNAgBQHJokEpoEAKA4NEkkNAkAQHFokkhoEgCA4tAkkdAkAADFoUkilccmLYrbovYQ AIxejRkk8FN/f3+njQQcl56eLvBTNEmkctqkjuE91R4FlBHHD+2JHTlMwoIrv9go3KRKlSqR28zM TIkjUw8zcj7K7ZG62xVeP5okUvltUps6FdUeCJR68VfySJMmjnlBwrLLVm8QbpKfnx+5zcrKYh6e PXtWwla4mjVrxpoi+5qZkfNRbo/U3a55/VahSSKhSQDSMU2aMna4hGWXrFov3CRfX19ym52dzTwk R1JuTuxldSWyr5kZOR/l9kjd7ZrXbxWaJBKaBCAd06SXx4+QsOziz9cJN8nHx4fc5uTkMA9LUZOY kfNRbo/U3a55/VahSSKhSQDSMU16beJICct+uOwL4SZ5eXmR29zcXOZhKWoSM3I+yu2Ruts1r98q NEkkNAlAOqZJb04eJWHZ+UvXCjepYkXjr2heXh7zUK0m6XWFRbmZ5Fjh5uWn0bqLWTMzcj7K7ZGM 201NTc3IyCgoKCgqKio0IferVKnStGlTvu2a128VmiQSmgQgHdOkWS+NkbDsnE9WCzfJ09OT3Obn 5zMPbR5J16Z8Ruk1o0ImCMxjb5NIkJKWDNE9yNG40R4+lZ8Yu4EvS5YrYUbOR/weiSH7dvV6/d27 d93d3T08vB4UFpLHxkOkweDvX/nAgX2RkZF82zWv3yo0SSQ0CUA6pknvvhwjYdl3FscJN8nDw/jf 4IMHxccy4SPpykufUHqDTq8rKtBNbjqdbza7mkSClPhRXy//Sn61Qmit2/07V/PvZzYbs8lqlixX woycj8g9Ekne7ZJznTt37lSuXNnb2/tyynVykkSSRP6P/NkGVa928sTxvn378m3XvH6r0CSR0CQA 6ZgmzX0tVsKyMz5cKdykChUqkNuCggLmId+RVGcoWpH8sZbS1PUJIX/HP596Lvd+/utPveOmcePO LL5JJEi/LulfsXLlSrUbkAMFpdHS2gqZty7mZt5rOWYjN0uWK2FGzodvj9J/G+/u5k3TmocTDIUF WX6Pf0BrLNZGU5TGk6a1cm339u3bJDw6na7IpLCw0PxkHfN8Hbm9dy+d/MGGd488fuz7wYMH823X vH6r0CSR0CQA6RQ9T3JzM0aFHCKZh3xN2pCyKiUr2b9C1bp+9cjf6K9nXP/r6rkQv9Cp7V7nziyy SSRIpz/tX9G/SqVaDbNvX85Jv23Q0BUr1/QNapR2/XzOvbRn/ss+W7JcCTNyPnx7lPZz79DIYzRN U6YnyyiaLspPvfPb+wYyxUTj7kuO/7TPEx4Bz8q13evXrwcHP5aRkWnapPFwaDAh/9JTVBX/St/u 3lW3XiOdXl+zRtDhQ/uGDx/Ot13z+q1Ck0SS3qTw8HBye+jQIUc2L2YlsmzIktUmka3IuC+yjxlc k6KvJ2m1xrMB8ld45qHwM12vn5zc7rH25ND5y8VfxrWYHFKlvtXZxDSJBOm3zwZW9K/qG9ww+9al 3Jy0GtGfkOmXd7zk4RXgUz3k7uW/M+6mRc3YqnFzt7oSZuR8+PYo7UT/0Mh9BbeW6wrIWZ8fTft6 1uxKQkQZj1F6ytgIA63xuXR4mH/rFXJtNyUlxd8/4PW4X8nBkLSv+B+T7KyshbGtjx09fP/+fbJs VHSffd/tHjNmDN92zeu3Ck0SqRQ0SXYKNYm1NgpNKgcevu9utIRl5y9dI9wkjcb4LJZer2ceCjdp 2pHx7UM66A26/Yn71wz8im82m00yBmnFoIqVAnxrNcq8fTE3I61KtwX1QkLJYNJS78SvivH0qlyp 5mPXL1y8dzNz2OJd2odZslwJM3I+fHuUdqRfSK/d+dfWG1/AeXCv8P5tHa1x96xBGQopfYHBQM5C inwbv55ycGDVDrusDl7Cdi9evBhQLejN1Wf8q1Qli9OaYuRO8j9/fxATdujQd40fb0GGVKtm0K5d 2yZOnMi3XfP6rWI1qU7LpQIzl2fyN4mZzrD8qdXprJVYDYPV8w/hrQvHgNsk7nYtR8sdM3cwrCGh SeUE9/NJ3Z5tJzD/4WMnzfdtfj6JNj1nZf4vVLhJk/aPfqZhR9KkfT/v2/DCVr7ZbDbp/NdTKf19 35qNMm8l52akBkYsfKxOPfrhs2epd+8cXjjC08enSnD1q+dTDNrAYfPjuCsxz28V3x6lHYmuG7kj 59JWQ0FOYfZd38aDPas2Mb2CxJwnGYznSW6VL2zvEND5W6uDl7Ddc+fOBdUInrn2bNWAAHOTmNt/ zv01f0xLcm5Uo0O13Vd2znh8/rYtm6ZOncq3XfP6rWI1afOJXQIzl2cyN4nvuCzyvtWDOHd+ij9L sjSJW0qKv0k29wvKMKvXcejRub3VmQ8cOWH50OZ1HJj/Ns3HWeEmjd35QsemnXQG3d5je7fE7Oab zWaTsv5NurB3tod/cOadW0+8uNq3kj/r5CMnK2PNxN7kPOrOlbQBsxbXe/Jp7kpsHJ159ijtYK/6 Q34kp0RMgQzkxKPgelHGYYMu01BE/j/LoMvxDJ5xafeYgIg9VgcvYbvkfnBwnVnr/6wWGPQoSGRW jeb8H7/PG91i185tP9Tedz+7aEWHtZs3fTl9+nS+7QoXEU0SyVWaJPDUmZj12MXeJvGNUyBdaFI5 8fB6dy+ypkd3e4Y1Ze/hn1hTlqz6UrhJzHNB5iQIN+nFTUM6tTQ2ac/hPbv+u59vNjGvJ2VcSbry y+azeY+PHTfhwYMHc+fOZY7SxOuvv+7u7r5i+TL978e6jJhoDhJrJcLPYvHtUdreXqFDD+lzzxoj pMs2FGXoC9PJfaoo44cL6cdSdJl5eYVF+a3c7j0/8oBc201MTKxXr/47G88FVq9RL9CLKu4KfSOz 6K+zv70/qgU5N2rdpoPeQD1Wu8aG9WtnzJjBt13hZw7RJJFcokkMtZrE98QdmgQ2CVwXvE/3jub7 uw4e585g87rgzGvm5tfthZv03Np+ndt20et1u/Z9u//V7/lmE/9e8HXr1o0ePZocbRcsWBASEkKG kZKS8sorr5Amvffee+RHgYGBfCsRfrWfb4/SdvQOGf6dLvuY8azIeG6UYbqTfuB8+u/5vq2ahAVX aXDkz52n/vixZVDPsRGvybLdkydPNmnSdOpnP1tdZP6YVhvWr3m6XRe9wVDnsVpr16x49913+bYr /A4LNEkkl2iSwOtDItdjFzQJ5MI0ie/7kwZEGt+yvG3fMas/tfn9Scx7i83vbxZuUr/l0V07dNMb dDt37fph5o98s4lvUlxcXGxsLDk+LFq0KDQ0lGnSlClTSJNmzZpFfhQUFMS3EuF3RfPtUermnvVj 9ham7zbVKKP4KTtd5pTdGX2ielJaTe8mk//3fayW0mz7dv/ud07Lst2jR4+GhbXJzs7W6fWFhUW5 uQ8MBn2FCu4a2nhk9PXxWb06rn3HcHIqVKdO8KqVn82bN49vu8LvREeTRHKVJvGt0N75JbyeJKZJ VieiScA0acyLz0tYdvWXXwk3ifkMpvlzoMJNiv4oPLxrd9KkHVt3/jjnFN9sNpt0O+/G9exrxy8d /ef8Pz1b9e3ZvPfixYsbNmyo0WguX748adKk/Td2Hfx7v2+R3xPVnqzpHdw2tB13JcKfHuXbo7Sv hzw29PPCtARKn2sw5FP6fMqQb9A9eH7T7olDJ0X+p/hN2N/+vmzuivf3zflTlu2eP38+NTWV+ahs Tk4OTdPkzt27d8mBUaPVkqNjzZq1mjV7ksxZPajaO+/MXLhwId92hT+xiyaJ5GiTLAk/HSfyfXeU pM5ZnZmPzSZZHS2aBFxMk0YMe07Csus2bhZuEnOtGvP1coSbFD7/2R4RPfSUfvvmnac+SOSbzWaT 5vzylkGn9/X2ybifcT+5aM7A+atXr27UqBE5T0pOTh46dGjcP5/6+/ll5mVcunrl79+S9715mLsS 4avs8O1R7tlvilLPF1xL0heWuMB27L+3e/XqXkTp3whfu+DgKE+tB995krTtMs6dO0dOBINr1/H1 rbxr5xaS4du3b9+4ccN8cQeiatWqb7zxBt92ha9shCaJVN6v4yD+Y0nIDHAxTXph6BAJy27Y9LVw k5hrepqvKyrcpGdntysq1BUVFumKdImLz/DNZrNJi39ekHLzcoUiz5uXb/nrqtatEOLr61v8kR2a vnDhQl61nAyvtCqVApKvJ9f0CV4+fgV3JcJXIxW5R2brDi/56d/N7Zo906D6kxdunT559qc2NftZ fT1J8nbJglu3bu3cuauPr29Rkc5Nq1m27NM333xTYG3c7QpfARZNEglNEtUkBAmsYpo0dMhgCctu +vob4SYx331g/v4Ftb6rQsKahb+1QcIerTm4eE/85rwH9yt6ePds89zo7i/Lu11yGCRNun79OnOZ O3JKFBgYOH78eIG1cbcr/E0Z+Mws1wdLH+NOLO9NAnAE06TBg4TSwuebLVuEm3T//n1y6+3tzTws RU1iRs5HuT1Sd7vm9VvFahI52Do4gNJu+ORENKkYmgRyYZo0YMBACctu27ZVuEnMd2mbv8+7FDVJ +FvAldsjdbcr/M3raBILmvQImgRyYZrUt98ACcvu3LFNuEnZ2dnk1tfXl3lYiprEjJyPcnuk7nbN 67dKoEkHztxwcDClS48WNSk0yRKaBHJhmtSrTz8Jy367a4dwk7Kyssitn58f85AcBCVshctqk+Rd MzNyPsrtkbrbNa/fKuEmkd8iWYbk+sixF01iQ5NALkyTonr1lbDsd9/uFG5SZqbxS30qVaokcXDq YUbOR7k9Une7wuu32SRyUFJoeK6D2U00iQ1NArkwTeoR3UfCsgf27hJuUnp6utRxgQr8/f0Ffiqm Sa3rV1V2iKpKuJiGJlnHNEntUUAZQf4z6xbZW8KCh/ftFm4SlCVimtS+cTWVRucMJ87fRZOsI01S ewgARsJNunTpktNGAo4LCQkR+KmYJnVuGsSzdFlw5I/baBIAgEsQ0yTmYC1SWFiY5cPERN4LSrkI 1m6iSQAAqhF3nlRd/ArbtW1Dbk+eimfdd1lH/riFJgEAuARxrycF8ixtRadn2pLboz+d4rtP7lhO YXDnt/qQb0HLieYpIp04fwdNAgBwCWKa1KZ+gPgVhncyfkvIoaMnmfvMHfN0yx9x71tOZM1jXhtr ImtOqz8VFn8xFU0CAHAJYprUom4V8SuM7vaM+f7ewz+xppunWD60et+8HvN0yxn4Vs7aihhnUu6h SQAALkFMkx4Prix+hf0iOpLbHfuPM/eZO6zp3Nm495llWQ8tl+Wuzcw8XYy/rmWgSQAALkFMkxrU ELo6Ecvg6E7k9pu9RwXui5mN3GFuLR+ytsK3crtcuJmFJgEAuAQxTapbTejK4izD+nQhtxt3/SBw X/yPuA9tbsheKXdz0CQAAJcgpkm1qniJX+HI/t0sH36x/bDldPND1pzc6XwLCi/FnW7T9Xu5aBIA gEsQ06SgSkLfnl7a3c7MR5MAAFyCmCZV8SnLR917OQ/QJAAAl4DvqqDwXRUAAC4C3+nHQJMAANSH 7z43Q5MAAFQm0KTyCU0CAFANmsSCJgEAqAZNYkGTAABUw2pS1+4R6o5HdRdTo9EkAAB14DyJBedJ AACqQZNYZG7Sorgtsg8RAKCUmvtabHp6usAMaBKL/E0i/xvIPkqzGR+uVHT9AACyIAcrCk2ynyJN Ev7fwBFKrx8AQBbMk0Zokr3QJAAA+aFJ0ijVpPDwcO5PDx065OBw0SQQg/z6sX7ZuFMAFIUmSaP4 eZK8xwI0CcRg/kpk+YuHJoGToUnSOLtJVv8CS5kOH+ZTK9b8lhPRJBCD+TWz/GVj3WfusH5qWTKr VWMtBSAATZLGVZpEcQ4QFOc4Qu6jSSCGQJP4JlLWaiS8FIAANEkaFZ674/7nzdctNAmk4f4KWQ2J zeSgSSAZmiSNqzfJckE0CUQS/h2z/L0S3yTL9aNJYBOaJI0673FgHSbEnCfxrR+AS6BJdp0GCZ9m AQhAk6RxlSZRtl5P4ls/ABf3bzmU4CkRmgSyQ5OkUe294Fb/Jss8tPpmJwrP3YFoNp8xtvyR8Dv0 BJ7xAxCAJkmj2nUcpL1ojCYBQKmAJkmjTpNsvkHcwfUDAKgLTZJG/ia9GjNI0W+sUHr9AAByQZPs Vcq+qwIAoLRgvlsHTbILmgQAoAhSI39/fzTJLio0acycoxrj+mkDXUDT7gaDbvWsLpIGDwDgunCe JIGzmxTz3g80bQwSyZKOJpvQ0wZN3NudJA4fAMBVoUkSKNWkVmFtKEMhOQ0yTdaTCFEa8k/RS3Pj tHqNQUPr9UVaSqujdEtmTEpIird33GFhYYmJifYuBQDgNGiSBIo0iQQpKSGeosncOgNFzohomlnW QLVuHWY6STLeGOgiMtFd734q6RdZdwoAQH1okgTKNKnVk0lJpzNzC9krpSifiu4ashLjc3Z6rZ4m p06tnwpLjE+yd9zm8yTmDrkl981TzPfNMzN3rE60nC48J87MAEA8NEkCRZoUFtYmMeFnitaKGUGr Vq2SkhxqEmWtRqxocZeSMBEAQDw0SQKlmpSQ8EtWXtGj1T28Y7DchvHJPKprx7aJib/aO27hkFA8 LUGTAMBp0CQJFGpSWEJiYvLNbON6KMsbY5Po4lva9AITPbhPx9PxyjaJ+zQdX34sN8FaHGUCALug SRIo2KSTf6fSvDMWv+mB/DNlWISEw734Jsl1SoQTJgCwC5okgWKvJyXG7zt9U8wI3o7plZCkWpOs vgQlvEUAADHQJAmUa9KpfadvixnB22OjExR+Pcnqk3LmGtl8ls/yIQCASGiSBAo1qWVCQtL+M7fE jGDm2D5JiXZ/ZlZGOAECACWgSRIo9ZlZWq+jNDRN6fXGKzjQtIFvCT2ZJyHxjAO7IIXVDycBAMgI TZIA1wUHAFAEmiQBmgQAoAg0SQIFmxQ2buXc8VF6WmO6ELjBjdbo9QY9Rc36/Fvy08QVSBcAlGVo kgTKNun9ib16NK9BG3QUrTV+PpY2TpwzISqyeXDY+JXIEgCUYWiSBIo3KaJ5kHEpSmOapqcMhtbj V5Pzpxmff4cmAUAZhiZJ4IQm1TBdSYjUSGO8wp3pR63HrZw3Ifqt5XslZ0neN3Bb/awSAIAj0CQJ lG3SvAm9ureoYcyRgdZTlKb4UnfGu+SnlGu8qiR8tVYAAGnQJAmUfo9Dz+4tapIIGb9l1mDQ07Sm +FJ3er1B02a89CzZ/P4kStx3ILGmW66NsvW9SgAAAtAkCRRu0sQ+PZpXo0yvJ9EGSk8bjN8wazxf 0pPbA2duzVy+2/EmUSXj4cjFVW1esggAQCQ0SQKFX0+a0DuCNMl4GQdjkwy0+YUlvcFAH/rt1lvL v5XlPEnyPBSaBADKQJMkcMbrScYTJNP77orI0qan7gz6IlqjOfDbzZnLJL7NQaA3Al9qbjUtYk6t 8BVKAGAvNEkC5zSJeniS9Og9DmT1B8/cmPH5HnmbJHx+Y/PtDMKnVjhhAgDx0CQJlG3SnAk9I1vU ZL0XXEcZ3Ciyevrg77dnfCbD60loEgC4IDRJAmd8Zta4KlprmqY3nSqZPj9L6/f/dnvmMvlfT+J+ W5LV99GJv4833QGABGiSBIqfJ/VoXlNjerKueA6DzkBpadMJ06HT197C1RwAoIxCkyRQ+vWkaB1F M9dgNb27wVgnA025kTLpNXoNLfm94AAALg5NkgDfVQEAoAg0SQI0CQBAEWiSBGgSAIAi0CQJVGjS mDlHNcb10wa6gKbdDQbd6lldJA0eAMB1oUkSOLtJMe/9YHrLA02ypKMNlOkaeHFvd5I4fAAAV4Um SaBUk1qFtaEMheQ0yDTZeHU7SkP+KXppbpxWrzFoaL2+SEtpdZRuyYxJCUnxsu6UHfg+BouPxwKA g9AkCRRpEglSUkK88b3fxk8jaYzvBmeWNVCtW4eZTpKMNwa6iEx017ufSvpF1p16xGZa0CQAUAia JIEyTWr1ZFLS6czcQvZKKcqnorvGdNE7Pa3X6mly6tT6qbDE+CS7Bs130SDulyFZPuSbIuZCD6yf 8k0EADBDkyRQpElhYW0SE35+eD0hG1q1apWUZF+TKGsXAbLrKydsfv2S8BpwFgUANqFJEijVpISE X7Lyih6t7uEdg+U2jE/mUV07tk1M/NXecUtoktXF+S7hiiYBgIPQJAkUalJYQmJi8s1s05dUWN6Y vqqi+JY2vcBED+7T8XS83U2iOCkS/zVIDPFNstyomC9kAgCg0CRJFGzSyb9Tad4Zi9/0QP6ZMixC 2pHd3iaJjJbAeRLfGCQMHgDKPDRJAsVeT0qM33f6ppgRvB3TKyFJzSZRol9P4huDhMEDQJmHJkmg XJNO7Tt9W8wI3h4bnWD/60kMvqfmBL7lz3Jxc9JEvu+O4n9HHwAAC5okgUJNapmQkLT/zC0xI5g5 tk9SomqfmQUAUAiaJIFSn5ml9TpKQ9OUXm+8ggNNG/iW0JN5EhLPOLALAACuCE2SANcFBwBQBJok AZoEAKAINEkCNAkAQBFokgRoEgCAItAkCdAkAABFoEkSoEkAAIpAkyRAkwAAFIEmSYAmAQAoAk2S AE0CAFAEmiQBmgQAoAgJTarTcqlThubS0CQAAPlJaNLmE7ucMrTSB00CAHAImiQjNAkAwCEu0qQv ZgfKtaqRs+84c+WW0CQAAIe4QpNkbAbDshyKrpwFTQIAcIjqTZK9GQymHIqunAtNAgBwCJokeeVc aBIAgEPKapMoUzkUXTl3IpoEAOAQNEnyyrkT0SQAAIegSZJXzp2IJgEAOKTUNMmTGjaVSviY+idf 7JrRJACAUgZNkgZNAgCQH5okDZoEACA/V28SSdEbVB3O5K0LbMfJjiZZbEXMmik0CQBACa7eJDOc JwEAlHlokjRoEgCA/NAkadAkAAD5lZom2Q9NAgAoZdAkySvnTkSTAAAcUlabhGuwAgCUPqo3iVKm HOZsKLpyFjQJAMAhrtAkCt8ziyYBAFAu06SyAU0CAHAImiQjNAkAwCFokozQJAAAh6BJMpLepFdj BpFbxQcIAODy7G1SnZZLnTKu0kdik/z9/RUfGgBA6YHzJFlIbBIAAIiHJomEJgEAKA5NEglNAgBQ HJokEpoEAKA4NEkkNAkAQHFokkhoEgCA4tAkkdAkAADFoUkioUkAAIrDZ2a5Plj6GHcimgQAoDhW k8jBVt3xqG745EQ0CQBAHWgSC5oEAKAaVpNeiJnv4ApjR3VydEyqQpMAAFQj73nSyrVH0SQAAJAI TWJBkwAAVIMmsaBJAACqQZNY0CQAANWgSSxoEgCAatAkFjQJAEA1aBILmgQAoBo0iQVNAgBQDZrE giY526K4LWoPAQCc5NWYQcIzoEksaJKzkSbNfS1W7VEAgOLS09P9/f3JrcA8aBILmuRsaBJAOTHj w5XkP3Y0yS5okrOhSQDlBJokAZrkbGgSQDmBJkkgf5PCw8NZUw4dOsRMJHfMMzD3bSIzs+bkTild 0CSAcgJNkkCpJglkw94msWZGkwCgVECTJHBSkwTOk8znVVZLw/2puUmWJ2SstZnPzCjOWZrNjdqV TAnQJIByQkKT8J1+KjeJlRCrheA+9Wdz5ZRgloQ3iiYBgCycf55UBij+epJAhyjFmuTgRhWFJgGU E2iSBC5xnmTG1ySqZEi4z/sJrFzCRhWFJgGUE2iSBC7RJOE3RPC98mT1dMfe+86HJgGUE2iSBKWp SXzLytskvJ4EALJAkyRwoffdcZeibH0+ifssnMgOCWwUTQIAWUhoUtfuEU4Zmuu6mBqN6zg4FZoE UE7gPEkCXFvI2dAkgHICTZIATXI2NAmgnECTJECTnI006dWYQfhmP4DyAE2yF5qkAn9/f7WHAABO gibZBU1yNpwhAZQrwl9/jiaxoEnORprUMbyn2qMAADscP7Rn3KhhEhZcsXYjmmQXNMnZmCa1qVNR 7YEAgCjxV/JIk/4bM1zCsp/GrUeT7IImORuaBFC6ME2aNm6EhGU/WrEOTbILmuRsaBJA6cI0afqk kRKWXfjZF2iSXdAkZ0OTAEoXpkkzpoyWsOzcJWvQJLugSc6GJgGULkyTZk+LkbDs7I/i0CS7KP6d fpTgpVFlZ/VLzblD4s7jNGgSQOnCNEna5VdmfLgSTbKLk64LbtcMkqm4afGsNok7MJEVt/n97srs BEA5gvMkZ3Kh76rgO7MRPhazVitmKdamLR/a/HJ0q6MV2HEuGZtks1VoEoDj8HqSM7nKd/rZ+0V/ wmsTOTbhJgkMzOY+CuA2idmuwNgENmcm/GcoLfwAQFl7313Xju0E5v/++Enzfbzvzl6Kv54k8itf uRMp/gOlXE1iDcBmD4SbJJJcTeJOlzf8AMCw+vmkiC7trc68/4cTlg/x+SR7ucR5kpnw3+tFrk3p JnFHaxdWk7hPGAqPQWB35A0/ADD4ruPQK7wDa8q3h35kTcF1HOzlEk2y+eq9wCZUOU8S/hMQxm0S awbx27WrSaz1U8gSgDhMk6xe765/xLPm+9v3H+POgOvd2ct1myTwUxmbZHWivKNlsWySZQglbNfe 8yS+MYsZNkC5xTRpzIvPW/3p4OhO5PabvUet/nT1l1+hSXZxoffdUdb+Xi8cANY88jbJ6hgExlYa myR+2ADlFtOkEcOek7Dsuo2b0SS74DoONs6TZGduEitIrE3L2CRKavgBgHrYpGFDh0hYduOmr9Ek u5T3Jok8c5IRruMAULowTXpusFBa+Gz+ZguaZJfy3iTnQ5MAShemSQMHDpSw7NatW9Eku6BJzoYm AZQuTJP69hsgYdmdO7ahSXZBk5wNTQIoXZgm9ezTT8Kye3btQJPsgiY5G5oEULowTYrs2VfCsvv2 7EST7IImORvTJLVHAQB2IE0Kj+otYcFD3+1Gk+yCJjkbaZLaQwAA50GT7IImAQCoBk1iQZMAAFSD JrGgSQAAqkGTWNAkAADVoEksaBIAgGrQJBY0CQBANWgSC5oEAKAaNIkFTQIAUA2axIImAQCoBk1i QZMAAFSDJrGgSQAAqkGTWNAkAADVoEksaBIAgGrQJBY0CQBANWgSC5oEAKAaNIkFTQIAUA2axIIm AQCoBk1iQZMAAFSDJrGgSQAAqkGTWNAkAADVoEksaBKAi1oUt0XtIcjj1ZhBAj8tM7vJR3j30SQW NAnARZGD9bhRw9QehaNWrN1os0llYDf52Nx9NIkFTQJwUeRg/d+Y4WqPwlGfxq232aQysJt8bO4+ msSCJgG4KHKwnjZuhNqjcNRHK9bZbFIZ2E0+NncfTWJBkwBcFDlYT580Uu1ROGrhZ1/YbFIZ2E0+ NncfTWJBkwBcFDlYz5gyWu1ROGrukjU2m1QGdpOPzd1Hk1jQJAAXRQ7Ws6fFqD0KR83+KM5mk8rA bvKxuftoEguaBOCiyMF67muxao/CUTM+XGmzSWVgN/nY3H00iQVNAnBRjpxAPN22jfn+z6fiZRqR FIqeJzltN5kNSdgEzpPshSYBuCjJL7R0bN+W3B4/cYp1XxXKvZ7E2jXyULndlPzHiNeT7IUmAbgo aW9I69qxHbn9/vhJq1PM9/lms5woMLN4Cr3vTmBI5h2hxO0Ld36BPwp7x4n33dkLTQJwUdI+uBPR pT253f/DCatTmPvMQ+50qxO50+2i0OeTxIzHrh3nLiU8m0j4fJK90CQAFyXtAge9wjuQ228P/Wh1 is37Yma2i0LXcRAzHrt2nLuUc3YfTWJBkwBclLQLwfWPeJbcbt9/zOoU4ftmwjPbRaHr3QmPx3J3 xOw4949LYHG74Hp39kKTAFwUOViPefF5e5caHN2J3H6z96jVKWLu21zQLqu//Mpmk2TZTe6PpO24 zT8Ku9jcfTSJBU0CcFHkYD1i2HMSFny+dxdy+9XuH1j3BX7Ems3mesRbt3GzzSY5vpvMQ9ZQxews d79s/lHYxebuo0ksaBKAiyIH6xeGDpG27PC+Xc331+/83up0gR8x05kp3Pt22bDpa5tNcsJuCuwL 345zpyix+2gSC5oE4KLIwXrokMHyrnNk/27k9ovth+VdrYBNX39js0my76brsLn7aBILmgTgosjB etDAgfKuM2ZQd3Ibt+WgvKsVsGXrVptNkn03XYfN3UeTWNAkABdFDtb9+w9QexSO2r59m80mlYHd 5GNz99EkFjQJwEWRg3Xvvv3VHoWjdu/cbrNJZWA3+djcfTSJBU0CcFHkYB3du5/ao3DU3t07bDap DOwmH5u7jyaxoEkALoocrCOi+6g9Ckft37vLZpPKwG7ysbn7aBILmgTgosjBultkb7VH4ajD+3bb bFIZ2E0+NncfTWJBkwBcFDlYqz0EedhsktNGogo0yS5oEgCAalhNqtNyqbrjcQVoEgCAOlhN2nxi l7rjcVloEgCA4tAkkdAkAADFOaFJX8wOlGtVI2ffcebKLaFJAACKU7pJMjaDYVkORVfOgiYBAChO 0SbJ3gwGUw5FV86FJgEAKA5NsrpyLjQJAEBxpbFJlKkciq6cOxFNAgBQHJpkdeXciSWadPj773Nz spiHaBIAgFzQJKsr50581CSie9dn9+zdZ84SAADIKO329QlTXv7ie5kvsyQ2G57UsKlUwsfUP/li 16x+k3bu3F3wIE+hEQAAlFuFD/KzMtLQJMuVcyeWaBLRs0fX5Z8tcXOvUNHbV6FxAACUN+QMidy+ 9PL0lQc2yb7ystwkynS2RG4XvDuDlMnDw1Oh0QAAlB+TX3md3Mp+hsSwkQ2SojeoOpzJWxfYjpMd TbLYipg1U+KbxOjY/mlR4wAAAFsUvcBdGT9PcrJ5s423wldAAgAAPmiSnNAkAABHoElyQpMAABxR Zj+fpAo0CQDAEWiSnNAkAABHlM1rsKoFTQIAcJAS5TAflhVdOQuaBABQFpS175lVC5oEAAAMNAkA AFwFmgQAAK4CTQIAAFfhKk06l5ao7jAAAEB1rtIknCcBAACaBAAArgJNAgAAV4EmqWbP2r/UHsIj PUc9rvYQAADQJPWQJsWO6qT2KIxWrj2KJgGAK0CTVIMmAQCwoEmqQZMAAFjQJNWgSQAALGgSR07O iXY30swPaa3P035NZgbUCKYLT9/7dWba7avGPzH30EptNgZV9eLMb1Sxzcna1X1sbAdNAgBgQZM4 ihtj6oqnPuPrGyc+yNXVD+jypffVgVcu3HCvv65Oo+CCa2tzvCcFBHiXnN9WhyyhSQAALGgSB6sx GTk/dbxxT+P11D7/y1HX7+gqNPrmsUaNNbzzi1mnCZoEAMDyf1W97K0KZW5kc3RyZWFtCmVuZG9i ago1NSAwIG9iago8PC9SMTEKMTEgMCBSL1I4CjggMCBSPj4KZW5kb2JqCjYzIDAgb2JqCjw8L1I2 Mgo2MiAwIFIvUjYxCjYxIDAgUj4+CmVuZG9iago2MiAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9D b2xvclNwYWNlL0RldmljZVJHQgovV2lkdGggNDcxCi9IZWlnaHQgMzY4Ci9CaXRzUGVyQ29tcG9u ZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0Nv bHVtbnMgNDcxCi9Db2xvcnMgMz4+L0xlbmd0aCAxMTIzOD4+c3RyZWFtCnic7d0JXBTl48fxWRZ2 l1NRBG8ERM37PlDxRBBM8b5BFFAzNM/qZ5ZaHmllSoW3aXmbV5IaHUZeqZWdf8u8b/PCA5DzPzC4 DXPt7Ozx7C7fd68Xzc7OPPvMIB+GZQFVYWEhxRIX2ZwCAACLWffFT+ybKn2Fk/q2evw0f/600e6u WpXahcTcAAAcWWF+7pOsp/97Z62HVp286ySzsqTC9CXwG0nDy3u6FWQ/zM/KKMjOIDpVAAAHpHLW qpx1atdyD26ce3PzKeaiuKjCdILffWVMfnZGQdYDOsGk5wkAYKNWpv5q4giJUY3pt86eftevXFi6 9w86xEUVHty96Yevjc69dxEJBgAQs2r/7z16D2xWP0jxCD//ee7LvdsTejakl7Ny8l7b+MvWr06r urSqt2VBYn7Wg5y7F802WQAAh7P6wJ8zZkzPunhM8QiutdotWrQ4PqI+VVzhggLqxTU/FVV487wx 2Tf/ryA323yzBXujaVFlxBQd9X+3Pn0rM4e+7ewcNNqvbSeNll7WrwRyuO8gIGDNl2emTZ3y5Nxh xSO4B3V45933xvSox9zMfJqXtO5XVfP6gfveS3xy+SfO1smHMpy0rgYH9cy/OzykstpJpXhaIEHl 3rJCaEy56n5O9I3C7Px76Tc/X5OVa4FH0rSsFjvdlToxq+uEJv0Dm7rV8x06x0t3ZffoPsm/ZxVS Hi/EBjbVmOmxXOr7Dn7Dy/Xhw30Tb9/I0q92qjLWv1dXddY317auoI9R5dnCu1U/r5q1nV0oKvdO 9uVv7p/c++RRycFb78zYCM47yFzvCzDG2rS/p0x+6dHfh9grf79497eLd+mFoZ3r6FduPvQ3/bZR rYoNa1Vkb+xZp/N7S94fHVayJV3huJTTRRXeuzj+8aVTnMd76VvvG5mG39Xe90+8P6i6TqNWckwg zcm3fJ8P/So/+HXh8Df23dHW6dJ7aPMzKcltOleubYlXEmbdnbPl1k3KuVGdCtEdI9uMfdmt6GM+ 7oaPp7+OUlHa9q18qjqb5ZGcNU0WBYT4Z6dPWvLt5X6+TsUrvTx6Lq9WS3v5o6j4LfdeGhPbadg4 d+qXI4teS/nqZmHDkdMXT2xaeOKnTxe75xVY+8zYCPY7qI253hdghHVfn508aWLGma/ZK7emn5v1 yQl64c2RrQeHBgmu0StXr9uSpcviugUzN+kKx6/6vajCu9+Oe3zxJOfxjuieD+/RQ+VURFX0v2eL pf+/4JVx/QPuo8IWoWlRI/51D6e/PogeeMJJV9tNlZuTe/VegW+Ad68WYS3G/c+NOn/n6Fm3xl3d PFyo7IsPf1p58+c/8pnXfzt5uzdP8G3SVueqpp5efnR6zc0fT9P5KqLycG0Y69usg5uXG5VzMeN4 8s3f/ilwaeOfSA/4045xL5yhuk5YPt+bM5n8n6+tn/Mws3h0TZOqsXPLaW/c2Zz0713O9ada0+y9 oPa1ihbz7mad33MrfW9WdiFnMEoX4hn7cnX1j+8NG+/VuHJ7LxXlEVYr9kXX3MNv9Rn7g7ry8Lmf D2muPftWt/Gp94Kr66q6qrWtPpia1OLptxPXfn+xW+WWys+MxAwFz0yh5Mksxcm55uDK7SM9KtLH k5N748j9H7fcv3izQOLdoWFO+4W7J697NGmvLbnsOX9rw7R7D/OLZuT1fK2YeF3B79e37Cs/7JWS d1CmJqRFjcCmpkwVlPj4m3OTkibc/+NL9srtRy7O3vwzszx7aLOit6ybA5l/ac94N+ixNPnDUV1L 0kxXOHHtmaIK71wQ8+jCCc7j/eDRT06F589IjPa/gwpbhEuDanGLvF3pr8evnf3xeOa9M87nj/5x 9lE2papRp3vrCbPcKerJkUW7d6ce+afyc9NWJ7V3v7pzzPXLt91UGl2b92u39X/6w2uzZn+b3X/N svh6N/bEX7pww0Plom25OLh9cN5fyUte3/BNhn+XmJ5epza3DO703Hh6QPrid1z9yCqNtE01SfPq FN2MPZJZqdvStJlttH+92/tEXl4znZO61qt1+7SnTr82dNye5j1rRJVnPR/l5FuudeiDLzfMOJhZ NWLBste6qk+8eij9l+ounOesdKo2qxq0rXDpo97v/ZoZU8/dq3VycEjNjF0jhi38JbB++/EfLq/v dmZZnwHfUW5NvTX1At1rVIgMenFSpYydU4a/HdI1tNv4xYrOjMQMNcJnpqZn+bZiJ5P3/hq9yFt3 94c3R8z7KsO7YY+BI5o83Z8SWMHdU2wEXduAcUWz/ffzV3Ye/Db9dGH1WV+/He55KSX6i3u5HT2c 6c89wSE1Mg8mDFnsseKrJVVK3kE1W7YzbaqgyIZDF5JeGHfn1/2c9TuPX3lz+++clbMGNuzXtgZn pU/jnskfLY/pHMDczHyaP3792aIKf/bW8Ifnf+BsfbLcoIieESWx1beXneTihXnTE3pXv6lzQYUt Qe1SfXB+x2ENq+q/zH50+8Dkm39cobTtAl+c7UFdWDuoz5Y7ziH+Wq3PyNGLX/C7s/GVqSuimzcP Tni/otvFtYN6b3/g0rJOdOIHs2rc3fzKSym9WzarG7+0ovvljwf32nTHuWllFw+q4Nb9vBotn58w d65n0Qf5mIdVy0W16NJ48puVS266V60zbdzrA8pdTZk0cUN462r1B22sFZj9TVLY/N/y2tXUNarj WY/9HYSCvBM/Pvhbrfbw6DpixcLAJ/tnDJ/buZ1ndefSJfDqXyUhsdLtDVPGftS5Q+uQsct8PM6u HNhv50Ndu4AuEz5a5ON0anb32JuVPJsGeYV4qyhdx4AJr3nmH5kZ8UJusO/w0BHqUOPPTCPXohAL zjC0VZuxywTOTLMO8TOTfQRPZhPXUnXTNPcft6Cc+tdVE2b8dPd+ZQ31NDv3RkZh4/YdR85YJjxC 666Nk+jZFn2+2Z+pC6nmrK35YsLcEd7XViRNWNulXbMO45b7lru+ZWTk2ofdVu55txbzHqnVblry yhqmTBUU+eS7SxPGJ9z+eR//rt0nr8/f9Zf+5v/61o1uVZW/mW+zXh+mrBrZyZ+5SVd4wsYLRRXe NKv/g7NHOFv/XnV0z549n+W3pMOq4v/Ya+ZOiQv3uahzcTLfkQJLQeFvZ3K+zwuq0W7w6KR+gXRz Hu1dNG1++6DOjWYs9KJOzekee6WiZ5C3U3P/ri1efcun4NjMiHGa5uEvLVhUjvNRV3j8tfCx6ubh U4ru+nFO95jLPp61y6maVlLlPqEeazpGvP12hZLseoQ17BT6Cj3+s5vB1WrEbG8ScC91Qu+fK3RL mj233K2U+EHJmX5e9Ss6dayu0pU8lpNLQEytbn3LVfH579Ny4Q+zwhKyAz1611CV+j6DqoK2746m DXK+finyZN3Xp40PKzw+ZchLX1ao5RFcrdmoN1N8i66FB//j4RYa5FTDhVKV798gaYp7xs5Jvd9Q +Xv0DFBd+dv4M/OcV69WMQGCM2wQMfP9ReUFzkyH8IWLKgqezOc8Inwo1j99V/e2C2qFtfIovpFz +9j1/QsOH/83y7VDv3cXC4/QvOfUhcx5jvvXzyOoorqFb1W/kTsaBNz8bEyfM/WnTp86SHPmreFx mzV1I+d8vLgm8x6pHTFrxWIfk6YKSmw+ej1h7LgrJ/bw79p/+tbSL87pb06KDOrZ1I+/WY3WfVat WD40pCTQWTn5U3f+W1Thza/TFT7K2fq3KnGRPSNV6pLs8nJcci08d3JceCVU2IJysgr+/rfg+uO8 jIpxLyVPqJab/mrEi66to15asMCr6Iqv32kXXUiQOqhKbMPxCa53Nk3ot8ClbttpS1ZV9/jrg+j+ O6/nswZzbty47dT3V9XwuPTx4OifnHUhgepAbfE92o71pi/QZ7dHw84dX2HdDHb2DZjVMKaH6rtJ c/8cNW9847/f6j7hwP2WtXR1aqobuj37uHdpEjjxQx/X28fmxLx94PIjr17JBxfVZwap5tEzWF2h 9D8TVeUp9eL76U4u3OI6dWTDjH3xPZaep9pV0zQMrNB08Gd16mtOzwlbeSYr8jm1r5OTpvGyJr2b Zn87fsjMo8FBbl1qq8vlGH9m6nWYsTSlquAMA9pMXbq6Jv/MuDSoNWGFr+DJrOcZFexU6rNdfsGx P13/9AjybzMiKTHU89Hn62cvqOvbKFBshOaRbyx/2/vZeQ4NUtdwcVIHzW80tEPmnrGrvRZO66L7 YUb3//2Q1fa57hOXL/IruRZuM2XZan8TpwrG23SErvDYqyd2c9Z/cfo2O8EMOsSRTX05K6u3jl61 YsWw9v9VeMpnt4sqvOWNgUIVHhUZGflffJ04OS75f/G18CVU2CK0rQL6hz/9LfX+hTNPHqqyAya1 HNFTd3rW8Bf2VGncc9Zy+tKVenJkwdL1B5vUrdOw93v+we7nP3p+/KdXmgSV6xW7umP3Og++nPXB 9kPOThUqPdelWefAv1Lmn8/WdhyxIjSsXvbJd5etTW1UO6Be2045R1c/UnWoN22+pz67jbqEvsy6 WcfFVxPgFru+QZVrf9yu1sD98+nPv3ze06Opj0v7ALWn/mNb0zQwaVlF3bUdLwzZn1ExbNTSIWH0 V17MIJ496jj7cp64cqrmNnxzg5rFy+cWx4xcR1Xzqufj3Km6k7ZcH5+EqbXyj29auNBNkx0YOKDW gHivwmPvDxv7xQNNSN0OidMjCxWcmQbtJyV/VE14hhX6xQqdmRwX17YpDboJnkynZkGsg9K28O/Z 4u6h3d/9fPNO5TFj34qrdH97Ut+3/Fv7hIenNBQcQdVp/PK3K7LPs7oopt6JKbU9btymqvg+2pwU PfdWBc/GNbu+uHRh+ZItvfvFrjRpqqDIpiPXEhITr54sVeEvfr79/rMEvxRZ9G039s3IZqVCXL1V 9KqVK4e1r8bczKQrvONmcYVnD8r4h1fhyqUrXPIE8X9PSTDXxHMmj4rwvYwKW4RL3arR0139/L09 i7+Uz7/38JfNb89MOZ6pCXkubHJRa/5vQ/IfLYdF16/oTGWd/2f7mzNSjhdU8Gzu5xISVP6xX3zt qIiGVVzpImVfSj9/cNXW1Av1WnoFO3tcqTi69vM9G1Vxo7LP3flmfuqWX9wahkfMmPcsu57hTbp0 nM66WY+ug5MqaEHjQW3pL/1vrOszauWFBkFutatpWrO/NUepXfzjtN2G1PNzoZ6cO3/0aPmwkRVK DcI5QienwLcaDm6vobKPvdL9taNP2vjr6gW41HdVUYWq+5ktHnQZ1bl9o0o6isr99+Efuza89dGu q/l1a7nXqNJo5IQZ7krOjK5Lt4RK3cVm6P3Ul3dmgt0DnD2uVhI7mezD0emCBhY0690gmD7Q/KdX 07fNf2396cfNgj3C6pTPFHx3tI/sNYNznove8c7NVzYND6SXLn0UmfDptSaBbsF1ug59nb2liVMF JTYevpqYkHitdIVTf769pDi7kyODooqby1+jV61V9MpVK4d3qM7cpCs8eduNogpvmzM44x/uz+T9 6hcbGRXJf0a4ZOHZ7TmT43r6XsJ35ywl9+mm7x/99Tj/SV7xS6mcnMp7agIrab39ur64ZH65oo/J 0dfd1Pce5GTk0A108qvoVqeCuqKvNsTHKet+9sEzmX/eyXlQ9FoyVQVvbUBFTe3yLgHVXdwePP3y rye/3cnNyC2kP+Tr13RvW9m5slfu2v0Pi1+O6hnxnNYvL/OdVNZNddEPDlQcv9hfc3JRn7j0AtfW vpq2wRofznu+sOCnXzIOXHl6L7coJvWqqq9fevqQPQhHYeHZX++tOpdbQFE+1Twb+2g7BTq7F4e9 IDfv57NZJ65lX32S/5S+W62u4OFSw0dTQatuGKjxV+UoPDMVqdPiM/TMEDozlVy0GaIn04d9BZKf f+qvx8euPL36pCCfvjjWuVT31dX0dAmpo9E8EBmhUu7H+0uf56KDLzh58s7Wa0UvMXOv5NnaTxNS 28U7t9R7xNSpgvE+PXwlMSGBU+G/bzw5e/MJvcAOLh1i+m1wZfc6VdzZGxdXeNWIDiWvnaArPGnr taIKb587JOMct8LLTxZW8Cl6dpmu8LO3zCLFXnn30p8jW3tqcS1sIYUFF6/nXMgoyC6gnr3oU+Xu 6dwgsHPI1Dc9nr2GIVBHZeZSRa+HdXLy9XFpXEmtVRUFLiMj78ztvPu5hcxLZbU6dS1fTYCnSq0q fJiRe+ZW3r2SvVRV/LSNvQv/+CfnRk5hPuXU8jmdnyr/F/ZNZ62m7rQ6vbtl7o4ZvuBnf/pCuKpb qK+K/47PeZL7+/W82znFD6py0qkLcvLoyRcPIvDJujDncc6xqwV0TAsplW8NXcty+n9ldIgLLt/O ufCwMDu/sPjwVR6ezvWquPhpTDozkjMUOjMVnZylTib7aAqznuSdvZ13M6swt3gztcaZ/oqhtrv4 u8O94PdzrPNccooKM+/n/HArPzOv6IZHZV1HHyengtLvEROnCsb79PsrifHx109xnxeWr2rL6JWr V4/o+F+FJ26+WlzhN4c+PHecs3VOXkF+Ae/F9jz0R4zWWa3Ce9fKtCG1J8591hqvyIauQoEzH5fn qick+7hT+Vc2zY6fd6rQtW0VbfO6rjVs8AfVrHxmoCz5JP3y2PgxJlZ4xeo1I0OZb4YUVThp02Xm 9cLDHp7jvl4YbN3Txwv33C/++tQrqpF7ZUu3Jj9nR+qtw9mUs6u2UTVdZV/3btXUzrb52dfKZwbK jE/SL4V0CW8YVE3xCL+fu3b024MjQ1mvF950sbjC84Y/4v3UBti6gtyfzmRdL/r61LmNFVpTkP/X uSfnnhTm0l9lu2paB+l8bbTBVj8zUJasOPiX4Y0kjQ2vq1+mK/zCp8U/tbFz/khUGADAyop+gvmT c6I/OwcAAJb2wpbi1wv3bVGJ9EwAAMqiXT/+q+oY0jb9yLEHd24yqwrVWrJzAgBwbKr8p8zCrasX EyZMRoUBAKwKFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYA IAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJ FQYAIMkiFQ4LC6PfpqWlcVbq1zAbMNibia23KPM+qOCxAwCIsdS1MCdG/AQzN8WWObtYDpEHBQDQ s3aF+ZeK+jViV5FiG8i/oNavkRhc7BD4j6ifiZwDNGoyAFAG2VyFKaGnMvTrxZ7roEQuqPnjSwwu OCZ/cMHRBA9QwaccAChrzFDhE5ey2Ddb+7syC+ziCD4dwV8jeHkr3TWDG8i81hZ7UOnnTKQPUOZk OCcQAByGvocSzFNhwUdSUGH2GkqoZTK/3hd7goISv/wUfFDpwRVX2OBkAMABiLWRwxYrTIm3THBZ 5uWnwQMx6qJbzgGaMhkAsHfkK0wZX1ijXkdhlgrLD6jMwVFhAGDYboX16xnSL2/grJTYnirdPuk1 yiZjbIUVTAYAHIZNVNgscP0IAPYIFQYAIMlxKgwAYI9QYQAAklBhAACSUGEAAJJQYQAAklBhAACS UGEAAJJQYQAAklBhAACSUGEAAJJQYQAAklBhAACSUOGy653V20lPAaBMmxY/kEKFyzK6wqFhvUjP AsC+paftGxc3XMGOy9dtRIXLOqbC4U2rkp4IgL06ePo6XeGJCSMV7Lts1SeocFmHCgOYiKnw1PGx CvZ9N2U9KlzWocIAJmIq/GpSnIJ9FySvQ4XLOn2FW7ZsSd88deqUhR6IHp8/uOBKsd0pS07Ppphy sMy+0rvLP+2OzcTzrN+RqfAbk8coGGfOkjU2WmGxv2os8YcypdfbESv/0SaDFeasV/wPtyxU2FyT NOUky9kRFTYdv8LzpicqGGfm4pU2WmFK6O8TG/wr9BK7gBh+hdkfyfoLK/Zd+psU68Oevxf741xm gsXG56wUm5jYpwr9A/HH5zy02PwFGXVyBDeQPmr+cUmcEMG7OBPgnA3+kfLvMmW2xo5AyTjnYsPy R+DMSvAwDU5YbGKcf7rProXjDU6eb86S1fZXYYm/Jy92FSm2gbF/1l5wcImh+HtxZiLnAI2ajILr aE6FKUNJFfuHy/mYp3gfeAYrLFYc/jSktxS8KTgrzmQkxpfeXnoa0ptJjENJvi8UT0BOhRU8KH+2 Mo9X4p8Nn/T4ghcQgp8ejPpHZfDf87PnhUfr13Tu0FbiKA4dPq5fXpC81gErTAk9laFfL/ZcByVy Qc0fX2b7BPeSmIngARo7GdMrbPBfp8RNiY8iS1RYbGPOvfwLYbEZyjkQzvYSE5YYR/6xyFw2agJi p12szopnK3MDBRWWM4LYqZBzmAYnJljhaeNHsaca1jlE8BDSDh1l33wn5WPbrTBVujiCT0fw10hc k4p1zeAGMissZy/B61yJA1QwGWNZocJyEiy4u8FpCM6Ec+XL/6gTm6TE4evxpyfz5HB2kXksMpfF zqHBfPDPm/QEjJqt4PFKnxPKhNMu/UCKK8yfA/8cPnu9cAxVWlT3Dpw1qV8d5qxZtmqDo1WYvYYS apnMr/fFnqCgRMIn9uSD9OCKKyw9GaPYaYUp3kejnArz95L5WGLE5iB4RNLXVmLj2FqFFcxW5iWn 6FnmkT7t0qdCwbUw/9EFKzwubgR/qn0jQvXLuw6k8zdYvu5Tx6wwJd4ywWWZl59yZisxDn+lKdfC 0pORzxIV5m9jYoXlpNPgTbFhBScvuKMgBefKYDVkdk3iKMTOgNj7gr+Z2JiKZ2vGChs7Q2WHaWyF x8QME5zqoKjO9NttqYcE712zYZNNV5gyvrBGvY7CvBWWeCCJoeQ8wSJ/MpZ4Xlh/k3MvVToH/A2M rTB7ZP5Q/OmxN2PvLh1B6XnyH0uM9BzExuGfLsFxxL4WFpykJSosdoDKZsu5S+wdwd+dz+Bpp0RO hZw1MicmVuGYYUMkZi5mw6YtdllhinXhSQlFirNe4qt4iecNpNcom4yxFTZ2MqZUWP4ubAaDJT/B YBRlX8hb4rQru5i1U4LnkKnw0MGDFAy4ees2W6+wWZj9q3hHggrbF/mXjYL7osImkqjwwAEDFAy4 fccOVLisw++RADARU+Hovv0V7Lt712dlosIgARUGMBFT4ajefRXsm7p3Fypc1uG3vAOYjq5weFQf BTseTN2DCpd1+ItHAGShwgAA5KHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIA ACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwmUXfr8wAFn4/cJlHf7WBoDp0tP2jYsb rmDH5es2osJlHf7uHICJmL87NzFhpIJ9l636BBUu61BhABMxFZ46PlbBvu+mrEeFyzpUGMBETIVf TYpTsO+C5HWocFkns8ItW7ak3546dcoqkzIbY6dtp4cJZDEVfmPyGAX7zlmyBhWWEhYWRr9NS0uz 2o5m2d0otllhcz0cKgxWwFR43vREBfvOXLwSFZYiv4acLc2YUUsXmV1hpkEMpkTsNRQrT/wt9dgh kxk1zmhi02DuEtxAbFbsHSU2Nrg987jSxy7/0Y0dgcInBtv27Fo4XsG+c5asRoVF0fmj2yeRV/0y s8AQvIvdUP7GnO3Ze3E25k+GU2cFydZXWKxT/J5Kt9XYCgtuI5YtY4vP3lHO4RissFHnROzRZc5f 4lMI2JRnzwuP1q/p3KGtxPaHDh/XLy9IXosKi5JfYUrkWpjipVN6WeZmNlJhSqQLyios8dAS4xic lVHlFVvmXwjLPCcyM40K2zumwtPGj2KvDOscIrhx2qGj7JvvpHyMCgvTB86UCstPqszdKd5Vs+lH qqDClGSIDXaKvyN/NIMVFvyiXnoci1bYqEcXnL/M50zABj17vXAMZ31U9w6cNalfHeasWbZqAyos jP1UAMMsGXWYClPiIVbwvDB/NOkKy3m218TyUsZXWMGjy7wWNnj2gCymwuPiRvDv6hsRql/edSCd v8HydZ+iwgI4gTNjRu20wgaDK5EY/l5iDF45yqmwxDgKJmnsZyZlj44K2zumwmNihgneOyiqM/12 W+ohwXvXbNiECguQU2GJZ3LFdpG5LH2X4Bo5d4mR8xoJwV4IbsasNOoJTcHnFqjS15VyvlqXfo5C bHzpFEp0VuKB5D865y6xE8vfHWwKU+GYYUMU7Lth0xZUmEvwGlMixEZ9R469GX+l9E2xAcXmKRN+ ds5yl5y4mC0jmAoPHTxIwb6bt25Dhe2PeV9BXGYrbIXLTFS4jGAqPHDAAAX7bt+xAxW2M2b/IY4y W2EAc2EqHN23v4J9d+/6DBUu61BhABMxFY7q3VfBvql7d6HCZR1+yzuA6egKh0f1UbDjwdQ9qHBZ h794BEAWKgwAQB4qDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQJJV K2zKRAEAHJWVKgwAAIqhwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIA ACShwgAAJKHCAAAkmVThd1Zvt/gEAQDs3LT4gRL3mlrh0LBe5pooAIDNSk/bNzZuuIIdV6zbaPEK /3vrhoKZAQDYi0p+VegKvxg/UsG+H6z+BBUGADAJU+HJY2MV7LtkxXpUGADAJEyFZ0wYpWDfRR9+ jAoDAJiEqfDMiaMV7Dtv2VpUGADAJEyFZ0+OV7Dv7CWrUWEAAJMwFZ43PVHBvjMXr7RGhd+fOZa+ +dK8Fcx6/k16mbOSTeIuzjZ60hsTJOdYAMC+2MG1sJwKs3eU3l4QextbLp0tzw0AlLGP54XFKqlP sH4l+6pW8C6D18sSQ7E35qznrJT5mUNiKGYQ/mZihwAAdor/GoluoSES23+dflS/bL3XSHDCJNYp wYtZfcIkQix9LWzwSll6F8GbnMnwlyXuQoUBHIng64UjurYX3PjAN0fYN633emHTKyxdMemLTYlE cnYXDDG/qtJzVjB/ALBfYj8793xYR86az9O+56yx3s/OWafC0nUWvLjmbyn2xIL8OaPCAGUKU2HB 3yPRL6KTfnnnge/4G1j190gY/BqfMneFJZ5QlhNiVBgA5GAqPCZmmOC9g6I602+3pR4SvHfNhk1l tMIGdzFlzmKbCaYfAOwdU+HY4UMU7Lt+4xZbrDBV+rLUXM9IUKVTKPhwnEGkJym2o8T3+nAtDOB4 mAoPHzpYwb4bN2/Fz84BAJiEqfCQQVIxFbNl23ZUGADAJEyFBwwYoGDfHTt2oMIAACZhKhzdt7+C fXfv+gwVBgAwCVPhXn36Kth3355dqDAAgEmYCvfsFa1g3/37duOvfwIAmIqucFhkbwU7pn2x17IV VjAnAIAyxYIVBgAAE6HCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAA JKHCAAAkocIAACShwgAAJKHCAAAkWbzCYWFh9Nu0tDSr7Sh/TOYms8b0h7PEhAHA4dlQhQUTaWLU JAZBdgHAFli2wnSn+JeZ7Jv6Zf1lqdhd7Nixr2E5Y/IHlxiTfa/YZbL09AQHFxxBYp4AUJbZSoUp 2U8XSAdXbGPph5a+i3NExo4gZ54AUGaZocInLmWxb7b2d2UWmARTimolZzP51bO1CvOXOecQAByD vocSzFNhwUfifNVPmamY/CcTTB9T+i7+4Zi9wgDgeMTayGGpCusvhPU3KbNWWDCRlquwwQtwBceI CgM4NjuoMOebbKgwADgSkhXmJFi/kjL0+gejvsmm31JscAVjGnwIsZUSxyL2KKgwgGMjfC0MAFDG ocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHC AAAkocIAACShwnbjndXbSU8BAMxmWvxAZgEVtht0hUPDepGeBQD8Jz1t37i44Qp2XL5uIypsf5gK hzetSnoiAFDk4OnrdIUnJoxUsO+yVZ+gwvYHFQawKUyFp46PVbDvuynrUWH7gwoD2BSmwq8mxSnY d0HyOlTY/qDCADaFqfAbk8co2HfOkjWocClm+Qublv4znagwgE1hKjxveqKCfWcuXokKl2IXf+cY FQawKc+uheMV7DtnyWpUuBSxCgv+mXpK8s/dc5alRzaq+6gwgE159rzwaP2azh3aSmx/6PBx/fKC 5LWocCmCTRSsqlHLlHiIUWEAe8dUeNr4UeyVYZ1DBDdOO3SUffOdlI9R4VIsVGH+silQYQCb8uz1 wjGc9VHdO3DWpH51mLNm2aoNqHApqDAAGIup8Li4Efy7+kaE6pd3HUjnb7B83aeocCmoMAAYi6nw mJhhgvcOiupMv92Wekjw3jUbNqHCpSirMPvJXznbG3xEaagwgE1hKhwzbIiCfTds2oIKl8J5zQPF +yYbVbqYgi+BQIUByhSmwkMHD1Kw7+at21Bh87DmC41RYQCbwlR44IABCvbdvmMHKmwSsWtki0KF AWwKU+Hovv0V7Lt712eosP1BhQFsClPhqN59FeybuncXKmx/8FveAWwNXeHwqD4KdjyYugcVtj/4 i0cAjgQVBgCwCagwAABJqDAAAEmoMAAASagwAABJqDAAAEmoMAAASagwAABJqDAAAEmoMAAASagw AABJqDAAAEmoMAAASagwAABJqDAAAEmosN3A7xcGcBj6Xy5MocJ2hK7wvOmJpGcBAKa6f/++t7c3 /Za5iQrbDVQYwDHMXLyS/lhGhe0PKgzgGFBhe4UKAzgGVNheocIAjsFxKhwWFsa+mZaWZsbBzYiZ p+nTQ4UBHIOjVZipm7lKZwmoMACwOXiF2RfI7PAJrues5OSSf5P9WIJDMYPwN6N4FVaQZlQYwDE4 eIVl3mtwF8GbnFLzlyXuQoUBgOFoFdaTyBwnkZzdBUPMr6p0XiUKjmckAIDN0SrMr5v0kw/SIeY8 sSD2PAMqDACKOXiFORezMi9+KV4xUWEAsJCyW2GDuxh7U06FBdMvNhNpqDCAY3DwClOln5GgxF84 If1qCrEKi+0o8b0+fHcOANgcp8JlDSoM4BhQYXuFCgM4BlTYXqHCAI4BFbZXdIWnxQ/EX9wAcACo sL3y9vYmPQUAMA9UGADAJqDCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACSh wgAAJFm1wqZMFADAUVmpwgAAoBgqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioM AEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABA EioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIq DABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgxg Ke+s3k56CtYzLX6gxL0OfyqkD18aKgxgKXR6xsYNJz0La1ixbqPBCjvwqTB4+NJQYQBLodPzYvxI 0rOwhg9Wf2Kwwg58KgwevjRUGMBS6PRMHhtLehbWsGTFeoMVduBTYfDwpaHCAJZCp2fGhFGkZ2EN iz782GCFHfhUGDx8aagwgKXQ6Zk5cTTpWVjDvGVrDVbYgU+FwcOXhgoDWAqdntmT40nPwhpmL1lt sMIOfCoMHr40VBjAUuj0zJueSHoW1jBz8UqDFXbgU2Hw8KWhwgCWouwCsF3b1vTbY8dPmHcyzLAM sw9u0Wthi86c/0AKHgLXwgA2StmToaHt29Jv048cN+NM2GNaYnzLPS/MmS1907wzl3gs+fC8MICN UvbCgG6hIfTbr9OPCq5nsO9lr5fYkb8Ls0a/LPa4cljoNRISUxI8GxLHwt9ev4a/u7HzxGskAGyU shfJRnRtT7898M0RsZVylqUH5O/F3BQbwSALvV5YznzkHIvEGZBzAg3C64UBbJSyHxh7Pqwj/fbz tO/FVspZlh7Q2BEMstDPzsmZj7Izo19jncOXhgoDWIqyX57QL6IT/Xbnge/EVspZlh7Q2BEMstDv kZCeD3Mvw9gzw95XYjOZ8HskAGwUnZ4xMcOM3WtQVGf67bbUQ2Ir5SxLD2jsCAat2bDJYIXNdSo4 dyk7MwZPslEMHr40VBjAUuj0xA4fYuxew3p3pd9u2vuN2ErBZWaBv6P07tJ3ybd+4xaDFVZwKgRn K3jgEmeGP4jgGrGVchg8fGmoMICl0OkZMXSwsXuNjO7GWfPJ7q8565k17O3pNfoFg8MK7s5ZNsqn m7carLCCU8GeIYM/c/ZdEsfCH0RsjSUOXxoqDGApdHqGDh5ktYcb1a87/fbjnV9Z7RH1Nm/dZrDC 1jwVVmbw8KWhwgCWQqdn4IABln6U+IE99Murt39p6YcTtH3HDoMVtsKpIMXg4UtDhQEshU5Pv379 Sc/CGnbu/MxghR34VBg8fGmoMICl0OnpHd2P9CysYe/unQYr7MCnwuDhS0OFASyFTk9U776kZ2EN qXt3GaywA58Kg4cvDRUGsBQ6PRFRfUjPwhoOpO4xWGEHPhUGD18aKgxgKXR6uvfsTXoW1vDV/r0G K+zAp8Lg4UtDhQEshU4P6SlYj8EKW20mRKDCAAD2ChUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkV BgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYA IAkVBgAgSaDCX339debjh8xaVBgAwKK4FS4sLOzRrdO+1P36EAMAgKXdvXVt/MQpX379XUmFd+/e m/M0i/SsAADKhNyn2Q8f3P2vwvSqXuHdUj5c5uyicXX3JD09AABHRl8F028nTZmx7+DX9EJJhWn0 FTH9duGcmXSLtVodwSkCADiwpKkv02/pq2Dm5n8VZoS2b0dgUgAAZUb6kWPsm/8P95F+4wplbmRz dHJlYW0KZW5kb2JqCjYxIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0ltYWdlTWFzayB0cnVlCi9X aWR0aCA0NzEKL0hlaWdodCAzNjgKL0JpdHNQZXJDb21wb25lbnQgMQovRmlsdGVyL0NDSVRURmF4 RGVjb2RlCi9EZWNvZGVQYXJtczw8L0sgLTEKL0NvbHVtbnMgNDcxPj4vTGVuZ3RoIDEwNT4+c3Ry ZWFtCjgGoJCDp0/T//////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////a9q1DCgAgAgplbmRz dHJlYW0KZW5kb2JqCjY0IDAgb2JqCjw8L1IxMQoxMSAwIFIvUjU5CjU5IDAgUi9SOAo4IDAgUj4+ CmVuZG9iago2OCAwIG9iago8PC9SMTAKMTAgMCBSL1IxMQoxMSAwIFIvUjgKOCAwIFI+PgplbmRv YmoKMTAgMCBvYmoKPDwvQmFzZUZvbnQvSGVsdmV0aWNhLU9ibGlxdWUvVHlwZS9Gb250Ci9TdWJ0 eXBlL1R5cGUxPj4KZW5kb2JqCjExIDAgb2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkL1R5 cGUvRm9udAovRW5jb2RpbmcgNzAgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNzAgMCBvYmoK PDwvVHlwZS9FbmNvZGluZy9EaWZmZXJlbmNlc1sKMTQ3L3F1b3RlZGJsbGVmdC9xdW90ZWRibHJp Z2h0XT4+CmVuZG9iago1OSAwIG9iago8PC9CYXNlRm9udC9LUFNIQk8rV2luZ2RpbmdzL0ZvbnRE ZXNjcmlwdG9yIDYwIDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDEvV2lkdGhz WyA0NThdCi9FbmNvZGluZyA3MSAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVuZG9iago3MSAwIG9i ago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRGlmZmVyZW5j ZXNbCjEvc3F1YXJlNF0+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EvVHlw ZS9Gb250Ci9FbmNvZGluZyA3MiAwIFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iago3MiAwIG9iago8 PC9UeXBlL0VuY29kaW5nL0RpZmZlcmVuY2VzWwoxMzMvZWxsaXBzaXMKMTQ3L3F1b3RlZGJsbGVm dC9xdW90ZWRibHJpZ2h0CjIzMy9lYWN1dGVdPj4KZW5kb2JqCjE3IDAgb2JqCjw8L0Jhc2VGb250 L1RpbWVzLVJvbWFuL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMT4+CmVuZG9iago5IDAgb2JqCjw8 L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkT2JsaXF1ZS9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+ PgplbmRvYmoKNjAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9LUFNIQk8r V2luZ2RpbmdzL0ZvbnRCQm94WzYyIDAgNDM3IDcyMl0vRmxhZ3MgNAovQXNjZW50IDcyMgovQ2Fw SGVpZ2h0IDcyMgovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViA2NQovTWlzc2luZ1dp ZHRoIDUwMAovRm9udEZpbGUyIDY5IDAgUj4+CmVuZG9iago2OSAwIG9iago8PC9GaWx0ZXIvRmxh dGVEZWNvZGUKL0xlbmd0aDEgNTIyOC9MZW5ndGggMjUzOT4+c3RyZWFtCnic7Vd9cFTVFT/33ve1 mw3ZfBDSrMpbnolIsoSAmPBhWJLdNcmOdUOC7KKW3XxgIkEiMBmilFkLCG6Csy3UGa1KUNGARN8S 1MDQDkXBdGzHOqMdLVTbThwdaxydinQ6A9tz301SYlunM/2nznjP/u7v3nPOO/ee+7FvFwgAZEIc GIRubSybD1bJPoLVbS3rY12i72wCIEtbujfrL5QdOoSK8wDy4rVdd61/7cslJoBSACCtuauzZ63w n+bEamt7W6z1V7vW4rN5N2D/xnZU5OTaHwawb8H+te3rN28R/jkSAHV2bmiJjT/fh+OdXR/b0sVu U+ag/+Oo1O+JrW8bn18SK1fXhk2bRT8vj9u7NrZ13fr6dWvQ/yQAa4L/t/LWf7SUo7SQMH2ArsbW z6AZ68cQrYhHYR/so0PCBxYgTGzVw0fyCMyHjZZ+AWzF2gd/IwPwoKVZCs1ob0bvM8hVaGtBJlaM faTP4h/CDoz9BR2ip+lpy7oM49ZzDyF0SB5BPY+3HV6A98kp9Lkf9qLtOLzFn8LI+2AQLpLZKL3k QzJGQ6glfHyMsw699+F8fwHvwV9JHqkiCXISfXLoA9ZcxGhx9DmD8pYVhcstpJNsIBvJQxhzlDK6 EKNuoLtpPzXpaRaRquQRJUepUDsxCgGKpzcbM+TRvg+NOHIz3DsZVchvCSUNpIm0k0dIP87hDBlD +ZJ66DJcdS4/ZVHJIX0sr5OfQhlRVqpPaArGlkGBQtChCG7ArPw4RgPOuRXuhvssuR9lK67lj2A/ 9MMBOAQpOAG/5GPCOXgfLuLqZKHwvCrIIrIKJYKykWwjO3A9eq+QPeRxMkRO4PzeIO/QmZi1kE7M XsxyO32MHqNv0F/TD+go/YR+wYDZ2BrWzDaxg+wwe5O9KdVK/dIB6bx0Xiayaa1UjpKn3Kn0ovSp NnWdukP9sfqE+rJ9LszAvEoxr3pYhVn1YCZbYTckrF1LoRyDl1BG4BOeB0p6PBMui4iPBMhKlAhZ TaJkPdlEtkxm9Ax5lgyQY5jLOyjvknPkT+Qv5DNLLlKF5tOSyfxCtJGuouvoI/RR+jh9Hk/kED1J 36XvY46j9ALmmMFy2HR2DfOzAEoTu51tYdvZIDvNzrEx3DeHdJNUJa2U7sTcz0qj0se4k1RmcpG8 UF6M0i7fI2+Te+Un8USPyWOKw1qVHCVXWaLsUvYrQ8p7yiV1upqvzkKZq5arjWqn2q0eVkfVj7Qj tuW2DttGeykchnnwytdu70t4ul+ldyplUEjO4Wm4l2Whl87vHnWonbYOOsRnpzaS2bhTf4CLzAZB 6SysYrdDp9zMMtRPYYBskh4gz7MAHIGDajc5yaJsjB2Ui5QlYj3pY+yw2qNG1Y9wpl+yvXK7Opcs l3vJAF2GN3ojaYCvyAX4AY68mc6Bs/AQ7CbdoME+7QjJxLt2hs4kvfJT7KjUz/zyNnI97qBLHmE7 YSFMBwfMhll41mXIQ4C3orLihgXzy+eVzfWUlsy5fvZ1xUXXGrPc+sxrrr7KVfi9ghn50/Nyc7Kd WdMyHRl2m6YqssQogVK/EYjqZnHUlIqN2loP7xsxVMSuUERNHVWBqT6mHrXc9KmeXvRc+zVPr/D0 TnoSp74UlnpKdb+hm7/xGfowWd0QxvYenxHRzTGrfYvVloqtTiZ23G58QvcXtPt0k0R1vxnobk/4 oz6Ml8qw1xg1bXZPKaTsGdjMwJYZMLpSJFBFrAYN+BenKGiZOCuz3vD5zTrDx6dgsiJ/rNUMNYT9 PpfbHfGUmqSmxWg2wag2s0osF6ixhjGVGlO1htE7eDrQq6dKTyX6hp3QHC1xtBqtsTvCJotF+BjZ JebNhs+8+b7RAk/pMHm2KWzaaoYJNIWPQ306nqqL+3wRPlpOTXiX5T4D3WfcN+piCX9Bh867icQu 3exvCF9pdfM6EsGgntLgirAbZ234+3SexoqwlQEGJQVlOEmu42mKhNsMP9dE79ZNm1FttCfujuJm FSZMWNHjPlpY7z2e/iPU+/VEU9hwm8tcRiTmuyqVB4kVPUN1Xr1uqsVTmnJmi5VOTcsabzgyr2y0 TdqsluXOWzjriaUmfEZGHR4RU2/RcSZhw6RFlbxqq4RESyW6YYkQXNEOXL9owrmYb4Rc5DT0xAXA g2CMfTpVExvXKEXOC8Cb/LhMHjm0T7TNkhJzzhx+UtQa3FqcWZXVX+gp7TaDRpdTN4O4ZBAK40OR xWW45G433+XeYS80Y8eMN4RFX4dm11HwlpVETBrlllMTlukruSU+YZl8PGrgcT4G/AfddFMrnvxk OfNz/e2LTZL/DeY2Ycfr49dTklyUCIWLY4leV3E00RfBrQngVUwkAoYeSEQTseF0vNnQnUYiFQwm uvzRiZSG06d6Xaa3L9JOcFHNBWI1zNyaMHPRiGhRF4t4gM9DLb8cAsjA33rpN+0fWDO7suywNH8m DiiDPTAN38RObC3CRz9Np/l73+uAQABdcrI1b60+TG88WjsfabtF5Iig5wUdEjQg6DlBTws6IGi/ oDpBtYJuFlQtyCuoStBSQYsEKYIkQUwQ8d6KfB5xDvF7xO8QryJeRryEeBExiDiCGEA8h9iPeBLx BKIPsR3RglhjxXxRhB4UdFjQs4IOCnpG0JOCfIKWC7pJUKUgVZAsiAoCrxf5PcQ7iBHE64iziDOI VxDHEEOIFxD9iJ8gehCttfPzbHm2iuQw6fbWqckDanKvmtyjJjeoyU41uVZNtqnJO9TkajUZUZNh 9VptlqZr12hXaYVagZav5Wk5mlObpjk0u6ZpiiZpVMNXmJnLgjTYWE2C5qkWCDbr5leNxjCxN6w2 ZaOamDlBCDZVF5iVJSbdbX0jDpN0ipCHd7r4l+FxICS9c49rnCMRyC/511IwpRcM9ZyEmaQCVKwX DKkzX1O5thG1SUub5NqkpS0gR0MwPxjrjV4N/ybwPwv5RusUT38HTzcUTmlQHam5Q/AQzbBjPlGX O1Kd7+yqspJb4i7Y5johAf70z8DvBAe+ZDIR3ORZ7lnOTfj3ipum8ffPuKlg2xK36wQZGDc5UZ2N S4m3LI7/neL4q59hkoY3S32bSG+Tp/EPXhrkNDtOPgQouzzmHINln2FdPm9Btju7yJ3tjjO4FKdw GeSRv1fGpRF+xwfJSXpJcmCsvJ8DoRV4WxlpwQBj+Cmfl4uPDtIQOoUumfzOF38nKFXfauGFjn+b 5+HOYyGFCAUb2//Hf9Df9iLhb2xeS3x9Pif4HhuvsY830VofAjm4fhRbCtgAVnXcc1crYpP1ziRJ /uv8vyza1O7n8Hl6ioJMTAri3+E7cLBDMCju7DcUfm5oHFLmiyfWZC29oLnEQTs4uPcy59Qb6tsA l0P2D9Ry7Domztk/AJ+WFd4KZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iago8PC9MZW5ndGggMTQ2 OT4+c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3pr YzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+Cjx4OnhtcG1ldGEgeG1sbnM6 eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdv cmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIy LXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4K PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0 ZDMyNDJkMCcgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6UHJv ZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA4LjU0Jy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PScwMjkzMWRlOS1hNjA5LTExZGQtMDAwMC1lOGJiNGQzMjQyZDAnIHhtbG5zOnhhcD0naHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOk1vZGlmeURhdGU9JzIwMDgtMTAtMjYnIHhhcDpD cmVhdGVEYXRlPScyMDA4LTEwLTI2Jz48eGFwOkNyZWF0b3JUb29sPkdQTCBHaG9zdHNjcmlwdCA4 LjU0IFBERiBXcml0ZXI8L3hhcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0ZDMyNDJk MCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRv Y3VtZW50SUQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0ZDMyNDJkMCcvPgo8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0nMDI5MzFkZTktYTYwOS0xMWRkLTAwMDAtZThiYjRkMzI0MmQw JyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0n YXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1k ZWZhdWx0Jz5cMzc2XDM3N1wwMDBuXDAwMG9cMDAwdFwwMDBlXDAwMFZcMDAwT1wwMDBTXDAwMHBc MDAwYVwwMDBjXDAwMGVcMDAwaVwwMDBSXDAwME9cMDAwRFwwMDBTXDAwMC1cMDAwdlwwMDAxXDAw MC5cMDAwMDwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2Vx PjxyZGY6bGk+XDM3NlwzNzdcMDAwQVwwMDBuXDAwMGRcMDAwclwwMDBlPC9yZGY6bGk+PC9yZGY6 U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0 YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVu ZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC41NCkK L0NyZWF0aW9uRGF0ZShEOjIwMDgxMDI2MjMyOTA1KzAxJzAwJykKL01vZERhdGUoRDoyMDA4MTAy NjIzMjkwNSkKL1RpdGxlKFwzNzZcMzc3XDAwMG5cMDAwb1wwMDB0XDAwMGVcMDAwVlwwMDBPXDAw MFNcMDAwcFwwMDBhXDAwMGNcMDAwZVwwMDBpXDAwMFJcMDAwT1wwMDBEXDAwMFNcMDAwLVwwMDB2 XDAwMDFcMDAwLlwwMDAwKQovQ3JlYXRvcihcMzc2XDM3N1wwMDBQXDAwMERcMDAwRlwwMDBDXDAw MHJcMDAwZVwwMDBhXDAwMHRcMDAwb1wwMDByXDAwMCBcMDAwVlwwMDBlXDAwMHJcMDAwc1wwMDBp XDAwMG9cMDAwblwwMDAgXDAwMDBcMDAwLlwwMDA5XDAwMC5cMDAwMykKL0F1dGhvcihcMzc2XDM3 N1wwMDBBXDAwMG5cMDAwZFwwMDByXDAwMGUpCi9LZXl3b3JkcygpCi9TdWJqZWN0KCk+PmVuZG9i agp4cmVmCjAgNzQKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDI0NzI0IDAwMDAwIG4gCjAwMDAx NjA0MTMgMDAwMDAgbiAKMDAwMDAyNDYwMCAwMDAwMCBuIAowMDAwMDIzMTExIDAwMDAwIG4gCjAw MDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMzAxNSAwMDAwMCBuIAowMDAwMDI0ODE5IDAwMDAwIG4g CjAwMDAxNTU3NDggMDAwMDAgbiAKMDAwMDE1NTk5OSAwMDAwMCBuIAowMDAwMTU1MjcxIDAwMDAw IG4gCjAwMDAxNTUzNDQgMDAwMDAgbiAKMDAwMDAyNDc4OSAwMDAwMCBuIAowMDAwMDMyNjM3IDAw MDAwIG4gCjAwMDAwMjMyNzcgMDAwMDAgbiAKMDAwMDAwMzAzNSAwMDAwMCBuIAowMDAwMDA3MDg5 IDAwMDAwIG4gCjAwMDAxNTU5MzIgMDAwMDAgbiAKMDAwMDAzMjY5OCAwMDAwMCBuIAowMDAwMDIz NDIxIDAwMDAwIG4gCjAwMDAwMDcxMTAgMDAwMDAgbiAKMDAwMDAwOTk0NyAwMDAwMCBuIAowMDAw MDMyNzYxIDAwMDAwIG4gCjAwMDAwMzM2MDUgMDAwMDAgbiAKMDAwMDAzMzU0MSAwMDAwMCBuIAow MDAwMDMzNTczIDAwMDAwIG4gCjAwMDAwNDE2NjQgMDAwMDAgbiAKMDAwMDAyMzYxNiAwMDAwMCBu IAowMDAwMDA5OTY4IDAwMDAwIG4gCjAwMDAwMTQ0ODUgMDAwMDAgbiAKMDAwMDA0MTcxNiAwMDAw MCBuIAowMDAwMDIzNzYwIDAwMDAwIG4gCjAwMDAwMTQ1MDYgMDAwMDAgbiAKMDAwMDAxNTk4NyAw MDAwMCBuIAowMDAwMDczMzEzIDAwMDAwIG4gCjAwMDAwNTY3MTMgMDAwMDAgbiAKMDAwMDA0MTgy MCAwMDAwMCBuIAowMDAwMDQxNzY2IDAwMDAwIG4gCjAwMDAwNzM2MDcgMDAwMDAgbiAKMDAwMDAy MzkzNiAwMDAwMCBuIAowMDAwMDE2MDA4IDAwMDAwIG4gCjAwMDAwMTY2MzIgMDAwMDAgbiAKMDAw MDA5MDEyNCAwMDAwMCBuIAowMDAwMDg5ODg0IDAwMDAwIG4gCjAwMDAwODE1MzMgMDAwMDAgbiAK MDAwMDA4MTI5MSAwMDAwMCBuIAowMDAwMDczNzI0IDAwMDAwIG4gCjAwMDAwNzM2NDggMDAwMDAg biAKMDAwMDExMDA4MiAwMDAwMCBuIAowMDAwMDI0MTEyIDAwMDAwIG4gCjAwMDAwMTY2NTIgMDAw MDAgbiAKMDAwMDAxNzQ4NiAwMDAwMCBuIAowMDAwMTMwMzcxIDAwMDAwIG4gCjAwMDAxMTAxNTUg MDAwMDAgbiAKMDAwMDExMDExMiAwMDAwMCBuIAowMDAwMTQzMzU3IDAwMDAwIG4gCjAwMDAwMjQy ODAgMDAwMDAgbiAKMDAwMDAxNzUwNiAwMDAwMCBuIAowMDAwMDIwMTExIDAwMDAwIG4gCjAwMDAx NTU1MTAgMDAwMDAgbiAKMDAwMDE1NjA3NSAwMDAwMCBuIAowMDAwMTU0ODgyIDAwMDAwIG4gCjAw MDAxNDM0NDEgMDAwMDAgbiAKMDAwMDE0MzM5OCAwMDAwMCBuIAowMDAwMTU1MTY3IDAwMDAwIG4g CjAwMDAwMjQ0NTYgMDAwMDAgbiAKMDAwMDAyMDEzMiAwMDAwMCBuIAowMDAwMDIzMDkwIDAwMDAw IG4gCjAwMDAxNTUyMTkgMDAwMDAgbiAKMDAwMDE1NjI3MiAwMDAwMCBuIAowMDAwMTU1NDMwIDAw MDAwIG4gCjAwMDAxNTU2NjAgMDAwMDAgbiAKMDAwMDE1NTgyOCAwMDAwMCBuIAowMDAwMTU4ODk0 IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgNzQgL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lE IFs8RTlEOEM4OUFEQjZCNTk3NkQyNTE0REFBOUM4MEVGNUI+PEU5RDhDODlBREI2QjU5NzZEMjUx NERBQTlDODBFRjVCPl0KPj4Kc3RhcnR4cmVmCjE2MDg1NgolJUVPRgo= --=_201c2at93vy8-- From grid-bounces@ivoa.net Sun Oct 26 23:41:35 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 319666242D7; Sun, 26 Oct 2008 23:41:34 +0100 (CET) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m9QMfaIv000559; Sun, 26 Oct 2008 23:41:36 +0100 (MET) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 9DAA9ECA37A; Sun, 26 Oct 2008 23:41:36 +0100 (CET) X-Original-To: grid@pat.hq.eso.org Delivered-To: grid@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 7B850EC8141; Sun, 26 Oct 2008 23:41:33 +0100 (CET) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m9QMfXxm000551; Sun, 26 Oct 2008 23:41:33 +0100 (MET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwEABePBEmCT8iYZmdsb2JhbACGaowJgQcNCwgIEqpFg08 X-IronPort-AV: E=Sophos;i="4.33,489,1220220000"; d="pdf'?scan'208";a="11852542" Received: from mailhost.u-strasbg.fr ([130.79.200.152]) by clavius.hq.eso.org with ESMTP; 26 Oct 2008 23:37:00 +0100 Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m9QMfROk070908 ; Sun, 26 Oct 2008 23:41:27 +0100 (CET) Received: from localhost (www-data@astron [130.79.128.15]) by newb6.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id XAA24643; Sun, 26 Oct 2008 23:41:09 +0100 (MET) Received: from 72.4.254.58 ([72.4.254.58]) by astron.u-strasbg.fr (Horde MIME library) with HTTP; Sun, 26 Oct 2008 23:39:07 +0100 Message-ID: <20081026233907.1ide941oua0448k4@astron.u-strasbg.fr> Date: Sun, 26 Oct 2008 23:39:07 +0100 From: schaaff@newb6.u-strasbg.fr To: interop@ivoa.net, grid@ivoa.net, vospace@ivoa.net Subject: last version of the VOSpace-iRODS note MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_201c2at93vy8" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-MailScanner-Astro: Message analyse non infecte par sophos sur astro.u-strasbg.fr X-MailScanner-SpamCheck: ORDB-RBL X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [130.79.200.152]); Sun, 26 Oct 2008 23:41:28 +0100 (CET) X-Virus-Scanned: ClamAV 0.94/8497/Sun Oct 26 22:30:29 2008 on mr2.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mr2.u-strasbg.fr X-BeenThere: grid@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Grid and Web Services Working Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: grid-bounces@ivoa.net This message is in MIME format. --=_201c2at93vy8 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The final note concerning the VOSpace-iRODS implementation. Andr=E9 --=_201c2at93vy8 Content-Type: application/pdf; name="noteVOSpaceiRODS-v1.0.pdf" Content-Disposition: attachment; filename="noteVOSpaceiRODS-v1.0.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nMVa3XJctw2+36c4d92TmaVJ8D93buxJ3ck0ibPjXDi5WGtXllJ5JevHbp6j fcm+RQCeQxLUUpZV200zTbk8AIi/DwCpvh2kUDBI+icvjt4s3g4qgE2/lIQweIgiRjdYJZ1wnkge PffDk/PFjws5fIv/fb14uwhC038SG18fvRn+ukaGMCiF3DEM6+OFRIHR6PmQQZPgwSkQ+PXNYjmM 698WT9dJvhTagrQKF05pCGp4/m13+/JjtIiD0sI5a6sWkJUAKQJaiwTBkBovUY+VFsoZqZfPxl/X f0cBSnIJXrhgDJmx3iL9fkQbwbiwvK6cu3HlhAYb1fJyXNEZymmPtCCMk0YvNz2uU+IyRoe4PC+U nCevzkYAEFIq0m/22WeJSYzkh+qOPzUq6GZh3UFUhtEKB6Chv/lidM734gZGgDUqx405+3L0Ikrj FQUDvROtNMubEqH/g9+9Ec4wg/9cv1uLXn2o37/vggWsCKpg5VXx5NW4isJJHwGxkh3NofIurUFZ b1kAGFgqQmr4fh+tlCU2bxfaqDhYa1IJe4M/XSg/z+afmAH5JxGXnyeLn4f9Z4qvUVIAdyyLL+kJ zpvBkvuTnuAxC/LPs/mnivlnIi4/Jz0/S9wpWFMxftyod5/oNuS3ZGspPDDZLwlFQhswlq1Oy2pT S2ctfUcsG3ajte5/ACBpeTcCXRSmcUGK0K2wasxTFfSUzhPFCoIVBL4VaOFd/YAeMVhDv6Off5n+ 9UXwrNSgorDSQjXLuNmsgM2KMh71nnz/FF2qIgD1ohVVG3BAzQjZ8HQEaNk8G0kWtgLqS14oC95R sxM2aqmWrzOlR9MK5YZ2lQOlcDcxJXwqPNNahZjN7K/K6qasrirz9eiEtwB2Fo7F4QVBPzqIEUsN JkvEOWX502SOM8uLImbWQWmHaUOGGbR2VzerYsco20bn8Pt5NfySltHJZANGUUs0vDl9RZE2TmXl dACmcTUShSLwPU5WszcT5VVRirFvxiCUidiMWFy2dTmM4EPuPNiDNFBqrb96yb22K3EsNgAWUmXQ BhMwjCVOR4VyV9knxZKHPnN/m9IQv8svPVXcjwaDhTN3tzmqGm1mfqB+olFbnT2CbmK+q/Hd1/jO mRLUUlVBojLJ1repHHvBtVSq0dLNgH02rkDE4I1HbUEAGCyMKQUhAMp7nLDgEwxnSrf8R9kkZdGL NmKCGiF1lGQq1lIfDFQWv4SyKceVFdGbSFp74bXyfhnmz1pxplkPBDdmVOavB52TpCBlhIR3mUC3 KzIxSYMwFJ8s0znNFLH8zC+RkTj9UdEvGdkp2VNGVTEU5QK9NUELKwEsT8hSH61LQzwO0drbgOlD fdVIXA51990IigbPSDkXMU7oFvIFHqK9SzBUNOO4LAr7HrrSoKoGPbmfj8L8+zpBG1OiZFUYcKqi 5lvTKnCLsWqmpMujnaZpx1DOKkx57ylnsf0GrzxFP+1iAJYrWhplFSVKoZXdZSD9JaAAEoulEr3O vzMBtpBmA1pv94KmsQ7Og8R3k1MgYvksnr4mA0B7badEn3avOAHmpwHrc1DIv++K02cmF1wblLJL pcAY5ZWdEnyKxaeFxTkRD8NyUj11XcNCd5SIVxkchS5GHDqM0gHPLN8f4UhulUFFHtXN94Q1zD5s Je9HnNXAK75iUT+lUQudjldc9Ar2Hy9t6o9ZlU03WfZ1d9dV+1FV+0k5l4nFEc/TXQFT7GZKi7B8 QwECLbWZbgm0t2+kJ5ERw0ONkmrOo7J3RhzGgOYazwppMFzNyn6dnIdd/JPlZHYGnXeTic7Fas5l /XxVP5+WM89TCoHFnHOuvjn0kLnvxmj2oQo2H/owuOHwKGe8/UBSVcTelKHhYihVDKFRS9sEEtBG c5DclCrG8ES1H1uyCi0K8+pyupIrzJu7QNgpjb8s5zIQAyuov4x19+upDJjw8Sg109x1C6UP8CXE ud+8pL6NHc9ZemhYKSckXvJ47Topte28rFg9au0rbmkNfHAZwpHEHxr4mI4NgI16euyitN3WBGMZ /N+6O1Tk/1T5GchPutnKlse1YBwnVGKV5GIZKcv87YEKIOPym1Jxfh/R2alRo97ghAo4JVW4nbHq x876YcRBzxLXrva0q2pMvxxkYdrDHAN66QhlwviIEQXih0aUaSASWtHTLWIQCwIGFGcqUHiLxYHZ azkAAJ2BSMbpW+nhcrc4/mpBrwfWhzRf4z3BOlrQ/+rKpxMf4D/Ec9cmlE08QeZ9MtxqPA4XOPYM lKLOq0jS0dFwKOnDGvV5Zvtg2owfffQBx/3OmF5j4GPs6zJMjpo2uaOyRi11f/fT514rA5VzvDHP VX1+xTCQLjIDXWhoEtl+6UsaAlpTJpf3oqYS4c2G/jgxV0rSSUmPlwhKcunSzQznGWwvMrVij8Y4 IEgDig3SUHHI39PbEea+9zT7oaZGy6i/0JUCqJT38Er3hRe1f36PtyApbXRTdZw2L+qQuik96ygV nIgli4+mWJtwJIhUHF/WVqgrwa91l9GepssptupUvbCOYY4HTnBd2U6qsNqNqSYqajAGb6aF9MUY 0WqLfaHa9Xi2K/oqP6KyZeSOReikK9VpRvk+VVdvLXXARKlp7KCmrWH5z0l7lwJZeI75hYm013R5 LEyM8sDORLkrBzHSLf9eluwo5tR9JWC715TBHlODNrEpY5V2zKj9NOIhJJWJecRjClTK4zoqsZht mKQUMhU4e1895oBdx1XMvE39fDQ6eo+KkfPgUYbKlHdc6HlDkHXZ9Bz8rsaS+aeowoTeFHam1Fm1 L6sSOuFxyhBpEu/aUIMPFIFVDsFqRi3F4WqGn6PRATxWJV2w44of06DLrptp6I52nliU1ogEn2+p Lk3KBX0bft/P1jOjGNerQsq+t1Uhn3UAhflGS06l9xpG+iJN2IYejib4Yqqm7/Q84j1T8KI+WFxw VbLWLNWOalBr0Fko70BCiepVA/DWg4mA0W6bXMu0TEIvw9usyxly1GW6SnmvYHrSK2U1wdYbimOG 7bPq9mtOWrTaFmMfUkwOdCEMMqnnU2CcidOIng7AwAAphze/NPWmOwSL6wdroGl8yaK1Z9EsWj+0 hFjbVpCCwNmbHIHsbWdfl9vmbQ2HEAogXQTyXfS8JCjTk5Gy3abTtfdSovW8Vx6UuPxSlK9dDK6v 7+iggNOP0f4w1omU+a3ClUntK1NJb/jokJO5KaIlV0qsdqVxNAleHLCe76jIc1Liz5KiScps3nkX rG3nyAfcJ+vmDuBPEPTCRp8huDucFpigg7AfNn4Ai17zt71zuyxdVD/2Lb06qDAU6Vc9/52NNO8q aBzBYtbgN/uMnXrcpnixtQ/wLvAmH3Lg/bs8lLJ+18yoZXlUCXKm11Ex8L5R87QClDVD5qhtZWpe gzLQ/lMktTmbD2Xz6b5BdSboz7qHI7IxmrPtizKsAByMU/kwr4SlP3a8p79lYzaZNteyUBaUf+WJ I+Ymqw1vshueQJ1ewaSyDLnpouJQu4nFRqPuGLanWRUVlGVWZeX9FQdFPpGB9/ogVKaNQ2HfdS1i JrMZq+un3fwYqTnljiO1M5ZsuqqyU/tQb3zOpnUGyvx9U03kk+fkUA6/z3tbzE2/uS3WC9j016mg 27mvCGAA2nbFHsawxS2RWkwim0v53Mqo1Bswt5WdSWuJaH2ZT2XF8nnJ4MlZxi+flK3steku2nGF raGsl9G2rGSudXluZjX1tNTvW3PrzMTxVXGYSpnzBDA+0x0ax1tiwl/A+7bUGX9s/m3Sk2GJz3RV fr963Dcf9mgPhhYNHEsNAln5y+x3trKuLp0JmkFp9s29UFrXv9k+rd+/SZGiV4e/ldVQUoKljLnj rSWTXnSnQ9Yyfute4Y4KJJjJguOTrLz1/yn6cfEHGdX05GVuZHN0cmVhbQplbmRvYmoKNiAwIG9i agoyOTMwCmVuZG9iagoxNSAwIG9iago8PC9MZW5ndGggMTYgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJy9XEmX3EQSvvevqNtUzaOFck9xYzAzMM9spod584wPvZTdxu4FNzb0v59I SZnxpRTqqjI2cJFVuUTG+kVkqH9dtY3Sqzb9nx/Or47Sv4zTrVP04JXRUa2e/Et8/ebF0a9HsTHp v346Pp9frf5xcvTpE6VWyjXOWLs6eX7UNl3XWR37IWoVQ+NXQasm+NXJ1dHT9Y8b3ejolV7/tqF9 rGlbvT7dHMdGG9sqekt7BK3N+u3mONB20Zr13ea4bVxrQ4jrVXrWTnUqrG9oCdO1RO36+bCaDTaN CE0XlXLrEx5wyY8vecDSyo82x7Zx9FrjJucwOpPn9fqKRigTgtPr7TDCRGPX1zwxn7UztMuzk38f fXly9AOxPLF9Hx7HlVKND11kFhtXsbglFuuBxScb29hoddefOUbbupjObBvlInGbzmyaoLxRREzb WEuc75miaJ4JHQ3wjfOGTkYs6ZpoolYkIyJBeevzpLZbf0vCpNVd1zOJdvLR92e1VgXi7nZ4q+K6 4ZcrfjzZHLsmdI7kflmW3/JSMPQ5U5IppQFv6KitVV0SpPJNJLJo/zIS5vNIWP/1yBSf3ub9T/l3 4pQyxG3n8+/G4qLDqYl7CumDAUDLZVkA6B84rbsOJ13wqrDBeRn6ll9epfU7ZzwSeM2//4ZsT3qn HZ3HJuU6uSBV+b0XIJnNeOp+EhLVkx+iWWv+vRUfY5E1HOUbpg82uB9kZTzql0qPpvO2W9tRFqpW m0T/cT5AEkzyOOkUX7MWX7PG09q0RtOarJL9gKxni/o+zAnrd4OVOB9RY1Dh0iSrK3neFC26Ri0u i/5eDGYL5lR+vkJ25d9fTQlxnVX9LGJFcAEVFtYSFf5WVK1hqJmYTlnptGgWKDkMZc0rC8FsUByg +VbY/UbU25GlxDLaUpOjVbFoELm4W1YbNNFe14Mjqfis6yCm6zIy+8LO4J6gq+Ai4PFUJPUlD4Cz XC9YFrMXhma6LgSudeszPKzkem7motjWK42bAtWX4qKrjQ5xsLiRjWhxt2xmbzbHnmJ3MEVUifp+ SeIEOavx3Tmrcc2yHbYDHnzYqItgPK95/p4e3FYO+uf1uKqt7OR6PIBOZ6njHjj+fqjs+DUPaMsC LXM6FmJ+3gwUeIIaM3c3svzxEf37bwNoILRFGk3ILJh25bQ3hAtWhKg0QQS9erM9er4nplDtLlBB etTYAVN8URwXYIob8RHghRzKb5i513LUn+qzXWJzpcZlgcq35llzK6nV5zXZptJKBxTu4K99rGwb 1POFpBxFp0hTT/GsxbguJDDxhvVgy4qSsKXRXvsAxv1u1GpfOz3BDSzZObuJsungnJzDhW7LQHB+ gD/uRkdraGGbHS2c6X5GqPITlzoxf9qKQQlQwuIR/fh2IzhZMq3RCX7GQAbwd21KBNp7U2ot2YU6 xJJ2onPfBiJzsKQZZk42AwAF3VSidGqo2ve51OOjk78fCPUHFgwDROiTo+spOkI0yzzga5bwT7RW ozpLHv67TWja1nV+/Tm/pFkmpUE0C0+ezWaeLEw8ALz9IyvoLRuViHIYmt1x0KkMuFjCCzSfTOid BLVfiI/bHUiiim8Q5wsBFSTI/AVfNRzQBTTqq42idLKdCq2seT1aZWySzoxWWSOKPAuIYlsXLWwe qetUQzxIlSBBbCusFhOkrUgq4CQQi+zgBBw0yqeztg6zoNQAbonBQStfwaCBnQiDFi2NQnHjTcAB 1wvWXt6CqV1gLJPepi20blKlooLK1YCRBrCBSzYczi8qXCXtcDalpk9A2MgmWcM461baADwL57Mw H4z0nO1JNLJPKiHyrpDgCLPgEfY6wzDHeLICzuMGp8yBW7QdSGdKRL0Z7NB35Lx1tkPOps45OIq6 zxb1Sc1hY8i5BknJgdAqmxKNrFgLkCyzUsjw7pj4aiDUKxb8YWb6OzbImYCtNWh6IwfR9G7QcMYU IxEfbZMi0L6GN+T0RT85MEGM2e7Q5LPy+0uEk+Wg8BY4cV/sJ5EdbGMU1geAUeyNLmv77Cd5Qbwz PJ3XT9FaNTZYjxsMQm19h/SBjz2VzKMwO4yB3wawozvJeovyAH49FdUUVbvo5n2O/7X/zlR8PVqb alodsrVNfNPIBqDuUnIYcHaQ4yQnH9e6xgXkwlsh8WwhxOXfpaQd4mZlsvOR16LxwYB8gErlbmau q9O18Q0MXTC+qrRW3kJYGyjVbkG578Qy20r0GBAhZdwI9imGn+3CAg8n+5DDVe4JBgj5phgfeSRA QM4GTwUBY64Iixf5im76XAxzz3cFWjb0papWDfz6MNhbYyr2LKZWJP2Uv6yMDh+hSuEI53RjcnVc lE1+KqWq6nHHyPrnlGscs0otvBR/l552DNy15J/bZ3l1UryPt01yMJNt+ofi6aUfpVHShL5s1kUK cgVy/Ym9FBmx8v49qbRkae9xhP22kn7c993BP34QSvbj7+GyMh3FzvF+KIue8rV0593Lvy5HREV5 XCiBnRCinMaNsKsPhnlSVfeFCD8Gy/FWN12lx7YN5WKd/73fjfpDPk8ZvbLRNXGszEJd/S3EvGx9 WCARyq41PhpOGQ6s7+RZT+ByC9K8Qh4wD6qa8FhhGQiPAEQPuXYRsChQW9VLZhDJVPzAeipgbSnt wVQsT5+BlQqj9UsBLULBhXNl+WYK9qouj3tA3KkUqbMvhGhf3SODEARafkPo4dqW47xqKb63po/v OnTdyufovm9vw4Pabn0gGiuFh8OK0OW6EmGnmzYEPxYxptJimGsiyahzFcx9ztgWEO/bWckmPV5A EtpXlALiwjodmGdr8DuwmjHsZ/z7p/z7p/yWsbX01GykguQ70TShwAHTAHrLIBpoeTSpcGdtzynf kt493L8AVgx7NVmAkyq8VmOPA/H75JeZlpnGeNXVI6r5x5Ru0xiMI8O47OL/4hYq+mejRwP4PAWm TrW9/ue+qVf8CH1HN5tIqtjFdKlCWSY9t33kK31OW+houuB5L/gRR1ylnifXta5+PWyonPO50Sm1 YY2tVc6Zj9X0ZNvYtPE9mp5KCa1YLRhA1lTnIaBWjTbS7cgk4S/ri1WkHJIrY8zp4hbTTawR9Wv2 N6G5ZM0r3UiUAiGzi9JJwpiGWvJ8IaXpqXAce6c3T0dfVcE01wovsPQuFSQm9Y6RKjmelwFuvHZO V4GPytOPFfjIS4l3FmMfCMWAaEsE3HUlCovOWG00BJqZTkyPt9QedpBUxqGPkunFwOhqLBGXGuqo 615ZvJ+qgmEp6YwMSXpuRowMXIWSDsQ66Om43/RO0TgOsGtT1RsnwMlWWisjo6XSZR4qAlFoIPyS f+dmha/K/X1eiR6f8qaWt3pWKeCwa66uQOtX36eU5fPLrPukrr3A8YZYmpom4UzfcPg7FWXGfU4V 0wBBFAUWAdCrAhxlEDy7PJoi338PFhSJjdl+QP1mRKf2P8jX/rdRRJ53uu5YkO8M85bfFkt/KbG3 tqSgKH8MYX5jWveTAc6ASXDjx5vqstP3rFFGNKOeKwv3gXUjonZ0UAooj/ntfbl5L21Tk8t2S2wM leXcCDEEVt+jGyYP5chWFWCn1hoK3B3bZaH6n+njmqlc1j0vQQyWqq7kshIcdsU8nkQ2nMlt90jq nZj8yPd4cn9kdXE8p+BMnP92NKJkC0YIQ7AWsPBJUclyv1IHwf4ip8PzPS03RY53f4aeh2lm/gqF aBhZ9U2JaW7eHUIYBCNoK2LDGTixu6Mwa6TQVDa5Mp91b07fzqoEQn9LHbjn7X2INmoxpWDDYWkM 1paQbxEUbODrSw1sBB7Xh1lwBDZ6Fh+o9BmCML7KmmO43LWWMjzpdFVYkqok91UfawEzUmlENs+l uJQxKN44DrZD+X8sBV12BHXUEnAVYFgYwLZVRTNoC8rRTOzOBUqBVzcLzgPa+naA4AVbZLsZuIB2 c8gnHnLfSa5S1JmD9OEFmAXGnwe+dlhs7ORQAxYImRds9Vbq9oIqxQsp1FXYfFr3rO+3Kg2cXvrV ZbAqqsjHllF8DuAQX8AwxfaTeTC1/PnCUpPWCyRwaALT5MULdrtBGMV4fHqTOa2iSVwR7/orZ1X0 HjRc7PoRO1dlAsU7egxGeSFuIpWi1ivOm8TN5bRp5CWa39L1NxcDoekyW6ccMvK7Kr/N8fy/RDDt 3um0UO6EhS9Dxpfe4HmAb5DzKLYXU+zlGc/CTGWhB/2vr38ZYoTTuRedHGdUTuGnedf8OR7UoOoq lTQifwDoYj7vh65S6Y6I7O+nhwoiDW+tRy9OIhlqlAHX8o1vCQQ9UKTUpomdKYUNuLURL3iwWlRU 4AIdbZ60x7cagKAG9xpyucWQmZhMtpFPRujPP1R9tW1HJqCQR/qD8Og/xczuoOAm9Z0AD7iOX31O kiHCRz32wkoHHnsnXp06n3KhWh3Lvu+xTON93Tpr2Fs27EPVhlKOseu92iRV43WnH9iF1o5tKO3O X5UjQToArUBQmf0dhu5qip2ihkln+bxxl/XDp28Awl/FSY31h0L1Y6Tv4V5gwGW7v32R+op2K1pJ YHv+dOSdW/tn+TMzoIWVDjQgsfoIkRrqhKfoRqcfny19RfZOGloVeaYcNhWDSRl1MBWHS4eu+sim bBdMWVJAiFEA0fmiU/yeb+nyRbg9Xcz9xcglGfZCyRrQft2N2+cgonhFhF59NzsHppBtVah50s4J buXDmM2+UtUfzEFD8VWUpNzWOfuAYGiwPOB7UsgQ+nsut9SgfSn5t91+AArye8nvvcMCaaFNkLig TpU7hAhL65UKbbkxtpvYWO96cH9Mp3Y6pg+zhZeLAXjWhRRT0yVvshdhjvBwrCj7PHHGOtUOJRFK H2z/UVRC2q7/0xrHrmm9SQ0emdzXPbk+ucDXm67xXavSbBJRKqfAit/z49fDz6VJlVINsmz/ENsn J3ZtAvMHHniQhIuHimHRzBbEMOxwiAwyTT+RFgedGsG/6wNLZ1rXK7RtvHaaFDqTxwIgddbJHvpg RY+hjV1kCXzJbP+DR95W8kt39W0qmZXpb9Kj1l4lx5iHvqGnzg4tTnOxuf3FdgCDBplZV/5kzf5i MweKrWxyiOSAMtl6UKS+/zs3dkmihfuVSBUZleksrvnPtJOL7fCNyyg9ECSL7IukRqavT1yWlyBn eLwbNu0ro/tJPOwvcYm3C0hRL2vTwUARYsFWyqffYliDPhD+2KfEmvvyJ22qL7LLfPEz9rqxP2NK /IsrMygYPxTWfjpeOwHo60EDBM3q02MpgzrbaNIpa6uoLH78PfuWyoSMdG1LeqXjYefr6z4/HP0f WJltVmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKMzk4MgplbmRvYmoKMjAgMCBvYmoKPDwvTGVu Z3RoIDIxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicxVvbchy3EX3fr5i37FZl x4M7kLdITrmcSlVimfGLrAdquSQV8SJRomR9R/LBAWYA9MFMj5cuKxWpVBrO4NJo9OnLAfi+G3oh uyH9LQ+H283QfRf/XW3eb3yv0p/xAz4fbrtnZ5tvXvhOiN664Luzy83QhxC0MmML0QXfW905aXpl u7Pbzdbuzv4V+wiHnWxvB+XSqGcXm203NWmGlar3YRw1tni5fb6TvR6MCdv7XWwlrLbbu93Qe6+t t9vDzvbGaqm3N7u90L1W8eVjbflht1e9E8b67ZvdXvfCeGviSPvQq2BirzyU8FGWV2d/3Sgne1XE 8/wKlI0rXF/AXg+hF0F0e6F6radl/DlKJ3rtokzvsnTxYRIjSnyEtVXZLurLN7S2X+qCu9TSKy/F OHqcUsdB/xQXpLWIa44N6uO/d7oftAiGBAlVkCRSVeiRHkHNTxflLM6kvQ4SFf6RJLmhtzDVf0b5 pC7boAfZe+mzlsPv3wclp314sdu73jutVNX59nKS3hmPIj1UlfEqOZBpHdHe4mQhWPFVFyKHXioH BjW1+8vZ5odNwrIycjAiPlihpBfdi+/Y1w9PwbgQnTC9UWmiAvJxAQnk3vW2s8ZmjL/cit1+6M2g nUtbtzfC90KI7ffptTRS+TDqTIUhyhDtIGp/8MYl9co4iR90RGP9fkGPj/QYNe3j+vUgRkOyWkXz TeaVpogb7BKgXVyKt7LMFlWXdyAr6Wu4uGn1KvRyWvxPBLu/7+LCBhPs9kd6mWE1RMM6ryZyyCZi GqxlBDmvti8JLIoavEJc17aAxg+Axtr0IwHzukqwnDZ9/556sesCDwa9AOSADcA7i6hLGiArRukC KBtU7qS0EjgXjHrPNrioYy30IkNAZUyiqMZJvaYxH+tA0OdYX8KUH0joRrxkedLEVtKVSFbnPKeJ ruiRhu9peH5/Pja2EJ2DEL7ZClozr77rcVoT9GxVZahPtX+jSGF7r2VolVa6Q/w9pSnof8EpACS5 ry8vWa0sFrUYSjqfNmNfdgOjcpFJlYGil1E10Yg7trfJ8SqT92yE8hUXttuFFoB/qZgkdC4tKna/ TS+DUdbG3Z8DfQqre9O7YAYBeRDo6Ta5PWmldVHUmkG8HWc1ZgXya/5Lit4ZV/KDqEWw2F9F6eS+ 6viKGvDu65EagHnAbIDJNftizP/ulPu4nlRkYxLE2urDhF/n+xQIMn6P1Omcs3roD0kOiHWJO09p Z335eSdkb71WrVAqBbS4wDu0b0b+i2bVRS2gzDu2AeziJWkIHsEFHBZ+wSLYYIKPOzH0TgqLCMz6 /N8hUPaDcw2ajhh3S752TQg5Z3O7xpXWboCxmYse55UROiFlN9LHNLNULc8yxoJDCQEkoko4rEb7 PP7P2xJCIMkAfwJRMSvOuvVw02Aky5XT4yQ4bWtNagO440cywRrYGt+AsMqjPyOpo3wxmhgRt4jG fEsTHScEBtsH6RcR9OddtgttcPzltiVRYgMRs3BFWVgrVRO366Lu1yCe9wKtHvzCiucCb1DGuqsD XLFbsRbZoG0FVlYTAuuC4FLUMsgVuE16ldHlQ9PXNADV02BsTT0NIGLwCBGJvl+0ISmrtUlYoSiF UWkzuVpsrSwrL+FxzQaWcll0rufo5Wq3kuCLpYhj009k22SFoEOwMvrOG1EbPKqOZylriq/NAmjS EVo2VlK2JqeN65+FqexQMvZW3P3SX1mUGVzTASM9Cc3Fm3turlPQBjxeLPEuEeR33HeIHrA/v0yz at3kPThBRWPWLKKRiUgrCIUwF2WyInm56vkTQXLJQpCnVbAmzGP5VbSW7wBMPg6+pcc/NvtOI0B8 JdcBWKnfX9fv5yg2lMgzDOdtdyIGD6efsO1TS9fOXzfwHVc0QMCLkSbbfc8sVSeig8kvQRfX6Dhg AlrLhMb4sw8FjVRVNZneSiY3U3ubFX7iYvINQgx0cTKrLMoEx/QFa80iyulcO6OlUFhdHG8YXOWu 6OcnkVa/xtpoZxIOjR//G4mbH4nL+HbM1HSUCXKq55QGtZLGdchOe5sm66STnesejpvLr8ErGSdJ uJrbQUpc/QKF6wKkuI9Xxa0cCVzJPdrYVjlISJdkpbHoEx45wubAIRKGbzK70glodq4QfdhFHVXN OjV0iZVOihVChqLZr8PcSaliZk46BtE/zsPdKBz5LXDd0Kspq3jHU5oeuPQZEAiuu8kfS9O1rJ6h qGj8Gq6Lq4lfWw9WxAMfD9n/xAdoN8NHPjmA7sBWmjr7q6Y8Kk2pfGHT4MVGzEuWU6tv4jJ6LWHU SGjA+oB5yPq3Qpeqwydbzs54u09M+17HaiV2bM4SIEMu5kKhQ2KgryhNFHk0TeNUVGw9icAgOSdG NXQKlZyJdc+XiY7TEkMzT7zWwjVQ5RQ8jssHemjQSFOiAKUP4HQ+V08D3Z+QPnMR7Wppz2A6DdrK TE2xCswGF6Y/V9s+Z63seGICCn1IMk/UkUspOFFHZaDWm5QxXy9ipF4jtK6oKa9fQAHRuJBG8En5 Oy7jaBRc9gRkbUJ/EWUt9HN1a9bSCiFUQdVkz5Ae1+AIcfK0D+fS0NWyNBdSZNRQlcIGNeTSjBOe +o/Unmmqmxu2+gMB2SNIOrXlA8cKCVMHhdznRbX/hqWqTcG3C5pgmLv5tMAmtoybMYSc2+bN/Vs6 tPzD/+vM0gxqivySP7D8Z9Kl0an++wAtjm3reuB4gPfn8Mz1Nb5o4msfReqY0paMhgj8R8wUK31a GF9XuN0RLVB4Qls8rMCUoTDRBCyAALCj0JQM/xzzTogwhYdepWBKA8DYAwUxSkcnDIyHWnxO17Di ANIiK3tGgykVpB/VsV2B4zzBvzeRhYuHdY+aKr/J/3IUhJZw94N3CBeV73G+RqQmuMwPG1yT1tmV tK4IQJkqJFX8ESVIdcNytfesDk8r4+nHgXXQOzY40RkMKON59ZNMNtyccGQlY0D7B+0PW8NB7ALu p6gHODzA0m8LQjGddcExlwWUE/TdFUofrkVNV3+Ahi3E40OTRc44xvaKwSckZOvbRRYyi21NyGf4 Otjo9iymLAaOyxmWz85gV3q15FrRFhRTlOahfZfu7F0Dsr53QNxOmIw60JX1oXSUPT2BbIrKn4be 4Y4RTmeGHCSBIz2dGTIqZVW+5qmYUeF4EYcinE2Kw2rsJeHIEo5e0VtIx94tgRYjIATOK4xws1K1 Pe2/YqEIRs/fkLniAhCdIUBLNmq1Bx6rZClz4LF2l2Z+N+A3nJaDiiijXCEQ8v7z9wWQQFiED+fb bKP6BzJQ9orAbYZaTJiUWBZk/CEGX6QujryAjJ2d5T+BH5pfXFAtamabvnqZBgB8YAMprLClRWaD aa2W/MGcJEcMThrFWAex7JrAVImQRMU43Sth16/O1UuyUMZx53xtXjcN69q7cwUMPBvFApu9nAPB 7nK+w+tXQUEqisbtIQceY2WpGiaAgV3L/JcJztkt5l0/nBLACPd8RGFyX16FJ4A/Xq0eZC9FhSC/ a4YEbX1AaUskIo+BY7u8Jcl7vZKwl6aX3OWzG/akjb5T6H5DbOIaa1MQVBSCCGprs1G7LhC539R2 JYOs+MJrEU1BvlKGv++kG6ZfA5BS2M7JkIitTkgzJB7+cBurUKm6b+9T4993CBM/eR2r9CHx8OnX A+gG8w+b/wLUVwCQZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iagoyNzY1CmVuZG9iagoyOCAwIG9i ago8PC9MZW5ndGggMjkgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzNXFtz5cQR fvevOG85pyoWmtGMLo8QIIGiCth1bVLF8uDLsRdYX1h7Dfs7kh+cHml6+mupZXu32AR44CDNpdXT l68v4183deX8pk7/8o/Ty4P0f030dXT0o3WN793m2d/Nx28uDn496Ksm/TNOx9+nl5vPjg4+eebc xsUqNiFsjs4P6moYhuD7cYjb9F3Vbjrvqq7dHF0e/LBtdod1FevQdf12szuMrq+cc9uf0mMffdMP 22e7w1BFGuG33+5iVXdd7befy8PnO1/5vnUDLfDj0dcHXxwdfE/kp094Cr39xrmq7YZeyG2iIrcO Vab2aBeq0Ac/bF/t6qrvQx377X5HC7g2JPqHqm86ena/O2yqzrWNo9fjyLZvt29oeh3cELe30/vY 9ulTQ+Vi38btdVqgGaIP26u8aEur1lUIjgZvnSxVTXv13m1reQpjX8nTY/kJ+25khZOy2V4oyJ8V B6IFNiiT5GPgC1/Lx8BSx9NSTeD926HJs5pALDqTn/AFxBhH7G5o2auyALz/WtY6nvZqAxM7rvVW fh7Lzze7w7byTUuS805WgHX9ODYOgVk7ToOfvUnu8Sh8vmsTISQ9R2ckMEK4/Y13u0NPyuh6RwfG Q/fmUPW51tdcCBOuy1pXs7XoQPrtD3KKTt67MulH2RUO3CbgHp/qU/L1sP2UDtFVoSPZ+o5+Vm4I pClf4Qa+6xPnDpl1h66pkvFI/NuLml3Jz2P5yaKbJG+Ulm4QhWRp8260LaTckV4fF2nXgs3vl4Ib RsUhsoYhtiQ1viP7GcZFW0fcJ9v11hq5ByU+DGRGaSDo+Hm2F30Sv8OG7O3QOxT7u52rK7KWSd2Z obLSt7uuqus4tFnQZyYGvujGlBcRkjs5jmsZeidH/27XVrH1g1oKxPQWFYnpe4XqV0TzviylxJwn ncjIPSgEqPekZckPRNYy+NQzpI/n3+cjadWmr9Hwlqf2B56BaJe9fts5X7V9aPSZFa69siYBr+U9 zL8t/OFJMdhMm4668cz9IQR2Jq0L+E3KCIi6TTxEdTsRxWKBzgR7mo0ODp4qV2i5ohsReRHPaxl6 Jj9FjU7FUwHLgFGwwJW57eMO6gEPGUKj1ZcP9TdCG/St5BbBcb9WP5lCoOXEEkuxkieoKuArDalV kshEqbOeiHb4Hkh9NtIfaP5kP0JHWIofPRcTvUEfMemcI0DYsM5Vcx8SXJ8B2CEPFdGiN0c/MzL7 Y/HmsKFd2jZGgJsI39qmqwKDTfrQlr40Ud8Ql/yQQBU/TEa4Hwia+u0/kuVt6nY0XeSWfBySwiXW 9mSlzohPvuqTQv5GUtbXyYEfl4XejAwlGaKDg8Vp9hDIRN6mdXyYsB+TcZaOiAZGz5Oa7iMB2pYg Rwa0X4kag3/dZFTSRXS18PRcDAGLFmHySeF87BBmig8DHzcZueADmktRtxtRx78qKDLt34MSKosD WMpS7Xuhypg2Hmt5CgNuTOsBfvzdzrVVT2xER6X0dPzurvtAPeTZPwgvImC1wkD4kjXjXzjkzaeX abEhNm1b4KxS+lPx86bzukIzB+gAXBqLwLFJ4RlaLz10si+FVIAcwFX4gJtCIJjkvXUqxZG+fXSK FrAVgz1qu7jZuS1UbnZv/mQjPgKjpD8xMoZKAndWNOVsEa8F5U9HYEVS00XUtGtzAODeK1N/Th5w o2O4pHazItG9sXGHogAhmw1KL+ln41vfqmkaITBlpzNUOlFWThuU1ZQVe6XjEhbfmf516YonyeHt 4f1kRUOtB9yNitfQ/7mO9W4lNixzxNgophT64KmOJLJsfbobqrqPvmfLniYtTXMThHtKMo3vPBdl AVA6Ta8J0gDOutt5RxZwdBGsNvn7V2LBCQ835KjBP70WT/Q2i/IovwrHLlGkHQy6BO3JA6OnATTo ak9anWIcI1a8xwhQLTrO6pZCPIfBe7R4vJdSKUPtF1QnTwLiVo7uF6UXPEdOERIJx7aVh/OWLc1g yAh24JOOlTTzUlcg7YUS+SSYfzs5qYHgVF+iQRFW2B6WX2ggO09ZFZJUC8G/N1NYEFeLu6uM5bsx JSLOnTeV7Au45pxvHPz2M2NSt325nbYdfEPTCq/A+2TWJIFs/MSfXzHIs3IqZ+B96D9V3YzhGMu0 qEz+aIKac0EfZ3WA88wsqFIUWdRIkqY1u1A1rghaVKZ+4W7YHzElvVKT/PDvJYMyY29+D2hCBAEe Xpvnn+GgH3CpNbij5D9/YatUJS8wiUJH+vWZpNTS+0g8ijOpVmKfF4C9gHEg679kx0O22EFmheeD sItVMAHhy50wo1A44NhrTOjwtHPlT9mEXJT3bw1Tdgy6/j7emD8KXNMkqzEqJzTyAp0QaMwVaoyF 4iQeSjsOFCd2ClWAx7k1sx3iUgCWAPQC52EjIJUjYWQ9s0p9qOLQUSQIjh9CtolurXZt5bzznaaK H8IcrCso85Dfm+5BIxweem5+3zwFlmRrZvTz/BtDeCQBeiby+NaS7Qexw5hlH/1QpLi79ag7mblg HewEpKlcdgIIln2KUfF1pD3QP0thx3y9mtbin4WrAxJgQtCbNVdsCQBDHqWTBSSCT8tsRrXks2pc cU+on3a+4gIdoeHTRP3eLwM5g93jU4Wry2KmV1QLgNdiOH1uWro3OyKr8W5Y2hI/dDi/tdKaC6+G RkOf3yslX7zAjZW4L6q24NpcUlVYwmse7Q5j1Q2xVgH3HoHOrBzZeK1Kk1oSj/rAaqklmZliZy7s GqXKZ/ACqia3JMXeyizBQOZjD0pVPhpsnYIahnxdmwQAWVJYAPqBQ2+tUEAFhlZlITMcFRTgpe03 01cPRODAYA5rC22/KKZNUeaNpUAgwJCyUI63hE8X9qpGPVzWXzjYEWyeWSs9oVoAwjgxoLOdIQy9 UcfKbHu7IqFGSuYasdAyiQC7ZmMTuyVwWVQzSkJHpUmNSvQFhLdTAEdM9gNr6MJAaq2C6BmofyEI viRUIY0KLFPoVRwsw6NDw2ZhspaUz3e+c2vpWgm9po9a0QIBh+C7oJQGfgr0AdClXSBTjoyMQ3Qd pi7QzCYqM23fpALNX/4/9ZnQk799oD7jpQCz2cWq9U0zbL+ZqiWhbqHEggUYrtRcSVnlpzIbHl7I T1kdyjLPdo54mGzxt6XQ83kpDj1PbUpdS/z8WLWa0A5cvYK8wa2ITCktN1tdq+GnD9VqZlG2dkLS D1Fs6O8yFm2kYYPtnDwMvbLAFTRUzEs8HNDze1XiMTNvYI55kuoOACdoZXSe0B5gF3t4M53c4qdm qlmCjgv5WNvgwsEAELzO1ZqGCCpIB3O1PAeEaBFIznGOImAk0CluQhuRpCx0PWoaGuzwYhVTMrE/ WxxaDfWk28UI5mwhUwGUeZpSxplYi4k0iB9Ky5HdLXEK+eqSmb5BCQbEwnL7kxnzm+1BwFRQMcm+ raFDIxCw8xPKJS8zdUD/Keb1geflp8rfrSeKNVW2qNiNcit+++EiK7tFVWMtq+uGOC6yrtUdp6CD 5CQ0EHQs64lmehFUXWWCHql1mYmuChvMMjSfyPqfdGY83gkckrXOrQjB7gR+kWJAkibnoPv3eZL8 2sWE6xpHvnjsVJD5JIQ9aXioRys9Po79CIZTV7EbXMqXHhJxdeo5u0+hM51DynGWeW/SFoQxGzWL ON5VhAZcXGtLJuDQuzjWp2HfjwENyFiRej+xMZllFopkABcW/Ri5J1GC+6XOX6N1sErLi/7BtD4Y PVXkMszPY73KqjnTaOzQZXCDwCvb0kD/nm1prObZSrTSIRhgvosl+lsSob5LyMZZvVqQG9eJfB7w QvL/dqQjOQPuSO5i6Ug+XRS39Pbg1Btw6mwfdfKYf0I/7x0mcpa9zWDIzDTKiRWE7tG4WQeBoevD RX2wk+844a+AnJXPyBxE379QnuTciaIuhQvdrGdl7G0lS/JP+unp7H2HcnqCYjjNnw40H7LlcKGV admmsGxwYhhmO3fY9iiZwq4NPeoJBNywg118gLVWMJ/dHsuTAJ/+y+wX161RPM0juxndnc+1PuN6 KV/wL9A5k2qVuwCqe1d1wzyPPSndkKZKSRqllol+NGVh5N5OzVilLBoQwDQIYFBtJ3lskzw2vqLI usV9BSF9Y+7wcstxhY3KljW1wC7wkPmCSRF1VyZ7rEUrYQvxSO1ZOrFXyqiGzjPvMADk7HdTlxR4 5lmn5SFI/6xxJDRjDgwyj3uLQtAkswflwWpoaM1q6NqVmrLpampYqJ5n8YNaQNzYF8JAsFUZh+SS Z54EIgke06+EjEzK6aRI/Zh1YUWyO8FuLO0Grh2vo+vkqF7umIGVMmRMvypDrJQpM9Ggs1BmtNwL nN9pcYTLIvaTOvkzj1CpRIEgZQjgD56WDqlSb/RaZNk3m50Xa8nsWev7QhHgvX3dRjyZ0fe4QUGe X5qLa+UQCS3tiwpryCo/Uzlk4/Q+GCTyUBMkNvORdKZPug8ya43lFFFfxVgaC69mxI3XwzaoBdls T7P+FA39DcVtg+eg0ezoNzLGX8n7yzF/25KY3xDLOopJfZJdfr2X6Zcp+0shWDeJ7tizD8njuxTj 9X0dxxRamXVHsjPUsVP9/ddlq7yADxHIu5ZVz8v0jUyXNV/NLgrEfir/pZGhbnKa2zfeoNS1Y5Cr 7ymkPphzeC9p9NPyq/CESzZ/dDCbqiU+J7q/LMEs2/BuWLFdgLglx8Yl/AaTVR/SK9NuP8ECMzS7 8Xu7bH5fYMKyazK0nDdMI2F9tRTbMRvnA0y4sIKHVxZyVFnuyWR2CkOrO0qPx16Mfc3YyzRQH3zh jre6L5Cg7gskMP08fNbXUuST9+9xbVZjAl4VDLSZelOlRTDRZVsZanbWXpgRg4qeAKmtgILEJQQF Uz5hTE4Dll7VLNc0YzlaNAtgNyRychdC86QaOy+qckbG+0VwlNo0l9FR1Fh8NQJ23lcpgbdMb9C2 P6qkFw/l5tqk8XB32axECC48GsuudafE6VFgYbR5mLhCX4diXinqLHWDBMiXpaUYAOpUhCe77Evx COC1Rb0kb9Yq60aYmhpDx5p0O7/YxV8ivYV35vu1ezfYz56HnhQjujdVxYbSmQmoNdCkosJOM886 9fC2a13K8+RHlvnc+HusRTaHH3Z2E3NB7G2WVYbQYkZ3Ft6UzuJ5eLNs2MwEyqp2bQhMGQSlGEfq vttZbkVVmZaBFITET8DfxlYzQSkDWOaefnvsMoNpwkdN2CwuHqx909y9Bae5W97/Xj7K1qSbx5h2 hgkx/tJ/Cycf/isbEKf+B4rIsxb8YN0CbPlE4qyqK9nUiWkr7ZslGmUHAtAJ9W9ZaJ2qA3bWhUNY 9WcaHqsZzHLakDZZXjW3LkLc4QCjMQKG3j9y6/zY3Na+rKYK5NLJbWV+VG6Mh6rME7R6G73K8Ac2 lG35k7QWedeTr3sgUvTW3W+IFFUExQHYPH5K97ytmAmjw4cCwan3qLwn5Wqq2PdTA1q+Mm6GfxI9 vtj1VU3y1+YuJd8P3JvUtHFMS/EkiFMxvNM3zqfaLem4g9JtUKVbN3jCl8xbgrrkOseKc1dFsqCJ t/KQvqINfcqFpKKrq7up5kNmKRJJn+4crUiHO0LdPP2WhzZkbEnI+sYn4sc12xG08sjXZfnRRBH2 InGUNb9LNd3e1X2kkx1Hth8phnVdrGJOTHBq3c/gQcEx+dna9XQDEQO2Nf+0hR3hrqTPSsZyhjky 9uWgKc4u0Bvpb6AQkuprf+ynjIX7ofMLGUEFwypmsLtAIOrD8KFg1rFlM3q/2hAKYGKlvMLrqvLK SgI73zPkat9YtOL7tZ9Pl6ym9gUGDt+YW60n6/Mh2RfvH762awKnO01/loz369ky4rqVZHm5XZWZ gEAADkiivplYlbtvTbrbSIQ8oazKJMH6j5dVmblS9ZGWBeXuHvd83x/8F1y2UwxlbmRzdHJlYW0K ZW5kb2JqCjI5IDAgb2JqCjQ0NDUKZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAzMyAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nKVYS28cNwy+z6+YW2cCrKL345ikQdEggBN34R6M HDbrtddN7HVs59F/X0ojidTOGA0Q+yKTIsXXR3L8pedMyJ7H33LY3nTxL2UkNwIOVijpRX/6xyL5 /qr70nmm4k8Sp+ftTf9y3T0/FaIXEiR0v77sOAshaO3TDdF7x2zvpGZG9uub7nzQo2JBBq4HNq4c M0ZZM0hCFCxY7QXQVsIwwV0Y+nElLagwcjgbOXPcWTGcAJEZofXwV6XdgbQXXothM64MM957PWzx uJvesTKqTI97O7yu4j/wJmr6XC06RBnHOTfDPRjHpHGSqMw0Gwxo/7B+071ed+8hqjGyPxNG3wvB rAsew6hME0bumNdTGP8eVwrcD9KDBSAnLJgKTgXmlTN+2INT4AeH46byv4EQc8LYIyEFiQ/g4MUk ZCEoOzx+Gy0zVktNiZ/HlWbCeEjeIb6qgpEpaklrlK/Ei0osTzlXjbL0/TOIoGDaAfVkFI5JbwJk txJR/QYt2U5O2aCyfUqr5JWEmhfOQ34hLyJoq2OCy92sS+noitBMx1I4VCIk0zKpbMpw1Xo/asa1 klT9NYrfVnHi1Bt8c4OapqDKECixaAWpR6BqLSBZYBS9UNQSsW3VtU11Jz1UgdZQOOsLKJVdteoB TSHHRmm5ejvlz+qQq+LYwBugKmmljbmsd2/xLjHwCo87GiJ0th73lb+QTOBfTiXupYDAW2hqClJQ MmjF3FmtU1MBiEthMzBXJUIroSDKU5j+TBGX8GC0p+AInvaCueBinlPFc1mDN5kWJONQ0aU4c75S bT5U6Dwg9K4ROh8XAUVgVtXbeUUcX0CcLfOJgj0FOgFiubotsVMFEsC/iVEJ0K+b44GUDE1YUYUl RYBKTLleQh9R9VCLmyglkFh+tfG1rSgTdHO1qaiagyYdCVTWsNSOU7EQ+DB8qhaLy9WUqOSBxbgQ 4hm2qpPRMc61o+w1tB/tdZA0AIelRkYswQB+RaG7xSPRWjvdI1q/mIqLYxluA+0IVzQ/0vkJf1Mw I/yUnCK6wYF1i8cLPPaIT0Kd3oRJ3I4hUv+00kpKH5ucLaQfgUsUELWHOj4JsFGIFPXHih+SnhZ0 +fkG4At8Yt5t5ZP0oNI8vGCVaMfEEv6If7MG0VYCqY6vi/ndk5ImShd6exNpMoiq1PdRMg2vanAg oc9wJqUo8Pu3qcTs//cxbqEe6qPJdOU/Zd6c346eo/iqozWiXm1WotppmkUCt4scU5bUa56MmqCR PcXRBJz1P2WZjL+wlDuY2DrYXskYXNcrLngvlQTmrrt81sFG3k/be2SJJAZsAas4NO4kKAIsm/Fz 4Pmp0v3vB1D/c5fNdPnXl1oNrsKHgvKw2tu41k6erpRVjPvYHuA7xGMIckTexj9/69bPzuf90gSb FsZMvJtvwWm4gaYQjD2atMBlXLm0MOaN80eFNAH/LNGJSkC3iETywHxlPEZy1Xo1IQ22s1w0Aj4v Nv8jRHoSefUduvW2VuILDBZZtHHQkDn2qmIyKnWaKeGGc+R7hMKHpr+Wu09sl4loAr1J9gvSwD5V 1BOANkOpyD8mLCkOVtSeQVpai++nswKWzgLc9kQy6HALf1zs2U8tSsVm/CA5UO/Ixl70Z0O1EGW6 kOFvj9wrIzcHg268uWEaXMJcyEMgjdl92WjJd2WZTHRHbrZJgodSrk/NuNk0baDVFHGVIkOUxPbT /MO2GZ0vxhA7ivT0AfINiUW4CE3y/jkqtZXflnvhH+btnnDX8X8NLhgucNV7h2BEsBGEEpnGpHp0 ixCcNlTJQ54xeevKfbTtqmnMwBzQQU9dOh7KHBBckTlg89D4pRlguIfM9ELK/K+NPAPAXEioTzPA H03B991/pUHdW2VuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTQwOQplbmRvYmoKNDAgMCBvYmoK PDwvTGVuZ3RoIDQxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVRNbxMxEL37 V/iGXbFTe2b8xREVISEkaLo3xAFCUkCNQlI48O8Z7252XRGkSiWrSBP7zdd7L3vQDjxqV59TsN4p p1/L91YdVAaqn+Gijdc7/bJXl6usvYeYStb9VjkopTCFAeF1ThB1wgAUdb9TRtv+u/IEzLp/q/qL D6a3DJwZi/lqHeTMLmSzsVLSRxZ8VyBTkrM72zH4kB2aTwvy3kYIkZHNzxGa0UuWkw4++SDQsVI0 R2nk2Jdg1raTEUoJ8dQz5mi+TfVjkFJz/mYBrM+1+tXU7yIgCQ9t0ouhFLoiQ33s39TdCevu8vuZ etWra3XQFNxAv0aXSegqMlzUJP2F1yrG5YpRX+0r+ElyBJcgoWYOkBpBOhkQKGTdeQdREr+cU+q9 0Aa+sMgycokhmf0ixY9WvzlcoA2rwrUX2UkI2swE3tuOQG5jngSsrO0XKrf/EHgGNKfbB71Out4t YSPR8wWrz6atLILsEop5Z30CzBJd2S5BTkxkbhZezs+1eLS5P5kwlglKTH7icAib088jR8Qtcc0y f1m3Mtcc/rY+QmaKBtpdqx8XG44OPN6qRIIR/yGSdE0aS2TxFCd93KjthfK6PgI81KvJWp7zbFxJ dItxaTLuo8A8gp/+4mEmYU9jTEJ943QKUV43fnB6Y/TzDBQUBuX/gIR16kJnGCD001KF56UKEkRJ HJcKMwOPAMf/xQDFDINw7sHLd9j0Wv0BJO817GVuZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoKNTUy CmVuZG9iago1MCAwIG9iago8PC9MZW5ndGggNTEgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJytVdtOHDEMfZ+vyFszlSbETuwkj5QCUlUJla76gvqwYpdL1eWOyufXmZ1NAmwlpAJC Cie+HNvHmVtlDaCy+XdzOF11Vh3K33l320Xj8s940Z5PV+rTrNs5jgrAcEhRzc46a1JK3tFoASoG wyogGcdqtuq06me/uv1Z963L2RyhJZADg8MI6vhwK3z3FhYAClA8fGXhY8uCUzIOM4sT7XtnEibr temHYIgck8YGBJPYR9CuH4AM2JCE+oDsxRb1bg8SURhkcOP+ox+iiWAj6SMxNQTe6++9NcEGBn2T LYO1lvS8H8hQjNHr03VORr0spybmgRCJED3oywr+LuyWNdCeEDXeOtYXxee6prwewURB31efmvIu eyNxIsn+c/ZlM6J3kwBHNKGRADjjZVJfu9nHE72fs0Py7PVTPzgTgB1IlyQmCLbqh2SSlM7SRGuE OUeWLgzeAEVpyHKNQpTYVuJCgLHi0Z31mUxDlA3SsOb+oR4vatRl8WpMZbKC+iDoUR+M9DOxTLaQ vilO80zVJcI82bES4rg96EGeQ0hkx9luSpGqwBvvnlHZ61FG652fmDrv8nC3He97NsSYUtZGpsI+ yXS9EXds01/WRCtBHTJymPo7RnrV3xFtbCd+wuqq3j/krNFFhOZ+Ue9VvZ9vY/3sPgsRE4rYWZQ0 W8jiXrWhSjG77SyKwU0h8LqrAjYCMGNW2R4/yX/YpB0moS7ap+tWObLje6nQspP3TfSZWDkX5c0K +fXcOSZUn6+z8X8tD1nZYFQy/bo7g8f8RkYhJ7VWbmWn5N8P42JVta6LRemLaGit0UZik0JQngc1 LUugRoBPVcvzAr51LTPajPVPn5/pSNTKvpHNxbZlmW8N9VjRtYLoX0nnLy09+im+jY7avX2lMLSp FVhTYKPgRZFVs1hXBWyobFXlYwHPa8xnkQpqCqm1VMdhy+jzp20a/UakGPxaRl6+phuRgiOqInXv IVL5FIkOgaHRqEtCHd2oUY4vFuhb9xdvbLesZW5kc3RyZWFtCmVuZG9iago1MSAwIG9iago3NjIK ZW5kb2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nMVaTXMbxxGtXPEr9paFq7Da+dzZ3BzLSTmlimMa5QvtA0iApCJSoAmRivLr07O7M/0G 2xApp5xIl+V8d0/369c9+LVqG6WrNv5PH5d3i/iXcbp1ij68Mjqo6uyvYvPD9eLXRWhM/DdMx+/L u+rP68WrM6Uq5RpnrK3WV4u26fve6jAMUVXoGl91WjWdr9Z3i/PaLVdt41rbdaGuliunQqOUqn9c 6kYHr3S9gwGXy1VotLGtqh+Xq442D17XD0vVNtp3pn4bx2qnetXVH+KANrjO15+WXaO19Tbu0DV9 UMrV90uSr29JsnrPn7ewAq4GO3+aDuRCT+v9sv7b4tv14gfSV9TZSxQUKqUa3/WB9WNcoZ/WNpN6 viE92Na5vr6hQ4ZA34HOSwsoEodOqGxjTdfTAX3jvPFRYcNAH3wUt2+CCVoNMk6tV9xaUau1qiN9 fODPGx67m7Yq1trkxkce+YH7b3L/Ljaa3mlbv8+NMJIEsI1ywbuoYdPQ7j6k9Uloeeg+L/UeZc3n v4uzeme8n5RhrFGThnQfVTmcyts+bWXstNQwErY6jKfyvcFVx71029cXeT7sBKf+ONyfLfvhcxJA hfpPfP7Rql6duR4tRXWNo9NXK2Wa6FvbRf2H5fqfxwblaD/TRnuiEeeDxXsy406jsvbyteb+R7ws TWihwguuNQuQ7DJo4VpPDPXza1XhhCpWScjfrIv1kjYNttf1G5b6RzpLo/oRKPIJP2YXBLuQvQVm 3XMr6PXA2oBP3gG89GG58oQ4JEm9BXXkDX6ueQBr9mkZVdL3Lm1bGPSAb0kE6GcrvuXr2OXGn5ek LTJiXQJK6n446u1onzVBedP1jvDyTR4Y9asa21lf6lfpxgdrSv0eo4kpLuWS/XLH3jzpzNMFFybm Kdwp3SHyFcgTbYwCSOONSrbCwABH2UlHoYuI8msbUKVPfEBeCoy9uIjUf8HzoR/ggoEHgGnP/XvW xXu8vtFSbIKWle5M0xqL/lNF/5kiWfxPsb4ztFvvK2NaWqqrdCD9aNJk9bBbXH21oEBfjaQgdo2E groNBXhCynEicYcusoxXZ15Vr/e0/MsG63Hwfx9RLS2vbWV6S4QiBtVR0pWxim7VkApIe6wBUggd bv0m/vnHrI//MUGKZzMyQYqMRBuiHj8tKSB0lnzpLbQeYDTylwumOG+ZA51iOye40+/BdYwm5wmj qBMo64LsJAYShbeO7qyz9XejG5DJ13+PR6U2Y2qdUfAfDDQGI904352A2WsRsjnAgff+e+AS5PMY CgHR4150h663gM0FWZn6HQLR2ShLDATfk9pbusb6dSYQBXrm6eD8wGAKyMhinyAjCSfejee3pFXY AGjPoxQmylhOoviWuMKKkXiL8CfwKoByGHCPUBgNz6ieDDvjM1wGIx3gL4SCT0vlm8GsQKyPrGsh kr3jM8FJb0SgvYeggLc6HM8X11ItdRcGAE7SMACf13/J5r9j87/gz2SqxiXeHVs3oi1PMtshKHsV WwM5SB7aip99YaGO/NV1Be15Lw4ACvUpO8YeXSj7CMwaD04uosDHtsUG6eBMkDACQ7fAIG7FT9gf DHtz7AMjrxC22mBjWukezW6yIJ59YLfaSeEZHAjst3CrgZ90IWZ6yf5lvy/Uy6wi78qm/ihuBfML hpsXEJUCax1O6C+tCscu0tCVjbE/oFufZbQawVCrvkDDPkYoHcCpkopWUxCfcGK4+zbnP9FpKg4g H/iziDrS2J84QQBLG+9c9QVr5QwKHLQwxKzeUTzX++TsU6aQiDzn4LxTwfOFxHoPcwAIk3M2w+5t MIkRTjD0/6U92rlGj1TAy2Whb6ICHbVqkjA29WHM3CducwnTbpnnPPKII4KURkAJaFououjvQ3nI Z5p+khPM8yyDHBvE64nduDI3XWlN2RURtXO+cZdv/JecJMDIIvYmM4j9xtEROzAyOV0tAkqaBBix LzBe2PUuqlV7SrMwN56lOUNrUcARCjQlYqXTiLWcLaJQGnkPET97B0DTk0hJtjPSZAvAA7k3BSSn ba+RP0ifW5w2kB5KvJjzyDkfqPARgopcOIOgIeiluM9CgkmunbRAgirfZ9Qb+BcZjFPFFcpb3aBe Ja40KgGp0giE2nXZ7oJPVQyL7OiQy6KpkNU5oBs7tPXkFSWPLyPXvIB6xGeOuRGEDHZrcOaiTpSO dYmUYWjUxVnA7Y3g9o14Pi553cwMuQzSIrcG45MZS0m40gIbiecURT9NSU1M32QaM8OtWMCF/gO6 6ljH0Y1qQ/IZgJJ78azP0LxTUJL2v5TqPLIoF0ijpAFbBAVeSyZfaRIndbPypCW3RfJ2gv2BsWQm NSkRfW6eCNosvVFInlIdkD7nJNsW+cB9boQAMqP7BfVpuMoI5cjv2LqOosNUvZ4nn6ODQ8WWjyIX bBNAgPle5EnzymlZXZ+Ts/EeU+Mp/4Li5pRayPIVSZCQnN8UJnf0lDMexUTiExQ4WnF94D2poHo7 uRwRHp1dDg7Fby5i6JHrsdeSmUKgPpUlPR/mplMVmWfW71a6ledu7YpX5f5bsczL/eyyxU4vDohJ 3+idkLA85Zi358ZbJpoQHiH5ASZapO5gykeS2uNIKIoihFpwOigo7PAzY8E2L5AchDZo0AOOns1y JrP+6rz+umDNCZSgPPgmIRmMhEIbx0zAF36ThQePc+4PEJKP1ROHwpMYa7KIU4ApyXr4EUOsTQqY 0IU5n5se/+SENN8v+zc4VVEZOYaSKNaM6dhuTnSGSQw6lyfKBUmAb3n+v3joveRpQhVvh/CR36jG YgqxUOWhmCgUJsGin6twXIlDk3bNlyCKVEwqUpOEqADzDF3zq+GX3ePWg7TU3A5HNUdBvLInAGlS JwLShlGGf5sAfCHX9Q/cJgdm2YqLAfBY+PmfLnAQL+4BSqiJZogYBJteIbXgeJi+iswC6uo4/7P7 w1DJs6D7a8YrvjKZ7MJFc2j+bfEU/KCAYyBn0TaGetIRFMONv6AQlzJKuEWoJQAanqpTHz8al8AL Q6G/SKqFHLHIYACPpW2LcJls5tlf3nyOr2pKoJnvwfXAAwbkSkwR+f1HeMgW39zFXPCdCJIygxEf 0iu0swGQXdfALzWOa7/5IcwHd+JnBKcwXEpVofVJgvNZzXRUZJ50LeVU8CQkUsmDxIVndvbltDaD 8KRCBOErJj3ABbl68mL3Q0GKop7MWuaZ0Ow3WacJDLj0C38oJDscETTZ4TZSZGDk5eUhY3+UgK9k XWmlLyFC+XPOhOwRz82SAJKyHWxF654FmQklRg4Unchw1ib9fm6DNpc/RacA2iX8vA6KhFjbkGgV qHL6bQ0t+n3sJ56hNQQ58T0te8RQt/9h8R+iy9tLZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iagoy NTMzCmVuZG9iago2NiAwIG9iago8PC9MZW5ndGggNjcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJzNWktzFEcSvs+v6NtOR2hK9X5wwzaBTbDhNSi8B9uxoReItYSwQCAue9tfsPuD N6u7qjJ7JnskEWO0EBA91fXM/PLLR/UfnRRKdzL/rQ/HFwvZPYV/rxd/LKIw+c/wgj4fX3TfHCz2 X8ROKeFDit3Bq4UUKSVr3NBDdTEI3wXthPHdwcXil+X7fmVEUN6o5WUP45S3y+t+lYRJLvrlVW+F tNqF5TF2PK0d93oprFVBuWWXx0QTdX4tRYzWw/BDfCwLOR+Xn3svnLfawqg2wQd8vMRRZNprOled gKw12Ux7fNWvNIhRRbU8h1FKKx3oqJthKueWb/qVssIaaDsq5/MwpDWetkYy+6/LQT4queVJEVrb lLEgqle4f1jACgVCdcu341zG0sYPvZIiaOXpVi5bz7c4abcuqvWlSIcLeDTaax/oWsfDqXVKRcFG V6GruFz1vx08W2jrRTAJUHNwQnCSDD1eG/0RX0+WIYPqQchMv/Z1PI8kciQUBNHJOS5FBPGpV1r4 aE3BST4mmZQA7QwHnbLiJa3khGQtsoNrbCVLvGG3OKfMekaC2q7XIWaFrKpGVsrAiFEt40oaZiqH sdJFNNBy7ABth/h6w6izUZ41fBP4fVgXxWAzx838PrDmedWMYs48Oa4ga5FtCWJsfZtX9Jyt19NG A49ZZE8OFj8tMo0ap6VT8OCV0VF1L56yzVd3oVelOuWEM1kFlV91pPzqoxHajvz6OFt1UjIs32VL TBKWgsdVgJmj1yCAVRSgPzmConQ4wUfQhhTaqaQCkFXrDLDQIhnQ5uNee6DzpJeP8rQyujDwZhv1 H9BnENHFAH2NAFA5VXajnPN0Y5PdRABgipbZjI5e5c1I4aQBGNflhvaDHsQTbRoYL4gUtUyDcr01 Ngz22/qekjn+C5iHdVKKU+3tzO1570E6o1r+3WvYYxjsL69VTOr5An7/ZfzvocADeHF63OWLpq4i KBtCBHIYZCnlBD1XcCJnorQzkDomM9DZ3pdnF9OfJHeXqjnAAgf/HIeAq7P5mG2ImgyJ+YijEH4B +IKwrU1LlSESZASI/NaDqasUMvSA7gFOEcTlAeYaeEngmK52/B7anLAJfP0hYNt6p0eUj0+Z9YQF ggxZJDrzk8tU1x7Phq4WZtqjsxd2BtVKeqqQz6xCdZ8vshswJfhohyALXWLrda+S8CZZ0Ck0au2V ohs5bXvucCN/7VdOSG8Mef0BXx/i9CftPWksXV2kwumw8dUo5ez7mM2RjmSiM5x+Y8v5/c99gHjH qEBlT2YlU13jVIdtA+fDnrwb6D4rOcLpfxz8bTLSQRi3LuigyU6u4CnZKGN27eUtL5FLMqbt7nPv pBRSqlH7E0hrDRZhfVX+XttdhkvIeKfeCSgkShkas+DvO1HK7cbkgQ4K751tHDCjgzy+a2d9hI37 7OOnZm7lCVwQPhETJOr9yCIeISeqNQdimiyiyUa+Q+Mikx73WVoQ/gF66viL0UpUstQM307mL8u/ zzhzEl6Tlc7xJCNUFKCXIGVi23m8UrpOamCiioMXTUxot6J2O2sIJzNftH7n4Pl1w08wsrMhDwid ihqSu+7qdPHqfvw9ix8jIeTUBEEjg680LKit6/KOIUUdUE54Wj88T+eue8zsU3mvv+WRRLTOouZ9 Q9rvQ+gs8/jPDT+TbRDChmxUae0o5sn75w1fCP9LbnUikBmiWfdNKjqhfaOnbebjIXfaMJ/BycxY T4ErofmXjeabIVC9Er/E8AEh3BMi78rXyPuo10Nua6TxNXVL1dJmTkbIsi70iD3kU3Q71xPNFAd1 wpDZOczpk1STjm/p7rgDQ7xRvc6qKjKPzgWdrE32+ES2BGJ/y2mWdUo2OTtriLebxBxM/HDNqem0 h5yC8YkBIlEvVQVdM7k9iv6v5BYVZAIJaM0a0fwi42Jud4vlDPt4hk+9Av3ooP58p8iAc79a2MSm K8iPG4wmJq08ZAvBEbyxJo0g3MdGxDAfOk0cYiUU8h5d4m0s9BLBSsYjGKdgzvmclIY9vKAhKh4U NqKV9CCRofzlIJVGjpw6XQWZcwdr2ex1tfJ6t17XDgk9wrM4XWMgYHVmYu3E6ZptTjeQaPtHgGOK Slkq03cUeEwMdcp71ZL9fA2bdTan6M6oIVMfjZYGSuWc9zLaL7PFMmrGFjdX+g4jGpZceQfLuMiJ NVbDQBMiCdHhxIIHSqDuhFriWmg6g5OMde00kekEJpheVZWQcJYhk7lwVoEKO2uHigLEs07uOJ4N fgqiGs/GBE7VzZmWvb9pHWTTchH45El7+23zA98j2T2YOZkcuTtQl+Ryw3LKiTW1148Yx0fMiZgD W8sghvWxEcwla0OnnL2UjSY9cahslk6Cvf2N3BvE7ztrZMxgiwCInWJNZ8IiAi5Qy7FHTLNQc9uh 9mb0tyGRJApBR4gGo+6HAphVIoETGzNIhq+5IItHGMn4t0ZZtU1QeXGVJYK1k/UAJWORTDCDqhLj jjAC3gSfDQcFGIUYdwwj43M9GOVYcWSRsrTdwJHfjqPHDR4luTVmpkhIJEg80R7O+RUhBQEQHNUm MKxbOKsc884RADn6Ro3nTgIhRHTdCsWrVmIkpQoCeAKpQ4rD1veorfqaRCBl+60mS6ZhSE6BLK2S Q6yavOn8bkkux6ioEUJyep7kwgw4y+vRd4aUFOE2Et+jH0UYHwwhSnD2obDpVE4pbRwLYrvEJqW4 FjawbMejjEALa94Er0fce1KSmPJiuyVgcrQW86Hb/53LGv/Va5FviRKJA4+4MBHD0kk5vi39jtsF E/tyvh+SO0gR5RBoOrXrwqkBu7AEDjXQtJDaxTnSjttJm5jA83ZGNIGX1BhK8PlDnebb/5eI03rY 0a4jTrQlnr0RwmT6N612QWJLYhdzt3NMQMDlyeTKbHtgetrT5HIYsuXuYzQLNpQ1MNsAZ2XDjoOQ BK880V2FszQirzzD8wkD9Vbv+2F73vR4Ere2wuDXDDLyZzCddaFdw39hcXDLndmkKPil5UESexTZ ssXjSUWCylHJZCAjTm6IW0PaMWS0zVf4KMcaGpiQP2yagwy54pfbowRSvMLrtG8eHj7526jOWpdR tOva8hpkZpIeQlwblyZrl2UEcTMlfpI/E2asdEcY7Yh2rW57crPB3EaQRW/ahWmjQZTMGevzcR16 /YOBeuV3Yhf/oAXjWtQ6JGE22do0yQO3DeGFGQtTxu04XnB+INgGm0qwwLhGmbmAgVjL3Lcxpecz 1PkkHiQOaest44NVEcKQ8hmdo+vt5tTi6hp7EsjfEj/QesL2EJsAelJQYLC9ETePVartwidRMovf E47ib7i7DWInE+up0ml3Rc9I5HwPZEysQ+sAGE5j2dZZvdss04D6dSQoaNG0zVq9gy+Z+yKh9HyM vuSmaY1NgcggzX2Hha7oCc5JI3NwhylnPg/ln4ITOlerspfaUXRT5In28p51MIcshyP3blZ4Z6Lj 2yu9XJp602C++QkJWI7mTFBxjkNxPSc34NvvPFfYFT069vzCixPrZWdsHBOAAE5ktxYY1ZC8NdxU C8wOMYY7+Ke568nS82e0ltvvJ9kPFLDo1sSLDEq+v5yUy2sjWijJt3EhLE7cp5CHWSHp2rG+4G3b fjeJnQpMZ7ZfwUPkBFySVafd8u8wexSQdQciByzHYNseoutrf59oQNQBYCVhIHtJMBgCft8wqQgw VaLm0/g8a82fm7tcD2x+g0N4iLncmvDQF4XBSATMsZEU3rGER3Pq9knSNjvSdnp/65wDHYUGAO2l BwcchyxRebnjyoKTbsiXGgIKsVjQlUo0TRxflJ/0Q/1CPRvf7v+0+B9UpUpUZW5kc3RyZWFtCmVu ZG9iago2NyAwIG9iagoyODg2CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvSW1hZ2VDIC9UZXh0XQovWE9iamVjdCAxMiAwIFIKL0ZvbnQgMTMgMCBSCj4+Ci9Db250 ZW50cyA1IDAgUgo+PgplbmRvYmoKMTQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRm9udCAxOCAwIFIKPj4KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoKMTkgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUMgL0ltYWdlSSAvVGV4dF0KL0Nv bG9yU3BhY2UgMjQgMCBSCi9YT2JqZWN0IDI1IDAgUgovRm9udCAyNiAwIFIKPj4KL0NvbnRlbnRz IDIwIDAgUgo+PgplbmRvYmoKMjcgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRm9udCAzMCAwIFIKPj4KL0NvbnRlbnRzIDI4IDAgUgo+PgplbmRvYmoKMzEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL0ltYWdlQyAvVGV4dF0KL1hPYmpl Y3QgMzcgMCBSCi9Gb250IDM4IDAgUgo+PgovQ29udGVudHMgMzIgMCBSCj4+CmVuZG9iagozOSAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvSW1hZ2VDIC9UZXh0XQov WE9iamVjdCA0NyAwIFIKL0ZvbnQgNDggMCBSCj4+Ci9Db250ZW50cyA0MCAwIFIKPj4KZW5kb2Jq CjQ5IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VDIC9UZXh0XQovWE9i amVjdCA1NCAwIFIKL0ZvbnQgNTUgMCBSCj4+Ci9Db250ZW50cyA1MCAwIFIKPj4KZW5kb2JqCjU2 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VCIC9JbWFnZUMgL1RleHRd Ci9YT2JqZWN0IDYzIDAgUgovRm9udCA2NCAwIFIKPj4KL0NvbnRlbnRzIDU3IDAgUgo+PgplbmRv YmoKNjUgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA2OCAw IFIKPj4KL0NvbnRlbnRzIDY2IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMg L0tpZHMgWwo0IDAgUgoxNCAwIFIKMTkgMCBSCjI3IDAgUgozMSAwIFIKMzkgMCBSCjQ5IDAgUgo1 NiAwIFIKNjUgMCBSCl0gL0NvdW50IDkKL1JvdGF0ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlw ZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDczIDAgUgo+PgplbmRvYmoKMTIgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNyAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggMzAwCi9IZWlnaHQgMTY5Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9EQ1REZWNvZGUvTGVuZ3RoIDc2NzI+PnN0cmVhbQr/2P/uAA5BZG9iZQBkAAAAAAH/ 2wBDAA4KCw0LCQ4NDA0QDw4RFiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIySGJJTlZYXV5d OEVmbWVabFNbXVn/2wBDAQ8QEBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVn/wAARCACpASwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEA AAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJx FDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJ ytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQF BgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3 eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0miiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKY7rGheRlVR1LHAFZz6/pwYrHObhh2t42l/9BBFAGpRWT/bYP3dO1Fh/1wx/MilG uW6/663vYR6vbPj9AaANWiqdpqVle8Wt1FK3dVYbh9R1FXKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqKaeK3QvPKkSD+J2Cj9aw7rxloluSq3Ru XH8Nuhf9Rx+tAHQ0Vwtz8QQCVtdOb2NxMqfoMmqM3i3X54nljSCCNQSTHbSPtHrk8U7MV0ejEhQS TgDkk1iy6vNeEppSI0XQ3cudn/AB1f68D3NYejWuraxD9p1e9lls5ACluVCCQerAfw+3fvXSrBgA ZAA4AApDKA02GRxJes99L1DTnKj6J90flV9flUKuAB0AGBThEP736Uoj9xQACnrSbT6UooAiubG1 vAPtNvFKR0Zh8w+h6ioBb31iM2U5uoh/y73L5bH+zJ1/Bs/UVfFPFAENjqMN7vRd0U8f+sgkGHT6 j09xwau1m6hpyXyhlke3ukB8q4j4dP8AEeoPFceNQ8S2F3JaT6jG0sS7v3tuCHXswIwSD+h4ppX2 E3bc9CorhIfF+rxf6+wtLgesMpjP5NmtKLxraJgX9le2Z/vNHvX81zQ4tApJnU0VnWOuaXqOPsd/ BKx/hDgN+R5rRpDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAoopjusaM7sFVRksxwBQA+mS SJCjSSuqIoyWY4ArnZ/Ekt6Xi0C3W5C8PeTHZbx/j/F9BWBeT6O0m/XdVn1qdTkW9uCIVPsBx+JN AG5eeNdOjlNvp0c+qXP9y2Ukf99f4Zqmz+MtX+7HBpEB9wZMfXn+QrO/4TP7LF5Ok6Tb2kQ6bz/7 KuP51nz+KdauTg3vlA9oY1X9Tk1SgyeZHQR+AluJBLqupXF3J3PX9Wz/ACFaUfhnw/YqPOijbHe4 lJH5E4/SvPZry7uCfPu7mUejzMR+WahCJjJjQnPdQarkfcnnR6lHeeHrHiKfTYMdkZAf0qldXUHi G7W2t5Vl0y3Ie4ZTlZn6rH9B94/gK88yqKSIxnsF4yfSvQ9Hsxp2mQ2+MyAbpD6ueSf6fQVMo2Kj K5reYO1JvqHn2FOB9P1qSiTNOBqMcdc59O9OHPpj17UASKaeMHr+dRZ7U/P/ANegB2KcKaDTqAHA 1m67pUeqWynykkuIDviDHAb1Un0PT24PatDNLmgDm4fDen39olzZTXNtvH3C28Ke4IbPIPHXtVa7 8PanGSUMN2g6bP3bj8DwfzFbtsfsetywdIb1TMg9JFwHH4jafzrXqlNolwTPMJrS3e6ZNQtAjkEh Zk2sfoe/4GpLdr/T1B0/U7mJRyI5T5sePo3I/A16LcW0F1CYriJJYz1V1BFc1qPhl4UZ9MYun/Pt I3/oLHp9Dx7irUov4kQ4yXwsrW3i6+tgo1PTxMh/5a2ZyfxQ8/rXRaXrmnasP9CukkcdYz8rr9VP NcQ7bmPDLsO0qwwVI7EdjUb2cFxmSWP94n3ZFJV1PsRzTdLsJVe56bRXn9jrmr6YQrP/AGnbD+CQ hZlHs3Rvx5rrdJ1yx1dG+yykSp9+GQbZE+oP/wCqsnFrc1Uk9jTooopDCiiigAooooAKKKKACiis LxL4hh0K0HAlu5c+TDnr/tH0AoAn17X7LQbXzruTLt/q4l+859h6e9ec6n4judXkD3SB4gcpakkQ r7tjlz+QrIup5r68e7vJWnuH6segHoB2FNzWih3M3PsWru8ur0KtzM0iL92PhY1Hso4FQgcDp+dN q7p91b2sm64sY7xfR2ZcflxWm2xG4t3YyWkVq8hGLiISr7Ak8f59agVTnt+ddh4k1jTnsdPH9mwz mSAOm5ivlKeMcc9v0rD0jQNQ1hvNt4Vhtj0mkyFx/s92/l70lLTUfLroZgVvQ0oOSqLln/uqCx/I V6FYeCdNtwDdtJeSd952p/3yP65roba0t7RNltBFCnpGgUfpUup2Godzy/TdMujqlgLi0niiaXdm RCobaC2OeewrvfmPtnPtTNWJbXbFR0SCV/1QUKMbMkfnWbdzRKxIMcc5yKcCT0HXqBUYI29zg08E k+xpDJBxwTz2pQSen4imAdj1HQU4EkcdaAJAQBxzTh79OxqMcc9+4pwJPT8qAJAcntTgeajyBx29 adn86AHn1pM0A8fWm5oApaufLitrroba4Ryf9ljsb9GrZrF1v5tEvh38liPqBmthTlQfUUAOoooo A5zxPp37htSt1xNCuZQB/rIx1z7jqD9RWBmNoV6KW5z2ru7x4orKeScgRLGxfPpjmvOowywQo4IZ Y1BB9cVvSfQwqrqWEjYSLnp61XuLdJ5RNl4p0OY5o22uv0P9K0NMaJZgbhnCbgOADnnv7U69jtmv ZBas33yCGAAznt7Vo9dGZrTVFrS/E8tq8dtrhXa2BHeqMK3s4/hPv0rrgQwBByD3rz64VXLxuoZS NpVuQRU2j6tJ4faOC5dpNKfhWbJa1PofVP5VjOnbVG0Kl9Gd7RTVYOoZSGU8gjoadWRqFFFFABRR RQBS1bUYdK02e9uD8kS5wOrHsB9TXjd/ez6jfS3l02ZpTkjso7KPYV1HxG1MzajBpqH93bqJpB6u fuj8Bz+NcfWkF1Im+g4U4A4puQPSpriCS2k8uYYbargezAEfzrQzG46cin4HHI/Ko/4RTv4RTEdN 4Q0iPWL5nuz5ttZquIz0YnJAPsOTjvkV6UAFAAGAOABXm/gXUkstVkt5mCx3gVVJ6BxnA/EE/iK9 KrCe5tHYKKKKkowdYQrrVlKfuPDLFn/a+VgPyDflSDAVeR+Fat/Zx31q0MmVyQyuvVGHRh7isJnk tHW31DEchOElA/dy/T0P+yfwzQBbGNxGDz604MWXHp2FMyAQcHPvTt2Gx2/pQA/tkn607djleKYo IOGwAeKcpA4x+JoAkHHPQUucdOhqNckkHNOUgcd/60ASDjr0pRknBP41GvPX86bNcQwpmWVIgO7s FoAsA5OaGPQ1QGoxycWsM90T1MUZ2/8AfRwv6012nlH+mXlvp0XdUkBkP/AjwPwB+tAC37faydNh +aWYYlI6RRnqT6EjgDv9BW50rEi1XQ9NiEUN1DhiTiMmRnPckjJJ96guPFUKbfs9lcy7skM4Ea4/ Hn9KaTewm0tzo6qX2oWunxCS7mWMHhQeSx9AOp/CuU/t/Ur+by/Mjs4sEnyRubH+83H5Cqum25uL h2eaPzXOGe4clzj0J5q1TfUh1F0J9T1iXVpNmxoLJDu8tvvSEdC3oPb8/SqIl3f6wbvfvW3remxQ sXjnhj3Ko2M2CcDHArCWNt4DD8a2ha2hjO99Sd4/3ahDnuR3psX3ix/h5qNnJkLDI9KlaaMRqkhA lk6BRlm/AcmqIFVw/wAr/ge9VtUuFt/3W0TSy/JHF/f+voPU0+RZ4Ww6mF8ZEeAZSPXb0Qe7fkaS zt1jmMkgDSP1brgemT1+v8hxSvfYq1tzU8I38mnTpod3JvRl3Wsp9erR/h1HtXa15tqMEkkXmW7Y niYTQuOzLyP8K7zSb5NT0u2vY+FnjDY9D3H4GueceVnRCXMi7RRRUFhRRRQB4lrtwbrxBqUxOd1w yj6Kdo/lVMdP0qbU0MesahGw5W6lH/jxqFelbR2MXuTW1xJazLLFs3r03oGH5GtbXdal1eVcrGsS xqP9WobcAM89cZzxWKOPqeaXPIaqsFx4C7Tz+lPG3b/F1pi/eK/hSr0b6UyR/wAhjPDdR3rsvD/j Iwqttqpd41AC3OMkf74/r+frWd4U0T7depLNJbmAAkx+aC54P8PbrWXfabJpsjxyTW8p6AxShj17 jqKh2ehSutT12CeK5iWWCRJY25V0OQfxqWvGtOvbqwm32dxJbk5JCH5W47g8Gun0/wAdXKbUv7RZ h08yE7W/FTx+tQ4NFqaZ31RyxRzRtHKiyRsMMrDINY1p4s0e5IU3Qt36bZ12fqeP1rZiminTfDIk iH+JGBFQWZMuiNFzYXLRKOkMoLx/h3X8Dj2qvI19b48+xcgcF7Y+YPy4b9DXRUUAc0moWsrhftCL J3ST5G/JsGrnGA33s9x0rVmhinTZNEki+jqCKoNoWmk7kthCfWFmj/8AQSKAIiS2P5e9O4xk9e4p f7FVf9VfX0Y9PMDf+hA0z+ybtfuam5H+3Ah/ligB+ScEVQfRdKabzm0+3aUnJfbzmrn9naiBgX9u frbH+j0n2DUx/wAvdmfrA3/xdAEP9laeDzZwse25c/zqaOys4gfLtLdDjOViUUosNTyCby0/8B2/ +LoOnaiVIOpRLkYyltyPzY0Acprl39r1fy4z+6tR5S46bz94/hwPzpi3G0MsnzRv8oz2x3rei8Hx IiK+oXTBOhCoD+ePxqceEtOHMst3IB/emI/litlNJWMZQbdzm9ix275yjudo7jA70yV44pFMk0QJ XB+Yde9dHNZ+F7PH2g2pK9FllMhH4Emm/wBu6RZoWsLBnAON0UAjGfqcU/aN7IXs7bswriS51O48 yG1uZsKqgrEccD1OBV600XV2U7oIYFI6zSZIH0XP86fL4ov7htsEUFqp6FsyN/QfzrMv3ublv9Lu ZrlPRmwmf90YFC535CfIvMtvaaZBJsn1Ca+n/wCeFkAq/Qtnj8WFQNeSR7orKCLTYjwfJ+aVvrIe fy/OoIgIosqAvZQBgVYtbh0lVlYq46OOoquTvqJz7aFmOxMGjCcRNh5TuGDnGPve/Peq23ahcHIP ANbEutXI0wFZB9oMpXdtH3cdayJbh3k/esXJ+8TTjfqTK3QIWwp3dDx+NbHgVyumXloeltdyIo/2 Thh/M1jSLt2qOQea1/A4Ji1aT+Fr1lB+iqKirsXS3OqooorA6AooooA8n8aaXND4rm8iGSQXaCZV RSxyOG6fTP41kJpeoZ/48Lvn/pi3+FeqeJbCe4tYryxz9vsW82EDjeP4k/EcVBY6l9vs4rmCZzHI M4LHKnuD7jpVqVlYlxueaf2ZqHX7Bdev+pb/AAp40q/wf9Busdv3Lf4V6h50v/PV/wDvo0edL/z1 f/vo0+cXIeY/2deghv7Puz9Ym/wp66dfB8f2fcYPfyWr0vzpf+er/wDfRo86X/nq/wD30aOcOQ8+ 0uPUtPvkuY9PuN6BgP3LDqCKgj0+9+bOnXHIPPlMK9I86X/nq/8A30aPOl/56v8A99GjnDkPOY9O u8n/AEC7Xg/8sm9PpTotLuzIv+i3I5/ihYf0r0Tzpf8Anq//AH0aPOl/56v/AN9Gj2guQ86bS9QH Jsrgg+kZNPGnXkVwGjs7pNuBmONlP5ivQvOl/wCer/8AfRo86X/nq/8A30aPaeQcnmctZXGqWU5F 1PqgtmP+sAL+Vj13A/L79R9K30utQADRaikqHkGSFWBHrlSKtedL/wA9X/76NZz2TRSNLZOsTMct E2TE59cDlT7j8Qahu5aVi5/aGqq2P9Ck/wCAuv8AU1J/aepKfmtLRvpcMP8A2Ss5tQ8rAvIntT0L H5oz/wACH9cVajZZo1eN0df7ykEfpSGTnVr4f8w6I/S5/wDsaUarfYz/AGamPX7SP8KjyNvAyR60 4BmUnnjvQA7+1b//AKB0Qz63X/2NDajqX/PpaLn1nY/+yVUl1C1g+RplMvZF+dz9FGTURkvLrAjQ 2cXd5AGkI9l6D6nP0oAffaxqtv8Au4Y7SW5YfJBGrufqTxtX3/Kqd1qXiLH7vAI4by7Q9fbJORWl axLaKwhLgucu5YlnPqT3NT+dL/z1f/vo000ugmm+pzc02uyW4aW41DzGPSOPYAPwFQiwup4vMuIb qZ14ImLvkeuD37V1XnS/89X/AO+jR50v/PV/++jVqaXQjkfc5e3s5V+T7DLH5gO4pERgdv8AGn3N jciONY4JmH3j+7PX0rpfOl/56v8A99Gjzpf+ej/maftfIXsvM5SKzulyxtZ8joPLPWiO1vA3FtPz 1zGcV1fnS/8APV/++jR50v8Az1f/AL6NHtfIXsvM5qSznk4S2mXb22HBpos7pI/+PabJ/wBg9K6f zpf+er/99Gjzpf8Ano/5mn7XyD2Xmc3DbXK/ftpio7eWetH2K5D5+zzEdf8AVmuk86X/AJ6v/wB9 Gjzpf+ej/maPa+QeyXc5mUS2tvNcXEMqxRKXJZCMYrpfCVk9l4dtVlGJpQZpP95zn+oFZdz5muav HpQdntLcrNenOQccpH+J5PtXXVEp8xcYcotFFFQWFFFFABXJ6tZyaHeS6naRtJYTnddwIMmNv+eq j+Y/GuspOtAGBDLHPCksLrJG4yrLyCKdVO90e50mZ7vRY/NtnO6awzjnu0fofboafYX9tqEJktnJ 2nDoww6H0YdjQBZooooAWq1vNeXUCTQ6bM0TjKt5sYyPXrVkdat+H/8AkA2P/XJaAMaTUDFaSTtb SZikMcke5cpg4JznGB61YH28jI0yYj/rtH/8VTbfBlvgRkG6kyD+FT6XcGxnSwlP+jv/AMezn+E/ 88yf1Htx2oAjt51ni3qGUglWRuGRh1B96kqTVrR4ZTqFshY4AuIlHMij+If7Q/UcelRI6yRq8bBk YAqw6EetAC1As000ki2lpJcrG21nV1Ubu4GSMkd6VxLc3AsrVisjDdLIP+WSev8AvHoB+PatWaS2 0fTlCIRHGAkca8lmPRR6k/8A1zQBjPdXEN1DBNYyxtNnH7xGwB1JwelQzW9lNcNHFYm4uR94QIFK n/abgA/jmnzedDaXl7MwN40TMSOQmASqj2H6nmuh062jtLKGGFcKFBJ7sT1J9SaAObGl3A+7p1+o 9BfD/wCLoOlSt/rNIuZf+ut0rj8i9XBfX19mWK5FrBuYIqRhmIBIyxbI7dAPxozf/wDQUm/79R// ABNADIbe7gXbBo7RL6I8Sj9DRJPNbjddWVxAnd8B1H12kkU/dqA6anLn/ahjI/QCtLSbyS8tnMyq JYpGicp90kdx9RjigCgjrIiujBkYZBU5BHrS1EYlttWvIIgFiISYKOilt2cfXbn6mnTzJbwtLISF X0GST2A9SemPegBJ7iODZv3FnOERAWZz6ADrQF1BhldNcD/bmQH8uau6TYvFuu7pR9rlGNvXyk7I P5k9z+FQT6xcGd2s4EmtYTtc87pCPvBO3Hv1PHvQBXS4/f8AkTRSW85BISQD5gP7pBINTVoTw22r 6epV90bgPFKnVD2YehH/ANY1kwSSb3t7kBbqHAcAcMOzj2P6HigCaiiigAoopaAErPv72b7Qmn6c ol1CYZAP3YV/vv6ew70xr241Kd7PRAsjqcS3bcxQ/T+83t+db+kaRb6TAyxFpJpDulnk5eRvUn+n agB2jaXDpNiLeIl3Yl5ZW+9I56sa0KKKACiiigAooooAKKKKACsbVfD9vfzfaoJHs79RhbmHqfZh 0YfWtmigDjZb690k7NbtsRdBe26loj/vDqv8q0YZY54llhkSSNujoQQa3yAwIIyDxg1g3fha1MrX GmTSaZcNyTB/q2P+0h4P6UAPHWrfh/8A5ANj/wBclrCkfWtN/wCP6wF9CP8AlvY8tj3jPP5VFpGs sYI7O01Oz3RDYI5rdlkGOxBYfpQBftv9de/9fcn8xUk8KXELRSZ2t3HBB7EehHXNMtoZIVk851eS SRpGKrtGT2xk1NQBa0m+ebda3RH2uEAk9BKnZx/Udj+FVLnT7q0uHOnwpLDMSwjZ9oic9T/unqQO QenXiOeASmN1d4pYzmOROGQ/1B7g8GpFvdVQY3WcuP4mVlP5DIoA0LO2h0uydpJcnmSeZ+Nxxyx9 B/ICsoSPf3IvZlKoARbxN1RT/Ef9o/oOPWiVbm8ZTfTI8akEQxKVQkd2zkt9OntU/WgCvfo0un3M aAlmiYKPUkHit2ymjuLKCWJgyOgII+lZNQrDLbyPJZXDW5c7mTaHjY+u09D7gjNACLb3dhug+xzX EasxjkhKnIJJ5BIIIzj0pfMuf+gbe/8AfKf/ABVSfatV/wCfm0/8B2/+LpftWrf8/Nn/AOA7f/F0 AR+Zcnppt5n6IP8A2atHRrWa2tpTOoSSaVpSgOdmcYGe/Aql9q1b/n5s/wDwHb/4umPJqM67Zb5Y 0PX7PFsY/iScfhQAszq+t3zKQVSONGPYMNxI/AEfnT9Lt/t06X8o/wBHjObZT/Ef+ehH6D2571Su bJmtUt7UxRxBsyLICRIPQkHPJ6nvVv7Zq2zar2C8YGI34/WgC9e6nYwySWs8rltuHWNHYqD7qOD+ tZCJ4ejRUT7YqqMAL9oAAqe3hFvFtDMzElndurserH3qXJ96AEsdQ0bT4jFbvLFGzFiZI5cAk8kl hx/Krmq2LXSLPb7Vu4cmMno47ofY/oeapnDAhsEHggjII9KrrcXmmW2xbq0W0T7huQcov93ORkDt 7UASW863EQdQykEqyN1Rh1U+4qWufTVrm81NptPgGoM67ZRaxMkbEdCXY4BHTPOR9BWpHomrahzq V6tlCf8Al3sj8xHoZD/SgBl7q1raSiDL3F233baAb5D+A6D3NLDouoav82rv9jsz/wAucD/M4/6a OP5CtzTdJsdKi8uxtkiB+8w5ZvqTyav0AQ21tDaQJBbxJFEgwqIMAVNRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAVR1DSdP1Ndt9Zwz+7LyPoeoq9RQBzTeFWtx/xKtVvLQdo5CJox+Dc/rUL2/iO 1+9bWWoL6xSGF/ybI/WurooA41tZNv8A8f2majaY6sYfMT81zT4df0mc4TUIA39122H9cV19Vrix tLoYubWCYf8ATSMN/OgDIjkjlGYpEkHqrA0/B9DSy+EdClOTpsKH1iJT/wBBIqE+D7BceRdajb+0 d02P1zQBJRUP/CLSr/qtd1RfZnVv5rTT4c1Efc8Q3P8AwKCM/wBKALFFV/8AhHtV7eIZP/ASOj/h HdUPXxDN+FrGKALFLUA8NXh/1niC+P8AuJGv9KUeE42/12ratL/28bR+gFAE2COoNVZ9Qsrb/X3l vF/vSAVMvg7RiczQzXB9Zrh2/rV628P6PakGDTLRSP4vKBP5mgDnv+Ei01m22zzXb/3baFn/AJDF Spc6vc/8eehzIv8Afu5FiH5DJrrURUUKqhQOwGBTqAOXTRdbuubvVIbNT1Sziyf++2/wq1beE9Kh kEs8T30w/wCWl25lP5Hj9K3qKAGoqooVFCqOAAMAU6iigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKAP//ZCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKPDwvUjEwCjEwIDAgUi9S MTEKMTEgMCBSL1I4CjggMCBSL1I5CjkgMCBSPj4KZW5kb2JqCjE4IDAgb2JqCjw8L1IxMAoxMCAw IFIvUjExCjExIDAgUi9SOAo4IDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjIyIDAgb2JqClsvSW5k ZXhlZAovRGV2aWNlR3JheQoyNTUKKFwwMDBcMDI2XDAzMVwwMzRcMDMwXG5cMDAzXDAwN1wwMjJc MDAyXDAyNVwwMTZcZlwwMzJcMDIwXDAzNVwwMDZcMDEzXDAxN1x0XDAyNFwwMDRcMDA1XDAzN1xi XHJcMDI3XDAyM1wwMzZcMDIxXDAzM1wwMDEgLzw/LS43Pj0zOCMmKjA0JTU7NixcKScrIToxIiQ5 XCgyW1xcSU1MWlRTTl5SR0hYVktXUEJRWVVfQURFT0BDSl18dXBcMTc3enFlb3lpc31idmthe2pt fnhkbnJoYHRsZ3djZlwyMDFcMjI3XDIwNFwyMDBcMjA2XDIyNlwyMzRcMjMxXDIzNVwyMjVcMjEz XDIwMlwyMTVcMjExXDIzMFwyMjBcMjIyXDIxNFwyMTBcMjEyXDIyNFwyMjNcMjAzXDIxN1wyMzZc MjM3XDIwNVwyMjFcMjA3XDIzMlwyMzNcMjU0XDI2MlwyNTZcMjQ2XDI1MlwyNTVcMjcxXDI1N1wy NzdcMjQxXDI3MlwyNDNcMjczXDI2MFwyNTNcMjQwXDI0NFwyNjRcMjY1XDI2NlwyNDJcMjQ3XDI2 M1wyNjFcMjc1XDI1MVwyNDVcMjY3XDI1MFwyNzRcMjc2XDI3MFwzMjJcMzE1XDMyMVwzMzZcMzI3 XDMzMlwzMTJcMzIwXDMxMFwzMDBcMzM1XDMwNFwzMDVcMzA2XDMzM1wzMjRcMzExXDMwM1wzMDFc MzAyXDMyNlwzMzBcMzM0XDMzN1wzMTNcMzMxXDMxNFwzMTZcMzIzXDM0NVwzNDFcMzQzXDM3Mlwz NjVcMzc0XDM1N1wzNzBcMzc1XDM1NVwzNjNcMzczXDM2MFwzNDRcMzUxXDM0MFwzNzFcMzc2XDM2 MVwzNDJcMzU2XDM2MlwzNjdcMzQ2XDM1MlwzNTNcMzQ3XDM2NlwzNTRcMzUwXDM2NFwzNzdcMDAw XDAwMFwwMDBcMDAwXDAwMCldZW5kb2JqCjI0IDAgb2JqCjw8L1IyMgoyMiAwIFI+PgplbmRvYmoK MjUgMCBvYmoKPDwvUjIzCjIzIDAgUj4+CmVuZG9iagoyMyAwIG9iago8PC9TdWJ0eXBlL0ltYWdl Ci9Db2xvclNwYWNlIDIyIDAgUgovV2lkdGggNTY4Ci9IZWlnaHQgNDY3Ci9CaXRzUGVyQ29tcG9u ZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzkxMz4+c3RyZWFtCnic7Z17fBTV2ccf CAmEayBsDEGJFyIoFhQiLwi2XlBbRfBepPoqliqIl2K9YH37qlQRqYJVaq3VYr2CiGKx9daCVxCj eMEbL5eELAQ1iIAYyPPXe87M7O5ssnF3T87sPCfn+X4+mT1zzjPnueSX2Zk5mwSRYRijgezM17dL 3t/QPvUMTe2y98QQZyMA5P0NcdNFHfKPq3Y7Cg68uUa0bjmoY6fjl3t2KwovRlxwQvLBj5yYYrYO f29mx7Q5Hh2DNX8Xp4eTTt6w+ZRJXsfygy9CvOinr9W+fuvPPLtDThRauOSi5IN/ObP5bNHHOjez Y9oUW7ogTv494tau+Hj/OsTXu6HbgW/kIXbf5jN9rOLNHohjnkB8EqDo0Lfwy1N7tr/ttKfEDFt6 LRxQ3Pl2x8yZLV/Yfdlb7H3VCd8e2LFiQXvpyW/GGM3KwxAPfxK/+tWlePIisV8XEZvDV8lWCeJ+ F30dt6wf9PT2nt9g+x2Il8369ps7jtj8o9k7d4wtfULMsLLj6e/ULe7j2MnZpowTdo+NF3urD13f 45ldywefKD35zRijWXQG1haJK5JTothht9jf3QGxtqe8yPmuDPHtcX3LTnrDtbxTyGDIu4nL3S5T Lxfbd9uLGXBRhbgY2thJdsvZ+k7bJuyumCN2lxx35Z3iZfLN0pPPjDEbcRlSNRhrHum4ByPyQvjZ UxCrDpMji890DDZccqTzuqe30M9Vs+Tl7pbJR3QE2G//jaJ7yYnyQuYSKaHnzpJ2YjaJsDvkcfF6 9cw8KcdxS6UnnxljNictwT/8Wrwe9RR224BYM3gh4h+mi466Q593Lb7p6bxMAcl0qZKhd31di7ed HdmKGD10ppgBT/qHsLjmN9LOmc3RY/fvEbcf9GykAXFvr33Sk8+MMZth7+LJz4rXmdfideds23Du eaJ98jKsrTrrKsTT7369/r0znNup99t9K7aP/1xeFnd9ctOXcw+4tf9ljV8fX/SCmAGHVYnBsY9I Q2c25/K5y+3131/XcU3lXQ3vD8hzPPnMGLM54Cvs97p4feto3HpOftllm0S7H0DXo2ZHxcXLcT0i ZVc2SrvT5snt+s7ysvip/YuOvueQ56uGl/zXok67xQx4wHdisO+X0sSZDeXl8+29S4c+3mXLByNK J/zyVMeTz4xh0nM+33sz2bFt+pY9k4fXhh0GYxg1U7t0OWVj2FEwDMMwDMMwDMMwDMMwpgCMubBu GBVC1U2IzpnWwLphVGDdMCqwbhgVWDeMCqwbRgXWDaMC64ZRgXXDqMC6YVRg3TAqsG4YFVg3jAqs G0YF1g2jAuuGUYF1o4wlH5JKDetGlVzKhl6hWDeq5DL4QH2ZJ3/WDQFfuZSNpjxYNwR8GZgH64aA LwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPNq8bjwb8dIX9jnN76Ev Lj+jLJJ33mrNvlRh3eSW7HQzEj50mk/C0I9Ks350yroJYppwyE43V8Esp3kLTBsGY5dv2rt4gmZf qrBuckt2uvkjXO80J8G9RbA3CF+q/ODcP3RiTCSnx1fOpwmH7HTzBIzHX8OlOBb+2QOu2B2AL1VS zn0DTPEGWTeayU43H8MgPKb0UDwQ1t5eDjDq+MVRzb5USTn3KBFuOt8KQbFustVNfUHBloLpRZsL S+pw1cSu4qd46Ba9vlRJNfcnIr7X0/lm3SiRnW5wNNxX8GXBbTBcdtQsnz8KZuj1pUqquW8Turml yfjq83qUdD57hWx+Ou6A/OMb5UDifQxg+10Hlgyan7UvTSEbQybBFzk226Ej4ngYchQOGQYTvaFP oK9eX6qkmvtMOArObjLuPjwo/QDxq/aydUZT3Vzm7CzK1pemkI0hk+Dbwx6x3Qf9EK8HuBGnAlzh De2FEr2+VEkxd10vWAW9apLHf7Hs+5qN18LP5T1h/7c3fTY8+boYYPiq+t3nwtAsfWkK2RwyCX4i nPlO3XsnwimIswBewAUAd+Cwuz+vrf1sAlTq9aVKirnfhSPwSKhKMb4TuqMY+kg0/9VUN/8S243Q JUtfKrR53bzd1Tl3d30NcRUUbsbNhfCud8KHgif0+lIlxdyXwG/xtzAzeXzZhM4FIuxCxI6wS+w3 NNWN/D+K26E8S1+aQjaHjIJfe05ZQdk5b6BcmJL/zH0w7MWVU44uLck7t0q3L0VSzH2sI+yRSeNz Ep8sb0E3GUTKujHy+XyGc28rcAQS2ebsFcFW+dIb7ttdg1uk9fDU71MZRMq6acu6eQwGiO0AeMTZ q4S528VLT3ixsX7FWGl9vbwu/uLHrBsl2q5uboJbxfZPcIOzd7/75jTNOQdNlk33Pvz0+H04uK0M ImXdtGXdjII1YrsSRjl70cvLpMmuK/IK8uZEHevXT+5efFIj60aJtqsb8r5YNwR8GZgH64aALwPz YN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP43VTNy4jy2xmTXkQ6yaIacJBBv/SvW57ASz4IUul 6Zv6CgrWTW6RwY95y22fdvrYH7JUmr6pr6Bg3eQWGXw7d8n4k4qaincQZ/YWfe/+OIrbB62FW3v1 fQrXHVMgH8E7bZhegl9URCrWefuxHTmVe6gza7z/4uLRK/2+gswjV7Bu3OAjNU5z6jP4zI2IPZfI jy6d+iJ+dCLC/IaXO2PFXNnjtmFJDfaf1zivwtuP7UgD71CnGeufXT2vv99XkHnkCtaN/3zT0AkA Ou3CV0Z2ugjx88O2X7sKISo1EKl2LJ021AmdNWB1xNuP7SBGwTsU/f3O1ucryDxyBevGDX68c33z 5xPE5oQHxGZFqdhc+eIF6J1GvPON8yW3lbc03Bc7xXg7vRfuug1ih/r6QWxzfb7xbg8zdpbOcFxd y75ag/G6eelO2RqyVGyWHiV6es8Rre96/z2mlRUVheDXzZrKSP8vYrpxd5b07TIHYof6+mFq7q9v YreHurjrpZZ9tQbjdZPy+U30nKY/ZpnzXp8WfQWFb+7Y7aEu1oxp2VdrMF43Kfvzl6pPWnJ1Vr50 4Jvbuz2Up8i/dG/34tXdOy2S4/0WYNXo/CtE98fHlhwh/97T2vYN2ND+80RPh/VPw9Pr23m78tZR srksmDzapG5M8+Wb27s9BOcWcGHJ/IZX24nd6L9HiGuu6tmie8gDtc87v6g88UGcezYmei788MLf jF91gbcrbx0ldU1/tZB10yZ14zvfRGO3gfN6FEI5Foi7O3mrJ24cnV+QejdvZ7+VmOi5/OIjo4Mu nuTtgvdGzeebFLRB3bi3hxi/lJdfpQsbFoC8x3PON0uqPdORAwc4Fl7PE0V/xVuL7vB2YzO+NTGY PFg3BHz576fudHv8urmmV/eZgFWD8q8rQnzzglLPfDE851h4PTtK9uH6gjXebmzGe5cFk4c9umlF ovIhSG6f36Sk/p4hWU/Nz29SkHHwGdq1ZCYfgoT/vBjKj8zmF5Nb5StX04RDrnQjH4KErxtSvtqK btynFjc8isumeM8znIVw7zkxuO/4SWvh6K6ee4vnsumYeY8/Eg9P0L0pYd0EMU04+IJ3n1psOv/B 8zd5zzOchSnv4tJ7SVoLR2/13F08d5oQn8j/8MR9CMK6CWKacPA/L3MfYrwKq2PNiHc7Gk3oJmkt XOAsgbuL504T4hMlHp5I+HwT1DTh4D/fOE8tGoc+d3CD9zzDOd94S91F6/3L3Ji4kpFL4M7iudOU ZonHHwk7+RCEdRPENOHgC959ajFtIb5wrfc8w1kId5e6cXIx+Ja5MaYHdwncXTyXTWmWePyRsJMP QVg3QUwTDnqCT794nsPnN4HDutEUfIaL56ybIKYJBwPrnfO5A/LFuiHgy8A8WDcEfBmYB+uGgC8D 82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDLwDxYNwR8GZgH64aALwPzYN0Q 8GVgHmA2WmqQYaHMnDsgX2F/41uJlhpkWCgz5w7IF79PEfBlYB6sGwK+DMyDdUPAl4F5sG4I+DIw D9YNAV8G5sG6IeDLwDxYNwR8GZgH64aALwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0B Xwbmwboh4MvAPFg3BHwZmAfrhoAvA/Ng3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubB uiHgy8A8WDcEfBmYB+uGgC8D82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDL wDxYNwR8GZgH64aALwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPFg3 BHwZmAfrhoAvA/Ng3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubBuiHgy8A8WDcEfBmY B+uGgC8D82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDLwDxYNwR8GZgH64aA LwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPFg3BHwZmAfrhoAvA/Ng 3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubBuiHgy8A8WDcEfBmYh+G6ySVB5hHc3AH5 Mlo3ORVOoGkEOHkwvszWjRL0Us6l/Fk3qhBM2TjZUCxi0FiYsn4sLKKFKevHwiJamLJ+LCyihSnr x8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqY sn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyi hSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fC IlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+ LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp 68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJa mLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiws ooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevH wiJamHJmgEfyLu81KUwQHoyGxDeH7p63H4QHe+CUGRUsLKKFKevHwiJamLJ+LCyihSnrx8IiWpiy fiwsooUp68fCIlqYsn4CL+Kff1JaXHndZwF7yQbWjQaCLuL9cO/O+pWDKX2rWDcaCLqI+0NUbP+P 0reKdaOBoItYBKvi7VcP6Vk6bLHzbP7l/iXy8fy5uEc+pG8yEGxErBsdBF3EMwGOnvTobtl8unBO 486rYal0evrmJ2ENlNUhru1X03Qg2IhYNzoIuojbpnUUZ5Hy0zYiHgwNiFvhEOn0DTlWCY8gTr26 +UCwsG40EHwRtz5+8wCAsYjF7tJxV+lUXvSIa+bxWN/u9eYDwcK60UBuijgb8qVu6pOd7i0q+PLF CSkGgoV1o4Ggiwgr5LYRuiGOdNpvjE44HQd/mvBKqoFgQ2LdtJ7AdXPgY1uiu2+EexCfLx/4Xt26 w25JOF0IZZ3rUw0EGxLrpvUEXcQVUw/rU9DprBdl+z8DepYcfZ/7GTlnMLofTE45ECisGw1YWEQL U9aPhUW0MGX9WFhEC1PWj4VFtDDl9MQuLYN+NRjjEwgAyIluzK682dEHQ25qYnblzY4+GFg36TE7 +mBg3aTH7OiZsGDdMCqwbjKmEhaI7QLoj7jjqm4l3WbsQNx9Zp+C3seEHVkIsG4y5vdwutieAX/E HWXdPqj/sEPZDhwL/6xdMzHsyEKAddOcFmryaXn+VtyaX74BZ8BLYv8fMAM7wm7vEID8abXy43eF HX71DeLtB3XsNwu3/2FQSY8/bs/GiyGYHX0wtFSTkbBIiGUgYgf4Tux+Bd2wDDpPe2i9PGRS9WS4 DPF/VjQ8JPQ0Dy78fs90vBd+V32N/NhMFl7MwOzog6GlmsyGE8Qb092IEagRuzVQgovLxImm6A5x yG5cD3mOWR30xhHwnmzuB5/itzAqKy9mYHb0wdBSTfZEIu9HSrbI880esfud/Nxm3Qe/HwTtnM+C 10AEPxrYpxyg3FOWeJEUZOXFDMyOPsecAAfBieJ1BiwT20VwldO7EUqd881u6IHtYWldg6jpKHhT Do2AjSGGGySsmyxYJE4er4jXHWX9Vtd/0F7cTw18ZV/9M0JLANc3XA+/xM7wUeMkUdP5cOG+vZNw Lhy3eefS88OOOwBYN1mwNR+6NsjGjhkdIh3k85vTDiwtbHfeHud+qviqWnx5eLm76P3wQUX9Hkac 1b+oy4ULw447AFg3WrCujNYlnAEKNcnNIYQwO/pgYN2kx+zog4E/R5Ees6MPBtZNesyOngkL1g2j AuuGUYF1kwL+/am0GJ9AELBu0mJ8AhSwsIgWpqwfC4toYcr6sbCIFqasHwuLaGHK+rGwiBamrB8L i2hhyvqxsIgWpqwfC4toYcr6sbCIFqasHwuLaGHKTQAqcMYmEXbtfHDGBkEm+BzqJkeO0kEmEBXI BM+6MQoywbNujIJM8KwboyATPOvGKMgEz7oxCjLBs26MgkzwrBujIBM868YoyATPujEKMsFT1E2w iwFkSq+CL/hw8yCkm6+nDOrYa+zLmeimNVG3Md3IWpXs/9/vi+bO6/cv2n/qVrczf/S01+T48jPK InnnrU6eJmVnS46UxrWR1tG/+/hWHVk3qWkevLdWW1yF0YFOa0A01hl5APGj0hRruSk70znKblwb 6Rx91xfOeK128/MnZGLNuknqqV93AQzEV6D96toPyuBFp7Nh+aTyorU4DMYu37R38YSkY1J2pnOU 3bg20jm6GcY0t/a/vHJC+5KOR/5udeITGaKz9i9Hd+x07iee0SWdes9tdSCkiQXf9My8D4rxZJgl WrfBybHOK+FSLIK9zWfxdQ6BRWL7BBzkK7C/wokCAzzW6dAtl/esTAokcNI5OhRebW7te7kxnosv q02/cBqdNzpG8zO6nm6TutkDB+Ag569Xr4XRsc63YDD2gCt2N5vF13kHjBTbiXC/r8C+CvsKDHAA wPkZXkjoI52j7vBtc2vfS0+4dUNd7ZsPHeuf7E447LO6DafCTU5f5bLq73/d6kBIk+q6GLHmjYnw K8wH+deKq6FnbOwb6IW3lwOMOn5xNGkWX2d1d3gNvyuJfJVc4NjsvgIDLF0K8MJ/iOmmwP0fAcnW vpcD4RfHXTz3yWjSZAc5P2JfwX5O331aAiFN6vspcUf1s0YsBFmcKBTGxmrk/1pYNbGrGB+6JWka X+ckuAHvl3+PP6nAsdl9BQbY2uh8NQ0kWFp7vvlohFOg/jv8kxV759OI07deSyCkaUk3Q8UVSMrz jaBm+fxRMKPJRPHOtdB152B4rEmBY7P7Cgywfbvz5XObBs0Zp2RYy9c3tc5LdMWSmWfmu1fPTXUD Tl/yybjlQHKUcRCkfp/aczUMqvaubz5PXN+skVe7Dp9A3+ZzeZ1nwU3QqR6TC9xUN+D2OF/eeI7K mG6SS+Cnvr0ikI+vsI/zH0r+lTj2HciXL4Xem9rgop0ZO0jYGSyc1LpBHA/X4KnwsGjd7b+fmu7Z 7oWS5nN5nX8T2SauCr0CxyrsK3BT3WQVrDrpJtl3AJy0vH7bf9znN5UwV/6/vmNh3O5NH/xIHvuT e9Y11nx6sXvq7QCzdsnXuXDIqp11n95+eBZR5izjIGhJN2ug765noV9V/eoO3vObXcsnl5d8jMPu /ry29rMJUOmfJamzrhvAh9ikwLEK+wpMVDf4dE/fT/r9busBp+cy/73hJXL4fz3LujGJ04NVukl+ +xAcBQ/UHO50JZ4XFzwcNyx4InkWf+c10D6KTQocq7CvwFR1g+/cNKKo12kvO+3o5WXOAfePiOx3 13bZ/OLSyuJIhwsfcYZ3Xtkj4l70PDS0S8mI31VlEWXb1M1TcBRuuzSvJO/6ne5w8aAZ60Rr5ZSj S0vyzq1KmiW58zdwpXxJKnC8wokCk9VNjmgTutFItIfzNhVAIKwbMugPLPog5KX+18+tDoR1Qwb9 gYm3tL8EFAjrhgwB6KZ42qaAAmHdkIFMYKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCs G1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgEFrZu6sa5o6mOaDaQ coofCG5OFoFkbRMKLQbm1dGx+YHDmw1CGvusA8nSRnWSl+51R1Md0Wwg2zh6ZxFI1jah0GJgXh0d m2aN5kP+sR8oMV3djHnLHU11RLOBbONIfX5qk7rx6ujYNGs0HzJeN+22uaOIX1REKtZJu34LEFeO zr/C1c3FxaNXotcN8catvfo+hbjumALnzOvtVsUOik+lmo15uvHqGKubrFLsc6SynvEh0TOzt/cZ U5he4lTPLbF7mOz/+NiSI1YnvgXZBZKljeokkRp3FLH/vMZ5FaIZ/fcIsTO7ep6rG9Hoj143xBvz G17ujFgxt9Z9h3Z3K2+pnu2YxKaySDdeHeN1i5fLrWd8SPT1XFLrqWRJjVM9t8ROj7Md8kDt88MT U2UXSJY2qpMkzjeRBqyO4LwehVDu7ri6cXq9bog3ou4h1e6h3m5B7CB3Kqt049XRq1u8XLF6xodE 3ysjO13kqqTOrZ5bLZC/I+z0R8RJpzzxLcgukCxtVCcZH7++qbyl4b4KLF3YsECefMSOqxvRED8M bjf4GvIrfr6Jz+Ceb9yprNKNV0evbm6VitbHWokhp72i1BnzyuaVuPfCXbe5xwxZUo2+b0F2gWRp ozrJS3e6o4hrKiP9v8BrenWfCfLNuPhGVzdTnTdftxt8Dfm1oqIQfLqpGpR/XZE8yJ3KKt14dfTq 5lZpcjHE6hkfcq54es9xxmK6cUu8pG+XOe4xb15QKvzEvwXZBZKljeokvucOGqi/Z4hqIFnbhEIm z29yQti60QqUH1mV3qhN6ibXtCndZATrRgesG1WbUCATGOtG1SYUyATGulG1CQUygdHRDTRrZDJr 865xda0MJEObUAgusHRlawId3SQsW2d310utD6Rt6SajY9KVTSEQs3SzZkzq/mwCsVA36cqmEEjO 3qfcdezYEjh6C7M3PIrLprjN+Ao4un/+2neQuyQu2FzWykAytAmFbAOLr317VZpegt4KufvhAa+s mL5sCoHkTDfuOnZ8CdxbmN10/oPnb3Kb8RUp3+qCd5C7JC6oS/EnELMKJEObUMg2sPjat1elJTXo rZC7Hx7wyorpy6YQSM50465je+uzGFuYxVdhdawZWwGPJnTjHRSNnY/5fOMjvvbtVakuvkLufnjA Kyuafb5x17G99VmMLcw2Dn3u4Aa36Z5v3JXb2JKudxDGdPPWxFYGkqFNKGQfmLf2naiSt0LufnjA KyumL5tCIDnTjbuO7a3PCtyF2WkL8YVr3aa7Au6u3MaWdL2DMKabe5e1MpAMbUIh28Dia9+JKnkr 5O6HB7yyYvqyKQSSE92810eDEwk/v8mQ5A8PmPr8puRqDU4ygXXjTZXJhwdaFQivM5CBTGCsG1Wb UCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFM YKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFu VG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFMYKwbVZtQIBMY60bVJhTIBMa6UbUJ BTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgE xrpRtQkFMoGxblRtQoFMYKwbVZtQIBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG 1SYUyATGulG1CQUygbFuVG1CgUxgrBtVm1AgExjrRtUmFMgExrpRtQkFMoGxblRtQoFMYKwbVZtQ IBMY60bVJhTIBMa6UbUJBTKBsW5UbUKBTGCsG1WbUCATGOtG1SYUyATGulG1CQUygbFuVG1CAeiQ SbCcMRXCrl2cjGLljA2CTPA5C8S+jIOATPCsG6MgEzzrxijIBM+6MQoywbNujIJM8KwboyATPOvG KMgEz7oxCjLBs26MgkzwrBujIBM868YoyATPujEKMsGzboyCTPCsG6MgEzzrxijIBM+6MQoywbNu jIJM8KwboyATPOvGKML+HK4Pztgkwq5dHM6YYUzm/wH20LcVCmVuZHN0cmVhbQplbmRvYmoKMjYg MCBvYmoKPDwvUjExCjExIDAgUi9SOAo4IDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjMwIDAgb2Jq Cjw8L1IxMQoxMSAwIFIvUjgKOCAwIFIvUjkKOSAwIFI+PgplbmRvYmoKMzcgMCBvYmoKPDwvUjM2 CjM2IDAgUi9SMzUKMzUgMCBSL1IzNAozNCAwIFI+PgplbmRvYmoKMzYgMCBvYmoKPDwvU3VidHlw ZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VSR0IKL1dpZHRoIDQ2OQovSGVpZ2h0IDIwMgovQml0 c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRENURGVjb2RlL0xlbmd0aCAxNDc0NT4+c3RyZWFtCv/Y /+4ADkFkb2JlAGQAAAAAAf/bAEMADgoLDQsJDg0MDRAPDhEWJBcWFBQWLCAhGiQ0Ljc2My4yMjpB U0Y6PU4+MjJIYklOVlhdXl04RWZtZVpsU1tdWf/bAEMBDxAQFhMWKhcXKlk7MjtZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWf/AABEIAMoB1QMBIgACEQED EQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0B AgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEB AQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFR B2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AOVuHjCcsAeg qmvPykD61X8yUKQ6bsHOcU5X3R+9AE0sINu205UspLdhwaoo3OCc1IsZBwCSrc496aUw2OhpJWNJ yUkklsO6g9TUikFcE8U0EnHNBbsFzTMyW2d0lGCTWulwEQZYIfXNY8cgI7jFRvKQTkkj0NAGydQP PzAP2FPt4/Ol86d+ewp+i28N1bmRoTv6VdSEKxKrlR69qALdhbgENGoIJ6mtqGOANl1VSO9Z9pNF 9lKsRnocdqJW2kbAZFHIyKANswwuRhhgDmmeSY5AVQsme1M0+PzSrvhfQVrLGQOBwKAGQ8kNyo7V fA3YxTURio4GKemQwB4BoAsL0peo6GkUYFLQAuSOlJ2pScCj+VAFZY7j7azlx5G3AXHOasblGeRm lqKSFXBOMHOeKAJaTmm8uo6rmn57ZoARxuQr6jFRxQ+XGF3MSO5NTE8dKTPpQA1QQOuTTqBRQAf1 oz6UZo7UAHek3DdjPNLjHWs06dKdWF39pcRhdvl9v89aANGgj3pfwpNxJxigByd6ox/66T/eb+dX 1qhH/rpP95v50mBNUVxPHbx75WCjOBkgZPpzTpZUhiaSVgqKMkmuellfV5WklYwafCckn/PLfy/m DNhNRt2tmm3bVD7MEj73pnOPxzipLe6ju4HePOFJUg44I9xwfwrAtbZtSdYoVaGwiPXux9T6sf0/ n0EFtFaW3lQrhQOvcn1NAEFn/rbv/rqP/QFq1VCB3WeZIkV3kuNoDNgf6oH0PpViY3cMMkrQQ7UU scSnOAM/3aaERQ6gLeacvaXbuzbcpFkbR0wc89z+PtU/9tJ/z433/fr/AOvUOoyyrCkNu225uXEM TYB2kgktg8HaoZsHrtx3rM1R5dOkaAanqFxdFGljija3GI1XJeRmjAjXdkZJPtnkAA2f7aT/AJ8b 7/v1/wDXo/tpP+fG+/79f/Xri4NTvLm5uv8Aiq47e3hdE3JafaEQk7fnl8pFAJ6Hp+WTuxx6rpV/ EL7VI9Qtmwkp2JE8Rc7YzsVc4LArndzu6DaSQDTsX3wkCKSNEYqgkXadvbj26fhVmo7ieO2t5Z5m 2xRIXdsZwAMk8VSm1vTYdLTUpLuMWcmNkgydxPYAc568YyMHPQ0AaNFV7u9t7LyPtMmzz5Vhj+Un c7dBx9KY2o2iakmntOq3bx+asZBG5ckcHoeh468UAW6KqW2o2l3dXNtbzrJNakLMFB+QnPGeh6Hp 0xT7S9t73z/s0m/yJWhk+Uja69Rz9aALFFZ0mtWUd5Na7p5J4NvmLFbSSbMjIyVUjkU1Ne06S6Nu s7BxObfLROE80fwbyNueOmeaANOiqV1qdpaXCW8ryNO6FxHFE8jbQcZIUEgZ4yajm1qwiuEg82SW WSITqsELy5jJwG+QHigDRorKk8Q6ZFM8Uk8iNHs8wtBIFj3427yVwucjrirF1qdpaXCW8ryNO6Fx HFE8jbQcZIUEgZ4yaALtFNjkSWNZI3V0cBlZTkMD0INFAHi13IiqUjTJ6Eis+Nz5nPIqyilDljTW TA3DHNACjdlvTtmkKEnd3NN3HA5705pW42p0oARkKnBXrzUEp2yfKamLySKeME96ktLTJLvzQAyN XfA4GfSrtpboZl3ruwec1NFZRvjkhq17SyQrgn60AXIZI4ztgQBQOcHvUqxmVWZkxk80ltaLbynY Mgj1q5DIjzeX932PegChDYkfddVBP3fWtq1smiRS3zL70fZVJHykH1FW4G2qEJLfWgAVYwQqAqc9 Ksxs6ttyT9ahZQXDBuR2q5GhyDg0ATxysv3lOKnHOMVEAO5zjpU6AAcCgCQVDeyPDaySRoXdRkKO 9Td6XqOaAKWl3Ut5ZJNNC0Lt/A3arhGRgkigcDjikaQKVByC3SgBaXt0pD9aXrQADGKCaTvTZEEi 7Tx9KAH0fQUg470vegBhDb+vFO/Gl70MQDgigAo460dqBQBT1PUYNNtmnuH2oB1pbG9hvrZZ4WDI 3Qg5pupaZb6nbNBcoHT0p9hZQ2NqkEK4RBgUAWs0jAsMA7felxx7UcUAOQYFUI/9dJ/vN/Or61Qj /wBdJ/vN/OkwMe7juNR1F4ZyYbSAkk9vrnpnB/AfrBMjXdwsDhrWxhbYq7SCxxnpjJYj+fqed1rb d56l/wB3ODuGOQcAcH6D0pFtiHV3cFxJ5jYXAPy7cAZ44xQMdamARmK3wEiO0gA4BzyPr/8Ar71K /wBxvpTIojEu0MCN7Mcj1JOP1p7/AHG+lIDLVjHcPIFYhLnJ2qWI/cgdvrUt3dmW0mjVJyzoygeS /OR9Kr/aXt5pwi7y82AApJ4jT0pzX9wqlmt3CgZJMT4AraMG1fQllUatajUbi4F/psc0BNtHHc3I QgA5kOOoLMqpyONm4ZBwampavpV/Ok0n7q6jRommtr20ZZEIwyHe/wA6E8gMoPfA5pNQOnxQzXUu k6fNKTn5oFzI7HABOO5I596yJtQtLeNnm8P6JGqnBLcZOM8fu+fwolTcHaQXE0TTdNht5EGoabpq 3UbxXDyailxOYyVyi4CxqCFPzYY811Mmq6UGg0uO70ltFNq0MpN+A68BVUDOSMZ5z68jA3ciuqRu 7LH4Q09wuPmKKgP03IDVqxvbOe9S3u/DWnWpkB2HylcEjnGQuOm49e30qVG7smM3nuTqXhXUo4pV vJ44ZbdnhwwlYIcMNvHzAqcDON2OorB1zRL9dI1S2SBpbWCQvZRxIDnzJEYhVXkbMOM9w5xgcV0V rPHZxmO1tba3QncVij2gn1wPpU39pSf3U/I/41t9WmK6MzxBpV7rlvfeUyxokZhhjeM7pMFXJB3D buZVXkHhMjhqrzQ6jfT2+rW9owv4ILZ/LaLy95zKssYL/d4b36D2Nbf9pSf3U/I/40f2lJ/dT8j/ AI0fVphdGJpdje6bqOswwpKZZxaxR3JiOGfYd8vPBwdzHJ5PGcmi2huvDWsXMjW0t5aXNtGB9jtm JV48IqAbmx8pzljz26Yrb/tKT+6n5H/Gj+0pP7qfkf8AGj6tMLoyIxLa+LdXuJW1CGGQwFDBatIk 21OQSEbp04I6n8M6PT72K6lu5YLmW1i1uSZrbyzyp4WZcDccE9BkH8DXUf2lJ/dT8j/jR/aUn91P yP8AjR9WmF0Y2rlrpE1iyi1Ww1NbdkhH2Yv5gDH926ANj1BOB8wPOMBs63o8S213dC9tC2lqksln bmUCXfkp91x6/kOfXb/tKT+6n5H/ABo/tKT+6n5H/Gj6tMLo5fVNPvby9165hguZLZzaSm2MZT7W iqCygkbgRjtz2xnFbNszaf4i1G8mguWttRjheJ4oHfbsXBV1A3Kec8j17jFX/wC0pP7qfkf8aP7S k/up+R/xo+rTC6NKNi8asyNGWAJRsZX2OCR+RorN/tKT+6n5H/Gij6tMLo8ldCw5BqKRtqhecCp/ PLIDwM+lIIhIvPWucZWABwM04A/UCporZl5PaporZiScZGe1AFUHAxjHNXI25AwNv1pr2pbcVGat W9tiMMRQBbtyBggfjWtBFhN68etUrSLdxgVpxIoj8tzsDdCKAEluGt4TIELeuKW0U3DpMgCt160r 2xETK3C+ueKZakwOvlDcQcHnigDchlYj58KfSrMcR3bqy5VYuJE+Zu+O1XbGeWXIx045oAsgZYHb tYnBrQjQDknNVVY55XrVmMHHWgBzJk8GpVbFNXrT9o60ASUo5HTmkAp3GfegApCB1xS89ulJQAo+ lFRyCTI2EDnnI7VJxigAA4pqjbn39aVwSh2nntTIt4QeYQW7kUAObOPl6+9LnHXrRjmgqM5NAAcg 1kaprtlp1xFHcShGc4Ga1yAc/wA65vXPC1vq17DcSEhoz24zyKAOhilWVA6kEH0qQ1XtoBbxLGo4 AwKnz7UAL3ppyRwcc07qPSmFPmDZPHagB9GBSDp6UtADlqhGcSzEdQXP6mr6DAqgn+sn/wCB/wAz QtwMnWtebSrdG2LNNI21I8hc9yScHgeuDyQO9c/F401ONws1tbXG4jmMGIRjuzZ3fKOMnjH41f8A FOmzXkENxbI0stvuBjBGWRsZx6nKr36Z6nFedTX07u/kHajK0Zwv3kPXr64HSrdGvUq8tFdDrtQW ElL/AJeN2W56Umv39swe+NvJASAzxRlDGOmSCWyOcnkYAJ5rWubiU3Nku8hWlYMBxkeW5wfxA/Ku F0u8udftpbRbciQ4SWReEVG6nk5BwGA68gV2s/8Ax+WH/XZv/RT1jh1WUZwrrVen6aHjYOdZpqtu hkb7NXQ/9N2/9FLWXpM+uahpQuNYd7dYIpR5ewI9wxDDc4wMKAcBe5G49q0LixkvZZvLKDZMc7vd E9qg/sO4/vQfmf8ACuuEIyim5JHY7mDf3PmXgG13jtjyEXJ3kf0U/ju9QBWZeyQS3KTx3kAcRtGY 5JdhTP8AEvdW7citq78JPBHcXUmpXEMS75nCTEKo5Y4AX61T/wCEfP8Az+63/wB+Lj/41RUXPJyu ho5ywsXkSV0JupZgSsgRlVGBHz+YwByDngZziugkI3x2rySG5eMMsuw7QyEENjoDnnH0B7VVuLfT bWdobnXr+GZcbkk85WGRnkGP0q1puj22qybLHW72U4Y53yKDjGcEoBkbl49xUez80Fy7d3X2nw/d SY2s0EgZc52sAQRnvggjNZaJHa22hy2caRXUrRq5jUBpEK5fIHUdDk9K6S08LzWsEkJnWdZWLOZn LE5AGDx0wKkh8NG3cvBFaRMRglF2nH4Cu7nhKzclcnU5S2X7Ey2s5iD3KStFqUTYYjBOX7ng56kd PTNWtIAtrg6bPaxw3C24Jmt2IEq5xk4wd3v164xnnoo/DjxStLGlqkjZ3OowTnk5OKSPw0YkdI4r RFkGHCrgMPfjnrSi6aa95BqYtrHb219LfwtFa2RhEeAAiOd2d/pjnAPfJ7YzVihW48R6nvtLa4UG HJm6oNvYbTn9OgroR4VRQwW3sQGGGATqM55+X1AqddBmWR5F+zq743MM5bHTJxzVc1N295Bqczqz x3mqaQYlgu0bzsK7ZRvlHfB9PTtUVratFf2On6g4uIYrVmRXGUaTdyBn72FOBnoOcCuoTw46eXsS 1Xys7MDGzPXHHGadN4ekuECTrbSqDkB/mGfxFK9Nu7kr/wDDBqcdBDPdQp5JiuIbW5m8m2mOVmiA AGCeuM4BOcZ69qc7rcQQanDbwz20Vu2+ymbPljccsucgdCOg4XA9B1snhx5YlikS1eNcbUYZAxwM DFJJ4aMqIkkVo6xjCBlyFHtxx0qf3f8AMg1OVu5kmvJ5I9+x9GYrvOWwTxk+tbmkvjSLIf8ATBP/ AEEVov4ekd2d1tmZk2EnklfTp09qcmh3CIqI0CqowACQAPyrSEqcXdyQalfzKKtf2Ldf34f++j/h RWntaX8wrM80tbVntUfrTY0cTkNwnatjR51a3WCRAHTgkmrs1sitmQAL2NeMaGMoA+7yPSrVico4 xz2NTmKN9/2bBdetNjtpS4aI7f7wxxQBBa20ss0gRsknlaneF7ZfKmzuPIpieZY3TPvw7n8MVs3d qL6x80nEgHVetAEembHiHGW71aum8tlXGPQ1j6fcNpsoSVc7zkFj1reuf31sJl2lumBQBIjCWHnB /rVPzxG+fLZS3GCKu28RFqpI+Yj1qaO2DOCy8e9AEVuwkO2M4J6irkIlimVQfqfWqohdbkNGmAOp 9a2YlU4OPmx1oAlU84I5PcU8lgcg0sYB/CnMNr4J60AEcjbgjDLHuBwKtKPl5qncz/Y7SWcIzlVz gdTTNF1FdVtFn8p489AwwaANKm7Rv385xin96guXlQL5UYfLYPOMCgCbtzR0oHTnrRyRnp7UALnN HaqmoXyWEAlkVmBOPlGaso4dA/YjNADuPWjPFJ05o3DdjvQAjNgj3pxqMnYWd2Gwe3SiOVJk3Rsr j1BzQBIKjeMmRWDEAdvWnnpS0AFFR5dVYtyO2KybC/m1G9kwkkMcDbSrD7/vQBtUdRzRnA68UgOV yKAAnAqOeV0ClEL5OD7VLnj2o47UAKmcc1RT/WT/APA/5mr6d6zW83M/kIryEsArMVHX1AP8qOoF G9u47K2M8quyBlXCLuOWYKOByeT25rzLUtHuIJZ3trdhADIwjZl3whckhhuPAGOckEMvOWAr0y5s NRuYlje2twBIkny3DdVYMP8Aln6gVVuNCup3una2hDXMTRORctwGAViP3fUhU9vlHqc91LFyotyp slxvuZXgrTJtPivWuSFuGdUeIc+XtGRk9DkODx6/gOgn/wCPyw/67N/6KemWmnalarJ+5hlkkbfJ I9wcucAZ4jA6ADgDpUjW959qtXuUtokSRiNsxYsfLYYAKj1z+BrOrW9peUnqxpWBEje6Kyorobrl WGQf3NWb62sVsbgpbRKwjYghBwcVDFCJpLj52QpOGBXGf9Wo7g+tSvZmRGRrqcqwIIwnT/vmuZWs DI7gpcalb20jqsMJS4mLHAJ3YhX6lxnj/nngj5qp+J7e6a6CCGRtNnhk3i2V8yXG3avn+X85j2gD 5e4GeMVVks/ECzXaxw6HPBNO8oN0sjMQRsGQOPuYXjtnrkk1f7L8SDhDpsa9kjvbxEUegUOAB6AD ApDMrSL3WdPjvbieGPSWk+a1gS0ij+0SKwxD5e3zHB34DA/Lzya7W/tGu1gvTb28erxwrNDF8plB X/WR784KkPszjALbueMYWmaZr2kqBYWPhuBgCu8LMXIJzgseSM+p7Cpnt/E0moRXz23h1ruJDGkp WbcqnqP5/mfU5ANTUL3/AIp66v7OT/l1eaF9v+wSpwfw61jx6hf2VpoV7LeSXaag8UMsMiIoUyLk MpVQRgg8HOQe3WtGw0+8k0q+tNVa3U3TycWhbaiuPmxu5yWLHnPX04C22gwwtZ+dc3N1HZAC3imK bEIAAbCqMkAcE5xk96AMnTNW1CTzoLqeSPWwkrLYTwqsUmM7fLYYJGcDJY5Ab/eFrw7qUt7G0Ml/ L/aKQAzW13bhWifswChcr3xycFeV73v7Dhe8iuJ7m7nMCOkKvIB5QcYOGUBiccZJJ79eadDo6xXk t493czXbweQsz7AY0yTwAoXrzyD0oAhsnv49fntWuJLuxS3VmlkVA0cxb7nygfw4JBBxx0zzRF9c 3HifU7F769ghhMIhW3t1cDcmTuby2xz3JHf0rQXRGWye0Gq6gI2GAVaNXU7gxbcqA5JzkknOTnnm nHRQupXd9b313bS3ezzRGIyp2jAxuQ4oA5+21zUJNa+zpdSSynVZLcW7RKI/s6gliG2j5l/3s9OD nnS17Ubmw1WHz5rm00kwEvc28Kvtl3cB8q2BjGOOS35Wm8OWZhlQSTqz3v29ZAw3Ry+o4xj2IPWn Poe/T/sZ1LUCjRtFIzyK7SqSepZTj7xGRg4xnOBgAzbvU7g+IYLX+0J1tX09Z91jbCTe5fG4Da5C kf059aOpa1qNrq2oWkF7K80ElrFaQtCmyZ3A3B228Z5PVe+OnHQNoMK3kN1a3NzaPDbLaKIijDyw cgfOrfn7U2bw5Z3C6iLiSeU6gkazMzAHMYwrDAGD39M9scUARrc3eo+IL+yiupLOCwSMHylRmlZx uySwIAAGMAd857VtxhxGokZWcAbiq4BPfAycfmazn0dTdC6hu7m3uWjEcssWz9/joXBUqSPUAdSO nFaMaCONUUsQoABZix49SeT9TQA6iiigDzW8sjFeobdfZsVIzvLG0AhLN6ntW5FDIgObRyScn54/ /iqeqyKS32JgT6PH/wDFVHtI9yuSXY5+Cya3jIZWUkZ4FXrS5QRmNk2t6+taMi3Bk3JbSbduCC8f /wAVUUds45a0fd7PH/8AFUe0j3Dkl2MuSxmmvUeWPCDowrSVZQghWLBB6gda0PNcxhDaTY7/ADR/ /FVLHduibRZzfXfH/wDFUe0j3Dkl2M690yC+siNm2Vec4qhplqba2kWVnLdlroo7vBJeymOfRo// AIuq0rF9220mAP8AtR//ABVHtI9w5JdhbCOQ2ieYm1/TOcU7LLKRg5NNjmmTaPs020dfnj/+Kp7z vjKWc2/1Lx//ABVHtI9w5Jdi5DEPL5BqYLmMkc1Qt72YL+/tJd3+y8ZH/oVTnUWwALKf/vqP/wCL o9pHuHJLsX4DuXOMGnKAz9OazxqRHSznH/Ao/wD4upU1RV/5crjP+9F/8XR7SPcOSXY0wFdcEceh FOSNY0CqAF9qzRrC4x9iuf8AvqL/AOLoOs+llcf99Rf/ABdHtI9w5JdjScOUIQgN2Jpy5AAYjPfF Zn9sjP8Ax5XP/fUX/wAXSDWR/wA+Vz/31F/8XR7SPcOSXY1D0pay/wC2R/z5XP8A31F/8XR/bI/5 8rn/AL6i/wDi6PaR7hyS7Gk6K33gCPen9FwO1ZB1ng4srj/vuL/4ugaxn71nc/8AfUX/AMXR7SPc OSXY1uMUmOe2ay/7ZGP+PK5/76i/+LoOsA/8uVz/AN9Rf/F0e0j3Dkl2NC6EZtnEv3MfNx2qDToY La0SO15i6g5zVZtXRlKtY3BB7Fov/i6F1dFUKtjchRxgNF/8XR7SPcOSXY1agkuQtwkRVssM5xxV L+2R/wA+Nz/31F/8XSf2wuc/Yrn/AL6i/wDi6PaR7hyS7Gpj8jSBFQ5AAz6Vmf2yP+fK5/76i/8A i6P7YXvZXP8A31F/8XR7SPcOSXY1eDVdWn+1MpRfI28Edc1T/tlf+fK5/wC+ov8A4uj+2R/z5XP/ AH1F/wDF0e0j3Dkl2NPmgn161mHWQf8Alyuf++ov/i6Q6upYN9iusj/ai/8Ai6PaR7hyS7GrGWLt kYGBiqSf6yf/AIH/ADNVYtXKSSM1rdMGIwN0XH/j9RLqRDSH7HcfNux80ff/AIHTVSN9w5JdjP1f VLnTpB5di08ATfJNiTbHyAclY2GACW69FPHTNC18SX15BHNb6PJJDJjDp5zL1UHkRHOCWzj+43+z nYvbx7jRL6yS0mEtxDJGpLx4BZcDPzVD4WuJNG8PWthc2krzQ79xjeMqcuW4yw7GtJV1fRh7OXYy pfFF3BLbx3OlNbyXBCxrKZlLE7OAPK5I39s/dPXK7ti3nluV0uae3a2leRi0TBgU/dycHcAc/h9M jmqPiRbjVtX0O7t7V1jsJ/NlEjxgkbkPy4Y8/KeuK0by9ee9gmSzmCxyFiC8ecbGX+96kUvbppps PZy7F9U2M5Riu87m9zgD+QFOy/8Az0b8h/hVL+0G/wCfOf8A76j/APi6P7Qb/nzn/wC+o/8A4usv aR7j5Jdi7l/+ejfkP8KMv/z0b8h/hVL+0G/585/++o//AIuj+0G/585/++o//i6PaR7hyS7F3L/8 9G/If4UZf/no35D/AAql/aDf8+c//fUf/wAXR/aDf8+c/wD31H/8XR7SPcOSXYu5f/no35D/AAoy /wDz0b8h/hVL+0G/585/++o//i6pX5N9cWYktbkW8cjNMqTqjMuwgAFXB+9tPXtR7SPcOSXY2sv/ AM9G/If4UZf/AJ6N+Q/wrH+yaT/0D9U/8D2/+PUfZNJ/6B+qf+B7f/HqOePcOSXY2Mv/AM9G/If4 UZf/AJ6N+Q/wrLgsNEklWOSDULdnIVPMvJSGJ7ZWQgfjjOeK0f8AhGdL/uXX/gbN/wDF1Sd9iWrb j8v/AM9G/If4UZf/AJ6N+Q/wpn/CM6X/AHLr/wADZv8A4ukbwzpgUkLddP8An9m/+LpiJMv/AM9G /If4UZf/AJ6N+Q/wq8/yNtX5VAAAHAFN3N/eP50DKeX/AOejfkP8KMv/AM9G/If4VD4juJrfw9qE sMrxyLAxVlOCDjqDU1ABl/8Ano35D/CiiigRhebR5tVMH1NGD6mvHuerYt+bR5tVMH1NGD6mi4WL fm1LIVS0jnDkhn8thj7p7fnWfg+pqxbXEcKSpcxyTQOASiY3ZByCM1cLN2ZM7pXRbZVW6S3aTD+Q biQkcRp7+9QxTw3Fm1zA7mJXCN5ibTz0PU8GqVpcySXl9eXMTH7WGjaPOCEPAA/DFRS3H/EuOn2k FxiRlMksyheFOQAAT371vy03sY3mal+6WEjRyi4LqFO4Q/Ic+jZ7fSpPJmBjBCgyDcgLqCw9hnmq MmptBb3cEAv5/NQoizBdiH+8Dknj6Cpb6aC31HTZ54riWeK0jYJEoIPJ9SMc/Wn7OD1FzzWhIrFg SWRQCAS7hRn05NPCSl5E24MfL7iAF+pPArNjuv8AQpWuLdxcS3BlykKS7VJztw/A+tSz3yXkuqh7 e5S2u/Lx8o3gqBzjODyOmalU4W1ZXPK+iLce6TfsKMqDczhxtA9d2cUkjNG21xg4z1zkVStLmKG0 u4UtpUjmCjLRIzZHfa3yn6ZqESy3FyHd7gqsYjHmxpHwCcYC8Dr71MoRUbp6jUpc1mjTuporSC2k lM7tcbtqxRhsbTz1YetEJkniSVIpArvsUOAGz7gE4qtd3uba0gWXUofJDbzajh8njneOn9aSy1Nr FFWCG6meaT969wcEJ9QT8x9e1XyQdieaauXfLk2SPmMJG5jdjIuFYdQTmnBCkd2ZQwaCBpQARzgZ HPpWe8donh0RtHcrD9v+T5QXPy5GRnB/P3obUWke9cWs6Qmy+yxJgbiexPOO56U/ZwWtxe0k9LFy ISSwxyhcCRN6qWAYjuQM5NEgaK3W4lZI4WzhndVBx9TVRL9IJLS7NrcPcwWvkqiqNhODgk5yOvoa qyu01rpVs8Uha2V97EfLyeP5VLhBa3Gpz2sa7JKiksAMKGK7huAPQkdcU2fdbojTskYcArukUFs9 MDOTVPUr95pZ3iFxG00XlssdvEQeMcufmx7YqG8cXl7bkxSbYbVIi0gGGYZzjn3pShBK6Y1Obdmi 95tHm1UwfU0YPqa57m9i35tHm1UwfU0YPqaLhYt+bR5tVMH1NGD6mi4WLfm0ebVTB9TRg+pouFi3 5tHm1UwfU0YPqaLhYt+bR5tVMH1NGD6mi4WLfm0ebVTB9TRg+pouFi35tHm1UwfU0YPqaLhYt+bR 5tVMH1NGD6mi4WLfm1HCYPs8JaCFmMaszNGCSSASSTUGD6mqzb/sybCd3krj67RVxbsS1qambb/n 2t/+/S/4VHMYPs8xWCFWEbMrLGAQQCQQRUedM9dX/OGqa7/sz7yd3ktn67TV6prUjRp6GjG0TGVp Yo5G8zaC6hsDapwM/U1LHHC8SyMulQhi21ZnVWIDFc42+oNZvOH5P+tP/oK0gKNHEGadHRSh2xK4 PzuwOd4/velOL7ikuxosIUleN7ezJUj5o0VlYFQwIOB2NQxmMzlHRXjTzdqsMgYcAcH0BxVRm3SE pvCBUQbwATtRVzgE46etAz50vJ/5a/8AowUm9XYaWiuacMSTtIIbO2fy1DlRGu5hnnaMc47/AFHX NE0SQNGJrO2TzFLhTGu5RnjcMcZ7fQ9MVUsboWc7TmNpJkX9xk/IrHIJbnJ4PAHqenBBfXQvJ1nE bRzOv7/B+RmGACvORwOQfQdeSauuS99RWfNa2g+Tyi8kaoqxyRDcqjAOSwPT2ArU0a7u57XTzdSy i1dVYTNw0kmB8rH+7nOD/FgD/ewhkydT/ql/9Ceuv0OVBoOnAkcW0fcf3RW2Her+RjXWi+Zp01/u N9Kb5yeo/wC+h/jSNKhUjI5H94V1nMQ3KJL5kciq6ONrKwyCCOQRXAXXw/3a2n2ebZpj5ducvH/s DPXPY9uc5wM9hf6zb2128RhvJSMZaG1kden94DB/Cq//AAkNt/z6al/4BS//ABNIZFr1rBZeD762 to1ihjtmCqvbj/PNaNYeuatHfaJe2sFnqJllhZUBspRk4/3a3KQBRRRQBlf2HqPpa/8Afxv/AImj +w9R9LX/AL+N/wDE10u+jfWX1en2Nfbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8AE10u+jfR9Xp9 g9vPuc1/Yeo+lr/38b/4mj+w9R9LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/wDfxv8A4mj+w9R9 LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/8Afxv/AImmDw5erM0oS1EjDBbzG5/8drqN9G+j6vAP bzOa/sPUfS1/7+N/8TR/Yeo+lr/38b/4mul30b6Pq9PsHt59zmv7D1H0tf8Av43/AMTR/Yeo+lr/ AN/G/wDia6XfRvo+r0+we3n3Oa/sPUfS1/7+N/8AE0f2HqPpa/8Afxv/AImul30b6Pq9PsHt59zl 5PDl7KyM6WpZDlT5jcf+O0/+w9R9LX/v43/xNdLvo30fV4B7eZzX9h6j6Wv/AH8b/wCJo/sPUfS1 /wC/jf8AxNdLvo30fV6fYPbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8AE10u+jfR9Xp9g9vPuc1/ Yeo+lr/38b/4mj+w9R9LX/v43/xNdLvo30fV6fYPbz7nNf2HqPpa/wDfxv8A4mj+w9R9LX/v43/x NdLvo30fV6fYPbz7nNf2HqPpa/8Afxv/AImj+w9R9LX/AL+N/wDE10u+jfR9Xp9g9vPuc1/Yeo+l r/38b/4mj+w9R9LX/v43/wATXS76N9H1en2D28+5zX9h6j6Wv/fxv/iaP7D1H0tf+/jf/E10u+jf R9Xp9g9vPuc1/Yeo+lr/AN/G/wDiaP7D1H0tf+/jf/E10u+jfR9Xp9g9vPuc1/Yeo+lr/wB/G/8A iaP7D1H0tf8Av43/AMTXS76N9H1en2D28+5zX9h6j6Wv/fxv/iaP7D1H0tf+/jf/ABNdLvo30fV6 fYPbz7nNf2HqPpa/9/G/+Jo/sPUfS1/7+N/8TXS76N9H1en2D28+5zX9h6j6Wv8A38b/AOJpg8O6 gBhWjUdgtzIAPwArqN9G+mqEFsHtps5f/hH9R/56J/4FSf4UHw7qBGGaNh3DXMhB/Aiuo30b6PYx F7aRzB8PagWLAwqT12TuufyFJ/wj+o/89E/8CpP8K6jfRvo9hAPbSOX/AOEf1H/non/gVJ/hR/wj t9hQBbrt6FZnB9+QM11G+jfR7CAe2kcv/wAI/qP/AD0T/wACpP8ACj/hH9R/56J/4FSf4V1G+jfR 7GIe2kcsdCvogzHyCSOS0zMT+JFS6VDH/ZNlkSZ8hM4mkH8I9GrfnOYz9DWHpXOlWYYD/Upjv/CK 3oUopsic3JK5Y8mL0k/7/wAn/wAVTXt42RlDTIxGAyzvlfcZOKmppDFlIbAzyMda6eSPYzuMEEYw MTN7+fJ/8VS+RF6S/wDf+T/4qljlEm7AI2ttOeKXepcxhhvABIB5APQ/oaOSPYLjfJi9JP8Av/J/ 8VR5EXpL/wB/5P8A4qgnyotzF32LyQMk/gO/4U8cKMknA6mjkj2C43yIvSX/AL/yf/FUU+ijkj2C 5d30b6kaBQM7m/T/AAqEYOcJKQCRn5a5Sh2+jfTcf9M5fzSjH/TOX80oAdvo30qIrx7wzDIBGQP8 KTy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2 j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfR vo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KA DfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5 D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cj y/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+ Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgA30b6PL/2j+Q/wo8v/aP5D/CgA30b6PL/ ANo/kP8ACjy/9o/kP8KADfRvo8v/AGj+Q/wo8v8A2j+Q/wAKADfRvo8v/aP5D/Cjy/8AaP5D/CgB GOY3+lZGl/8AIJs/+uCf+githl2xvyTx7VjaX/yC7L08hP8A0EVrS3YMtg5JA7Uue2cZpoVQQdoy AQDjoDTs1uSQ20csceJpvOcnJO0L+QFTUgIIIFIxbK7VBBPJJxgUAQyzCBk3lAjcZZ8EtxgAd881 Pn3qrc2UN3IpuIo5FQq6buoYZ5qwyKVxgdc8jIBHSgBQSoAO5uOpHWinUUAabHIqurFYsgZJcgZO OrYqQNk1Cc+TkAnEoJwM8B+a4ZXs7Frcf5vrsP0fn9cU5HDEjGCBnqD/AC+lUL2+aC3Zo0eMZAJ8 ogDJAyeO1Ns55P7TaE3H2lGhD7iOVwRx0HXcfyrnp1JOVmOdo6GjB/x7p/uin1HCf3Mf+6P5VJXU SFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADJP9W30NYulf8AILs+v+oj4/4CK2pP9W30 NYulH/iVWeQP9QmPf5RWtLdgyyWGSNygggYNMaRklCsBschU2gk55Jz6DjrTmdR1xmlDgnityRSA OeeKUDGff0o60hUbg5JGARjPH5fhQAuT+FIE2liufmOTkk//AKqU9vSloAKKKKALi5DDIOPpSKXU EBQRknqe5+lRf2HF/wA/d5/38H+FH9hxf8/d5/38H+FcgyYs7KQ0akHggk8/pUcESW4IgtoYgeSE G3P5Cm/2HF/z93n/AH8H+FH9hxf8/d5/38H+FKyAnjBVY1/ujB49qkqoNEjByLy8B9pR/hTv7HX/ AJ/r7/v7/wDWpgWaKrf2Ov8Az/X3/f3/AOtTJtNWFVc3t6RvRcGXIOWA9vWgC5RWRKgN5feZcXix QeWFWFmY8j0AJNJaJbXjEQXmqHGcl96Dg4IyygZz2osBsUVR/s1f+fy+/wC/3/1qP7NX/n8vv+/3 /wBagC9RWathm4kj+2Xu1UVh++5yS3t7CpP7NX/n8vv+/wB/9agC9RVH+zV/5/L7/v8Af/Wo/s1f +fy+/wC/3/1qAL1FUf7NX/n8vv8Av9/9aj+zV/5/L7/v9/8AWoAvUVR/s1f+fy+/7/f/AFqP7NX/ AJ/L7/v9/wDWoAvUVR/s1f8An8vv+/3/ANaj+zV/5/L7/v8Af/WoAvUVR/s1f+fy+/7/AH/1qP7N X/n8vv8Av9/9agC9RVH+zV/5/L7/AL/f/Wo/s1f+fy+/7/f/AFqAL1FUf7NX/n8vv+/3/wBaj+zV /wCfy+/7/f8A1qAL1FUf7NX/AJ/L7/v9/wDWqKO1glmmhj1C8aWEgSL53K5GR29D/nFAGnRWdDZR XEEc0V9fNHIodT5uMgjI7U/+zV/5/L7/AL/f/WoAvUVR/s1f+fy+/wC/3/1qP7NX/n8vv+/3/wBa gC9RVH+zV/5/L7/v9/8AWo/s1f8An8vv+/3/ANagC9RVH+zV/wCfy+/7/f8A1qP7NX/n8vv+/wB/ 9agC9RVH+zV/5/L7/v8Af/Wo/s1f+fy+/wC/3/1qAL1FUf7NX/n8vv8Av9/9aj+zV/5/L7/v9/8A WoAvUVR/s1f+fy+/7/f/AFqP7NX/AJ/L7/v9/wDWoAvUVR/s1f8An8vv+/3/ANaj+zV/5/L7/v8A f/WoAvUVR/s1f+fy+/7/AH/1qP7NX/n8vv8Av9/9agC9RVH+zV/5/L7/AL/f/Wo/s1f+fy+/7/f/ AFqALcn+rb6GuU0+9zp9vGvylYVGT3woroNNLPo0Ujszu4clmYknkjv9K8tXU5mEa4OyJSnBHHb+ laUt2D2OyN8AM7uB+tXLW4EnYgY71xEV60zqPMIAIHH61tWM7LKo3HGOBW4jqo2LDJGKQBnMgkAC 5wpVzkjA69MHNVbG6Scbgwxkr17g4NXu2MdaAA8Y6+lNRw6kqc8kfkcUixKDjcSoAG3sMd/8+lPK glSQCV5BI6UAKBx1oqNFlDyF3VlJ+QBcbRgcH15zRQBv0UUVxlBRRRQAUUUUAFVr7/UL/wBdYv8A 0Nas1Wvv9Qv/AF1i/wDQ1oApW3/IV1L/AHo//QTUEFo02mTQtmKQzzOjFfut5rMjY784PoakijWT U9SDbvvw/dcr1GOxHrVgwW4cKRc5zjPmS4/PNNiRg3Z+3XFjeXds5RJjCIUO4j92/m9MbhuG0jnI jOM7sF81u7WreRBssvte4RPbMyiPysf6oYOPM5xjr83vW1Bp1rtSMxsPJxs2zPhRggbeeOMirH2C D1m/7/v/AI0hmbo6eWjrvL/IpGYmiwN8mAFbkAdAPQCtKobmGzs4HmmM4UlVJV5GYnOFAwSTy3Qe tRI2ntFJJvukEeNyyNMj88DCnBOTwMDk8DmmBboqh5+ndP8AiYBuylLjcR6gYyQOMnoMjPUU5pdP RUZ/tyKw3bnW4VVGSMsTwvTvjjnpSAu0VHPbWtvBJPK8yxxKXdvOkOABknrTbaC1uYy8Yu1AOP3j TRn8mwaAJqKqQtp885hR7reGZAWaZVZlJBAY8EjB4B7H0pyfYHuTAslxvyVBMkoViOoDZ2kjByAc 8H0NAFmiqH2jTeu69KdnAn2N6Yboc9sHnIxnIqSJrCV0QG9RnbYol8+PccFsDdjsp/yRQBboqOC2 tbiCOeJ5mjlUOjedIMgjIPWpPsEHrN/3/f8AxoAKKPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo+wQe s3/f9/8AGj7BB6zf9/3/AMaACskW8y3l5dRRnzknGwHgSRmOLeBnj+Hg8cqOcZrW+wQes3/f9/8A Gj7BB6zf9/3/AMaAOVu4Zl0e1X7MRPHYoI2Nu8riQL0XH+qYHHzHrkf3auS2gne7uVhmEkl3D5b4 ZXWMiIMV6FeNwJGDxg9ON77BB6zf9/3/AMaPsEHrN/3/AH/xoA5+6tZEjliihC2iXgPlmAyR+X5I 6RjG4bznjvz2NamlJ5enxrvL8sRmJosDccAK3IA6AegFXPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo +wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAaPsEHrN/3/f8AxoAKKPsEHrN/3/f/ABo+ wQes3/f9/wDGgAoo+wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAaPsEHrN/3/f8AxoAK KPsEHrN/3/f/ABo+wQes3/f9/wDGgAoo+wQes3/f9/8AGj7BB6zf9/3/AMaACij7BB6zf9/3/wAa PsEHrN/3/f8AxoAoaX/yAoPo/wD6Ea8abMkzANt+YjjvXtkKJHYeXEpVEaVQCc4wxrw8K32xgpxl /wAK1pfExdC1bs6qu1Mjsx7Guisz5U0PmsMjG48DPFZaxt5ITcRk5LHtWhaKjzRszFyPmPBxW4jp bSSN5QYySQcZ54FbC8jNZVgVaYlQQMYxg4+taqZ2gHqKAALh2bcSD0XjAp1JRQAoooooA26KKK4y gooooAKKKKACq19/qF/66xf+hrVmq19/qF/66xf+hrQBRt/+QpqX+/DViaAM7HYDk/3R/wDEmo7E A6vqeRnmP+RrSpsSIIF2uVxjEa/1qxSYGc45paQyhrO77CGVHfZPC5CIWOBKpJwOTwDVadory4W5 khuPssMLxtmCRXLMyEbVxu42ZyBxkYPBxsUUAYYl3Q77h74MrkW9ylqxlKYXduUJgfNkYKjO0HGQ DTrq6llghtL+CaMSwK1yYYHkBJGGjUqDjvk5zjGOTldqigChrG6XSdQgjR3kNs+FCE7iVYAD1PHQ c9PUVPAjW6qktxNcM7cO6LkcZx8qgAcHk9z9KsUUAZOmWDAmaeSY7LmeSOFwoVCXcBhwCcqx6kj5 vpiGGOQ6dZaZ5UouLcweYxQiPEbKSQ+MHO3gDnkZAwcblFAGGjxZkjWO7bTgmWje2kUwtuXYIxtD f3jxnbtGNoxTovtM0tkziaWOO8YpJLHscp5LjLDAx8xI6Dt65O1RQBS0ZHj0WwjkVkdbeNWVhggh RkEVdoooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KAM9P+PR/wDrpN/6G1eGSHFwwA6sTXuaf8ej/wDXSb/0Nq8dtIGa4YhRy351rS3YnsWNOtpJ4y8j ZfPyr6D34rpbBZNqcbYumODk1TiRoxGAMLkZPetq12yZ4IIIyMcVuIv2qKoG3P4ire4CQJhskE9D j8/xqKLgjH5VMDxQAgABJAwSefelIBGCAaB6c0dqAD9KKrXk11Fs+zQxy5zu3SbMfoc0UAdLRRRX GUFFFFABRRRQAVWvv9Qv/XWL/wBDWrNVr7/UL/11i/8AQ1oAq2H/ACGNT+sf/oJrTrMsP+Qxqf1j /wDQTWnTYkFFFFIYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAZ6f8ej/APXSb/0Nq84stOmktonRdsgO9SRw wPY49a9HT/j0f/rpN/6G1c3pX/IPtD32KM/8BrWluxPYzoIN8bGRCpLAlc9OBmtW0hESrnk+tOu1 VVfaAOnQe9WIAAcAAAdPatxEkSOGUgqFwdy45J4xz+dTc5Pp6VHCSQ+SThjUp6mgBozvOSNuBgd8 /wCcUkhZQCoycgYyemeT09KX1PenCgBjuExkE59BminUUAf/2QplbmRzdHJlYW0KZW5kb2JqCjM1 IDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCA1NTAK L0hlaWdodCA0MDAKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVjb2RlCi9EZWNv ZGVQYXJtczw8L1ByZWRpY3RvciAxNQovQ29sdW1ucyA1NTAKL0NvbG9ycyAzPj4vTGVuZ3RoIDE2 Mzk3Pj5zdHJlYW0KeJzt3QlcFHXjx/GZ3YXdBZZbUA5BQFHDW9EQLbw1NY8K1Kw8y8wOy3w6/PdU lqZlmaV5dJtWlpZHpuVjeWR55F2IFygqKsgNy17z/+2Obtses8ty/Bbm+3568QzLzG+GFfbD7PVj OY5jLEwY0pkBAACoDR//8Kflp6w5OTNGdiur0r/+zERfpZyVetE4NgAAaCQ4vba8sur5Nz/yk0uX bDjAX3gzOeTk5qUZ4wJVPgZ1ib6y2KAupnqoAADQsLEyOStTSJUBRVfOvrr2IH+6Y0wO6c1b/5mk VxcbKotIb2gfJwCAWKzYcqyGI0y9q72HjyZThV++eH7xxpOkOsbkpPfr+P6LE7U3stEbAIB6s3Lr iQHD7+3UNt7tEQ7/dXb7xnVTBid5+GiVGt2LXxz96ucjbFq31l/Om6qvLNIUZLs9NAAAVNeqH/96 9tlZldn73B5BGXv7ggULJw9q6+GjkeQYDMxjH/5pTM7a1yap8/42aNVuDw0AjHeXZvfPVDB/X109 t0JD+2CgIfhwe+YzT88sP7vH7RF841PffGvRpAGtPXw0oqJKN+PjY2zntnGbF00tv/Cn1dpLfimW yJVOB1XpC8alNJVKWLcPCzydV9uw9Jf8lSUlmx+/dqXSfLGk2cMxQ/tIK/936avllVqGVXUJ6jbK v3mCzIthtPnqC/8rPLCxvFTLr8z6dg3u/UBAVLiEfMKp9Td25W36sFJL5xu6ybtr5IOzbH7E/7ry 6cvl7gXj5oD75/SZ3mF0XEfvGh8hNHYf/ZQ186knS7N+cXsEVas7F739zsT+rRyNtvaXLIHNx9zZ qlqjncguOJ5dYLUhv4t2sSFJsSGORmNMyZmw7IgxORsXTi7LOWh1KE/uDLpS4fyXJqhw/zv3RSm8 pU7XhAZL5t1hQYuUGPWuJ97eeWFUmMR0ob/f4A8iY+UXlt41+csbT0568I6xj/gyR/cueHHZz3lc 0vhZCx/vyO3/c/VCX52BkYQF3v1+eNOiY/PHvbQ5X94qbfiYzpnLlnS/s2kCxWfjeydHT5rtYyzE g3vLLL/g+8i4mA5uBOOfASeVRASP6B4aIautY4XG6eMdp5964vHizB1ujxDQuu/bi9+d0Lelo9G+ 2nV2zuf77W776vjk9N7/eqjG9dHM29peYnc0xpScyStPGJPz3RsTyrIPWB3NXsWwgQMGsBIj1vh/ txb//f/z/vPI6BaFSE4jp0hRPTg7Snpo0dhp/u2b9vRnGb/+sQ8+ptTumXv3w39Im457ZVNGZ/np uX2nbbnRMkoRoZTKu7339IwuVTsf/2h3dt+mXaMn/5+f5NR7I+7dL1Ek+LBajTb3hiGsRdDQLv27 PPK8D3Mu/7fTPu37+Ph5Merskj9X5B0+qb/5gjGpd6dF8T1jjYu6gspz31/dtbFSbfoa66dMejCs U6qPvw+jyS7+fUne8TMG8hVJkG/nKWEdeiiUUqbqQumRD/MOHSHhs+bdPWbq87cK4dtEcutySUji 1NX3pvhX7n0y5/AFjvGWd369RUpL/al553dzkZMdH+2/Bgy6Ozmh5e2PhLXvJpezTFVu2bGP8w4e 1OrNq50vOHDZr0NPudeJ3JUvlOocHLPdlXGvXWPxyf/OPjFjeuHJ7W6PEHTbgMVL3n+oT7yj0dbt zf7v2sN2t/3vmE738r9Zbo1GNjd+tPhUYDTGlJypH2Uak7N+3gOl560z+IffKFeS8/qzU0fE5CM5 jZ2C7b7yth7BOUuHLzpW8UBrX//kJS1TmhdvuH/s/KNxbXtOe/+Dtj6Z7959z6+MT8cg79ZxvtHB Q+Ife6JJ8fqZ495I6dO777SFQUqG0V46fej3ihuZsnO/nTxdqmbY6Fb9kqfP8WWY8r0Lvvtuy94z Tds8s2pGT9/c9ZMuX7jmw5IAhAUk9y7a/tmz2yoiBs1798U+0v3P/bLraJSXt7zrwpY9W+pOLXn7 /z77X3FM2gOD/Q+u7dpcFdjjnYQeMVV/vDjnvzvVoz98d3LrK99Pzjl/xc/q3l95jxaPkF3zhQgc 1tm/qfmn2KuV5O6320Ze/HnRU+GxDyWOGup95eMZYxbmtBj1+cdzAxwdrcJywPCxMz7p3j2q7OcZ sxcc85u0+o306Gubp545fclfya/GXN/0n/Xbdu46XHJFFzDr7a8Gp9g7ZoXtysop9zZrh9dqNwqf /XJ+xqOP5B/b6vYIoe0HL1n6wQN3tnA02vrfL7667sSce5OsNuQvHNUjulqjmQe0utB2KKvRGGNy 9NM+PW1Mzrdzx5Wc+8Nq7QMB9w0aPOhmWcyhseyPaeG1WVOGR+UpvJCcxs5/dLMpU5tc+2zmw0vv TE1OefjdUL/TK+4dtb5EcXuLtOlLF4RKDv6334N5TVQd4/1TglhG0avF9BdV+r0vDHpU2zJsXO/7 pb3HJkWYbylLr/34VN7Ji4z89rjH/uvHnP/ovru/zJelxMjloeMnLnw0PP+L/zy9fEQ7pbE6Bt3+ Q0VZUqmfX5/7l8+PK9/67LhX7uzdrfvD74b4XvgkfeiafFnHpl5+jOFqoS66U+rkF5aE+mR/dN/w dUVeXVuNmPrenOiCtf95ctnwDsp/Vefmrq0cy35vVonakF81MHLWM4nMxetsdBPmwMqMSWuvSbq0 GTBjxYLmjo62a5+kGWRAU3Jie85674Mon6z3R476Ua3o2nbc1Leealb49ezH3hvWo09H42rGQm+t UKREyqSypIFvreoSYO+Yk/u0t1rZwBgYWXKSb1P8zjV8n/+aM33alGuHN7s9Qlinoe8vWzn+jhhH o3134PLrG049PzJxRLcI4QtdGc1yc/OntuPYjsaYkjP9i/PG5KyZM7ro9F6rtU9ETBw8ePCt1tyM Dmv6n+Ulr8ycMDA0W+ElsdkdNC5ssHzkNx1v0+x4csiBxP97Zlp/7veZGU9uD471axnZ6aFXl4UZ z3LSz/j59I6XRHsxbODo22bM9C1e/8Twl9gYv8Et2ItZmt26+Ojb0yfOGBVH0lO6ccEzr/eMv7Pd s/P9mYMv93vwYogqPkjSOaZPl+fmhhr2vTDoEe82/kO7PdCi78iAZqH/3MByf8zpP0V926AX3lkQ yB56ud8DF0JVCQFsxyastpwp804dOH9BiNUJDff7iwMflrbxGxTK/POTKu/Vxrhr28dyvMYPUrWV Kop7fjmgXxPy+Y11GePePNkizjci9I5Hl7wR7OhoOw9+aj4/4KSShEFzli8MZQ++1PehvDC/VjF9 Hpr/eghZbeAjks6DZ73BrzbherhffIi0S1Rq19kL/O0ec+fBT8//98pNWF/8tjUWa3+7POXhRy7u /97tEaKT7165/IMxKRGORtt65OriH84+MSR+cMdw4QtdGc1yc/OntuPYjsYYnyetf3r9dWNy1v4f Sc5vVmsfbzZhyOAhrPRmY2zac/Ms55WnJgxsguSIAtt0ZuvJoxQH5n+pfHp8UvHmyQMWn2Nuj/RO igvumP5tq7beR17uvyKzckgbaZhE4t3+3Q7DO6p3Tst44beW8T5pCdIAjSHruuFyma44ZMKTS6ZH anc9N+gxZfJdT86b5288bxh1xEuREi+Nb/Zg0rQpyvw100fN82qd+uziZRHKa/tefuCNHy+U+g9d sm1BW/42vUX3pxevau6X80n6iD9lipQ4aZzcdJRet8VOXx7md+q9EaPXX9ZbHL6sfWvVXS0lAeZb dnmv1rPm+ds+lmMk6Zo6pffUCT439h8xJHcMPbN2xqTTJZq2iXcOeN7x0bYd8tIHbwTdPMtJeWbJ 8mjfU++PvC/L16d31zGDn3zcp/Drx0a8Kmsz5P8+IN3i9+vXO14a7eP4mDtbjMmvjLvUGpE1e8nN +sO5+7+zvPCHI9cENhnSMczy06jkESuXLx/bM0JgNL4ulhvavdCV0czbWl1oO5TVaIwpOTO/vWZM zpcv3WsvOQ8NGTLkn9JIrNpz8/9NZzk5SI4oSCJ9xq29rblp+ezCB8Z/zET6tw6V3RElkQfcHTrl 6Vj972vmz/fxVsfF3RN7z2R/bt87Yx/+ocg7JTF16qwh3PEtheczy0tYdYsnut4/WHFkzrhHv2/W fvAc4+0vU7533uJPt3VIbJU0fFFMS99zS4dNW32xw209n1iyNFJx6ZtHM7YWh/R/aHFGf3KSfvMp YaMeXN67f2v1gbfe/WhLu4QWrXvcofltVanGS9lj2W19WxVtn/Peul9kkuAmbdI63Rl3atnr59SS TvGyMPPpkjy19TOvq27dmg9o5fXPlxSdYya/E+af+fX4sZ9IJ77/8WMtrn256LWlt8ekJhk3cXC0 7QbNXv5GyM0Bm9w3fU3P25te/nLq4m1XRj3yQffukVc+vWfiB6fbkdVWmFfj9+v4mNk7pn1gtTKF f3moI2v2XpoydWrugX9H4vC1d2xu03lPklv2Tv+ORLcRK1esGNszUng0sqHVUPyF7o1mPhh+HFeO jaggyfkmz5Sc/95XfMYmOU3/nZybD+r8c88af7bz8lMPDQq7gOSIg0QSNzcpvac3o973n34v/lbe PUbRuoVXWyXLcGxhRZeitIfu7NmuiYJhtNdLTm74bO7SDbn6xFjf6Gbtxk9/1jc8Jkhleuqx/kbJ 0bVvvLDs9wrvlDb9nzIm5+/PlpzsOnZE2xAZU3nuzLpXn132uyFY1TlckdZ3SpN+Ga3DvZjys+d+ +y2w//hb5weqga2DqsImJgwb3K6ZD6M+m/+/17d8edSnpW8LmV9uk8kJdw1KaqYkdVDn7Dq3beVX W8637urf0vJZy/LUxJmvqay/xyNn3nmZHfhpfBvv0wuHTf/mSkxMYFK/hY9Mvb1qxzNf7JPf/yLZ xMHRxvaZ8f78IPPh3RYrue2JDv27G4+i6uLlrQtmLvy5zN8vuUXfGUstVmvNV8TBMfccMvTZ11TW K0Mj8cWe3KlTpl769836lsPX3naQnKeGxN/175v1yG4jVqxcMS41qp5HM29re4nd0RhTcp76+oox OV+/nF58xvpdDY6FPzjkriG2j+LcXLj1+ctPTRgcloOnD4gFx50+dmPlWa2BYUIjVe1D5XfEyXxN d1UZtLrDpyv3X1LnluuryJel0mA/r+hQ72C5NCnOO4bVrNldeqpMX64zPb9ZIglUecc1kQeF93ns 7dcDjDepEy/7SG8UaYo1ZFtJeIhPq2BpSJg8JYQ5crT4x4tVN7QM4yVrHSG9nFNVwsjatVINaiNX FVdtP1V+PF9brOXIV9s29+3RVNa0iZe8WL0ts+KvfE2R8dWmbHCQvEWId0KgV4sor1DLv46qKt7c UpJn/U16PzQ00HA4/7NLhpBmqnYB0sTm0st/FW/J1Ukj7lr93ZtNBI5WpV5kHJA/PG9FgXrz3+WZ hbpK4xUiaRKsaBXsFdRE3itA/fY/q8nDTb895YUOjrmJ9pOt1itD47B6z8WpU6bY3qwLbGLvZn3l /anR9TNa1pXy03nlVhvyu2jZ1LdVM19HozGm5Dzx1SVjcta9klF81jo5HxzggkONjwiR5Nz6yC8y lhcW5Pw1Plklx1mOWHCaMs2+XAMpB8ewYdGKrgHmHwpSHcOFa5rzJZxaz5leBsP6qWStm3mFk3Mb zpB9WXO+2KA2PuGKx/qqZLfF3Zny9Kt+tx5QiVMwFVrG+BoXiSQs1Kt9E6mcZTTl2hOXddc0nPFy VqKQGjQ6MoikaxtFuJQrKdZmXtXduLkV2yxc3j5EIuO44mJd5jVdoZbjX98jV0hjw7xbqFip5aP0 Bv3RM5orZGTrb1PSKoS5UEiOlg2NVCQHsVUlmj8u68q9e4//YEFzgaPlzAOaDk9iuHpde+oGCa3p u2bZkFDvDmFSpdVqfEUcHbOv4cRZm5WhUVi9++LUyZMvH7R+vMR1EV1HrFi16v5e0R4+GmNKzuNr c03JeXVMydnfrdbW6Ax6A2cziDVyeyOXSVm83w24R56S8Pgrt5LjPyRJ6dE3qQ3raMHjfb7rwsOT J9XwZn35qg/H927u4aMxpuTMWHOBf13O2JKz1q/LAagnVWXzvy803XHkf1c7j3+5ScM6WvBsn+/K SUkbmBQf6fYIJ85e+m3ntvG9Yzx8NIZ/Xc6abFNyXhtXavNSUIB6YtD+mVl52XjHkay759+IN6yj BY+3fNsp5ysJenhgYoMYjSTn0dWml4Kuf308kgMAAHXH+IY3n591+O4DAAAAtejRL02vyxnZpQnt IwEAgEZuw6HrbK+UHrv27ivKv/niBE4qp3tMAADQaLD6Kn7ham72lOlPWScnMLQpvWMDAIBGxRwX +8nxD7Z+azYAAAD3lNy4+fYH9pPjFxhK79gAAKBRKSvK5xfsJ8fHP5jesQEAQKNSUXKDX7CfHKUq iN6xAQBAo1JZWsgv2E+O3DfAdptevXpZXbJ7927+QrJgXoFfrgm7O7JdwelOa+t4hI/T9tisrhYA AJGrKi/mF+wnx0tpM4EIw9xxxx3k46+//upoUKcruMjtHdXWAbjOao/k0/rcOwBAg6CtLOUX7CdH Kve13SYtLY183Llzp6MLrVbgP7XdxCm7O7Ic0HJY88qWXxU+HtsLzZvX8FDJp65cFXa/ajsIAEDj oK8q5xfsJ4f1Utpu07dvX/Jxx44dji60u2x3K2Hu7ch2Q9c3qa1DJZ+6clUIHKflIAAAjQOnreQX 7CeHkSlst+nXr5/lpz///LP5QoFlywtd5N6OrJbd2MSNQ7X6ToV3LXCh5eXVPQAAAE+nU/P/bz85 Bom37SYDBgwgH7dv3+7oQttlM6uthLmxI9tlNzaxu1/Xj5YsCOzazGpf/FZ2BwEAaBwkBg2/YD85 OkZmu82gQYPIxx9//NHRhY6Wq8vtHVltWN1N3Dtm81ZkwemuHW1ldxAAgMZBRqpiYj85GoPEdpsh Q4aQjz/88IOjCx0tV5fwjvgFV3bqyrHVyjHbbujKsAJHCwDQmHhLDPyC/eRU6Vnbbe666y7yccuW LY4utFqB/5RntZUwyw0tNzeP78pOrVZzdDwCQ1X3gC03rO6ua7J3AAAPJ5dy/IL95FRqOXrHBgAA jYrS6+ZpjP3klFfprTa4++67bUf5/vvva/3I6m1HNWf3UBlPPVoAAFp85VJ+wX5ySiu19I4NAAAa FZXSi1+wn5ySCg29YwMAgEbF3+fmC2/sJ6eoTE3v2AAAoFEJ9Lv59gL2k8NJ5fSODQAAGhVWX8Uv 2E/O2ZxL9I4NAAAalfiYSH7BfnICQ5vSOzbwIIWFhbQPAQAaPCdnOf7BYeRjcXExtQP0PAEBdqat M6u764rufvEzAAA15yQ5qqAm5GNJSQn/6bFjx2plr+3bt7e6pAGN7O/vL7Ba3V1XdPdrHh8AwG1O kuMXGEo+lpbenMeN3JzZ3qZXl91BGtDIKpWdmVLN6u66ortf8/gAAG5zkhzfgBDysaysjP+0AYWh 7kb28/MTWLPuriu6+zWPDwDgNifJUaqCyMeKigr+0wYUhrob2cfHR2DNuruu6O7XPD4AgNucJEfh F0g+VlbenDq0AYXBxZENeq2uophcDzIff4nUy5WRlUo7k3ObVfe62nZ2S/+4wRLWziQRdbpfYbb7 NY8PAOA2J8mR+xqfraRW33wPAorJyc3NZVk2MjKyFkcmvTn0brq+qkwiY+V+ge2mrHZUHctBFAo7 k3ObVfe6mrP92eaq2Cm3P1rP+xVmu1/z+AAAbnOSHG8f47OVqqpurkQrORcvXtTpdBzHeXl5RUdH 18rIpDcH3x7hExTgHxnHSmXl1y6qy4vbT1prtzqWg8jlQu/IIHBdlWiLTtw4+nfByezC84WlBVVq rUatiQyO1Gi0iaq2U+6YVkf7dYPtfs3jAwC4zUlyvJTGZytpNDff3LP+k0MyQ3qj1+slEuNdTyQ8 ZCE2Npac8dRkZNKbP98dpQwMDIhuSa4ERiJlpd7FeWcqim90nvSFbXUsB/H29hb47hxdVxfLc369 8nNx1Y0AeaCPt6+EZbUGrVanIx/V2qpDR/9MDrt9ct+Ha32/hUcf8ZL5sv/cccdpNSX+bd9gJRaj ketSomBZqcB+zeMDALjNSXKkcl/GdEPPf2r35ptUIS8vr1mzZi7uslrJuXz5Mn+XjlQqJTsyGAzk YJRKpd1zHRdHJr05/N4oZVBwQGSr0qvnywqvchJWGRihCk8suJRZdqMg9THrcx3LQWQymcB3Z/e6 KtYUbcxep2d1Yb5hZZoyCSvV6rWm5Gg1Bq1Grz108M9u4T1mDHlC4ODd2C9RsG94/OBfjYU2TrbH MSyrU+dfOzqXu9VsiRf5q8Kb9WsnD71DYL/m8QEA3OYkORJv47OVyEkG/6nd23RyFqLVauPi4lzc pRt3rJ0+fdrLy9gA8rc2iY2jB9JdGZn05uj79yiDQlRRrUrzzlWUFTS7azG5/PyGJ+Q+oX5N466f P1V0vWDIC99IZF52ByHxE/ju7F5Xuy/vPHT99/iQeK1eV6wuyczOPH3+tIac3ag1URGRpDwdQzo/ M2K28Hfkxn6Jgr2j4gdv1eQt02ukjMSfZVWKiL6kM+QvBXJlMJyBdIiV+J37eVxQt+UC+zWPDwDg NifJYb2MN+7k3IL/1PY2PTc3l/SGP//g/s3yEsut3EhOVlYWf/cOOeNp3bq1o9WcjmzszfJ7lQGh qsjE4qtnKooKgvvNbxEXL5FICvKv7V85WeETGBDR/NLpMzeuFI9b9L30VnUsB+Hv4nPE7nX1wZHF Ui/WT6kqV1f8efxw18jkialT+S/d/86YVk1b/V/Gy06/Izf2SxTsHBk3bKM693POwBmqbmjLr+pZ iZeiGcNpGYOG48i5i07Venb29ntCev0zh6ntfs3jAwC4zUlyGJnx2Uqc8S9iI6ubs0uXLpHTDvNN Ib+a5Ud+oaysrEOHDuat3EjOqVOnzMlp06aNo9Wcjpz51ZOMoVwVkVicd7aiKD9s0ILmMS3MDwvl X7/284IHFX5+wVFNL2Zmc9KwcfNW2Q5i92EkM7vX1TPbZpSUF5PTGkbL9k8cOK7Hg+b1P/xp5UN9 Jx7M+12vNxiM/xGGtFb9amW/jDE5d8UO3lB27htOU6Ytva5qfZ8ipI3p0Rv+LIcznuXIAk+v7xWa tsnulcbv1zw+AIDbnCTHYHqQ2XxjZ5ucqqoq/lEW/hK71al5cjIzM/nnTVVWVrZt29bRak5HLrlw 6PSW/8qDooqv5bV74ENVQJDVqUNZSdFHjw4nZ0HXcgpGz1nUotPttoMI3/java52ndtJcsJHhSRl QLtBe/N39mrS17zVxlPrt2duLSsvq6qs8jJ4fTblq1rZL1GwfVhC+m5yQsMHhiOnK5pLuqKfOX0x pyP/lXD6MkXUC+c2TgodtNnulcbvVzh4AACucJIcPWu8Z8l8u2x7m37x4kVyokNuj3Q6HX9PmtU9 bIzpNqtjx47mTdxIzt9//61QKMg4JDm33Xabo9VcGbko51DOH18eq2w75eFppJevvfYa+e5Yk9mz Z3t5eS1fttRw/Nc+Dz5q7o3VIMJ3MQlcV2bf5359oSR7Rttn+U+/Pv7F7+d/a9+qHSuVXLl2peRS +ev3Lait/RZsGRY/5idDxTFjY/SlnK7IoC0ky4yu6H+nC3/N1hdXVmp16i6yG2Mf2ibw/QrfrQcA 4AonydExxmcrmR+4tnszev78ea1WK/CovhU3kvPXX3/xL0isqKhISkqq+ciffvrpxIkTyY3p/Pnz 4+LiyDeYnZ399NNPk+S88sor5EthYWGOBhF+IF34uiJ+uLQhp+ycTqs7e/VslVqjUWsjgiJiw2Nl 3jLjU9eO/tmn+YD7bs+orf0WbBgeN/4HfemvxnMa45lNkWmhcFtm4XG1qkubrlHBLXee/O73E7s7 hw+dMmiWo/0KP3kBAMAVTpKj5Yw3NOan5zp6knRubq7AKzStuJGckydPkp6RHZHktGvXruYjr1q1 aurUqWTAN998Mz4+nk/O448/TpIzZ84c8qXw8HBHgwg/XVj4utp2adOZ4syEkJbkdlxr0BmfKm16 tnSJukQqkZ3LPi8rkj855OnwwPDa2m/+l0MTJm/RFm40xabo5v1p+uLHNxbdPWQoI5UMbzPjrR1T pYzk200/bnzpsKP9Cj9FGwDAFU6SU6U33oNvfhEirXcfOHHiBH8KVV5eLrCa05GvVl6+VJq769wv WZlZQ7uMGNph+KJFi1q1aiWRSMi52vTp03+8/P32Uz+qdP7tmnSK8I3qEZ9iO4jwiyKFr6ttFzaf LDgaHxqvNxg0BmNvyJlNRWX59cLrly5dbsI0HddrfLsY+8/uc2+/BV+lNx/zgbbgAGOo4Dg1Y1Az nJrTV41du/HRMdMH3zaJX23T8aWvLZ+79dWTjvYr/EJUAABXOEmO2vSHtfmtVmgl5/jx4/z7GVs9 E6G6I7/6x/Oc3qDy9SsqLyo/q3v1nnkffvhhYmIiOcs5e/bsmDFjVmW9F+TvX1xZdO5izqmjZ7c+ 97PtIMJv/eL0ulr315qT+cc0Gu2ZnDMataZKrfWV+rQIie/SoltaUl/z+U1t7bfi2Ne6/ExN7iGD 9l9vBT31wtVhwwboGMN/+n88f/sEhVTu6CyH36/w2+0AALjCSXIqtcbH/81vKEkrOeSrdp+JUN2R F+2bn33lvLdOceV8XpA+JNY7TqVSSUxYlj19+nRlk7Iin4LggNCzl85G+EUte2S57SDCb3DpynW1 ct/Svy/9veieJQLj1MV+LX3687t7LnyZ0j61ZdNOp/MO/3ZsT3LESLuP5fD7FX5TUQAAVzhJToXG +Gwl8/MCaCXHo0YWfht/V64rA2f49uDX93bLqOf9Wvlo+6LN+7+srCpXyn2HJmdMHDBTYL8uPjcE AECAk+SUme5Z8/X15T9tQGGou5HLy8sF1qy764rufs3jAwC4zUlySiu1jMUUyA0oDHU3svCUzHV3 XdHdr/A02AAArnCSnJIK47OVVCoV/2kDCkPdjVxaWiqwZt1dV3T3ax4fAMBtTpJTXG78sr+/P/8p uSWqlb3aDUNDGbmkpERgtbq7ruju1zw+AIDbnCSnqMz4bKWAgABqB+h5iouLBb5ad9cV3f3iZwAA as5Jcm6UVDjeFkQkKCiI9iEAQIPnJDmcFC8ABACA2uEkOWdzLtE7NvAgrs/6CgDgiJPkLPx4I71j g8bsmcn3vrlqHe2jAID689qsqea4IDlQT0hsgoKCCgsLkRwA8SC9IR9dSg6/KkDNvbBwBf/jZE5O nf50mXcHALSQX0MGyQEqSGn4J79ZJocs19HuyC7qdHwAcMryj0skB+qV3bMcJAegEXMnOTm7x0pY BctKbg3C6XVlUT2WsRKLmbtYhpUqWRYzFoNDjpLTv39/25V/+umnGu4OyfFA5N/a6l/W9hJoTNxJ zpkfesUP/pVlWcY0bQ3Dsjp1/rWjczmW5deUevuzrNynSbIqws5tBwDP6VlO7d76IDkeiP/zwvJf Gclp3NxJztktfeIG/aDJW6bXSBkJqYtKEdGXkXgxxpnTDAxnIB1iJX45Ox+I6buW0vcFDUB1k2P3 L2LGdINlPjGyWt/yQiTHA/H/ppb/slbL/ILVVy1DZTdaVluB53ArORvSWgz9Xp37OWfgDFU3tOVX 9azES9GM4bSMQcNxOobRqVrPzvnp3vhhv1L6vqABqK3kMDY3SYzNLRdZRnI8kEByHF3I2IuN8Fbg Ody6Y219SuzgDWXnvuE0ZdrS66rW9ylC2hgfvWH4sxzOeJYjCzyzoXfCyN2Uvi9oANy4Y832BsVR lpCcBsH238tuJ5wWBclpKNxKzlepCem7yQkNHxiOMRg0l3RFP3P6Yk5H/ivh9GWKqBfOb5qckLGH 0vcFDUBdJ8dyQyTHMwn/g1r+I7qeHMvxkRxP41ZyVqfGj/nJUHHM2Bh9KacrMmgLyTKjKzJdQpJT rox98/yG6QnjkRxwyL2nD1jdMLlylsNDcjyQQHKqdRIjfJIEnsOt5HzUK278D/rSX43nNMYzmyLT QqHp/Ib/r9wnYVX2V08kTEZywKHaSg7j7LEcHpLjgWz/YmAET2iQnIbOreR8kBo/abO2cKMpNkU3 708zfizle8MZ1L6Jq7O/eCrhESQHHHL7SdJ2/zTmP7X7zCUGd6x5Kqf3nVp+Sfi5bQJ3x4HncCc5 51YMis5YpsnfzxgqOE7NGNQMp+b0VQyn4bgq42M8nF4eOebiujkJj/5C59uChsDtdx9w7yFiJAeA OneSU3jgc3XeifLzvxu0DuYJ5RhW5hXQdmjYgOfr4XuABsq95Dh95rQjSA4AdXiPNaDGNjl1PXEO JuYB8ARIDlBQz5MXAIAnMP/iu5+cbUcuD+wYUV8HDI2Eo+QcOnQoKSlJKpWyt961z0yn0+3fvz86 Orp58+YSicR2TADwcOZZS5AcqFeOkkOi0rlz56qqKnNySGkMBoNGowkJCbl+/fqZM2eioqJQHYCG CGc5QIfd5HAcd+DAgS5dumi1WlIUUhrGlBy9Xk+SExwcTD6SC48ePRoREREbG0v3WwCA6qrX5GCu HTATTg5pzL59+zQm2lvS09PNmx86dKhbt262d7451bVrV8tPDx48KPAl4Usst3W0C9t1BL5q/pIb R8VvYl6wu1PLNQGoqNfk1GSuHfyqNDLCySELfE7Igt6EnOuQ6pBTHLIQFhZWk+RY3aA7urF2+iMn cPsusKHlV50uu3hUwslx/UKAulavycFcO2AmnBzyKVkgjSGBISc6/H1rBElOWlpaQEBAbSXHfAnd 5NTwqITH4RcsV7A9nbJ7ggVQ6+o3OTWYa8fql8p8RwFjcaeB5cr8gqM7KIR/0/DrVw+cJscSf65D ekM+kmUfH59aT47wl1wcqrpbubJrV47K9bMcu2vijAfqTf3esVaDuXYsf1UYe7ER/l1y70KoO06T c+zYMZ2J/hbyVVKd1NRUb2/vukgO4/jPl2rdMeXGYzk1PCokBxqK2kmOwA4sa1STuXac/qq4focD kuMJqnWWw5hOdPgnsJEFmUxWR8lx8RL3zn4EvlrDo6phchjHZQWoXfV7llODuXaqlRzbPyQd/dZZ 7kLgj0qodU6Tk5WVxT9rwGBClsmFZKFz5850k+P2YzwCX6WeHBe/NYAaqt/k1GCuHdeTU1snNPj1 q1MunuUYT4ZvfTSTSCS1/ow1gXUYl39mBMZ0+lXXT9kFjgrJAQ9Xv8mpwVw7tZUcuw//2IVfvzrl NDk5OTkGC+bqJCYmktLU+uty7J4ZC6/GOHgwxu2TpK6On0jm9KhceUTT0bLtfgHqSL0mpyZz7bh9 xxpj81wDp3fBWX4KdaS6j+VYIclJTk6u86MEgFpVr8nxkLl2cPriCRy9xxr5p2nfvr1UKvT2E3q9 /vjx466UCQA8iljeY83u3RFAESYvABAhsSQHPA2SAyBCSA7QgflyAEQIyQE6MF8OgAghOUAH5ssB ECHMlwN0YL4c26/afYK+i0flUW/XZPcFCQBMA5ovxynhV9i5+HOP35B6g/lyXFl28ag8Kjl4XwMQ IIr5cpAcD4T5chgX0lK7yRF4dwNH51WWw1q9cwcjeA5nu6HT/YIYNLD5cgR+6O2+p4CjXxi7qzFI Tj3CfDku7tqVo3IlOS6+DY/AO+K4+JZRrg8LItSQ5sthXJsmx+6vlsD6wttCHcF8OYzg3zrVOqp6 SI7TOwPdGBZEqOHNl+No2cW/CpEcD4H5cmrxqKp1x5rtnQG8ekuO7ZGAeNRCclxXK/PlOFp2IzmW 6yA59Qzz5dTiUVXrbybhlesnOQKbQ+NWv8mpjflyHC3X5CzH7ppQpzBfjsDlbh9VLSbH7t3R1T1O /LqBlfpNTm3Ml+NoGclpWDBfjsCxuXFUTpNjO7jw93jQwct93D4Nsr2DAb9rIlSvyamV+XIcLVtd yC84/X0wj4871uoZ5supU3Zb4sYg+HWA2lWvyfGQ+XLAE2C+HM9UK60CcKRekwNghskLAEQIyQE6 kBwAEUJygA7MlwMgQkgO0IH5cgBECMkBOjBfDoAIITlAh9P5cvjV+FfkkOqQ856goCDz5nX67gOu f9WNrVwfEM9RhsYHyQE6PGS+nFpfvxYHRHKg8UFygA7XXwpqro55ypy6mC/HvNDVwZs0C68pvBW/ ILAX29XsHipAQ4fkAB2eOV8O49qkGI5i4+LbLwmsL7wtQEOH5AAd1X3DG/5BHf4xnjqaL0f4hMbR m4HW+jv+ITnQiCE5QIfT5KjV6r179544cSIoKKigoGDkyJGBgYGffvop+ZRsQj5mZGQolcrq7teN 5PCX1HVyLNdBcqCxQnKADqdPkl6zZk1ZWVl6enp5eXlubu6RI0cUCkVaWppUKr1y5Qo5y1GpVBMm TKjuft07y3H01Wpt5cr6wocK0NAhOUCHcHJ27dq1Y8eO0RkZ2zZv/u2335o2bdquXTtSmvz8/Ly8 vJSUlF69em3dunXu3LnV3a/byXF6od0VkBwAS0gO0CGcnCVLllRWVg4aNiwxLm706NGzZs0KCgoi Jz3Xr19fuXLlt99+e/jwYZKl5557rrr7tb0Lq1oPqNg+tIOpNABch+QAHcLJWbdu3R9//PHApEmb 1q/fs2cPy7K+vr5knfLycrJOz549+/XrR8KzaNEiyt8GAFQHkgN0CM+Xk5OTQ3KSlJQUFRVlMBiu Xr2alZUll8tjYmLCw8NJgS5cuJCZmbl06VLK3wYAVAeSA3Rg8gIAEUJygA4kB0CEkBygA/PlAIgQ kgN0YL4cABFCcoAOzJcDIEJIDtDhdL6cffv2aUy0t6Snp5s3r8l7rFl+ipfFANQnJAfooDJfjqOK 4MX/APUDyQE6nL6tJ1kgjSGBISc6/H1r/PwFaWlpbs+XU620IDkAtQ7JATo8cL4cp2sCQA0hOUCH 0+QcO3ZMZ2KeD5R8lVQnNTW1JvPlMIIzeFqthuQA1C4kB+io7hRtfG/4BZlMVpPk8JzOhIbkANQ6 JAfocJqcrKws/lkDBhN+PlCy0LlzZyQHoIFCcoAOF89yyCXmj2YSiaQWk8PgGWsA9QXJATqcJicn J8dgwVydxMREUhq3n7FmXrZ9EoHVl5AcgFqH5AAd1X0sxwpJTnJycp0fJQDUKiQH6BCeL0cqlQps q9frjx8/7kqZAMCjIDlAByYvABAhJAfoQHIARAjJATowXw6ACCE5QAfmywEQISQH6MB8OQAihOQA HRTny3H0apvaekGowKt/AEQOyQE6qMyXI6wuXvuJ15MCWEJygA4q8+UwNu9zwy9Yvt2AwPtM2z19 sRpEYHcAgOQAHdTny7E7cQ5j8243dtcXvtDu7gCAQXKAFlrz5QgnRyAqbiQHvQGwguQAHbTmy6m3 5KA3ALaQHKCD1nw59ZMc9AbALiQH6KA1X07Nk2P3IR/hkQGAh+QAHVTmy2FceMaa1Wq26/PPahN4 xprlE9sYvDQHwAKSA3Q06PlycB4D4B4kB+hocPPl4D0FAGoOyQE6MHkBgAghOUAHkgMgQkgO0IHk AIgQkgN0IDkAIoTkAB2OkpOze6yEVbCsefo1Tq8ri+qxjJV4/7Mxy7BSJcsKPcUAADwQkgN0OErO mR96xQ/+1fiCG9NrQBmW1anzrx2dy916CY7U259l5T5NklUR/d3YL57fDEARkgN0OErO2S194gb9 oMlbptdIGQmpi0oR0ZeReDHGl4IaGM5AOsRK/HJ2PhDTdy3l7wEAqgnJATocJmdDWouh36tzP+cM nKHqhrb8qp6VeCmaMZyWMWg4TscwOlXr2Tk/3Rs/7Fc39mv1tgJW717D/Ps1N3bnwnF91hzhqXQA RAjJAToc3rG2PiV28Iayc99wmjJt6XVV6/sUIW2Mj94w/FkOZzzLkQWe2dA7YeRuN/br6K3SGMcz 5dT8QgDgITlAh8PkfJWakL6bnNDwgeEYg0FzSVf0M6cv5nTkvxJOX6aIeuH8pskJGXvc2K97bwKN 5ADUCiQH6HCYnNWp8WN+MlQcMzZGX8rpigzaQrLM6IpMl5DklCtj3zy/YXrC+DpPju19aI7qYrkL 27cBdeM4ARolJAfocJicj3rFjf9BX/qr8ZzGeGZTZFooNJ3f8P+V+ySsyv7qiYTJdZuc2jqhwekO gBmSA3Q4TM4HqfGTNmsLN5piU3Tz/jTjx1K+N5xB7Zu4OvuLpxIeoZkcR7PmCOwRAJAcoMNRcs6t GBSdsUyTv58xVHCcmjGoGU7N6asYTsNxVcbHeDi9PHLMxXVzEh79xY39un3HGmPzXAOnd8FZfgoA DJIDtDhKTuGBz9V5J8rP/27QVtjfkmNYmVdA26FhA56vx+O1A6cvANWF5AAdDfQ91jBrDkBNIDlA RwNNDgDUBJIDdCA5ACKE5AAdSA6ACCE5QAeSAyBCSA7QgflyAEQIyQE6aM2X45TAU59df1Y0nj8N YBeSA3Q0xPlykByAGkJygA668+UITJNj9z0FHE2xY3c1BskBcADJAToozpfDuDZNjm023JtWBwDM kBygg/p8OY6WhZODyXIAagLJATqoz5fjaNmN5Fiug+QACEBygA7q8+U4Wq7JWY7dNQHADMkBOqjP l+NoGckBqDtIDtBBfb4cR8tOn7Fmd1vz+LhjDUAAkgN0NIL5cgCgupAcoAPvsQYgQkgO0IHkAIgQ kgN0IDkAIoTkAB2OknPo0KGkpCSpVMreeh9PM51Ot3///ujo6ObNm0skEtsxAcDDITlAh6PkkKh0 7ty5qqrKnBxSGoPBoNFoQkJCrl+/fubMmaioKFQHoCFCcoAOu8nhOO7AgQNdunTRarWkKKQ0jCk5 er2eJCc4OJh8JBcePXo0IiIiNjaW7rcAANWF5AAdwskhjdm3b5/GRHtLenq6efNDhw5169bN9s63 mqvd+XJsX7IDIGZIDtAhnByywOeELOhNyLkOqQ45xSELYWFhdZccATWcLwevDwVAcoAO4eSQT8kC aQwJDDnR4e9bI0hy0tLSAgIC3E4OxflykBwAJAfocJocS/y5DukN+UiWfXx8apIchtJ8OUgOAJID dDhNzrFjx3Qm+lvIV0l1UlNTvb29a3iWI7BcR/PloDcADJIDtFTrLIcxnejwT2AjCzKZzKOSY7mO 3W3RGwAekgN0OE1OVlYW/6wBgwlZJheShc6dO3tacoTvQ0NvAMyQHKDDxbMc41TUtz6aSSSShpIc 9AbAEpIDdDhNTk5OjsGCuTqJiYmkNPWQHKY25suxe7cbgGghOUBHdR/LsUKSk5ycXOdHCQC1CskB Ohy9xxo5D2jfvr1UKhXYVq/XHz9+3JUyAYBHQXKADkxeACBCSA7QgeQAiBCSA3RgvhwAEUJygA7M lwMgQkgO0IH5cgBECMkBOpzOl8Ovxr8ih1SHnPcEBQWZN6cyeQEA1BCSA3TQmi/H6dsB4P0CAOoO kgN0uP5SUHN1zFPmuD1fjt2JbSwvcboCANQEkgN0UJwvp1pveIN35wSoRUgO0FHdN7zhH9ThH+Op n/lyBJYBwD1IDtDhNDlqtXrv3r0nTpwICgoqKCgYOXJkYGDgp59+Sj4lm5CPGRkZSqWyuvtFcgAo QnKADqdPkl6zZk1ZWVl6enp5eXlubu6RI0cUCkVaWppUKr1y5Qo5y1GpVBMmTKjufpEcAIqQHKBD ODm7du3asWPH6IyMbZs3//bbb02bNm3Xrh0pTX5+fl5eXkpKSq9evbZu3Tp37tzq7hfJAaAIyQE6 hJOzZMmSysrKQcOGJcbFjR49etasWUFBQeSk5/r16ytXrvz2228PHz5MsvTcc8+5sWuBGXFcXAEA 3IPkAB3CyVm3bt0ff/zxwKRJm9av37NnD8uyvr6+ZJ3y8nKyTs+ePfv160fCs2jRIsrfBgBUB5ID dAjPl5OTk0NykpSUFBUVZTAYrl69mpWVJZfLY2JiwsPDSYEuXLiQmZm5dOlSyt8GAFQHkgN0YPIC ABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQI yQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfo QHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kB ECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQ HKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAO JAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwA EUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJ ATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hA cgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQ ISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAc oAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4k B0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAAR QnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkB OpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EBy AEQIyQE6kBwAEUJygA4kB0CEkBygA8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAh JAfoQHIARAjJATqQHAARQnKADiQHQISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEkByg A8kBECEkB+hAcgBECMkBOpAcABFCcoAOJAdAhJAcoAPJARAhJAfoQHIARAjJATqQHAARQnKADiQH QISQHKADyQEQISQH6EByAEQIyQE6kBwAEUJygA4kB0CEqpecZybfy986ANScVXLw0wUgBq4mh9wi BAUFUTtMaKT45OAUB0BUnCcHNwpQF5AcABFykpzF7y+nd2wAANCoPDH9YX7BfnI4qZzesQEAgEcw PbxSZlr0M1+o06llsorKSoVaXeXiOKz+5ppIDgAA2BEU5EVKo9aVK2QkGMHmy4vKrvlLdQavMJlM Vl5RqHGhO0gOAADYx3GVcoXym282DR82NCgo+NjhA+07ddPpdORLJDM5F48VFVV2aNe9ouLcn/t+ Se07sbCwUHhAJAfAo+3Zs2fYsGFOf5MBat2KFSumTBkfHBxBGkMCQy4hjYmJbm/+lGEuk5Oegqts adWO2IghjIy5fnm7TNlNYEwkB8Cj8S9RQHKgnpEfPEMls/DdN2bPnl1ZWfHZZ5/17ds3IaFFUdkN Pz//t95YnDF2sCrAW+nVXOpV5C1TkPYc2Pe1WnuiV+9XBH5ckRwAj4azHKDip60LRt03j2F0337z TVr/lLCQCP7y7t1Tfvzxx+7du0dERm1Y/+3GTZvvTOsYFpqQdeZ4TCzrL0uWKHWGSlmx2v5PLJID 4NGQHKh/KlXQV598PWpkwMpPlj3+xHdffPL1pp++OXbqzxaxsbmZf2xY/6KPotXAIQ8Eh6b8fTrz /Pnsn3ZuCgtR9OjRh9HJDMz2rCNbi7Tpia0TbUdGcgA8GpID9UylUsoYhU7G6HTln374fsbYDgGq vjGxLZuEyndvW5x/+X2yjlLhq/TxqeLCu3R/u3vqsEFDej304LTCvCuB4bpNG/YNHz62Ulth95nT SA6AR0NyoJ79tHVB/tX/hYSNSB/3nI5Rv7d4yZtvz0/t3nfNF5PVF79VV+kqDAYfBSuXs4ymskIX 3an/qm/Wbpk25clP1i7u0K47P4iOYUrt/dAiOQAeDcmBeqZQGG/213+xrGm0/tCfWVMmvNRzUFoz X82m1YPVHDl54ULCB2aMefSN1x9sGVmirQguNUj46vS4vQfZ8NSpA9HRIUolW1QUaDs4kgPg0ZAc qGcqlUomk1VWViiVPuR0ZdTQ8Zm5B04cXEpOcSp0JX2Hba40NNVVSDWy6xf+eo4rzlarb6QOO3c+ 9+Rnn3xZqb40fPgUpTdrHEhm55mWSA6AR0NyoJ59svp5X6+AP/bv7nBbk+atkr5cncUaVB8uaKnm cuXsjU4DD5QUa4b0H7Jv//4/983y1vykY0LadNs4782Z6RkTTQPIzEMhOQANDJID9SwoKKiygvPy YUk6ym/oU3v3DItULX4tKazpFUMl2+3O75RNIi9nXw0La/rHr1P8mVMMo+zS/6fCMk3GfYPeWLAE yQFowJAcqGckOSf/zPr4k5kB/pLiEkP2Ze702atM5al9O8dXFcoU4WVXriaf+LuoY8fL0YGMQWO4 Vpbdrf++2dMXTnkqXSGTIzkADRiSA/Vs7SeD/jxQKfNPnjdvQZAqmBSkV1oyuXzX/z6qOvepXnKp igtWKA2coUomCeEquDa93wtr1lOp0m/9YYtS6VNUdo2sHOgXXFhYajs4kgPg0ZAcqGdBQRzHFevZ EBmje/XFhwxekV9t+Oly9tU+qUO/3fT6pb/f8VGU+ipDyZoV+qJ70n+8URxx5fqVvKunGEah0+l+ 2Lwt0D+wXac2pC+2gyM5AB4NyYF6pgpSMYxs6VsjruQeTxvweu+B9/Xv2/30X1fVVTfu7NX74PHf d+1/tUWTwX8d1k6cdn/e1etNQuVPPfLKHX3ujIg5V1nczddfahxFdrmwUGk7OJID4NGQHKh//9vy 7Oj7V+pMD8s88/jQBx5e2P62NmmpA8/lZhUX5SckRCpV/pWlJSUlerLyfaMnDBys7tntFbJ8Mf9Y THSoaU4dhd0fWiQHwKMhOVD/FPJApQ/L6Jinn+yRMW5mUod7N26Yn9an78ef7Vzz5TqFNFCjLgsM DFi/ae3IUaN/2PHNx2/PHpMeFhz1OsOUbd+2t/+AyKKiSLsjIzkAHg3JASoCFNxrrz308PQXw5ol b/5mWd71Q5Onrfrqi3np457b+O38ASNnf/j2lOlPr9q+9av2id6qpneuW7e6V0pIfMux/OaOfmKR HACPhvlygBb+Z49hdKtX3HP/xO8M2opdO1+9c8i8zINPte769ldfrkjPGKpjIrQF27xCBspM5zcd Es55B2cIjInkAACAfaQ6e3Z81KnTg/Jg6Z5dGy6f/mXUg6/nZz0f1fatY4cPq8t3tE+ZffbI6biY QjYoWSFhMRE1AAC478jvM9MGf0wW9u+Zn5w6lWF8cv+aTZJTWam5/vfiiM7PkS9JtSs43VSJ0vnp OJIDAABC+HvYrmYt8I+apfSpupr1bkjcTJmMqSz4xiskQ8YwWSfym0RKXRnKTnJ+3rGjoqyEvxTJ AQAAM5KfiqsfeIdMlslkbjzEaJ0cjuMG9L1j85at5uoAAADUooKrl6Y9PnP7jl9vJue77zZqqipp HxUAADQ22ip1SVHBP8khFw0d2HfZ++/KvLyVvirahwcAAI0EOb8hH5+Y+ezmbTvIws3kEORch3yc //ILJDxyuYLiIQIAQOMw4+nZ5CM5v+E//Sc5vN49b6dwUAAA0Bjt2rvP8tP/B5z/uaUKZW5kc3Ry ZWFtCmVuZG9iagozNCAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9JbWFnZU1hc2sgdHJ1ZQovV2lk dGggNTUwCi9IZWlnaHQgNDAwCi9CaXRzUGVyQ29tcG9uZW50IDEKL0ZpbHRlci9DQ0lUVEZheERl Y29kZQovRGVjb2RlUGFybXM8PC9LIC0xCi9Db2x1bW5zIDU1MD4+L0xlbmd0aCAxMTQ+PnN0cmVh bQo4BsDMhB06fp////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////+17VqGFAB ABAKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago8PC9SMTEKMTEgMCBSL1I4CjggMCBSPj4KZW5k b2JqCjQ3IDAgb2JqCjw8L1I0Ngo0NiAwIFIvUjQ1CjQ1IDAgUi9SNDQKNDQgMCBSL1I0Mwo0MyAw IFIvUjQyCjQyIDAgUj4+CmVuZG9iago0NiAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggMzg1Ci9IZWlnaHQgMTk3Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMg Mzg1Ci9Db2xvcnMgMz4+L0xlbmd0aCA3MzY1Pj5zdHJlYW0KeJzt3QlYVFXDB/A7+8DMAMOOQCgg oiIqIhImqYQCGpqmZmquIC64o36pqZm7maXmWr22afq+ZlbaZpZlmpqaqaG44Ia4IIuyMzPfHQbG y+wDA2cY/r+eh+49c+5Z7sz8OXe4AkuhUFAMoxPCKACAevPRgdPMXZY6g1Jf6vykVLZs1hiRnYDF 4ZEYGwDYMoWsvLC49PU1H4oFnPVfnlQVVmUQvfxZmDrMSWIvLymQFefLS/KJDhUAbBCLK2BxhRw7 x7y7V5fsPKVaECkziA6gt+eOlZXky4vz6AAiPU4AsFJbvz1XxxaS+4TSX7kSj6xb19/df4GOIWUG DXmhw8b5Y8ofZSKAAECfbQfP90oc1LFNQK1bOHPx6g/79yTFh9DbxWUV8z/7+4ufzrJ6dA7etTxZ VpxXlpNpscECgM3Z/t3F2bPTijOP1boFu+bPrlq1elxcG6oyg+RyavIHp5UZtHPp2JLsf+XlJZYb LTQpXG7AGI/I5/kCevvfe7sPOg6eIaQ3Pn2rqIz00Oobv5PX8KYy2Q9+SJ81c0bh1d9r3YIo4Lk1 b68d2ytYtVtUWpH60TlWWBv/b9YmF948rVF7/S/5bIGd0UYlspxhUZ4cNqvWw7IK/HDvkWnq2SrK HpXnpBdmHMzLuCyTVxWyROHO0a85+niwlTVKZI+OZH/9QXG5vnIe17OrQ3A3sXcrvj2PouTygozC jK8e/X26XKYw3Hu1i3d3LC4s01tHUXKnOGPvw1NHyyqqGmRJOkk7D3B4JpBLd1j+sOTmz7kn9xc+ Lq/V+NU9Vg6DYmxrv9O4we5DFzsIb+0b02/9+WKFuM8XP69xo04s6Dmp/dDBfZL0H2jyM6JzvgTw tc5DVUnlZAf6d+ATG1oD+PDHyzOmT3t8+Rdm4fnMnH8yc+iNod2D1IU7f7lMf23X3CWkuQuzsiSo +9p31o2JrapJZ9DoTWeVGbR/9bgnN05p9DftsPRukfEzKs09sW6wj5DPqc2crAc/wnfsHHv6lRQz 8o9SicszHaJfmTE+MZi6/vGVQ/vZ5QqK7e7Ub6OHZ965FcMWfvNQENQjcWhY+qb1XXqGhr+sq7xX fLf+vYrOHjz849Gfzt67KwyOmbR2ZoJ30clF50/848jW03vPkUefMB8QpQzza8/XrsPmOwfHTHs/ Lc6j6M/5Z07+68qhWA6x3oNTRNTfR1fN3/RTtiJkRNrqKR0UJ05/ulpUITd7/N09A0XqHie2Gzyo b0r1dr/qIekY/+i7rhI/IcWSy89ffnyf4rbrkLh461InfQea8ozomS8ZfMY5UU+nOGfxrnvZ9GSD nPt3cW3GJTS2+vfRoYzpU6fkpx9iFn5x5OqCT07QG0tGRAyJDtBZouYYHPPOu++Njmmp2qUzaNy2 88oM2rdy9JPMkxr9HRW+2LtXLxZbiaX8X/Vmzf8vn5sysEVu48+gLn7Jr1e+tsYWeIncWIrSCoHD oJ1pA70ffpV8/Oq9AHEn33FviNmXNvQfdIItDLRnlZeV334kd28TN3fdCql2eQtp3yDOVz8/kkm4 Ej6bx6Lk4t6vbVrcouyXBSPeiImSenD09N5M5FYjofhRYVIvro46CsfEketff6b00Lzhi194zjew 73bfAH7GWzETvn3U0kfYzI4j6LxhZmqn0sNTPvwtM8Yz3Ozxd4rtlFLdY+CLi7Yuk1b1Lu0XXjmk GoNXO3Ns84H2KfPsqdP/nb6r8zur/BgPndu0iCdjc58Z4tk1QeziwKLKyu8ezf1rV25mtpyqyfB8 Y+K6KMd2Pedklrh9VwHv/O1t8x5XuIg7p7iHdhYIWFTp7SfnPso+dapcpm7q2sM/MuxDe9qLeVRJ ZsHprdlnLlQtSdlSUViSe/tIoR2HKr35+OwH2X+dpXO7+sDqXjQDtHI6HFWd0/9NmZhexI8K9w+M 0NUUZdqsrdt/fr46NXVS7oUfmIV7jmYu2nlGtb1oaEflV8buoK7NmZWlbXu9u37jqJ5VwURnUPKH 6coM2rv8tcfXT2j096d4gCkZtGx2cn+/h40+gwSRLVIWiKpe8U59O0qk5eX3qAERcye45e6ZOfbd hB5RYeNWSelrg/I7GX8dL3qUzr32x4WMxyX80Ng3N3hpl1MsXx/BvVvFD4oVEmeBn1TgEpTWekAP 3oPPJr68QhTqOTSQz9fT+4thDp7ap1OzjsRd3MsveZpj6aHZcdOosNg5S9e6CNPf6/fyr5R9Byk/ 2F/k65wQMHmqW/7eGcNWRvWMjpmw2rzxB70QMam6x8C+i7Yul+obIbsDP3VpkHodJ47f9fNad+Vu Sps+8Z1mMh6i7JKGvRA3fpVUmPPnkuFLf8qXhvQaNLx96cFN/s48Hsvk+XYesGDVYglFPfh67t7v Dx85U3C3wmn2u3viIn2e/JQ6Z9U58dhPVw7xvf9N8pWMOw52qqaowqOr9u379ugVz9aztqd2Fd3e Ozbr5n17Fl/YZV1gpF/pn/MXLDpcMvCD98YF3/1q3I3rd8XCqgOf9iKIWfvzhg7M6Yx4KTFVNc6U Ngl+nZ/T0xS/rfcYE2Zt3T7+5XrqxJSH5w5qlO89fmvJnvMahQsGhQyI9NUodA2NX//+5te6t1Dt FpXKJuzIUGbQ/94aVnDtT43aJx0Hx8XHVUWNOnmYgVS5sTQtKdEnW8hr7Bn0rP/kReKqV7xjn1CR 8j0mjPabNM9RfmxeXAqrjccrzw6jur0a0kx9B/nj+99Nz76QxfMZItNRfovROovtHOMzJM3JPu/I vP5LDud2DHToFWLvztHoXcO5zA1pBaU6R+j0YmRoq5jFvq1dC3+YMHzh7y3aJ8x/f6Uz+9SiF0Zm u0k6BDhESVmUsFuLSfMlsqPz4iaWt3QfFj2cE23O+Jk9BvZduHW5s8b5UeNFuE9Z4qles4ijR2ym lz+qAxPmbF3ZjLnEEz6bvPEdd865bZNmn87J9eRTpSXld/MVoRGu3aVsDsvE+fZdsJnORGXmHiwS RnlzOdx2cWu3hTlc3vjSgO9KhOFthiW/Pd0rd/ecyRtejOzZIZVu6vqHg/vtesiN8hMIXEeMWT3R 4+Fnc2du6R8W1jJpnYt95oeDE/fk8cKD+idvWOCbs3PutE2JET1DlQcyehFGD1NPTTUd+x4TN1ef meZRs9Zv8RXpaqpz17YTljsanbV1++TXG5MmJN0/8432Q/tOZi378pJ69/WXWvXv3Ey7mnvHvhs3 bRvxfNXimM6gSZ9dV2bQ5wsG5mUc1ah9vtmY+Pj46vCpSiFW5X/MkjdnjO7tminksbW6a1QE3VrP XuFQ9doSxway3TgUy2VEu4kpdrl7Uvu/yfETJ/izbl4q+60iwPfZIWNSB/jT79nH+1fNWta1Gfvf dF3lPhzl9QpLIg6fHRjXU0DlX3h72Kzd15y8xG2cuZF+LAe2du8anwfxRsRJ2vCYdRiKb9z8adPC t/dnce0j/TsnrdvkY0+/W4ZcEdtHB7B9eRTLaWDb1Bmi/L1TExey/MTxLVi3Lpsz/oDu7dTnJDDh ja0rXWqeH71nL+T56LkGDrQTRS5vHttZlbll949lHVz++/EHxRTl48l21jwneuYbGDNls6rZ0Q88 xAEunE4+z4XPWeXAOrUwZlS2uzjIr+eoFctc6O8fvVPYYfFpK+mmTi1+YeQtF0mAlB3m17PT/73l WvndhR/We9ryVY4aKaA4Pr/3eE5Y/MwVqomoe4kOn1vzdWLPmHtg3IItq111NtXGbWCf5f5GZ23d dv6RlTQ+5daJr7QfOnj23rsHrqp3pyYExHfw0K7mG9Fv25bNQ6Oq4qm4TDZz7wNlBu18g86gPzRq /+M1OiE+gcWpCh2tMKpaB705fXRvN1vIoOC05erXVq+WHDeOSNJrR+sIz5zdQ0e8c7FtgH33lhzH MvnlB/KsJxX5LqOnrZ/kXX7k/+Im24U6dLeXX9FV3rtFpG/iG82aO8izvv5g3tIvLhS4eIrbOnG8 vDihEoqlu3eNz4NYHQM4yjf80zqMnOJy3Bz5/i58RyenxIlftmnDP7s4dmt6cUJrjjubzQ99r31i h5LDE16Z90fLAPsegWaOP6LPtOXLdUZJ5fnRf/ZCuneba/BAmfzYRbuL4gC/LsNTk6Mlj7/esWh5 Kym7xrwNz9fz+QlrVjpWNxsdwPG1b9di8iY30aWNLw2+LLKPDh8aP22Kfe7uyf2XcFsnvLF5pbNy HTTgLE8YFcAJ8BoZMiHJ7uHnkwYs57WKnPXONh/xpQ39B+7NkjFGwA0NS1i4eaWU2YtY63Vizyhp HjnjvW1+OpsKlvTxpy7+a2zW1u3zo3QGjb99Yp9G+YGz95kBpELHUEIHd41Cn4j+27ZsebXr0wya 8b/7ygzatXCQrgwalZCQ8DR62BphVPX/ynXQjcafQc8Fz1omUf5cbOxjX48Xn+0YGJH8TMeW8svr p4zfdI0vigzompSWoPjn29zr6YUFrJIWU8OHxwvPLhiW9mDGupecrxwoyaxZPunHjiNfnzg2UcLJ Sv/w9fnb/8zj8II87bzsWG4evA7u3dqm0d2dyVgzNa+U0bvqlR3EU16mVRXqrMPIKRbl7MRt48oW S/u5Js1sLjv++YoV9vwSf/+Xm788zkFxbN2r4w/k8aNaPZds1vgnfuUVGr9A+dbVipKq7eqBUVrj b9cjek71rn+Pue+/58XP2DL4lYt8vnJq9p384jvl/LLv1zPZDz3Hjn9rtBu90nzpLb8Ix2hHZi4b nK93dKfZGmdMKI75uHWkZ9au5He/vzsgZXOXLt53d7w8ZnNGu3Zxc5QDpgqPLn93x/ftWwWFJK71 aym69v6LEz691T7Ase/I7d1eCMr7YcGGPb9w2c5urXt07O5/adOya6znJ2xmBCjdi1144NS10hrT YY5TOnCUvqYiRkyOKPrV2Kyt2+dH7yQlJ98+WSODDpy5v646gKYlKD9sZu4mdKwRQz6d+2/buvXV rt6q3SI6g/6bXZlBiwbnX9HKIM+aGVT1wdDTizHVemjx9FFx7jdtIINazVgqqd5TlD0qzj53+Ycd Kz46nsMTdvQRuHu1Gzp+tr2Hn1RS+VGy7FHB3ztXztt0XN5h/qqF7f39nDXKWb22H1jbQkdPZ6+s nZpHqbqjX7hJgd2d2orVu/TrWNI7uCqDjNdhUrByizrl9RjVvWs7NyFFlT8ouPDlx2+9/+VtWavm Il+vdiMmzRaZPv4iflTr2OmGMqh6YDzmUCvH1r5Ht7TqXW+PwaNWhPQIr7wd4fRfq6crKoTCgEHy joltW9IzkJXePrJ72fwdZ590bCmODeIyrsUMzlfnoxzvh8FT28d2UX7EXnor6+CqGat/euIgjmgR k/r+Cin178frL4S/2r+NC5cqvnZlz5LZ9OydJWEevKgApyce4wL7xIUojywsuXHk2vfbvvj2enDX hL6zNXqxF0UuafY8YzocjZFIyzx1NRXu3q6VCbO2bp/9fjs5KflOzQz69sz9dypDZ3pCQJ/KxNEu UfPu3H/rtq3DnvNR7dIZNH33XWUG7V48JP+K5v3X5zxGJvRJ0P4kqGqjen/x9NHx7jca/WfStNKi Nd8WZFfvcbhsiR3HScz3ceAK7XmRflwnWennvz2+9ERWqLpHjs12kvD93QRSMZWTWZihXS5SXPm7 4IaOnvijXnQOkau647YLksS1FnhU1NzlMIdksA6DvLziTEbxiTsltwtlpXJ6DhxnMc/Xle8s4IT4 8/1YZeaN34Hf3bN044HqHv1ln3yna1s1EgNDDeJe/iv3u+yKUkX13NmyU5eeHLtVertQTl+xCIQ8 H3fhMxJeVBBfylwSlBqcr45HFfn3S775tzA9t6JYOX22m7MwyJkn9Y1JWqaKiTFZ9pxHeWX5ZcpH PVzsg5w5Lu6CKFd2cW7J9+lFFx+W5Snv6GQ5SwUtXPiBTrwWbuX/OVizF5nstxM1p1PzqRQX6GnK i52ZYcKsrdinv99KTkrSyKDLdwszsgvpDWbc0DFEf23pKQryEjErV2bQtuHPVf28jM6gqV/cUWbQ njdfyb+qmUGbTyqcXZWfKtEZVP1VtUkxC3NuXBwRIRE09nUQTS77+0rZ3TLF0+t4FovHY3u58Fo6 s4X0dBXyzKyy6/nyEjn19N5pCbdtM07hfV3lXuyszJoNPsUOb8XLvq56lB3eWujBUvdeucvRGJL+ OhqTKJffpAdToCiRKSoHwxJLuMFePA+++eP35rmxGT0yB6wxeI7BoQYL7QvKzt6reCyjVCEXHixw KKnIuF+RXaworyzi8LmB3vxAkcZkDM5X56MK+b0H5Zce0XlaORcWy8WV3943OnTakuofsYn8hVRR OaW8M4jNdnflhbpxBMonV5GfX5F+vyK3XKG6aUgg5DR357cQyc9frdmLgnqcW3M6GmeDracpMVVW ZMKsrdinv91KHjcu65Tm50Gmaxbef+v27cO7Pc2gKTtvV2bQkqEFV49r1C6rkMvkxm+Kp7NIwOWw GkmQQ1MkiAqc8mZ1BjkkhNjpjG8w6pMjN8ePG1vHDNqy/YMR0c+odukMSv38pur+oFcLrmreHwRg O0qfrPgqt/JyyaFPO5GOW0DBBJ8cuRHVo3dIgHetWzh/9c4fh78fEc24P+jzzMoMWjrssdY9igC2 Q15+Or04S3m5xO2CDKqDLd9fMl7JoPG9W6m36Qya+GnlPYp7l41ABgFAA1P+W41Pruq9TxoAoL5N 3FV5f9BLndxIjwQAmqIv/3rA6hYVeeTosbyHVXfGKDgCsmMCANvGklX9U+x7tzOTJk1HBgFAg6pl Bq3ZvqeBBmgFZo0bxNxN2/A3qZFYm9WT25MeAjR6tckgOoA03pY2TGOydABtX9Cd3HCsS25uLukh QKNndgY1qQCias5XFUDjlvxCdERWBOsgqDvzMqipBRDFmLI6gJKGdSI9KKuw7bO/kEFQd2ZkUBMM IKp61gggbcggsAhTM8hoAMXGxjJ3f/zxx3oYrXGqYViwd3ri90qCjAbQpME91Nsbdx+2VO+qZrUb ZJbr2zaxqVpDBoFFmJRBpqyAmG9+iweBif3WB1NWQBpvb3rXUm91U4LDlJyqD8ggsIj6zSDmBvMh FXVwaNfXaNZAZY3WNFrQPlzfGPQxmkFGlx4qzIRS7Wonl7mVDayDtFvT1x1z5Gat5pBBYBENkUHa 5Tq3Ka0Y0plNBto0PIzardHqkkE66zDf/DqPNaWyudv6HjLxOk4nZBBYhIUzSM30gDBl20CI1C6D KJNjqJ4yyMDbvi5ZU/cMMjoXNWQQWES9rIP0FdYug9Rql0Eah1NmxlAdM8jwNZHRy7F6zSCNvigz YwgZBBbRCDLI9DZNOZxZTd+jTHX/PMjcy6iGXAfpG7O+R5mQQWARTTSDjD6qVpefizXGDDL6qBoy CCyiQTOIqnl9pH1xpFGus77hn53p+7mYxuHaHelj4t2J+n6ipH3Vo+86yKzKZuUOpRVtOgds7i1O yCCwCItlUF005P1E5rL4HdL1fdtOg0EGgUUgg4xABumDDAKLsIoMsmb4t/IGIIOg7pBBRqgy6M9r j0kPxOpgHQQWYSSDZm1KJzc2K4J/Lq+NziDSQ4BGz0N4OW10ompbbwbh1wbSsA7S1sVfQnoI0OjN W73VeAZhCQAA9WT//3YigwCAGFMzKEhaQW6QAGCDLudyKWQQAJCCDAIAkpBBAEASMggASEIGAQBJ yCAAIAkZBAAkIYMAgCRkEACQZMkMWrN9T30PFwAal6Vpybm5uQYqWDiD6P4sNHIbN2/1VpwrsG30 i5wikkGG+wMVnCuweaoLI2SQlcK5ApvXFDMoNjZW40/9GP07q6R+fz7xc9WIaDx9lMl/9aB2zy/B V4WNQQbVyCBTyhsS8XPViNT6aaqP5xcJZTpkEDLIRuh8mlSFRv/OJfOJ1vl3vbULdR6lsaBGDJkC GaQ7a/RtNzDi56oR0ZdBFCMadD7RlJ4/yWv4haFxCW+gCzAMGaT78yCdFRoe8XPViOj8OM9wfNSi XGcGGe0CDEAGGXlVae82JOLnqhExcC2msY0MsirIIFyL2QhkUCOFDMJn0jaidhlkkc+DkEF10RQz iNLz0Y/260b9Iw9kkPXTeX+QgbWtdp26/FxMZxeIIVM00QxqLHCuGhJSgwhkkFXDuWpIyCAiyGTQ rHGD8Bs8TIRzBU0BfneHlcLv7gCbR+x3d1hm+LYOGQQ2j36R04t9qVSKDLJGyCCweSTXQeHh4adO narduOtybCOizqCGPFfa9eu7d7qOelu7a41CA5V11tfXkXYLho+tj/EYrqPdssb4DTRr7jjVddQP GT5XlOXeg431WqypZVBdWHkGaVTQeBvQ2wZa0HesiQPW7svwsfUxHn1t6jzErHmZPk51IWVaPGmU 1PHNaBXrIPUpo7TyXmeQa5xfnZVtg/Y6yLLnypSXvs5QsEjvGvPSeYjOIRkYmylH1fHY+hiPiZXN KjcrgwzHluEAUpXU+t1nLRlE6XpdatTReClbJIOtnM4MourzXBnNIAv2rn2IzneCiW8MC77nrSSD DFxPmbvKM6U7fYcYLbSddZDh6dVx1d1I6VsHqStY/FyZsg6yVO8aiWPKHNUllLGPJ8zNEX0pb8qx Fm/T6HeO2j2V+voynCbIIJPqULZ4IUZZOoOoWr3BLJVB2r0zM0j9kOEBGCg3PYMMNKhvDEYPt2yb pszF6DvfxKPUays1cxehyCC9JTbA4hmkr8TEmpbtXWNDXz6amCZ1zyATK9TutWcNGWSpQ8xachrV KDPIlKW4bah7Bpl1riyeQUZ7r+O7V9946i+ADHRqwTYpY3OpRacWPMT2M4hirA81pqouZB6rXdNm GM0gqm7nytwVU308U8xrAcOXCRrRpl1f/VAt1hQ6x6B9rPZ4jA6yFm0amIt2tTqO03A75n6v0vcN xkBONdb7g5qIhrxPurFc3lrnqJoOi59/ZJBVQwaBtUEGNS3492Jg88hkkGXGDgC2AusgACBGtd5H BgEAGcggACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQ AJCEDAIAkpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEA ScggACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCE DAIAkpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScgg ACAJGQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCEDAIA kpBBAEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScggACAJ GQQAJCGDAIAkZBAAkIQMAgCSkEEAQBIyCABIQgYBAEnIIAAgCRkEACQhgwCAJGQQAJCEDAIAkpBB AEASMggASEIGAQBJyCAAIAkZBAAkIYMAgCRkEACQhAwCAJKQQQBAEjIIAEhCBgEAScggACAJGQQA JCGDAICkumbQT4cOFT0pUJUigwDAXHXKIIVC0Svm+W++PaiOIQCA+pZz786EKTN+OPRrVQbt27e/ rLSY9KgAoEkoLy0pyMt5mkF0Ud/eMZs2vsfl8e1EEtLDAwBbRq+A6K9TZ8z+5vtD9EZVBtHo1RD9 dcXieXQSCQRCgkMEABuWOnMO/ZVeAal2n2aQSnTXZwkMCgCajCNHjzF3/x9zfvxFCmVuZHN0cmVh bQplbmRvYmoKNDUgMCBvYmoKPDwvU3VidHlwZS9JbWFnZQovSW1hZ2VNYXNrIHRydWUKL1dpZHRo IDM4NQovSGVpZ2h0IDE5NwovQml0c1BlckNvbXBvbmVudCAxCi9GaWx0ZXIvQ0NJVFRGYXhEZWNv ZGUKL0RlY29kZVBhcm1zPDwvSyAtMQovQ29sdW1ucyAzODU+Pi9MZW5ndGggNjM+PnN0cmVhbQo4 BmBPCDp0/T//////////////////////////////////////////////////////////////a9q1 DCgAgAgKZW5kc3RyZWFtCmVuZG9iago0NCAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggNDg4Ci9IZWlnaHQgMTg5Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0NvbHVtbnMg NDg4Ci9Db2xvcnMgMz4+L0xlbmd0aCA4MTQ5Pj5zdHJlYW0KeJzt3QlcFHX/B/DZe4FdTrkUQgER L7wQCZVUQgHNTFMz9fEET7yvf2pq5l1mqXlWT6emz2NmpZWZZZmmpuajpuKBF+LJodzs7n+WhXWY nZmdXRZ2Bz7vXi+c/c3Mb76/Yfezs8PMJtLpdATFiKS2BAAAOJKP9p6kPhQZgzv1pfZPijRLZ4x0 cVKIJDJ71AYAAJXoNCV5BUWvvfWhSiFZ+9VxQ2N5cJMH2gtSB7urnbWFuZqCHG1hjl1LBQAAPZFU IZIqJU5u2XeuLN52wnDorQ9uMrXfnjNKU5ijLcgmU9vedQIA1B6bvztTxR5SekaQP6Vq34yb197d c47Mbn1wD3y+9fp5I0sepSO1AQBsaMu+s91792/TLMTqHk6dv/Ljnp3JiS3I6YLi0nmf//3lT6dF XduHb1+WoinILn6YbrNiAQCAILZ+f37WrJkF6Ues7sGp4bMrV64andCMKAturZaY+MFJfXBvWzKq MPMfbUmh7aoFcARSachI3+jn5Apy+p+7O/a5DZimJCc+ezO/2N6lVTd5O/8hdWawDuyDHy/MmD4t 78rvVvfgEtLprbdXj+oebniYX1Sa+tEZUdtmwd+uTsm7cZK29NpfcsQKJ7OdqjUPB8f4ScQiq8sC LvLIBsNmGn8NuuJHJQ8v5KXty067pNGWN4pcIj1j/+UW4CvWL1GoeXQo85sPCkrY2mVSv46u4Z1V DZrInWUEodXmpuWlff3o75MlGh331iucv/Pxorxi1mV0hbcL0nY9OHG4uLS8Q5G6nUf7vq7PhErJ DZY8KLzxc9bxPXmPS6yq37jFsjIIyrRpPEnDfQYtclXe3D3yxbVnC3Sqnl/+/JY3cWx+twmtBg3o mcy+Iu/fCON47UBush/KW8oG2y+4tdxupdVxH+6/NG3qlMeXfqE2nk1/+L/0h+TEoC5hxsZtv1wi f7Zs6NWioRd1YXVYl9XvrBkZX74kGdwjNpzWB/eeVaOfXD9B296Ugx538s3/tj2yjq0ZEKCUS6wZ E5gljwocNduZfPnFDfujSO31TOvYV6aN6R1OXPvk8oE94hIdIfZxf3G9r1/2meWDF3z7QBHWtfeg thc2rO3QLSLyZab27omd+3TPP73v4P7DP52+e0cZHjdh9fSkBvnHF5499j83McvWuw07/IQ6w2Xs 4KBWctNlxHLP8Lgp789M8M3/c96p4//UkxAi1/gGA8a6EH8fXjlvw0+ZuhZDZ66a1Fp37ORnq1xK tRbX38Uv1MW4xfEtB/TvNbZi+sWKkhjqH3GnnjpISYi02rOXHt8jpC1b9160eYk724p8fiMs47UP OWWfGIdT8HDR9ruZ5GDDPPt0qFdfaqfa6raPDqRNnTwp58IBauOXh67M//QYObF4aNTA2BDGFiO3 8Lh33n1vRFxjw0MyuEdvOasP7t0rRjxJP07b3mHlCz26dxeJ9UT6fyomK/+7bM7Yfo2yENzVRd4h KOW1shfkqFx/F2+RrqhU4dp/28x+DR58nXL0yt0QVbvA0a+rxBfX9el/TKwMdRaVFJfceqT1aZYw Z81yD9P2Rh69wiRf//xIo5aq5WKZiNCqevxrw6JGxb/MH/p6XIyHr4Rl6/VdvCvFujymrYe/lGEZ nVvvYWtfe6bowNwhi57vFBjaa2tgiDztzbhx3z1qHKCs7yRRtF83PbVd0cFJH/6WHucXaXH97eLb ja3YYugLCzcv9SjfuseLkWUlVSre6NSRjXtbjZ3rTJz8z9Tt7d9ZGUSZdWbDQplGLH1moF/HJJWX q4goLrlzOOuv7VnpmVqiMu7xxiV00Nd27eHxDFWrjgrZ2Vtb5j4u9VK1H+sT0V6hEBFFt56c+Sjz xIkSjbGrqw/+SHOO6OaskhGF6bknN2eeOlf+4Ufs4dI22adVtNJJQhTdeHz6g8y/TpNvdhUrVmyF /q5TNhyJYZmT/xk7/kK+PCYyODSKqSuC36jBWv/++crk1AlZ536kNu48nL5w2ynD9MJBbfQ/KQ/7 d2xIXdijefd3164f3q08zcngTvnwgj64dy371+Nrx2jb+1PVl09wL52V0ifoAYK7uiiiG42d71Ie E+692qg9SkruEn2j5ozzzto5fdS7SV1j2o5e6UF+dC+5nfbX0fxHF6RX/ziX9rhQHhH/xjp/03ZC FBiguHuz4H6BTu2pCPJQeIXNbNq3q+z+5+NfXu4S4TcoVC5n2foLbV39TH/P9GXUPqruQSlT3IoO zEqYQrSNn71ktZfywnsvvvwr4dzaQx4e7BLomRQycbJ3zq5pg1fEdIuNG7fKsvrDno+aULHF0F4L Ny/zYKtQ3FqeuiTM+IlBlbj959U++odjm/VMbDedMotwSh78fMKYlR7Kh38uHrLkpxyPFt37D2lV tG9DsKdMJuI93vZ9569cpCaI+9/M2fXDwUOncu+Uus96d2dCdMCTn1JnrzyjGvXZioGB975NuZx2 29XJ0BWRd3jl7t3fHb7s13TG1tSOLrd2jcq4cc9ZJFd2WBMaHVT057z5Cw8W9vvgvdHhd74eff3a HZWyfMWnW1HErf55XWvqcIa+1DvVUOfYZklB7TuxdCVv3mAkj1GDtT755Vrq+LEPzuyjte86enPx zrO0xvn9W/SNDqQ11otIXPv+xn91aWR4mF+kGfdxmj64//vm4Nyrf9KWPu42ICExoTyfjXFNTfGy iSUzk3sHZCplCO7qoXg2eOJCVXlMuPWMcNEHkzI2aMJcN+2RuQljRc18X3l2MNH51Rb1jTe7Pr73 /dTMcxmygIEahvablN5FYs+4gIEz3Z2zD83ts/hgVptQ1+4tnH0ktK3TnElfNzO3iLFC9xeiI5rE LQpsWi/vx3FDFvzeqFXSvPdXeIpPLHx+WKa3unWIa4yHiFB2bjRhnlpzeG7C+JLGPoNjh0hiLamf usXQXgs2L/Ok7R8jWZTPpMV+xqNjVezQjeSBtmHFpNmbV9SnfphQPpuy/h0fyZktE2adfJjlJyeK Ckvu5Ogioup18RBLRDzH22v+RvKNRP9GtS9fGdNAKpG2TFi9pa3rpfUv9f2+UBnZbHDK21P9s3bM nrjuhehurVPJrq59OODF7Q+kMUEKRb2hI1eN933w+Zzpm/q0bds4eY2Xc/qHA3rvzJZFhvVJWTc/ 8OG2OVM29I7qFqFfkbIVZexg49AMw3HuOn5jxZ5pGDNj7aZAF6au2ndsPm6Zm9lRg7U+/fX6hHHJ 9059azpr9/GMpV9dND587aUmfdrXN13Mp02v9Ru2DH2u/CMiGdwTPr+mD+4v5vfLTjtMW/ps/ZGJ iYkViV0e3aKy/6gtb0wb0aNeulImNtkc2IKic9NZy13LX5Cq+FCxt4QQeQ1tOX6sU9bO1D5vSIJU ScGiGxeLfysNCXx24MjUvsFk0D3es3LG0o71xf9cYGoPkOhPJ4jUqshZoQndFETOubcHz9hx1d1f 1cxTGh0kchWbbp12jls2NEHdTEZdhqLg+o2fNix4e0+G1Dk6uH3ymg0BzmTEDLysco4NEQfKCJF7 v+ap01xydk3uvUAUpEpsJLp5yZL6Q7q0NO6T0KTXN6/wqrx/WPdei+di53Cs6OQSvaxhfHvDG1Xx vSMZ+5b9fvR+AUEE+Ik96fuEZbyhcZM2Grodcd9XFeIlaRfQKXL2SlfRiQVxwzN9VGFB3YYvX+pF vun2GCtumzhzBdnViUXPD7vppQ7xELcN6tbu/96sV/aWLG/bY8qylW606NQdnddjjKRt4vTlhoEY txIbOafy88SZMvbQhPmbVtVj7KqZd7+ey4LNjhqste2PjOQxY28e+9p01r7Td9/de8X4cHJSSGJr X9PFAqNe3LJp46CY8kwvKNZM33VfH9zbXieD+w/a0v/zH5GUmCSSlCe1SYKXH3G/MXVED28Ed7VR dA6fucz4guzeWOItcVF3/7hplN/DHYOGvnO+eYhzl8YSt2LtpfvajCelOV4jpqyd0KDk0P8lTHSK cO3irL3M1N6jUXRg79frN3TVZnzzwdwlX57L9fJTNXeX+PtLItSEiHnrtHPcojYhEn1KPl2GEu5S ibebPNhL7ubu3nv8V82ayU8vit98oSCpqcRHLJZHvNeqd+vCg+NemftH4xDnrqEW1h/Vc8qyZYz5 W7Z/2Pdeiy6d53CuqNEeOe90XhUS1GFIakqs+vE3Hy9c1sRDXGnc3OP1e27cWyvcKrqNDZEEOrds NHGDt8vF9S8NuOTiHBs5KHHKJOesHRP7LJY2TXp94wpP/RF339MyZUyIJMR/WItxyU4PvpjQd5ms SfSMd7YEqC6u69NvV4aGUoE0om3Sgo0rPKhbUZk8T5wpLQ2jp723JYixq3B1z2Di/D/mRg3W+uIw Gdxjbh3bTWvfe/oeNbUNyOxOau1DawyI6rNl06ZXOz4N7mn/vacP7u0L+jMF9/CkpKSneS2mJXj5 v2VH3NcR3NVF0Sl8xlK1/qqSUY8DfV94tk1oVMozbRprL62dNGbDVblLdEjH5JlJuv99l3XtQl6u qLDR5MghicrT8wfPvD9tzUuel/cWpldun7C/zbDXxo/qrZZkXPjwtXlb/8yWyML8nPydRN6+stY+ nZvPJDd3Ku2tydlFlK0b4iBMpj+LUt7IuAwl3EWEp7u0WT2xyuPFesnTG2qOfrF8ubO8MDj45YYv j3bVHVnz6pi92fKYJp1SLKp//Nf+EYnz9Xlnkr/l0xWFESb1t+waO7viYXDXOe+/5y9P2zTglfNy uX5ozu2CEts9/GX3r6cyH/iNGvPmCG/yM81LbwZFucW6Ud/MOMfbILbdLNoeU6riPmka7ZexPeXd H+70HbuxQ4cGdz5+eeTGtJYtE2brCybyDi979+MfWjUJa9F7dVBjl6vvvzDus5utQtx6Ddva+fmw 7B/nr9v5i1Ts6d20a5suwRc3LL0qem7cRsq7DrkVp8jQyas9Kg2HWqdHv+FsXUUNnRiV/6u5UYO1 vjh8Ozkl5dbxSsG999S9NRWpPSVJ/1dH6sOkNpWyO6B9ny2bN7/asYHhYT4Z3P/JLAvuhQNyLpsE t1/l4C4/2f30XInhyHvR1OEJPjcQ3NVF0anJtCXqike64kcFmWcu/fjx8o+OPpQp2wQofPxbDhoz y9k3yENd9jdFzaPcv7etmLvhqLb1vJULWgUHedLaRd237l3diGFLpy+vnpxNGDZHvtqTQ7u4N1cZ H5IvfnWP8PLgNr8MlU6Uld8uu+vwLh1beisJouR+7rmvPnnz/a9uaZo0dAn0bzl0wiwX/vXny2Oa xk/lCu6KwmTUUstqa9W188yKhw18Bwxf3qJrZNkVkCf/WjVVV6pUhvTXtundvDE5Ak3RrUM7ls77 +PSTNo1V8WFSyqkSzvEyzpU0eBA+uVV8B/3fWotuZuxbOW3VT09cVVGN4lLfX+5B/PPJ2nORr/Zp 5iUlCq5e3rl4Fjl6T3VbX1lMiPsT39GhPRNa6NfMK7x+6OoPW7787lp4x6Res2hbcXaJXlz/Ocpw JLRKPIr9mLqK9GnZhMeowVqf/34rJTnlduXg/u7UvXfKknpqUkjPspg2bTFq0L7P5i2bB3cKMDwk g3vqjjv64N6xaGDOZfodmWd8hyX1TDI9u10+UfF40dQRiT7X8cfJalSU/9Z3uZkVjyRSsdpJ4q6S B7hKlc6y6CCpu6boi98eX3yiyTPcACIWu6vlwd4KDxXxMD0vzbTdRXf579zrDFuSD3/Bs4XWsDlp yzB1QlOFb2nlhxJqSZzLUGhLSk+lFRy7XXgrT1OkJccg8VTJAuvJPRWSFsHyIFGxZfW7yrv4Fa3f W7HFYM2n3zNNGyrhKDVMeumvrO8zS4t0FWMXa05cfHLkZtGtPK2GDGGlLMBH+YxaFhMm96AefBZx jpdhri7nXuG3/+RdyCot0A9f7O2pDPOUeQTGJS81ZOvIDGfJo+zinGL9XF8v5zBPiZePIqaeuCCr 8IcL+ecfFGfrb1cSeXooGnnJQ91ljbxL/r2v8lY0mt+OVR5O5V+lKpelK39xehqPUYNVPvv9Zkpy Mi24L93JS8vMIyeoGU1mN/mzsZ9LmL8LdeGy4N4ypFP51SZkcE/+8rY+uHe+8UrOFXpwbzyu86yn P1NOBnfFT8MkQW18eP380Ci1Akfc1Uer+fty8Z1i3dNzkyKRTCb295I19hQryd+DTpueUXwtR1uo JZ7eTamWNq8vybvH1O4vzkiv3OFT4sgmssxrhrniyKZKX5Fx62UPJbSS2JehDaJEe4MsJldXqNGV FSNSqaXh/jJfueX1N5B5iylbpBZMK17CWWq40jm3+PTd0scawvDOEBmucC0sTbtXmlmgKylrksil oQ3koS60wXCOl3GuTnv3fsnFR+SbUNlYRCKvevJWgbERUxZXXKDiEqwk8ksI/RXcYrFPPVmEt0Sh /+XqcnJKL9wrzSrRGS7uViglDX3kjVy0Z69U3oqOeJxVeTi0vSFm6UpFFOfzGDVY5bPfbqaMHp1x gn6Om7/6kX02b906pPPT4J607VZZcC8elHvlKG3p4lKtRmv+Fl4ywBVSiQjvzACWUsSETnqjIrhd k1o4Mb7ngaB9eujGmNGjqhjcm7Z+MDT2GcNDMrhTv7hhuI771dwr9Ou4AaDaFT1Z/nVW2dkM154t XRjubwKB+/TQ9ZiuPVqENLC6h7NXbv9x8IehsZTruL9ILwvuJYMfm9yAAwDVTlty8kJBhv5shrQD gruW2vTDRfMLcRrTo4lxmgzu8Z+V3YCza+lQBDcAgOPT3/L+6RXWOycBAMABjd9edh33S+287V0J AADw8tVf90WdY6IPHT6S/aD8QmGdRGHfmgAAgEakKf9et7u30pMnTEVwAwA4OiuDe+a6v2uoQAew amIr6sO3tu60VyWOZsbo/vYuAaAusia4ydTeOr9LjZVoX6MX/0INbjK1kVYAYF8WB7chtck4q8kq 7csY3EhtKuwNAHuxLLiNqZ08uF1NV2oPWz7/i6gIbuQUDXYIgL1YENx1LbUJSnAjpExhnwDYC9/g NpvaEwZ0pT5cv+NgtdXMxVCGrbZuCG5f5SWzCRUfH2+c3r9/v022buzWtENqO9s0z66shuAGsBde wc3nWJuamLZNT27Vui3qqRIOtEwkH9oqH/mkLZ9wrw4IbgB7qd7gpk5QZxkY09Z0eVq3HAvTeqP1 YLo6Ww2M+AS32YNcA2qsGx6axr2lC3MccZv2xrY5auUWfW5AcAPYS00Et2k74zRhkt2Mgc7RJ3cZ VnwaqGJwMy5DTUzGdfksbOk02yyep1kYIbgB7MXGwW3EP1X5THMkr3XBTfDL7uoLbo6srEpAVz24 zY7FCMENYC/VcsTN1mhdcBtZF9y01QlLsrvqwc19ysLs2ZJqDW7atggLsxvBDWAvAghu/n3yWZ26 GNtcI5uc47b0LEdNHnGz1cw2lwrBDWAvdTS4zc41qOJVJUIMbrNzjRDcAPZSo8FNVD59YXrugtbO uDz3lSdsV5XQVjfdECOewU2wX49helKC7TSFRQtbFNaEyfsBY8GWXoqO4AawF5sFd1XU5HXfFuEf 3PxV9+XVNQbBDWAvCG4uCG4OCG4Ae7EsuO1VpX3ZNrhrDQQ3gL1YENx/Xn1stzLthzzoRnAzQnAD 2IuZ4J6x4YJx0brzpYBUhrMlAAAOwld5aeaI3oZp1uA2/s9u6uYRd4dgtb1LAAB4au6qzeaDu24e aAMAOKY9/92G4AYAEBK+wR3mUWq/IgEAQO9SlpRAcAMACAiCGwBAYBDcAAACg+AGABAYBDcAgMAg uAEABAbBDQAgMAhuAACBQXADAAiMLYP72PWC6i4XAKAuiApy4phr4+Dm3hgAAJhlNksR3AAAjgXB DQAgMAhuAACBQXADAAgMghsAQGAQ3AAAAoPgBgAQGAQ3AIDAILgBAAQGwQ0AIDAIbgAAgUFwAwAI DIIbAEBgENwAAAKD4AYAEBgENwCAwDh0cMfHx+/fv5+7BaqC3J+0Furupc41tjM2crRbuiGe3fKv zdBoeEidZiyPnMW2DIDjcPTgJkxernhF2RBtD3NknGHPMzYSlX8vjMHHnYZs2+Uzzac2thXN1oYQ B8ckgOAm2F+NpnMJykETwXIAZdotbVbdeaGy7Ry2A08++8dWwW2r2riD2/Rg3/RZRJg8x2iNADXM 0YOb9iplPHlCVH5ZEpzZXfVgqk3MhiPjXIJzF9VYcPOszdIjbu5De+6xA9SMWhjcPKfxIiQ4g5tg Obo0e8jJeDqL4yw221xb1Wbz4GYbOECNEUBwE5XTluNVyj+4aSvWWdzhSG3h00iw/xGC/xG3zWuz YXBzDBygJgkjuAn2V2MV/65Vx/EJR/6NbKnN1oMV/VtRm22Dm0B2gwMQTHATPM54VD2461qsc2eW aTtjo/GhRSeX+fxSOH6J/Guz6GljRWEANU9IwU0wvWKNeIY4bUU+h2+1GG0fEiynBQhze4+xn6oH N9vmrKjNuuCm9rmf5ToTgJrn0MENAACmENwAAAKD4AYAEBgENwCAwCC4AQAEBsENACAwjhvcpleY GeAyLACo4xw3uI3q2rXVAADchBfcbDfsMd5bQV2FwC1wAFAr1LbgJtjvi+P/TRcAAI5MeMFNVM5i 676eAgBAuOpKcBshuAFA6OpKcCOvAaDWEGRwMzbie1wBoI6obcFtZPYrQDk6BwBwZAIIbkY8//co AAC1jyCDGxf2AUBdJsjgBgCoyxDcAAACg+AGABAYBDcAgMA4dHDXwN8b8SdNA+qtTADg4OpccCOp GSG4AQREkMHNdkMNrd10MbYW2n3ztJ7Nfk2V0N8MkNoAwiK84Lbi1naOxfj0xvaFsdx1CgiCG0BY ENx8g7sWf2UVghtAWGp5cPM8N1KXgxupDSA4tTm4Gc9NI7hpENwAgoPgtkFwCzrNEdwAgiOA4KZi uzjEdHmO//0Nxx8bua8qIRDcAOAAHDq4obohtQGECMFdpyG4AYQIwQ0AIDAIbgAAgUFwAwAIDIIb AEBgHDq4zV6cBzbBsZ9pjdRZbL8Cxgvqrbh9ibZWFcvjfwmp2f45tmJD+LsxcHDc4Da9whrP4+pg xV1OBjyDm/qL4x923FlvaXkcy1t0KxbHMM0Oh//C1LXwnAdGggluxnbG+2uo7bXvK1hti/9OZstB 7j5p0cN4LytHD7Yqz9Igtmh57vty9zN9vTDB8hSlLYnnKrBx9OAmLPkgTHvx1L67HG2O+52vKsFN 65A2y6JQrnp51RfctLGwfdpg+6KF2n1TLlQfxw1ugvc5bj6vCmBk3dezVDG4qx6g1RTcPN8YeNbJ cY6II7jNjgWAcPDgNqA9odleA6bLU9cCRtUX3IxvnPYKbsLcs4LtlE5V6jQb3KbFmGY3ghsYCSC4 Cc4XkqWxAlTVGtymS9oxuDnmxpv8DbDGjrjZyjO7dajjHDe4+Xx0teK0IF4JVDWQjNadO66m4OaT 2lWsk09JVr/zARg4bnATPM5xm/3ISVgY63UQ277i2PlU3IlGa+F5FovtV2x1eXw64eiK+9CYrVu2 czVsJbG14LkKphw6uKHOYjwQFgpbBa6gdwJUKwQ3OCiBxhZSG2oAghsAQGAQ3AAAAoPgBgAQGAQ3 AIDAOHRwW3GZNncnbDewMd7mZ2lhQmTd5X2m69pkV5i9iJN7W3wuuOa/IvcWufcb/2ppyzB2y33h IFsN3JXYqh3sRQDBTXDeE8yzEytez1b0KThWD8T0LbCKe8O6+wypCxhYFDfcK3Lf5FWVO7zY9h6f O3csuhPKotugrLvdCexC8MHN894K2tPOdC7HwTh3n7S5wnpOc3+miad8Kyn/wbL9jvh/rLEuKXi+ Q/O505KxAFojzzszLVqGT22Wbo5jRFWcBjty9ODeT/nOB9McseFTkM9rlW1d0x6Egv89ftzLmHZo urtM2/lUxf1maXYspu38g5u2UT5V8anWiuC2oiuOJa2b5h4U1DBhBDfBcgDoUMEtRGYTyvQh47rc B9eW7jo+n/HZxmI2uHmuyPZJjnt1PtXy+bBC3S5HJRYFt9ldavbVwVgD2AWCm/XZbFTrg5s7DvjE JWG7XRdv+TesctdpRXDT3n74r26T4ObOdO7PCmwV8tmlZqf57A2oGQIIbqJ6ztDxOeKmFcO9gBBV PbgJm+66eKu+YZW7zqoEt6WrV19wm62Tozyeu9SKVw3YSy0PbsbjwSoGN9txhxCf01YHt0VnM3i+ 8k0jhv+6HHPNDodncNMaLTrzYLYktlXYNsQ9ZMbVuUdnxTTYkTCCm9ZI8Dj7xvZ6Y5zm2S1jn2yF CUJVjri59zy1ndrC2JXpMqYFWLEuY7vpc4DnRtmeIYx7j6NajsU4CubYFvc7Ga037iItbQd7cejg htpBiG9pAI4MwQ3VDsENYFsIbgAAgUFwAwAIDIIbAEBgENwAAAKD4AYAEBgENwCAwCC4AQAEBsEN ACAwCG4AAIFBcAMACAyCGwBAYBDcAAACg+AGABAYBDcAgMAguAEABKamg9tGZQMA1Gk1F9wAAFAD ENwAAAKD4AYAEBgENwCAwCC4AQAEBsENACAwCG4AAIFBcAMACAyCGwBAYBDcAAACg+AGABAYBDcA gMAguAEABAbBDQAgMAhuAACBQXADAAgMghsAQGAQ3AAAAoPgBgAQGAQ3AIDAcAX3TwcO5D/JNbQi uAEAHARrcOt0uu5xz3373T5jdgMAgAN6ePf2uEnTfjzwa3lw7969p7iowN5VAQAAs5Kiwtzsh0+D m2zq1SNuw/r3pDK5k4va3uUBAEAl5LE2+XPytFnf/nCAnCgPbhJ53E3+XL5oLhnfCoXSjiUCAABV 6vTZ5E/yWNvw8GlwG8R2fNYORQEAALtDh49QH/4/mybw4wplbmRzdHJlYW0KZW5kb2JqCjQzIDAg b2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0ltYWdlTWFzayB0cnVlCi9XaWR0aCA0ODgKL0hlaWdodCAx ODkKL0JpdHNQZXJDb21wb25lbnQgMQovRmlsdGVyL0NDSVRURmF4RGVjb2RlCi9EZWNvZGVQYXJt czw8L0sgLTEKL0NvbHVtbnMgNDg4Pj4vTGVuZ3RoIDYxPj5zdHJlYW0KOAag0Qg6dP0///////// //////////////////////////////////////////////////9r2rUMKACACAplbmRzdHJlYW0K ZW5kb2JqCjQyIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9X aWR0aCA2MTMKL0hlaWdodCA0MjAKL0JpdHNQZXJDb21wb25lbnQgOAovRmlsdGVyL0ZsYXRlRGVj b2RlCi9EZWNvZGVQYXJtczw8L1ByZWRpY3RvciAxNQovQ29sdW1ucyA2MTMKL0NvbG9ycyAzPj4v TGVuZ3RoIDE5NzU1Pj5zdHJlYW0KeJztnXd8FFX3/1cIhhIg0luo0kFAeuhdpJcAAkqv0kKXXhUC JBBalA4PCIhI7x0BAYWASGiCoZeg9JKQfH/nxTzOb5/dyU7Yudm9c/bz/mNfs3fK3nPuZ85n7rZ5 7//+7/8sAAAArHjvvffc3QXTw89c3qOQoAzj8FNGQoByjOOZypEcCFsUzOQNWQiDmTJ0QU0Rhacp R34UbWNcjMAyh/8tecyicjEslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsB sFSGLp4ZtViQQznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5 hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJyYa F2m7Km3HjAC/FABLZejimVGLBTmUE5eNS4YMGR4+fHj37t3MmTNbt1NL1qxZ06dPHxUV5fgI0kpI 2o4ZQaRf5suX7+rVq8ePHy9XrpzSQssVKlTImzfvn3/+qbQ8ffp03Lhx69atI0FkyZIlICCAnvr4 +Fgfp1evXmFhYfQ4b948471yASyVoYuRqI1L5ezZs5MnTz548CCVG1pbq1atbt26VapUSURkrsMz lSM/LhsXUuzRo0dJxlWrVrVup5bq1avT2p9//tnxEaSVkLQdM4JIv+zZs+e33347adKkkSNHKi20 PHr0aGqfP38+PY2LiyMRHD582HovEsr+/fuTJEmitijFlB6vXLlivFcugKUydDEStUGpUHvdunVf vXplc1jTDYFnKkd+XDYunTt3XrJkCZ0L3bt3t26nFjoXaO2iRYscH0FaCUnbMSOI9Msff/yxZcuW 1apVO3DggNJCy4cOHaL25s2b09M1a9a0adMma9asP/zwQ5kyZU6ePEnb37t3j9pbtWql7ELTiw8/ /FBZJtfMkyeP8Y4lNiyVoYuRqA1KpXz58idOnKhfv35QUFChQoUeP35Ml+Fz5szZvXu3uPhcgWcq R35cNi5Tp04dPnz4wIEDZ8yYYd1OLSEhIbR26NCh9PT169e0wcqVK6k8pkyZsk6dOt98803evHnV rj579qxHjx4//fSTt7d37dq16bzInTt3YnfeMSy1LdIv//nnnwwZMnh5ef3999+pUqWiIUyXLh1N FKKionx9fWmDgICAdevWWV9M0WSid+/eVAqpLFq3qMt0kfX/+/p2AJ4/f96rVy86jqKMadOm5cqV S3etwurVq5ctW3bmzBnqEk1TcubMSWW6U6dO/v7+RgJnqQxdjERtUCo0uNHR0Q8fPqS9HPTNgRiO HDmyYMGCffv23b17N23atJUrV6aZLhmzeoSYmJjZs2evWrXq4sWLsbGx5NBUwho1aqSsdVC/3gnP VI78uGxcNmzY0KxZswYNGmzZsqV///6hoaH9+vWbNWvWp59+un37dlrbpEkTkmLdunXVK0uFzJkz nzp1Klu2bEpXW7duTZeS6lq60AwPD8+UKVNi998BLLUt+Ps+yoX/1q1babzpsWHDhtTyyy+/KGtp 4kj15dKlS/nz51daqBjR/IDaL1++rLSQekgltNfx48dpef369f+/r28HgKYdZHtqY/bs2UkZVHwd r6VlulKjiqnZbYPhs1SGLgajNiIVutC5ceMGORyVmIwZM8bXNwdisL+5Cnnqzp076fqJlsmMP/nk k/3799tsowTruH69UxI8Uzny47JxiYiIKFKkiPLZU9myZc+dO1esWLGTJ08qn0nRWtL89OnThwwZ Urp06bCwsJIlS96+fTswMJAKo/LhhdJVOsiKFSuKFy/+xx9/tG/fnh5pm+Dg4MTuvwNYaluwX44e PXrSpEkDBgwICQmhR7pQopYJEyYoa2km8eItKVKkUFpoOdVbaIZBT9+8eUPl7PHjx4cOHapatSpd +NMcImnSpP/tazzKGDx4MBmh47W0KnXq1PQqkydPpnaqazRpuH79OlW9JUuWHD161EjULJWhi8Go jUiFpobKvJP6UKBAATJamneS46ouqCuGGjVq9OjRg9yRrsHv3Lkzfvz4hQsXqu8PBwUFDRs27IMP PqDrfbr2pxelQjZlypS1a9fSWsf1y5U5BImEy8aFrsxSpkxJC1FRUXTl16tXL5LQ/fv3qQwmSZKE NJ8sWTLS2JkzZ6yvHWkDuj7LnTv3tWvXlK7StV316tWVtcp3hei8oEvMxO6/A1hqW7Bfks9R0Sla tCjVF3o8f/48tVSpUkVZS84XFxdHRqV+u4eeUiM9pUZ6Sr5VqVKlggULXrhwgR5JItRSsWLF//Y1 HmXQJRhdiDleS0/z5s1L8qpcubKfn1+OHDmyZs1KlZTqpurHTsNSGboYjNqgVPbs2UNGS8P98uVL ZQO6wNq4caPydq6uGGx4+vRpmjRpaN9//vmHnioVyvpjdWsc1693SoJnKkd+XDkupCKaXM6bN69v 376RkZG5cuWia8c+ffpQO2mMNiBDVUVujZeXV0xMjNJV2iB58uRK+6tXr+gq09vb2/4Lca6EpbYF +yWNX7p06WgGcPLkybJly/r4+Pz99990iaSs1Z1fjhs3jq70STd0XU+Pc+bMoZaxY8f+t6/xKIOe UqPjtZa3H1l17NjR5ju3VKm3b99ODmokapbK0MVg1Aaloh6E/O/w4cPBwcFXr17t2rUrTT0telKx vP0ke9GiRWR79KKKAROqGdOWtD2ZqM0vnRQc1693SoJnKkd+XDkuDRs23Lp1a5kyZehFT5w4QecC ve5vv/1G7Zs3b7bErzelh7pSdxcstS3+/wqU4a9Zs+a+ffvUIVew/1CKlmkeqX5+6e/vf+zYMeuj UQv53H/76vBKKiHXWRQmlcizZ8/SPCA8PHzXrl1UhW066QQslaGL8aiNSMUG5QdIGTJkePDggUVP KhMnThwzZoxml5RwFL8kYyZ7tt/Gcf1KePgWT1WO/LhyXAYNGqR80Kh8WECPyndlqX369Om0UKpU qfPnz0dFRaVOnTq+rlq/laK8cxPfWykug6W2xfslTQ379++vLtM0UV3VsmXLH3/8kWYANA9QWpT/ JVC+9Pj48eP06dOrF/sKdM1OQkmbNq0lfmUo79Q7XqvZVaXIUvl7/vy5kZBZKkMX41E7LRX7Qykf /9D0NDo62qInFdqStp8zZ07z5s0zZcqUNGlSmmWS9tRwHL8f67h+vROeqRz5ceW4fPfddz169KAF ul5UrhobN26stHfr1o0WQkJCBg4cSOodP3586dKl6RLwxo0bdIm5cOFCml3YfFRPHtm+ffvff/9d tVt3wVLb4v1S+caXukyXOeqq77//vm3bttmyZbP+Ud3du3eVwrR+/foWLVpUrVr14MGDyvbKb/Ko vVmzZha7L3GoylC+M+J4La0iqdGr02yGiiZp7ubNm3PnzqULOjLjR48eGQmZpTJ0MR6101IpX758 586da9Soofw+hLxt+PDh5I7FihWjEbfoScXHx4eukOhQDRo0IIs9d+7cyJEjd+zYoYZj/X0fKmE0 yySDnDp16qpVqyx69cvFOQSJgSvHRflkPUmSJA8fPvT19aVaRJducXFx6p/+vHnzpkmTJtu2bbPf V30/1v73JHRSaH513GWw1Hai/H9sjhw5bt26RY9UR6zbSQSkAPX9VQX1T1t0//NFGYCAgADrGUaW LFnCw8MzZ87seK26uz3WH5E6B0tl6CIkauekojmUNE1ct25d06ZNLXpSUf5UxXpfmubOmjVLDYcm qfXq1bP5xYi61nH9SnjsFk9Vjvy4clyUv4otWbLk6dOnlZZSpUqRUK3/VDY2NnbBggV08UfXdi9f vvTz86Pr/i5dulSoUEHp6tOnT2kyunHjRm9v7zp16uD/ChKJRPHLTp06LV26lB4XL15ss+rJkyfk T1TF7t27R2qguQI9Vd7X0v1PUWUA6AikjE2bNpEyatWqRcqw/p+L+NYSp06dovnB3r17L126RAUx Q4YMH3/8cdeuXZXJqxFYKkMXIVE7JxUSxrJly8jPrl27RqUkU6ZM/v7+gYGBNl+ljk8Mr169ouuw 1atX37lzh0oVaWDUqFFeXl7W4Sj/V7By5coLFy5QY9myZQcPHqz+X4GD+vVO4XumcuQH42IcljlM FL9MJBwPgBuHh6UydJE5apn7Zo1Z+ulpYFyMwzKH8EsBsFSGLjJHLXPfrDFLPz0NjItxWOYQfikA lsrQReaoZe6bNWbpp6eBcTEOyxzCLwXAUhm6yBy1zH2zxiz99DQwLsZhmUMz+aW0sFSGLp4ZtViQ QznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHM qMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyV oYtUUdv8o6wkvdJFqhwCFSPjYi3FpEmTpkuXrkyZMn369Pn000+F9c8MsNQ2/FIALJWhyztFHd+f 3Sf8CO90fLOMhWcqR35E+aU18+fP79mzp6FumQqW2oZfCoClMnSRyi9tXsgsY2Gu3noOxv1S2Tcu Lu7+/fthYWHjx4/38/O7fv262H7KDEttwy8FwFIZujjhly5IkbnGwly99RxE+aXCq1evUqRI4e3t TQv2m40bN2727NlJkiQZOXLkgAEDqPHmzZtjxozZsWNHVFRUhgwZPvnkk4kTJ2bPnp1W5cyZ88aN G2fPni1evLj1i1JLiRIlFEtevXr1smXLzpw5Q7vTYWmXatWqderUyd/fX9n49evXM2bMWLly5Z9/ /pkyZco6dep888036n2cHPfNSB4YAL8UAEtl6CLWLzt27EgneZEiRU6ePEnn8IsXL8qWLXv+/Hlq X7JkibL78+fPe/XqtW7dOio9tWvXnjZtmnK/6IS8kIMaZL+vfZnQLTGOd3c6LcAtCJxf3r17NyQk ZPr06aSZXbt22WxGOunbt6/aSHvRfPTjjz++deuW9TFJqKdOncqUKVPbtm2///77efPm0YlgvQG1 fPnll5999lmOHDnovNDsmNKlmJiYunXr2tzbNXPmzHT8bNmyOe6b03lgA/xSACyVoYtYv1QNskOH DkuXLqXH5cuXFy1a9MSJE+RPyu5t2rSha2d1Fyoi4eHhZH66L+S4Btnsa18mElJiHOxuJC3ALYj9 /DJ16tQNGjQIDg7OmjWrzWak8BEjRjRp0uTp06d0ATd37tzAwMCZM2dS+4oVK+jxjz/+aNeuXURE BLXTERRfJNekSzfrl1B8lHYfNmzYs2fPJk+e3L59exJnbGwszThJunTRefToUdqSnHvIkCGlS5cO CwsrWbLk7du36cjr16/v2bPn/PnzHffNiTww0zb8UgAslaGL8M8vySzJMsk4W7Ro8eOPP6ZKlYrm moULF1Z3p9knFZHixYtTEaFyQI+DBw+2uZrW7JXjGmSzr32ZSEiJcbC7qBwClyHWL728vFq3br1g wYIUKVLYbBYaGmp9dUUUKFDg8uXLBw8erFq1qtJCblejRg1qv3jxovK+a86cOSMjI+nakSaUP/zw Q8uWLXPlykW+eObMmaZNm167dq1y5cp+fn401ySHpvOFdk+aNKlyNBIwbXbp0qX8+fMrLXQ1SRd/ uXPnph0d982JPDDTNvxSACyVoUtifN9n2bJlHTt2VJe/+OIL6933799fvXp1pYUKCi0XKlSIbE+3 V45rkM2+9mUiISXGwe4O8EzlyI/A92OvXr1Kcz66uhowYEBISIjNZjdv3rT5UCB58uSvX79++fIl LSgttJwyZUp6Sgt0wPTp0z969OjGjRujRo3asGEDmeW4cePIHX19fR8+fHjs2DE6g65cuWJ9TLqG 2759O21Dy3QoOo59t8nUY2JiHPfN6TywAX4pAJbK0CWRvu9Dl8zKhfOqVatsdrcuIsp3KJQiovtC jmuQzb72ZSIhJcbB7g7wTOXIj9jv+zx48CBTpkxZsmS5c+eOzWaxsbFJkiSx3l1Xq59++imZH50d gwYNGjJkyIwZM6ZNm9a2bdv69etv27ZNeWm6vKOZKF3MhYeH79q168WLFw0bNty8ebMlfjFb9zm+ vhnMAwPglwJgqQxdEsMvnz9/TpM5ujr+8MMP6Zync9t6d3u/tPnOYXwv9E5+aV8mElJiHOzuAM9U jvyI9csnT56kTZs2WbJk0dHRui+hvBdy6NChKlWqKC0274V8/fXXI0eOrFy58qVLl+jijGyYpo+H Dx+ePHnyiBEj7PtDE9x8+fKRhunkoqelSpU6f/58VFRU6tSpEyN8sQeRDfilAFgqQ5fE8MtevXqF hYWpy/PmzbPe3fr9WCoo1apVs3lDlSAHpar09OlTHx8ftVG3BjnuZEJKTMJjNLgLcAEC348lSxs3 btySJUsKFy5MKtJ9CeWz9uLFi69YsaJIkSLqR/XqZ+2K8mnhiy++WLZsWbt27ZR3YpSPG0qXLk1z zZo1a5K26XKQXn3u3Lk0ASXDfvToEW0WEhIycOBAOsL48eNpY9rmxo0b+/btW7hw4bFjx4yHrxug qYFfCoClMnQR7pc7duyoX7/++++/v2jRoi5dupDtUUu9evXU3dXv+0RERFAR+f33320+EyJo7blz 52bNmtW3b1/1Q1PdGuS4kwkpMe+aEKd3AS4gMf7fZ+XKleRkui+h+13uV69ekfnR2bF69erWrVuT WZJl0lnz+PFjUmZ8r06ePXbsWFp48+ZNkyZNlHdubbB5PxZ+aQ/8UgAslaGL2O/7/P333+Rnt2/f DgoKGjJkCD0OGzYsW7ZsZH4ffPCBsntAQMAPP/yg7pglS5bw8PDMmTNbH418kVzQ5uDv9HsS+4gS UmIc7O4Az1SO/IjyyyRJkij/H9uvXz+6FkzgS9CkcPTo0Ta/Fc6RI4e6gb+//4kTJ2itr6/vP//8 kzFjxnLlyik/FyFJk4Pu3bv30qVL5Km0Oym/a9euzZo1U3ePjY1dsGABXTvSyfXy5Us/Pz+aj9IV aoUKFYyHn5AAzQv8UgAslaGLWL9s06bNmjVrqlSpcuDAAaoycXFx1atXP3z4MLV///33yu5Pnjzp 1q3bpk2bvL29a9WqRZ5q848BlrfvgNGl9HfffXfv3j3r7unWIMcR6ZaYd02I07sAF4BxMQ7LHMIv BcBSGbq4MmquGeYal9nBuBiHZQ7hlwJgqQxd4JfG4RqX2cG4GIdlDuGXAmCpDF3gl8bhGpfZwbgY h2UO4ZcCYKkMXeCXxuEal9nBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7l BONiHJY5hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQAh/wbi4+NT qVKl0NDQAgUKUGN8R6O19Hjp0iW15datWwMGDNizZ8/Lly/LlSs3dOjQRo0a2e9IB7Q57LZt20aM GBEREeHn5zdq1Cj1Rlrv1HMoxwjIoZxgXIzDMofwSwEY9Etlx6ioqJCQkJ07d/7666/x+eXRo0e7 dOlCC4sXL65YsaLSWKVKFTLawMBAX1/fX375JSgoaOvWrTYHt39Kh2rRosXSpUtr1Khx48aNSZMm LVmy5F17boFyjIEcygnGxTgscwi/FIAQv7S8/SflNGnSREdHx+eXPXr0yJMnD62KjIxU7+Oh/NWy 9a3bNQ9u87RJkybNmzfv0KGDE31Wj2aBcoyBHMoJxsU4LHMIvxSAqPnlzJkzd+zYEd/88vXr19mz Zw8PD6flkiVL3rp1y9vbm5Zpolm+fPl+/frZ/5mqA7/MkCFDRERExowZneizejQLlGMM5FBOMC7G YZlD+KUAhHx+mSpVKn9//9DQ0EKFCmn65dq1axcuXLhr1y5arlOnTvfu3QMCAmj59u3bY8aM2b59 +9OnTz/55JMZM2b4+fmpB4/PL728vMiAkyZN6kSfrXsO5RgBOZQTjItxWOYQfikAUe/HOm5s0KBB 27Zt27VrR8v/+c9/Vq9evWXLFusNaIY6derUI0eOKHf2sT8O5peygRzKCcbFOCxzCL8UgAv88t69 ezly5Hjz5o3aQhPEmzdv2tz98cWLF76+vtHR0ZrHsX7auHFjmp5+/vnnTvRZPZoFyjEGcignGBfj sMwh/FIALvDL4ODgs2fPLl26VG3p0qVLsWLFAgMDGzZsOGTIkPLlyz979mzmzJm7du06ceKE5nFs vh9LfkkHrFat2o0bNyZPnrx48eJ37bkFyjEGcignGBfjsMwh/FIAieGX1k9pgxIlSsyaNat69epq 48GDB/v37x8eHr5169apU6eSR3p7e1etWpUsM1++fJoHj+/3lzlz5hw1atS7fleW5fngYpBDOcG4 GIdlDuGXAmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJBDuUE42IcljmEXwqApTJ08cyoxYIc ygnGxTgscwi/FEAClWEiASWkqyYKR1qQQznBuBiHZQ7hlwLQVYb193dMkeqEdJjl+eBikEM5wbgY h2UO4ZcCcKAM+2+6uqhPhtHtOcvzwcUgh3KCcTEOyxzCLwWgqQwbv1EwUZ51+8/yfHAxyKGcYFyM wzKH8EsB2ChD02ksJkyy40BYng8uBjmUE4yLcVjmEH4pAFUZ8RkMY6AcI7CsKQzAuBiHZQ7hlwLw QJtUgXKMwLKmMADjYhyWOYRfCiCB80vTJTkh1wGmC0oqWNYUBmBcjMMyh/BLAeDzS+AcyKGcYFyM wzKH8EsB4PuxwDmQQznBuBiHZQ7hlwLA7y+BcyCHcoJxMQ7LHMIvBYD/9wHOgRzKCcbFOCxzCL8U AP4/FjgHcignGBfjsMwh/FIALJWhi2dGLRbkUE4wLsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BL AbBUhi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEgh3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyW OYRfCoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZUYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcY F+OwzCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQ QznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHM qMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyV oYtnRi0W5FBOMC7GYZlD+KUAWCpDF8+MWizIoZxgXIzDMofwSwGwVIYunhm1WJBDOcG4GIdlDuGX AmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJBDuUE42IcljmEXwqApTJ08cyoxYIcygnGxTgs cwi/FABLZejimVGLBTmUE4yLcVjmEH4pAJbK0MUzoxYLcignGBfjsMwh/FIALJWhi2dGLRbkUE4w LsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BLAbBUhi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEg h3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyWOYRfCoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZ UYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcYF+OwzCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgq QxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQQznBuBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIv BcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHMqMWCHMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY 5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyVoYtnRi0W5FBOMC7GYZlD+KUAWCpDF8+MWizIoZxg XIzDMofwSwGwVIYunhm1WJBDOcG4GIdlDuGXAmCpDF08M2qxIIdygnExDsscwi8FwFIZunhm1GJB DuUE42IcljmEXwqApTJ08cyoxYIcygnGxTgscwi/FABLZejimVGLBTmUE4yLcVjmEH4pAJbK0MUz oxYLcignGBfjsMwh/FIALJWhi2dGLRbkUE4wLsZhmUP4pQBYKkMXz4xaLMihnGBcjMMyh/BLAbBU hi6eGbVYkEM5wbgYh2UO4ZcCYKkMXTwzarEgh3KCcTEOyxzCLwXAUhm6eGbUYkEO5QTjYhyWOYRf CoClMnTxzKjFghzKCcbFOCxzCL8UAEtl6OKZUYsFOZQTjItxWOYQfikAlsrQxTOjFgtyKCcYF+Ow zCH8UgAslaGLZ0YtFuRQTjAuxmGZQ/ilAFgqQxfPjFosyKGcYFyMwzKH8EsBsFSGLp4ZtViQQznB uBiHZQ7hlwJgqQxdPDNqsSCHcoJxMQ7LHMIvBcBSGbp4ZtRiQQ7lBONiHJY5hF8KgKUydPHMqMWC HMoJxsU4LHMIvxQAS2Xo4plRiwU5lBOMi3FY5hB+KQCWytDFM6MWC3IoJxgX47DMIfxSACyVoYtn Ri0W5FBOlHEBxmGmbchCGMyUoQtqiig8TTmmAPI2Dj9hv0chQRnG4aeMhADlGMczlQMMgncm3MJ7 yDhgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbg l4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4Bf As6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4J OIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXg DMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4Az KCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6g rACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOy AlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoK YAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuA JRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACW QNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgC YbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE 7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2 W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2W4BfAs6grLgLJfP2 xDcW2B7by7z9f/dCKZEE2fSB7bE9tsf22P5/9oJfSkJ842cxj6SwPbYHrgFvnLgF+CXgDMoKYAmE 7Rbgl4AzKCuAJRC2W4BfAs6grACWQNhuAX4JOIOyAlgCYbsF+CXgDMoKYAmE7Rbgl4AzKCuAJRC2 W4BfAs6grACWQNhuAX4pHYsXL54zZ05ERASdEvny5atZs+bnn39epkwZd/fLlKCsAJZA2G4BfikX M2fODAwMnDp1as+ePZMnT3769OlevXrRI4bJOVBWAEsgbLcAv5SLXLlyXb9+PTY2NkmSJErL+fPn ixYtimFyDpQVwBII2y3AL+XC29s7Ojr64MGDVatWjW+b3bt3T5o06bfffiNb/eijj0aMGNGkSROL 1d+V7dy5c8iQIRERETExMepeS5Ys6dixY1RUVMaMGZUWGvp3OpQZpYKyAlgCYbsF+KVcNGvWbMOG DbRQuHDhunXr+vv7V65cOVu2bOoGu3btql+//tixYwcNGkRjN23atAkTJmzduvXTTz+1/HsWtWnT Zv78+WfOnKlevfqRI0cqVaqUOXPmmzdvenl50dqLFy/WrFmTZrF79+59p0OZUSooK4AlELZbgF/K xePHjwcOHLhy5crXr18rLXRi1KpVa8GCBblz56anZJ9kgS9evEiRIgU9ff78uY+PT7Vq1Q4cOGD5 9yyi6WChQoXUYxYtWvT8+fM//fRT06ZN6SnNF5MlS/b11187cSjTgbICWAJhuwX4pYw8e/bs2Ft2 7979888/UwtZ5p49e2ghZcqUL1++tNmefO7p06eWf8+iN2/eJE2aVF0bHBxMM8gGDRps2bIlOjra z8/v6NGj+fLlc+JQpgNlBbAEwnYL8EvZmTt3bp8+fWgKSBNBy79+SbPP999/335jzbMoKioqe/bs sbGx169fpwnl/Pnz9+3b59yhTAePKACwAcJ2C/BLuaDT4OTJk9a/tlTeJs2aNevt27fpqb+/P807 f/vtt48//ljZ4OzZsy1atLh8+bIl/rOoVatWP/zww+TJkw8cONCxY8e2bds6fShzwSMKAGyAsN0C /FIu6DTImTPnjBkzatas6evre+/eveDg4OnTp0+ZMmXYsGG0wdatWxs1alS5cuVFixblyZPn3Llz 5H8932KJ/yzatWtXvXr1smTJEhMTc/PmzeTJkzt9KHPBIwoAbICw3QL8Ui5OnTq1atUqmgVeunTp xYsXadOm/eijj7p27dquXTt1m+3bt5N90rwwOjr6ww8//PItFqsfgVjsTqS4uLi8efNGRkb27ds3 NDTUyKHMBcoKYAmE7Rbgl4AzKCvAOawvGcG7wvWMg18CMaC+vCs49aQFYjYOS3nDL4EAUF+cA2ef nOBtCSMwzh78EgiA8RmSSCBjMoPRMQLj7MEvgQAYnyGJBDImMxgdIzDOHvwSCIDxGZJIIGMyg9Ex AuPswS+BABifIYkEMiYzGB0jMM4e/BIIgPEZkkggYzLj+tHRfEW1MUOGDA8fPrx7927mzJmtN6CW rFmzpk+fPioq6uzZs5MnTz548CBtmSVLllq1anXr1q1SpUouC8G+265/6cQGfgkEIPYMKV68+Llz 5zZt2tSoUSOlZfPmzY0bN6Z2Kgr09Pr162PHjt25c6dyO8+6detOmDDBz8+PVt25c6d379579+59 /vx52rRpc+XKdfr0aSG9EgvjmsIA2fySbO/o0aP2t8WllurVq9Pab775hs6CV69e2RzWLQJjrG34 JRCA2DNkypQpX331VZs2bb7//nulhZbXrFmj/ClgZGRkuXLlkiRJQi3ly5c/fvx4q1ataJuTJ0+S ZdavX3/Hjh0bN26sV68emS5dca9fv15Ir8TCuKYwQDa/7Ny585IlS7799tvu3btbb0AtPXv2pLUk 9RMnTpD4g4KCChUq9Pjx459//nnOnDm7d+92WQj23Xb9Syc28EsgALFnCE0fc+fOnSJFinv37vn4 +Dx79ixz5swvX77866+/cubM2bFjx2XLli1fvvzzzz9XtqflDh06UDvVlOTJk79+/frWrVvWN9lW e6iQMmXKtm3bzp07V7kxy8yZMwMDA8mAM2XKRDPa6dOnp0mThtoXL148e/bsiIiIDBky0HS2W7du FGBISMi8efOoh1myZPnyyy+HDh3q3G9PGdcUBsjml1OnTh0+fPjAgQNnzJhhvQG1kCBp7ejRo6Oj ox8+fJguXTqX9Tk+GGsbfgkEIPwMqVKlCl0gr1ixon379vT4xRdfUMuhQ4doVdasWe/evXv//v2M GTMqG9MyGSoZJNmksjZ9+vQNGzasVKlSgwYNFONUekj1ZdKkSaNGjQoODqbHiRMnUiNVIpqhFilS ZNWqVV26dFF8l5yyX79+dJCFCxcmTZp0woQJoaGh06ZNI4MkbybLpAv58ePHk7kOGjTIiQAZ1xQG yOaXGzZsaNasmXIL2/79+5MUSZyzZs369NNPt2/fTmv79u1748aNkSNH0lr1vHAXjLUNvwQCEH6G hIWF9erVq379+tu2bVPeYqWWHj160KpkyZK9eYt6I2taTvYWusTetGlT9+7daWKqrKJG2rFz585K D2/fvq3cGS179ux+fn40TbR+0djYWC8vL5pNPnjwIG/evNeuXbty5Uq+fPnUDfLkyUNz3MuXL3/4 4YePHj364IMPqOXq1atOBMi4pjBANr+MiIig6zmSIgmybNmy586dK1as2MmTJ6mF5EdrDx8+rLxV S7sUKFCgfPnyLVu2pKs9t/zxFmNtwy+BAISfIQ8fPiRjowOGh4eXLFmSjk+zRuW9pvjml+otQsk+ jx07dvDgwaVLl/7555+ZMmUi+1R6SI6YJEkSxReJmJgYKjR0VU6v8uzZM6X/tGVcXJy9K1v+tWrr fipHcyJA/IOg/Mjjl3QhmDJlSsvbe7+T7OlScv78+SR7urYjBb548YKUuWfPnpCQkP379798+VLZ vWrVqhs3bvT19XVZFA5i4QH8EgggMc6QRo0abdmypUSJEmfOnKFlmjgq7R06dFi+fLnyVq3Sorxh q7yPan2Emzdv0iQyefLkVEGs55d37tzJli2bMr+kBXq6efPmevXqkRcqVYkC0ZxfKo32X+t3Avil /Mjjl/SYP39+UuO8efP69u0bGRmZK1euWbNm9enTh9ovXbqk7kKXgMp0Mzg4mKaeXbt2XbBggcui sO82M+CXQACJcYasXr36s88+U5dbt26tLP/1119ly5al2eHatWvLly//yy+/0CqaEZ48eTJnzpzV qlXr3bt39erVP/jgA3LBli1bKl5r/fnl6NGjZ8yYMWLEiMmTJ5Pz0XX6oUOHaBY7ZsyYmTNnKoFY f35JF++0Je1CFWrAgAFk2LQZzTt//vlnWti5c6cT0TGuKQxw/eh4e3vTJJJkrF5I0avT3JHalV+J kBS3bt1apkwZ2uDEiRN0CtAGv/32G7WTzu0PSGZJl3rKhwsui0KBsbbhl0AAiXGGvHjxgszs2bNn Pj4+ZGkpUqRQV5Fljh07dteuXVFRUVQRaGo4fvx4uuK2vC0rf/zxB00BqfrQqvr160+fPp0WrOdz dChyYrpUp2K0Z88e8sULFy5Yd15ZXrRokfL92IwZM44bN44u1anxu+++mzt3Lm1P09ZKlSqRfdat W9eJ6BjXFAa4fnSyZ89++/Zt8jbSqtJi/S02ejpo0CCaMtLC4MGDp02bRo/Kd2WpnRRuf0DlnVvl Q32XRaHAWNvwSyAA+c8Q2XooW3+ANa4fnYCAgHXr1jVt2pRcMGfOnJGRkQMHDty0aVOLFi2o3fL2 Qk35vhvNJpU5ZePGjZX2bt26lS9fvnPnzjVq1FCuGs+cOTN8+PD9+/cXK1bs999/d1kUCoy1Db8E ApD/DJGth7L1B1jj+tE5d+5cxYoVnz17Zt3o4+Nz5MiRjz76yPLvX/kkSZLk4cOHvr6+jx49Sp8+ fVxcnPKnP5ofhydNmlTxYBfF8C+MtQ2/BAKQ/wyRrYey9QdY45bRuXjx4vjx4/ft26d8ylCzZs2x Y8cWLFhQWav8VWzJkiXV/3csVapUeHi48u2z48ePL1u27MCBA9euXYuNjc2UKZO/v39gYCB5sCtD UGCsbfglEADjMySRQMZkBqNjBMbZg18CATA+QxIJZExmMDpGYJw9+CUQAOMzJJFwfcZat269Zs0a m8ZWrVrVrl27e/fuW7ZsGT58+OXLl/Pnzz916tQGDRooG9y6dWvAgAF79ux5+fJluXLlhg4d2rBh Q9d0uECBAvRo/eNC9VM6Hx+fSpUqhYaG0jbUKDyN0LMRGGcPfgkEwPgMSSRcn7Fs2bIdPXo0d+7c astff/3l7+9/9erV8PDwZs2arVy5kkzoyJEj7du3/+mnn8qXL295+0e+1BgYGOjr6/vLL78EBQVt 3brVBb2lrnbp0sXy9l/v1Q/hVGuMiooKCQnZuXPnr7/+Cr+UDcbZg18CATA+QxIJ12dswoQJ//zz D9mM2kITx3Tp0o0ZM6Zp06ZNmjTp1KmT0k4WtXnzZrJMWn7//fcfP35s/eNXpfM0B50xY8azZ89o 2jp//nxvb2/L29/I0zH3798fExNTo0aNZcuWZcqUiZaHDRu2YsWKN2/ejBo1atCgQbGxsbSwaNEi 2r1x48YLFixInTq1TW979OiRJ08eyk9kZGRYWJj6umrGXr16lSZNmujoaPilbDDOHvwSCAD/7uYc rjz7aE5WrFixixcvpk2blp4+evSoYMGCf/zxR4YMGTJmzEgL5G3Klvfu3StevPj9+/dpmeZ2NNHs 169f3rx51UPRcDdo0IBslZbJZemwZJ+0XLRo0dmzZ9MuZGNjx46lV/zPf/4zcuRImgWSO/r4+Iwf P54Me+LEiYcPH6bdqSd0ZDLjefPmWXf19evX2bNnp1kvLZcsWfLWrVuKH1vPL2fOnLljxw7MLyWE cfbgl0AMsMx3xfWnXu/evWnSNmTIEFoOCgr666+/FKPy8vIii7K+3wt5GM0LLW//cZcmoNu3b3/6 9Oknn3xCc0o/Pz8aa+UmLbQBLdSsWfPGjRs2r/XixYvcuXOT6dL2e/fuVT6MVKD2nTt3Kr+UIG8u UaLE3bt3rfddu3btwoULd+3aRct16tTp3r17QECAxUpjqVKl8vf3Dw0NLVSoUOL5JTACS2eBXwLm ML7afVeuXLlSu3ZteqRskNuRjSme52B+qUJTOppEHjly5OjRo5RS9c4t1uZKq4YNG3b69Onnz59b /r3TC5nxq1ev6FE9VLJkyZThoEflH1Pp0fq1aPLatm3bdu3a0TLNUFevXr1lyxbL/74fq5IYfmmB ZRqD6+kGvwTMgV9a07x58xYtWlA21r9FaWzSpEnTpk2tP7/ctGnThg0bbPalKaOvr6/ykaE6vyT3 rV69+s2bN2k5R44cNAGlaWiaNGloPpo2bVp6Ifv5Zc6cOY8dO5Y9e3bNHpJb03Gs75tGXkvHz5w5 syv9UnKgarfgiVIDHgUqizU0BezTpw9lY+7cuf7+/mojmejKlSsrV65MM0ia25GVKt9Kbdiw4ZAh Q8qXL//s2bOZM2fu2rXrxIkTlNJGjRotWrSINujcuXPhwoWDgoJoOX369OS15Je3bt0aMWLEmjVr 6IVGjRp18uRJ688vv/76a3qV0NDQXLlyRURETJ48mWaQag+Dg4PPnj27dOlStaVLly7FihULDAyE X6pA1W7BE6UGPApUFhsUmySPtG6kCeVXX32l/P5yypQpZIdK+9atW6dOnUoe6e3tXbVqVbLMfPny WX8/NiAgICwsLHny5LQxTUkHDRoUGRlJc8fBgwf369eP0h4TE0OOu2LFCloePXo02V5cXBzt/u23 396+fbtgwYJkqOrN2ogSJUrMmjWL5qxqy8GDB/v37x8eHg6/VIGq3YInSg14FKgswvFMi5IKqNot QPeAOagswoFfuh2o2i1A94A5qCzCgV+6HajaLUD3gDmoLIAfULVbgF8C5qCyAH5A1W4BfgmYg8oC +AFVuwX4JdAG/28iLThnnQaqlhZTqBp+CTRAWZEcnLZOAFVLjvyqhl8CDfBuj7RgaJwGqZMWswwN /BJoYBb5eiAYGqdB6qTFLEMDvwQamEW+HgiGxmmQOmkxy9DAL4EGZpGvB4KhcRqkTlrMMjTwS6CB WeTrgWBonAapkxazDA38EmhgFvl6IBgap0HqpMUsQwO/BBqYRb4eCIbGaZA6aTHL0MAvgQZmka8H gqFxGqROWswyNPBLoIFZ5OuBYGicBqmTFrMMDfwSaGAW+XogGBqnQeqkxSxDA78EGphFvh4IhsZp 3J46mz/kwyCquH1oEgj8EmigK1+z6JsfyLzTuCZ1kZGRU6dO3bVr182bN5MnT16hQoX+/fvXr1/f 4iq/NKNCzNJn+CXQwDm/tC4HyZIly5YtW7Vq1YYNG1akSBGl8enTp+PGjVu3bt3du3ezZMkSEBBA T318fGx2T5kyZfbs2atWrUqFpnjx4uoxz549O3ny5IMHDz58+JB2r1WrVrdu3SpVqpTAoAzunkAS +8w3S2WREBekbv/+/U2aNCGd27RrninwSxWz9Bl+CTRwTr6a939IkSLF3r17K1asGBcXV7169cOH D1uvJVOkEpMkSRLN3b28vBYsWNCxY0daph3r1q376tUrm20S2EmDuycc+KW0JHbqHjx4ULhwYboa a9269VdffVWoUKEXL14cOXJkzpw5O3bscFlPzKgQs/QZfgk0MOKXyl7R0dF//PHHkCFDyCyrVKly 6NChNWvWtGnTJmvWrD/88EOZMmVOnjzZsmXLe/fuUXurVq2sd3/58uXly5cXLlxIhYbmqTQvLFiw YPny5U+cOFG/fv2goCCqRI8fP/75559pg927dyekbwZ3dy4JiYFZKouEJHbqJkyYMHbs2IYNG27e vNmJniSkcfXq1cuWLTtz5kxUVBRdZebMmbNatWqdOnXy9/d3cLcydffXr1/PmDFj5cqVf/75Z8qU KevUqfPNN9/kzZvX/uXGjRs3e/ZseomRI0cOGDAgwTlwErOoGn4JNIhPvo4/gLHfi+wwS5YsNMWk C+2AgIB169Z9++233bt3V9bOnz+/d+/e5JrkoJq701rapn///jNnzvT29iYPpov3dOnSORGR7u5l y5b99ddfly9f/vnnnystGzZsaNasWYkSJcLDwy0OS5V9Zuyz5LhUKbtTHnr06JEvX75t27aFhoYG BwfnyZPn999/tz6aWSqLhCR26ipUqHD8+PE9e/bUqlXLiZ7oNg4dOnTatGmaB6QNdBUYExNTt27d AwcOWK/KnDnzqVOnsmXLZv1y5JR9+/a12T1RMYuq4ZdAA1F+SdaSMWPGDz744O+///7www/JKi5d upQ/f35l7cWLF2mqR+00m9TcnWaENC8sWbLk6dOnyZ9u3LhBV7tkn3TMd41Id/fFixd36dKFSt6x Y8eUlqZNm27cuDEkJISurx2XKvvM2GygW6qU3SlR//zzDy3Url2byq718VXMUlkkJLFTR8P36NEj kjotONET3cbUqVM/e/Zs8uTJ7du3J9nExsZev36dRLVkyZKjR486Pg4xffr0IUOGlC5dOiwsjM6p 27dvBwYGrl+/vmfPnnRVar1v0aJFR4wYoXwQO3HixLlz5zqTjnfBLKqGXwINjHzfR2mkk5mscfjw 4Zs2berWrdt3332XKlWqF2+h6aayPS2negtVAc1jPnnyJO1bqAwtWLBAmZjSZgUKFCAfpYlpw4YN HRiVNbq7v3z5Mnv27GRX5GGlSpUip6eSRJ25detWpkyZEliq4suMbqlS9tq6dSs9NmjQgB43b96c LFmyTz75BH4pisROnZeXFwnjzZs3SZMmdaInuo158+a9du1a5cqV/fz8cuTIkTVr1uLFi9eoUcPm 5eILk4R35swZ6wvW+/fv00Vb7ty56bDW+4aGhlrPL12AWVQNvwQaGP9+rAJV/M8++2zevHlkinRW x8XFUUFRvt1D0FNqpKfUqHlMaqcaRNtQDaKnNOWi2d7+/fvJ25QNqlatSlNAX1/fhASluzt52MyZ M7t27UrmOmvWLJpWNmrUiPzekuBSFV9mdEuVshddztOC8oVhdRl+KQqzzy+PHDnSsWPHK1euWG9A c8Ht27eTLB0fx/L2a+eq8q2hUywmJsZ635s3b9K1o+MQxGIWVcMvgQai/JIMZunSpfny5aNlg/NL tZHO7YiIiMOHDwcHB1+9elWxt4SH5mB38rNChQpR92hOWbNmzdOnT//444/Nmze3JLhUxZcZ3VKl 7kUo1xPqsm6SExVO9SGxi7LynTKBn1++fv06efLk1o20QBdeZ8+epcus8PDwXbt20Ulk8w2jd/VL 642Vfa0val2DWVQNvwQaGPHLuLfQ/InmakFBQWSWdHrTuWr/+SUtFyxY0MHnl8ePH69QoYL6jRsb yO3o4BkyZHjw4IETMWruXrt27b1793bu3Hnx4sXp0qW7c+fO+++/r6xKSKmKLzO6pcp6L5tl9/ql hZFlJrZfjhkzZuLEiY0bN964caPjLZVvnz19+lT98TGRJk0aarlx40aOHDmUFpIiCdJBnxUNk7qe P3+uNipv5Ni/LVyqVKnz589HRUWlTp06vo65a55nFlXDL4EGxj+/VGjQoMG2bduojowfP75ly5Y0 XaPJHE3plLVhYWG9evVy8P1YWkvb9O3bNzQ01L4PypeJkiVLRqXHiRg1d1+/fn2LFi2U5d69ezv4 poNmqbLEU610S9W7+qVrTluzvEuWQBI7nLt37xYuXPjRo0dt27YdNmxYoUKF6CLpl19+mTVrFp0F 1lsWL1783Llz1E7aVq2iUqVKR48ebdWqFV1o0mXcsWPHevToceHCBbXPpUuXpiPXrFmzQIECNO+8 efMm6XPatGk2b8BkzZqVevLtt99+8cUXyvRUISQkZODAgdWqVaOTkQ5Fq8ib9+3bt3DhQvU7bu71 S/lVDb8EGojyS+ULrunTp6dz+6effqKzPVu2bNa/v6QT2/73l69evVJ+fzl79mwvLy+a1VEZouPQ tK9GjRq5cuWizahx+PDh+/fvL1asmM0vLjRJ4O7kc7lz57516xYtHzx4sGrVqkp7AkuVJZ5qpVuq 4JcuwAXh7Ny5s3nz5i9evLBpt3lRcsTAwECbtcuWLVP+mkNl1KhRkyZNsvyvMOwZN27c2LFj1afK Vab9q5O2mzRpYuPcNt2DX+rsy+ZkAAJJ4O9JVOwLvUq5cuXIGpcsWUL+QfZz5MgR67WO/9+Hpmhk PF26dInvpWmDdevWNW3aNIERJWR3sjQqQGR7ZIrqpzgJLFWWeKqVbqmCX7oA14Tz559/BgUF7d69 m666lP+PHTBggPL/sSpxcXGknO++++7evXvWXSIfDQ0NVd6S/fLLLwcNGqR+mE2Pp06dWrVq1d69 ey9duhQdHU1z0I8//rhr167NmjWzPvizZ89GjBixcePG27dvK1+UU48fGxu7YMGCFStW0OyW5r5+ fn50Caj8jMqVKbLHLKqGXwINBPrl8uXLO3ToULZsWZprPnnyhMoEzS+pTGTOnJmmlfRUfYtSPXiK FCloGkpW2q9fv5IlSyqNx48fpwvwAwcOXLt2jU77TJky+fv700V6xYoVExJRwnf/6quvpkyZQtVq zpw5amMCS5Ul/mrluFTBL10As3A4YRZVwy+BBh5bWejCP2/evJGRkeSs1apVc3d3NDBLZZEQZuFw wiyqhl8CDTyzslC88+bN69OnT/bs2a9fv+7ir9QnELNUFglhFg4nzKJq+CXQwDMri/qG8KRJk0aO HOnezsSHWSqLhDALhxNmUTX8EmjgmZWFok6RIsVnn302f/589WeXsmGWyiIhzMLhhFlUDb8EGqCy SItZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJi lsoiIczC4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWy SAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLC LBxOmEXV8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhQsJ58+ZNu3bt1qxZY3Nkpw9rs28C D2XkFY3vbs/XX389YsQII/2xmEHV8EuggUD5atYXm9cSK0LlgO96WHX7ROqPwKNZzFBZJERIOKtW rbp169aQIUNsjmwuvxROxowZHzx44PTuZlG1XEkHkiBQvpr1xea14nsh54qC4710jym8YMEvJUFI OI0aNRozZkzZsmVtjuzhfml8vmsxg6rlSjqQBIHy1awvNq8Fv0w4ZqksEiIknMyZM1+6dClt2rQ2 R1YO+9tvv3Xu3Pn8+fNFihRZunRpqVKl1NfNnj37/Pnz6XSg5ePHj3/++ed0Hdm3b9+pU6fa+OWw YcNmz55N269YsaJ8+fLWnVcPYi0q+1UTJkyYMWOGl5dXcHDwF198QWtPnz7dpUuXs2fPxsbGWr/7 ornxsWPHaOH27dv23XMQIPwSeCgC5atZX+KrF9ZnfuPGjdXt1XPb8r91x8EB1Yowfvz4OXPmREVF 2XRM2Ya2DwsLi46Otq4g9gXLvjxZHyciIoKK0a+//ponT57FixdXqlTJQUE0iFkqi4QICSdZsmSv Xr1KmjSpzZGVw3700UfdunUjRyEZLFy48MyZM8oGcXFxhw8f7tSp09WrV5XNevbs2bFjx0WLFvXr 18/GL+fOnausWrBgATmcusr6IDYXYTarSL0kyIMHD5Lt3b9/nzYoUaIE9Ype1Nvb27rDmhsXL178 yy+/pKfkiLRg/ULxBYj5JfBcBMpXs744qBcOioLFru44OKC6b6pUqWbNmtWuXbsUKVJY7Jxv2bJl tIq6Z11B7AuWzV42n4+WK1eOykqbNm327dsXGBh44cIFBwEaxCyVRUJcML8ktT958oSU9vz5c19f 35iYGNIezd7oyomkS5vRo/VmL168IH3a+CU1KqvoVegI1Gh/EPUVNVfRJDJJkiQ2HXv8+HHKlClt Oqy5Mc01nz59qtk9+wBtDugcZlE1/BJokNjzS8164aAoaK51fEB131WrVtEVNE0BybcmTJhg43x0 wlN1sPxvBbEvWOpael0yVxu/pFd/8+aNekzaxkFBNIhZKouEuODzS3VmRtdJyvSLNLBp06bKlSvv 2bOncePG6jS0d+/eHTp0WLJkic0Ejg41f/58ZVVYWJhyuWZ/EPUVHayy7ljJkiXpKlNzfmm/sRKF ZvfsA7TZ1znMomr4JdAgsT+/1KwX9mf++++/HxkZmTVrVs21jg9ocwKHh4dXrFjx5cuX1sfULBaa BStjxowrVqyoVq0alYm+ffva9I2i69OnT0BAgHr97qAgGsQslUVChISzcuXKO3fuDB482ObIymFP nDjRpUuXCxcuFC5cmIa+dOnSY8eOpUs9WhUYGDhu3Dhls3f9/NL+IOorOlhl3bFTp06RX/7+++// 9xbHfql+ftm1a1c6BV6/fq12zz5Am32dwyyqhl8CDQTKV7O+aNYL+zOf1pI/kcnRsmbdcXBA64pA jxkyZKD55ejRo62PGZ9f2hesZcuWDRo0iCaRQ4YMGTVqlE3fLl++3KtXryNHjrx69UrJGz6/lBAh 4cTExLRv397B76PYEB0dTWfB2rVrScyJ/VpmUTX8EmggUL6eU19cg1kqi4QwCydRee8t+fPnX758 ufod3UR9OYsZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWy SAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4S4IBwHP6sw+IsLITjdh9atW69c uVL5pXJiYBZVu38IgYQwK5QGSexi8U6YpbJIiHvDcZdfCnndoKCgHDlytG3bVkiX7DGLquGXQAPJ C6WLS09iF4t3wiyVRULgl05z4sSJiRMnbt68WUiX7DGLquGXQAPJC6WLS09iF4t3wiyVRUJc+X6s /X08NP8HQ8X+L/t79epVs2bNgICAtWvX7t+/v1+/fjYbWOK/64jak/es7g1gvYFm9+xvVKLy6NGj QoUK3b17N/HyZjGDquGXQAPZCqWDe4xonvnqXUcs/8ZifVcT+9sV2Vcr61dJ7GLxTpilskiIK/3S /j4e78V/4xGL1l/2x8TENGjQoEmTJhs3bty6dStp0mYDS/x3HbFe1mzU7J79jUpU3rx5kyJFCvXf 1RMjbxYzqBp+CTSQrVA6uMeI5pmv3nVE2cbmrib2tyuyr1bWr57YxeKdMEtlkRBX+qX9fTze0/of fxX7v+ynhb1799auXfvIkSP+/v6aG8R31xH1rgCWePxSs3v2NypRwfzyv/uyORmAQGQrlA7uMaJ5 5qt3HdG8q4n97Yo0i5EK5pcueC0X4Eq/tL+Px3ta/+OvYv+X/aTnevXqjR49esqUKdu3b69SpYrN Bha7u47Y3xWAGjVvMKDZPXtbVTl58iSdd/j8En4JNJCzUGreY8Txma95VxP72xXZVytrErtYvBNm qSwS4kq/tL+Ph+PPL+3/sp92b9OmTZ06dbZt2/bTTz8NHTrUZgOL3V1H7O8KQNto3mBAs3sO/HLa tGnUbXw/Fn4JNJCtUL4X/z1GHJ/5mnc1sb9dkX21sn71xC4W74RZKouEJHY4V65c+fjjj588eZJI x3cj+P3lf/dlczIAgTArlJok/HZF+P2lC17LBSR2OClTpqRZIF2WJdLxGWMWVcMvgQbMCqU9773F ZbcrEohZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQao LNJilsoiIczC4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0 mKWySAizcDhhFlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWap LBLCLBxOmEXV8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouE MAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC 4YRZVA2/BBqgskiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhh FlXDL4EGqCzSYpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV 8EugASqLtJilskgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwS aIDKIi1mqSwSwiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBqg skiLWSqLhDALhxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhhFlXDL4EGqCzS YpbKIiHMwuGEWVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV8EugASqLtJil skgIs3A4YRZVwy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwSaIDKIi1mqSwS wiwcTphF1fBLoAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBqgskiLWSqLhDAL hxNmUTX8EmiAyiItZqksEsIsHE6YRdXwS6ABKou0mKWySAizcDhhFlXDL4EGqCzSYpbKIiHMwuGE WVQNvwQaoLJIi1kqi4QwC4cTZlE1/BJogMoiLWapLBLCLBxOmEXV8EugASqLtJilskgIs3A4YRZV wy+BBqgs0mKWyiIhzMLhhFlUDb8EGqCySItZKouEMAuHE2ZRNfwSaIDKIi1mqSwSwiwcTphF1fBL oAEqi7SYpbJICLNwOGEWVcMvgQaoLNJilsoiIczC4YRZVA2/BBookgLSIn9lkRCoWnLkVzX8EmiD 4iItLjtnmfmlBaqWGFOoGn4J3Ay/oswGDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiUFmkBUPjNEidtMAvgYlBZZEWDI3TIHXSAr8EJgaVRVowNE6D1EkL/BKYGFQWacHQOA1S Jy3wS2BiFPkCaUGJcAKoWnLgl8CsoLhIC+qD00DV0uK0quGXAAAAgD7wSwAAAECf/weaRxVqCmVu ZHN0cmVhbQplbmRvYmoKNDggMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoKNTQgMCBvYmoKPDwv UjUzCjUzIDAgUi9SNTIKNTIgMCBSPj4KZW5kb2JqCjUzIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UK L0NvbG9yU3BhY2UvRGV2aWNlUkdCCi9XaWR0aCA1ODcKL0hlaWdodCAyNjIKL0JpdHNQZXJDb21w b25lbnQgOAovRmlsdGVyL0RDVERlY29kZS9MZW5ndGggMjAwNjg+PnN0cmVhbQr/2P/uAA5BZG9i ZQBkAAAAAAH/2wBDAA4KCw0LCQ4NDA0QDw4RFiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIy SGJJTlZYXV5dOEVmbWVabFNbXVn/2wBDAQ8QEBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVn/wAARCAEGAksDASIAAhEBAxEB/8QAHwAA AQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIh MUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpT VFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAA AAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEI FEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm Z2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0GSITQ7JBwRzg1G5EShQO AKmY4H1qpcSAMODQBBdhZFBYZ2nPNQyhJBu7LRdNwCmST2qhcSsBsAI+lAE4PnIwTAx0rMugsIDT kHecCrassKqCfmajyVnyJMEKcjIzQBl39pHc2pSIupyDuHWsyJ54G3NE5jX2rrLGBlaTOOT1pdUl W3sX2Rq7gcAY5oAxbbVEkVvKDFF65HSsPW7v7SoW3Uhz6+ldHZ6b9utVn8t7ZnHK96wtZ0uS0QgS lm6DjNAHNi3unw+8nb1GamaYwRbdp5/vd6sQ2lwEIUkt1NOltS6AyHnuKAIYplKAtjNQXUyOQo69 frUN1aNG3yEiq7GdVG4HHQUAWdyhSZSABVW4VAEZOjLn9SP6VMfLdAHR2PfDY/pR5QCgOrMuPkAb BAyeDxVpItJW3K0ZzxjJp/TBxxSHbuzGrKB6nP8ASnZwc9frUEMccFcHO6rFmWQnnA9TVTc3UDIF S7sx529qANWS8UZAbD9sd6jF28uFjLAnqccVlI8gcCNS5B6EZrr7a1DWSt5ABxk4oApWcMSDGCzN 1yK6Gzi8oAnaq44FZSr5KAk4WtZbmGRI1IJHY+9AGjDNbqwVsbjzxVhVhkJI5z2rFXzRKCq8dMmt 2yiQKTxvPJoAbDFJFJwgZT39K0bdChBIIJoSMqwORzVryz65oAdGuGDVP2qGMHJDc1N7UALjPag5 ozzRnnigBCOMVBa2726vvlMm5iee3tVjpRQA1ZVYgKRk807P51G0YDK6qNw4p+0FgT1FAC4xUc0K zIEkGQDmpM880pP5UAMMYxjpj0peaXmigA5o70Zo60AFGcZJPFFIQCCvrQA1JUkzsYHHHFPFUdP0 yKwkmeNmYytuO45q9zQAYGfemz/8ekv+438qUEnrST/8esv+438qAK0P3D9akqOH7h+tVNT1JLCL Aw0zD5U/qfapGLf6lFZMEODIV3YJIBH1APJpl1q0MEcZAy0kfmBWyOOwyAef85rHdFtkN1qA867l +ZIm7e7f4fh9L+n6UZmN1qIMkrnIRu31/wAP8hgafmCa3jlUEK4DDPXkVDp3/IOtf+uSfyFWZvuD 61W07/kHWv8A1yT+QoQiaUuIXMQDSBTtB6E9qrwXt5BCkSaYSFGMm4XJ9zx1PWrdRrF9quNhLiKI ZYqxXLHoMj25I/3aYDP7Svv+gZ/5ML/hR/aV9/0DP/Jhf8Kt/wBnW/8A02/7/v8A40f2db/9Nv8A v+/+NAFCe9vJ4XifTCAwxkXC5HuOOo61YiLmFDKAshUbgOgPekaL7LcbAXMUoypZi2GHUZPtyB/v VJQAUUUUAFFFFABRRRQAUUUUAFFFFABVS7+9+Kf+hVbqpd/e/FP/AEKkxokp8n3h/uj+QplPk+8P 90fyFIbLrEd6qXLL61YkcKvNZF9N5g2JnJ71RI6dVypU/MB2qvI8ahhLx3zVO3uJIpiGG8H3qtd3 /wBoZowu0g96AJIQlxM7HJUHAqwWER2D7vSq1q/l4VkwMdqJ5N0uAaALP2xLcoxOATjFLIjzXcb7 lEajJBrCu3lnlKMh8uMggg9TWik29RgnpQBpXF9HBEV3BRjHFYl032ojDHn9akmweDz9aoyq8G0o M8+vSgBbm3NvZyGEbnxxn1rIgMk8INygSQ9hWnLNOQRnjtWVqLvHb7x8rAUAQzmOP7xHHrWTdSNI DtUBR6U4iSdA7P1pBhRt9aAK8BbBB7+tWOSiDPKjH6//AF6ZIu049qbuO7IJJHancd7Egi52g0xh tJzjFIzTZ4xzSNG8oG44pCIUyZfl6E9atxQ+Znc2farNtaqiAEZz1q/BaRMQwTBXvigA0rZDL5jo oA7kVuRyyOhMQGCeMUy2tIWQZGRirlvELeM7VG3+dADHty0QDKORTrawjZwA5PqD0FWrJ1uN394H pVz7Mv3ivT0NAEkVt5A7PkVLGqueFxinROSvPQUsSAy5TJz60ATwb84H61bjdh8rCo4kwTn9KnTb kdz70ASpnOalFNWlFAGfrEl9HHGbCNXcuA27sKvx7jGpYYYjmlP50vSgBCoOD6Uv4U0PmQptIx3p 3egAPNLkUh6ZoHegBNwBAJ5p3TpTGRWYMRkjoad2xQAHnpTVUjJyTzTvWgUAHel6U3dkkd6U0AKT WDrXiK30q6gt5AxeVsDAzW72qpdada3bxvNCrshypI6UATxyB0Vh0IzUme9IqhVCgcDtS0ANZcsG JPHaif8A49Zf9w/yp2efemz/APHrL/uH+VAFRd/kP5e3fzt3dM44zWLZWsmDfXCmW6lP7hWxgnGQ ev8AhjH0rch+4frUYtVESxrI48s5jPGU4xgcc8ZHOaQzGsIgsz3t6Hlm8vzxgAhV5wfrxwO3H4b6 NvQNtZc9mGDUJtIvLdBuVXiEWAeijOMfnU+DuJycY6dhQAyb7g+tVtO/5B1r/wBck/kKszfcH1qt p3/IOtf+uSfyFCETSyCKF5GyVRSxx14qC01fToIAr3IMjfM5CNyx69unYewFWqjPmSTLDCyq2NzM ylgo/Ajkn+R9KYB/b2m/8/P/AI43+FH9vab/AM/P/jjf4VJ9kuv+fmH/AL8n/wCKo+yXX/PzD/35 P/xVAFW71fTp4CqXIEi/MhKNww6dunY+xNTxSCWFJFyFdQwz15pB5kczQzMrNjcrKpUMPxJ5B/mP WpKACiiigAooooAKKKKACiiigAooooAKqXf3vxT/ANCq3VS7+9+Kf+hUmNElPk+8P90fyFMp8n3h /uj+QpDZNPyOtZbkpIQcEdq1Zl/dnPYVizSR7zucBvTNUSR3SK8RZcBh0rAvUKTJJIuC3vXQTx7o 8o2CetY2pJ5gELEH3oAIt0sfyMcDuaryxzmUIznnuKlImWAIgwo7gVELrywOWZvVhxQAXiyIFVTj A656moVuWjAyQKrPdPcyPkgc8AGoV3SyEE8jrQBpC6aRx6D9aivJ3cbY/vHpVe4M8FvvgQSMTjFP EwDK0mFJHSgCJLoxgrM+WHYVn6jLNcxkKpVB68ZrSkREdpMZLetU7iXcpUCgDFtkcq3OeenpT2i7 kdKieYwzlV4yamZyx5NAFaRstzx70qgNk46VZaBZE4IB9acLfavWgCvtO3PWnI/zjJHoKupaMkeW HGM5pv2XhGHTNAD4GO/nB9K1LcnIB6VWSDyyOnrWrawllB70AWVjESggjBpl1cywlFUKY2OCfSrK okuI3GJF5GOlMuLdVVQ4GR0wM5oAsWUR5ljYZ9q04ZBJ8u8Me9ZFmzK+QAsRHNWdjo2+L7p/nQBs JEVUlcE0+FMyDIwKgtDK8IYnnqRVuPccAjj1oAtoFVcCk2fNuFIo44OalSgByNzjpT6aFAangUAL 1ooBDZI5oxxyaAD0FHaimBGEu7cduPu0APxQRkY7UZqOZC6gK5U56igCQDAwOBSEEsCDgDtSjPSg CgBAQTikZgoJJ4FOAApGXK4oA5uHxXZy622nqTvHGeozzXSKwYcd6xI/DdimqtfiMece559P8K2l UrxxxQA6g9DRmg84oAaMbs5p1NCBSSOpp1AC0y4/49Zf9w/yp2M02f8A49Zf9w/yoArQ/cP1qIg3 E0iF3WKMhSFOCxxnr1xgjoR3qWH7h+tV7wSwq8tuyq0m1CCONxO0N+ozwcgAUhkOH+2+V50v2bPl 7d3zb9u773XGPfr7VZANvNGgd2ikJUBjkqcZ69cYB6k9qqf2c/2j7R8m/bt2b2z16+Z1z+HTirFm JZlSW4ZWaPcgAHG4HaW/Q44GASKALE33B9arad/yDrX/AK5J/IVZm+4PrWTb6ilvaW8bBciFOrY/ hFVGLk7ITNVmCqWYgKBkk9BU1hGViMrgiSY7iCOVHYe3HUepNYzapDMjRlFYOCCA/UVl3txptmIw dPkleQkKkcvOAOTyRx059x61bpTSvYVzt6K86fWtLjiWR9JnWNvus1wgB+h31BH4j0iVA8eiai6H oygkH/x6o5WM9Cv4y0QlQEyQncAByw7j346D1AqFWDKGUgqRkEdDXK6bfaVqSSGKxdGiba6SS/MO M8gE4/xB9K2Y9QSONUSHCqAAN3QVoqM2rpCujSorP/tIf88v/Hv/AK1H9pD/AJ5f+Pf/AFqfsKnY Lo0KKz/7SH/PL/x7/wCtR/aQ/wCeX/j3/wBaj2FTsF0aFFZ/9pD/AJ5f+Pf/AFqP7SH/ADy/8e/+ tR7Cp2C6NCis/wDtIf8APL/x7/61H9pD/nl/49/9aj2FTsF0aFFZ/wDaQ/55f+Pf/Wo/tIf88v8A x7/61HsKnYLo0KqXf3vxT/0Kov7SH/PL/wAe/wDrVLbst653AqBjofTmpnSnFXaGmSU+T7w/3R/I VL5Uf+1+f/1qoWd6L+AzrGY18x4wCcn5GKZ/Hbn8axGzRkO5CCOtcnqmhy3GoRTi6ZVQ8oO/+ea6 44xjrVSSINJnHaqEczd29ykeEuSoxWZ9muhOkszll9K6ma1RpiGJIqG7tR5Yx0FAGdbSxOG+Ugr1 zSzbTF8ygZ9KpXqbQWRWCHqR0qFri5EtuLRQ8Y+/u9KAIE05bd3l5OecGmTRvCDNEu49MVr/AD3m 7YCqVGIsLsTOB1zQBnAytGuRsz1xUX2Q+YSSXPv0rXnWJIxuYKPWn2qqVIOPrQBjSxugGULA8YFR PZkruweldIvlk4UAn6VAUBYoy49DQB53cQuL0K3UtxWq9iwjBUE5HpV7XNOJ2XCcPGeg71bsLgXc QDAKQMUAYFtE8YIkBLVY2nYducetbE/lW5Pm4JxnNQmMSossPCd1PegCHl7L0+lOsNNa5tx5b5Xu TUyaa+xirOqOOlRaezW9ysMZYAfe4zmgBJT5TbGxuj6nPWt6xxJGCqgjHWqur6clykboMuetV9Ov 3s5Ps0pVABjJFAF9pWW5IORjvVyVmMW5F3P2BNQ3Ue+SNo2BU4JNXmhPyqoGO9AGbHM6ybPL4rQt VW4XKkgCpUgCxseMmktLeSOcucBT2FAFmyWRZGOeOmK0UJPBGMelMTb2GP61YQAjPTNAEZDdmIz3 qaEu5OVwB3z1piYLFRzg1T1q9u7C3jaztjOzMAQO3agDYHXjtS1Fau0kCPIuxmGSKmoAaFAzgYye adUBE/2oEFfJxyO+amPA460ALmjqc0dxVGa9li1CG3WBmRwSZB0FAF4kZo+lGcdRR7UAL1poPz4w aFYEHGRVa4uobCLfPJtUnAJoAtGlpitvUFehGQaXqRQA1YwsjMM5an9KQjKkA4PrVa+knt7J3gTz ZQPlHqaALQINBrM0YTSQfabhWSWXloyc7fatJmwtACnnFBOCKM0frQBCTL9pxgeVjr3zUk//AB6y /wC4f5U6mz/8esv+438qAK0P3D9agvDK7C3jEZEsb535xxgdvr/noZ4fuH60/aNwbA3AYB7/AOeK kZlGW5uDCILkohcAOyDfzGW5wcEYI7fy50LQq1nAUXYpjUhc5wMdM054IpE2PEjLndgqCM+v6mpK YEc33B9a5i51WXR9Dvb23SN5ooLbaJASvOAc4I7Gunm+4PrXOLaXrpFJbq4VoY+Vk25wo9/rWtKP M2r29RMknur27t/tV3GLaGSVfs9sV+eNQrfM5/vNkfL2wO+a5tryKa9aWSRRu/dwgn+HPUe7HOPU KPQ1uXWm6ncW8kWZVLKQrGXO0kYyOfesf/hFtc8ry/tq+Xjbt+zx4x6Yz0reUGociafzRKMXUre7 iNzMpBkLApcFkGxDkbPmI24z1HXNJphuy0ASdp5A585vMZ49mAcEnjeM8bfxrU/4QrUv+etv/wCA kX+NWv8AhGtf/wCgh/5Bj/xrD2UvL71/mO5Xhu44bszRzCTym8q4GR8qk5BOMfdPc9Bu71e1DUJL S4ssBDBNL5L8HcCR8uO2Mjmqx8La4Q4N6pD/AHh9nj+bjHPPPFaLaBdTWC2l1CZ12qrkyAFyMc9c 9RmuuheMXFtLtqiWZ7arcO2nRxCJGvd7h2UsFQDcoIyOcEZ565qu2v3B0myvPKSOOVis8u0usWDg HaCDgn349zitq40K4uTG0tsd0ZJRll2suRg4IINRt4cka2S3FsywopUIk20EHrnDc/jWza1tNff6 f8EDNvNXuorh4oDbSKlkbkyEHDEHsAeh+vfOTjBbf689tZwXUbRZeJJTbFGZsEjPzg4Uc4BI61em 8LTz3omeIiIQeR5SPsGM56hhx2xUtz4ZN0FEtkCFTYAsgX5cggcEcZA4qW97SX3gV47+4uNWuraM xRxW3l7tyFmfcMnByMenQ1S0/X7u5R5Xs2aIx70Mcb/Kd+3aTg7uMEkDseDWwPD0wnEy28iyYUFl nI3bem75vm/HNLb6BPakmC3dAc/IJvkGTk4XOB+Aqrq/xrr1AyNKupLjVNUhmnnkUrHt3K8YXKnO B/D1478ZyetNsmnmbUbmzmmMao0Nqrys4dgOX+YkHnABzjGa3I9EuIriadLbEs2N7eYOcDA702DQ ri3tRbQ2xSIAgAS8jPXnOe9CUNLyXXqBztjNdSXD2cc1ykkmnZbz2cFZs43AtyOvbj8qv2kpj1GS zdZYpzB5iut08ygZx0fgHOOxrSh0CaFZQtru87/WF5A5fjGCSSSMdqI9Anj3Fbdy7KVMjTbnx6Bi cgfQ0oqKt7y+8DIn86H+0ZLa4l+yJaMvzSsxEwzypJJ4HBwevuDjpPCCudHjZJWM0kQffKzSfMU6 4J6Z7Aj8Kz4/DkscTRLBKYmQxlGuCw29MAFuPwrZ0G0XSLaRJcwxIC/7yXcFUL6knAGKwr8vLo19 40TfZNZ/6C9t/wCAB/8AjlQaEqJpgVJTKBNNlzHsyfNbOBk4Gc456Vi2tv4RtdbfUo9QtezRwbxs jfuwH5YHbn2xr+G3WTR1dGDI085DA5BHmvzXAWbrMAm6qjO7tuBwDUznAAJzVZkmW5Lbx5JA+XHS qEPAHmncOveop48njgZq55QcA/limSxBhtZiAPSgDLv7WOaDYgwfWsX+z50jQI20HhjjtXT+WuTk 4FZUpWS4njYkxRsFK5wGbAJz6jBHH1yOlTOSgrsqMXJ2RZhijgtkSIq2Bg1m6haLKrFSY2AySDTm +wIxVobNSOxjT/Ck3ad/zzsv++ErD6wuxt7DzMJ5lEJiOXbPfvWha28zWwKJgnj6CtLybX/n1t/+ /S/4UeTa/wDPrb/9+l/wpfWl2H9XfcNNsTFHmRsk1cFskjH5RVPybX/n1t/+/S/4UeTa/wDPrb/9 +l/wo+tLsH1d9yo9kwDyXA2gNwD6ViLZSpcySRL+7PIHrXTeTa/8+tv/AN+l/wAKPJtf+fW3/wC/ S/4UfWl2D6u+5z5trm+RVKBUB9Ke1q8MYxHyDgHORW75Nr/z62//AH6X/CjybX/n1t/+/S/4UfWl 2D6u+5nRTSXMQjVdr4wDjio7XS5opnaUASN0PrWr5Nr/AM+tv/36X/CjybX/AJ9bf/v0v+FH1pdg +rvuRpBdPIHePCrwR61FrOlR30KyIu2QDH4VZ8m1/wCfW3/79L/hR5Nr/wA+tv8A9+l/wo+tLsH1 d9ylHbFLSGGFNr5HL9Petrym8sdAQKpeTa/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWl2D6u+5PCr MduOAa0Ng2ggc+1ZHk2v/Prb/wDfpf8ACjybX/n1t/8Av0v+FH1pdg+rvubbggKR1FTqf3eRxXO+ Ta/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWl2D6u+50kQ/ixVjaGAyK5PybX/AJ9bf/v0v+FHk2v/ AD62/wD36X/Cj60uwfV33Oux2proWZSHK7TyPWuT8m1/59bf/v0v+FHk2v8Az62//fpf8KPrS7B9 Xfc6+j0rkPJtf+fW3/79L/hR5Nr/AM+tv/36X/Cj60uwfV33Ow6UmBmuQ8m1/wCfW3/79L/hR5Nr /wA+tv8A9+l/wo+tLsH1d9zryenNFch5Nr/z62//AH6X/CjybX/n1t/+/S/4UfWl2D6u+513BPWq uomAoiXERkVmAAxnmueNlEqbzYRBP7xgGP5UzybX/n1t/wDv0v8AhR9ZS6C+rvudag2qAAAoHFOz iuQ8m1/59bf/AL9L/hR5Nr/z62//AH6X/Cj60uw/q77nURSu8sivGUCnAPrUwGeM1yPk2v8Az62/ /fpf8KPJtf8An1t/+/S/4UfWl2D6u+51wwDgUp6VyHk2v/Prb/8Afpf8KPJtf+fW3/79L/hR9aXY Pq77nUWqzqjCdg5JJBAxxU461yHk2v8Az62//fpf8KPJtf8An1t/+/S/4UfWl2D6u+512Rk46imS Z+xS7jk7W/rXKeTa/wDPrb/9+l/wo8m1/wCfW3/79L/hR9aXYPq77nSQ/cP1rM1OS9sV89pf3Lyb VVWXIB57p6BvXqOuOc7ybX/n1t/+/S/4UeTa/wDPrb/9+l/wpfWV2D6u+5siz1bjNxGemcMPbP8A yz/3vzHpzVifUZNRksvPHmxKGY7lCkfL0+T3P5j05oeTa/8APrb/APfpf8KPJtf+fW3/AO/S/wCF P6zHsH1d9zpJvuD61WVAihVyqgYADEACsTybX/n1t/8Av0v+FHk2v/Prb/8Afpf8KX1ldg+rvubm P9pv++jRj/ab/vo1h+Ta/wDPrb/9+l/wo8m1/wCfW3/79L/hR9ZXYPq77m5j/ab/AL6NGP8Aab/v o1h+Ta/8+tv/AN+l/wAKPJtf+fW3/wC/S/4UfWV2D6u+5uY/2m/76NGP9pv++jWH5Nr/AM+tv/36 X/CjybX/AJ9bf/v0v+FH1ldg+rvubTSRqcNLg+hf/wCvSebF/wA9h/38/wDr1jeTa/8APrb/APfp f8KPJtf+fW3/AO/S/wCFH1ldg+rvubPmxf8APYf9/P8A69Hmxf8APYf9/P8A69Y3k2v/AD62/wD3 6X/CjybX/n1t/wDv0v8AhR9ZXYPq77mz5sX/AD2H/fz/AOvR5sX/AD2H/fz/AOvWN5Nr/wA+tv8A 9+l/wo8m1/59bf8A79L/AIUfWV2D6u+5srJGzBVlyScAB+v61N5Mn92X8zWB5Nr/AM+tv/36X/Cm PDblo0S2tQXJG4wqQMAnp36U1iU+gOg+50Xkyf3ZfzNIYnAyRIB6kmuea2t1IDfYgScDNovP/j1H 2a337P8AQt2M4+yLn/0Kn7dE+wZv4/2m/wC+jSgYOeSfc5rn/KWCVRH5SMykrJBH5RBGODgnI5HB 446VsWFybuzjlYAMcq2Om5SQce2QcVcKinoROm4liiiitCC4FVhTXj42nGKmxxUSmRy4ZAAOhz1q hEUMTq5x92neWzNlqV51QqhOGbpinjIBOc0AVbiEtGc9RXMyuy3l5kc+cP8A0XHXVSM7HCg4Ncpd vHHqN6ruqt5wOCf+mcdYYj4Dah8Zq6VY2t1A0k9rBK5fG54wx6Duas32lWCabdMtjahlhcgiJcg4 PtXOrdKmfLu3QE5wkpA/IGla83oyNfSsrDBBnbBH51nHEJRSsy5UG5N3Q4SnHSjzT6VH50H/AD1T 86POh/56p+dcVmdl0SeafSjzT6VH50P/AD1T86POh/56p+dFmF0SeafSjzT6VH50P/PVPzo86H/n qn50WYXRJ5p9KPNPpUfnQ/8APVPzo86H/nqn50WYXRJ5p9KPNPpUfnQ/89U/Ojzof+eqfnRZhdEn mn0o80+lR+dD/wA9U/Ojzof+eqfnRZhdEnmn0o80+lR+dD/z1T86POh/56p+dFmF0SeafSjzT6VH 50P/AD1T86POh/56p+dFmF0SeafSjzT6VH50P/PVPzo86H/nqn50WYXRJ5p9KPNPpUfnQ/8APVPz o86H/nqn50WYXRJ5p9KPNPpUfnQ/89U/Ojzof+eqfnRZhdEnmn0o80+lR+dD/wA9U/Ojzof+eqfn RZhdEnmn0o80+lR+dD/z1T86POh/56p+dFmF0SeafSpbeZVuYjIPkDDd9M1W86H/AJ6p+dHnQ/8A PVPzpq6dxOzNGCN4NYv9QvWP2U7/AN6W+Ro8fKB69uKjha8k0nSXtYI2kl3+axjDHAPGc9vest4r GSTewiL+uadeSR3YtIZHt/s1uGAXud3/AOoV0qrHqjndN9Ga6ywSXOqx2vzvCQIdiCQnP3tqkgMQ c96IrkGa9JtGQxWJlxOig7x32gnGf8ayFWzWIxAx7D1GaasNgqMgEQVuozU+0ja3KP2cu5fubh/s WlSMqeZcLJvKqFzgjHA+tR+afSq4FoHVw0e5BtBz0FSedD/z1T86ym+Z3SNYLlVmyTzT6UeafSo/ Oh/56p+dHnQ/89U/Oosy7ok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR 50P/AD1T86LMLok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T 86LMLok80+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok8 0+lHmn0qPzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok80+lHmn0q Pzof+eqfnR50P/PVPzoswuiTzT6UeafSo/Oh/wCeqfnR50P/AD1T86LMLok80+lHmn0qPzof+eqf nR50P/PVPzoswuiTzT6UxpSJYjjoW/8AQGpPOh/56p+dMkliJVlkjJUk4LYzkEdfxpxvcT2L2lyy PqCgCPYEbzvNI2eVxvzn8Pxx2zU2qSxC2tmsNhsN5553+bg/e3c/d6e3/Aaxy8TY3JCccjM/T/x2 jfFu3bId3TPn8/8AoNbKVo8pk43lzE5mZnhJHZ//AGStnQDnSkP/AE1l/wDRjVhJLGXUs8aBQQAJ N2c49h6VueHyDpKEHI8yX/0Y1aYf4mZ1/hRpUUUV1nKaRHtTWUlcKcUxp8SogViGGdw6CpOc+1UI jaIHtk0bGAxUp9qr38ssVnI8CF5AuVHqaAJAmBVGzGLnUQP+fkf+io6safLLNZRyTpslZclfQ1V0 5nebUGkXa32rp/2yjxQwLtFFFSMKKKKACiiigAooooAKKKxrb+1dQutQFvf29vFbXBhVXtfMJ+RW zneP73p2oA2aKzv7O1v/AKDFr/4An/45R/Z2t/8AQYtf/AE//HKYGjRWd/Z2t/8AQYtf/AE//HKP 7O1v/oMWv/gCf/jlAGjRWd/Z2t/9Bi1/8AT/APHKP7O1v/oMWv8A4An/AOOUAaNFZ39na3/0GLX/ AMAT/wDHKP7O1v8A6DFr/wCAJ/8AjlAGjRWd/Z2t/wDQYtf/AABP/wAco/s7W/8AoMWv/gCf/jlA GjRWd/Z2t/8AQYtf/AE//HKP7O1v/oMWv/gCf/jlAGjRWd/Z2t/9Bi1/8AT/APHKP7O1v/oMWv8A 4An/AOOUAaNFZ39na3/0GLX/AMAT/wDHKP7O1v8A6DFr/wCAJ/8AjlAGjRVO2sdUjuY2utSgmhz8 yJabCePXecflV3I/uj9aAEopcj+6P1pssgjid9gO1ScZPNIBaKqaXcve6VZ3UgVXngSRgvQFlBOP bmrdABRSrjkkZwKiRpHRW/djIz90/wCNMCSim/vPWP8A75P+NNdpERm/dnAz90/40ASUUkj7Vyqr nIHOe5+tJ+89Y/8Avk/40AOopuX9Y/8Avk/40m51ZAwQhjjgEdj70APopkzHYAvykuq5HUZYDvTp H2rlVXOQOc9z9aQC0U3956x/98n/ABo/eesf/fJ/xpgOopm51ZAwQhjjgEdj70TMdgC/KS6rkdRl gO9IB9FJI+1cqq5yBznufrSfvPWP/vk/40wHUVG0hX7zwr9Qf8aBIcocxsrHGVB9D7+1AElFLkf3 R+tGR/dH60gEopcj+6P1oyP7o/WgBKKXI/uj9aMj+6P1oASilyP7o/WjI/uj9aAEopcj+6P1oyP7 o/WgBKKXI/uj9aMj+6P1oASilyP7o/WqmnXL3du8kiqpWeaMBc4wkjKP0UUAWqwbCGFrd2eCB2M8 3LRqSf3jdyK3qxNO/wCPV+/7+b/0Y1a0km9RMn+zW/8Az62//flf8KQwW+f+PW2/78r/AIVL271k 3UWsm4f7JPaLBxtEiMW6dzmujlj2JN2+F6bi3+ybPKDfvM+ntV/nFL0xxRXIUU727lt3iEUDSh22 nH8PvVzOV5ox69aRs44GTQAoxis61/4+9R/6+R/6KjrQVg3QjIrPtf8Aj71L/r5H/oqOhgWqp2U0 kt1qCO2VhuAiDHQeVG2PzY/nVys02V9Fd3Utrd2yJcSCQrLbs5BCKvUOP7vpSGSpqSPIo8mZYXO1 JyBsY9sc557EjB/EUJqSPIo8mZYXO1JyBsY9sc557EjB/EVDDpkkaQ273CvZQFTHF5eG+U5UFs8g EDsOgoh0ySNIbd7hXsoCpji8vDfKcqC2eQCB2HQUAGmah9oLQuWlmE0wbaBiNVldVz+AAHc/mat3 MyxT2iFnBmlKAKBgnYzYbPb5e3OQO2arW2li1k82GXbK0sjyHbxIrOzbSM9RuwD/AEOKs3Nt589p Jv2/Z5TJjGd2UZce33s/hQBWg1aKe5WIQTqGlkgWRlAUum7IHOeik5xj8eKuyS+W8S+W7eY+3KjI X5Sct6DjH1IqnHpvl/Zv3ufIupbn7vXf5ny9e3mdfb3q5IkjPEUl2Kr5ddud42kY9uSDn2x3oAkq h4e/1+s/9f5/9FR1frL0ZpFXXmgTfKLxii5xubyY8ChAXV1ERQSTy75BJcNFBHGuWbHy4HrnazZP Y+lSw6gHliiltp7eSQsAJQvUAHGQSDkEkYz0PpTH03/QLSCKYxy2m1opcbsMFKkkd8gkH61FfwXf 9mMzSrPepIskLRxFVDZAAxknaeQST0JpiJP7WiN8lrHBPI7s6hlA2/IUDHJPQF8fVSPTMX25nksP JkkKS300EnmKuSFWbjjsGQY74Az3qe201bee0kWQn7PBJEcjly7ISxPrlD+dNi0vy/s377PkXc1z 9372/wAz5evbzOvt70AaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUANbqv1/pWVqhv1sXbTBA1yvIS YHa49MgjB9+n8xqt1X6/0qtSYzziDxt4guL5bKKwtWuWfZ5XluGBHUHLcY756V3gFwNLb7Y0TXHl neYgQmcdskn/AD26U9LK2jvpL1IEW5lQI8oHzEDoP8+g9BT7r/j1m/3G/lSAp+Hv+Rd0v/r0i/8A QBWjWd4e/wCRd0v/AK9Iv/QBWjQAq9G+n9ajh/1Mf+6P5VIvRvp/Wo4f9TH/ALo/lTAymkl/tQRi XEm/buxxjbuxitWb/Uyf7p/lWSba6/t8TeSfs4k3eZuXGPK29M56+1a03+pk/wB0/wAqiCtczgrX CX7g/wB5f5iqGo3cgf7LAG8xupHXnsP8e1X5fuD/AHl/mKpXbXYvYWitBIkbZ3hlyQRg9SPWiabV kaqSi7tFCRZ9GCThVMZwH28D6H+hrWhuEuobeePOyQ5GRg9DWNBYXUFtJCLQt5uzdymPlJPPPOeP 1rZgaV4YDPEIZNxygIOODjp7UoxUXZbA582+5YKhsZzgMG49jmmy/cH+8v8AMU+mS/cH+8v8xWgh rFjI4G8hVU4QDvn2PpTgHBALYz/eC5/n/SmSLKJGaIIdwA+ZiMYz7H1rLu0dbkm7tXnhaMhREC+1 ue236c4rllzqRbaUbmoH8xYH6bjn/wAdNSlQ2M5wGDcexzVLT0ljsrZJgwYM2AxyQvzbQfoMVero jsrkbjJfuD/eX+YrP1PUXs5EVUL7s/xYxgD2PrWhL9wf7y/zFZ2qWgkKyEMx3cbQxK5Az9057ela Rtf3hSvbQoNqTyIxJMW0jkuMEEN/s+1a9q26GM/9NZP5tWVb6dcOWeNECh/+WhdGbAOPvA8fMfxr WtYXghiSTbv8x2O05AyWPXA9aJNN6bCjfqW6KKKgoKKKKACiiigAooooAKKKKACiiigArO0P/jxl /wCvu5/9HvWjWdof/HjL/wBfdz/6PegDRrDsObOUbin76bDccfvG5rcrD08BraRWUFTNNnPIP7xq 2pfEJloAKSwX5m5OO9OpOcjgY9aBg+9dBJsHntR6Udjg1XaOaWHaX8t8/eWuMosetA6035gnHLe9 OGe9ACbQCSByaz7X/j71H/r5H/oqOtLtWba/8fWo/wDXyP8A0VHQwLVFFFSMKKKKACiiigAooooA KhsrZLNrlkZybmYzPkjAO0Lgceij9amooAk80+/6f4Ueaff9P8KjopgSeaff9P8ACjzT7/p/hUdF AEnmn3/T/CjzT7/p/hUdFAEnmn3/AE/wo80+/wCn+FR0UASeaff9P8KPNPv+n+FR0UASeaff9P8A CjzT7/p/hUdFAEnmn3/T/CjzT7/p/hUdFAEnmn3/AE/wo80+/wCn+FR0UASebyCQTj3rFNrrRJI1 W0HsLI8f+RK1qKAMn7Jrf/QWtf8AwCP/AMcpGstZdCraralWGCPsR/8Ajla9FICtp9r9i061tN+/ yIki3Yxu2gDOO3SrNFFAEc4mMDrbvHHKcbWkQuo57gEZ/Os5bXWVUAanZ4AwP9Cb/wCOVq0UwMv7 NrX/AEE7P/wCb/45SNa6yykHU7PBGD/oTf8AxytWigDMe31d1x9vsRyDkWT/APx2k+za1/0E7P8A 8Am/+OVqUUAZf2bWv+gnZ/8AgE3/AMcoFrrG4E6jZNg5ANk3/wAcrUooAzvJ1j/n+sP/AACf/wCO 017fV3XH2+xHIORZP/8AHa06KAMv7NrX/QTs/wDwCb/45R9m1r/oJ2f/AIBN/wDHK1KKAMsWusbg TqNk2DkA2Tf/AByn+TrH/P8AWH/gE/8A8drRooAzHt9Xdcfb7Ecg5Fk//wAdpPs2tf8AQTs//AJv /jlalFAGX9m1r/oJ2f8A4BN/8coFrrG4E6jZNg5ANk3/AMcrUooAzvJ1j/n+sP8AwCf/AOO0eTrH /P8AWH/gE/8A8drRopAZ3k6x/wA/1h/4BP8A/HaPJ1j/AJ/rD/wCf/47WjRQBneTrH/P9Yf+AT// AB2jydY/5/rD/wAAn/8AjtaNFAGd5Osf8/1h/wCAT/8Ax2jydY/5/rD/AMAn/wDjtaNFAGd5Osf8 /wBYf+AT/wDx2jydY/5/rD/wCf8A+O1o0UAZ3k6x/wA/1h/4BP8A/HaPJ1j/AJ/rD/wCf/47WjRQ BneTrH/P9Yf+AT//AB2ptNtXs7TypJVlkMkkjOqbQS7s5wMnH3sdat0UAFYmnf8AHu//AF3m/wDR jVt1iab/AMez/wDXeb/0Y1bUviEy1S5xTGdEZFJALZCj174p30P6V0EmxR29qOp4o7VxlBwKRjjm hiAOelGBj2oAAcgelZ9r/wAfWo/9fI/9FR1ojCjgVnWn/H1qP/XyP/RUdDAtUUVm29pBcSXTzKzM J2UfvGGBgHsfc0hmlRVT+zbT/nk3/f1/8aP7NtP+eTf9/X/xoAt0VU/s20/55N/39f8AxqnYQW11 Lfq0G0W9yYVxLJyAiNk/N1yx/SgDXoqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zy b/v6/wDjR/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/ AL+v/jR/Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6 /wDjR/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v /jR/Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDj R/Ztp/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/ Ztp/zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Zt p/zyb/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/ zyb/AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zy b/v6/wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/ AL+v/jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zyb/v6 /wDjQBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/AL+v /jQBboqp/Ztp/wA8m/7+v/jR/Ztp/wA8m/7+v/jQBboqp/Ztp/zyb/v6/wDjR/Ztp/zyb/v6/wDj QBboqp/Ztp/zyb/v6/8AjR/Ztp/zyb/v6/8AjQBboqp/Ztp/zyb/AL+v/jR/Ztp/zyb/AL+v/jQB borH1SG3soIXjgy0lxFD80r8BnCk/e64JrWSCO3jRIl2rjPUk/maAHViad/x7P8A9d5v/RjVt1ia d/x7P/13m/8ARjVrS+ITLPylhnBYcjPanc9qTcN2OM0hRCclFJ9SK6CTZ796CMg0DletHtXGUNVM LjOQPWndBxQScVl2V7dTajcQy2xSFPuOT97/ADxQBoyZMZAbax6Gs+xDLPqAY5YXAyf+2UdaXBHN Z9p/x9aj/wBfI/8ARUdDAtVUsOt3/wBfLf8AoK1bqpYdbv8A6+W/9BWkMpW8V3/bEsD6pdPFDFFL tZIvmLM4IOE6fIOmDyea2KrpbbNQmut+fNijj246bS5zn33/AKULFcDy91zu2yu7/ux86HdtT2xl ee+33oAsVlaL/r9Y/wCv9v8A0VFWjCkiIRLL5rb2IbbjALEgfgMDPfGaztF/1+sf9f7f+ioqQC6X eTSNIt0wYPPMsLYA4SRl2/UAA+/PpUdhqznTtPkuYZ2M0cIe4CqE3uFx3B5LDoMc1bisAlm8HmEs ZZJlcDBVmdnH5Zx7/jWWPDTKkAFzEzQLD5cklvuZGjC42ndwpK5IHPJ5pgXp9Zhgnmja3uWWCRYp JFQFQzBSo65OdwHA6/nUiapE0TM0UySrL5PksBvL7QwAwcfdIPXp1pJNN8z7T+9x591Fc/d6bPL+ Xr38vr7+1RXeixXYuPNZHMlwtwgkjDqpEapgg/eGAfTr7ZoAu2l0t0jkI8bo2x43xuQ4BwcEjoQe D3qxVPTbP7DbtFttVy5bFtB5K9B1GTzx1+lXKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQBk+If+PWz/wCv62/9GrWxJ/D/ALorH8Q/8etn/wBf1t/6NWtiT+H/AHRT AbWJpv8Ax7P/ANd5v/RjVt1iad/x7P8A9d5v/RjVrS+ITLQHufxpaa27Hy4zkdemKd+VdBJrUvfm jqM0ySEO6MWPynsa4yh/UUmMGlB9qB1oARkDDB6Vn2vF1qI/6eR/6JjrRrOtf+PvUf8Ar5H/AKKj oYFqsN7q9hN2LG3gl2zs8rTzeWFG1cdj6H0xitysNv8AUa5/ut/6CaS1dhvQY1/rqqWay00KBkk3 ZwP/AB2nrd+IHRWTT9PZWGQRdEgj/vmt8Qxz2SRyruRkGR/nofes6xWS3uru0d/MWNhKj9yHyTn3 yCc+/bpT5VYnm1KX2nxF/wBA2w/8Cm/+JqG0TW7SO5dLG0aa5uWmYG5IVRsRQAdvJyp9Mcda6Gs/ Wi39nhVd033ECExuVbDSoCMjkcEipKKn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1P5R0++s1h mneK4do3SWVpMYRmDAsSR93HXvVazWdVuLczXCar5Df61y0Tt2kQcgAHsMYzyOlADvtPiL/oG2H/ AIFN/wDE0fafEX/QNsP/AAKb/wCJqSwSOaK5txLfQyrtEqSzFnT3VjnhvUHHHGDU2mKVln8p5Xs8 L5RlkZyW53EFiSV+7j6HHFAFX7T4i/6Bth/4FN/8TR9p8Rf9A2w/8Cm/+JqII1zrF+kkOoyotwiC SG7MccY8uM42iRT1JPAPXvUVnKZZysMl4bw3su5neTyvLWYggbjtPycYXocdMUAWvtPiL/oG2H/g U3/xNH2nxF/0DbD/AMCm/wDiau6sk726eSJWRX3SpC+x3TB4U5GDnB6joRWVPIs82nLb/wBoXdu0 E7bYrgxvkPGPmJZc7ckYJzQBY+0+Iv8AoG2H/gU3/wATR9p8Rf8AQNsP/Apv/iaqzPDBqDRTf2kF FrEY41nlYqzPJncwYrnoMscccHAq7HHPdXEdneTyAwWsby+TIY/MkYsCcrg4Gw8D1oAZ9p8Rf9A2 w/8AApv/AImj7T4i/wCgbYf+BTf/ABNa8MfkxLHveTb/ABOcn8TXM2ZkHhO4vMX8Vx/Z5YTTXRcO xjzuUbzjkZ6A8/WgC/8AafEX/QNsP/Apv/iaPtPiL/oG2H/gU3/xNP1S0R9QsG826Tz7gpII7qRF IETnGAwA5UHim6kn2eaN55btLFI1RZIpWzE2Tln5ywxt5ORwc9c0AJ9p8Rf9A2w/8Cm/+Jo+0+Iv +gbYf+BTf/E1t0UAYn2nxF/0DbD/AMCm/wDiaPtPiL/oG2H/AIFN/wDE1t0UAYn2nxF/0DbD/wAC m/8AiaPtPiL/AKBth/4FN/8AE1t0UAYn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2nx F/0DbD/wKb/4mj7T4i/6Bth/4FN/8TW3RQBifafEX/QNsP8AwKb/AOJo+0+Iv+gbYf8AgU3/AMTW 3RQBifafEX/QNsP/AAKb/wCJo+0+Iv8AoG2H/gU3/wATW3RQBifafEX/AEDbD/wKb/4mj7T4i/6B th/4FN/8TW3RQBifafEX/QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAGJ9p8Rf9A2w/wDApv8A4mj7 T4i/6Bth/wCBTf8AxNbdFAGJ9p8Rf9A2w/8AApv/AImj7T4i/wCgbYf+BTf/ABNbdFAGJ9p8Rf8A QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAGJ9p8Rf9A2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2n xF/0DbD/AMCm/wDiaPtPiL/oG2H/AIFN/wDE1t0UAYn2nxF/0DbD/wACm/8AiaPtPiL/AKBth/4F N/8AE1t0UAYn2nxF/wBA2w/8Cm/+Jo+0+Iv+gbYf+BTf/E1t0UAYn2nxF/0DbD/wKb/4mj7T4i/6 Bth/4FN/8TW3RQBifafEX/QNsP8AwKb/AOJo+0+Iv+gbYf8AgU3/AMTW3RQBifafEX/QNsP/AAKb /wCJo+0+Iv8AoG2H/gU3/wATW3RQBifafEX/AEDbD/wKb/4mj7T4i/6Bth/4FN/8TW3RQBifafEX /QNsP/Apv/iaPtPiL/oG2H/gU3/xNbdFAHO3UeuXxt47ixtI4o7iKZmjuCzYRwxwCo9PWukfOEyC DtHB7U2pJvvj6UwI6xdN/wCPZ/8ArvN/6Matque0oTj7QXaMwGaTywAQw/eNnJ71rS+ITLgkVrlo 8SBkUHJBCnPv0J4qXmimNJGrYZlB9Ca6CTapGZVxkdfelx3prxrJtLgHByK4yhRg9KdwR1o+lIRx zQAVnWv/AB96j/18j/0VHWj2rOtf+PrUf+vkf+io6GBarFVRIusx70TfldznAGVPJ9q2qwJv9VrP 0b/0E1LdtSrXNxbsRQjcYgqLyxkwOO/SoIhvvZrrfGY5o4wu1s9N3P6irohjnskjlXcjIMj/AD0P vWRbJJbXl1aO/mBCJEfuQ+Sc++QT+PbpTqScYtomCvJJmnuX1H51XvbZb22MJleP50cPHjKlWDA8 gjqvcUVQ1rd/ZoCu6b7iBC0bFWw0qgjI5GQSOtcqrtu1jd0kkXYLLypRLNcTXMiAhWlCjbnrgKoH amRaasbs73NzK/ltEjOwzGp6gEAHsOTk8daoeUdPvrNYZp3iuHaN0llaTGEZgwLEkfdx171Ws1nV bi3M1wmq+Qf9a5aJ27SIOQAD2GMZ5HSq9t5C9maraSrQXCPdXLSThVeY7N+1SSFxt24+925yalSy lWNklv7qX5kYFtildrZx8qjg4wc9s1l2CRzRXNuJb6GVdolSWYs6e6sc8N6g444wam0xSss/lPK9 nhfKMsjOS3O4gsSSv3cfQ44pOv5B7MtPpr/aZ5odQurfz3DuiCMrkKFz8yE9FHftUo0+JbfyQ0gx M8yvkblZmZjjj1JH04OaxbdWn1298yO+dYrhQsiXJWJAIkbaUDjPJP8ACRz9am111T+z1ke5WJ7k q4tzIHYeVIQPk+Y8gHj0p+21tYPZmq9mxg8tbq5jYSNIJAwLDJJxyCCBkgAjgAelV20hVMDQXVzb vCsi702EvvYMxbcpGSVzxjvWTbiaW5WyaS6S0kMksZd2WUoojG0sfmHzMx9cAVK6XKm9sLaWV9iR SoWkJcKzMGQMec4Q4J6butHtvIPZmvDYLG8rzSyXLyxLFIZQvzKpc8gAD+Mj8PrTX00ERFLm4imi UoJlKlivocgg9O4z+tZHM2mj7G168ccx8+FpSJwAvKBic5ztPXkdDgipLOdXvtPFvPNJbvbTt+8Y 5JDxj5s9xkjnnrR7Z9g9n5mzFa+U0TGedzGjKd75DZIOT7jacegJqP8As6L+x/7M3SeR9n+z7sjd t27c9MZx7VU0R3l0PT5JGZ3e2jZmY5JJUZJNYdmZB4TuLzF/Fcf2eWE010XDsY87lG845GegPP1o VZ9g9mdbPbJNLbyOWBt5DIuO52svP4MfyqG9sBeEiSedImXZJEpG2Recg5GR36EVlapaI+oWDebd J59wUkEd1IikCJzjAYAcqDxTdRT7PNG88t2likaoskUrZibJyz85YY28nI4OeuaPbeQezOjoqtRU /WPIr2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5 lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9 Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZ oqtRR9Y8g9l5lmiq1FH1jyD2XmWaKrUUfWPIPZeZZoqtRR9Y8g9l5lmpJvvj6VTX74+tXJvvj6Vr Tqc6ZnOPKR1g2Kl7SVQzJmaYBh1/1jVvViad/wAez/8AXeXp/wBdGrqpfEZstcggfw46k80HGen6 UAhhkEEZxTsV0EmqeFJ6mmpIGXoQKeAKMYNcZQdzR3qCW6WOQxgEuBnGOKkRcDOSc+tAEM92sFxF EysTIcAgZxVe1/4+tR/6+R/6KjrQK5xntVC1/wCPvUf+vkf+iY6GBZrE8ozDV03omcjc5wBlTyT6 Vt1ht/qNc/3W/wDQTU2voO9tTZW7EUI3GIKi8sZMDjv0qssTS3st0GjMc0aBdrZ6bufpyKviGOey SOVdyMgyP89D71nWKyW91d2jv5ixsJUfuQ+Sc++QTn37dKuUVKLRMW00yx5TeoqC8sBe2pgeV4vn Rw8eNylWDDqCOoFXao6u7x2cbRsyE3MC5U44MqAj8QSK51RijV1GJb6b5cqyzXU1zIoIVpQo25xn AUAf596ZFpCo7O91cyuYzGjOwzGpxkKQAew5OTwOasXcwiuLFCrEyzFAQ5XH7t2yR3+70PrntVS3 1WWW5jV7UJDJcS26yeZklk384x0IQ9+vbvT9lEOdg2iK8E6PeXLSThVeY7N+1TkLjbtxy3bnJ9ak j02RYykuo3UuWRgSEUrtYHA2qOD0Oe3pmodHv2neW3G6V4p5/Ndm+4vmuFA9eB06AD6CkGsXLOoS wBWS4ktoz5wBZkL8kY4XCHnr7HrR7KIc7LsFikEtxIrsTcSCRs9jtVePwWo/7MQtAzzSuYJnmUsc 8sGGPoA5AHsKZHfiYWLNEyvLcyQECQ4VkWQH/eGUPX1B6in2V7cXnlTLaKtnKNySGX58YyCVxwD9 SeelHsoh7RjrrT1ugh82SKSM5SSPG5fXrkH6EY6VHHpSpBKguZ/NlILz5G8kYx2x+GMe3JqjpOrS R6ZaG+jKr9g+0ecZN7OEVdxYY4J3Ajk574qO511LrTtRjhkhEq2Us0bW9yJCuF/ix91gSPX68Uey iHOzRXSQkDIl5cpK8nmPONu9mwByMbegxjGOBTrfSYbeWGRHfdEkic87t7KzE++Vz+J/DQoo9lEO dlC10xLWO1jjml2W0PkqpPDD5eSO5G3r7n1pv9kw/wBj/wBmeZJ5H2f7Pu43bdu3PpnHtWjRR7KI c7Kk1ik8tvI7sDBJ5i47kqV5/Bj+QqK80tbwkSXM6RMuySJCNsi9wcjPc9CK0KKPZRDnkReV/tfp R5X+1+lS0UvYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv 9r9Kloo9jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8A a/SpaKPYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv9r9K loo9jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8Aa/Sp aKPYwD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIi8r/a/Sjyv9r9Kloo9 jAPaSIvK/wBr9KPK/wBr9Kloo9jAPaSIvK/2v0o8r/a/SpaKPYwD2kiLyv8Aa/Sjyv8Aa/SpaKPY wD2kiLyv9r9KPK/2v0qWij2MA9pIi8r/AGv0o8r/AGv0qWij2MA9pIjWPBB3dKsTffH0qOpJvvj6 VcYKOxMpN7kdYemgi2kPJzPNgf8AbRq3KxNO/wCPZ/8ArvN/6Mauil8RLLY6Aml/GmbVMgYgFgCA ccgd/wCQp2K6CTXPAzQOmTQDTW6cVxlC4U84p2KjjUomGYsfWn0AFZ1r/wAfeo/9fI/9FR1on0rO tf8Aj71H/r5H/oqOhgWqxkTzF1mPcqbsruY4Ayp5J9K2aw2/1Guf7rf+gmktwexsrdiKEbjEFReW MmBx36VDEhe9mugUMc0cYXa2em7n6cirghjnskjlXcjIMj/PQ+9Z1islvdXdo7+YsbCVH7kPknPv kE59+3Sr6Mnqi9Ve+tVvbYwtI8Xzo4ePG5SrBgeQR1A7VYqrqEwgt0cqzAzRJhXK/ekVc5H16d+n esyyNNPYSwyT3tzcmGTzE8wRjB2sv8Kjsx/Ifi5NOhTyMM/7m4kuFyRyz78g8dP3h/SojqExmvlS 2Ty7Rgm9pgu4lUb04ADHJ9uM54gi1sSaZdXSxxSG3kEbeTNvjPCnIcDoA3Jxxg0wLcWmwxMjRs6y LI8gcEZO9yzKeOVyen0780qadCnkYZ/3NxJcLkjln35B46fvD+lS2kzT2scr+Vlxn9zJ5iY7YbAz x7ViWUtwIJb29Ri7XggUR3khX/j42fdwAAMDt8wznGSKANZNOhTyMM/7m4kuFyRyz78g8dP3h/Sk ttPW1kXy7i48lc7ICw2L9OM49icCoItQvPN1My2sTQ2bEJ5UhMj4RWA2kYyQ3r14weps6bdte2on YQYY/L5MpkGPclRg9eMUAMi0q3jitozvdLe2a1CsQQyHbnPHX5B+Zpp0svbT20t7dSwTRNDscodo IxkHbnOPUmtCigAooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVJN98fSo6 km++PpTAjrE04f6M/wD13m/9GNW3WHp5ItZCBuImm4/7aNWtL4hMuUY96aXUNt3Dd1xnmkjEgT5y pbJ+6OMZ4/Sugk2RkDk5pCSvbP0p2aM4rjKGjdu6DFPNJnB60GgBT0rNtf8Aj71H/r5H/oqOtIkD k1m2pzdaif8Ap5H/AKKjoYFqsZE8xdZj3Km7K7mOAMqeSfStmsNv9Rrn+63/AKCaS3B7Gyt2IoRu MQVF5YyYHHfpUMSF72a6BQxzRxhdrZ6bufpyKuCGOeySOVdyMgyP89D71nWKyW91d2jv5ixsJUfu Q+Sc++QTn37dKvoyeqL1Q3Vul1EschYASJJ8vqrBh+oFTVV1CYQW6OVZgZokwrlfvSKucj69O/Tv WZYybTIZortGaQC5kWViCPlZQoGOP9gHnPemxacYUuPLvbkSXDK7SfIWDAAZGVxyAB0xxximnUJj NfKlsnl2jBN7TBdxKo3pwAGOT7cZzxBFrYk0y6uljikNvII28mbfGeFOQ4HQBuTjjBpgXbewS3hg jjklCwu0n3seYW3Z3YHIyxOOOQPSk/s6H7L9n3Ps+0faM5Gd3m+Zjp03fp+dNOL3TkkuJhCh+dmt rg7SvP8AGADjGDxil0xZFhl3mQwmT9x5pJfZgdSeeu4884IoAcLLZc3M0VxNGbgfMq7SA2AocZB5 wB7e1OsrNbNJAJHleV/Md3xlmwBngAdAOgrGspbgQS3t6jF2vBAojvJCv/Hxs+7gAAYHb5hnOMkV ei1C883UzLaxNDZsQnlSEyPhFYDaRjJDevXjB6kA1KKqabdte2onYQYY/L5MpkGPclRg9eMVbpAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFSTffH0qOpJvvj6UwI6xNN/49 n/67zf8Aoxq26xNO/wCPZ/8ArvN/6MataXxCZb7UUfXrSEHP3iPpXQSWhcSjps/75P8AjS/aZv8A Y/75P+NFFcRRXlWaSeOQTsmz+FR8rfXNTtPM2PmVcHPC/wD16KKAAzynOdnP+yf8ag04lpb8nGft I6f9co6KKBl6seKJrj+2IUIDSZQE9MlSKKKFuJ7GzHK6RquxTtAGd3/1qrpE/wBvnuG2hZERQAck Fd2f5iiirezJW5PUN1bpdRLHIWAEiSfL6qwYfqBRRWZZBNpkM0V2jNIBcyLKxBHysoUDHH+wDznv TYtOMKXHl3tyJLhldpPkLBgAMjK45AA6Y44xRRQAjaUn2KK2iuJ4RHJ5u9dpLMSScgqR1OenUDHS porR0EfmXlzMY5C+W2ru+UrtIVQCOc/UCiigBv8AZ0P2X7PufZ9o+0ZyM7vN8zHTpu/T86UWWy5u ZoriaM3A+ZV2kBsBQ4yDzgD29qKKAHWVmtmkgEjyvK/mO74yzYAzwAOgHQVZoooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKkm++PpRRTAjrnrGwhnhkkczZM82dtxKo/1j dlYD9KKKcZyi7xdgZYGlwf3rj/wKn/8Ai6X+y7f1uP8AwLn/APi6KK09vV/mf3isj//ZCmVuZHN0 cmVhbQplbmRvYmoKNTIgMCBvYmoKPDwvU3VidHlwZS9JbWFnZQovQ29sb3JTcGFjZS9EZXZpY2VS R0IKL1dpZHRoIDU2MQovSGVpZ2h0IDMzMwovQml0c1BlckNvbXBvbmVudCA4Ci9GaWx0ZXIvRmxh dGVEZWNvZGUKL0RlY29kZVBhcm1zPDwvUHJlZGljdG9yIDE1Ci9Db2x1bW5zIDU2MQovQ29sb3Jz IDM+Pi9MZW5ndGggMTI3ODM+PnN0cmVhbQp4nO3dCWAMZ+PH8ZndRCIXIRJHFImzr6KEKqWukMN9 VlVdEddL6aEHWq06ql5taSmCKkrrVupsHS3VHKV60BKibhI5JZFkd99nd2JtZnZmZ2dndjbJ7/P/ d7s7meMZbzpfs8csbTAYKAAAABdAo0kAAOAi0CQAAHAVvE0aFdXSyUMBACir1n73q9pDKB2sNGly v9Y5D3TzXh3tXdGD1rqrMiwAgLLBoCu8n/fgrUVrfDy0S3ckqD0cV8duEjk9emfysMq+Xvr8LF1e pj4/U62RAQCUAbSbB+3mqa1YKeNm8pxNiQ3a4IRJSIkmkSD9740xuvxMfV4GCZKKwwIAcBEr9551 cA2x0c3IrZtv0I2rlz/Z/SeyJKBEk4Z0a/HZzNGF91IQJAAAYtW+P7r3HvTk46GS13D6r+SDu7eM jWxK7ucVFM3c+FvzZ87IN8Cy5lGTurRpsnl+rC4voyAtRdUhAQC4irj9f02f/lpeys+S11Cx7tML F34YE/E4ZWqSXk/9d/Wv3aLOyTfGMqVEkzbNHZN/65y+MF/dMQEAuIjVB8+/+srL95N/krwG79Bn Fv1v8ZjujZmHuQ+KJq89iybxedSkVv8J3bM49v6/7Cc6lx7N1HhUtLkiX13asHbVtRpa/jFC+UD7 tvJv3d/vsfpu7hRVmJr/7w/pCbvvZxeqPS4o19Yc+uflaVOz/zlqOfGPlLTfU9LInaGdGponbjr6 D7l9om7VpnWrWs7s27DT4o8+Hh1ePCdp0qjlZwYMSlZ65KVUiSbt/jAm50oia46pR/xv5lawuSL/ 9PiPBwd7VtDKP0YoB2i/8FqDx3tTv51YOHP54VuGpsNf+3BKC0P8rxs+9C7Sqz06KL/Wfn9h2ktT Ms9/bznx6+PJs9bHkztzhrcZ0jHU6hSzSo27fvTJklFdGzAPSZNiVv2BJvEp0aSdH4zKSWG/ff6E Z68e3bvTGiPa+K+Hd0v+e/4b4wfUS0eTQBIfn8i42qEVLrzfdcLeew2CPWtW1Hq0/vSVya0eHJmy 5seUrtXb1ol9y4u6lHryglezLl4+7lR+StavK2+d/lPH/P5q/L1bjg1s3tazopZ68G/2mdW3ks4Y W1bhqYcLJns371LRW2vI/i3tyP/u/ot38YAoX/yQ/NLkSel/HrScuOVEyuxNp5n7s4c+aby1eDio fV3Lmf3/0/2TpZ+N7FIcKtKk2DXn0SQ+JZq0ff6L2ZfjWXP84tNfTJPmTY/tWycVTQIp3P9Ta/RC f8/zS/oMPEZ5tfCv0DjEu3aVqND/vlQtc/vLwz5o1y06curb3hR1/8TCnTv3nrhYvcmrcZPbe1/b PubGv3e86AqeT31cv22dB7/MnDX7SP6A1UtiGt/cFXPl8k0fz7b1xs8iC6Z998bOg6f+rvL6rLcj fdM2rft4XcsALZ5oBpu+PHp58sTxqWf3saZvP3V1zpY/WBNnDWrav21t1sSAZpFLl33+Yqd6zMPc B7oJ6y6gSXxKNGnb+8OyLv3CmiOh0uCIyIji9JhLZBko0525r43tHXzL0x1NAvt5PFVv4nu+msTZ 3UbcqubbItSvnT9NeXaoN2mmr+7EjIiJhc16z/rfHF/q8prBfTanurWr4+ERMHz0hxODUje+8cqK vi1bNhj7cVWvlDWDe2/JcA9r2Df201m10za9MXV57zZdmk2e7UOdX9p34N4cj2caRwz/dG4dw6mZ EROqP1WtYyVUCWxYf+zKpAlj75zew/3RzoQb83b8bX74Vr9GfVvX5M4W+GTPz5avGv5sHeYhadKk jZfRJD4lmvTVrAEZF06w5vij5ujIyMiHMSquEm36P8sp7708qkdAiqe7xum7AKWfe/OQKcuqeZHz pCEXfbw6hmpqu1N05QH/mfyyd+b2l3q/QzeJevvzD6pQie92G3G1qm+ov6ZlnS6t3nw/QP/zjIjx FVr2mDp/IbsvJDw9xmlbRr6yYIEfFf9219F3An1Caj0bs4isJ35WlzHZtX2iQjSV8AsLgjadvDF2 3Pir8bu4P9p35vYn3z1Ky0tRoZEtgriz1W7TZ9WKz4e2K85VXoHule130SQ+JZq06W3SpJOsOX6v MSoqMorWFkeIE6fi86T3po3qUQ1NAmn8Kvff1vDxCmfeDV95Pi+qiTZQo6nQbEnz3i3yj0x4bsbJ Bk9EvLnig6rG86T+Z9w924VqQ2uMaDphbMXUryb1n+/eqO2rH60K9vn7074Dtt/QWazWrVnLqHc+ /8DfFKGsGj4dmnbq/uZ8P+ZhTZ/uDbTVcGIPgr46QZo07lr8Ttb0787csQwSg2QpqkUga2Jwm76r Vqx4vv2jJr287Q6axKdEkza/M8hak0ZGRUU9SpGGFafif5vOk66gSSANXalPwNhX6upOfbVggVeF /JCQgXUHxvgZfv74+XHfZVRo16jrlGXk/Ia6f2L+J+sONG/UsGnvxXUaeF9a1mvChqvNQyv1HBHX oVvDjIOzPt1y1E1TpVqTzk92Cvl7+bxL9LMTPicxexihZp07Tp/na37Y0D0QTQJBX524PjY29lpC iSZ9d/rOxw+DNDXK+OYFy4dRT5bIUnDrvqtWrny+fS3mYS5p0tZbaBKfkk2aPTjzIqdJ1Us2qfiF pUdP3jHnS+9OGxkR+C+aBBIZ6PTcVhmdR3Zq/0Q1T4oqvJv1544v31+245quUV3v2sGdJy0i5zfn vlz6Z9jzfR+v6kblXbq4Zc705af0VXxbBrm3C62cExRTPzqiaY2KpFz5V45fOrDq672XG7eP6jl9 7sMI+fZo3rnDaxYPG6NJYMPGn67Fjo29XrJJe0/f+cgUoWlRodGmAnGnmNVq3XflqpXDnglmHpIm TfvmJprEp0STvnl3SOZF9iU0zgaNiIqO4r6SVHzn4eN3p42KDLyC9ziAZPrCotMX8uKv51+7r3ug pyittoqPe+2AClU8tE2bdO72OtOS0Te8tPcyCjILyAyaoKpeDatoqwZ6tAvQ5KXnHzif+1dqQYbx U7Z0FX+PelUr1K/sXq9a4Rf7sm5Rbk809I1o4hFUlLtor8VD/MKCoA0/XY0dO5bVpH9u3r9w6z65 Y5kfkiVy26C6d8Ma3pYzm5q06oVnit+PR5r00tfX0SQ+JZq05b3nMpPZTfo8wVAlwPjCHWnSw1vm LmU5Me3KX8Pb+HrgPAkcoC/U/3un4HKWIV9nMH1QlvbxdWtcwz3It32Dl+b4FJ/feId4UrmFlPGT SRpNYIB7s2paD/JraDBkZhadv1OUXmhgPrTk4amtG1ihnrf+j+SCmwUGHaUJa+IZROt+u2jxEE0C QRt+vBobE3Mjkf16kng1w/qujIt7ocOjJk3ZdA1N4lOySXOGZiWfYs1RUKTX6W1/Pzppk4eblsZ7 a0EJHu3qT3nvYZP8oppWREvAOdYf/3dczBgHm7QibvXwjo8xD0mTJn/1L5rEh/X5pOezktmfTwJw CQ9yFuxKNz3n5hf9hHd1NAmcYv3xK+0692gaWkvyGv5Ivn7yyIHhHS0+n/RVCprEp2ST5g7L5nxm FsAl6At/PZ93w/icm9tTaBI40YoDf9ueSdC4Ho3M90mTJm7AZ2Z5lby20LzhaBIAgHKM1xZan4wm 8bF9HQcAAJDRxM34fBKvEk3q16qauqMBACjzdiTh2kK8HjWpY/unj5/4OSP1FvPQoPVQb1QAAGUK rXvA3Ll9LWXspGkR4dK/TL1sQ5MAABSHJomEJgEAKI7VpDotl6o7HpeFJgEAKI7VpHnT16o7HpeF JgEAKA5NEglNAgBQHJokEpoEAKA4NEkkNAkAQHFokkhoEgCA4tAkkdAkAADFoUkilccmLYrbovYQ AIxejRkk8FN/f3+njQQcl56eLvBTNEmkctqkjuE91R4FlBHHD+2JHTlMwoIrv9go3KRKlSqR28zM TIkjUw8zcj7K7ZG62xVeP5okUvltUps6FdUeCJR68VfySJMmjnlBwrLLVm8QbpKfnx+5zcrKYh6e PXtWwla4mjVrxpoi+5qZkfNRbo/U3a55/VahSSKhSQDSMU2aMna4hGWXrFov3CRfX19ym52dzTwk R1JuTuxldSWyr5kZOR/l9kjd7ZrXbxWaJBKaBCAd06SXx4+QsOziz9cJN8nHx4fc5uTkMA9LUZOY kfNRbo/U3a55/VahSSKhSQDSMU16beJICct+uOwL4SZ5eXmR29zcXOZhKWoSM3I+yu2Ruts1r98q NEkkNAlAOqZJb04eJWHZ+UvXCjepYkXjr2heXh7zUK0m6XWFRbmZ5Fjh5uWn0bqLWTMzcj7K7ZGM 201NTc3IyCgoKCgqKio0IferVKnStGlTvu2a128VmiQSmgQgHdOkWS+NkbDsnE9WCzfJ09OT3Obn 5zMPbR5J16Z8Ruk1o0ImCMxjb5NIkJKWDNE9yNG40R4+lZ8Yu4EvS5YrYUbOR/weiSH7dvV6/d27 d93d3T08vB4UFpLHxkOkweDvX/nAgX2RkZF82zWv3yo0SSQ0CUA6pknvvhwjYdl3FscJN8nDw/jf 4IMHxccy4SPpykufUHqDTq8rKtBNbjqdbza7mkSClPhRXy//Sn61Qmit2/07V/PvZzYbs8lqlixX woycj8g9Ekne7ZJznTt37lSuXNnb2/tyynVykkSSRP6P/NkGVa928sTxvn378m3XvH6r0CSR0CQA 6ZgmzX0tVsKyMz5cKdykChUqkNuCggLmId+RVGcoWpH8sZbS1PUJIX/HP596Lvd+/utPveOmcePO LL5JJEi/LulfsXLlSrUbkAMFpdHS2gqZty7mZt5rOWYjN0uWK2FGzodvj9J/G+/u5k3TmocTDIUF WX6Pf0BrLNZGU5TGk6a1cm339u3bJDw6na7IpLCw0PxkHfN8Hbm9dy+d/MGGd488fuz7wYMH823X vH6r0CSR0CQA6RQ9T3JzM0aFHCKZh3xN2pCyKiUr2b9C1bp+9cjf6K9nXP/r6rkQv9Cp7V7nziyy SSRIpz/tX9G/SqVaDbNvX85Jv23Q0BUr1/QNapR2/XzOvbRn/ss+W7JcCTNyPnx7lPZz79DIYzRN U6YnyyiaLspPvfPb+wYyxUTj7kuO/7TPEx4Bz8q13evXrwcHP5aRkWnapPFwaDAh/9JTVBX/St/u 3lW3XiOdXl+zRtDhQ/uGDx/Ot13z+q1Ck0SS3qTw8HBye+jQIUc2L2YlsmzIktUmka3IuC+yjxlc k6KvJ2m1xrMB8ld45qHwM12vn5zc7rH25ND5y8VfxrWYHFKlvtXZxDSJBOm3zwZW9K/qG9ww+9al 3Jy0GtGfkOmXd7zk4RXgUz3k7uW/M+6mRc3YqnFzt7oSZuR8+PYo7UT/0Mh9BbeW6wrIWZ8fTft6 1uxKQkQZj1F6ytgIA63xuXR4mH/rFXJtNyUlxd8/4PW4X8nBkLSv+B+T7KyshbGtjx09fP/+fbJs VHSffd/tHjNmDN92zeu3Ck0SqRQ0SXYKNYm1NgpNKgcevu9utIRl5y9dI9wkjcb4LJZer2ceCjdp 2pHx7UM66A26/Yn71wz8im82m00yBmnFoIqVAnxrNcq8fTE3I61KtwX1QkLJYNJS78SvivH0qlyp 5mPXL1y8dzNz2OJd2odZslwJM3I+fHuUdqRfSK/d+dfWG1/AeXCv8P5tHa1x96xBGQopfYHBQM5C inwbv55ycGDVDrusDl7Cdi9evBhQLejN1Wf8q1Qli9OaYuRO8j9/fxATdujQd40fb0GGVKtm0K5d 2yZOnMi3XfP6rWI1qU7LpQIzl2fyN4mZzrD8qdXprJVYDYPV8w/hrQvHgNsk7nYtR8sdM3cwrCGh SeUE9/NJ3Z5tJzD/4WMnzfdtfj6JNj1nZf4vVLhJk/aPfqZhR9KkfT/v2/DCVr7ZbDbp/NdTKf19 35qNMm8l52akBkYsfKxOPfrhs2epd+8cXjjC08enSnD1q+dTDNrAYfPjuCsxz28V3x6lHYmuG7kj 59JWQ0FOYfZd38aDPas2Mb2CxJwnGYznSW6VL2zvEND5W6uDl7Ddc+fOBdUInrn2bNWAAHOTmNt/ zv01f0xLcm5Uo0O13Vd2znh8/rYtm6ZOncq3XfP6rWI1afOJXQIzl2cyN4nvuCzyvtWDOHd+ij9L sjSJW0qKv0k29wvKMKvXcejRub3VmQ8cOWH50OZ1HJj/Ns3HWeEmjd35QsemnXQG3d5je7fE7Oab zWaTsv5NurB3tod/cOadW0+8uNq3kj/r5CMnK2PNxN7kPOrOlbQBsxbXe/Jp7kpsHJ159ijtYK/6 Q34kp0RMgQzkxKPgelHGYYMu01BE/j/LoMvxDJ5xafeYgIg9VgcvYbvkfnBwnVnr/6wWGPQoSGRW jeb8H7/PG91i185tP9Tedz+7aEWHtZs3fTl9+nS+7QoXEU0SyVWaJPDUmZj12MXeJvGNUyBdaFI5 8fB6dy+ypkd3e4Y1Ze/hn1hTlqz6UrhJzHNB5iQIN+nFTUM6tTQ2ac/hPbv+u59vNjGvJ2VcSbry y+azeY+PHTfhwYMHc+fOZY7SxOuvv+7u7r5i+TL978e6jJhoDhJrJcLPYvHtUdreXqFDD+lzzxoj pMs2FGXoC9PJfaoo44cL6cdSdJl5eYVF+a3c7j0/8oBc201MTKxXr/47G88FVq9RL9CLKu4KfSOz 6K+zv70/qgU5N2rdpoPeQD1Wu8aG9WtnzJjBt13hZw7RJJFcokkMtZrE98QdmgQ2CVwXvE/3jub7 uw4e585g87rgzGvm5tfthZv03Np+ndt20et1u/Z9u//V7/lmE/9e8HXr1o0ePZocbRcsWBASEkKG kZKS8sorr5Amvffee+RHgYGBfCsRfrWfb4/SdvQOGf6dLvuY8azIeG6UYbqTfuB8+u/5vq2ahAVX aXDkz52n/vixZVDPsRGvybLdkydPNmnSdOpnP1tdZP6YVhvWr3m6XRe9wVDnsVpr16x49913+bYr /A4LNEkkl2iSwOtDItdjFzQJ5MI0ie/7kwZEGt+yvG3fMas/tfn9Scx7i83vbxZuUr/l0V07dNMb dDt37fph5o98s4lvUlxcXGxsLDk+LFq0KDQ0lGnSlClTSJNmzZpFfhQUFMS3EuF3RfPtUermnvVj 9ham7zbVKKP4KTtd5pTdGX2ielJaTe8mk//3fayW0mz7dv/ud07Lst2jR4+GhbXJzs7W6fWFhUW5 uQ8MBn2FCu4a2nhk9PXxWb06rn3HcHIqVKdO8KqVn82bN49vu8LvREeTRHKVJvGt0N75JbyeJKZJ VieiScA0acyLz0tYdvWXXwk3ifkMpvlzoMJNiv4oPLxrd9KkHVt3/jjnFN9sNpt0O+/G9exrxy8d /ef8Pz1b9e3ZvPfixYsbNmyo0WguX748adKk/Td2Hfx7v2+R3xPVnqzpHdw2tB13JcKfHuXbo7Sv hzw29PPCtARKn2sw5FP6fMqQb9A9eH7T7olDJ0X+p/hN2N/+vmzuivf3zflTlu2eP38+NTWV+ahs Tk4OTdPkzt27d8mBUaPVkqNjzZq1mjV7ksxZPajaO+/MXLhwId92hT+xiyaJ5GiTLAk/HSfyfXeU pM5ZnZmPzSZZHS2aBFxMk0YMe07Csus2bhZuEnOtGvP1coSbFD7/2R4RPfSUfvvmnac+SOSbzWaT 5vzylkGn9/X2ybifcT+5aM7A+atXr27UqBE5T0pOTh46dGjcP5/6+/ll5mVcunrl79+S9715mLsS 4avs8O1R7tlvilLPF1xL0heWuMB27L+3e/XqXkTp3whfu+DgKE+tB995krTtMs6dO0dOBINr1/H1 rbxr5xaS4du3b9+4ccN8cQeiatWqb7zxBt92ha9shCaJVN6v4yD+Y0nIDHAxTXph6BAJy27Y9LVw k5hrepqvKyrcpGdntysq1BUVFumKdImLz/DNZrNJi39ekHLzcoUiz5uXb/nrqtatEOLr61v8kR2a vnDhQl61nAyvtCqVApKvJ9f0CV4+fgV3JcJXIxW5R2brDi/56d/N7Zo906D6kxdunT559qc2NftZ fT1J8nbJglu3bu3cuauPr29Rkc5Nq1m27NM333xTYG3c7QpfARZNEglNEtUkBAmsYpo0dMhgCctu +vob4SYx331g/v4Ftb6rQsKahb+1QcIerTm4eE/85rwH9yt6ePds89zo7i/Lu11yGCRNun79OnOZ O3JKFBgYOH78eIG1cbcr/E0Z+Mws1wdLH+NOLO9NAnAE06TBg4TSwuebLVuEm3T//n1y6+3tzTws RU1iRs5HuT1Sd7vm9VvFahI52Do4gNJu+ORENKkYmgRyYZo0YMBACctu27ZVuEnMd2mbv8+7FDVJ +FvAldsjdbcr/M3raBILmvQImgRyYZrUt98ACcvu3LFNuEnZ2dnk1tfXl3lYiprEjJyPcnuk7nbN 67dKoEkHztxwcDClS48WNSk0yRKaBHJhmtSrTz8Jy367a4dwk7Kyssitn58f85AcBCVshctqk+Rd MzNyPsrtkbrbNa/fKuEmkd8iWYbk+sixF01iQ5NALkyTonr1lbDsd9/uFG5SZqbxS30qVaokcXDq YUbOR7k9Une7wuu32SRyUFJoeK6D2U00iQ1NArkwTeoR3UfCsgf27hJuUnp6utRxgQr8/f0Ffiqm Sa3rV1V2iKpKuJiGJlnHNEntUUAZQf4z6xbZW8KCh/ftFm4SlCVimtS+cTWVRucMJ87fRZOsI01S ewgARsJNunTpktNGAo4LCQkR+KmYJnVuGsSzdFlw5I/baBIAgEsQ0yTmYC1SWFiY5cPERN4LSrkI 1m6iSQAAqhF3nlRd/ArbtW1Dbk+eimfdd1lH/riFJgEAuARxrycF8ixtRadn2pLboz+d4rtP7lhO YXDnt/qQb0HLieYpIp04fwdNAgBwCWKa1KZ+gPgVhncyfkvIoaMnmfvMHfN0yx9x71tOZM1jXhtr ImtOqz8VFn8xFU0CAHAJYprUom4V8SuM7vaM+f7ewz+xppunWD60et+8HvN0yxn4Vs7aihhnUu6h SQAALkFMkx4Prix+hf0iOpLbHfuPM/eZO6zp3Nm495llWQ8tl+Wuzcw8XYy/rmWgSQAALkFMkxrU ELo6Ecvg6E7k9pu9RwXui5mN3GFuLR+ytsK3crtcuJmFJgEAuAQxTapbTejK4izD+nQhtxt3/SBw X/yPuA9tbsheKXdz0CQAAJcgpkm1qniJX+HI/t0sH36x/bDldPND1pzc6XwLCi/FnW7T9Xu5aBIA gEsQ06SgSkLfnl7a3c7MR5MAAFyCmCZV8SnLR917OQ/QJAAAl4DvqqDwXRUAAC4C3+nHQJMAANSH 7z43Q5MAAFQm0KTyCU0CAFANmsSCJgEAqAZNYkGTAABUw2pS1+4R6o5HdRdTo9EkAAB14DyJBedJ AACqQZNYZG7Sorgtsg8RAKCUmvtabHp6usAMaBKL/E0i/xvIPkqzGR+uVHT9AACyIAcrCk2ynyJN Ev7fwBFKrx8AQBbMk0Zokr3QJAAA+aFJ0ijVpPDwcO5PDx065OBw0SQQg/z6sX7ZuFMAFIUmSaP4 eZK8xwI0CcRg/kpk+YuHJoGToUnSOLtJVv8CS5kOH+ZTK9b8lhPRJBCD+TWz/GVj3WfusH5qWTKr VWMtBSAATZLGVZpEcQ4QFOc4Qu6jSSCGQJP4JlLWaiS8FIAANEkaFZ674/7nzdctNAmk4f4KWQ2J zeSgSSAZmiSNqzfJckE0CUQS/h2z/L0S3yTL9aNJYBOaJI0673FgHSbEnCfxrR+AS6BJdp0GCZ9m AQhAk6RxlSZRtl5P4ls/ABf3bzmU4CkRmgSyQ5OkUe294Fb/Jss8tPpmJwrP3YFoNp8xtvyR8Dv0 BJ7xAxCAJkmj2nUcpL1ojCYBQKmAJkmjTpNsvkHcwfUDAKgLTZJG/ia9GjNI0W+sUHr9AAByQZPs Vcq+qwIAoLRgvlsHTbILmgQAoAhSI39/fzTJLio0acycoxrj+mkDXUDT7gaDbvWsLpIGDwDgunCe JIGzmxTz3g80bQwSyZKOJpvQ0wZN3NudJA4fAMBVoUkSKNWkVmFtKEMhOQ0yTdaTCFEa8k/RS3Pj tHqNQUPr9UVaSqujdEtmTEpIird33GFhYYmJifYuBQDgNGiSBIo0iQQpKSGeosncOgNFzohomlnW QLVuHWY6STLeGOgiMtFd734q6RdZdwoAQH1okgTKNKnVk0lJpzNzC9krpSifiu4ashLjc3Z6rZ4m p06tnwpLjE+yd9zm8yTmDrkl981TzPfNMzN3rE60nC48J87MAEA8NEkCRZoUFtYmMeFnitaKGUGr Vq2SkhxqEmWtRqxocZeSMBEAQDw0SQKlmpSQ8EtWXtGj1T28Y7DchvHJPKprx7aJib/aO27hkFA8 LUGTAMBp0CQJFGpSWEJiYvLNbON6KMsbY5Po4lva9AITPbhPx9PxyjaJ+zQdX34sN8FaHGUCALug SRIo2KSTf6fSvDMWv+mB/DNlWISEw734Jsl1SoQTJgCwC5okgWKvJyXG7zt9U8wI3o7plZCkWpOs vgQlvEUAADHQJAmUa9KpfadvixnB22OjExR+Pcnqk3LmGtl8ls/yIQCASGiSBAo1qWVCQtL+M7fE jGDm2D5JiXZ/ZlZGOAECACWgSRIo9ZlZWq+jNDRN6fXGKzjQtIFvCT2ZJyHxjAO7IIXVDycBAMgI TZIA1wUHAFAEmiQBmgQAoAg0SQIFmxQ2buXc8VF6WmO6ELjBjdbo9QY9Rc36/Fvy08QVSBcAlGVo kgTKNun9ib16NK9BG3QUrTV+PpY2TpwzISqyeXDY+JXIEgCUYWiSBIo3KaJ5kHEpSmOapqcMhtbj V5Pzpxmff4cmAUAZhiZJ4IQm1TBdSYjUSGO8wp3pR63HrZw3Ifqt5XslZ0neN3Bb/awSAIAj0CQJ lG3SvAm9ureoYcyRgdZTlKb4UnfGu+SnlGu8qiR8tVYAAGnQJAmUfo9Dz+4tapIIGb9l1mDQ07Sm +FJ3er1B02a89CzZ/P4kStx3ILGmW66NsvW9SgAAAtAkCRRu0sQ+PZpXo0yvJ9EGSk8bjN8wazxf 0pPbA2duzVy+2/EmUSXj4cjFVW1esggAQCQ0SQKFX0+a0DuCNMl4GQdjkwy0+YUlvcFAH/rt1lvL v5XlPEnyPBSaBADKQJMkcMbrScYTJNP77orI0qan7gz6IlqjOfDbzZnLJL7NQaA3Al9qbjUtYk6t 8BVKAGAvNEkC5zSJeniS9Og9DmT1B8/cmPH5HnmbJHx+Y/PtDMKnVjhhAgDx0CQJlG3SnAk9I1vU ZL0XXEcZ3Ciyevrg77dnfCbD60loEgC4IDRJAmd8Zta4KlprmqY3nSqZPj9L6/f/dnvmMvlfT+J+ W5LV99GJv4833QGABGiSBIqfJ/VoXlNjerKueA6DzkBpadMJ06HT197C1RwAoIxCkyRQ+vWkaB1F M9dgNb27wVgnA025kTLpNXoNLfm94AAALg5NkgDfVQEAoAg0SQI0CQBAEWiSBGgSAIAi0CQJVGjS mDlHNcb10wa6gKbdDQbd6lldJA0eAMB1oUkSOLtJMe/9YHrLA02ypKMNlOkaeHFvd5I4fAAAV4Um SaBUk1qFtaEMheQ0yDTZeHU7SkP+KXppbpxWrzFoaL2+SEtpdZRuyYxJCUnxsu6UHfg+BouPxwKA g9AkCRRpEglSUkK88b3fxk8jaYzvBmeWNVCtW4eZTpKMNwa6iEx017ufSvpF1p16xGZa0CQAUAia JIEyTWr1ZFLS6czcQvZKKcqnorvGdNE7Pa3X6mly6tT6qbDE+CS7Bs130SDulyFZPuSbIuZCD6yf 8k0EADBDkyRQpElhYW0SE35+eD0hG1q1apWUZF+TKGsXAbLrKydsfv2S8BpwFgUANqFJEijVpISE X7Lyih6t7uEdg+U2jE/mUV07tk1M/NXecUtoktXF+S7hiiYBgIPQJAkUalJYQmJi8s1s05dUWN6Y vqqi+JY2vcBED+7T8XS83U2iOCkS/zVIDPFNstyomC9kAgCg0CRJFGzSyb9Tad4Zi9/0QP6ZMixC 2pHd3iaJjJbAeRLfGCQMHgDKPDRJAsVeT0qM33f6ppgRvB3TKyFJzSZRol9P4huDhMEDQJmHJkmg XJNO7Tt9W8wI3h4bnWD/60kMvqfmBL7lz3Jxc9JEvu+O4n9HHwAAC5okgUJNapmQkLT/zC0xI5g5 tk9SomqfmQUAUAiaJIFSn5ml9TpKQ9OUXm+8ggNNG/iW0JN5EhLPOLALAACuCE2SANcFBwBQBJok AZoEAKAINEkCNAkAQBFokgRoEgCAItAkCdAkAABFoEkSoEkAAIpAkyRAkwAAFIEmSYAmAQAoAk2S AE0CAFAEmiQBmgQAoAgJTarTcqlThubS0CQAAPlJaNLmE7ucMrTSB00CAHAImiQjNAkAwCEu0qQv ZgfKtaqRs+84c+WW0CQAAIe4QpNkbAbDshyKrpwFTQIAcIjqTZK9GQymHIqunAtNAgBwCJokeeVc aBIAgEPKapMoUzkUXTl3IpoEAOAQNEnyyrkT0SQAAIegSZJXzp2IJgEAOKTUNMmTGjaVSviY+idf 7JrRJACAUgZNkgZNAgCQH5okDZoEACA/V28SSdEbVB3O5K0LbMfJjiZZbEXMmik0CQBACa7eJDOc JwEAlHlokjRoEgCA/NAkadAkAAD5lZom2Q9NAgAoZdAkySvnTkSTAAAcUlabhGuwAgCUPqo3iVKm HOZsKLpyFjQJAMAhrtAkCt8ziyYBAFAu06SyAU0CAHAImiQjNAkAwCFokozQJAAAh6BJMpLepFdj BpFbxQcIAODy7G1SnZZLnTKu0kdik/z9/RUfGgBA6YHzJFlIbBIAAIiHJomEJgEAKA5NEglNAgBQ HJokEpoEAKA4NEkkNAkAQHFokkhoEgCA4tAkkdAkAADFoUkioUkAAIrDZ2a5Plj6GHcimgQAoDhW k8jBVt3xqG745EQ0CQBAHWgSC5oEAKAaVpNeiJnv4ApjR3VydEyqQpMAAFQj73nSyrVH0SQAAJAI TWJBkwAAVIMmsaBJAACqQZNY0CQAANWgSSxoEgCAatAkFjQJAEA1aBILmgQAoBo0iQVNAgBQDZrE giY526K4LWoPAQCc5NWYQcIzoEksaJKzkSbNfS1W7VEAgOLS09P9/f3JrcA8aBILmuRsaBJAOTHj w5XkP3Y0yS5okrOhSQDlBJokAZrkbGgSQDmBJkkgf5PCw8NZUw4dOsRMJHfMMzD3bSIzs+bkTild 0CSAcgJNkkCpJglkw94msWZGkwCgVECTJHBSkwTOk8znVVZLw/2puUmWJ2SstZnPzCjOWZrNjdqV TAnQJIByQkKT8J1+KjeJlRCrheA+9Wdz5ZRgloQ3iiYBgCycf55UBij+epJAhyjFmuTgRhWFJgGU E2iSBC5xnmTG1ySqZEi4z/sJrFzCRhWFJgGUE2iSBC7RJOE3RPC98mT1dMfe+86HJgGUE2iSBKWp SXzLytskvJ4EALJAkyRwoffdcZeibH0+ifssnMgOCWwUTQIAWUhoUtfuEU4Zmuu6mBqN6zg4FZoE UE7gPEkCXFvI2dAkgHICTZIATXI2NAmgnECTJECTnI006dWYQfhmP4DyAE2yF5qkAn9/f7WHAABO gibZBU1yNpwhAZQrwl9/jiaxoEnORprUMbyn2qMAADscP7Rn3KhhEhZcsXYjmmQXNMnZmCa1qVNR 7YEAgCjxV/JIk/4bM1zCsp/GrUeT7IImORuaBFC6ME2aNm6EhGU/WrEOTbILmuRsaBJA6cI0afqk kRKWXfjZF2iSXdAkZ0OTAEoXpkkzpoyWsOzcJWvQJLugSc6GJgGULkyTZk+LkbDs7I/i0CS7KP6d fpTgpVFlZ/VLzblD4s7jNGgSQOnCNEna5VdmfLgSTbKLk64LbtcMkqm4afGsNok7MJEVt/n97srs BEA5gvMkZ3Kh76rgO7MRPhazVitmKdamLR/a/HJ0q6MV2HEuGZtks1VoEoDj8HqSM7nKd/rZ+0V/ wmsTOTbhJgkMzOY+CuA2idmuwNgENmcm/GcoLfwAQFl7313Xju0E5v/++Enzfbzvzl6Kv54k8itf uRMp/gOlXE1iDcBmD4SbJJJcTeJOlzf8AMCw+vmkiC7trc68/4cTlg/x+SR7ucR5kpnw3+tFrk3p JnFHaxdWk7hPGAqPQWB35A0/ADD4ruPQK7wDa8q3h35kTcF1HOzlEk2y+eq9wCZUOU8S/hMQxm0S awbx27WrSaz1U8gSgDhMk6xe765/xLPm+9v3H+POgOvd2ct1myTwUxmbZHWivKNlsWySZQglbNfe 8yS+MYsZNkC5xTRpzIvPW/3p4OhO5PabvUet/nT1l1+hSXZxoffdUdb+Xi8cANY88jbJ6hgExlYa myR+2ADlFtOkEcOek7Dsuo2b0SS74DoONs6TZGduEitIrE3L2CRKavgBgHrYpGFDh0hYduOmr9Ek u5T3Jok8c5IRruMAULowTXpusFBa+Gz+ZguaZJfy3iTnQ5MAShemSQMHDpSw7NatW9Eku6BJzoYm AZQuTJP69hsgYdmdO7ahSXZBk5wNTQIoXZgm9ezTT8Kye3btQJPsgiY5G5oEULowTYrs2VfCsvv2 7EST7IImORvTJLVHAQB2IE0Kj+otYcFD3+1Gk+yCJjkbaZLaQwAA50GT7IImAQCoBk1iQZMAAFSD JrGgSQAAqkGTWNAkAADVoEksaBIAgGrQJBY0CQBANWgSC5oEAKAaNIkFTQIAUA2axIImAQCoBk1i QZMAAFSDJrGgSQAAqkGTWNAkAADVoEksaBIAgGrQJBY0CQBANWgSC5oEAKAaNIkFTQIAUA2axIIm AQCoBk1iQZMAAFSDJrGgSQAAqkGTWNAkAADVoEksaBKAi1oUt0XtIcjj1ZhBAj8tM7vJR3j30SQW NAnARZGD9bhRw9QehaNWrN1os0llYDf52Nx9NIkFTQJwUeRg/d+Y4WqPwlGfxq232aQysJt8bO4+ msSCJgG4KHKwnjZuhNqjcNRHK9bZbFIZ2E0+NncfTWJBkwBcFDlYT580Uu1ROGrhZ1/YbFIZ2E0+ NncfTWJBkwBcFDlYz5gyWu1ROGrukjU2m1QGdpOPzd1Hk1jQJAAXRQ7Ws6fFqD0KR83+KM5mk8rA bvKxuftoEguaBOCiyMF67muxao/CUTM+XGmzSWVgN/nY3H00iQVNAnBRjpxAPN22jfn+z6fiZRqR FIqeJzltN5kNSdgEzpPshSYBuCjJL7R0bN+W3B4/cYp1XxXKvZ7E2jXyULndlPzHiNeT7IUmAbgo aW9I69qxHbn9/vhJq1PM9/lms5woMLN4Cr3vTmBI5h2hxO0Ld36BPwp7x4n33dkLTQJwUdI+uBPR pT253f/DCatTmPvMQ+50qxO50+2i0OeTxIzHrh3nLiU8m0j4fJK90CQAFyXtAge9wjuQ228P/Wh1 is37Yma2i0LXcRAzHrt2nLuUc3YfTWJBkwBclLQLwfWPeJbcbt9/zOoU4ftmwjPbRaHr3QmPx3J3 xOw4949LYHG74Hp39kKTAFwUOViPefF5e5caHN2J3H6z96jVKWLu21zQLqu//Mpmk2TZTe6PpO24 zT8Ku9jcfTSJBU0CcFHkYD1i2HMSFny+dxdy+9XuH1j3BX7Ems3mesRbt3GzzSY5vpvMQ9ZQxews d79s/lHYxebuo0ksaBKAiyIH6xeGDpG27PC+Xc331+/83up0gR8x05kp3Pt22bDpa5tNcsJuCuwL 345zpyix+2gSC5oE4KLIwXrokMHyrnNk/27k9ovth+VdrYBNX39js0my76brsLn7aBILmgTgosjB etDAgfKuM2ZQd3Ibt+WgvKsVsGXrVptNkn03XYfN3UeTWNAkABdFDtb9+w9QexSO2r59m80mlYHd 5GNz99EkFjQJwEWRg3Xvvv3VHoWjdu/cbrNJZWA3+djcfTSJBU0CcFHkYB3du5/ao3DU3t07bDap DOwmH5u7jyaxoEkALoocrCOi+6g9Ckft37vLZpPKwG7ysbn7aBILmgTgosjBultkb7VH4ajD+3bb bFIZ2E0+NncfTWJBkwBcFDlYqz0EedhsktNGogo0yS5oEgCAalhNqtNyqbrjcQVoEgCAOlhN2nxi l7rjcVloEgCA4tAkkdAkAADFOaFJX8wOlGtVI2ffcebKLaFJAACKU7pJMjaDYVkORVfOgiYBAChO 0SbJ3gwGUw5FV86FJgEAKA5NsrpyLjQJAEBxpbFJlKkciq6cOxFNAgBQHJpkdeXciSWadPj773Nz spiHaBIAgFzQJKsr50581CSie9dn9+zdZ84SAADIKO329QlTXv7ie5kvsyQ2G57UsKlUwsfUP/li 16x+k3bu3F3wIE+hEQAAlFuFD/KzMtLQJMuVcyeWaBLRs0fX5Z8tcXOvUNHbV6FxAACUN+QMidy+ 9PL0lQc2yb7ystwkynS2RG4XvDuDlMnDw1Oh0QAAlB+TX3md3Mp+hsSwkQ2SojeoOpzJWxfYjpMd TbLYipg1U+KbxOjY/mlR4wAAAFsUvcBdGT9PcrJ5s423wldAAgAAPmiSnNAkAABHoElyQpMAABxR Zj+fpAo0CQDAEWiSnNAkAABHlM1rsKoFTQIAcJAS5TAflhVdOQuaBABQFpS175lVC5oEAAAMNAkA AFwFmgQAAK4CTQIAAFfhKk06l5ao7jAAAEB1rtIknCcBAACaBAAArgJNAgAAV4EmqWbP2r/UHsIj PUc9rvYQAADQJPWQJsWO6qT2KIxWrj2KJgGAK0CTVIMmAQCwoEmqQZMAAFjQJNWgSQAALGgSR07O iXY30swPaa3P035NZgbUCKYLT9/7dWba7avGPzH30EptNgZV9eLMb1Sxzcna1X1sbAdNAgBgQZM4 ihtj6oqnPuPrGyc+yNXVD+jypffVgVcu3HCvv65Oo+CCa2tzvCcFBHiXnN9WhyyhSQAALGgSB6sx GTk/dbxxT+P11D7/y1HX7+gqNPrmsUaNNbzzi1mnCZoEAMDyf1W97K0KZW5kc3RyZWFtCmVuZG9i ago1NSAwIG9iago8PC9SMTEKMTEgMCBSL1I4CjggMCBSPj4KZW5kb2JqCjYzIDAgb2JqCjw8L1I2 Mgo2MiAwIFIvUjYxCjYxIDAgUj4+CmVuZG9iago2MiAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9D b2xvclNwYWNlL0RldmljZVJHQgovV2lkdGggNDcxCi9IZWlnaHQgMzY4Ci9CaXRzUGVyQ29tcG9u ZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZQovRGVjb2RlUGFybXM8PC9QcmVkaWN0b3IgMTUKL0Nv bHVtbnMgNDcxCi9Db2xvcnMgMz4+L0xlbmd0aCAxMTIzOD4+c3RyZWFtCnic7d0JXBTl48fxWRZ2 l1NRBG8ERM37PlDxRBBM8b5BFFAzNM/qZ5ZaHmllSoW3aXmbV5IaHUZeqZWdf8u8b/PCA5DzPzC4 DXPt7Ozx7C7fd68Xzc7OPPvMIB+GZQFVYWEhxRIX2ZwCAACLWffFT+ybKn2Fk/q2evw0f/600e6u WpXahcTcAAAcWWF+7pOsp/97Z62HVp286ySzsqTC9CXwG0nDy3u6FWQ/zM/KKMjOIDpVAAAHpHLW qpx1atdyD26ce3PzKeaiuKjCdILffWVMfnZGQdYDOsGk5wkAYKNWpv5q4giJUY3pt86eftevXFi6 9w86xEUVHty96Yevjc69dxEJBgAQs2r/7z16D2xWP0jxCD//ee7LvdsTejakl7Ny8l7b+MvWr06r urSqt2VBYn7Wg5y7F802WQAAh7P6wJ8zZkzPunhM8QiutdotWrQ4PqI+VVzhggLqxTU/FVV487wx 2Tf/ryA323yzBXujaVFlxBQd9X+3Pn0rM4e+7ewcNNqvbSeNll7WrwRyuO8gIGDNl2emTZ3y5Nxh xSO4B3V45933xvSox9zMfJqXtO5XVfP6gfveS3xy+SfO1smHMpy0rgYH9cy/OzykstpJpXhaIEHl 3rJCaEy56n5O9I3C7Px76Tc/X5OVa4FH0rSsFjvdlToxq+uEJv0Dm7rV8x06x0t3ZffoPsm/ZxVS Hi/EBjbVmOmxXOr7Dn7Dy/Xhw30Tb9/I0q92qjLWv1dXddY317auoI9R5dnCu1U/r5q1nV0oKvdO 9uVv7p/c++RRycFb78zYCM47yFzvCzDG2rS/p0x+6dHfh9grf79497eLd+mFoZ3r6FduPvQ3/bZR rYoNa1Vkb+xZp/N7S94fHVayJV3huJTTRRXeuzj+8aVTnMd76VvvG5mG39Xe90+8P6i6TqNWckwg zcm3fJ8P/So/+HXh8Df23dHW6dJ7aPMzKcltOleubYlXEmbdnbPl1k3KuVGdCtEdI9uMfdmt6GM+ 7oaPp7+OUlHa9q18qjqb5ZGcNU0WBYT4Z6dPWvLt5X6+TsUrvTx6Lq9WS3v5o6j4LfdeGhPbadg4 d+qXI4teS/nqZmHDkdMXT2xaeOKnTxe75xVY+8zYCPY7qI253hdghHVfn508aWLGma/ZK7emn5v1 yQl64c2RrQeHBgmu0StXr9uSpcviugUzN+kKx6/6vajCu9+Oe3zxJOfxjuieD+/RQ+VURFX0v2eL pf+/4JVx/QPuo8IWoWlRI/51D6e/PogeeMJJV9tNlZuTe/VegW+Ad68WYS3G/c+NOn/n6Fm3xl3d PFyo7IsPf1p58+c/8pnXfzt5uzdP8G3SVueqpp5efnR6zc0fT9P5KqLycG0Y69usg5uXG5VzMeN4 8s3f/ilwaeOfSA/4045xL5yhuk5YPt+bM5n8n6+tn/Mws3h0TZOqsXPLaW/c2Zz0713O9ada0+y9 oPa1ihbz7mad33MrfW9WdiFnMEoX4hn7cnX1j+8NG+/VuHJ7LxXlEVYr9kXX3MNv9Rn7g7ry8Lmf D2muPftWt/Gp94Kr66q6qrWtPpia1OLptxPXfn+xW+WWys+MxAwFz0yh5Mksxcm55uDK7SM9KtLH k5N748j9H7fcv3izQOLdoWFO+4W7J697NGmvLbnsOX9rw7R7D/OLZuT1fK2YeF3B79e37Cs/7JWS d1CmJqRFjcCmpkwVlPj4m3OTkibc/+NL9srtRy7O3vwzszx7aLOit6ybA5l/ac94N+ixNPnDUV1L 0kxXOHHtmaIK71wQ8+jCCc7j/eDRT06F589IjPa/gwpbhEuDanGLvF3pr8evnf3xeOa9M87nj/5x 9lE2papRp3vrCbPcKerJkUW7d6ce+afyc9NWJ7V3v7pzzPXLt91UGl2b92u39X/6w2uzZn+b3X/N svh6N/bEX7pww0Plom25OLh9cN5fyUte3/BNhn+XmJ5epza3DO703Hh6QPrid1z9yCqNtE01SfPq FN2MPZJZqdvStJlttH+92/tEXl4znZO61qt1+7SnTr82dNye5j1rRJVnPR/l5FuudeiDLzfMOJhZ NWLBste6qk+8eij9l+ounOesdKo2qxq0rXDpo97v/ZoZU8/dq3VycEjNjF0jhi38JbB++/EfLq/v dmZZnwHfUW5NvTX1At1rVIgMenFSpYydU4a/HdI1tNv4xYrOjMQMNcJnpqZn+bZiJ5P3/hq9yFt3 94c3R8z7KsO7YY+BI5o83Z8SWMHdU2wEXduAcUWz/ffzV3Ye/Db9dGH1WV+/He55KSX6i3u5HT2c 6c89wSE1Mg8mDFnsseKrJVVK3kE1W7YzbaqgyIZDF5JeGHfn1/2c9TuPX3lz+++clbMGNuzXtgZn pU/jnskfLY/pHMDczHyaP3792aIKf/bW8Ifnf+BsfbLcoIieESWx1beXneTihXnTE3pXv6lzQYUt Qe1SfXB+x2ENq+q/zH50+8Dkm39cobTtAl+c7UFdWDuoz5Y7ziH+Wq3PyNGLX/C7s/GVqSuimzcP Tni/otvFtYN6b3/g0rJOdOIHs2rc3fzKSym9WzarG7+0ovvljwf32nTHuWllFw+q4Nb9vBotn58w d65n0Qf5mIdVy0W16NJ48puVS266V60zbdzrA8pdTZk0cUN462r1B22sFZj9TVLY/N/y2tXUNarj WY/9HYSCvBM/Pvhbrfbw6DpixcLAJ/tnDJ/buZ1ndefSJfDqXyUhsdLtDVPGftS5Q+uQsct8PM6u HNhv50Ndu4AuEz5a5ON0anb32JuVPJsGeYV4qyhdx4AJr3nmH5kZ8UJusO/w0BHqUOPPTCPXohAL zjC0VZuxywTOTLMO8TOTfQRPZhPXUnXTNPcft6Cc+tdVE2b8dPd+ZQ31NDv3RkZh4/YdR85YJjxC 666Nk+jZFn2+2Z+pC6nmrK35YsLcEd7XViRNWNulXbMO45b7lru+ZWTk2ofdVu55txbzHqnVblry yhqmTBUU+eS7SxPGJ9z+eR//rt0nr8/f9Zf+5v/61o1uVZW/mW+zXh+mrBrZyZ+5SVd4wsYLRRXe NKv/g7NHOFv/XnV0z549n+W3pMOq4v/Ya+ZOiQv3uahzcTLfkQJLQeFvZ3K+zwuq0W7w6KR+gXRz Hu1dNG1++6DOjWYs9KJOzekee6WiZ5C3U3P/ri1efcun4NjMiHGa5uEvLVhUjvNRV3j8tfCx6ubh U4ru+nFO95jLPp61y6maVlLlPqEeazpGvP12hZLseoQ17BT6Cj3+s5vB1WrEbG8ScC91Qu+fK3RL mj233K2U+EHJmX5e9Ss6dayu0pU8lpNLQEytbn3LVfH579Ny4Q+zwhKyAz1611CV+j6DqoK2746m DXK+finyZN3Xp40PKzw+ZchLX1ao5RFcrdmoN1N8i66FB//j4RYa5FTDhVKV798gaYp7xs5Jvd9Q +Xv0DFBd+dv4M/OcV69WMQGCM2wQMfP9ReUFzkyH8IWLKgqezOc8Inwo1j99V/e2C2qFtfIovpFz +9j1/QsOH/83y7VDv3cXC4/QvOfUhcx5jvvXzyOoorqFb1W/kTsaBNz8bEyfM/WnTp86SHPmreFx mzV1I+d8vLgm8x6pHTFrxWIfk6YKSmw+ej1h7LgrJ/bw79p/+tbSL87pb06KDOrZ1I+/WY3WfVat WD40pCTQWTn5U3f+W1Thza/TFT7K2fq3KnGRPSNV6pLs8nJcci08d3JceCVU2IJysgr+/rfg+uO8 jIpxLyVPqJab/mrEi66to15asMCr6Iqv32kXXUiQOqhKbMPxCa53Nk3ot8ClbttpS1ZV9/jrg+j+ O6/nswZzbty47dT3V9XwuPTx4OifnHUhgepAbfE92o71pi/QZ7dHw84dX2HdDHb2DZjVMKaH6rtJ c/8cNW9847/f6j7hwP2WtXR1aqobuj37uHdpEjjxQx/X28fmxLx94PIjr17JBxfVZwap5tEzWF2h 9D8TVeUp9eL76U4u3OI6dWTDjH3xPZaep9pV0zQMrNB08Gd16mtOzwlbeSYr8jm1r5OTpvGyJr2b Zn87fsjMo8FBbl1qq8vlGH9m6nWYsTSlquAMA9pMXbq6Jv/MuDSoNWGFr+DJrOcZFexU6rNdfsGx P13/9AjybzMiKTHU89Hn62cvqOvbKFBshOaRbyx/2/vZeQ4NUtdwcVIHzW80tEPmnrGrvRZO66L7 YUb3//2Q1fa57hOXL/IruRZuM2XZan8TpwrG23SErvDYqyd2c9Z/cfo2O8EMOsSRTX05K6u3jl61 YsWw9v9VeMpnt4sqvOWNgUIVHhUZGflffJ04OS75f/G18CVU2CK0rQL6hz/9LfX+hTNPHqqyAya1 HNFTd3rW8Bf2VGncc9Zy+tKVenJkwdL1B5vUrdOw93v+we7nP3p+/KdXmgSV6xW7umP3Og++nPXB 9kPOThUqPdelWefAv1Lmn8/WdhyxIjSsXvbJd5etTW1UO6Be2045R1c/UnWoN22+pz67jbqEvsy6 WcfFVxPgFru+QZVrf9yu1sD98+nPv3ze06Opj0v7ALWn/mNb0zQwaVlF3bUdLwzZn1ExbNTSIWH0 V17MIJ496jj7cp64cqrmNnxzg5rFy+cWx4xcR1Xzqufj3Km6k7ZcH5+EqbXyj29auNBNkx0YOKDW gHivwmPvDxv7xQNNSN0OidMjCxWcmQbtJyV/VE14hhX6xQqdmRwX17YpDboJnkynZkGsg9K28O/Z 4u6h3d/9fPNO5TFj34qrdH97Ut+3/Fv7hIenNBQcQdVp/PK3K7LPs7oopt6JKbU9btymqvg+2pwU PfdWBc/GNbu+uHRh+ZItvfvFrjRpqqDIpiPXEhITr54sVeEvfr79/rMEvxRZ9G039s3IZqVCXL1V 9KqVK4e1r8bczKQrvONmcYVnD8r4h1fhyqUrXPIE8X9PSTDXxHMmj4rwvYwKW4RL3arR0139/L09 i7+Uz7/38JfNb89MOZ6pCXkubHJRa/5vQ/IfLYdF16/oTGWd/2f7mzNSjhdU8Gzu5xISVP6xX3zt qIiGVVzpImVfSj9/cNXW1Av1WnoFO3tcqTi69vM9G1Vxo7LP3flmfuqWX9wahkfMmPcsu57hTbp0 nM66WY+ug5MqaEHjQW3pL/1vrOszauWFBkFutatpWrO/NUepXfzjtN2G1PNzoZ6cO3/0aPmwkRVK DcI5QienwLcaDm6vobKPvdL9taNP2vjr6gW41HdVUYWq+5ktHnQZ1bl9o0o6isr99+Efuza89dGu q/l1a7nXqNJo5IQZ7krOjK5Lt4RK3cVm6P3Ul3dmgt0DnD2uVhI7mezD0emCBhY0690gmD7Q/KdX 07fNf2396cfNgj3C6pTPFHx3tI/sNYNznove8c7NVzYND6SXLn0UmfDptSaBbsF1ug59nb2liVMF JTYevpqYkHitdIVTf769pDi7kyODooqby1+jV61V9MpVK4d3qM7cpCs8eduNogpvmzM44x/uz+T9 6hcbGRXJf0a4ZOHZ7TmT43r6XsJ35ywl9+mm7x/99Tj/SV7xS6mcnMp7agIrab39ur64ZH65oo/J 0dfd1Pce5GTk0A108qvoVqeCuqKvNsTHKet+9sEzmX/eyXlQ9FoyVQVvbUBFTe3yLgHVXdwePP3y rye/3cnNyC2kP+Tr13RvW9m5slfu2v0Pi1+O6hnxnNYvL/OdVNZNddEPDlQcv9hfc3JRn7j0AtfW vpq2wRofznu+sOCnXzIOXHl6L7coJvWqqq9fevqQPQhHYeHZX++tOpdbQFE+1Twb+2g7BTq7F4e9 IDfv57NZJ65lX32S/5S+W62u4OFSw0dTQatuGKjxV+UoPDMVqdPiM/TMEDozlVy0GaIn04d9BZKf f+qvx8euPL36pCCfvjjWuVT31dX0dAmpo9E8EBmhUu7H+0uf56KDLzh58s7Wa0UvMXOv5NnaTxNS 28U7t9R7xNSpgvE+PXwlMSGBU+G/bzw5e/MJvcAOLh1i+m1wZfc6VdzZGxdXeNWIDiWvnaArPGnr taIKb587JOMct8LLTxZW8Cl6dpmu8LO3zCLFXnn30p8jW3tqcS1sIYUFF6/nXMgoyC6gnr3oU+Xu 6dwgsHPI1Dc9nr2GIVBHZeZSRa+HdXLy9XFpXEmtVRUFLiMj78ztvPu5hcxLZbU6dS1fTYCnSq0q fJiRe+ZW3r2SvVRV/LSNvQv/+CfnRk5hPuXU8jmdnyr/F/ZNZ62m7rQ6vbtl7o4ZvuBnf/pCuKpb qK+K/47PeZL7+/W82znFD6py0qkLcvLoyRcPIvDJujDncc6xqwV0TAsplW8NXcty+n9ldIgLLt/O ufCwMDu/sPjwVR6ezvWquPhpTDozkjMUOjMVnZylTib7aAqznuSdvZ13M6swt3gztcaZ/oqhtrv4 u8O94PdzrPNccooKM+/n/HArPzOv6IZHZV1HHyengtLvEROnCsb79PsrifHx109xnxeWr2rL6JWr V4/o+F+FJ26+WlzhN4c+PHecs3VOXkF+Ae/F9jz0R4zWWa3Ce9fKtCG1J8591hqvyIauQoEzH5fn qick+7hT+Vc2zY6fd6rQtW0VbfO6rjVs8AfVrHxmoCz5JP3y2PgxJlZ4xeo1I0OZb4YUVThp02Xm 9cLDHp7jvl4YbN3Txwv33C/++tQrqpF7ZUu3Jj9nR+qtw9mUs6u2UTVdZV/3btXUzrb52dfKZwbK jE/SL4V0CW8YVE3xCL+fu3b024MjQ1mvF950sbjC84Y/4v3UBti6gtyfzmRdL/r61LmNFVpTkP/X uSfnnhTm0l9lu2paB+l8bbTBVj8zUJasOPiX4Y0kjQ2vq1+mK/zCp8U/tbFz/khUGADAyop+gvmT c6I/OwcAAJb2wpbi1wv3bVGJ9EwAAMqiXT/+q+oY0jb9yLEHd24yqwrVWrJzAgBwbKr8p8zCrasX EyZMRoUBAKwKFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYA IAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJ FQYAIMkiFQ4LC6PfpqWlcVbq1zAbMNibia23KPM+qOCxAwCIsdS1MCdG/AQzN8WWObtYDpEHBQDQ s3aF+ZeK+jViV5FiG8i/oNavkRhc7BD4j6ifiZwDNGoyAFAG2VyFKaGnMvTrxZ7roEQuqPnjSwwu OCZ/cMHRBA9QwaccAChrzFDhE5ey2Ddb+7syC+ziCD4dwV8jeHkr3TWDG8i81hZ7UOnnTKQPUOZk OCcQAByGvocSzFNhwUdSUGH2GkqoZTK/3hd7goISv/wUfFDpwRVX2OBkAMABiLWRwxYrTIm3THBZ 5uWnwQMx6qJbzgGaMhkAsHfkK0wZX1ijXkdhlgrLD6jMwVFhAGDYboX16xnSL2/grJTYnirdPuk1 yiZjbIUVTAYAHIZNVNgscP0IAPYIFQYAIMlxKgwAYI9QYQAAklBhAACSUGEAAJJQYQAAklBhAACS UGEAAJJQYQAAklBhAACSUGEAAJJQYQAAklBhAACSUOGy653V20lPAaBMmxY/kEKFyzK6wqFhvUjP AsC+paftGxc3XMGOy9dtRIXLOqbC4U2rkp4IgL06ePo6XeGJCSMV7Lts1SeocFmHCgOYiKnw1PGx CvZ9N2U9KlzWocIAJmIq/GpSnIJ9FySvQ4XLOn2FW7ZsSd88deqUhR6IHp8/uOBKsd0pS07Ppphy sMy+0rvLP+2OzcTzrN+RqfAbk8coGGfOkjU2WmGxv2os8YcypdfbESv/0SaDFeasV/wPtyxU2FyT NOUky9kRFTYdv8LzpicqGGfm4pU2WmFK6O8TG/wr9BK7gBh+hdkfyfoLK/Zd+psU68Oevxf741xm gsXG56wUm5jYpwr9A/HH5zy02PwFGXVyBDeQPmr+cUmcEMG7OBPgnA3+kfLvMmW2xo5AyTjnYsPy R+DMSvAwDU5YbGKcf7rProXjDU6eb86S1fZXYYm/Jy92FSm2gbF/1l5wcImh+HtxZiLnAI2ajILr aE6FKUNJFfuHy/mYp3gfeAYrLFYc/jSktxS8KTgrzmQkxpfeXnoa0ptJjENJvi8UT0BOhRU8KH+2 Mo9X4p8Nn/T4ghcQgp8ejPpHZfDf87PnhUfr13Tu0FbiKA4dPq5fXpC81gErTAk9laFfL/ZcByVy Qc0fX2b7BPeSmIngARo7GdMrbPBfp8RNiY8iS1RYbGPOvfwLYbEZyjkQzvYSE5YYR/6xyFw2agJi p12szopnK3MDBRWWM4LYqZBzmAYnJljhaeNHsaca1jlE8BDSDh1l33wn5WPbrTBVujiCT0fw10hc k4p1zeAGMissZy/B61yJA1QwGWNZocJyEiy4u8FpCM6Ec+XL/6gTm6TE4evxpyfz5HB2kXksMpfF zqHBfPDPm/QEjJqt4PFKnxPKhNMu/UCKK8yfA/8cPnu9cAxVWlT3Dpw1qV8d5qxZtmqDo1WYvYYS apnMr/fFnqCgRMIn9uSD9OCKKyw9GaPYaYUp3kejnArz95L5WGLE5iB4RNLXVmLj2FqFFcxW5iWn 6FnmkT7t0qdCwbUw/9EFKzwubgR/qn0jQvXLuw6k8zdYvu5Tx6wwJd4ywWWZl59yZisxDn+lKdfC 0pORzxIV5m9jYoXlpNPgTbFhBScvuKMgBefKYDVkdk3iKMTOgNj7gr+Z2JiKZ2vGChs7Q2WHaWyF x8QME5zqoKjO9NttqYcE712zYZNNV5gyvrBGvY7CvBWWeCCJoeQ8wSJ/MpZ4Xlh/k3MvVToH/A2M rTB7ZP5Q/OmxN2PvLh1B6XnyH0uM9BzExuGfLsFxxL4WFpykJSosdoDKZsu5S+wdwd+dz+Bpp0RO hZw1MicmVuGYYUMkZi5mw6YtdllhinXhSQlFirNe4qt4iecNpNcom4yxFTZ2MqZUWP4ubAaDJT/B YBRlX8hb4rQru5i1U4LnkKnw0MGDFAy4ees2W6+wWZj9q3hHggrbF/mXjYL7osImkqjwwAEDFAy4 fccOVLisw++RADARU+Hovv0V7Lt712dlosIgARUGMBFT4ajefRXsm7p3Fypc1uG3vAOYjq5weFQf BTseTN2DCpd1+ItHAGShwgAA5KHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIA ACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwmUXfr8wAFn4/cJlHf7WBoDp0tP2jYsb rmDH5es2osJlHf7uHICJmL87NzFhpIJ9l636BBUu61BhABMxFZ46PlbBvu+mrEeFyzpUGMBETIVf TYpTsO+C5HWocFkns8ItW7ak3546dcoqkzIbY6dtp4cJZDEVfmPyGAX7zlmyBhWWEhYWRr9NS0uz 2o5m2d0otllhcz0cKgxWwFR43vREBfvOXLwSFZYiv4acLc2YUUsXmV1hpkEMpkTsNRQrT/wt9dgh kxk1zmhi02DuEtxAbFbsHSU2Nrg987jSxy7/0Y0dgcInBtv27Fo4XsG+c5asRoVF0fmj2yeRV/0y s8AQvIvdUP7GnO3Ze3E25k+GU2cFydZXWKxT/J5Kt9XYCgtuI5YtY4vP3lHO4RissFHnROzRZc5f 4lMI2JRnzwuP1q/p3KGtxPaHDh/XLy9IXosKi5JfYUrkWpjipVN6WeZmNlJhSqQLyios8dAS4xic lVHlFVvmXwjLPCcyM40K2zumwtPGj2KvDOscIrhx2qGj7JvvpHyMCgvTB86UCstPqszdKd5Vs+lH qqDClGSIDXaKvyN/NIMVFvyiXnoci1bYqEcXnL/M50zABj17vXAMZ31U9w6cNalfHeasWbZqAyos jP1UAMMsGXWYClPiIVbwvDB/NOkKy3m218TyUsZXWMGjy7wWNnj2gCymwuPiRvDv6hsRql/edSCd v8HydZ+iwgI4gTNjRu20wgaDK5EY/l5iDF45yqmwxDgKJmnsZyZlj44K2zumwmNihgneOyiqM/12 W+ohwXvXbNiECguQU2GJZ3LFdpG5LH2X4Bo5d4mR8xoJwV4IbsasNOoJTcHnFqjS15VyvlqXfo5C bHzpFEp0VuKB5D865y6xE8vfHWwKU+GYYUMU7Lth0xZUmEvwGlMixEZ9R469GX+l9E2xAcXmKRN+ ds5yl5y4mC0jmAoPHTxIwb6bt25Dhe2PeV9BXGYrbIXLTFS4jGAqPHDAAAX7bt+xAxW2M2b/IY4y W2EAc2EqHN23v4J9d+/6DBUu61BhABMxFY7q3VfBvql7d6HCZR1+yzuA6egKh0f1UbDjwdQ9qHBZ h794BEAWKgwAQB4qDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQJJV K2zKRAEAHJWVKgwAAIqhwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIA ACShwgAAJKHCAAAkmVThd1Zvt/gEAQDs3LT4gRL3mlrh0LBe5pooAIDNSk/bNzZuuIIdV6zbaPEK /3vrhoKZAQDYi0p+VegKvxg/UsG+H6z+BBUGADAJU+HJY2MV7LtkxXpUGADAJEyFZ0wYpWDfRR9+ jAoDAJiEqfDMiaMV7Dtv2VpUGADAJEyFZ0+OV7Dv7CWrUWEAAJMwFZ43PVHBvjMXr7RGhd+fOZa+ +dK8Fcx6/k16mbOSTeIuzjZ60hsTJOdYAMC+2MG1sJwKs3eU3l4QextbLp0tzw0AlLGP54XFKqlP sH4l+6pW8C6D18sSQ7E35qznrJT5mUNiKGYQ/mZihwAAdor/GoluoSES23+dflS/bL3XSHDCJNYp wYtZfcIkQix9LWzwSll6F8GbnMnwlyXuQoUBHIng64UjurYX3PjAN0fYN633emHTKyxdMemLTYlE cnYXDDG/qtJzVjB/ALBfYj8793xYR86az9O+56yx3s/OWafC0nUWvLjmbyn2xIL8OaPCAGUKU2HB 3yPRL6KTfnnnge/4G1j190gY/BqfMneFJZ5QlhNiVBgA5GAqPCZmmOC9g6I602+3pR4SvHfNhk1l tMIGdzFlzmKbCaYfAOwdU+HY4UMU7Lt+4xZbrDBV+rLUXM9IUKVTKPhwnEGkJym2o8T3+nAtDOB4 mAoPHzpYwb4bN2/Fz84BAJiEqfCQQVIxFbNl23ZUGADAJEyFBwwYoGDfHTt2oMIAACZhKhzdt7+C fXfv+gwVBgAwCVPhXn36Kth3355dqDAAgEmYCvfsFa1g3/37duOvfwIAmIqucFhkbwU7pn2x17IV VjAnAIAyxYIVBgAAE6HCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAA JKHCAAAkocIAACShwgAAJKHCAAAkWbzCYWFh9Nu0tDSr7Sh/TOYms8b0h7PEhAHA4dlQhQUTaWLU JAZBdgHAFli2wnSn+JeZ7Jv6Zf1lqdhd7Nixr2E5Y/IHlxiTfa/YZbL09AQHFxxBYp4AUJbZSoUp 2U8XSAdXbGPph5a+i3NExo4gZ54AUGaZocInLmWxb7b2d2UWmARTimolZzP51bO1CvOXOecQAByD vocSzFNhwUfifNVPmamY/CcTTB9T+i7+4Zi9wgDgeMTayGGpCusvhPU3KbNWWDCRlquwwQtwBceI CgM4NjuoMOebbKgwADgSkhXmJFi/kjL0+gejvsmm31JscAVjGnwIsZUSxyL2KKgwgGMjfC0MAFDG ocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHC AAAkocIAACShwnbjndXbSU8BAMxmWvxAZgEVtht0hUPDepGeBQD8Jz1t37i44Qp2XL5uIypsf5gK hzetSnoiAFDk4OnrdIUnJoxUsO+yVZ+gwvYHFQawKUyFp46PVbDvuynrUWH7gwoD2BSmwq8mxSnY d0HyOlTY/qDCADaFqfAbk8co2HfOkjWocClm+Qublv4znagwgE1hKjxveqKCfWcuXokKl2IXf+cY FQawKc+uheMV7DtnyWpUuBSxCgv+mXpK8s/dc5alRzaq+6gwgE159rzwaP2azh3aSmx/6PBx/fKC 5LWocCmCTRSsqlHLlHiIUWEAe8dUeNr4UeyVYZ1DBDdOO3SUffOdlI9R4VIsVGH+silQYQCb8uz1 wjGc9VHdO3DWpH51mLNm2aoNqHApqDAAGIup8Li4Efy7+kaE6pd3HUjnb7B83aeocCmoMAAYi6nw mJhhgvcOiupMv92Wekjw3jUbNqHCpSirMPvJXznbG3xEaagwgE1hKhwzbIiCfTds2oIKl8J5zQPF +yYbVbqYgi+BQIUByhSmwkMHD1Kw7+at21Bh87DmC41RYQCbwlR44IABCvbdvmMHKmwSsWtki0KF AWwKU+Hovv0V7Lt712eosP1BhQFsClPhqN59FeybuncXKmx/8FveAWwNXeHwqD4KdjyYugcVtj/4 i0cAjgQVBgCwCagwAABJqDAAAEmoMAAASagwAABJqDAAAEmoMAAASagwAABJqDAAAEmoMAAASagw AABJqDAAAEmoMAAASagwAABJqDAAAEmosN3A7xcGcBj6Xy5MocJ2hK7wvOmJpGcBAKa6f/++t7c3 /Za5iQrbDVQYwDHMXLyS/lhGhe0PKgzgGFBhe4UKAzgGVNheocIAjsFxKhwWFsa+mZaWZsbBzYiZ p+nTQ4UBHIOjVZipm7lKZwmoMACwOXiF2RfI7PAJrues5OSSf5P9WIJDMYPwN6N4FVaQZlQYwDE4 eIVl3mtwF8GbnFLzlyXuQoUBgOFoFdaTyBwnkZzdBUPMr6p0XiUKjmckAIDN0SrMr5v0kw/SIeY8 sSD2PAMqDACKOXiFORezMi9+KV4xUWEAsJCyW2GDuxh7U06FBdMvNhNpqDCAY3DwClOln5GgxF84 If1qCrEKi+0o8b0+fHcOANgcp8JlDSoM4BhQYXuFCgM4BlTYXqHCAI4BFbZXdIWnxQ/EX9wAcACo sL3y9vYmPQUAMA9UGADAJqDCAAAkocIAACShwgAAJKHCAAAkocIAACShwgAAJKHCAAAkocIAACSh wgAAJFm1wqZMFADAUVmpwgAAoBgqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioM AEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABA EioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIq DABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgwAQBIqDABAEioMAEASKgxg Ke+s3k56CtYzLX6gxL0OfyqkD18aKgxgKXR6xsYNJz0La1ixbqPBCjvwqTB4+NJQYQBLodPzYvxI 0rOwhg9Wf2Kwwg58KgwevjRUGMBS6PRMHhtLehbWsGTFeoMVduBTYfDwpaHCAJZCp2fGhFGkZ2EN iz782GCFHfhUGDx8aagwgKXQ6Zk5cTTpWVjDvGVrDVbYgU+FwcOXhgoDWAqdntmT40nPwhpmL1lt sMIOfCoMHr40VBjAUuj0zJueSHoW1jBz8UqDFXbgU2Hw8KWhwgCWouwCsF3b1vTbY8dPmHcyzLAM sw9u0Wthi86c/0AKHgLXwgA2StmToaHt29Jv048cN+NM2GNaYnzLPS/MmS1907wzl3gs+fC8MICN UvbCgG6hIfTbr9OPCq5nsO9lr5fYkb8Ls0a/LPa4cljoNRISUxI8GxLHwt9ev4a/u7HzxGskAGyU shfJRnRtT7898M0RsZVylqUH5O/F3BQbwSALvV5YznzkHIvEGZBzAg3C64UBbJSyHxh7Pqwj/fbz tO/FVspZlh7Q2BEMstDPzsmZj7Izo19jncOXhgoDWIqyX57QL6IT/Xbnge/EVspZlh7Q2BEMstDv kZCeD3Mvw9gzw95XYjOZ8HskAGwUnZ4xMcOM3WtQVGf67bbUQ2Ir5SxLD2jsCAat2bDJYIXNdSo4 dyk7MwZPslEMHr40VBjAUuj0xA4fYuxew3p3pd9u2vuN2ErBZWaBv6P07tJ3ybd+4xaDFVZwKgRn K3jgEmeGP4jgGrGVchg8fGmoMICl0OkZMXSwsXuNjO7GWfPJ7q8565k17O3pNfoFg8MK7s5ZNsqn m7carLCCU8GeIYM/c/ZdEsfCH0RsjSUOXxoqDGApdHqGDh5ktYcb1a87/fbjnV9Z7RH1Nm/dZrDC 1jwVVmbw8KWhwgCWQqdn4IABln6U+IE99Murt39p6YcTtH3HDoMVtsKpIMXg4UtDhQEshU5Pv379 Sc/CGnbu/MxghR34VBg8fGmoMICl0OnpHd2P9CysYe/unQYr7MCnwuDhS0OFASyFTk9U776kZ2EN qXt3GaywA58Kg4cvDRUGsBQ6PRFRfUjPwhoOpO4xWGEHPhUGD18aKgxgKXR6uvfsTXoW1vDV/r0G K+zAp8Lg4UtDhQEshU4P6SlYj8EKW20mRKDCAAD2ChUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkV BgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYAIAkVBgAgCRUGACAJFQYA IAkVBgAgSaDCX339debjh8xaVBgAwKK4FS4sLOzRrdO+1P36EAMAgKXdvXVt/MQpX379XUmFd+/e m/M0i/SsAADKhNyn2Q8f3P2vwvSqXuHdUj5c5uyicXX3JD09AABHRl8F028nTZmx7+DX9EJJhWn0 FTH9duGcmXSLtVodwSkCADiwpKkv02/pq2Dm5n8VZoS2b0dgUgAAZUb6kWPsm/8P95F+4wplbmRz dHJlYW0KZW5kb2JqCjYxIDAgb2JqCjw8L1N1YnR5cGUvSW1hZ2UKL0ltYWdlTWFzayB0cnVlCi9X aWR0aCA0NzEKL0hlaWdodCAzNjgKL0JpdHNQZXJDb21wb25lbnQgMQovRmlsdGVyL0NDSVRURmF4 RGVjb2RlCi9EZWNvZGVQYXJtczw8L0sgLTEKL0NvbHVtbnMgNDcxPj4vTGVuZ3RoIDEwNT4+c3Ry ZWFtCjgGoJCDp0/T//////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////a9q1DCgAgAgplbmRz dHJlYW0KZW5kb2JqCjY0IDAgb2JqCjw8L1IxMQoxMSAwIFIvUjU5CjU5IDAgUi9SOAo4IDAgUj4+ CmVuZG9iago2OCAwIG9iago8PC9SMTAKMTAgMCBSL1IxMQoxMSAwIFIvUjgKOCAwIFI+PgplbmRv YmoKMTAgMCBvYmoKPDwvQmFzZUZvbnQvSGVsdmV0aWNhLU9ibGlxdWUvVHlwZS9Gb250Ci9TdWJ0 eXBlL1R5cGUxPj4KZW5kb2JqCjExIDAgb2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkL1R5 cGUvRm9udAovRW5jb2RpbmcgNzAgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNzAgMCBvYmoK PDwvVHlwZS9FbmNvZGluZy9EaWZmZXJlbmNlc1sKMTQ3L3F1b3RlZGJsbGVmdC9xdW90ZWRibHJp Z2h0XT4+CmVuZG9iago1OSAwIG9iago8PC9CYXNlRm9udC9LUFNIQk8rV2luZ2RpbmdzL0ZvbnRE ZXNjcmlwdG9yIDYwIDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDEvV2lkdGhz WyA0NThdCi9FbmNvZGluZyA3MSAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVuZG9iago3MSAwIG9i ago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRGlmZmVyZW5j ZXNbCjEvc3F1YXJlNF0+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EvVHlw ZS9Gb250Ci9FbmNvZGluZyA3MiAwIFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iago3MiAwIG9iago8 PC9UeXBlL0VuY29kaW5nL0RpZmZlcmVuY2VzWwoxMzMvZWxsaXBzaXMKMTQ3L3F1b3RlZGJsbGVm dC9xdW90ZWRibHJpZ2h0CjIzMy9lYWN1dGVdPj4KZW5kb2JqCjE3IDAgb2JqCjw8L0Jhc2VGb250 L1RpbWVzLVJvbWFuL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMT4+CmVuZG9iago5IDAgb2JqCjw8 L0Jhc2VGb250L0hlbHZldGljYS1Cb2xkT2JsaXF1ZS9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+ PgplbmRvYmoKNjAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9LUFNIQk8r V2luZ2RpbmdzL0ZvbnRCQm94WzYyIDAgNDM3IDcyMl0vRmxhZ3MgNAovQXNjZW50IDcyMgovQ2Fw SGVpZ2h0IDcyMgovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViA2NQovTWlzc2luZ1dp ZHRoIDUwMAovRm9udEZpbGUyIDY5IDAgUj4+CmVuZG9iago2OSAwIG9iago8PC9GaWx0ZXIvRmxh dGVEZWNvZGUKL0xlbmd0aDEgNTIyOC9MZW5ndGggMjUzOT4+c3RyZWFtCnic7Vd9cFTVFT/33ve1 mw3ZfBDSrMpbnolIsoSAmPBhWJLdNcmOdUOC7KKW3XxgIkEiMBmilFkLCG6Csy3UGa1KUNGARN8S 1MDQDkXBdGzHOqMdLVTbThwdaxydinQ6A9tz301SYlunM/2nznjP/u7v3nPOO/ee+7FvFwgAZEIc GIRubSybD1bJPoLVbS3rY12i72wCIEtbujfrL5QdOoSK8wDy4rVdd61/7cslJoBSACCtuauzZ63w n+bEamt7W6z1V7vW4rN5N2D/xnZU5OTaHwawb8H+te3rN28R/jkSAHV2bmiJjT/fh+OdXR/b0sVu U+ag/+Oo1O+JrW8bn18SK1fXhk2bRT8vj9u7NrZ13fr6dWvQ/yQAa4L/t/LWf7SUo7SQMH2ArsbW z6AZ68cQrYhHYR/so0PCBxYgTGzVw0fyCMyHjZZ+AWzF2gd/IwPwoKVZCs1ob0bvM8hVaGtBJlaM faTP4h/CDoz9BR2ip+lpy7oM49ZzDyF0SB5BPY+3HV6A98kp9Lkf9qLtOLzFn8LI+2AQLpLZKL3k QzJGQ6glfHyMsw699+F8fwHvwV9JHqkiCXISfXLoA9ZcxGhx9DmD8pYVhcstpJNsIBvJQxhzlDK6 EKNuoLtpPzXpaRaRquQRJUepUDsxCgGKpzcbM+TRvg+NOHIz3DsZVchvCSUNpIm0k0dIP87hDBlD +ZJ66DJcdS4/ZVHJIX0sr5OfQhlRVqpPaArGlkGBQtChCG7ArPw4RgPOuRXuhvssuR9lK67lj2A/ 9MMBOAQpOAG/5GPCOXgfLuLqZKHwvCrIIrIKJYKykWwjO3A9eq+QPeRxMkRO4PzeIO/QmZi1kE7M XsxyO32MHqNv0F/TD+go/YR+wYDZ2BrWzDaxg+wwe5O9KdVK/dIB6bx0Xiayaa1UjpKn3Kn0ovSp NnWdukP9sfqE+rJ9LszAvEoxr3pYhVn1YCZbYTckrF1LoRyDl1BG4BOeB0p6PBMui4iPBMhKlAhZ TaJkPdlEtkxm9Ax5lgyQY5jLOyjvknPkT+Qv5DNLLlKF5tOSyfxCtJGuouvoI/RR+jh9Hk/kED1J 36XvY46j9ALmmMFy2HR2DfOzAEoTu51tYdvZIDvNzrEx3DeHdJNUJa2U7sTcz0qj0se4k1RmcpG8 UF6M0i7fI2+Te+Un8USPyWOKw1qVHCVXWaLsUvYrQ8p7yiV1upqvzkKZq5arjWqn2q0eVkfVj7Qj tuW2DttGeykchnnwytdu70t4ul+ldyplUEjO4Wm4l2Whl87vHnWonbYOOsRnpzaS2bhTf4CLzAZB 6SysYrdDp9zMMtRPYYBskh4gz7MAHIGDajc5yaJsjB2Ui5QlYj3pY+yw2qNG1Y9wpl+yvXK7Opcs l3vJAF2GN3ojaYCvyAX4AY68mc6Bs/AQ7CbdoME+7QjJxLt2hs4kvfJT7KjUz/zyNnI97qBLHmE7 YSFMBwfMhll41mXIQ4C3orLihgXzy+eVzfWUlsy5fvZ1xUXXGrPc+sxrrr7KVfi9ghn50/Nyc7Kd WdMyHRl2m6YqssQogVK/EYjqZnHUlIqN2loP7xsxVMSuUERNHVWBqT6mHrXc9KmeXvRc+zVPr/D0 TnoSp74UlnpKdb+hm7/xGfowWd0QxvYenxHRzTGrfYvVloqtTiZ23G58QvcXtPt0k0R1vxnobk/4 oz6Ml8qw1xg1bXZPKaTsGdjMwJYZMLpSJFBFrAYN+BenKGiZOCuz3vD5zTrDx6dgsiJ/rNUMNYT9 PpfbHfGUmqSmxWg2wag2s0osF6ixhjGVGlO1htE7eDrQq6dKTyX6hp3QHC1xtBqtsTvCJotF+BjZ JebNhs+8+b7RAk/pMHm2KWzaaoYJNIWPQ306nqqL+3wRPlpOTXiX5T4D3WfcN+piCX9Bh867icQu 3exvCF9pdfM6EsGgntLgirAbZ234+3SexoqwlQEGJQVlOEmu42mKhNsMP9dE79ZNm1FttCfujuJm FSZMWNHjPlpY7z2e/iPU+/VEU9hwm8tcRiTmuyqVB4kVPUN1Xr1uqsVTmnJmi5VOTcsabzgyr2y0 TdqsluXOWzjriaUmfEZGHR4RU2/RcSZhw6RFlbxqq4RESyW6YYkQXNEOXL9owrmYb4Rc5DT0xAXA g2CMfTpVExvXKEXOC8Cb/LhMHjm0T7TNkhJzzhx+UtQa3FqcWZXVX+gp7TaDRpdTN4O4ZBAK40OR xWW45G433+XeYS80Y8eMN4RFX4dm11HwlpVETBrlllMTlukruSU+YZl8PGrgcT4G/AfddFMrnvxk OfNz/e2LTZL/DeY2Ycfr49dTklyUCIWLY4leV3E00RfBrQngVUwkAoYeSEQTseF0vNnQnUYiFQwm uvzRiZSG06d6Xaa3L9JOcFHNBWI1zNyaMHPRiGhRF4t4gM9DLb8cAsjA33rpN+0fWDO7suywNH8m DiiDPTAN38RObC3CRz9Np/l73+uAQABdcrI1b60+TG88WjsfabtF5Iig5wUdEjQg6DlBTws6IGi/ oDpBtYJuFlQtyCuoStBSQYsEKYIkQUwQ8d6KfB5xDvF7xO8QryJeRryEeBExiDiCGEA8h9iPeBLx BKIPsR3RglhjxXxRhB4UdFjQs4IOCnpG0JOCfIKWC7pJUKUgVZAsiAoCrxf5PcQ7iBHE64iziDOI VxDHEEOIFxD9iJ8gehCttfPzbHm2iuQw6fbWqckDanKvmtyjJjeoyU41uVZNtqnJO9TkajUZUZNh 9VptlqZr12hXaYVagZav5Wk5mlObpjk0u6ZpiiZpVMNXmJnLgjTYWE2C5qkWCDbr5leNxjCxN6w2 ZaOamDlBCDZVF5iVJSbdbX0jDpN0ipCHd7r4l+FxICS9c49rnCMRyC/511IwpRcM9ZyEmaQCVKwX DKkzX1O5thG1SUub5NqkpS0gR0MwPxjrjV4N/ybwPwv5RusUT38HTzcUTmlQHam5Q/AQzbBjPlGX O1Kd7+yqspJb4i7Y5johAf70z8DvBAe+ZDIR3ORZ7lnOTfj3ipum8ffPuKlg2xK36wQZGDc5UZ2N S4m3LI7/neL4q59hkoY3S32bSG+Tp/EPXhrkNDtOPgQouzzmHINln2FdPm9Btju7yJ3tjjO4FKdw GeSRv1fGpRF+xwfJSXpJcmCsvJ8DoRV4WxlpwQBj+Cmfl4uPDtIQOoUumfzOF38nKFXfauGFjn+b 5+HOYyGFCAUb2//Hf9Df9iLhb2xeS3x9Pif4HhuvsY830VofAjm4fhRbCtgAVnXcc1crYpP1ziRJ /uv8vyza1O7n8Hl6ioJMTAri3+E7cLBDMCju7DcUfm5oHFLmiyfWZC29oLnEQTs4uPcy59Qb6tsA l0P2D9Ry7Domztk/AJ+WFd4KZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iago8PC9MZW5ndGggMTQ2 OT4+c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3pr YzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+Cjx4OnhtcG1ldGEgeG1sbnM6 eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdv cmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIy LXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4K PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0 ZDMyNDJkMCcgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6UHJv ZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA4LjU0Jy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PScwMjkzMWRlOS1hNjA5LTExZGQtMDAwMC1lOGJiNGQzMjQyZDAnIHhtbG5zOnhhcD0naHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOk1vZGlmeURhdGU9JzIwMDgtMTAtMjYnIHhhcDpD cmVhdGVEYXRlPScyMDA4LTEwLTI2Jz48eGFwOkNyZWF0b3JUb29sPkdQTCBHaG9zdHNjcmlwdCA4 LjU0IFBERiBXcml0ZXI8L3hhcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0ZDMyNDJk MCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRv Y3VtZW50SUQ9JzAyOTMxZGU5LWE2MDktMTFkZC0wMDAwLWU4YmI0ZDMyNDJkMCcvPgo8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0nMDI5MzFkZTktYTYwOS0xMWRkLTAwMDAtZThiYjRkMzI0MmQw JyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0n YXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1k ZWZhdWx0Jz5cMzc2XDM3N1wwMDBuXDAwMG9cMDAwdFwwMDBlXDAwMFZcMDAwT1wwMDBTXDAwMHBc MDAwYVwwMDBjXDAwMGVcMDAwaVwwMDBSXDAwME9cMDAwRFwwMDBTXDAwMC1cMDAwdlwwMDAxXDAw MC5cMDAwMDwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxyZGY6U2Vx PjxyZGY6bGk+XDM3NlwzNzdcMDAwQVwwMDBuXDAwMGRcMDAwclwwMDBlPC9yZGY6bGk+PC9yZGY6 U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0 YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVu ZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC41NCkK L0NyZWF0aW9uRGF0ZShEOjIwMDgxMDI2MjMyOTA1KzAxJzAwJykKL01vZERhdGUoRDoyMDA4MTAy NjIzMjkwNSkKL1RpdGxlKFwzNzZcMzc3XDAwMG5cMDAwb1wwMDB0XDAwMGVcMDAwVlwwMDBPXDAw MFNcMDAwcFwwMDBhXDAwMGNcMDAwZVwwMDBpXDAwMFJcMDAwT1wwMDBEXDAwMFNcMDAwLVwwMDB2 XDAwMDFcMDAwLlwwMDAwKQovQ3JlYXRvcihcMzc2XDM3N1wwMDBQXDAwMERcMDAwRlwwMDBDXDAw MHJcMDAwZVwwMDBhXDAwMHRcMDAwb1wwMDByXDAwMCBcMDAwVlwwMDBlXDAwMHJcMDAwc1wwMDBp XDAwMG9cMDAwblwwMDAgXDAwMDBcMDAwLlwwMDA5XDAwMC5cMDAwMykKL0F1dGhvcihcMzc2XDM3 N1wwMDBBXDAwMG5cMDAwZFwwMDByXDAwMGUpCi9LZXl3b3JkcygpCi9TdWJqZWN0KCk+PmVuZG9i agp4cmVmCjAgNzQKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDI0NzI0IDAwMDAwIG4gCjAwMDAx NjA0MTMgMDAwMDAgbiAKMDAwMDAyNDYwMCAwMDAwMCBuIAowMDAwMDIzMTExIDAwMDAwIG4gCjAw MDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMzAxNSAwMDAwMCBuIAowMDAwMDI0ODE5IDAwMDAwIG4g CjAwMDAxNTU3NDggMDAwMDAgbiAKMDAwMDE1NTk5OSAwMDAwMCBuIAowMDAwMTU1MjcxIDAwMDAw IG4gCjAwMDAxNTUzNDQgMDAwMDAgbiAKMDAwMDAyNDc4OSAwMDAwMCBuIAowMDAwMDMyNjM3IDAw MDAwIG4gCjAwMDAwMjMyNzcgMDAwMDAgbiAKMDAwMDAwMzAzNSAwMDAwMCBuIAowMDAwMDA3MDg5 IDAwMDAwIG4gCjAwMDAxNTU5MzIgMDAwMDAgbiAKMDAwMDAzMjY5OCAwMDAwMCBuIAowMDAwMDIz NDIxIDAwMDAwIG4gCjAwMDAwMDcxMTAgMDAwMDAgbiAKMDAwMDAwOTk0NyAwMDAwMCBuIAowMDAw MDMyNzYxIDAwMDAwIG4gCjAwMDAwMzM2MDUgMDAwMDAgbiAKMDAwMDAzMzU0MSAwMDAwMCBuIAow MDAwMDMzNTczIDAwMDAwIG4gCjAwMDAwNDE2NjQgMDAwMDAgbiAKMDAwMDAyMzYxNiAwMDAwMCBu IAowMDAwMDA5OTY4IDAwMDAwIG4gCjAwMDAwMTQ0ODUgMDAwMDAgbiAKMDAwMDA0MTcxNiAwMDAw MCBuIAowMDAwMDIzNzYwIDAwMDAwIG4gCjAwMDAwMTQ1MDYgMDAwMDAgbiAKMDAwMDAxNTk4NyAw MDAwMCBuIAowMDAwMDczMzEzIDAwMDAwIG4gCjAwMDAwNTY3MTMgMDAwMDAgbiAKMDAwMDA0MTgy MCAwMDAwMCBuIAowMDAwMDQxNzY2IDAwMDAwIG4gCjAwMDAwNzM2MDcgMDAwMDAgbiAKMDAwMDAy MzkzNiAwMDAwMCBuIAowMDAwMDE2MDA4IDAwMDAwIG4gCjAwMDAwMTY2MzIgMDAwMDAgbiAKMDAw MDA5MDEyNCAwMDAwMCBuIAowMDAwMDg5ODg0IDAwMDAwIG4gCjAwMDAwODE1MzMgMDAwMDAgbiAK MDAwMDA4MTI5MSAwMDAwMCBuIAowMDAwMDczNzI0IDAwMDAwIG4gCjAwMDAwNzM2NDggMDAwMDAg biAKMDAwMDExMDA4MiAwMDAwMCBuIAowMDAwMDI0MTEyIDAwMDAwIG4gCjAwMDAwMTY2NTIgMDAw MDAgbiAKMDAwMDAxNzQ4NiAwMDAwMCBuIAowMDAwMTMwMzcxIDAwMDAwIG4gCjAwMDAxMTAxNTUg MDAwMDAgbiAKMDAwMDExMDExMiAwMDAwMCBuIAowMDAwMTQzMzU3IDAwMDAwIG4gCjAwMDAwMjQy ODAgMDAwMDAgbiAKMDAwMDAxNzUwNiAwMDAwMCBuIAowMDAwMDIwMTExIDAwMDAwIG4gCjAwMDAx NTU1MTAgMDAwMDAgbiAKMDAwMDE1NjA3NSAwMDAwMCBuIAowMDAwMTU0ODgyIDAwMDAwIG4gCjAw MDAxNDM0NDEgMDAwMDAgbiAKMDAwMDE0MzM5OCAwMDAwMCBuIAowMDAwMTU1MTY3IDAwMDAwIG4g CjAwMDAwMjQ0NTYgMDAwMDAgbiAKMDAwMDAyMDEzMiAwMDAwMCBuIAowMDAwMDIzMDkwIDAwMDAw IG4gCjAwMDAxNTUyMTkgMDAwMDAgbiAKMDAwMDE1NjI3MiAwMDAwMCBuIAowMDAwMTU1NDMwIDAw MDAwIG4gCjAwMDAxNTU2NjAgMDAwMDAgbiAKMDAwMDE1NTgyOCAwMDAwMCBuIAowMDAwMTU4ODk0 IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgNzQgL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lE IFs8RTlEOEM4OUFEQjZCNTk3NkQyNTE0REFBOUM4MEVGNUI+PEU5RDhDODlBREI2QjU5NzZEMjUx NERBQTlDODBFRjVCPl0KPj4Kc3RhcnR4cmVmCjE2MDg1NgolJUVPRgo= --=_201c2at93vy8-- From interop-bounces@ivoa.net Sun Oct 26 23:41:35 2008 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 1FACB1AC003; Sun, 26 Oct 2008 23:41:35 +0100 (CET) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m9QMfa9R000554; Sun, 26 Oct 2008 23:41:36 +0100 (MET) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 0363AECA346; Sun, 26 Oct 2008 23:41:36 +0100 (CET) X-Original-To: interop@pat.hq.eso.org Delivered-To: interop@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 7B850EC8141; Sun, 26 Oct 2008 23:41:33 +0100 (CET) Received: from oren.hq.eso.org (oren.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id m9QMfXxm000551; Sun, 26 Oct 2008 23:41:33 +0100 (MET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwEABePBEmCT8iYZmdsb2JhbACGaowJgQcNCwgIEqpFg08 X-IronPort-AV: E=Sophos;i="4.33,489,1220220000"; d="pdf'?scan'208";a="11852542" Received: from mailhost.u-strasbg.fr ([130.79.200.152]) by clavius.hq.eso.org with ESMTP; 26 Oct 2008 23:37:00 +0100 Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m9QMfROk070908 ; Sun, 26 Oct 2008 23:41:27 +0100 (CET) Received: from localhost (www-data@astron [130.79.128.15]) by newb6.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id XAA24643; Sun, 26 Oct 2008 23:41:09 +0100 (MET) Received: from 72.4.254.58 ([72.4.254.58]) by astron.u-strasbg.fr (Horde MIME library) with HTTP; Sun, 26 Oct 2008 23:39:07 +0100 Message-ID: <20081026233907.1ide941oua0448k4@astron.u-strasbg.fr> Date: Sun, 26 Oct 2008 23:39:07 +0100 From: schaaff@newb6.u-strasbg.fr To: interop@ivoa.net, grid@ivoa.net, vospace@ivoa.net Subject: last version of the VOSpace-iRODS note MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_201c2at93vy8" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-MailScanner-Astro: Message analyse non infecte par sophos sur astro.u-strasbg.fr X-MailScanner-SpamCheck: ORDB-RBL X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [130.79.200.152]); Sun, 26 Oct 2008 23:41:28 +0100 (CET) X-Virus-Scanned: ClamAV 0.94/8497/Sun Oct 26 22:30:29 2008 on mr2.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mr2.u-strasbg.fr X-BeenThere: interop@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Interoperability Forum - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: interop-bounces@ivoa.net This message is in MIME format. --=_201c2at93vy8 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The final note concerning the VOSpace-iRODS implementation. Andr=E9 --=_201c2at93vy8 Content-Type: application/pdf; name="noteVOSpaceiRODS-v1.0.pdf" Content-Disposition: attachment; filename="noteVOSpaceiRODS-v1.0.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nMVa3XJctw2+36c4d92TmaVJ8D93buxJ3ck0ibPjXDi5WGtXllJ5JevHbp6j fcm+RQCeQxLUUpZV200zTbk8AIi/DwCpvh2kUDBI+icvjt4s3g4qgE2/lIQweIgiRjdYJZ1wnkge PffDk/PFjws5fIv/fb14uwhC038SG18fvRn+ukaGMCiF3DEM6+OFRIHR6PmQQZPgwSkQ+PXNYjmM 698WT9dJvhTagrQKF05pCGp4/m13+/JjtIiD0sI5a6sWkJUAKQJaiwTBkBovUY+VFsoZqZfPxl/X f0cBSnIJXrhgDJmx3iL9fkQbwbiwvK6cu3HlhAYb1fJyXNEZymmPtCCMk0YvNz2uU+IyRoe4PC+U nCevzkYAEFIq0m/22WeJSYzkh+qOPzUq6GZh3UFUhtEKB6Chv/lidM734gZGgDUqx405+3L0Ikrj FQUDvROtNMubEqH/g9+9Ec4wg/9cv1uLXn2o37/vggWsCKpg5VXx5NW4isJJHwGxkh3NofIurUFZ b1kAGFgqQmr4fh+tlCU2bxfaqDhYa1IJe4M/XSg/z+afmAH5JxGXnyeLn4f9Z4qvUVIAdyyLL+kJ zpvBkvuTnuAxC/LPs/mnivlnIi4/Jz0/S9wpWFMxftyod5/oNuS3ZGspPDDZLwlFQhswlq1Oy2pT S2ctfUcsG3ajte5/ACBpeTcCXRSmcUGK0K2wasxTFfSUzhPFCoIVBL4VaOFd/YAeMVhDv6Off5n+ 9UXwrNSgorDSQjXLuNmsgM2KMh71nnz/FF2qIgD1ohVVG3BAzQjZ8HQEaNk8G0kWtgLqS14oC95R sxM2aqmWrzOlR9MK5YZ2lQOlcDcxJXwqPNNahZjN7K/K6qasrirz9eiEtwB2Fo7F4QVBPzqIEUsN JkvEOWX502SOM8uLImbWQWmHaUOGGbR2VzerYsco20bn8Pt5NfySltHJZANGUUs0vDl9RZE2TmXl dACmcTUShSLwPU5WszcT5VVRirFvxiCUidiMWFy2dTmM4EPuPNiDNFBqrb96yb22K3EsNgAWUmXQ BhMwjCVOR4VyV9knxZKHPnN/m9IQv8svPVXcjwaDhTN3tzmqGm1mfqB+olFbnT2CbmK+q/Hd1/jO mRLUUlVBojLJ1repHHvBtVSq0dLNgH02rkDE4I1HbUEAGCyMKQUhAMp7nLDgEwxnSrf8R9kkZdGL NmKCGiF1lGQq1lIfDFQWv4SyKceVFdGbSFp74bXyfhnmz1pxplkPBDdmVOavB52TpCBlhIR3mUC3 KzIxSYMwFJ8s0znNFLH8zC+RkTj9UdEvGdkp2VNGVTEU5QK9NUELKwEsT8hSH61LQzwO0drbgOlD fdVIXA51990IigbPSDkXMU7oFvIFHqK9SzBUNOO4LAr7HrrSoKoGPbmfj8L8+zpBG1OiZFUYcKqi 5lvTKnCLsWqmpMujnaZpx1DOKkx57ylnsf0GrzxFP+1iAJYrWhplFSVKoZXdZSD9JaAAEoulEr3O vzMBtpBmA1pv94KmsQ7Og8R3k1MgYvksnr4mA0B7badEn3avOAHmpwHrc1DIv++K02cmF1wblLJL pcAY5ZWdEnyKxaeFxTkRD8NyUj11XcNCd5SIVxkchS5GHDqM0gHPLN8f4UhulUFFHtXN94Q1zD5s Je9HnNXAK75iUT+lUQudjldc9Ar2Hy9t6o9ZlU03WfZ1d9dV+1FV+0k5l4nFEc/TXQFT7GZKi7B8 QwECLbWZbgm0t2+kJ5ERw0ONkmrOo7J3RhzGgOYazwppMFzNyn6dnIdd/JPlZHYGnXeTic7Fas5l /XxVP5+WM89TCoHFnHOuvjn0kLnvxmj2oQo2H/owuOHwKGe8/UBSVcTelKHhYihVDKFRS9sEEtBG c5DclCrG8ES1H1uyCi0K8+pyupIrzJu7QNgpjb8s5zIQAyuov4x19+upDJjw8Sg109x1C6UP8CXE ud+8pL6NHc9ZemhYKSckXvJ47Topte28rFg9au0rbmkNfHAZwpHEHxr4mI4NgI16euyitN3WBGMZ /N+6O1Tk/1T5GchPutnKlse1YBwnVGKV5GIZKcv87YEKIOPym1Jxfh/R2alRo97ghAo4JVW4nbHq x876YcRBzxLXrva0q2pMvxxkYdrDHAN66QhlwviIEQXih0aUaSASWtHTLWIQCwIGFGcqUHiLxYHZ azkAAJ2BSMbpW+nhcrc4/mpBrwfWhzRf4z3BOlrQ/+rKpxMf4D/Ec9cmlE08QeZ9MtxqPA4XOPYM lKLOq0jS0dFwKOnDGvV5Zvtg2owfffQBx/3OmF5j4GPs6zJMjpo2uaOyRi11f/fT514rA5VzvDHP VX1+xTCQLjIDXWhoEtl+6UsaAlpTJpf3oqYS4c2G/jgxV0rSSUmPlwhKcunSzQznGWwvMrVij8Y4 IEgDig3SUHHI39PbEea+9zT7oaZGy6i/0JUCqJT38Er3hRe1f36PtyApbXRTdZw2L+qQuik96ygV nIgli4+mWJtwJIhUHF/WVqgrwa91l9GepssptupUvbCOYY4HTnBd2U6qsNqNqSYqajAGb6aF9MUY 0WqLfaHa9Xi2K/oqP6KyZeSOReikK9VpRvk+VVdvLXXARKlp7KCmrWH5z0l7lwJZeI75hYm013R5 LEyM8sDORLkrBzHSLf9eluwo5tR9JWC715TBHlODNrEpY5V2zKj9NOIhJJWJecRjClTK4zoqsZht mKQUMhU4e1895oBdx1XMvE39fDQ6eo+KkfPgUYbKlHdc6HlDkHXZ9Bz8rsaS+aeowoTeFHam1Fm1 L6sSOuFxyhBpEu/aUIMPFIFVDsFqRi3F4WqGn6PRATxWJV2w44of06DLrptp6I52nliU1ogEn2+p Lk3KBX0bft/P1jOjGNerQsq+t1Uhn3UAhflGS06l9xpG+iJN2IYejib4Yqqm7/Q84j1T8KI+WFxw VbLWLNWOalBr0Fko70BCiepVA/DWg4mA0W6bXMu0TEIvw9usyxly1GW6SnmvYHrSK2U1wdYbimOG 7bPq9mtOWrTaFmMfUkwOdCEMMqnnU2CcidOIng7AwAAphze/NPWmOwSL6wdroGl8yaK1Z9EsWj+0 hFjbVpCCwNmbHIHsbWdfl9vmbQ2HEAogXQTyXfS8JCjTk5Gy3abTtfdSovW8Vx6UuPxSlK9dDK6v 7+iggNOP0f4w1omU+a3ClUntK1NJb/jokJO5KaIlV0qsdqVxNAleHLCe76jIc1Liz5KiScps3nkX rG3nyAfcJ+vmDuBPEPTCRp8huDucFpigg7AfNn4Ai17zt71zuyxdVD/2Lb06qDAU6Vc9/52NNO8q aBzBYtbgN/uMnXrcpnixtQ/wLvAmH3Lg/bs8lLJ+18yoZXlUCXKm11Ex8L5R87QClDVD5qhtZWpe gzLQ/lMktTmbD2Xz6b5BdSboz7qHI7IxmrPtizKsAByMU/kwr4SlP3a8p79lYzaZNteyUBaUf+WJ I+Ymqw1vshueQJ1ewaSyDLnpouJQu4nFRqPuGLanWRUVlGVWZeX9FQdFPpGB9/ogVKaNQ2HfdS1i JrMZq+un3fwYqTnljiO1M5ZsuqqyU/tQb3zOpnUGyvx9U03kk+fkUA6/z3tbzE2/uS3WC9j016mg 27mvCGAA2nbFHsawxS2RWkwim0v53Mqo1Bswt5WdSWuJaH2ZT2XF8nnJ4MlZxi+flK3steku2nGF raGsl9G2rGSudXluZjX1tNTvW3PrzMTxVXGYSpnzBDA+0x0ax1tiwl/A+7bUGX9s/m3Sk2GJz3RV fr963Dcf9mgPhhYNHEsNAln5y+x3trKuLp0JmkFp9s29UFrXv9k+rd+/SZGiV4e/ldVQUoKljLnj rSWTXnSnQ9Yyfute4Y4KJJjJguOTrLz1/yn6cfEHGdX05GVuZHN0cmVhbQplbmRvYmoKNiAwIG9i agoyOTMwCmVuZG9iagoxNSAwIG9iago8PC9MZW5ndGggMTYgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJy9XEmX3EQSvvevqNtUzaOFck9xYzAzMM9spod584wPvZTdxu4FNzb0v59I SZnxpRTqqjI2cJFVuUTG+kVkqH9dtY3Sqzb9nx/Or47Sv4zTrVP04JXRUa2e/Et8/ebF0a9HsTHp v346Pp9frf5xcvTpE6VWyjXOWLs6eX7UNl3XWR37IWoVQ+NXQasm+NXJ1dHT9Y8b3ejolV7/tqF9 rGlbvT7dHMdGG9sqekt7BK3N+u3mONB20Zr13ea4bVxrQ4jrVXrWTnUqrG9oCdO1RO36+bCaDTaN CE0XlXLrEx5wyY8vecDSyo82x7Zx9FrjJucwOpPn9fqKRigTgtPr7TDCRGPX1zwxn7UztMuzk38f fXly9AOxPLF9Hx7HlVKND11kFhtXsbglFuuBxScb29hoddefOUbbupjObBvlInGbzmyaoLxRREzb WEuc75miaJ4JHQ3wjfOGTkYs6ZpoolYkIyJBeevzpLZbf0vCpNVd1zOJdvLR92e1VgXi7nZ4q+K6 4ZcrfjzZHLsmdI7kflmW3/JSMPQ5U5IppQFv6KitVV0SpPJNJLJo/zIS5vNIWP/1yBSf3ub9T/l3 4pQyxG3n8+/G4qLDqYl7CumDAUDLZVkA6B84rbsOJ13wqrDBeRn6ll9epfU7ZzwSeM2//4ZsT3qn HZ3HJuU6uSBV+b0XIJnNeOp+EhLVkx+iWWv+vRUfY5E1HOUbpg82uB9kZTzql0qPpvO2W9tRFqpW m0T/cT5AEkzyOOkUX7MWX7PG09q0RtOarJL9gKxni/o+zAnrd4OVOB9RY1Dh0iSrK3neFC26Ri0u i/5eDGYL5lR+vkJ25d9fTQlxnVX9LGJFcAEVFtYSFf5WVK1hqJmYTlnptGgWKDkMZc0rC8FsUByg +VbY/UbU25GlxDLaUpOjVbFoELm4W1YbNNFe14Mjqfis6yCm6zIy+8LO4J6gq+Ai4PFUJPUlD4Cz XC9YFrMXhma6LgSudeszPKzkem7motjWK42bAtWX4qKrjQ5xsLiRjWhxt2xmbzbHnmJ3MEVUifp+ SeIEOavx3Tmrcc2yHbYDHnzYqItgPK95/p4e3FYO+uf1uKqt7OR6PIBOZ6njHjj+fqjs+DUPaMsC LXM6FmJ+3gwUeIIaM3c3svzxEf37bwNoILRFGk3ILJh25bQ3hAtWhKg0QQS9erM9er4nplDtLlBB etTYAVN8URwXYIob8RHghRzKb5i513LUn+qzXWJzpcZlgcq35llzK6nV5zXZptJKBxTu4K99rGwb 1POFpBxFp0hTT/GsxbguJDDxhvVgy4qSsKXRXvsAxv1u1GpfOz3BDSzZObuJsungnJzDhW7LQHB+ gD/uRkdraGGbHS2c6X5GqPITlzoxf9qKQQlQwuIR/fh2IzhZMq3RCX7GQAbwd21KBNp7U2ot2YU6 xJJ2onPfBiJzsKQZZk42AwAF3VSidGqo2ve51OOjk78fCPUHFgwDROiTo+spOkI0yzzga5bwT7RW ozpLHv67TWja1nV+/Tm/pFkmpUE0C0+ezWaeLEw8ALz9IyvoLRuViHIYmt1x0KkMuFjCCzSfTOid BLVfiI/bHUiiim8Q5wsBFSTI/AVfNRzQBTTqq42idLKdCq2seT1aZWySzoxWWSOKPAuIYlsXLWwe qetUQzxIlSBBbCusFhOkrUgq4CQQi+zgBBw0yqeztg6zoNQAbonBQStfwaCBnQiDFi2NQnHjTcAB 1wvWXt6CqV1gLJPepi20blKlooLK1YCRBrCBSzYczi8qXCXtcDalpk9A2MgmWcM461baADwL57Mw H4z0nO1JNLJPKiHyrpDgCLPgEfY6wzDHeLICzuMGp8yBW7QdSGdKRL0Z7NB35Lx1tkPOps45OIq6 zxb1Sc1hY8i5BknJgdAqmxKNrFgLkCyzUsjw7pj4aiDUKxb8YWb6OzbImYCtNWh6IwfR9G7QcMYU IxEfbZMi0L6GN+T0RT85MEGM2e7Q5LPy+0uEk+Wg8BY4cV/sJ5EdbGMU1geAUeyNLmv77Cd5Qbwz PJ3XT9FaNTZYjxsMQm19h/SBjz2VzKMwO4yB3wawozvJeovyAH49FdUUVbvo5n2O/7X/zlR8PVqb alodsrVNfNPIBqDuUnIYcHaQ4yQnH9e6xgXkwlsh8WwhxOXfpaQd4mZlsvOR16LxwYB8gErlbmau q9O18Q0MXTC+qrRW3kJYGyjVbkG578Qy20r0GBAhZdwI9imGn+3CAg8n+5DDVe4JBgj5phgfeSRA QM4GTwUBY64Iixf5im76XAxzz3cFWjb0papWDfz6MNhbYyr2LKZWJP2Uv6yMDh+hSuEI53RjcnVc lE1+KqWq6nHHyPrnlGscs0otvBR/l552DNy15J/bZ3l1UryPt01yMJNt+ofi6aUfpVHShL5s1kUK cgVy/Ym9FBmx8v49qbRkae9xhP22kn7c993BP34QSvbj7+GyMh3FzvF+KIue8rV0593Lvy5HREV5 XCiBnRCinMaNsKsPhnlSVfeFCD8Gy/FWN12lx7YN5WKd/73fjfpDPk8ZvbLRNXGszEJd/S3EvGx9 WCARyq41PhpOGQ6s7+RZT+ByC9K8Qh4wD6qa8FhhGQiPAEQPuXYRsChQW9VLZhDJVPzAeipgbSnt wVQsT5+BlQqj9UsBLULBhXNl+WYK9qouj3tA3KkUqbMvhGhf3SODEARafkPo4dqW47xqKb63po/v OnTdyufovm9vw4Pabn0gGiuFh8OK0OW6EmGnmzYEPxYxptJimGsiyahzFcx9ztgWEO/bWckmPV5A EtpXlALiwjodmGdr8DuwmjHsZ/z7p/z7p/yWsbX01GykguQ70TShwAHTAHrLIBpoeTSpcGdtzynf kt493L8AVgx7NVmAkyq8VmOPA/H75JeZlpnGeNXVI6r5x5Ru0xiMI8O47OL/4hYq+mejRwP4PAWm TrW9/ue+qVf8CH1HN5tIqtjFdKlCWSY9t33kK31OW+houuB5L/gRR1ylnifXta5+PWyonPO50Sm1 YY2tVc6Zj9X0ZNvYtPE9mp5KCa1YLRhA1lTnIaBWjTbS7cgk4S/ri1WkHJIrY8zp4hbTTawR9Wv2 N6G5ZM0r3UiUAiGzi9JJwpiGWvJ8IaXpqXAce6c3T0dfVcE01wovsPQuFSQm9Y6RKjmelwFuvHZO V4GPytOPFfjIS4l3FmMfCMWAaEsE3HUlCovOWG00BJqZTkyPt9QedpBUxqGPkunFwOhqLBGXGuqo 615ZvJ+qgmEp6YwMSXpuRowMXIWSDsQ66Om43/RO0TgOsGtT1RsnwMlWWisjo6XSZR4qAlFoIPyS f+dmha/K/X1eiR6f8qaWt3pWKeCwa66uQOtX36eU5fPLrPukrr3A8YZYmpom4UzfcPg7FWXGfU4V 0wBBFAUWAdCrAhxlEDy7PJoi338PFhSJjdl+QP1mRKf2P8jX/rdRRJ53uu5YkO8M85bfFkt/KbG3 tqSgKH8MYX5jWveTAc6ASXDjx5vqstP3rFFGNKOeKwv3gXUjonZ0UAooj/ntfbl5L21Tk8t2S2wM leXcCDEEVt+jGyYP5chWFWCn1hoK3B3bZaH6n+njmqlc1j0vQQyWqq7kshIcdsU8nkQ2nMlt90jq nZj8yPd4cn9kdXE8p+BMnP92NKJkC0YIQ7AWsPBJUclyv1IHwf4ip8PzPS03RY53f4aeh2lm/gqF aBhZ9U2JaW7eHUIYBCNoK2LDGTixu6Mwa6TQVDa5Mp91b07fzqoEQn9LHbjn7X2INmoxpWDDYWkM 1paQbxEUbODrSw1sBB7Xh1lwBDZ6Fh+o9BmCML7KmmO43LWWMjzpdFVYkqok91UfawEzUmlENs+l uJQxKN44DrZD+X8sBV12BHXUEnAVYFgYwLZVRTNoC8rRTOzOBUqBVzcLzgPa+naA4AVbZLsZuIB2 c8gnHnLfSa5S1JmD9OEFmAXGnwe+dlhs7ORQAxYImRds9Vbq9oIqxQsp1FXYfFr3rO+3Kg2cXvrV ZbAqqsjHllF8DuAQX8AwxfaTeTC1/PnCUpPWCyRwaALT5MULdrtBGMV4fHqTOa2iSVwR7/orZ1X0 HjRc7PoRO1dlAsU7egxGeSFuIpWi1ivOm8TN5bRp5CWa39L1NxcDoekyW6ccMvK7Kr/N8fy/RDDt 3um0UO6EhS9Dxpfe4HmAb5DzKLYXU+zlGc/CTGWhB/2vr38ZYoTTuRedHGdUTuGnedf8OR7UoOoq lTQifwDoYj7vh65S6Y6I7O+nhwoiDW+tRy9OIhlqlAHX8o1vCQQ9UKTUpomdKYUNuLURL3iwWlRU 4AIdbZ60x7cagKAG9xpyucWQmZhMtpFPRujPP1R9tW1HJqCQR/qD8Og/xczuoOAm9Z0AD7iOX31O kiHCRz32wkoHHnsnXp06n3KhWh3Lvu+xTON93Tpr2Fs27EPVhlKOseu92iRV43WnH9iF1o5tKO3O X5UjQToArUBQmf0dhu5qip2ihkln+bxxl/XDp28Awl/FSY31h0L1Y6Tv4V5gwGW7v32R+op2K1pJ YHv+dOSdW/tn+TMzoIWVDjQgsfoIkRrqhKfoRqcfny19RfZOGloVeaYcNhWDSRl1MBWHS4eu+sim bBdMWVJAiFEA0fmiU/yeb+nyRbg9Xcz9xcglGfZCyRrQft2N2+cgonhFhF59NzsHppBtVah50s4J buXDmM2+UtUfzEFD8VWUpNzWOfuAYGiwPOB7UsgQ+nsut9SgfSn5t91+AArye8nvvcMCaaFNkLig TpU7hAhL65UKbbkxtpvYWO96cH9Mp3Y6pg+zhZeLAXjWhRRT0yVvshdhjvBwrCj7PHHGOtUOJRFK H2z/UVRC2q7/0xrHrmm9SQ0emdzXPbk+ucDXm67xXavSbBJRKqfAit/z49fDz6VJlVINsmz/ENsn J3ZtAvMHHniQhIuHimHRzBbEMOxwiAwyTT+RFgedGsG/6wNLZ1rXK7RtvHaaFDqTxwIgddbJHvpg RY+hjV1kCXzJbP+DR95W8kt39W0qmZXpb9Kj1l4lx5iHvqGnzg4tTnOxuf3FdgCDBplZV/5kzf5i MweKrWxyiOSAMtl6UKS+/zs3dkmihfuVSBUZleksrvnPtJOL7fCNyyg9ECSL7IukRqavT1yWlyBn eLwbNu0ro/tJPOwvcYm3C0hRL2vTwUARYsFWyqffYliDPhD+2KfEmvvyJ22qL7LLfPEz9rqxP2NK /IsrMygYPxTWfjpeOwHo60EDBM3q02MpgzrbaNIpa6uoLH78PfuWyoSMdG1LeqXjYefr6z4/HP0f WJltVmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKMzk4MgplbmRvYmoKMjAgMCBvYmoKPDwvTGVu Z3RoIDIxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicxVvbchy3EX3fr5i37FZl x4M7kLdITrmcSlVimfGLrAdquSQV8SJRomR9R/LBAWYA9MFMj5cuKxWpVBrO4NJo9OnLAfi+G3oh uyH9LQ+H283QfRf/XW3eb3yv0p/xAz4fbrtnZ5tvXvhOiN664Luzy83QhxC0MmML0QXfW905aXpl u7Pbzdbuzv4V+wiHnWxvB+XSqGcXm203NWmGlar3YRw1tni5fb6TvR6MCdv7XWwlrLbbu93Qe6+t t9vDzvbGaqm3N7u90L1W8eVjbflht1e9E8b67ZvdXvfCeGviSPvQq2BirzyU8FGWV2d/3Sgne1XE 8/wKlI0rXF/AXg+hF0F0e6F6radl/DlKJ3rtokzvsnTxYRIjSnyEtVXZLurLN7S2X+qCu9TSKy/F OHqcUsdB/xQXpLWIa44N6uO/d7oftAiGBAlVkCRSVeiRHkHNTxflLM6kvQ4SFf6RJLmhtzDVf0b5 pC7boAfZe+mzlsPv3wclp314sdu73jutVNX59nKS3hmPIj1UlfEqOZBpHdHe4mQhWPFVFyKHXioH BjW1+8vZ5odNwrIycjAiPlihpBfdi+/Y1w9PwbgQnTC9UWmiAvJxAQnk3vW2s8ZmjL/cit1+6M2g nUtbtzfC90KI7ffptTRS+TDqTIUhyhDtIGp/8MYl9co4iR90RGP9fkGPj/QYNe3j+vUgRkOyWkXz TeaVpogb7BKgXVyKt7LMFlWXdyAr6Wu4uGn1KvRyWvxPBLu/7+LCBhPs9kd6mWE1RMM6ryZyyCZi GqxlBDmvti8JLIoavEJc17aAxg+Axtr0IwHzukqwnDZ9/556sesCDwa9AOSADcA7i6hLGiArRukC KBtU7qS0EjgXjHrPNrioYy30IkNAZUyiqMZJvaYxH+tA0OdYX8KUH0joRrxkedLEVtKVSFbnPKeJ ruiRhu9peH5/Pja2EJ2DEL7ZClozr77rcVoT9GxVZahPtX+jSGF7r2VolVa6Q/w9pSnof8EpACS5 ry8vWa0sFrUYSjqfNmNfdgOjcpFJlYGil1E10Yg7trfJ8SqT92yE8hUXttuFFoB/qZgkdC4tKna/ TS+DUdbG3Z8DfQqre9O7YAYBeRDo6Ta5PWmldVHUmkG8HWc1ZgXya/5Lit4ZV/KDqEWw2F9F6eS+ 6viKGvDu65EagHnAbIDJNftizP/ulPu4nlRkYxLE2urDhF/n+xQIMn6P1Omcs3roD0kOiHWJO09p Z335eSdkb71WrVAqBbS4wDu0b0b+i2bVRS2gzDu2AeziJWkIHsEFHBZ+wSLYYIKPOzH0TgqLCMz6 /N8hUPaDcw2ajhh3S752TQg5Z3O7xpXWboCxmYse55UROiFlN9LHNLNULc8yxoJDCQEkoko4rEb7 PP7P2xJCIMkAfwJRMSvOuvVw02Aky5XT4yQ4bWtNagO440cywRrYGt+AsMqjPyOpo3wxmhgRt4jG fEsTHScEBtsH6RcR9OddtgttcPzltiVRYgMRs3BFWVgrVRO366Lu1yCe9wKtHvzCiucCb1DGuqsD XLFbsRbZoG0FVlYTAuuC4FLUMsgVuE16ldHlQ9PXNADV02BsTT0NIGLwCBGJvl+0ISmrtUlYoSiF UWkzuVpsrSwrL+FxzQaWcll0rufo5Wq3kuCLpYhj009k22SFoEOwMvrOG1EbPKqOZylriq/NAmjS EVo2VlK2JqeN65+FqexQMvZW3P3SX1mUGVzTASM9Cc3Fm3turlPQBjxeLPEuEeR33HeIHrA/v0yz at3kPThBRWPWLKKRiUgrCIUwF2WyInm56vkTQXLJQpCnVbAmzGP5VbSW7wBMPg6+pcc/NvtOI0B8 JdcBWKnfX9fv5yg2lMgzDOdtdyIGD6efsO1TS9fOXzfwHVc0QMCLkSbbfc8sVSeig8kvQRfX6Dhg AlrLhMb4sw8FjVRVNZneSiY3U3ubFX7iYvINQgx0cTKrLMoEx/QFa80iyulcO6OlUFhdHG8YXOWu 6OcnkVa/xtpoZxIOjR//G4mbH4nL+HbM1HSUCXKq55QGtZLGdchOe5sm66STnesejpvLr8ErGSdJ uJrbQUpc/QKF6wKkuI9Xxa0cCVzJPdrYVjlISJdkpbHoEx45wubAIRKGbzK70glodq4QfdhFHVXN OjV0iZVOihVChqLZr8PcSaliZk46BtE/zsPdKBz5LXDd0Kspq3jHU5oeuPQZEAiuu8kfS9O1rJ6h qGj8Gq6Lq4lfWw9WxAMfD9n/xAdoN8NHPjmA7sBWmjr7q6Y8Kk2pfGHT4MVGzEuWU6tv4jJ6LWHU SGjA+oB5yPq3Qpeqwydbzs54u09M+17HaiV2bM4SIEMu5kKhQ2KgryhNFHk0TeNUVGw9icAgOSdG NXQKlZyJdc+XiY7TEkMzT7zWwjVQ5RQ8jssHemjQSFOiAKUP4HQ+V08D3Z+QPnMR7Wppz2A6DdrK TE2xCswGF6Y/V9s+Z63seGICCn1IMk/UkUspOFFHZaDWm5QxXy9ipF4jtK6oKa9fQAHRuJBG8En5 Oy7jaBRc9gRkbUJ/EWUt9HN1a9bSCiFUQdVkz5Ae1+AIcfK0D+fS0NWyNBdSZNRQlcIGNeTSjBOe +o/Unmmqmxu2+gMB2SNIOrXlA8cKCVMHhdznRbX/hqWqTcG3C5pgmLv5tMAmtoybMYSc2+bN/Vs6 tPzD/+vM0gxqivySP7D8Z9Kl0an++wAtjm3reuB4gPfn8Mz1Nb5o4msfReqY0paMhgj8R8wUK31a GF9XuN0RLVB4Qls8rMCUoTDRBCyAALCj0JQM/xzzTogwhYdepWBKA8DYAwUxSkcnDIyHWnxO17Di ANIiK3tGgykVpB/VsV2B4zzBvzeRhYuHdY+aKr/J/3IUhJZw94N3CBeV73G+RqQmuMwPG1yT1tmV tK4IQJkqJFX8ESVIdcNytfesDk8r4+nHgXXQOzY40RkMKON59ZNMNtyccGQlY0D7B+0PW8NB7ALu p6gHODzA0m8LQjGddcExlwWUE/TdFUofrkVNV3+Ahi3E40OTRc44xvaKwSckZOvbRRYyi21NyGf4 Otjo9iymLAaOyxmWz85gV3q15FrRFhRTlOahfZfu7F0Dsr53QNxOmIw60JX1oXSUPT2BbIrKn4be 4Y4RTmeGHCSBIz2dGTIqZVW+5qmYUeF4EYcinE2Kw2rsJeHIEo5e0VtIx94tgRYjIATOK4xws1K1 Pe2/YqEIRs/fkLniAhCdIUBLNmq1Bx6rZClz4LF2l2Z+N+A3nJaDiiijXCEQ8v7z9wWQQFiED+fb bKP6BzJQ9orAbYZaTJiUWBZk/CEGX6QujryAjJ2d5T+BH5pfXFAtamabvnqZBgB8YAMprLClRWaD aa2W/MGcJEcMThrFWAex7JrAVImQRMU43Sth16/O1UuyUMZx53xtXjcN69q7cwUMPBvFApu9nAPB 7nK+w+tXQUEqisbtIQceY2WpGiaAgV3L/JcJztkt5l0/nBLACPd8RGFyX16FJ4A/Xq0eZC9FhSC/ a4YEbX1AaUskIo+BY7u8Jcl7vZKwl6aX3OWzG/akjb5T6H5DbOIaa1MQVBSCCGprs1G7LhC539R2 JYOs+MJrEU1BvlKGv++kG6ZfA5BS2M7JkIitTkgzJB7+cBurUKm6b+9T4993CBM/eR2r9CHx8OnX A+gG8w+b/wLUVwCQZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iagoyNzY1CmVuZG9iagoyOCAwIG9i ago8PC9MZW5ndGggMjkgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzNXFtz5cQR fvevOG85pyoWmtGMLo8QIIGiCth1bVLF8uDLsRdYX1h7Dfs7kh+cHml6+mupZXu32AR44CDNpdXT l68v4183deX8pk7/8o/Ty4P0f030dXT0o3WN793m2d/Nx28uDn496Ksm/TNOx9+nl5vPjg4+eebc xsUqNiFsjs4P6moYhuD7cYjb9F3Vbjrvqq7dHF0e/LBtdod1FevQdf12szuMrq+cc9uf0mMffdMP 22e7w1BFGuG33+5iVXdd7befy8PnO1/5vnUDLfDj0dcHXxwdfE/kp094Cr39xrmq7YZeyG2iIrcO Vab2aBeq0Ac/bF/t6qrvQx377X5HC7g2JPqHqm86ena/O2yqzrWNo9fjyLZvt29oeh3cELe30/vY 9ulTQ+Vi38btdVqgGaIP26u8aEur1lUIjgZvnSxVTXv13m1reQpjX8nTY/kJ+25khZOy2V4oyJ8V B6IFNiiT5GPgC1/Lx8BSx9NSTeD926HJs5pALDqTn/AFxBhH7G5o2auyALz/WtY6nvZqAxM7rvVW fh7Lzze7w7byTUuS805WgHX9ODYOgVk7ToOfvUnu8Sh8vmsTISQ9R2ckMEK4/Y13u0NPyuh6RwfG Q/fmUPW51tdcCBOuy1pXs7XoQPrtD3KKTt67MulH2RUO3CbgHp/qU/L1sP2UDtFVoSPZ+o5+Vm4I pClf4Qa+6xPnDpl1h66pkvFI/NuLml3Jz2P5yaKbJG+Ulm4QhWRp8260LaTckV4fF2nXgs3vl4Ib RsUhsoYhtiQ1viP7GcZFW0fcJ9v11hq5ByU+DGRGaSDo+Hm2F30Sv8OG7O3QOxT7u52rK7KWSd2Z obLSt7uuqus4tFnQZyYGvujGlBcRkjs5jmsZeidH/27XVrH1g1oKxPQWFYnpe4XqV0TzviylxJwn ncjIPSgEqPekZckPRNYy+NQzpI/n3+cjadWmr9Hwlqf2B56BaJe9fts5X7V9aPSZFa69siYBr+U9 zL8t/OFJMdhMm4668cz9IQR2Jq0L+E3KCIi6TTxEdTsRxWKBzgR7mo0ODp4qV2i5ohsReRHPaxl6 Jj9FjU7FUwHLgFGwwJW57eMO6gEPGUKj1ZcP9TdCG/St5BbBcb9WP5lCoOXEEkuxkieoKuArDalV kshEqbOeiHb4Hkh9NtIfaP5kP0JHWIofPRcTvUEfMemcI0DYsM5Vcx8SXJ8B2CEPFdGiN0c/MzL7 Y/HmsKFd2jZGgJsI39qmqwKDTfrQlr40Ud8Ql/yQQBU/TEa4Hwia+u0/kuVt6nY0XeSWfBySwiXW 9mSlzohPvuqTQv5GUtbXyYEfl4XejAwlGaKDg8Vp9hDIRN6mdXyYsB+TcZaOiAZGz5Oa7iMB2pYg Rwa0X4kag3/dZFTSRXS18PRcDAGLFmHySeF87BBmig8DHzcZueADmktRtxtRx78qKDLt34MSKosD WMpS7Xuhypg2Hmt5CgNuTOsBfvzdzrVVT2xER6X0dPzurvtAPeTZPwgvImC1wkD4kjXjXzjkzaeX abEhNm1b4KxS+lPx86bzukIzB+gAXBqLwLFJ4RlaLz10si+FVIAcwFX4gJtCIJjkvXUqxZG+fXSK FrAVgz1qu7jZuS1UbnZv/mQjPgKjpD8xMoZKAndWNOVsEa8F5U9HYEVS00XUtGtzAODeK1N/Th5w o2O4pHazItG9sXGHogAhmw1KL+ln41vfqmkaITBlpzNUOlFWThuU1ZQVe6XjEhbfmf516YonyeHt 4f1kRUOtB9yNitfQ/7mO9W4lNixzxNgophT64KmOJLJsfbobqrqPvmfLniYtTXMThHtKMo3vPBdl AVA6Ta8J0gDOutt5RxZwdBGsNvn7V2LBCQ835KjBP70WT/Q2i/IovwrHLlGkHQy6BO3JA6OnATTo ak9anWIcI1a8xwhQLTrO6pZCPIfBe7R4vJdSKUPtF1QnTwLiVo7uF6UXPEdOERIJx7aVh/OWLc1g yAh24JOOlTTzUlcg7YUS+SSYfzs5qYHgVF+iQRFW2B6WX2ggO09ZFZJUC8G/N1NYEFeLu6uM5bsx JSLOnTeV7Au45pxvHPz2M2NSt325nbYdfEPTCq/A+2TWJIFs/MSfXzHIs3IqZ+B96D9V3YzhGMu0 qEz+aIKac0EfZ3WA88wsqFIUWdRIkqY1u1A1rghaVKZ+4W7YHzElvVKT/PDvJYMyY29+D2hCBAEe Xpvnn+GgH3CpNbij5D9/YatUJS8wiUJH+vWZpNTS+0g8ijOpVmKfF4C9gHEg679kx0O22EFmheeD sItVMAHhy50wo1A44NhrTOjwtHPlT9mEXJT3bw1Tdgy6/j7emD8KXNMkqzEqJzTyAp0QaMwVaoyF 4iQeSjsOFCd2ClWAx7k1sx3iUgCWAPQC52EjIJUjYWQ9s0p9qOLQUSQIjh9CtolurXZt5bzznaaK H8IcrCso85Dfm+5BIxweem5+3zwFlmRrZvTz/BtDeCQBeiby+NaS7Qexw5hlH/1QpLi79ag7mblg HewEpKlcdgIIln2KUfF1pD3QP0thx3y9mtbin4WrAxJgQtCbNVdsCQBDHqWTBSSCT8tsRrXks2pc cU+on3a+4gIdoeHTRP3eLwM5g93jU4Wry2KmV1QLgNdiOH1uWro3OyKr8W5Y2hI/dDi/tdKaC6+G RkOf3yslX7zAjZW4L6q24NpcUlVYwmse7Q5j1Q2xVgH3HoHOrBzZeK1Kk1oSj/rAaqklmZliZy7s GqXKZ/ACqia3JMXeyizBQOZjD0pVPhpsnYIahnxdmwQAWVJYAPqBQ2+tUEAFhlZlITMcFRTgpe03 01cPRODAYA5rC22/KKZNUeaNpUAgwJCyUI63hE8X9qpGPVzWXzjYEWyeWSs9oVoAwjgxoLOdIQy9 UcfKbHu7IqFGSuYasdAyiQC7ZmMTuyVwWVQzSkJHpUmNSvQFhLdTAEdM9gNr6MJAaq2C6BmofyEI viRUIY0KLFPoVRwsw6NDw2ZhspaUz3e+c2vpWgm9po9a0QIBh+C7oJQGfgr0AdClXSBTjoyMQ3Qd pi7QzCYqM23fpALNX/4/9ZnQk799oD7jpQCz2cWq9U0zbL+ZqiWhbqHEggUYrtRcSVnlpzIbHl7I T1kdyjLPdo54mGzxt6XQ83kpDj1PbUpdS/z8WLWa0A5cvYK8wa2ITCktN1tdq+GnD9VqZlG2dkLS D1Fs6O8yFm2kYYPtnDwMvbLAFTRUzEs8HNDze1XiMTNvYI55kuoOACdoZXSe0B5gF3t4M53c4qdm qlmCjgv5WNvgwsEAELzO1ZqGCCpIB3O1PAeEaBFIznGOImAk0CluQhuRpCx0PWoaGuzwYhVTMrE/ WxxaDfWk28UI5mwhUwGUeZpSxplYi4k0iB9Ky5HdLXEK+eqSmb5BCQbEwnL7kxnzm+1BwFRQMcm+ raFDIxCw8xPKJS8zdUD/Keb1geflp8rfrSeKNVW2qNiNcit+++EiK7tFVWMtq+uGOC6yrtUdp6CD 5CQ0EHQs64lmehFUXWWCHql1mYmuChvMMjSfyPqfdGY83gkckrXOrQjB7gR+kWJAkibnoPv3eZL8 2sWE6xpHvnjsVJD5JIQ9aXioRys9Po79CIZTV7EbXMqXHhJxdeo5u0+hM51DynGWeW/SFoQxGzWL ON5VhAZcXGtLJuDQuzjWp2HfjwENyFiRej+xMZllFopkABcW/Ri5J1GC+6XOX6N1sErLi/7BtD4Y PVXkMszPY73KqjnTaOzQZXCDwCvb0kD/nm1prObZSrTSIRhgvosl+lsSob5LyMZZvVqQG9eJfB7w QvL/dqQjOQPuSO5i6Ug+XRS39Pbg1Btw6mwfdfKYf0I/7x0mcpa9zWDIzDTKiRWE7tG4WQeBoevD RX2wk+844a+AnJXPyBxE379QnuTciaIuhQvdrGdl7G0lS/JP+unp7H2HcnqCYjjNnw40H7LlcKGV admmsGxwYhhmO3fY9iiZwq4NPeoJBNywg118gLVWMJ/dHsuTAJ/+y+wX161RPM0juxndnc+1PuN6 KV/wL9A5k2qVuwCqe1d1wzyPPSndkKZKSRqllol+NGVh5N5OzVilLBoQwDQIYFBtJ3lskzw2vqLI usV9BSF9Y+7wcstxhY3KljW1wC7wkPmCSRF1VyZ7rEUrYQvxSO1ZOrFXyqiGzjPvMADk7HdTlxR4 5lmn5SFI/6xxJDRjDgwyj3uLQtAkswflwWpoaM1q6NqVmrLpampYqJ5n8YNaQNzYF8JAsFUZh+SS Z54EIgke06+EjEzK6aRI/Zh1YUWyO8FuLO0Grh2vo+vkqF7umIGVMmRMvypDrJQpM9Ggs1BmtNwL nN9pcYTLIvaTOvkzj1CpRIEgZQjgD56WDqlSb/RaZNk3m50Xa8nsWev7QhHgvX3dRjyZ0fe4QUGe X5qLa+UQCS3tiwpryCo/Uzlk4/Q+GCTyUBMkNvORdKZPug8ya43lFFFfxVgaC69mxI3XwzaoBdls T7P+FA39DcVtg+eg0ezoNzLGX8n7yzF/25KY3xDLOopJfZJdfr2X6Zcp+0shWDeJ7tizD8njuxTj 9X0dxxRamXVHsjPUsVP9/ddlq7yADxHIu5ZVz8v0jUyXNV/NLgrEfir/pZGhbnKa2zfeoNS1Y5Cr 7ymkPphzeC9p9NPyq/CESzZ/dDCbqiU+J7q/LMEs2/BuWLFdgLglx8Yl/AaTVR/SK9NuP8ECMzS7 8Xu7bH5fYMKyazK0nDdMI2F9tRTbMRvnA0y4sIKHVxZyVFnuyWR2CkOrO0qPx16Mfc3YyzRQH3zh jre6L5Cg7gskMP08fNbXUuST9+9xbVZjAl4VDLSZelOlRTDRZVsZanbWXpgRg4qeAKmtgILEJQQF Uz5hTE4Dll7VLNc0YzlaNAtgNyRychdC86QaOy+qckbG+0VwlNo0l9FR1Fh8NQJ23lcpgbdMb9C2 P6qkFw/l5tqk8XB32axECC48GsuudafE6VFgYbR5mLhCX4diXinqLHWDBMiXpaUYAOpUhCe77Evx COC1Rb0kb9Yq60aYmhpDx5p0O7/YxV8ivYV35vu1ezfYz56HnhQjujdVxYbSmQmoNdCkosJOM886 9fC2a13K8+RHlvnc+HusRTaHH3Z2E3NB7G2WVYbQYkZ3Ft6UzuJ5eLNs2MwEyqp2bQhMGQSlGEfq vttZbkVVmZaBFITET8DfxlYzQSkDWOaefnvsMoNpwkdN2CwuHqx909y9Bae5W97/Xj7K1qSbx5h2 hgkx/tJ/Cycf/isbEKf+B4rIsxb8YN0CbPlE4qyqK9nUiWkr7ZslGmUHAtAJ9W9ZaJ2qA3bWhUNY 9WcaHqsZzHLakDZZXjW3LkLc4QCjMQKG3j9y6/zY3Na+rKYK5NLJbWV+VG6Mh6rME7R6G73K8Ac2 lG35k7QWedeTr3sgUvTW3W+IFFUExQHYPH5K97ytmAmjw4cCwan3qLwn5Wqq2PdTA1q+Mm6GfxI9 vtj1VU3y1+YuJd8P3JvUtHFMS/EkiFMxvNM3zqfaLem4g9JtUKVbN3jCl8xbgrrkOseKc1dFsqCJ t/KQvqINfcqFpKKrq7up5kNmKRJJn+4crUiHO0LdPP2WhzZkbEnI+sYn4sc12xG08sjXZfnRRBH2 InGUNb9LNd3e1X2kkx1Hth8phnVdrGJOTHBq3c/gQcEx+dna9XQDEQO2Nf+0hR3hrqTPSsZyhjky 9uWgKc4u0Bvpb6AQkuprf+ynjIX7ofMLGUEFwypmsLtAIOrD8KFg1rFlM3q/2hAKYGKlvMLrqvLK SgI73zPkat9YtOL7tZ9Pl6ym9gUGDt+YW60n6/Mh2RfvH762awKnO01/loz369ky4rqVZHm5XZWZ gEAADkiivplYlbtvTbrbSIQ8oazKJMH6j5dVmblS9ZGWBeXuHvd83x/8F1y2UwxlbmRzdHJlYW0K ZW5kb2JqCjI5IDAgb2JqCjQ0NDUKZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAzMyAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nKVYS28cNwy+z6+YW2cCrKL345ikQdEggBN34R6M HDbrtddN7HVs59F/X0ojidTOGA0Q+yKTIsXXR3L8pedMyJ7H33LY3nTxL2UkNwIOVijpRX/6xyL5 /qr70nmm4k8Sp+ftTf9y3T0/FaIXEiR0v77sOAshaO3TDdF7x2zvpGZG9uub7nzQo2JBBq4HNq4c M0ZZM0hCFCxY7QXQVsIwwV0Y+nElLagwcjgbOXPcWTGcAJEZofXwV6XdgbQXXothM64MM957PWzx uJvesTKqTI97O7yu4j/wJmr6XC06RBnHOTfDPRjHpHGSqMw0Gwxo/7B+071ed+8hqjGyPxNG3wvB rAsew6hME0bumNdTGP8eVwrcD9KDBSAnLJgKTgXmlTN+2INT4AeH46byv4EQc8LYIyEFiQ/g4MUk ZCEoOzx+Gy0zVktNiZ/HlWbCeEjeIb6qgpEpaklrlK/Ei0osTzlXjbL0/TOIoGDaAfVkFI5JbwJk txJR/QYt2U5O2aCyfUqr5JWEmhfOQ34hLyJoq2OCy92sS+noitBMx1I4VCIk0zKpbMpw1Xo/asa1 klT9NYrfVnHi1Bt8c4OapqDKECixaAWpR6BqLSBZYBS9UNQSsW3VtU11Jz1UgdZQOOsLKJVdteoB TSHHRmm5ejvlz+qQq+LYwBugKmmljbmsd2/xLjHwCo87GiJ0th73lb+QTOBfTiXupYDAW2hqClJQ MmjF3FmtU1MBiEthMzBXJUIroSDKU5j+TBGX8GC0p+AInvaCueBinlPFc1mDN5kWJONQ0aU4c75S bT5U6Dwg9K4ROh8XAUVgVtXbeUUcX0CcLfOJgj0FOgFiubotsVMFEsC/iVEJ0K+b44GUDE1YUYUl RYBKTLleQh9R9VCLmyglkFh+tfG1rSgTdHO1qaiagyYdCVTWsNSOU7EQ+DB8qhaLy9WUqOSBxbgQ 4hm2qpPRMc61o+w1tB/tdZA0AIelRkYswQB+RaG7xSPRWjvdI1q/mIqLYxluA+0IVzQ/0vkJf1Mw I/yUnCK6wYF1i8cLPPaIT0Kd3oRJ3I4hUv+00kpKH5ucLaQfgUsUELWHOj4JsFGIFPXHih+SnhZ0 +fkG4At8Yt5t5ZP0oNI8vGCVaMfEEv6If7MG0VYCqY6vi/ndk5ImShd6exNpMoiq1PdRMg2vanAg oc9wJqUo8Pu3qcTs//cxbqEe6qPJdOU/Zd6c346eo/iqozWiXm1WotppmkUCt4scU5bUa56MmqCR PcXRBJz1P2WZjL+wlDuY2DrYXskYXNcrLngvlQTmrrt81sFG3k/be2SJJAZsAas4NO4kKAIsm/Fz 4Pmp0v3vB1D/c5fNdPnXl1oNrsKHgvKw2tu41k6erpRVjPvYHuA7xGMIckTexj9/69bPzuf90gSb FsZMvJtvwWm4gaYQjD2atMBlXLm0MOaN80eFNAH/LNGJSkC3iETywHxlPEZy1Xo1IQ22s1w0Aj4v Nv8jRHoSefUduvW2VuILDBZZtHHQkDn2qmIyKnWaKeGGc+R7hMKHpr+Wu09sl4loAr1J9gvSwD5V 1BOANkOpyD8mLCkOVtSeQVpai++nswKWzgLc9kQy6HALf1zs2U8tSsVm/CA5UO/Ixl70Z0O1EGW6 kOFvj9wrIzcHg268uWEaXMJcyEMgjdl92WjJd2WZTHRHbrZJgodSrk/NuNk0baDVFHGVIkOUxPbT /MO2GZ0vxhA7ivT0AfINiUW4CE3y/jkqtZXflnvhH+btnnDX8X8NLhgucNV7h2BEsBGEEpnGpHp0 ixCcNlTJQ54xeevKfbTtqmnMwBzQQU9dOh7KHBBckTlg89D4pRlguIfM9ELK/K+NPAPAXEioTzPA H03B991/pUHdW2VuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTQwOQplbmRvYmoKNDAgMCBvYmoK PDwvTGVuZ3RoIDQxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVRNbxMxEL37 V/iGXbFTe2b8xREVISEkaLo3xAFCUkCNQlI48O8Z7252XRGkSiWrSBP7zdd7L3vQDjxqV59TsN4p p1/L91YdVAaqn+Gijdc7/bJXl6usvYeYStb9VjkopTCFAeF1ThB1wgAUdb9TRtv+u/IEzLp/q/qL D6a3DJwZi/lqHeTMLmSzsVLSRxZ8VyBTkrM72zH4kB2aTwvy3kYIkZHNzxGa0UuWkw4++SDQsVI0 R2nk2Jdg1raTEUoJ8dQz5mi+TfVjkFJz/mYBrM+1+tXU7yIgCQ9t0ouhFLoiQ33s39TdCevu8vuZ etWra3XQFNxAv0aXSegqMlzUJP2F1yrG5YpRX+0r+ElyBJcgoWYOkBpBOhkQKGTdeQdREr+cU+q9 0Aa+sMgycokhmf0ixY9WvzlcoA2rwrUX2UkI2swE3tuOQG5jngSsrO0XKrf/EHgGNKfbB71Out4t YSPR8wWrz6atLILsEop5Z30CzBJd2S5BTkxkbhZezs+1eLS5P5kwlglKTH7icAib088jR8Qtcc0y f1m3Mtcc/rY+QmaKBtpdqx8XG44OPN6qRIIR/yGSdE0aS2TxFCd93KjthfK6PgI81KvJWp7zbFxJ dItxaTLuo8A8gp/+4mEmYU9jTEJ943QKUV43fnB6Y/TzDBQUBuX/gIR16kJnGCD001KF56UKEkRJ HJcKMwOPAMf/xQDFDINw7sHLd9j0Wv0BJO817GVuZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoKNTUy CmVuZG9iago1MCAwIG9iago8PC9MZW5ndGggNTEgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJytVdtOHDEMfZ+vyFszlSbETuwkj5QCUlUJla76gvqwYpdL1eWOyufXmZ1NAmwlpAJC Cie+HNvHmVtlDaCy+XdzOF11Vh3K33l320Xj8s940Z5PV+rTrNs5jgrAcEhRzc46a1JK3tFoASoG wyogGcdqtuq06me/uv1Z963L2RyhJZADg8MI6vhwK3z3FhYAClA8fGXhY8uCUzIOM4sT7XtnEibr temHYIgck8YGBJPYR9CuH4AM2JCE+oDsxRb1bg8SURhkcOP+ox+iiWAj6SMxNQTe6++9NcEGBn2T LYO1lvS8H8hQjNHr03VORr0spybmgRCJED3oywr+LuyWNdCeEDXeOtYXxee6prwewURB31efmvIu eyNxIsn+c/ZlM6J3kwBHNKGRADjjZVJfu9nHE72fs0Py7PVTPzgTgB1IlyQmCLbqh2SSlM7SRGuE OUeWLgzeAEVpyHKNQpTYVuJCgLHi0Z31mUxDlA3SsOb+oR4vatRl8WpMZbKC+iDoUR+M9DOxTLaQ vilO80zVJcI82bES4rg96EGeQ0hkx9luSpGqwBvvnlHZ61FG652fmDrv8nC3He97NsSYUtZGpsI+ yXS9EXds01/WRCtBHTJymPo7RnrV3xFtbCd+wuqq3j/krNFFhOZ+Ue9VvZ9vY/3sPgsRE4rYWZQ0 W8jiXrWhSjG77SyKwU0h8LqrAjYCMGNW2R4/yX/YpB0moS7ap+tWObLje6nQspP3TfSZWDkX5c0K +fXcOSZUn6+z8X8tD1nZYFQy/bo7g8f8RkYhJ7VWbmWn5N8P42JVta6LRemLaGit0UZik0JQngc1 LUugRoBPVcvzAr51LTPajPVPn5/pSNTKvpHNxbZlmW8N9VjRtYLoX0nnLy09+im+jY7avX2lMLSp FVhTYKPgRZFVs1hXBWyobFXlYwHPa8xnkQpqCqm1VMdhy+jzp20a/UakGPxaRl6+phuRgiOqInXv IVL5FIkOgaHRqEtCHd2oUY4vFuhb9xdvbLesZW5kc3RyZWFtCmVuZG9iago1MSAwIG9iago3NjIK ZW5kb2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nMVaTXMbxxGtXPEr9paFq7Da+dzZ3BzLSTmlimMa5QvtA0iApCJSoAmRivLr07O7M/0G 2xApp5xIl+V8d0/369c9+LVqG6WrNv5PH5d3i/iXcbp1ij68Mjqo6uyvYvPD9eLXRWhM/DdMx+/L u+rP68WrM6Uq5RpnrK3WV4u26fve6jAMUVXoGl91WjWdr9Z3i/PaLVdt41rbdaGuliunQqOUqn9c 6kYHr3S9gwGXy1VotLGtqh+Xq442D17XD0vVNtp3pn4bx2qnetXVH+KANrjO15+WXaO19Tbu0DV9 UMrV90uSr29JsnrPn7ewAq4GO3+aDuRCT+v9sv7b4tv14gfSV9TZSxQUKqUa3/WB9WNcoZ/WNpN6 viE92Na5vr6hQ4ZA34HOSwsoEodOqGxjTdfTAX3jvPFRYcNAH3wUt2+CCVoNMk6tV9xaUau1qiN9 fODPGx67m7Yq1trkxkce+YH7b3L/Ljaa3mlbv8+NMJIEsI1ywbuoYdPQ7j6k9Uloeeg+L/UeZc3n v4uzeme8n5RhrFGThnQfVTmcyts+bWXstNQwErY6jKfyvcFVx71029cXeT7sBKf+ONyfLfvhcxJA hfpPfP7Rql6duR4tRXWNo9NXK2Wa6FvbRf2H5fqfxwblaD/TRnuiEeeDxXsy406jsvbyteb+R7ws TWihwguuNQuQ7DJo4VpPDPXza1XhhCpWScjfrIv1kjYNttf1G5b6RzpLo/oRKPIJP2YXBLuQvQVm 3XMr6PXA2oBP3gG89GG58oQ4JEm9BXXkDX6ueQBr9mkZVdL3Lm1bGPSAb0kE6GcrvuXr2OXGn5ek LTJiXQJK6n446u1onzVBedP1jvDyTR4Y9asa21lf6lfpxgdrSv0eo4kpLuWS/XLH3jzpzNMFFybm Kdwp3SHyFcgTbYwCSOONSrbCwABH2UlHoYuI8msbUKVPfEBeCoy9uIjUf8HzoR/ggoEHgGnP/XvW xXu8vtFSbIKWle5M0xqL/lNF/5kiWfxPsb4ztFvvK2NaWqqrdCD9aNJk9bBbXH21oEBfjaQgdo2E groNBXhCynEicYcusoxXZ15Vr/e0/MsG63Hwfx9RLS2vbWV6S4QiBtVR0pWxim7VkApIe6wBUggd bv0m/vnHrI//MUGKZzMyQYqMRBuiHj8tKSB0lnzpLbQeYDTylwumOG+ZA51iOye40+/BdYwm5wmj qBMo64LsJAYShbeO7qyz9XejG5DJ13+PR6U2Y2qdUfAfDDQGI904352A2WsRsjnAgff+e+AS5PMY CgHR4150h663gM0FWZn6HQLR2ShLDATfk9pbusb6dSYQBXrm6eD8wGAKyMhinyAjCSfejee3pFXY AGjPoxQmylhOoviWuMKKkXiL8CfwKoByGHCPUBgNz6ieDDvjM1wGIx3gL4SCT0vlm8GsQKyPrGsh kr3jM8FJb0SgvYeggLc6HM8X11ItdRcGAE7SMACf13/J5r9j87/gz2SqxiXeHVs3oi1PMtshKHsV WwM5SB7aip99YaGO/NV1Be15Lw4ACvUpO8YeXSj7CMwaD04uosDHtsUG6eBMkDACQ7fAIG7FT9gf DHtz7AMjrxC22mBjWukezW6yIJ59YLfaSeEZHAjst3CrgZ90IWZ6yf5lvy/Uy6wi78qm/ihuBfML hpsXEJUCax1O6C+tCscu0tCVjbE/oFufZbQawVCrvkDDPkYoHcCpkopWUxCfcGK4+zbnP9FpKg4g H/iziDrS2J84QQBLG+9c9QVr5QwKHLQwxKzeUTzX++TsU6aQiDzn4LxTwfOFxHoPcwAIk3M2w+5t MIkRTjD0/6U92rlGj1TAy2Whb6ICHbVqkjA29WHM3CducwnTbpnnPPKII4KURkAJaFououjvQ3nI Z5p+khPM8yyDHBvE64nduDI3XWlN2RURtXO+cZdv/JecJMDIIvYmM4j9xtEROzAyOV0tAkqaBBix LzBe2PUuqlV7SrMwN56lOUNrUcARCjQlYqXTiLWcLaJQGnkPET97B0DTk0hJtjPSZAvAA7k3BSSn ba+RP0ifW5w2kB5KvJjzyDkfqPARgopcOIOgIeiluM9CgkmunbRAgirfZ9Qb+BcZjFPFFcpb3aBe Ja40KgGp0giE2nXZ7oJPVQyL7OiQy6KpkNU5oBs7tPXkFSWPLyPXvIB6xGeOuRGEDHZrcOaiTpSO dYmUYWjUxVnA7Y3g9o14Pi553cwMuQzSIrcG45MZS0m40gIbiecURT9NSU1M32QaM8OtWMCF/gO6 6ljH0Y1qQ/IZgJJ78azP0LxTUJL2v5TqPLIoF0ijpAFbBAVeSyZfaRIndbPypCW3RfJ2gv2BsWQm NSkRfW6eCNosvVFInlIdkD7nJNsW+cB9boQAMqP7BfVpuMoI5cjv2LqOosNUvZ4nn6ODQ8WWjyIX bBNAgPle5EnzymlZXZ+Ts/EeU+Mp/4Li5pRayPIVSZCQnN8UJnf0lDMexUTiExQ4WnF94D2poHo7 uRwRHp1dDg7Fby5i6JHrsdeSmUKgPpUlPR/mplMVmWfW71a6ledu7YpX5f5bsczL/eyyxU4vDohJ 3+idkLA85Zi358ZbJpoQHiH5ASZapO5gykeS2uNIKIoihFpwOigo7PAzY8E2L5AchDZo0AOOns1y JrP+6rz+umDNCZSgPPgmIRmMhEIbx0zAF36ThQePc+4PEJKP1ROHwpMYa7KIU4ApyXr4EUOsTQqY 0IU5n5se/+SENN8v+zc4VVEZOYaSKNaM6dhuTnSGSQw6lyfKBUmAb3n+v3joveRpQhVvh/CR36jG YgqxUOWhmCgUJsGin6twXIlDk3bNlyCKVEwqUpOEqADzDF3zq+GX3ePWg7TU3A5HNUdBvLInAGlS JwLShlGGf5sAfCHX9Q/cJgdm2YqLAfBY+PmfLnAQL+4BSqiJZogYBJteIbXgeJi+iswC6uo4/7P7 w1DJs6D7a8YrvjKZ7MJFc2j+bfEU/KCAYyBn0TaGetIRFMONv6AQlzJKuEWoJQAanqpTHz8al8AL Q6G/SKqFHLHIYACPpW2LcJls5tlf3nyOr2pKoJnvwfXAAwbkSkwR+f1HeMgW39zFXPCdCJIygxEf 0iu0swGQXdfALzWOa7/5IcwHd+JnBKcwXEpVofVJgvNZzXRUZJ50LeVU8CQkUsmDxIVndvbltDaD 8KRCBOErJj3ABbl68mL3Q0GKop7MWuaZ0Ow3WacJDLj0C38oJDscETTZ4TZSZGDk5eUhY3+UgK9k XWmlLyFC+XPOhOwRz82SAJKyHWxF654FmQklRg4Unchw1ib9fm6DNpc/RacA2iX8vA6KhFjbkGgV qHL6bQ0t+n3sJ56hNQQ58T0te8RQt/9h8R+iy9tLZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iagoy NTMzCmVuZG9iago2NiAwIG9iago8PC9MZW5ndGggNjcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJzNWktzFEcSvs+v6NtOR2hK9X5wwzaBTbDhNSi8B9uxoReItYSwQCAue9tfsPuD N6u7qjJ7JnskEWO0EBA91fXM/PLLR/UfnRRKdzL/rQ/HFwvZPYV/rxd/LKIw+c/wgj4fX3TfHCz2 X8ROKeFDit3Bq4UUKSVr3NBDdTEI3wXthPHdwcXil+X7fmVEUN6o5WUP45S3y+t+lYRJLvrlVW+F tNqF5TF2PK0d93oprFVBuWWXx0QTdX4tRYzWw/BDfCwLOR+Xn3svnLfawqg2wQd8vMRRZNprOled gKw12Ux7fNWvNIhRRbU8h1FKKx3oqJthKueWb/qVssIaaDsq5/MwpDWetkYy+6/LQT4queVJEVrb lLEgqle4f1jACgVCdcu341zG0sYPvZIiaOXpVi5bz7c4abcuqvWlSIcLeDTaax/oWsfDqXVKRcFG V6GruFz1vx08W2jrRTAJUHNwQnCSDD1eG/0RX0+WIYPqQchMv/Z1PI8kciQUBNHJOS5FBPGpV1r4 aE3BST4mmZQA7QwHnbLiJa3khGQtsoNrbCVLvGG3OKfMekaC2q7XIWaFrKpGVsrAiFEt40oaZiqH sdJFNNBy7ABth/h6w6izUZ41fBP4fVgXxWAzx838PrDmedWMYs48Oa4ga5FtCWJsfZtX9Jyt19NG A49ZZE8OFj8tMo0ap6VT8OCV0VF1L56yzVd3oVelOuWEM1kFlV91pPzqoxHajvz6OFt1UjIs32VL TBKWgsdVgJmj1yCAVRSgPzmConQ4wUfQhhTaqaQCkFXrDLDQIhnQ5uNee6DzpJeP8rQyujDwZhv1 H9BnENHFAH2NAFA5VXajnPN0Y5PdRABgipbZjI5e5c1I4aQBGNflhvaDHsQTbRoYL4gUtUyDcr01 Ngz22/qekjn+C5iHdVKKU+3tzO1570E6o1r+3WvYYxjsL69VTOr5An7/ZfzvocADeHF63OWLpq4i KBtCBHIYZCnlBD1XcCJnorQzkDomM9DZ3pdnF9OfJHeXqjnAAgf/HIeAq7P5mG2ImgyJ+YijEH4B +IKwrU1LlSESZASI/NaDqasUMvSA7gFOEcTlAeYaeEngmK52/B7anLAJfP0hYNt6p0eUj0+Z9YQF ggxZJDrzk8tU1x7Phq4WZtqjsxd2BtVKeqqQz6xCdZ8vshswJfhohyALXWLrda+S8CZZ0Ck0au2V ohs5bXvucCN/7VdOSG8Mef0BXx/i9CftPWksXV2kwumw8dUo5ez7mM2RjmSiM5x+Y8v5/c99gHjH qEBlT2YlU13jVIdtA+fDnrwb6D4rOcLpfxz8bTLSQRi3LuigyU6u4CnZKGN27eUtL5FLMqbt7nPv pBRSqlH7E0hrDRZhfVX+XttdhkvIeKfeCSgkShkas+DvO1HK7cbkgQ4K751tHDCjgzy+a2d9hI37 7OOnZm7lCVwQPhETJOr9yCIeISeqNQdimiyiyUa+Q+Mikx73WVoQ/gF66viL0UpUstQM307mL8u/ zzhzEl6Tlc7xJCNUFKCXIGVi23m8UrpOamCiioMXTUxot6J2O2sIJzNftH7n4Pl1w08wsrMhDwid ihqSu+7qdPHqfvw9ix8jIeTUBEEjg680LKit6/KOIUUdUE54Wj88T+eue8zsU3mvv+WRRLTOouZ9 Q9rvQ+gs8/jPDT+TbRDChmxUae0o5sn75w1fCP9LbnUikBmiWfdNKjqhfaOnbebjIXfaMJ/BycxY T4ErofmXjeabIVC9Er/E8AEh3BMi78rXyPuo10Nua6TxNXVL1dJmTkbIsi70iD3kU3Q71xPNFAd1 wpDZOczpk1STjm/p7rgDQ7xRvc6qKjKPzgWdrE32+ES2BGJ/y2mWdUo2OTtriLebxBxM/HDNqem0 h5yC8YkBIlEvVQVdM7k9iv6v5BYVZAIJaM0a0fwi42Jud4vlDPt4hk+9Av3ooP58p8iAc79a2MSm K8iPG4wmJq08ZAvBEbyxJo0g3MdGxDAfOk0cYiUU8h5d4m0s9BLBSsYjGKdgzvmclIY9vKAhKh4U NqKV9CCRofzlIJVGjpw6XQWZcwdr2ex1tfJ6t17XDgk9wrM4XWMgYHVmYu3E6ZptTjeQaPtHgGOK Slkq03cUeEwMdcp71ZL9fA2bdTan6M6oIVMfjZYGSuWc9zLaL7PFMmrGFjdX+g4jGpZceQfLuMiJ NVbDQBMiCdHhxIIHSqDuhFriWmg6g5OMde00kekEJpheVZWQcJYhk7lwVoEKO2uHigLEs07uOJ4N fgqiGs/GBE7VzZmWvb9pHWTTchH45El7+23zA98j2T2YOZkcuTtQl+Ryw3LKiTW1148Yx0fMiZgD W8sghvWxEcwla0OnnL2UjSY9cahslk6Cvf2N3BvE7ztrZMxgiwCInWJNZ8IiAi5Qy7FHTLNQc9uh 9mb0tyGRJApBR4gGo+6HAphVIoETGzNIhq+5IItHGMn4t0ZZtU1QeXGVJYK1k/UAJWORTDCDqhLj jjAC3gSfDQcFGIUYdwwj43M9GOVYcWSRsrTdwJHfjqPHDR4luTVmpkhIJEg80R7O+RUhBQEQHNUm MKxbOKsc884RADn6Ro3nTgIhRHTdCsWrVmIkpQoCeAKpQ4rD1veorfqaRCBl+60mS6ZhSE6BLK2S Q6yavOn8bkkux6ioEUJyep7kwgw4y+vRd4aUFOE2Et+jH0UYHwwhSnD2obDpVE4pbRwLYrvEJqW4 FjawbMejjEALa94Er0fce1KSmPJiuyVgcrQW86Hb/53LGv/Va5FviRKJA4+4MBHD0kk5vi39jtsF E/tyvh+SO0gR5RBoOrXrwqkBu7AEDjXQtJDaxTnSjttJm5jA83ZGNIGX1BhK8PlDnebb/5eI03rY 0a4jTrQlnr0RwmT6N612QWJLYhdzt3NMQMDlyeTKbHtgetrT5HIYsuXuYzQLNpQ1MNsAZ2XDjoOQ BK880V2FszQirzzD8wkD9Vbv+2F73vR4Ere2wuDXDDLyZzCddaFdw39hcXDLndmkKPil5UESexTZ ssXjSUWCylHJZCAjTm6IW0PaMWS0zVf4KMcaGpiQP2yagwy54pfbowRSvMLrtG8eHj7526jOWpdR tOva8hpkZpIeQlwblyZrl2UEcTMlfpI/E2asdEcY7Yh2rW57crPB3EaQRW/ahWmjQZTMGevzcR16 /YOBeuV3Yhf/oAXjWtQ6JGE22do0yQO3DeGFGQtTxu04XnB+INgGm0qwwLhGmbmAgVjL3Lcxpecz 1PkkHiQOaest44NVEcKQ8hmdo+vt5tTi6hp7EsjfEj/QesL2EJsAelJQYLC9ETePVartwidRMovf E47ib7i7DWInE+up0ml3Rc9I5HwPZEysQ+sAGE5j2dZZvdss04D6dSQoaNG0zVq9gy+Z+yKh9HyM vuSmaY1NgcggzX2Hha7oCc5JI3NwhylnPg/ln4ITOlerspfaUXRT5In28p51MIcshyP3blZ4Z6Lj 2yu9XJp602C++QkJWI7mTFBxjkNxPSc34NvvPFfYFT069vzCixPrZWdsHBOAAE5ktxYY1ZC8NdxU C8wOMYY7+Ke568nS82e0ltvvJ9kPFLDo1sSLDEq+v5yUy2sjWijJt3EhLE7cp5CHWSHp2rG+4G3b fjeJnQpMZ7ZfwUPkBFySVafd8u8wexSQdQciByzHYNseoutrf59oQNQBYCVhIHtJMBgCft8wqQgw VaLm0/g8a82fm7tcD2x+g0N4iLncmvDQF4XBSATMsZEU3rGER3Pq9knSNjvSdnp/65wDHYUGAO2l BwcchyxRebnjyoKTbsiXGgIKsVjQlUo0TRxflJ/0Q/1CPRvf7v+0+B9UpUpUZW5kc3RyZWFtCmVu ZG9iago2NyAwIG9iagoyODg2CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvSW1hZ2VDIC9UZXh0XQovWE9iamVjdCAxMiAwIFIKL0ZvbnQgMTMgMCBSCj4+Ci9Db250 ZW50cyA1IDAgUgo+PgplbmRvYmoKMTQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRm9udCAxOCAwIFIKPj4KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoKMTkgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUMgL0ltYWdlSSAvVGV4dF0KL0Nv bG9yU3BhY2UgMjQgMCBSCi9YT2JqZWN0IDI1IDAgUgovRm9udCAyNiAwIFIKPj4KL0NvbnRlbnRz IDIwIDAgUgo+PgplbmRvYmoKMjcgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRm9udCAzMCAwIFIKPj4KL0NvbnRlbnRzIDI4IDAgUgo+PgplbmRvYmoKMzEgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9JbWFnZUIgL0ltYWdlQyAvVGV4dF0KL1hPYmpl Y3QgMzcgMCBSCi9Gb250IDM4IDAgUgo+PgovQ29udGVudHMgMzIgMCBSCj4+CmVuZG9iagozOSAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL0ltYWdlQiAvSW1hZ2VDIC9UZXh0XQov WE9iamVjdCA0NyAwIFIKL0ZvbnQgNDggMCBSCj4+Ci9Db250ZW50cyA0MCAwIFIKPj4KZW5kb2Jq CjQ5IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VDIC9UZXh0XQovWE9i amVjdCA1NCAwIFIKL0ZvbnQgNTUgMCBSCj4+Ci9Db250ZW50cyA1MCAwIFIKPj4KZW5kb2JqCjU2 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvSW1hZ2VCIC9JbWFnZUMgL1RleHRd Ci9YT2JqZWN0IDYzIDAgUgovRm9udCA2NCAwIFIKPj4KL0NvbnRlbnRzIDU3IDAgUgo+PgplbmRv YmoKNjUgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA2OCAw IFIKPj4KL0NvbnRlbnRzIDY2IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMg L0tpZHMgWwo0IDAgUgoxNCAwIFIKMTkgMCBSCjI3IDAgUgozMSAwIFIKMzkgMCBSCjQ5IDAgUgo1 NiAwIFIKNjUgMCBSCl0gL0NvdW50IDkKL1JvdGF0ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlw ZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDczIDAgUgo+PgplbmRvYmoKMTIgMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNyAwIG9iago8PC9TdWJ0eXBlL0ltYWdlCi9Db2xvclNw YWNlL0RldmljZVJHQgovV2lkdGggMzAwCi9IZWlnaHQgMTY5Ci9CaXRzUGVyQ29tcG9uZW50IDgK L0ZpbHRlci9EQ1REZWNvZGUvTGVuZ3RoIDc2NzI+PnN0cmVhbQr/2P/uAA5BZG9iZQBkAAAAAAH/ 2wBDAA4KCw0LCQ4NDA0QDw4RFiQXFhQUFiwgIRokNC43NjMuMjI6QVNGOj1OPjIySGJJTlZYXV5d OEVmbWVabFNbXVn/2wBDAQ8QEBYTFioXFypZOzI7WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWVlZWVn/wAARCACpASwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEA AAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJx FDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJ ytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQF BgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3 eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0miiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKY7rGheRlVR1LHAFZz6/pwYrHObhh2t42l/9BBFAGpRWT/bYP3dO1Fh/1wx/MilG uW6/663vYR6vbPj9AaANWiqdpqVle8Wt1FK3dVYbh9R1FXKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqKaeK3QvPKkSD+J2Cj9aw7rxloluSq3Ru XH8Nuhf9Rx+tAHQ0Vwtz8QQCVtdOb2NxMqfoMmqM3i3X54nljSCCNQSTHbSPtHrk8U7MV0ejEhQS TgDkk1iy6vNeEppSI0XQ3cudn/AB1f68D3NYejWuraxD9p1e9lls5ACluVCCQerAfw+3fvXSrBgA ZAA4AApDKA02GRxJes99L1DTnKj6J90flV9flUKuAB0AGBThEP736Uoj9xQACnrSbT6UooAiubG1 vAPtNvFKR0Zh8w+h6ioBb31iM2U5uoh/y73L5bH+zJ1/Bs/UVfFPFAENjqMN7vRd0U8f+sgkGHT6 j09xwau1m6hpyXyhlke3ukB8q4j4dP8AEeoPFceNQ8S2F3JaT6jG0sS7v3tuCHXswIwSD+h4ppX2 E3bc9CorhIfF+rxf6+wtLgesMpjP5NmtKLxraJgX9le2Z/vNHvX81zQ4tApJnU0VnWOuaXqOPsd/ BKx/hDgN+R5rRpDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAoopjusaM7sFVRksxwBQA+mS SJCjSSuqIoyWY4ArnZ/Ekt6Xi0C3W5C8PeTHZbx/j/F9BWBeT6O0m/XdVn1qdTkW9uCIVPsBx+JN AG5eeNdOjlNvp0c+qXP9y2Ukf99f4Zqmz+MtX+7HBpEB9wZMfXn+QrO/4TP7LF5Ok6Tb2kQ6bz/7 KuP51nz+KdauTg3vlA9oY1X9Tk1SgyeZHQR+AluJBLqupXF3J3PX9Wz/ACFaUfhnw/YqPOijbHe4 lJH5E4/SvPZry7uCfPu7mUejzMR+WahCJjJjQnPdQarkfcnnR6lHeeHrHiKfTYMdkZAf0qldXUHi G7W2t5Vl0y3Ie4ZTlZn6rH9B94/gK88yqKSIxnsF4yfSvQ9Hsxp2mQ2+MyAbpD6ueSf6fQVMo2Kj K5reYO1JvqHn2FOB9P1qSiTNOBqMcdc59O9OHPpj17UASKaeMHr+dRZ7U/P/ANegB2KcKaDTqAHA 1m67pUeqWynykkuIDviDHAb1Un0PT24PatDNLmgDm4fDen39olzZTXNtvH3C28Ke4IbPIPHXtVa7 8PanGSUMN2g6bP3bj8DwfzFbtsfsetywdIb1TMg9JFwHH4jafzrXqlNolwTPMJrS3e6ZNQtAjkEh Zk2sfoe/4GpLdr/T1B0/U7mJRyI5T5sePo3I/A16LcW0F1CYriJJYz1V1BFc1qPhl4UZ9MYun/Pt I3/oLHp9Dx7irUov4kQ4yXwsrW3i6+tgo1PTxMh/5a2ZyfxQ8/rXRaXrmnasP9CukkcdYz8rr9VP NcQ7bmPDLsO0qwwVI7EdjUb2cFxmSWP94n3ZFJV1PsRzTdLsJVe56bRXn9jrmr6YQrP/AGnbD+CQ hZlHs3Rvx5rrdJ1yx1dG+yykSp9+GQbZE+oP/wCqsnFrc1Uk9jTooopDCiiigAooooAKKKKACiis LxL4hh0K0HAlu5c+TDnr/tH0AoAn17X7LQbXzruTLt/q4l+859h6e9ec6n4judXkD3SB4gcpakkQ r7tjlz+QrIup5r68e7vJWnuH6segHoB2FNzWih3M3PsWru8ur0KtzM0iL92PhY1Hso4FQgcDp+dN q7p91b2sm64sY7xfR2ZcflxWm2xG4t3YyWkVq8hGLiISr7Ak8f59agVTnt+ddh4k1jTnsdPH9mwz mSAOm5ivlKeMcc9v0rD0jQNQ1hvNt4Vhtj0mkyFx/s92/l70lLTUfLroZgVvQ0oOSqLln/uqCx/I V6FYeCdNtwDdtJeSd952p/3yP65roba0t7RNltBFCnpGgUfpUup2Godzy/TdMujqlgLi0niiaXdm RCobaC2OeewrvfmPtnPtTNWJbXbFR0SCV/1QUKMbMkfnWbdzRKxIMcc5yKcCT0HXqBUYI29zg08E k+xpDJBxwTz2pQSen4imAdj1HQU4EkcdaAJAQBxzTh79OxqMcc9+4pwJPT8qAJAcntTgeajyBx29 adn86AHn1pM0A8fWm5oApaufLitrroba4Ryf9ljsb9GrZrF1v5tEvh38liPqBmthTlQfUUAOoooo A5zxPp37htSt1xNCuZQB/rIx1z7jqD9RWBmNoV6KW5z2ru7x4orKeScgRLGxfPpjmvOowywQo4IZ Y1BB9cVvSfQwqrqWEjYSLnp61XuLdJ5RNl4p0OY5o22uv0P9K0NMaJZgbhnCbgOADnnv7U69jtmv ZBas33yCGAAznt7Vo9dGZrTVFrS/E8tq8dtrhXa2BHeqMK3s4/hPv0rrgQwBByD3rz64VXLxuoZS NpVuQRU2j6tJ4faOC5dpNKfhWbJa1PofVP5VjOnbVG0Kl9Gd7RTVYOoZSGU8gjoadWRqFFFFABRR RQBS1bUYdK02e9uD8kS5wOrHsB9TXjd/ez6jfS3l02ZpTkjso7KPYV1HxG1MzajBpqH93bqJpB6u fuj8Bz+NcfWkF1Im+g4U4A4puQPSpriCS2k8uYYbargezAEfzrQzG46cin4HHI/Ko/4RTv4RTEdN 4Q0iPWL5nuz5ttZquIz0YnJAPsOTjvkV6UAFAAGAOABXm/gXUkstVkt5mCx3gVVJ6BxnA/EE/iK9 KrCe5tHYKKKKkowdYQrrVlKfuPDLFn/a+VgPyDflSDAVeR+Fat/Zx31q0MmVyQyuvVGHRh7isJnk tHW31DEchOElA/dy/T0P+yfwzQBbGNxGDz604MWXHp2FMyAQcHPvTt2Gx2/pQA/tkn607djleKYo IOGwAeKcpA4x+JoAkHHPQUucdOhqNckkHNOUgcd/60ASDjr0pRknBP41GvPX86bNcQwpmWVIgO7s FoAsA5OaGPQ1QGoxycWsM90T1MUZ2/8AfRwv6012nlH+mXlvp0XdUkBkP/AjwPwB+tAC37faydNh +aWYYlI6RRnqT6EjgDv9BW50rEi1XQ9NiEUN1DhiTiMmRnPckjJJ96guPFUKbfs9lcy7skM4Ea4/ Hn9KaTewm0tzo6qX2oWunxCS7mWMHhQeSx9AOp/CuU/t/Ur+by/Mjs4sEnyRubH+83H5Cqum25uL h2eaPzXOGe4clzj0J5q1TfUh1F0J9T1iXVpNmxoLJDu8tvvSEdC3oPb8/SqIl3f6wbvfvW3remxQ sXjnhj3Ko2M2CcDHArCWNt4DD8a2ha2hjO99Sd4/3ahDnuR3psX3ix/h5qNnJkLDI9KlaaMRqkhA lk6BRlm/AcmqIFVw/wAr/ge9VtUuFt/3W0TSy/JHF/f+voPU0+RZ4Ww6mF8ZEeAZSPXb0Qe7fkaS zt1jmMkgDSP1brgemT1+v8hxSvfYq1tzU8I38mnTpod3JvRl3Wsp9erR/h1HtXa15tqMEkkXmW7Y niYTQuOzLyP8K7zSb5NT0u2vY+FnjDY9D3H4GueceVnRCXMi7RRRUFhRRRQB4lrtwbrxBqUxOd1w yj6Kdo/lVMdP0qbU0MesahGw5W6lH/jxqFelbR2MXuTW1xJazLLFs3r03oGH5GtbXdal1eVcrGsS xqP9WobcAM89cZzxWKOPqeaXPIaqsFx4C7Tz+lPG3b/F1pi/eK/hSr0b6UyR/wAhjPDdR3rsvD/j Iwqttqpd41AC3OMkf74/r+frWd4U0T7depLNJbmAAkx+aC54P8PbrWXfabJpsjxyTW8p6AxShj17 jqKh2ehSutT12CeK5iWWCRJY25V0OQfxqWvGtOvbqwm32dxJbk5JCH5W47g8Gun0/wAdXKbUv7RZ h08yE7W/FTx+tQ4NFqaZ31RyxRzRtHKiyRsMMrDINY1p4s0e5IU3Qt36bZ12fqeP1rZiminTfDIk iH+JGBFQWZMuiNFzYXLRKOkMoLx/h3X8Dj2qvI19b48+xcgcF7Y+YPy4b9DXRUUAc0moWsrhftCL J3ST5G/JsGrnGA33s9x0rVmhinTZNEki+jqCKoNoWmk7kthCfWFmj/8AQSKAIiS2P5e9O4xk9e4p f7FVf9VfX0Y9PMDf+hA0z+ybtfuam5H+3Ah/ligB+ScEVQfRdKabzm0+3aUnJfbzmrn9naiBgX9u frbH+j0n2DUx/wAvdmfrA3/xdAEP9laeDzZwse25c/zqaOys4gfLtLdDjOViUUosNTyCby0/8B2/ +LoOnaiVIOpRLkYyltyPzY0Acprl39r1fy4z+6tR5S46bz94/hwPzpi3G0MsnzRv8oz2x3rei8Hx IiK+oXTBOhCoD+ePxqceEtOHMst3IB/emI/litlNJWMZQbdzm9ix275yjudo7jA70yV44pFMk0QJ XB+Yde9dHNZ+F7PH2g2pK9FllMhH4Emm/wBu6RZoWsLBnAON0UAjGfqcU/aN7IXs7bswriS51O48 yG1uZsKqgrEccD1OBV600XV2U7oIYFI6zSZIH0XP86fL4ov7htsEUFqp6FsyN/QfzrMv3ublv9Lu ZrlPRmwmf90YFC535CfIvMtvaaZBJsn1Ca+n/wCeFkAq/Qtnj8WFQNeSR7orKCLTYjwfJ+aVvrIe fy/OoIgIosqAvZQBgVYtbh0lVlYq46OOoquTvqJz7aFmOxMGjCcRNh5TuGDnGPve/Peq23ahcHIP ANbEutXI0wFZB9oMpXdtH3cdayJbh3k/esXJ+8TTjfqTK3QIWwp3dDx+NbHgVyumXloeltdyIo/2 Thh/M1jSLt2qOQea1/A4Ji1aT+Fr1lB+iqKirsXS3OqooorA6AooooA8n8aaXND4rm8iGSQXaCZV RSxyOG6fTP41kJpeoZ/48Lvn/pi3+FeqeJbCe4tYryxz9vsW82EDjeP4k/EcVBY6l9vs4rmCZzHI M4LHKnuD7jpVqVlYlxueaf2ZqHX7Bdev+pb/AAp40q/wf9Busdv3Lf4V6h50v/PV/wDvo0edL/z1 f/vo0+cXIeY/2deghv7Puz9Ym/wp66dfB8f2fcYPfyWr0vzpf+er/wDfRo86X/nq/wD30aOcOQ8+ 0uPUtPvkuY9PuN6BgP3LDqCKgj0+9+bOnXHIPPlMK9I86X/nq/8A30aPOl/56v8A99GjnDkPOY9O u8n/AEC7Xg/8sm9PpTotLuzIv+i3I5/ihYf0r0Tzpf8Anq//AH0aPOl/56v/AN9Gj2guQ86bS9QH Jsrgg+kZNPGnXkVwGjs7pNuBmONlP5ivQvOl/wCer/8AfRo86X/nq/8A30aPaeQcnmctZXGqWU5F 1PqgtmP+sAL+Vj13A/L79R9K30utQADRaikqHkGSFWBHrlSKtedL/wA9X/76NZz2TRSNLZOsTMct E2TE59cDlT7j8Qahu5aVi5/aGqq2P9Ck/wCAuv8AU1J/aepKfmtLRvpcMP8A2Ss5tQ8rAvIntT0L H5oz/wACH9cVajZZo1eN0df7ykEfpSGTnVr4f8w6I/S5/wDsaUarfYz/AGamPX7SP8KjyNvAyR60 4BmUnnjvQA7+1b//AKB0Qz63X/2NDajqX/PpaLn1nY/+yVUl1C1g+RplMvZF+dz9FGTURkvLrAjQ 2cXd5AGkI9l6D6nP0oAffaxqtv8Au4Y7SW5YfJBGrufqTxtX3/Kqd1qXiLH7vAI4by7Q9fbJORWl axLaKwhLgucu5YlnPqT3NT+dL/z1f/vo000ugmm+pzc02uyW4aW41DzGPSOPYAPwFQiwup4vMuIb qZ14ImLvkeuD37V1XnS/89X/AO+jR50v/PV/++jVqaXQjkfc5e3s5V+T7DLH5gO4pERgdv8AGn3N jciONY4JmH3j+7PX0rpfOl/56v8A99Gjzpf+ej/maftfIXsvM5SKzulyxtZ8joPLPWiO1vA3FtPz 1zGcV1fnS/8APV/++jR50v8Az1f/AL6NHtfIXsvM5qSznk4S2mXb22HBpos7pI/+PabJ/wBg9K6f zpf+er/99Gjzpf8Ano/5mn7XyD2Xmc3DbXK/ftpio7eWetH2K5D5+zzEdf8AVmuk86X/AJ6v/wB9 Gjzpf+ej/maPa+QeyXc5mUS2tvNcXEMqxRKXJZCMYrpfCVk9l4dtVlGJpQZpP95zn+oFZdz5muav HpQdntLcrNenOQccpH+J5PtXXVEp8xcYcotFFFQWFFFFABXJ6tZyaHeS6naRtJYTnddwIMmNv+eq j+Y/GuspOtAGBDLHPCksLrJG4yrLyCKdVO90e50mZ7vRY/NtnO6awzjnu0fofboafYX9tqEJktnJ 2nDoww6H0YdjQBZooooAWq1vNeXUCTQ6bM0TjKt5sYyPXrVkdat+H/8AkA2P/XJaAMaTUDFaSTtb SZikMcke5cpg4JznGB61YH28jI0yYj/rtH/8VTbfBlvgRkG6kyD+FT6XcGxnSwlP+jv/AMezn+E/ 88yf1Htx2oAjt51ni3qGUglWRuGRh1B96kqTVrR4ZTqFshY4AuIlHMij+If7Q/UcelRI6yRq8bBk YAqw6EetAC1As000ki2lpJcrG21nV1Ubu4GSMkd6VxLc3AsrVisjDdLIP+WSev8AvHoB+PatWaS2 0fTlCIRHGAkca8lmPRR6k/8A1zQBjPdXEN1DBNYyxtNnH7xGwB1JwelQzW9lNcNHFYm4uR94QIFK n/abgA/jmnzedDaXl7MwN40TMSOQmASqj2H6nmuh062jtLKGGFcKFBJ7sT1J9SaAObGl3A+7p1+o 9BfD/wCLoOlSt/rNIuZf+ut0rj8i9XBfX19mWK5FrBuYIqRhmIBIyxbI7dAPxozf/wDQUm/79R// ABNADIbe7gXbBo7RL6I8Sj9DRJPNbjddWVxAnd8B1H12kkU/dqA6anLn/ahjI/QCtLSbyS8tnMyq JYpGicp90kdx9RjigCgjrIiujBkYZBU5BHrS1EYlttWvIIgFiISYKOilt2cfXbn6mnTzJbwtLISF X0GST2A9SemPegBJ7iODZv3FnOERAWZz6ADrQF1BhldNcD/bmQH8uau6TYvFuu7pR9rlGNvXyk7I P5k9z+FQT6xcGd2s4EmtYTtc87pCPvBO3Hv1PHvQBXS4/f8AkTRSW85BISQD5gP7pBINTVoTw22r 6epV90bgPFKnVD2YehH/ANY1kwSSb3t7kBbqHAcAcMOzj2P6HigCaiiigAoopaAErPv72b7Qmn6c ol1CYZAP3YV/vv6ew70xr241Kd7PRAsjqcS3bcxQ/T+83t+db+kaRb6TAyxFpJpDulnk5eRvUn+n agB2jaXDpNiLeIl3Yl5ZW+9I56sa0KKKACiiigAooooAKKKKACsbVfD9vfzfaoJHs79RhbmHqfZh 0YfWtmigDjZb690k7NbtsRdBe26loj/vDqv8q0YZY54llhkSSNujoQQa3yAwIIyDxg1g3fha1MrX GmTSaZcNyTB/q2P+0h4P6UAPHWrfh/8A5ANj/wBclrCkfWtN/wCP6wF9CP8AlvY8tj3jPP5VFpGs sYI7O01Oz3RDYI5rdlkGOxBYfpQBftv9de/9fcn8xUk8KXELRSZ2t3HBB7EehHXNMtoZIVk851eS SRpGKrtGT2xk1NQBa0m+ebda3RH2uEAk9BKnZx/Udj+FVLnT7q0uHOnwpLDMSwjZ9oic9T/unqQO QenXiOeASmN1d4pYzmOROGQ/1B7g8GpFvdVQY3WcuP4mVlP5DIoA0LO2h0uydpJcnmSeZ+Nxxyx9 B/ICsoSPf3IvZlKoARbxN1RT/Ef9o/oOPWiVbm8ZTfTI8akEQxKVQkd2zkt9OntU/WgCvfo0un3M aAlmiYKPUkHit2ymjuLKCWJgyOgII+lZNQrDLbyPJZXDW5c7mTaHjY+u09D7gjNACLb3dhug+xzX EasxjkhKnIJJ5BIIIzj0pfMuf+gbe/8AfKf/ABVSfatV/wCfm0/8B2/+LpftWrf8/Nn/AOA7f/F0 AR+Zcnppt5n6IP8A2atHRrWa2tpTOoSSaVpSgOdmcYGe/Aql9q1b/n5s/wDwHb/4umPJqM67Zb5Y 0PX7PFsY/iScfhQAszq+t3zKQVSONGPYMNxI/AEfnT9Lt/t06X8o/wBHjObZT/Ef+ehH6D2571Su bJmtUt7UxRxBsyLICRIPQkHPJ6nvVv7Zq2zar2C8YGI34/WgC9e6nYwySWs8rltuHWNHYqD7qOD+ tZCJ4ejRUT7YqqMAL9oAAqe3hFvFtDMzElndurserH3qXJ96AEsdQ0bT4jFbvLFGzFiZI5cAk8kl hx/Krmq2LXSLPb7Vu4cmMno47ofY/oeapnDAhsEHggjII9KrrcXmmW2xbq0W0T7huQcov93ORkDt 7UASW863EQdQykEqyN1Rh1U+4qWufTVrm81NptPgGoM67ZRaxMkbEdCXY4BHTPOR9BWpHomrahzq V6tlCf8Al3sj8xHoZD/SgBl7q1raSiDL3F233baAb5D+A6D3NLDouoav82rv9jsz/wAucD/M4/6a OP5CtzTdJsdKi8uxtkiB+8w5ZvqTyav0AQ21tDaQJBbxJFEgwqIMAVNRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAVR1DSdP1Ndt9Zwz+7LyPoeoq9RQBzTeFWtx/xKtVvLQdo5CJox+Dc/rUL2/iO 1+9bWWoL6xSGF/ybI/WurooA41tZNv8A8f2majaY6sYfMT81zT4df0mc4TUIA39122H9cV19Vrix tLoYubWCYf8ATSMN/OgDIjkjlGYpEkHqrA0/B9DSy+EdClOTpsKH1iJT/wBBIqE+D7BceRdajb+0 d02P1zQBJRUP/CLSr/qtd1RfZnVv5rTT4c1Efc8Q3P8AwKCM/wBKALFFV/8AhHtV7eIZP/ASOj/h HdUPXxDN+FrGKALFLUA8NXh/1niC+P8AuJGv9KUeE42/12ratL/28bR+gFAE2COoNVZ9Qsrb/X3l vF/vSAVMvg7RiczQzXB9Zrh2/rV628P6PakGDTLRSP4vKBP5mgDnv+Ei01m22zzXb/3baFn/AJDF Spc6vc/8eehzIv8Afu5FiH5DJrrURUUKqhQOwGBTqAOXTRdbuubvVIbNT1Sziyf++2/wq1beE9Kh kEs8T30w/wCWl25lP5Hj9K3qKAGoqooVFCqOAAMAU6iigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKAP//ZCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKPDwvUjEwCjEwIDAgUi9S MTEKMTEgMCBSL1I4CjggMCBSL1I5CjkgMCBSPj4KZW5kb2JqCjE4IDAgb2JqCjw8L1IxMAoxMCAw IFIvUjExCjExIDAgUi9SOAo4IDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjIyIDAgb2JqClsvSW5k ZXhlZAovRGV2aWNlR3JheQoyNTUKKFwwMDBcMDI2XDAzMVwwMzRcMDMwXG5cMDAzXDAwN1wwMjJc MDAyXDAyNVwwMTZcZlwwMzJcMDIwXDAzNVwwMDZcMDEzXDAxN1x0XDAyNFwwMDRcMDA1XDAzN1xi XHJcMDI3XDAyM1wwMzZcMDIxXDAzM1wwMDEgLzw/LS43Pj0zOCMmKjA0JTU7NixcKScrIToxIiQ5 XCgyW1xcSU1MWlRTTl5SR0hYVktXUEJRWVVfQURFT0BDSl18dXBcMTc3enFlb3lpc31idmthe2pt fnhkbnJoYHRsZ3djZlwyMDFcMjI3XDIwNFwyMDBcMjA2XDIyNlwyMzRcMjMxXDIzNVwyMjVcMjEz XDIwMlwyMTVcMjExXDIzMFwyMjBcMjIyXDIxNFwyMTBcMjEyXDIyNFwyMjNcMjAzXDIxN1wyMzZc MjM3XDIwNVwyMjFcMjA3XDIzMlwyMzNcMjU0XDI2MlwyNTZcMjQ2XDI1MlwyNTVcMjcxXDI1N1wy NzdcMjQxXDI3MlwyNDNcMjczXDI2MFwyNTNcMjQwXDI0NFwyNjRcMjY1XDI2NlwyNDJcMjQ3XDI2 M1wyNjFcMjc1XDI1MVwyNDVcMjY3XDI1MFwyNzRcMjc2XDI3MFwzMjJcMzE1XDMyMVwzMzZcMzI3 XDMzMlwzMTJcMzIwXDMxMFwzMDBcMzM1XDMwNFwzMDVcMzA2XDMzM1wzMjRcMzExXDMwM1wzMDFc MzAyXDMyNlwzMzBcMzM0XDMzN1wzMTNcMzMxXDMxNFwzMTZcMzIzXDM0NVwzNDFcMzQzXDM3Mlwz NjVcMzc0XDM1N1wzNzBcMzc1XDM1NVwzNjNcMzczXDM2MFwzNDRcMzUxXDM0MFwzNzFcMzc2XDM2 MVwzNDJcMzU2XDM2MlwzNjdcMzQ2XDM1MlwzNTNcMzQ3XDM2NlwzNTRcMzUwXDM2NFwzNzdcMDAw XDAwMFwwMDBcMDAwXDAwMCldZW5kb2JqCjI0IDAgb2JqCjw8L1IyMgoyMiAwIFI+PgplbmRvYmoK MjUgMCBvYmoKPDwvUjIzCjIzIDAgUj4+CmVuZG9iagoyMyAwIG9iago8PC9TdWJ0eXBlL0ltYWdl Ci9Db2xvclNwYWNlIDIyIDAgUgovV2lkdGggNTY4Ci9IZWlnaHQgNDY3Ci9CaXRzUGVyQ29tcG9u ZW50IDgKL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzkxMz4+c3RyZWFtCnic7Z17fBTV2ccf CAmEayBsDEGJFyIoFhQiLwi2XlBbRfBepPoqliqIl2K9YH37qlQRqYJVaq3VYr2CiGKx9daCVxCj eMEbL5eELAQ1iIAYyPPXe87M7O5ssnF3T87sPCfn+X4+mT1zzjPnueSX2Zk5mwSRYRijgezM17dL 3t/QPvUMTe2y98QQZyMA5P0NcdNFHfKPq3Y7Cg68uUa0bjmoY6fjl3t2KwovRlxwQvLBj5yYYrYO f29mx7Q5Hh2DNX8Xp4eTTt6w+ZRJXsfygy9CvOinr9W+fuvPPLtDThRauOSi5IN/ObP5bNHHOjez Y9oUW7ogTv494tau+Hj/OsTXu6HbgW/kIXbf5jN9rOLNHohjnkB8EqDo0Lfwy1N7tr/ttKfEDFt6 LRxQ3Pl2x8yZLV/Yfdlb7H3VCd8e2LFiQXvpyW/GGM3KwxAPfxK/+tWlePIisV8XEZvDV8lWCeJ+ F30dt6wf9PT2nt9g+x2Il8369ps7jtj8o9k7d4wtfULMsLLj6e/ULe7j2MnZpowTdo+NF3urD13f 45ldywefKD35zRijWXQG1haJK5JTothht9jf3QGxtqe8yPmuDPHtcX3LTnrDtbxTyGDIu4nL3S5T Lxfbd9uLGXBRhbgY2thJdsvZ+k7bJuyumCN2lxx35Z3iZfLN0pPPjDEbcRlSNRhrHum4ByPyQvjZ UxCrDpMji890DDZccqTzuqe30M9Vs+Tl7pbJR3QE2G//jaJ7yYnyQuYSKaHnzpJ2YjaJsDvkcfF6 9cw8KcdxS6UnnxljNictwT/8Wrwe9RR224BYM3gh4h+mi466Q593Lb7p6bxMAcl0qZKhd31di7ed HdmKGD10ppgBT/qHsLjmN9LOmc3RY/fvEbcf9GykAXFvr33Sk8+MMZth7+LJz4rXmdfideds23Du eaJ98jKsrTrrKsTT7369/r0znNup99t9K7aP/1xeFnd9ctOXcw+4tf9ljV8fX/SCmAGHVYnBsY9I Q2c25/K5y+3131/XcU3lXQ3vD8hzPPnMGLM54Cvs97p4feto3HpOftllm0S7H0DXo2ZHxcXLcT0i ZVc2SrvT5snt+s7ysvip/YuOvueQ56uGl/zXok67xQx4wHdisO+X0sSZDeXl8+29S4c+3mXLByNK J/zyVMeTz4xh0nM+33sz2bFt+pY9k4fXhh0GYxg1U7t0OWVj2FEwDMMwDMMwDMMwDMMwpgCMubBu GBVC1U2IzpnWwLphVGDdMCqwbhgVWDeMCqwbRgXWDaMC64ZRgXXDqMC6YVRg3TAqsG4YFVg3jAqs G0YF1g2jAuuGUYF1o4wlH5JKDetGlVzKhl6hWDeq5DL4QH2ZJ3/WDQFfuZSNpjxYNwR8GZgH64aA LwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPNq8bjwb8dIX9jnN76Ev Lj+jLJJ33mrNvlRh3eSW7HQzEj50mk/C0I9Ks350yroJYppwyE43V8Esp3kLTBsGY5dv2rt4gmZf qrBuckt2uvkjXO80J8G9RbA3CF+q/ODcP3RiTCSnx1fOpwmH7HTzBIzHX8OlOBb+2QOu2B2AL1VS zn0DTPEGWTeayU43H8MgPKb0UDwQ1t5eDjDq+MVRzb5USTn3KBFuOt8KQbFustVNfUHBloLpRZsL S+pw1cSu4qd46Ba9vlRJNfcnIr7X0/lm3SiRnW5wNNxX8GXBbTBcdtQsnz8KZuj1pUqquW8Turml yfjq83qUdD57hWx+Ou6A/OMb5UDifQxg+10Hlgyan7UvTSEbQybBFzk226Ej4ngYchQOGQYTvaFP oK9eX6qkmvtMOArObjLuPjwo/QDxq/aydUZT3Vzm7CzK1pemkI0hk+Dbwx6x3Qf9EK8HuBGnAlzh De2FEr2+VEkxd10vWAW9apLHf7Hs+5qN18LP5T1h/7c3fTY8+boYYPiq+t3nwtAsfWkK2RwyCX4i nPlO3XsnwimIswBewAUAd+Cwuz+vrf1sAlTq9aVKirnfhSPwSKhKMb4TuqMY+kg0/9VUN/8S243Q JUtfKrR53bzd1Tl3d30NcRUUbsbNhfCud8KHgif0+lIlxdyXwG/xtzAzeXzZhM4FIuxCxI6wS+w3 NNWN/D+K26E8S1+aQjaHjIJfe05ZQdk5b6BcmJL/zH0w7MWVU44uLck7t0q3L0VSzH2sI+yRSeNz Ep8sb0E3GUTKujHy+XyGc28rcAQS2ebsFcFW+dIb7ttdg1uk9fDU71MZRMq6acu6eQwGiO0AeMTZ q4S528VLT3ixsX7FWGl9vbwu/uLHrBsl2q5uboJbxfZPcIOzd7/75jTNOQdNlk33Pvz0+H04uK0M ImXdtGXdjII1YrsSRjl70cvLpMmuK/IK8uZEHevXT+5efFIj60aJtqsb8r5YNwR8GZgH64aALwPz YN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP43VTNy4jy2xmTXkQ6yaIacJBBv/SvW57ASz4IUul 6Zv6CgrWTW6RwY95y22fdvrYH7JUmr6pr6Bg3eQWGXw7d8n4k4qaincQZ/YWfe/+OIrbB62FW3v1 fQrXHVMgH8E7bZhegl9URCrWefuxHTmVe6gza7z/4uLRK/2+gswjV7Bu3OAjNU5z6jP4zI2IPZfI jy6d+iJ+dCLC/IaXO2PFXNnjtmFJDfaf1zivwtuP7UgD71CnGeufXT2vv99XkHnkCtaN/3zT0AkA Ou3CV0Z2ugjx88O2X7sKISo1EKl2LJ021AmdNWB1xNuP7SBGwTsU/f3O1ucryDxyBevGDX68c33z 5xPE5oQHxGZFqdhc+eIF6J1GvPON8yW3lbc03Bc7xXg7vRfuug1ih/r6QWxzfb7xbg8zdpbOcFxd y75ag/G6eelO2RqyVGyWHiV6es8Rre96/z2mlRUVheDXzZrKSP8vYrpxd5b07TIHYof6+mFq7q9v YreHurjrpZZ9tQbjdZPy+U30nKY/ZpnzXp8WfQWFb+7Y7aEu1oxp2VdrMF43Kfvzl6pPWnJ1Vr50 4Jvbuz2Up8i/dG/34tXdOy2S4/0WYNXo/CtE98fHlhwh/97T2vYN2ND+80RPh/VPw9Pr23m78tZR srksmDzapG5M8+Wb27s9BOcWcGHJ/IZX24nd6L9HiGuu6tmie8gDtc87v6g88UGcezYmei788MLf jF91gbcrbx0ldU1/tZB10yZ14zvfRGO3gfN6FEI5Foi7O3mrJ24cnV+QejdvZ7+VmOi5/OIjo4Mu nuTtgvdGzeebFLRB3bi3hxi/lJdfpQsbFoC8x3PON0uqPdORAwc4Fl7PE0V/xVuL7vB2YzO+NTGY PFg3BHz576fudHv8urmmV/eZgFWD8q8rQnzzglLPfDE851h4PTtK9uH6gjXebmzGe5cFk4c9umlF ovIhSG6f36Sk/p4hWU/Nz29SkHHwGdq1ZCYfgoT/vBjKj8zmF5Nb5StX04RDrnQjH4KErxtSvtqK btynFjc8isumeM8znIVw7zkxuO/4SWvh6K6ee4vnsumYeY8/Eg9P0L0pYd0EMU04+IJ3n1psOv/B 8zd5zzOchSnv4tJ7SVoLR2/13F08d5oQn8j/8MR9CMK6CWKacPA/L3MfYrwKq2PNiHc7Gk3oJmkt XOAsgbuL504T4hMlHp5I+HwT1DTh4D/fOE8tGoc+d3CD9zzDOd94S91F6/3L3Ji4kpFL4M7iudOU ZonHHwk7+RCEdRPENOHgC959ajFtIb5wrfc8w1kId5e6cXIx+Ja5MaYHdwncXTyXTWmWePyRsJMP QVg3QUwTDnqCT794nsPnN4HDutEUfIaL56ybIKYJBwPrnfO5A/LFuiHgy8A8WDcEfBmYB+uGgC8D 82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDLwDxYNwR8GZgH64aALwPzYN0Q 8GVgHmA2WmqQYaHMnDsgX2F/41uJlhpkWCgz5w7IF79PEfBlYB6sGwK+DMyDdUPAl4F5sG4I+DIw D9YNAV8G5sG6IeDLwDxYNwR8GZgH64aALwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0B Xwbmwboh4MvAPFg3BHwZmAfrhoAvA/Ng3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubB uiHgy8A8WDcEfBmYB+uGgC8D82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDL wDxYNwR8GZgH64aALwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPFg3 BHwZmAfrhoAvA/Ng3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubBuiHgy8A8WDcEfBmY B+uGgC8D82DdEPBlYB6sGwK+DMyDdUPAl4F5sG4I+DIwD9YNAV8G5sG6IeDLwDxYNwR8GZgH64aA LwPzYN0Q8GVgHqwbAr4MzIN1Q8CXgXmwbgj4MjAP1g0BXwbmwboh4MvAPFg3BHwZmAfrhoAvA/Ng 3RDwZWAerBsCvgzMg3VDwJeBebBuCPgyMA/WDQFfBubBuiHgy8A8WDcEfBmYh+G6ySVB5hHc3AH5 Mlo3ORVOoGkEOHkwvszWjRL0Us6l/Fk3qhBM2TjZUCxi0FiYsn4sLKKFKevHwiJamLJ+LCyihSnr x8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqY sn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyi hSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fC IlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+ LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp 68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJa mLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiws ooUp68fCIlqYsn4sLKKFKevHwiJamLJ+LCyihSnrx8IiWpiyfiwsooUp68fCIlqYsn4sLKKFKevH wiJamHJmgEfyLu81KUwQHoyGxDeH7p63H4QHe+CUGRUsLKKFKevHwiJamLJ+LCyihSnrx8IiWpiy fiwsooUp68fCIlqYsn4CL+Kff1JaXHndZwF7yQbWjQaCLuL9cO/O+pWDKX2rWDcaCLqI+0NUbP+P 0reKdaOBoItYBKvi7VcP6Vk6bLHzbP7l/iXy8fy5uEc+pG8yEGxErBsdBF3EMwGOnvTobtl8unBO 486rYal0evrmJ2ENlNUhru1X03Qg2IhYNzoIuojbpnUUZ5Hy0zYiHgwNiFvhEOn0DTlWCY8gTr26 +UCwsG40EHwRtz5+8wCAsYjF7tJxV+lUXvSIa+bxWN/u9eYDwcK60UBuijgb8qVu6pOd7i0q+PLF CSkGgoV1o4Ggiwgr5LYRuiGOdNpvjE44HQd/mvBKqoFgQ2LdtJ7AdXPgY1uiu2+EexCfLx/4Xt26 w25JOF0IZZ3rUw0EGxLrpvUEXcQVUw/rU9DprBdl+z8DepYcfZ/7GTlnMLofTE45ECisGw1YWEQL U9aPhUW0MGX9WFhEC1PWj4VFtDDl9MQuLYN+NRjjEwgAyIluzK682dEHQ25qYnblzY4+GFg36TE7 +mBg3aTH7OiZsGDdMCqwbjKmEhaI7QLoj7jjqm4l3WbsQNx9Zp+C3seEHVkIsG4y5vdwutieAX/E HWXdPqj/sEPZDhwL/6xdMzHsyEKAddOcFmryaXn+VtyaX74BZ8BLYv8fMAM7wm7vEID8abXy43eF HX71DeLtB3XsNwu3/2FQSY8/bs/GiyGYHX0wtFSTkbBIiGUgYgf4Tux+Bd2wDDpPe2i9PGRS9WS4 DPF/VjQ8JPQ0Dy78fs90vBd+V32N/NhMFl7MwOzog6GlmsyGE8Qb092IEagRuzVQgovLxImm6A5x yG5cD3mOWR30xhHwnmzuB5/itzAqKy9mYHb0wdBSTfZEIu9HSrbI880esfud/Nxm3Qe/HwTtnM+C 10AEPxrYpxyg3FOWeJEUZOXFDMyOPsecAAfBieJ1BiwT20VwldO7EUqd881u6IHtYWldg6jpKHhT Do2AjSGGGySsmyxYJE4er4jXHWX9Vtd/0F7cTw18ZV/9M0JLANc3XA+/xM7wUeMkUdP5cOG+vZNw Lhy3eefS88OOOwBYN1mwNR+6NsjGjhkdIh3k85vTDiwtbHfeHud+qviqWnx5eLm76P3wQUX9Hkac 1b+oy4ULw447AFg3WrCujNYlnAEKNcnNIYQwO/pgYN2kx+zog4E/R5Ees6MPBtZNesyOngkL1g2j AuuGUYF1kwL+/am0GJ9AELBu0mJ8AhSwsIgWpqwfC4toYcr6sbCIFqasHwuLaGHK+rGwiBamrB8L i2hhyvqxsIgWpqwfC4toYcr6sbCIFqasHwuLaGHKTQAqcMYmEXbtfHDGBkEm+BzqJkeO0kEmEBXI BM+6MQoywbNujIJM8KwboyATPOvGKMgEz7oxCjLBs26MgkzwrBujIBM868YoyATPujEKMsFT1E2w iwFkSq+CL/hw8yCkm6+nDOrYa+zLmeimNVG3Md3IWpXs/9/vi+bO6/cv2n/qVrczf/S01+T48jPK InnnrU6eJmVnS46UxrWR1tG/+/hWHVk3qWkevLdWW1yF0YFOa0A01hl5APGj0hRruSk70znKblwb 6Rx91xfOeK128/MnZGLNuknqqV93AQzEV6D96toPyuBFp7Nh+aTyorU4DMYu37R38YSkY1J2pnOU 3bg20jm6GcY0t/a/vHJC+5KOR/5udeITGaKz9i9Hd+x07iee0SWdes9tdSCkiQXf9My8D4rxZJgl WrfBybHOK+FSLIK9zWfxdQ6BRWL7BBzkK7C/wokCAzzW6dAtl/esTAokcNI5OhRebW7te7kxnosv q02/cBqdNzpG8zO6nm6TutkDB+Ag569Xr4XRsc63YDD2gCt2N5vF13kHjBTbiXC/r8C+CvsKDHAA wPkZXkjoI52j7vBtc2vfS0+4dUNd7ZsPHeuf7E447LO6DafCTU5f5bLq73/d6kBIk+q6GLHmjYnw K8wH+deKq6FnbOwb6IW3lwOMOn5xNGkWX2d1d3gNvyuJfJVc4NjsvgIDLF0K8MJ/iOmmwP0fAcnW vpcD4RfHXTz3yWjSZAc5P2JfwX5O331aAiFN6vspcUf1s0YsBFmcKBTGxmrk/1pYNbGrGB+6JWka X+ckuAHvl3+PP6nAsdl9BQbY2uh8NQ0kWFp7vvlohFOg/jv8k