From - Fri Mar 28 11:28:32 2003 X-UIDL: 3e5baf6500000351 X-Mozilla-Status: 9001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h2SASNNw013968; Fri, 28 Mar 2003 11:28:23 +0100 (MET) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h2SAV5F19699; Fri, 28 Mar 2003 11:31:05 +0100 (MET) Message-ID: <3E8423BE.9000205@eso.org> Date: Fri, 28 Mar 2003 11:28:14 +0100 From: Markus Dolensky Reply-To: twiki@ivoa.net Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en, de-AT MIME-Version: 1.0 To: ivoa@ivoa.net, grid@ivoa.net CC: esodev@euro-vo.org Subject: Grid forum ready for subscription Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Dear Member of the IVOA Board, At the IVOA telecon on Wednesday we decided to create a grid mailing list: > ACTION TM5-8.2 MD: To prepare the formation of a properly focused grid > working group create a new maling list (www.ivoa.net/forum/). is ready for subscription. How to subscribe: - reply to this message -or- - click on 'subscribe' on our forum page http://www.ivoa.net/forum/ At the same place you may also browse archived messages independent of a subscription. In contrast to ivoa@ivoa.net the new list is not restricted to the IVOA Exec and so please feel free to invite others to join. The initial motiviation was the formation of a grid interest group/alliance within IVOA and to exchange relevant ideas prior to the interop meeting in Cambridge, May 12-16. ToDo: Those who inspired this list please drop a few lines to grid@ivoa.net in order to define its scope and to trigger the exchange of ideas. Regards, Markus +--- | Markus Dolensky Mailto:Markus.Dolensky@eso.org | AVO Technical Lead Web: www.euro-vo.org | Voice: ++49 89 32006/261 Fax: ++49 89 32006/480 +--- From - Tue Apr 1 14:31:48 2003 X-UIDL: 3e5baf65000003a6 X-Mozilla-Status: 9001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h31CTQl7006134; Tue, 1 Apr 2003 14:29:26 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h31CTPK09639; Tue, 1 Apr 2003 14:29:25 +0200 (MEST) Received: from maroon.csi.cam.ac.uk(131.111.8.2) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAHaaq0s; Tue, 1 Apr 03 14:29:24 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by maroon.csi.cam.ac.uk with esmtp (Exim 4.12) id 190KqE-0000eN-00; Tue, 01 Apr 2003 13:26:14 +0100 Received: from cappc33.ast.cam.ac.uk (cappc33 [131.111.69.212]) by cass41.ast.cam.ac.uk (8.12.8+Sun/8.12.8) with ESMTP id h31CQD8Z014397; Tue, 1 Apr 2003 13:26:13 +0100 (BST) Date: Tue, 1 Apr 2003 13:04:54 +0100 (BST) From: Nicholas A Walton To: dal@ivoa.net, , , , , , , cc: ivoa@ivoa.net Subject: Cambridge, UK, May 12-16, 2003, InterOperability meetings Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: Dear All, ** registration now open at ** http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 please check http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 and related links for emerging details as to the upcoming InterOp meetings in Cambridge. I provide details and links to hotels on the above page. I would advise that you consider booking your accommodation as soon as possible. Yours, Nic Walton ======================================================================== Dr N. A. Walton (AstroGrid Project Scientist) Tel: +44 1223 337503 Institute of Astronomy FAX: +44 1223 337523 University of Cambridge WWW: http://www.astrogrid.org Madingley Road WWW: http://www.ast.cam.ac.uk/~naw Cambridge, CB3 0HA email: naw@ast.cam.ac.uk ======================================================================== From - Mon May 19 15:55:17 2003 X-UIDL: 3e5baf6500000a15 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4JDolG1002318 for ; Mon, 19 May 2003 15:50:47 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4JDokg22145 for ; Mon, 19 May 2003 15:50:46 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAALQa4pR; Mon, 19 May 03 15:50:45 +0200 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h4JDnUHT029083 for ; Mon, 19 May 2003 15:49:30 +0200 (CEST) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id h4JDs9A21073 for ; Mon, 19 May 2003 15:54:09 +0200 (MEST) Message-ID: <3EC8E205.7471700E@astro.u-strasbg.fr> Date: Mon, 19 May 2003 15:54:13 +0200 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: grid@ivoa.net Subject: CDS Web Services Content-Type: multipart/mixed; boundary="------------5AFED61E307197B042438E1F" X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------5AFED61E307197B042438E1F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JDnUHT029083 Hello, The Web Services portal link is available on the CDS webpage : http://cdsweb.u-strasbg.fr/ Andr=E9 --------------5AFED61E307197B042438E1F Content-Type: text/x-vcard; charset=us-ascii; name="schaaff.vcf" Content-Description: Card for Andre Schaaff Content-Disposition: attachment; filename="schaaff.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JDnUHT029083 begin:vcard=20 n:Schaaff;Andr=E9 x-mozilla-html:FALSE url:http://cdsweb.u-strasbg.fr org:Observatoire Astronomique;CDS adr:;;11, rue de l'Universit=E9;Strasbourg;;67000;France version:2.1 fn:Andr=E9 Schaaff end:vcard --------------5AFED61E307197B042438E1F-- From owner-net@eso.org Fri Sep 19 11:22:25 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8J9MK5x014645 for ; Fri, 19 Sep 2003 11:22:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8J9MK35014642 for net-outgoing; Fri, 19 Sep 2003 11:22:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-net@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8J9MF5x014601; Fri, 19 Sep 2003 11:22:15 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8J9MFI16262; Fri, 19 Sep 2003 11:22:15 +0200 (MEST) Received: from rose.csi.cam.ac.uk(131.111.8.13) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAqyaOWF; Fri, 19 Sep 03 11:22:14 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A0HSt-0004Yu-TD; Fri, 19 Sep 2003 10:22:11 +0100 Received: from cappc57.ast.cam.ac.uk (iwasawa [131.111.68.188]) by cass41.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8J9MBZD025164; Fri, 19 Sep 2003 10:22:11 +0100 (BST) Date: Fri, 19 Sep 2003 10:22:11 +0100 (BST) From: Nicholas Walton To: ivoa@ivoa.net, cc: semantic@ivoa.net, Subject: GGF Astro BOF Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870910533-250209383-1061565162=:2290" Content-ID: X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-net@eso.org Precedence: bulk Reply-To: Nicholas Walton X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1870910533-250209383-1061565162=:2290 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Dear All, at the upcoming Global Grid Forum meeting in Chicago (5-8 Oct 2003) - see www.ggf.org - there will be a Birds of a Feather session which starts of the process of forming a Astronomy Research Group at the GGF. I attach the draft charter to this message. This will give the Astro and IVOA VO communities a chance to input astro requirements into the 'grid' standards process. I would encourage those of you interested in this area to aim to attend this GGF meeting. Hope to see you there. (Note that early registration closes sept 26.) Please forward this message to those that may be interested. Yours Nic Walton ======================================================================== Dr N. A. Walton (AstroGrid Project Scientist) Tel: +44 1223 337503 Institute of Astronomy FAX: +44 1223 337523 University of Cambridge WWW: http://www.astrogrid.org Madingley Road WWW: http://www.ast.cam.ac.uk/~naw Cambridge, CB3 0HA email: naw@ast.cam.ac.uk ======================================================================== ----------- >From spartz@ggf.org Fri Sep 19 10:16:21 2003 Date: Thu, 18 Sep 2003 13:38:01 -0500 From: Clare Spartz To: ggf-membership@ggf.org Cc: membership@ggf.org Subject: [ggf-membership] Just Over Two Weeks Away -- GGF9 - October 4-8 - Chicago GGF9 - The Ninth Global Grid Forum October 5-8, Chicago, IL USA Chicago Sheraton Hotel and Towers 42 working groups and research groups gathering for 4 days working together to build a standards-based foundation for Grid computing. Nine sessions will focus on finalizing proposed charters for new working groups and research groups, including: * Business Process Grid * Configuration Description, Deployment, and Lifecycle Management * Workflow Management * Grid API In addition to working sessions where community practices and specifications are being developed, GGF9 will include four full-day workshops: * Designing and Building Grid Services (OGSA/OGSI teams) * Life Sciences Grid (Applications and requirements for bioinformatics, pharmaceuticals, etc.) * Peer-to-Peer and Grids: Synergies and Opportunities * Semantic Grid ***Important dates are approaching*** Advance Registration - available through September 26 - GGF MEMBERS save MORE MONEY http://www.globalgridforum.org/Meetings/ggf9/reg.htm Hotel Availability - space and special GGF rate guaranteed through September 26 http://www.ggf.org/Meetings/ggf9/lodging.htm ***GGF9 Schedule*** http://www.globalgridforum.org/Meetings/ggf9/schedule.htm Find "Click here to download the full GGF9 Schedule at a Glance" The Complete List of Sessions/Workshops and BOFs: WORKSHOPS = 4 Designing and Building Grid Services, led by Ian Foster et. al. P2P and Grids: Synergies and Opportunities, led by Andrew Chien et. al. Semantic Grid Workshop, led by David de Roure et. al. Life Sciences Grid Workshop, led by Abbas Farazdel et.al. WG/RG SESSIONS = 56 Grid Checkpoint Recovery (GridCPR-WG) Grid Remote Procedure Call (GridRPC-WG) Advanced Collaborative Environments (ACE-RG) Applications and Test Beds (APPS-RG) Grid Computing Environments (GCE-RG) Grid User Services (GUS-RG) Life Sciences Grid (LSG-RG) Production Grid Management (PGM-RG) User Program Development Tools for the Grid (UPDT-RG) Open Grid Service Common Management Model (CMM-WG) Open Grid Services Architecture (OGSA-WG) Open Grid Services Infrastructure (OGSI-WG) Grid Policy Architecture (Policy-RG) Grid Protocol Architecture (GPA-RG) Semantic Grid (SEM-RG) Data Access and Integration Services (DAIS-WG) Data Format Description Language (DFDL-WG) GridFTP-WG IPv6 (IPv6-WG) OGSA Data Replication Services (OREP-WG) Data Transport (DT-RG) Grid High-Performance Networking (GHPN-RG) Persistent Archives (PA-RG) Authorization Frameworks and Mechanisms (AuthZ-WG) CA Ops (CAOPs-WG) Open Grid Service Architecture Authorization (OGSA AUTHZ-WG) Site Authentication, Authorization, and Accounting Requirements (SAAA-RG) CIM based Grid Schema (CGS-WG) Network Measurement (NM-WG) Grid Information Retrieval (GIR-WG) Grid Benchmarking (GB-RG) Relational Grid Information Services (RGIS-RG) Appliance Aggregation (APPAGG-RG) OGSA-P2P-Security (OGSAP2P-RG) Distributed Resource Management Application API (DRMAA-WG) Grid Economic Services Architecture (GESA-WG) Grid Resource Allocation Agreement Protocol (GRAAP-WG) Job Submission Description Language (JSDL-WG) OGSA Resource Usage Service (RUS-WG) Usage Record (UR-WG) Grid File Systems BOF's = 9 Astronomical Grid Community-RG Grid Support for Ubiquitous Computing-RG Grid Federations Grid Scheduling Ontology-WG Workflow Management-RG Business Process Grid-WG Metadata Management Services Architecture-WG Grid API-WG Configuration Description, Deployment, and Lifecycle Management-WG GGF Sponsors at GGF9: http://www.globalgridforum.org/L_Involved_Sponsors/2003_spons.htm GGF9 Participants (as of September 12): http://www.globalgridforum.org/Meetings/ggf9/participants.htm Exploring Chicago: http://www.ci.chi.il.us/Tourism/ GGF Members Register NOW: Right Price and Guaranteed Room Rate; Meeting with the CORE international Grid COMMUNITY ; Learning through Workshops; Continue to BE a part of the GRID action!! Contact membership@ggf.org if you've forgotten your Y2003 GGF Individual Membership number!! See you in Chicago!! Clare Spartz Director of Marketing and Membership Global Grid Forum work: +1.630.252.0924 cell: +1.917.860-9126 fax: +1.630-252-4466 spartz@ggf.org --1870910533-250209383-1061565162=:2290 Content-Type: APPLICATION/PDF; NAME="Astro-RG-charter.pdf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: pdf Content-Disposition: ATTACHMENT; FILENAME="Astro-RG-charter.pdf" JVBERi0xLjQNCiXk9tzfDQoxIDAgb2JqDQo8PCAvTGVuZ3RoIDIgMCBSDQog ICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJzlXduKJMcR fV/Yf+hngcYVmXUFYZhLt59lL/gDZMlgLIP2xb/vrJ7OiJg8EdFZs7s2wggk u6YqL3E5cc3s307D6fvhgU4zpfLvZdv//fnn01+/O/3r44ffyl/3fz7//eOH p08fPxDRw3yat+lhOn362+kPFzrRePr0y+mHgf54+vSPjx+2h628X/72w5Be n0wPY32SX5+M8mR8fTKXSW9PpvqEx5nrV3N9srw+oaE+WOuDh7U+2uCrx+Hp 9hrJ4HUB/vTPr0+Wh8V/h7ea65MX2NgZxnnkdY8PqT68vD7KshOYjoZ2KCJY Eo6jpyNgQF0ApfrhEqycMpKS17k6xKWxDsRPJh5mkmVW9mZ5iOTsILlQBVYk 253hqyVkFFIORXeFDS++ND3SCvuVNcwde+EFsH7NQJPUfHUu2vwjKvh2hYIp lferfqdX/V6GlyENL0TDSHNd3zgr9brJTaOTm5p6mGisFEijcK75lG66uwo9 iCVlUpurSu5shtJOmzmvRUavu0m8G6r05cWlgUW6IVVu+CvLGuZClso9UthT d1QeLvKwws/UCEMGGZ5kXWd4wprd8pTpN8BCVxG81EjUBBLF46T6zRps4qny mRUoW9vHvS7tE4pl88bOtEvA12DnWudnBMvV1myy7uxzJBiJ+Sh4VednFJ+A /rdx2Dpu9Q3+Jle80qRtN3au0xd7OPprhNELFI04+lMd/+oguNycB0T3ZZgq RWkVAhadqZOTSDGttNFAN9FJSs87IGvatgaw6JGeCkNf6tdlQLaWbOLGhhfK e2kxaaWloFBi8FKolurHrfMRCvK07it6K8hlyc/IgZc6Q3nIHNgqDmzKxTDk F0BsEB4zvD7j+AHu+BpsytRLRaMWZ96Qh5g8KaXCGIs8xRCfG62mcx2duXvh l1iC2IVk1FrSwFpCoiXn4an84fZ9WYc4IGlgn6e+najZB912onfw068fPwzl v/++/e3Pfyr///Q9nX49bbsylv/1z9NfIjlZ9sEaOdkAmTtwykAcxLLHyp1V UOe50KRKzcIikqpUKpTZYAaUCEYiWbvISIvWnoxc8cQiDdoja1HinahFXO6K TfF+Zt5065wK6dPNACdlWqq5FcnNnvSovQXSsw4FIQPpecXFcd/1N0XGCk7a 6ySDSmOZkamQlMyM9MzmQBnMxx4MzalGoiwAllgimIE5TKRimsWVgBZPU66S KzogyMzToXY+glDCXIk9NNbEUTSlDWFdTdmDdYtQhucGExrqi2Yg2BwG8bI5 0bfI25pZNoSfhn4Vja6iaiiUkCCC432Cuwo1TA/gaoghgdCTFavSbRYwQWV7 quaMlOlpPZFLGazK+AQGAB28DKob6tS4JXCwjYhCO/ltABq6xqyL/NVFQllR K8sRmguyFB+9ClPxwoLwwgrC0giv9cQc47KVDz45MUdgZ1rna2aMUcKMVhlR 50UMlu+Dy0gbMCTdpUBIEcET2vbBLIp0AW+a6/wJyOZ7CBEwMdUqnPEbCmB4 oMmw/EBInC6xqxssYK3cVWM/VayiaL8udGlqB9BFOUXIldPi8AxCfnangyQF uv0JttQK1SJREhpFN0THmVCgV+DDck+p5z2SHWdII/Sqp6gj5QCCjE/vbxmC ebSIgA5IJg6wxW8jgGI6c1bNd3BK2MsBo2hWLjPUxyqwQ7t/5oSRyvflGuW/ 8Q8bx2ojwW/xf9gbkHQbZSAzL46BX7KsJJR84khRLQ7lHT0el0m+J2VAWF8C aq50EFRJTz1Ga0oYQBf447BXEjVDGp5Ttbdi4RNHgh6T7tmKJXsLQcRYqhgr D2luOZvG9NK+VZ+oVNKZ/Sgxz3QuITzDfyLFceLiFaMKq5QVM26+5B3Dexmq bgItgKJhZAHSvoh73ut4lQzPkTGSpy2ea2dv0unvEtBFSSCgE76D0Uids60W aj+bEyESQogORckRw6GSPNsGuXU958Don4zMhy8cHBVn8BD18GyCZ3f51bLE IxmWIjDmrVkmxDsj6zb7I2Od4sJLxJElrTR1Sd9leGYHX9iQCPL+nHixaAXq HoCzK7IO+r1qXFncegj85kZa/o/ATzaRzkmEpa0wiz3KAwcds+t74ugy0MwD tYTNJcouQLgAkyswK/YGuJyuVZPINx+SIyaVmJ2h6nU9eR3R1obVMbTtIoFn hQUshFzlBm9I10W53CheOQAECxAUK9QSwAXp8c+w+QFGVjAT1sZ15LtLkEnh /403gyxkL87KfmMGJshXoyePNhRMh6Fp5zc18sVdFEYnO1D4XpHiRRgX77nF SPvyYHN0rKYTC2KSoWbTksBfwEaRryfUvroYdWezFwF18VyXsELi0dJ07MEQ ewtiXiw1ZsnrW/7QICPVLo1AbfWVlV68Ue4QzARZKSkZ4E6BsI+Q27FgeyGs 8fUEjKjK6MksldYCxsTFH6YbemtGjR/8SRQk7NZrY0aXrwZcA3986Yj40zbz veUPu4OjyhM25DHcQVUvaj38oKcG3zgbrVJI12fgD/YKwTs0Q8Fc+uuUjZhF IHRKBnNPYBbudxEZSGZ1j3DHm0qzQUdJJDtux8OLYhT5/FxVSUPkG0sT/w2s 0M1krQBZGez3yaLdKLTUhUkoUr2KcPHGd1Y5r4WQ6nuE8DiOUMXeWxKIJN5L i18xW2u/IjN2b2Nk/w8L+W3GQfdHvB278lUJku6waRVHpUAXJj4mSvg1Alkr rjuPr5uE6alGNbRCx4eK2iqT3P0M/A13BcxWXxiX/RcgX9uCcqhLdFX9g5sW r6P9pwrWRyETN6CGAndtwfh0JIxC50J4M0jih2Q/K4xn940CuLiZstkI5hgO NgnmfHuexRppsiFnE3AWZzTaUEMrKvJ2fztWIcjqjUTj0wHWkkPUwIhrsOyY 1JAma7RgR9YyLkBCtMkdRTLpHg/md7v5Dn6FwXCGJzwO83yv61fKWRGHnzmW sCCQfjNn6xZ+LbEOgic0c67CaKxXtaweeRXflOE4GVsOWiLi9o9X5BtG7Ja3 6qLoXsiTIGWKQr7Ud9qAeQzGSfxVy6hAUYzw5QtAmBtUkoGT99too/0aoV+g 9q21bS2RoqOVHsBmtaDDS9VKFoAmDFF6KkEM9i3QqnWfhScNiRYwvF+LjJhQ 7omLVFQH2E2jt3ldoTHKV7gzTrAqJwD9fcSlnij/EY9OzNVL3yIuGQ6SZwqQ uKN2oG1/SR0aaLtEQ8xx/aUICNNG2AbX03bNLO05QiLxaNVNFZWnKkCAcSJS vbVI9o0wMTkZRbx2N0v0VWweNngSVZX8eiQ2V6zgJkwqvQ/zczcDRndBPiup GgjygetHSZ9b5JUXtkJKoceBi7sZsXsfjUuLHbLHnAvGVKFRtZeluGBGO8yl paOx+TFJH1Gb4NXBBSy3OfAkeYYewI48euUhBdzGA31B1l2YM2AGCPH/ZTCU 4qUlnbGocwc2LSt08lmpPsPZGriZCJt2hS3FF0/IUXSX2XYHFYLAX/criIGQ wvrZ0mJ0IRLa6n6arKDMIEViduusIHfX+QcKJCjHCJK3OeWUJeoZebmcyxHg zf5ZBKPEeKSPwejJzWZmEFThbhHHSO0faKzYjDAMCz1B0NUzF5KViYglvMhQ eL5OWN+ejGN8W5I0sDgRidMp4PH6RCLW42wofEDdRUp2Qfamg08Zxsk93tcM p1WM9EjCSkY2Moo9h28suBZBaAWcFfUITHnGGsuZggNJH6BFwfKPWRgp+7MR svUE6OiMGE6vnEvyaGVVL40VJVg3s5QGjJmP6KMbtuGlCgcYfP+kfsRgT8nE TS8QUcLf4TkvdYY8qIUYVRfTV5wFP4IQrl3f6ksMp33QG8rcTKz1ko9JtWa/ PS0yu2wWMBGnxEjhvHVlx4YdIe5MBL0gr1q476BuK9+R4cAhxag+rIpiBRSl rBnnXa6T3+ItIiq18F0keQJVWL7KaKVHShGE9GSGDjQOeMVfIwWExzQQKpUV CZppAYaxrcIoj3e1VRhC3XG8pIi9YRFbb6bj4o+wSUFSMrAT5OEeAs89Nd6U pmOt6WS4ZwEWf93kb0sLavguS5KMacuH8DIVrtxg7QSJfOBuFcTWmGqSjQwO eQI5jJNPPceGMXWGZDzQk+Izw8hOQTdz1x4szJZjkEFc2bNVnM44x07SxzoZ AfX9VGxcSTTUfrO6VOzjwKrC1V57YEVgyDC/tck8vAVtWzwZxkiRYsISL3J8 G8fGkdRVN+yeBd5Bx10A1HbCWhB6ZUgDoQf0ZQH5UfObJXF5iEc69OlloJTl NfXcdLW95a9xownc52asx00hLuipPwA2w3rR/Mk7Sj0Xo6Cjyj6QmLPOHBsJ c7zv5J0ZZk8sQ6KgyBvjRF5JcGcE5wmxxCd9XPdhzaCjWxqPjuoSeiO4nnee n5ZyXkuPxQjXUJB7Km4tuh7konuc62AjBK75i+rG2EmICVIsXqh3DlQtI/Cl bcUbVg6aFtUxFDdmvseWWOlMlV2EiN3oDLAipfoE/Zj7jShWY1HQZmP5AHwn V9BbZNlAdXQDnSZZuaByINEXjKxJnUOMzmtYaVYMLoLGGnXk/QwgGxyD+nLa zGQ4BF2mR+pnkppB/yqqn+B5FxXBoYk0UsegExejqhd0esFFP8Yq29t5D5Y1 3WNaWIi2TsQwo+Ig2m9020tTNfuTBjiFGYLhOmH/bE9C1sp4dZiZIKURpSt6 YiKMHXEudDmehcL+NjCVOqvbMoI1IcajUcX9H0mfqXCt6zLXtEiCU6OnurY3 WNmscvyymK5TBwgAmJ4ICqeRrw3CgTBipCcsyx0Vl3TdUYQfrWDgG7V50vCu nSAhdkj40ZeOUm3AN+NCYqNlB4+YH4DkEAx+F0G/XLsZ5BXxHrL3+a8LGY2/ vowcKj0aeqtyB+7tMlbS2RdSf7Iej+pinFHV7mUQ5C/4acexuPdUQILeJ+zC dg/EvaeOMonGUggH95dsBjdGezw86YlJreQkjT0FCBqn4JK/zgIEN+tIW4/0 6L9p6wlStUGFKMCBrpvRDGaIu48/emGEbCwQd4FpHSAs6vHlrCZA1VwZWfGv 5Whb9gLOuXf1Ch5KiPQk5+SqNXEXKOxL8v2FsAkcJjTi3vYrUrcc69IAl5AD l+x5eCI+75QoKnj3ZAZcdA0ENrjCCduT/Vppj9dS0/nZwBDfj+pq8e/JuKlk gXCTfQ3DiqE+qcZ8COd7ihX7lZV3vQ3LJ8PkAbfM+LGsYfDB4sjxDKlMGffY IH1neIJB+KEM67cDlGMZVv9a9jiBBBoRHD8M+oTxOtsDPeXaH5XO6Cgb8D4i nY0GziADFHbjMSn9ZGrfTWXSWBAdZLS6f7pShmaMC4yw7vLGbgKjrSW6P92/ 0InOzGZ1W1WQsY7qGEY1Gzweo/iiyqEBFoAxl454P4loNR8Ur1wuAhfJ7vJ2 aT16UVjQLWyY87xYwdOh4wFB3vdQLs+XmS+F5UDWvyEsgwnGfbkhhGWkfGpc 7/mVzBzqUOAvLlFK/4gdkGrRMYHoq8B0pPl6iszihPRsrUfxuYEevso9BIG0 UH4CV6ZDkiyXU7IyAV0P3T0qwOv/WpC+uq/lR+Ry+6eC3i80Dt5ZvfqGnQKj a9z+1tOsTMOEt4bZ1wNJqxSSFXvood3GEJBDnfdBG5Z/n8CQIxfJbzU0jlkH WWNUV8nQy5ncwNsNfHR/7CP1BusqQVkjjeyrzEHQbwRAh+4Y8xmHrYzWhexy MaXviEETrdvikSNHCVZonGLoOhIE73QJDUCD1f3Wca9L7AcHiuT/rqDhdbcV VPyl0FDVj+Zy/Vtcem7q0Tef+KsM0qeIyqO/RJSRoO7sewb1nQjJr7+6/BbI 40uY3QqB0Q0Id2dcuxK5tUX9FJeb1PV5dJb7nCkoErUDmdBqaMX9as/vpJD3 RgZ+3G+wvd0snLZdLPOud2nvt7kmuD//fPrlu11W9r+u+1/3AxLlD7Qnudyf 576NtVWvIPMRJmrm/w/nIX7TZW5kc3RyZWFtDQplbmRvYmoNCg0KMiAwIG9i ag0KICA0NDgyDQplbmRvYmoNCg0KMyAwIG9iag0KPDwgL0xlbmd0aCA0IDAg Ug0KICAgL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnic7V3N buQ4Dr430O9Q5wE2a0m2XAYGC1QqyX2AAPsCOzPAHhaYfv/D2knxp/VRNF3J bM9h0UAfHEuWSIr8+Kf64zSc/jY8pFNNef1/Xrb/v/16+udPp/98/fLH+tft 37ffv355fP36ZdnenIfloZxe/3X6+0s+pXx6/e3085D+cXr999cv80NeX1// 9vOQh/L+bJ14pofj+6Px4UxPnt+fTDLwQk+cd17SONTb9EWmv9LD5aH2P7nQ dMvtSZ7pSX9UyaWU29M88NBhuq1ieJj6X3yCDSywyZf3J2WlLT0hCp4fxv5M M4y7whP82oXJtzG8u/AzTcX7LeU2fUo8MJWV8mfm91k+fPtIlSfwjXSjYO1/ 85oSU3npLxYpUYBaSL/cSsNKm4W3OPfZA0RNUxpZJh1pwHUudHqcUTWVRDyr vHx6NDnibVB0pun75CSaq3n4HLLEzPQsDZ4YoUReaAmLcAK5JVI6yBG45mtv 6POqo37pqK261FZpPcF+kHaPTHTiTSpAcuMMkhpb5JRMeaBn7XEoMhc/oQ3n Sz6zWCXgBdPgET6IsoFSXBSJWw7KGoZnEiKZXvjVak01DikjdiHJaziQ1cni yTpK9pIrLpQ4rcXI0ZuopUU3kEJzaNW1L6PMjKNA+vNVUYo/d2YdMzizpTrA ISEpUuQrJBBnR/7SM73DfL4S9ao8Qz1qnHoa5dCBBbvVhaJTC1C4XBLLJ++E MQkRr9yOSH+vxprhWMkK6R0yYZqy9KSFPsWz5T8cFQTU6HmDc40i5a85O6H9 kzROLQ8NvYprBnqImep9yVCV7RuVzufUpyiupbRyYEDXmcbJSclMLWef+P1m zQTDkH61v2+UJtR5IDkr1B5J4sQswqlYlCGZYAn82nV4IjPoitm0qdjXuJOR jJMWxO6LoWoc1lRgO4wSS+VgMANrIFEjAjVcSAGtYN7Zykw62sJcLRB0SSCg SCFIpZim/o4KHZKEIFINtBDVApOxPXF27Vjj/qiEdLmIRU3NTC5Tz0SEZIE8 Eto0rS+Kn7M4r1p+jgVwDMcGnkQMDmwpoeoeQSaREaiOUMkZp8RSKxUGRj5n 2NKbJPRneWQHZ+RhuRqieA7otDGvEzc6DZdZicGzi3P73HU8QfQRiHNAgtTn Es7bJe1BZ/xDoFztHAw62ZxiAHcUInpSBlAwyK+ud+2Cryd6JkrPsBqR6Bh+ jXePJlHZYXBQDX4g3Cqso5KBdtnXCBA3ERpnlVXAgBREHrCVMrUMKE80isS6 pJaRpabbW0gkXvME63FWiBpbVpjZ6OmgGbosqGtBurwl8HZrO4o26zEEt2vr omHZrBVbKom+grBgCMmgDXFrBS8sCM9FwpOl2YKrYvMG5r5XsUIwJs9IZF2n 54cvdNpkS3QiHUh9oWWtrG1JO4kPnYmMwkZi20rC1gDJwDLRUI1wEVZf2E4p CTMieETXVi4mbw1ZdMXcnxs19bM45axRA9Ira2oBmkVQlstQAELIxAesSJ7i Y2uS88OjEEaiqzmvJ+qZl8CTOb5a37MlgqNGVbJPAtvneFqSxAXPGppcgezP ioIzy4dQcDrC1aFd7hEV7CqGt5h5oxjAcMj3eY3o5KO9D4SI0G63yEsMUu0H TYCdaeEMlCRZDG0DAg3xhKngkbI8M0Mu5a2x2S4apHMjDuBEe5JraG38dCT/ gVj0OTFoAITIo8ganp1AUSS6MZ23BOXrkehGPxo6TJuZpk3mwfPcgBLrSR9Y ftBKs5ihHARic/IEMRYD88nNB7C4VtKlysVNleMQSd5cDFwVSA0mhoiIkDh0 B4Fe8XwxGqQ0vBN4Qc+LZTtLmiwpITxzCMXxSkIBYInFhPzmPhfLewaYFosh Xcej4elR/ETD503I161T7q+o15+NYxlQAiHWTbQ8TaKgChwEGWLOrE/LdT9t iExkE5dagb+ODNSAbporlndEMqVmsjYihhhxLlbmy/F8HcWFOUPDgxcvB/1s x2agXamZEQSkw/ucO6r5RUGY2JURwexJmRPYxhAJL/VOVQZFHnyE+mGd9cij T+MpIyfBElEHbfqEUR1uizHtwdSoVxBBo/pyYhhhw+cZnnpvudrD8ktEEY1i czHfZtQGGO4hSVd/CejNQEAsVNIQyaaBB51Z08cqHORE9CTZVbIVVKxXKdHy zbH7weixsvyzPKRMBcv3CHNxcU/fov8v2PY5iW5vX4YI4zykI+QoQFRXvtVq rEMx5QI2IrJiFmAWc7OoJKCNDRbC5Cn1tuqJy3DhkDJqdWugU3bheHr7yF+Z ngG+zmARK+aYROhAR3K8rQzJ2URySGKV2Tiq8zJk5C2iya1MdniMhFOncYFi j1S9uPV+kaN6577MElgqiW07GCuQSQmhbLSTgQhRvsLerYyQxNy86idtbxGD RRCfCL6Js6U0M3VXa6S+r1iY5FF0gplEmji7MDisSMVyOLCIKBTM+GhBmyN5 fgnkn4TuI0frke29hHhTsZCB47PxwFGqW6GKuU8c3/Vh+XNO3SEX5y5+gWeA ViZQODeV7auNLrWo7ZlxAQhkjxdDpbQqzgppYaWNUxEfqGaMrNpQg6oCtR/A NbCHaf+cCEHfh0O75JXrfjbZVjx2ZW2n0vMzCZ1OKrCH0p3O8qKBKMZhQg9O eOUgN8fIfzDuZpQnGCYHD6LpEK2nRTJULAlPG5GZ9qpppUgqwJF3dP0jBqPb f2KpJFR2qjMCYyMGqyNVOF3HnBdkFUEZUlSlNUND10BvxpQLVnsaRbmq28TJ k+IWoSLYqpdD1nRp9d2m2Ud2qwSkagZkyhkG6Wqn843mU01SBra6rw61WaqX /XcEBHWm0evVzpOnVJB2BxI6TmV4yAEhCVPQ0CllU1WtXKjrZCV00LyXCjVK 5cfdrfmos5viNPQnspHYNnt0c4pNHUFDDOMf+u4RDwFg+Pwjy5qEb7CTxkO/ npobl0rVSYnUXM4SslVGSCCPJPVzSlm60SCY1Z4Edaim4SpDdQV8luhUW3Gh IEQSICmxjsTUa/GO+rBTXYRHp61cHuHAjZANKmo9ijaYXBROKe2PCcMO+1Le 2hHGum32jX/jaRu7MfBx9keOW5+WGskGLpehsL1cNBhjSNzHqBYkBmm2au2J kBj43AfE2PKggjDoeBsnBw3SSp8r5LMpsmc1xCrLq/LBaTESoY4ykNhBcjYV iswakM5TGR+rhzarRsk/NaKnoSiLR4JYGzBs7hlspkNct4rRqEEezbbggQuo VNFoiKdI9ye2lYOLeFtFRSvA3hK9gMGoBk4RLTKx/RCYbBSfGRFfoGG1UBVi 6Q8mXIIBkpt6HQvV6B1VrzLyL6FeSxfL9duRjIx24Ag6bKF3eit55GsOYikk tKldFGklIYNO0aFksi9O+W5rndFaj9gKYuS/zI5tsBiffKiM+NIHpM2LYx2y ZmfpksLOMRUARGVoTIYxQTP63+5F3SLgxJKNyWGdht1XNmI8HRHMxGr8qGAm NAAlqTozdYxQy4HYGQEjo6rTaDg1eoRhpq5D6jhkreIzcs5GrZ9Ry8GXJOiQ gdE4f1dAAEkEW/sBvW6+yA13m9YBTet7Yapx30/gLh+rWNOvTP1M5Ra7Lsco B4x0kxqJaS4bCJjyfTRtVObxvsRszv2dYZSKtagahwqyn0jrMX6f7gYkNU47 Zoe6a/luXBXaq1CJkfnFJBUqRYQ3BYh2lluJnIScbTO4E7HbndG2h+8qWVUu /mNaw9sCeS8uVmbDr3Ezw739R3w7Q+8K7/oek3nzgpEhMPIB96CwO+O3kyQH ZN1GuBavy9k6QfjIyA1ViUva/Ar43Yhs6LIE4Faog27XMKB4Z18s361mGe/1 INRIZTVbAnx2/Q2nLdW1XSFrC0ed472YN+9zT/LmzqgDeXNnlkBB72oS2+RZ DO8GYFnEXesnWo28t9eqVq4cqqma23iqzd58hwWtAFjROocJV64fUk3a1Suj 5pW6wRRAQiPqO+ls7LaDWtf6YJzDiU84OAwrMLz61sC3OmldR4iwXEBh7DsD jKVU6Ev8syCrHbjkM1v7ToUjTo4D1i0O8k1ALtQNddQEyEiJSV4yd4rpvuoX s9rHUd1iyJnV2ahM7t8jJboaRzkHADtZOPeAEfc+M9B6GfYs5EMb16sZRWag eA2XwUByEmDCovu+4VFxzWyk2fB2TtmxUYZ1Vy9TLCnwpNAHpiv6nX6e7PDu 3hwWVmjQIXBE6O68xRdYvBimKeDBWLZdiYZz6rrFFBixHRXidcua2+oWXwcN CEO/A/QOJjCa1owrgz7JbTH6S6EZybi8KlqsvOOEvqv6vLDxO6jq1UhB+5gv sNqwYJORTooflhtIA98WQK+M7DQuXpOEARC6Xc4aaVjZoEDg/0612W7XPor0 mop7Rq5HsFpnuyXb/aC4d1Qd29nM0mkugG3w9StdMTp2dNGvb31OV/F2Ew9s /QNlWHke3g+rFGFx17ZUg66gLNN9K7rXIlDSxG0vfGyGFw7DSVduqOYoT5Va sI5qJRmpkuKw0QNBGGiNBnHbL8VHkfxOcpzWN41lMGh9sCjR6Vx7ZPuYjeJg rMY3KjfVa4G7Z+gqX7w1Splew9sHoke9aiFfq2SC5UItqlVRF8gAyZVR7fGY 8fOeR6kj2QpdGFeYODk7J6FsJQ0T8h2WakSVIlW0XUSHTcn+tRs0yj0wO/U3 7wpjRI/V20qkJ9KrnKcnvHDd1KNq4GcOS2eDf61Ha9yyy6viH1JwwvxW7cpV XbHsXSOu7uYfvfnKutVI2jaX4T7VT+P+Qor/SE2UMct+OcEdKChVyznB9l0n daGuxZR7nh0PEHcW6TsJtIq08zqXbzJ3g/D2nsPWb87vZ3L3l3yPWVD3W4T8 f6t2pN2cmRSLAPNI9rqF6oErMyMXO62OODWgMvBdpZb1GjPBIBNU5OMFv+kp 5Q3misNfVFhpSo9yPUFGPe6qwTRXuDjbdEVv2opXOe62AJWpjFsnID3PcsbH nM5jYtsjLtBYyqWQfEmad2xckVKJSHhpR2+7dfs1rlQLpMNzkR83U7Hx4SkZ Cgwtq5WVNpCpgauL1X5jFcMZV090VIKzAqMST13xt++DOsbA+gWjUBlj957o vtbCa1esdC1G02CcV+fjwN1QKyMzu/Otz4mhrJLh/HKURNFD2Q4IjuzWHTmX +ESKDnb6zY1MfQTWpWmAmjpTn9EPHemrsfftBVxrm+lsqiMc6mwJHOqsLnnm nKzx+0x7qx6h0IPG1O4cY8P9skP8d+1aqlGasTUr8fWV1ag2i1QCOv3GeFuD 1YVft4t52BApSCb3gI794tV7XKLAFVvBQgqjTdYpnMAI6H7hhFPxE7j3qUBe sPuzlfudw3aFcQC4xfRDLpiG39EP/NHdX95aIc/LljkRpJ9lhWPF4ywgSH6G oYeB7jqRb8j9/yfyJjT8uwAIG61IhpFQdpLaRjjOq5U4iCgAZN59QWbA7wuo CRilb5sOH/YP9l99BA9zye+huxgwtBi5fxGb4EYOaYzaSegXarlabYGb5IKQ Z0Q4ZnpxoI1Wtw5+qMmQgH0QOzZxMIQiLVgZp5DqOxdI0RiNZparYDX47EtG oBfNcFXQah/IJR+5oWJfkiMdXqpgUpcFWCkUJeCoWLyYpnndipmYUs0CYmnE qugysE62huIKXpzMuVxRVUtYxxmVf3Oafzmlt3+b5OZlG1q2C8XyhjnSpmy/ /Xr67adNwre/nre/pu2v0/bX2v8x+dtcCwWlSlsozd//L42+F21lbmRzdHJl YW0NCmVuZG9iag0KDQo0IDAgb2JqDQogIDQzMTgNCmVuZG9iag0KDQo1IDAg b2JqDQo8PCAvTGVuZ3RoIDYgMCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29k ZQ0KPj4NCnN0cmVhbQ0KeJzlXNuKbLcRfT9w/qGfDZ6oJO0bmEBf8+zkQD4g sQMhDtgv+f1IPbuqNFoltabnGBKbgMnZo60tlVbdVpX654M7fOte6DCTT/9d tvzfX344/PWbw78/f/o5/TX/75d/fP50+vL5E/k5D3LbSzh8+fvhDzd/IH/4 8uPhO3Lk/nj48s80ZkkvpD9+F13Y9kf+JfLD+Prommb73vjAnL8/b3M1fdwn n1+mfSJ3dsfXZ1t6Y392dbfXZ6uO2z8Y9n8Tvf57etl4xLqP0CdXHuP3J36B MfLEN77ktvpLOsvaekdGyBMP6w316mCW4Pc9EYlwaObX1vZEqzu/Plv0GY46 wkwXGINvzbzM5WVuCjqNmuFYQ37qTq/PfRAw6UcCLE3PiT87v3QwAGelWxIB Bl4CTe+RzeJdF/PbXf2mrFl30JPo1I3lpXImSiC/uMiwCF5WTAvvk8VLPEgl duYxS7Vgkc3KGiTvTDTxvnXqiU9JPu9ZGiV2WIybHhFiZRd+rJbUlVf0SSpv jYR7YFvuxmv2W7INlfHyIOgRrduXySIJC4zwvLWkh6vACBBSmyjPYyioqpzp UuMYX8R98IlvPYheaQ38yUWgESJDYWl8MEy1QQsnWMLEs8wwL584by2ozsPW +EiSTGQ5pg+oTyHMKrmtmv4NVEigEnxsQMVA7yUsrKme5Gz8xCshWdrGlmAt RI/zecdfoUJza6Wgfc3lWv/20+dPLonnP/vf/vyn9O/Dt3T4KTntJP/0//51 +EtPO2hOC3noew2P6Y6y6LnQbAN+u32PL2hFm6fvXMDTPxra5c8GuC88XxrI yxjbVdu/qEl2gW0mRTkuVicL9XNjl6pNalN9CMTw9RPgN3yl3aDXazvyZ/Qp Lg1w0ZR8hByk98VBqv6oC74loO348U4FufBuF3AqRfS1y6jwmKEeQytPX0SQ 1uxXDVMYjz75yWSlZDRqaiGFjqZSUugwoKoub6SS5gbWF8UwYRzISy7M6MPw NqwgqCsDqjgyNgBFRIsGAFHn3/pWUYGmBtBJPdg7/FfYQ0FyamlJHhbGRpYo 7/q2GsiYC1gBAkVF/1goWB0jtBTMzWn9FiSMSAZdztEy0xq6iRB8UkBWP3V1 SUFmjFThI2evVpzU9RNrIepLsamOvqxLGvVQXaZ1e6mzypCD6SOHsj40cWIF VqR7kYc3wHoNiCsoDerHqXBY6hPx1a/jY4wlTTwPLWp6H4ZoxkRifERCK0Og H7HVYaVKpKkAS/qsdciWufGs4GqlktRvggNJ+wk2gMoz4GjytvnpnWfh6du+ othPD/tuxFVMywyEjZvEWMdCGdUTYOIjUMCDrsORRZy316z7ypOnhxr72YEj ZPaKAIE2GE7jqIciA3KwIYyeRE+9CAssK7oXMRwSJSwpn+YNT00J+iOJE2pb CohG1bljjLNWe4t6oBgSiHN77NrEHKGBeiJSXNYWYFHzwNyyCqte4zki0wMR rqHARppWI3QkvmSDgvpe7Luj77NPC3is7zNqu5/FXS1tQBlkmWHWlQiLRb6L GDIi+BTWC5FRWEJAVwAsgWsjwHGyscIHiOdALcVt4+kamhwuHAakAF0GTiAd MEviOluTF8teZNlGSGZSG48UKph4QIYbXB0+EfVyesggTAR9SpGv8iLKHPUH CWp5a8UTNpi5JYWa5zZjsouko2dbfv5Yz2I+sEqyxBZfaZ8iLZLzjaAu6ENl C9TlrmH/PV8pMJ3VN5Yh7AedIy6ztb8wxaW21niSqKsdhqKTYWJdxSh+sKI2 08ULG0PNMQc0kLL3M7GCdie4m2jZpimpFdigXV4T7FVFdc70mNdtCfLrOLBi l/2AdR1QrJAzv7fCCtHdnJLUdezSSni8eiGtXmDkYET6GNef6ycDtMQmtMSs 5OAIMeHp5ISeCEW2PdUv00k8KjUTP9ooMIxoLdN8qfhpjqOBm+GjmzDPQa51 chwt9Au1T56A5ZLMyjDwdTn3T5qxtvmHYkc9SOc9PIa0D1zg69F1aJXATxrR usHsOsGYCM+LqGJTwsYTtPaYEYLDyXQcw9xPXQLuTnFLvhFUTQzzS07JGqXL 6gW2uYome+DzSRtHZGDXkJlmzXqQgsxZXwUznsK8GU8FXJyRkATJDwt6vM2k 6f76xnmgRjS5DUqvBpKvFIXFKlLNE8MyGtLrYO7s1Ca5prlNuXWyclrNTHYT E4g2GBldRcOKI5Kqv0AuuoKiK8iM6Y2NLVoQ1oIPkdHIFgLH8GqKH1Yrs7O3 jsUMlwflDYubc/Vlx+Gb2ot8QrtlvNSjkBDuRGnn5+o4CWtN5Bey6dVcXG4q eAj9uM1QEbbMqtHWAnu9ckz6RhXUGshAJPARJjWSBeu9WZS13zqjFH7awxFu QeuxBB9th/xgqcUcaKai5LN8jYUnEc/loQQEqwUVgB1QAwXeZ0gsygK0wGKG QnO9UAM/mL9slufoYEWjfFap4qC66OiNqmdPNkJz1qW9H7MVwl1gRzxMVj/X J8+naoRvego91Q80Uj+KaxjpjEBeZVIiB0OIpisyZjYi2BEm60jC1La8pge2 jTZxhQX1sJ+/aMZAtSllbZLE+EXnf1xN8oz5N1X3G2lMIenUExrqcieIdaY0 Y9+O5agw+z4WEZ+c0OLmnH0PNy0YamGwtM0wT3fVC/PCCLkV5w2KyQYsDfIN 1mv1F9Rsl6RhxcHmTE7xS2vzbaOGHowaJsLTH6XWX/a9cUpRxIHvzin8lCVg SZFmtmJSgz1b2BnhtQrA9FI4zhkBMuUqe3UHNwCYaYbiqw/uykk7bZ2i9wBf SE5ZDu1IgL2CBXyOMc1pqSaw4wGNdxObUx819PADyYvRZWCYc4xhjEzwLYUz GrX4dH4fPEXvRKGmTkL71c7thlJFCWF2M8B9Gou+NiMNlVw3yYgjTFGMAa9X sPSLosKNbaqmXdqV3UOQtHNTu3ItEYHmJsVrnQKNwG5pU5FYUZgCMrvPtB8b yVhyikW27oWIMFtKV6lshjJCP1JUffJ4faNZe8uplXmeqk/xkYhz4o3Rw6k+ fc1uVF1S6HESuerA3KcoXy8qjs0kutjHA3yPBBbB1dI4OcF30XGnFKYgB9TA uvGDrYvoEdFI1CB9ULR1k+RfRfV8qNmkaIOp72VY3SXtbDqgw8CdNsvRnaKF 4YjGSv5DlcEC5e1YBz3yk9W36W6bAXMpsqzjfO1rEp0QFoF6PUZFwz4VJJA7 aeHNF7zfxTsNdlmWzbqarL9Xrs4C7yje/cpMdMShqF4xOibdC6pqBVWPl4fw zk99eUiDUb08VGMkmZ8oLZdUSIUHyudOYqELuzdwXQm+qBeYigaLFKkU7ajY 1oPBS80RacMmq4sgKZnCFAj5tFduGdGcnZRRVkvNAVHh7Oqdejql5DQlwIyp UEqPNb97+SksAbKRX/96R223RFyy1Y597ljsq6aVnWuHt4cmwtNqSsawb9jQ ejSaO4ygyyiioecaNDdjJDkFvcyQvH/XSRkc5MPbDCq1B+TaQMNamB0mHUO8 uhHaF43ZyuDg3dOU1PD1oSIEw5rMyBXP2eM1gmTlHgMvpnVbm0eeeOjO6rtW vzUh5qlLRxS9Axts20ikth7/UIig3481wNHmCzZ1pG0xqbARpKyaDGkRrF8F Pp2Sntlm9AAXtE4f2k3SWyXTlq+w4Fsyc7um+ai++F1ZdE1RAxTKXfeg4Ieg EKAL5X+qMa958pnCNhb/G+oU0z1+uE8sV3frprrfYFNNy33c6X5LBr2uFasP wOpaaQLqTc9K+wrfR3tWyt19uGclX6epder3U7jvhB/RFE2/TN0Jc/tl6vdI 5ndTpi5P4eNlar9FbDPMuYA0Y/lCClvBu8kNjdWwFOonh2/k0ZqNm7meKSch r3e5S/IkWgZangDh2bul0+4Wz4lRxzXpmvs3Tgdsjr/7sEqxnr91h/UwDgUx HpN3rCs4I79u5JcB7+PsLRr3LeW3OwpzckUlspZxE3EVfbtoihrFdMI4ePyK P/oCZgTKNK/qP+/nzCKz/v3/AXDNC/6MTYNG9wiBonrUtfA1MYz8OwhJMgp0 CgVv9IRB8fcin7XxLpcrtHdBrnQ6cn9dNrfcwwf43B0DU8T2FeMXIKRlhgYO tvjhBj7K2bg30bmgY5UKjCiyUV9peZMt+0drxyNXPCmm0+eyBxn+AulfzX4L PPhSWzqFp04ybZTCjRaOd0XKpWy65Tnq51T3KoEn/GGt/0PD0vvtMNqMnwAz ssYUp8gvmnjf5oZ6KWCnMCe4rfPUxtrj1Fo8MBSQjMcNU9dwo8whRKkH+ubx 8IRSisMu2WNUK9Nowvs+Y3XX6RxjZd4vHd1dtHdO6pcfDj9+kzee/7rmv9Lh bmopk07NX6Xc59o4jQnCloXq+/8FTRXmcGVuZHN0cmVhbQ0KZW5kb2JqDQoN CjYgMCBvYmoNCiAgMzI5NQ0KZW5kb2JqDQoNCjggMCBvYmoNCjw8IC9UeXBl IC9QYWdlDQogICAvUGFyZW50IDcgMCBSDQogICAvTWVkaWFCb3ggWyAwIDAg NjEyIDc5MiBdDQogICAvQ29udGVudHMgMSAwIFINCj4+DQplbmRvYmoNCg0K OSAwIG9iag0KPDwgL1R5cGUgL1BhZ2UNCiAgIC9QYXJlbnQgNyAwIFINCiAg IC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0NCiAgIC9Db250ZW50cyAzIDAg Ug0KPj4NCmVuZG9iag0KDQoxMCAwIG9iag0KPDwgL1R5cGUgL1BhZ2UNCiAg IC9QYXJlbnQgNyAwIFINCiAgIC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0N CiAgIC9Db250ZW50cyA1IDAgUg0KPj4NCmVuZG9iag0KDQoxMSAwIG9iag0K PDwgL0xlbmd0aCAxMiAwIFINCiAgIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQog ICAvTGVuZ3RoMSAyMzg0OA0KPj4NCnN0cmVhbQ0KeJztfAt8VNW1917nnHkl k5kz71eSOZOZyYMTMiGBwEDGHEiCQEQRARMwJIEkJLwSkoAgYoIaQEDBior1 Wp7io94yWEXsC9qira0U26p92F6fpbWVar3q1yqZfGvvOZMHoL2393fv7/vu rzOcc/Zee+3X2mv919p7DunpWttCjKSP8ERZuqqp84mnnzhICHmRELAuXdcj PVBbFMT0G4To9a2dy1atu+XQrYQY/kCIbnDZyg2tO+reuYYQC+bHiW0tTc13 3jndRci0v2IbZW1IWJHYoCOkshjzobZVPeu/Zoa7MD8P83tWdixtOvFL/Xcx j/XJVaua1ndeLZzjCakaj3lpddOqlmn2A5swj/z2gs6O7p7vk9AgIbV9tLyz q6Vzn/MPizC/nxBhG9IAv/RjxKSW5jle0Gh1ekNaujHDZBYtVpvd4XS5PV5f Zla2XwrkBEPkf/NHcyfx4P2q4fvID/9okjL4+9H3xCxWdznxJJYnqWrezP1s 8C//uRHo1Uv4xyeR/Bwh04l9cOHgNwbfIwlyA3EMcoOHB//ERfksLC0dPEP8 g2+S64RuoZvMGjwOMSgAP1nOLgkckEY+BoEshQjkQTbYyKfkKFlKPiA7STdp J4vJ++Rxche2+wH5KTlBNmDZXGz3G+QsuZFsJlXq9/d4NaWGBFfht5O7n1SS XZeM9zb6hTTs91WiwBFyNanV3EHOkNdJKxmPz5+TtaR0iLtiEO2Ac3C7sHQi eQopNWQjCQ++BqVQSiaTcnIXmMBEriAJ+ITMI78kT5C3sJUl5Bbsu4E8z8nk IT6NfPhfFfM/P//8/PPzz88/P/9Pfl4mYy9DjZHjpAS9wQIwgxl9QvI7Bb83 se/9yrS5M2dcESufMjk6aWLZhPGlJeOKI0VjC+UxBfl5ueFQMCcg+bOzMn1e j9vldNhtVotoNmUY09MMep1WI/AckEJwx92VtdXL457KxrgxWBUUpbjx6g9m R+LE6gsELVJppG6syhXXyHFiq4nb59QeI8qkurhWvpjl6jgfFj8MYOXZPqk6 LoTxX3BWU3M8f25tICi+6hsqr8M6cW9lbSDgi3Nh/DcTi/DfrCapOS7OQXrA l6TMjJM5tfQ6MfjWJCSSSYE6vM+tjWensnV1lxvksxj5nLpomFfDdvGY0VNZ FSf2Y8T4Vpw4KNsHk0iclMfzZRyIiCnWGonEwf5hHGxxcMzGIY/uglZ7Y9Jl ZFDdvDxY3dyOEm1uHJbpB0mJBqTt0va5tZZSTLJB18R/eG3tsfS0ymBlS9oQ gRxLS0dKuo8giWAjncfAeAWwBGesnnyMI/oMFKCVDriaXsvjyo5GTASrUHJY YhsuOTF4aufIIoLVUilbMpXsNa6tjOuSw5Da40pTnOyQjhWe2r7zhEiWNMrG 5mBz0w21cb4JGY4RPlzdNi+eWTNnIZKwK7wa2yS64FXsRpdPqm6TtmOe8jbi PVhFl30UvbmtpZEqCjQGq7DMUFm7NXDKF7fiszpukeNXItuVN73jQ2pdnRtH tr06iI0hb/XyaVTmkaF1Yeo2s5lJX9nRJMX7lixPKlfTzpSCB7aLceMnARQ/ LgDWZBVVSTU3LqcjWt5EZ1G9XNq+o4XNZCcbOSqkVL28il60Iqo3mY+1F9ZW twWrhzvEeWGCD19cNxCIe2Racfv2ajrEpmYcfXLIWDA8fqr0PhlwPJVxZR57 kHlMxNij0lRVp5JUhoW0Gi1prKqrCySXFVnjuvBWTVFQ2k5b1IXjdlkMnMay U2MLa+bWVlf52OzjXGVt7Lzbdx7TNXOGyOBGnu2R876kjGquC9Zcm1zkttSt cV7SQrmhhUVWlZ+1esbtO4Pp6cHpjdu3Tw9K07c3bm86Mdi3JCiJwe3HjMbt ndWNEjNtQPo3dvji03fWxcXGNpiMi0zVafrcmrjt2kV0eaZLbU1JNKgIBib5 Apa6FM+czytWDQkVGtU6aUjbxfdwdEYEHZ80nSLICTR8X1ycRC0RxzK/FhV9 KVNKdkMDuA6b91FT4OvC1e3XqSLyBVIqQ6HtWpWKjQQC1Eh2nFDIEszE+66t TeYlssT3JFEiMq5eIy05lSpxzKclfamSoeqNQVwtd811f0erR2r0dkvQKkUj bAUYojbHT83DOf51Ulw/SV1wW2Ut7+PUFOfjaSpNRoQqj7tkVpHKBIFwuxiU XgrGRTmuqaw95Suvk0QLIhgMqYPaIsQVLwXNl4IvAIVKYhfjUB4HJy0iCJ0M wXnXJCwcqitVb29UdW3kFFW8b267/DyRRwziVH1Jfos1SGf7IsMvFZjD06ll +QJJjll1cROF37jpPXbD+fkqayWEGrTda1lCqpba6MLHpcYqBgp1vpHkE4Nv NFZRjMMhUxafquR4r/v7vXqS3br/42bQh2aweWdd2+SLxVwzbyg1t3aT76Y6 DBk4yMQdfFSLm36iI/ZntJxA6BU58/IZdhtXHLAELGG8QaaQdWEpn3XhbS1u kvs0GF9wxI61n9Qsx1QWhJRDJM0ABi7dCEYwuOcCZ9jscds9HjcYMUeMtzpd dqfTxd2Tnm51CYJGzBJsR6wL3BD1tHs4j+jxz1Bc0no3lLmnuzm3oJitM4gA 6bzAK/Ssxun26Hirn+/k5lgaLZ0W3mzBQotVybau4uJ+2O2HPj/M8YPiB8kP oh/e8MNLftjP6J1+KPZDPfusSX5k8LrFMw2L6+tlsFhdUTUnR+rrvWe8cn09 icw+74pWWKOR88VbTUWyXhZP49PNEuNEnaa8XNSVl1NXo2Q+BuACEFx2V8jF b9Tv0D+o5wXOzoU4Xg+LWb91wPMQmFCGsVZeQOuwO10OmpuI2/lszsXHvvUc /8nAhqsqrkqEa6cuSkydunAS/GEsPJcbub4aPoDnE5MTYhU3prj4mRfzQ7ma qiphVp9Q+9mZ+vkVHD3nmjH4Nvc6/xxGfT9XjLl7FbHYVSAQr5iNDlyZ580p yw7kKOnGspyAmLGXOAViEA2SodPQZ9Ck8Qa9Uwo+nCP+uVgZX9zOFfzZpUt7 2KAQA5j4UkMrZx4PR8dD73joGA8N4+Ga8RAZn5KnDCg3FN/s8yWvnmdinX3+ 5fMlpILK83TF+YozMnGLp/FWQeU8+/y4Yiq0p0skg6nMgzaieDDBF91WdE8R z2NQaXb4HRHHLoeQIdD1aaiX5TpNTl5uMEfrCFpKnc7SEhRibl4RN2F8WWmJ C/MTSi3BXMaAcs3mHHYt7CrvKTIYLZWVjk2LY9PLb7q2+cqjd01alqvPqqx0 ds2cOC267rr2mqeystPdZihZ3aNMLF5QWThr46K1uxz6rMS7i5dNm1IwKybP 2riwfw/K147yPSj8mDjJYqUgTasx7U0377OD3Xo/cWZkmIij2MHpHe50U79G UJjquoQWLiWcMygd8fnF9ZZohFQMPF9fcT4aPZMUhJLmkFzeGaDoxDKZ0Knm TrAEqWqUWkpxwnac30SXFm5bv753/cOOhWfPRvIqZoQ3Z914I7dpjuXw+sRv Fw4cjE2LTtlJ9aAADXoj6oFEXlQKTHsJsZv1sEu/Tz+o54keDHrjfZyY9Uj2 45JodTyi2IkGvLyGKslMi6VMk0Osu637rXGrgPZGzP1K1iHHIXfA3cI9lQOH c2BPDtyeA405wM3JASUHxBx4KQdO5UA8B3bnQCcrG7K0hjVd+JEBdeLcOe9A yfMoDfF5JhTijqAulFR8fL7i/Blc5jXU0lTVIGng0gCO6UmdsYxx1wGuNG5D tEGmCDoqFbQfVATL+NxgcEK4FJ66++b5LZVlYyePD0+ou/LWgSdqC0Ljw3B1 lDc+23LVpJnTlTWJwKIxVVUFN8DHUwormiiKTR98m/8GSiudOMh3lG6D1qPl tLjGnM6yl4jGvVqn2eQ3cQbedBuvuPh2znabahZONIuQC95xQbMLqlww3gWY tbsQBSD6sgtOj8h/5II3XMC95IJTLmh0geIC4oJ9LKEiUsMaJqquJFiMMivV pqjM0JrOI0dKce61PmzlvpzxeAZH8aXE6rBzwRy0CquthIolB6XEcS+8/++v fO+PH766s+7a7dfzzyXef/P1xPtgef0NsF5YDxtfeivRe/a3VHPGQQe3gYuh PzA9hbs7DUTEn6AnGFeMsBXgNgyc4GZAx0+o1CKD72l+obmKhEmEvKnUagT3 XGGz5LdLkl8SOL9bsycvL2PsHtcRNx/cw9nSTUcyxtyijM+syuTGZkKmVGww zkj3L/JzGX6a5PxW/5f8B/1P+jWikOmX+LBuXHgVl06V0qVLL0s/kKvrVVym A9Zi6wrupXFQPA4oblOtKkGtOicnMZziN/5zUwyffZ5EULtQXuepYlmilmiU wriGondSfJnn/DBGAw/x/8p/m+fXFcCWbMjIHpsdy+Z1PKHQU081uS6ASsfx 1BBVnWNKlxucECgRUCN1VopIiOMMlVA3Nb945ubNr/+mxnt910Bk9ZVe99wW 7ssJEB6758/X3xM151+YfsO2A4fWTyy1Qxq0JY40znJWVXmVVr6qfpan6lvH er8fShxds17DbTq87q4d6bgyNwy+qbWir82Ducq3AtlH/H4t2WXaZzpq4k1p aRkm3rJHK7j3EJvxsPmwKUSyxWxOn73f12sOgCGwXwl1oiMKFfTZoZMH+yZe IXwxr/B8miafX8mdKoDOAlAKwFwAHxTAGwXwUgEgMV4A+wtgdwE0FoBUAGIB HGXZBsZcXIBYA5OSFZB1sADOsuK+ApjDyvaxdhtZ1s9a1y8e6YOHtX3N0CcJ FynNr68XX22oP7e4fgAv8eXz55kBuEojkXoLXdUSdSXHPqz5nYbbDpBrhX4B ttjA4Qw7n3by91phlvgNkduiofqs28CBg8M1TRkZW16NRCwiCTA/gpAb5AI5 nMVupTlqRBMCDnQrFq2WlxPfTKyDO6Fq/a/mW8ekTY31JHZ+99e9v9vasqS8 n9vaVX4g4Yd+UKAY9uSJExPl0Jo4nPjk24n37paBu/WKqqqirsSPq8uoBX1t 8E34lOGOixQpXm0cwSZutRl481GH4vY4jhYX7/fAbg/TcyaLaJRNHq1RxcFc 9H62EWmYV93UVD3i4p9LJQfaUilmvYQIB9lvP0GYr/y7RgNrNf2ajzW8hoe1 fD//Mc/79uh05sAezxHCZ4hHzP5syL5FUIQ23Uy/AL3CLuGswAtKdnDGjcJW gWsXIEPIEsYKDwmCng8LHRzJEDOkDB6/XkOv4hEP2EN2tNwwxMPQG4aGMFSE IRIGfxheD8PRMOwOQ2cYisMghUEMwwdhOBmGfWHYxfg7GD8ym8Mw8f0wnGUN 9bE6c1g1LBtkbZ1NdRBh3Eh8f0QH2DoJg24IZIeVbiT2XlwwjDTUfzH1xGVB iE4qaRJozif9F9SvqV9jY8ggBC7FjGGUiHA3XABf4reJP8/JarxpwJcECvhz 9U0Pfbk3J6C56hfxk68lftVQMwIcBvoP33nPoXRcQ1dilhBA/ckkeeT3SlUe +nlO73nE+3imGL6fE/179U6T5RExc4PmDg2n1Tg1uRpeZ84BA59zm0Yp0LRz xAQ63pSXRvoVyyHPIYeDom0k3TQj39HCkZTFY2LKS8yChwChk2WTCKCKKyk6 dFlyytGXnGaSSjkuLEbtZXCMDt8y7OoV/wPCYwIX0gIJiAEpwJvC/ASeIzxY eCKZLBgRUWkvZgE0hgDo4giGAI5L3L/FOSRZOLh5bfxXid/+USkpWT3wyqLc 8PgQzJ4sV667ZUXrzBl87arEpz/4IPGa+Y1FYyor8+v5J2JjKpouPBR8+dTD J6emooLFKF0tcWM0nandiwhhkSx066ExWCw6fq+SIRInjtFJpTY7LaPMab9P 0TmJYsgoI7crLtEs+kUMG7xiO6e13J6Gm5gH0jg9BjYm3pPWyr3vhbNeOOmF o17o9UKHFxq8UOGFiBeGlJApWhIJB55jGbf4PDo2Gknj4zQTDUuiPBfXpyTq /qPxUyP3oAa+bIQH9PCwCeZYG62dVh7hjiQhD6ictDobixVoXBVQg0xuyhXj Cyfxm55+5xffePp0Qrxp/h0dE3u52LZD+3YOHAHTb34Plgt/+NL3tk/+lMpp 3uDbwkbNnSQNI4EfKitZVEnIXpNJ5Pc6xfAj6Y9nOA33i86sQ24T6ln4UCAv 0MZJWlhn22LjDDaPrcDG67S32RRiQ8Hk2lo59HFSHoh5gIkpL+XBnDw4lQfx PNifB50sq+RBcd4lmpdyGcw0mb1SLXyHMIWrYMaJCVVE9jpLu4WT7VBhAbPG r4loeBOvOvy6sEXdSJSWaDTBCVoWURHcZ0xIqRoWlXKvj52x7rbOZVfD7xL/ MunWm479GxS8W1kWGh+FJdHApOiT3J6cV75z4Pty04pVoHv+LxAy/xSDzsbP Zo0LoEfHbTcXRslZyBqlJo0Kili4R8ByyJR2iDuEewjFatP0FxfHbbDfBrtt 0GeDOTZQbJCkNNrAb4M3bHCKUXbZoMIGEduIPW4KuphUzp0TzzGYoiIIjDYc nA0XHviwLt8/Gcc+Obe+qrCO/2FZHo61fGY5rrIWV3ksjtVO/OSXStTyiPVx TCLi6LMQalwINWlG52ig8SLQeBFoAgg0/iTEZGSkAEbKQIAJgBQAMYBmj8sc gDkBOBWAeAD2B6CTZZUAFAcuDzBedIYXYUtpxSWLHGDIUpfZnrkhk6cA4xE9 koc3XYQt6qqPABdd8LKgQtc48Yt3V61dPjE0IQrNk6gCdLRdPZMCyt+e/0vi N+Nk4eslUkXjp68EX8Wln6oiyYeIJHoyhryi3AB7nU6TaM4Ckc9S0jJmZHn2 5ohj8u9Pd2rvE7EIJWU4lFuY28b5CS/yCCB8v02RqV0UQs2cQnijEPoKobEQ MK0U0p9gkllMD8dVI5H3NDOGd7znS0qoLQw8X4HAgXRrdBiDc5bgarid3hkt of7QvaGHQ0KBHSK+Ch/HZziyHJxZCJ4YfPUZjMQtxQbcpDK5NVAokVFwEwRm K2UaFoeowUiYCQ0zbIvudFjsiC/cgsSF2NjgAvj2iq3XXb/u6+23vA1jq+Yt CmQ3rPjl148/Vy75gbw38VBFVeymjoVXP3pHx91fKT/Uu3n5yrrbdh5PrOrF fRn6O8IVMMvJIn3KXPdbVkLth2SgO8sQqRE53vQpGpPvzeJiy8Ehc8r2U3NK HhDF2blQox/87JjoFKPs8kOFHyL+USY0wnzUJLMinP7HLBa71JRGRmdcwUCi tiBcSjehxVcm/nrFooUVFYsWsQ0odTkDwoKIZuaiK5BWccUiRAUamT2OkVku TH3apKQZy9gWKEQT+7X3mPbbbF6iuSd0JMy7fUe8pvTDRjhMlHxyI+emjP9q NJcRN7i1tl4lRPwoEN8Bf54fA698iOdDbz405ENFPkTywZ8Pr+fD0XzYnQ+d +VCcD1I+iPnwQT6czId9+bCL8XcwfmQ252PglQ9nWUN9rM4cVg3LBllbZ1Md RBg3EpE/2fFQN435oLCeSP5wEPafDsRQ+iwWq5fVNXn1fIkag51GCDg3gPtB DMSCuCoBSykNvTCqp8HX5bZwwuPT5/9r4pu/WjQzs6rKN6P+V9Ky/gFtMhgT NvIXtjQNvGebVZ8I18+0Jr4yKhqrwhUbi9jYyD9Ksslbyi0ijcIcdsMjaWbf I5mPZztN9yuc067oM8rsB4nYr/gOuSRXG0fSER7T0dQPav3aFi4kwSIJ7BII EkRfluC0BLdL0CPBHAk4RYJiCUQJPpDgDQniEjSyAr8Ep1h2vwSdEkQkGL2z ahgS5BrVHZ5nEZnqGc+pQQRzjtHoiIDMmg6QYQa7YBZNtjJe0WWoBo+ekel1 clPEDDqVRH/o0AS55+7effPtkRmwuTu2rPhK2IzOMPGV6PKt++6H568vqhrY +p15nHdBpGpg6hS5oil5VqXdjOg4hf+tMjWtxLe3qKg4MOYR+fGxouf+YlF/ /3gRONFi80/R5TyiBMwcmDk/18Dt4gQbzylGsYzT9CtTDk76OKMkQ6QmYENZ iwfp9gOxM6PfqRRl+il9EOn+g5n9yphDOYfCHzvNNjDb/LYG2y4bNmWjTdmc 5TEnYkRuDDwxSI/Bp5/F4FwMXojBszE4EoMHYnBHDDbEoD0GdTGoiUE0BgUx MMTgbzH4VQxOx+A4Y0vyLIjBTMaAzb3L2vlmDB6LwYOsnY0xaGUtyIwBG/kR Mr0WgzOM774YbEk1tCjVWbKnd1lnL4zobEUM6hmPJ8Xw2xg8n2LYgZ0pg4xr UYoLW9qL03snNegjrMfbY7CO9TgvBtNiMD4GKAwhBi8ztqcYGzIsYQzTY1DG GFBUH7GmXmWdJiWFg++JQXOK08PaaftwBN8expSUAbaiTRUlu0kOpZlJEccR ioGTrcb3Ugx3jBBzFRtKclqTsJWfxQBOMcbDbPqNMVCq5jG+0IjxvsSmFY/B V2PQyTqrSk0Xa3NY0McK5sSgIgYkNnR+0XDxkQX7NIwErlGnGsM8ozkuz/If Zvv7vaW4qN0nj13XIAB8RLdo6NAspWxvgVSWYSXeAZUveT7rio7cs5WmDlws /ATbhOAEnh9nGxccx3v4CWhkX0eoGIfP4/hML4L0xRSgGXCk3CSGBDQUGN67 XfYk10EP9dWowVmq3ZzIi/o3XdHGRWYkU63FVw771d13H5395Xtv2RmZgWEr xL+zYKIvMRnBJpmbN3AO8WbI4W7btmfPwT20nJ53pnZ5mWS7YjQbIY03WvYq WtFDAaMozVTmcd2nEKfBm+1di2ji4Tmd/TZeifKAIaSJz+JxG5cNZ7PhaDak tmupTQgTOFG3aQxp6a8hKYj9uQP+poEdAMucsMsMC/TA9mW4PavTDO3JWBSR N7QXwd2ZFt488favX7jv+ISxpTO9UllsRmfD5rUTq49jPPnrP4B486JxV0Sv an720PEXtk/evIHO0YMRxVUYLeWCFhF2b1aWX2SnBER/v18knClXsDyiiGZu H8dRaK1g4KpJgatZg44KETb3YDA/2MaZqGAWIJKaDmah+/Icshyy59nRgeXD onyw54OQjw4sH07nw+350MNCBE5hYQLGFW+wWKCRUTFqOMWy+1lcgCHDKO91 ifM6p57yJr0XSvJSJR11rPC0WQcejYTjfUYnlmW501JObKQqXqp5liGtE65K 5E2SmB+jupbc1u2+m7o3qllfOzWkWfx36LZuIL5t3/1MsdhpraZNsxz16ogy rcPUa9qVOqa17tEKxAtpXvfdybNaxeQz+3b5OAuf7evgHJt4xcxDuiaLX8mR bOjMhghVrVG/BbBjgFdx1vQw9PTievU8VFWt/AkaWOfa4uLWwRHgfmkByVns 5LbY77MfsfOvaGCL5j4NR49CVeygrV9yAkp/SeOQQpWOGz723HRiSkZB2rQr 8t86+N1fg/Z3fzspnxs68CwwTUyUP/ENeuCJ35+ejiXOU/3LG3xXcw9GtDlk n5Lhw6DKu1mntet0Wh3VpSgiBZECvPuIT6fx8kbzEZPG5tWZJbRFab/W16eQ A5qQZjVn3K/rsylu8wFb0LaCmxOCZCTzyfNekQJZUi2i59i+hlTQWBD3N6gX 44rlrZoi92xZkMXTTEDiPF+zr8fHG3yQTnRg5NU9YB3kaLUOSxAuEyOC+tTc s1KxT7/wmmPGwoS9o9qVWbsUXueWmMpuhj9p9L7y9s8OCAsuPLd4pgdDyYpW ft7V0zOrLhznptcpeVUkGd9z76E0XKRJucKUfsTIu7gjYHIdsKVzB2y9WsXt 0fYWF7/hgVMe6PSA4oFiD0gsG/dAnwcaUsQRoD+0SykRz6mBcIm6NRmagoPN jk6Ne2+gUv1R4tsd073ua1uHA1o66gvfwlQyNhOuQnTMJQOjkEP8340czxKJ gkZGCjS+GDAcFwNGyjklf3kcBoxRroj++LhtGC/ExAz+Q9xDFPCCMmgyZaCm FJgLMowmY4HZvM3jtXs8XpPRZDZuBWIHIDqbwykIj2jMwbz7sjKPeCEXymA6 8GEygVQTngDyerw6zW479Nqhwg52h2J2RBycjpcdy7le7S4tR7SiltNpFUmD YODhx2iWcdNl0MrwGcrniAxbZGiVAUm5jIo29qoMyaL7ZFjA0lsYA5b++BMZ XpDhMRkekGGHDO0y1MlQI0OBDB4Z0mX4mwzvIp8MzzI25NnA2JBnygi2z2Rl kDL+irX3zVSTd8iwMdXqTFYDR+VkXe9NtnxphU0ywAoZFslQIYNPhkEZuNdl OCnDPhl6UQdYgZ8VDNF3saIOVnoNY4gwHrMMy5Dv/RGsn9dEkq7IIMpAZJjY l0p9IMMbMrwkwykZ4jLsl2G3DFjaKUMjqyAxNsWTZDzFWPpYYbJkeMO8Zs3o YO8y2+XLxo/JX+MbPifIvEzDoxhHURer8Y5bPO09k8rQ9xzq19RbXVEay1Rg zIPOKZp8e2aT+vYMPkWdqVzU6cv15eMYJKdHMisyOzJ7M/dlamgEBCnEoi9z 2KxlE8YnszrQqgcryZc+yuD1xLNy6Rj4fqgoPbbrvoIGmJwbzU3cO/5La2av nJIvjy3KLbzOyr1Wf0VVldPiGHNn4jjcvMozpapq7JILa27bOC9aNDkUnq8i s24xIvMYOKmsyPZnZ/lv1enRT+mzsrM3G9Lshmy/IU1Mk9I4nT4t26/JMhtA zxsCviNZPHDmMYL1iEWv0Hdqig2KYY5ht2G/QWcUDHpDFnLr0jhFl1bGHdD1 KmPMYdDxgQPhwvBqzkxx8SEsMh9I61N81gNO2bmCm1IIciH4CiG9ED4rhD8V wmuF8ONCOFkIRwthXyFw1xRCRSFIhfB6IZxNUXcVQm8hdBRCQyFECsFfCOZC mHQ2VQ9J719SoYMxfcAOFl9KETvZkaLEjhd1lyjXmotVh2nWcNHQr2Up2E2e 15xL/kbvjlBFOaO+XXW+hGapwmzVF8kaqiT0DatNQ7/Rh8Rs4MYYwJ4NdX7I 8o/1c1uz7s/iwhjyZoFG79CH9bzqAlDnGtQADxEaLu/KYYQr1C0eqEJXOPCX vMRYccItCUH1i1nQCl/ivJjzXNvCvOPhz2qFRy/csKwsOOL450Inv3vYY/Ik kriKf4V5zBJSAS5lmVh6ryCE06W9WXl7icOdlaOhPz6Gx+71iZP2KumZ5iyw 8mMUQ3rZmC3E4cuSwlq3P6dUnMJ9ZMuxuad8pFfMer++Qn+NfpdeY+Cn6tdy Ez4yFW9xK8SNOxDF3cpJU2FEePjy+eE0O+Glt+dRvufVd27Ymc/5lxfXIyly ftSP6FcIRnjH+JGRe2UitGjXarl7tXDEedzJPRZ6NsQd8R73cpqQIxQO8bzZ 4/dEPLxBYyk2WMoyJPT4WvoilwkTUzJqMribDLDHwCLX5BawIbVCa+oAzbo0 QPc3AjPmibmpGzXrgCOY3PlMVA/eKQjwyR1QkgB3ztsDprX9id+cO/HO18ZV fGvF+p8e370c9E+M+9G3xcyK6fNnTK2ef23NjYu3fXvhjjMQiwblW5bd/dGN zfX1UlPBvDWhQ0t2f2vayum1d8UXrW9a13/zis5NiXFXXD11wa014zPVU9g/ Ixb4MEqbwqK0uA/MPvA592C05j3sU8w+vy/i43V8FkbtJozcFIzftJnaFdz+ LOjMAiULirOYVo4whqGFwRDt/On6+i+I0lA+ZRNKhT9/NlXVyJ/eMts9pgos O24boX9V2VWLL2yMjXnwYfVXfc1yHLWVZJElSoH1iG8P4Q1HHHt01kUCEEER uHSNe5Og+IUODkdsNRzIyM5YwaVGOOI1I/pbLX1xRlWMjPu08CMO9nDAV6Gt AV3MOlsguWkY+ds2rpHVInLsx+0dMBOWJbYmnh64I/XL9sToj1595UyRorkq 8UDiB4mzif6huXy2zAal4IJsKMkgMPgJIfwu3LXmcN1K5Bpbg+2ojbe592aQ bJ92r8Gcwz0CmZnZLzmhw7nLyTmJWCxyoijhg2engIMm6wwxRHIQaHN8hux+ ncId0ga1LVx6CAY/C8HpEDwVggdDsCMEvhCYQ/BRCN4JwVcZcWMI5oVgSgi+ ySh7QlDDsvYQCCH4Cdb/Mat/mNVPH1GzmdXEFv8UgpdZN0NNyKzyg1jwGqt/ mFF3sN4WseJk84MheD9FX8Fa/4xVeZCNAtn8jNj+UartB0e0khxnJKRspLWG +vpmimtFiqsihE4r1dnrITgbgqMh6A1BRwgaWB9YGsWyl0JwMgS7Q4B7LiUE xSGQQkBYTayzn9X5IAR9IWhMVRvyFZeLM4Y8xeVPxS4feVxccvnXN4ZOt88M RKPsRcOX5fo1Z+pxSxhJ7oqi6HDODL08NyYdeHM6GDTohP/4ZLpYpiJVKuIP TihVf7waOolxONQXMrlZA7+ty3/yydd+vO3ZCZGCqlD+lP733hvfjKE+t3nx jB+8euP8SNmYaxf+9e7FA73zi2mE0T34puDTLCfF4FAy+ougJQ80eU/ncbq8 E4N/UPINxhl/csAOx4MOrsYEi0w7TA+avmoSMkxgcuQVCcSNm2I9L2WeGHxR mWfzlmXS9+RCe9wC0e/Wc3q9WQCbIGj1fPoeYssOHJboG9SS2QRFvGl3kVJS 1MHl7XZoDYcxStGLekmP6DVOv5K7pgQqSiBSMnSCddGbvEh5WaZv89JjhsX1 EfXAQSbMkVtYrLcGcR63VCnJGh9OQ8my9x80rhODr7J3+MzF/mLu6QiECycU zi/kryx4poBjAEn33wgp6hu+uqCl1Bq45P3eiRe/3ytws9r31PiKNFOnjodr V21c9Ozmg90fP1u/pcIxxjBtWtZXv7Kw+4ZvbXl0Q+L/+HMspfC1RHxVY6yr obLjqb6DP/Rl5CdWPfAvS+ZOXlk/rePJ3ifO0RUig2/zb9L/AQ/zld9nmNxz cQu2ze2xu92eDCPmTKkN2BEPLHQvd3M6q83BNmLEmdyCHQEhuQl7mAi4Dcsw edw6TZ9tt43rtYGN/uBrsytme8SOWzGffdRWjNdqFC/uwl7zwTd98KAPbvdB sw+qfBDygeCDd3xw2geHR9CROPE0y49nmY8Y08uMD4k9jM/Oij5LVW70ATfH B4oPJB8QnxrdNYyK/S9jYaPellcDfVkN9ElFBQ3lilGBLn1NnurDUws893k4 GB3Yj47r4eeJp8YkA3nDT/4lZzFEx5UGEmezuHPJ0D3PmRgLty+zYOReMWfA hB7i08E3uQr0EDwZr1h5IHCS4+0cx6MntBENF6GHrxXjirdqiuStm9jJzzNX wlbgZhAAetiD0SFXkZi1C45r7vx0nuYJtv70WhP+2ZsN5vKPiU/P/iPlk9+r nJH6T5WDnyRm6BZrKZ9O/bsSrI4ukKgm1w/930sgoz9hbRQyNT8gdj6LzOAe x+edpEAgZDqmxyE9oo2SGzD9NQ6ZhbdJROgmLuSZjs95XJRo8all/FGSp5aP 1T5OClQeD7ZxA1552D4to22LujsxTUhEswAv7IN7fPATLOumf3WBiw5+ig8/ +T3cD3/ibuX1fBb/ivAd4YJwQfNv2jt1Ad139Hb9k4ZFhhfSDqZPzejL+ND0 hLnE/KxoFk9bt9gete+0/94x2/mMa5t7sXsbm3GYKLgahP3fEBGjkevQh18v /IaeRyDNBd4huRwfkhEQA+ZArSWQk2qaJ9nk+2paICbypprWECN5X01rkf6Z mtaRVjDQngQDNroSOtQ0ENz9qWmO6Lnzapon5dzHalogmfw4Na0hbn62mtYi vUVN68iL/GY1rSclQorHQCYJvWo6DfTCM2o6nZRpTqppI+nUpPrKME7Xpto0 kWbrV6val7X3tN/U0iw1N/U0SUs7Ojd0tS9r65Eek0qKi8dJU5e1NkmzO1Z3 9GzobJEqO7o6O7qaeto7VhdJU1eulBhvt9TV0t3Sta6luUia19bRtbq5aWXL 41J7t9Qk9XQ1NbesaupaIXW0fn5jUtPqZmlV0wZpSQu2tay9u6elC4fUvlpa 2tLV04TP5Wu72rub25dS7u6ioV6mdaxsHt3q2OEhSLR0dG5BS1c37W9cUXHx UMnYUXz/rQMnVaSdLMOrB6+bSAtpJhJeTZhvwtRS0kE6yQbSxbjakCqRx/Aq IcX4HYepqUhvZbyzkXc1Xj3I34ktSaQSc12Ypvcm1gPlKGK1VuJXGtFuN8u1 4LMFn+vYSCjnPCyl9VezUa0kLYEcpLYzftprD2u7GflX4bOLrEBaB47oHxkZ bXE1kwBtawM+lzBuOq5lrM8eNrqklNpZjaWMQqWVzC8na9msupGnHUtTbXfj bC6ZC5mG+ZWY+6Kxjr2cFJCWqvtFZQvY6LqH5jcOR0FX7tI6Yz+/vf+PJf6f H9EX1ahinDeyfpdh/hrkbGV9tvxdqSX1up3JKdUi7Wcpa5mmVmHpSiaDZmYH 1DJWqzPvwbZTslmF9x7W1lLWU7IOtdRV2GpyJktUPbiRWXYb06B2VpOO52p8 3ojPuawOXYGvkULW/lpm4dTmexj/MCa0stnReSxl69HCZN/MZtiJvdHVoxKn ttyDlMno8CLYC/0WYekydY6jZVqkjvsfqxVh9VZh75GLZNY1RGlgq0XT69XR Uf4MkoZSuAalMpNMx6sS152mr0EqXdfpeL+K0auRch3eqXZfiRKrxu9sRp2H NNoOvejqJ9f60rVN0dtYrhPH1sE4uhjvf8V28rHWbOy7YIQdtatYupZpHF1T 2scGrLF2aCxUeutG2NVaVUJdI8aZtLtVjD85Qjq2laq2r1ZbpyuU1IZVjNrD MLtO7a0Ny9cxvg4cR8piUxr9+RLrZj32oA40sdYlvNrVkXWpWkfp1NaT2t/K pLqKyXE2W5kOdTYdOMKWEXWHLeLSXppVxOliFrSWyaB5SIYdbOwpaaTkNCyR pUwOw/JKjqToslpyad/DSLGOWfVavKesuAnLutksLm17Pva8kvXbPWKdhyWf XJXRGJpEkyQqdTI5tqs49h9ZYYlRmlg6hYSpfqlfaFajCSqvpku8fOEQd9cI LR2W6RfLZ6WKSj1kJC4Ot7Ka5TqHSuisknLIx11oAVv/Duazupk+DttSCt+G x9aBvKuZxa5lK0FH0DY042SfI7U95cGStjscO6V08XLa9UVzHqk5M5l8Ll1d ugq0hzVIb2Gtp3xfsv/VqrdcfdFKdZGLY69U293Mj61lkUDSD69DvqS/uFTn P19HUu0l7bRFXYfmURaYau/S1U5KLDmDHoYLPSNsO7VWTRdJ+fJ2+UVIlZLv F6HvUibllPcdPabkjKgeTR7R2nz0GFMxP4mMJxMxspqIcdckfBZjnkZfEvvO JzV4H4/ffKQVIM9EUoqXhFcZamuUXcOt0mu6OvOLZzcSrVOegGpoE0O/Sy2w k2FGk1p7HdPAdhVf1qo42YIzllR6y9As6Sj+Ef+cKotcNPbRPpleV6lRx2q8 L2ESTuruWnZvUW08OcermR3dpJZ1q9rWpo64dcj30zrXMT2m81jLNGWtOoIu 1TNcz2bcrfqalv+Ruc4Zkncnw/xuhhN5bNxJLV81AqUuteom1dpWqp6nmfnB VAxAW1rLaifRayTetYyq9/n4kYz2qa5TjpVqjUKmNS1Ia1dpNw3V6Gbo0aPS krLqUu38f1KyTWzkqdijRY0LpYtkS33fv6s7kaRUl7JazSqKdKgxyruMv52N sHtE+bD3b2f1Noyo1axq11KGqcO11jLEKxxleS1MVqlV6GLeq3vIk0qqDrcw f3q9apuU9j8jyxYVdYYRsJlZaVJb2i/Slh6mLU2sXWko7kjFbe2svH1IPy+V RZMqj3Y226TER8ukYwRCJfdAeaqtJ3ugf9Ct479dNv/1Xcvf74ed/SXPWgPk +5f7c3fKv73+htOV+fIreNt4s9OnbDTboxtv9jSs71zft57/6c+Qvu5GvK3q xNvKDrytWO30mVcDWQEVq69Z3bCaX7G6t8vbs9buyFy2HG+RFihuVVq51nbM CK321lArf7r15dZ3Wj9qFeytcE1bQxvX0mb3+dsq2riOtn0tZ1v411veb+Eq Wna17Ws72Xa2TdPS1r/G6+l23lTpCWzAi+O+e0qQ40cF2fyk/0lOeVKni5r/ 6P9jwx/5o++efJfrfQ0ee8QsH8brYbyO4KU8MqYwSt+jflzKTT7TRfY87/LT p1L8ZY83qnzZaIo+sJOXv/IQJz+0h5fvwetLeN29h8h9e+Cae6Hi3qP3nrz3 7L0CrWR8y2CMvvVmmnzf/Tb/Cf7dZ7bxsvJeuom1/NfsnOTT6WY95J0ymqPm j5WPP/iY/9G0DP8LPyRy4w/h3X5OPtfPy7/D6+RTZ5/iKG/2MTqaYzp99Ogm jfyTacWBR/Ga82jjo9yZFzUyZUl70ZMZVV6EXXfRP+ahZN4ZzoveiUO/Y7tB 3r5TJ+/YKcg7+wW571ae8j9za1YguntafoAOaXe2RIf0zG6nN7q7l2PtTduv M0T79gM5AI0HYHNvmnxLryBvwqsXR/ZnvA4e4uU38bmtn8hb+7WysiV2RXRL v06+/TatfBs+aTNf7588OWru9/dH+o/2C76JDneZwzHBYR3vMJc6jCUOwziH ttjBRxykyJGbZ8rPM4+RTYWyOSdoCgXN2X6T5DebRYuR/mEirU5v5AWNkQBn 1PLNfoWYTFGFWG1Rwhvkl3gwm8HMm80V5gazYDCb/Tyn80FWhlvnzXCIrgyr YM8oLB9Tnl+eWx4qzymXyrPLfeXucke5tdxcbijXlvPlpHxOKcStNaRm3rS4 DfB53bR4qVxzgpfmxkvkmrhuzqLaYwB31SE1zm07AWReXNh2gsOHtXLhotoT 4KHF/b5nCQCJ1zT231l3jCPT4rAtHryulj6Ua2vj0rYTIplXe4yDaXV1dfGJ NXNqKVednBVvpn9oqy+rLl5CE7uz6khNfPK1cV9wmny5z+Luxd09PRcRj+UL 9I/vNcXzg1Uj6dA9mq+7ZzShey1eyVTySmYIY724E7m7u5syHLPRzpob4z8I VkFlra+OXrIcd8eLUHqUrWetvJbeurtHNJRs+piBSnXO3Gk1cf1cvOYsinuD mPkhZsowYwxO+7+UZti2DQplbmRzdHJlYW0NCmVuZG9iag0KDQoxMiAwIG9i ag0KMTI3NjUNCmVuZG9iag0KDQoxMyAwIG9iag0KPDwgL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yDQogICAvRm9udE5hbWUgL0JBQUFBQStUaG9ybmRhbGUtQm9s ZA0KICAgL0ZsYWdzIDQNCiAgIC9Gb250QkJveCBbIC0xNzYgLTMwNiAxMDgw IDEwMjUgXQ0KICAgL0l0YWxpY0FuZ2xlIDANCiAgIC9Bc2NlbnQgODkxDQog ICAvRGVzY2VudCAtMjE2DQogICAvQ2FwSGVpZ2h0IDEwMjUNCiAgIC9TdGVt ViA4MA0KICAgL0ZvbnRGaWxlMiAxMSAwIFINCj4+DQplbmRvYmoNCg0KMTQg MCBvYmoNCjw8IC9MZW5ndGggMzg5DQogICAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+Pg0Kc3RyZWFtDQp4nF2Sy27CMBBF95HyD162iyqxMYZKKBKFIrHoQ6X9 gJAMNFJxIhMW/H2Te92q6ibR8cx4fOzJVtv11je9yl5DW+2kV4fG10HO7SVU ovZybHyaaKPqpup/EL/qVHZpkg31u+u5l9PWH1q1WKSJUtnbkHDuw1XdLOt2 L7dYfAm1hMYf1c3Hasel3aXrvuQkvld5mhSFquUw7vlUds/lSVSG8rttPWQ0 /fVuKPyT8n7tRBkuaJ6tams5d2UlofRHSZNFnhdqsdkUaSK+/h+dOFbtD9Vn GcZsPWTnudXFCAYwmwAmBAuwBAOYAtwG4ABmDZgBpkybc+sZ4B4wWQKWrMkB D6whrNiHsGafKeCRwONsCKsRdE5AU00fBx9NH3cPoI91gOiDrXX0gYKmj8Md aPq4OSD6MEIf+wigj2Uf+jhGog8j9LHsE31wO5o+Fj6GPhamJvrg1IY+U5zA xPdhhD4mPvvP844TgKH9na/qEsIwWphtjNQ4TI2X3/nv2g518fMNoOvDaGVu ZHN0cmVhbQ0KZW5kb2JqDQoNCjE1IDAgb2JqDQo8PCAvVHlwZSAvRm9udA0K ICAgL1N1YnR5cGUgL1RydWVUeXBlDQogICAvQmFzZUZvbnQgL0JBQUFBQStU aG9ybmRhbGUtQm9sZA0KICAgL0ZpcnN0Q2hhciAwDQogICAvTGFzdENoYXIg MzYNCiAgIC9XaWR0aHMgWyA3NzcgNzIyIDM4OSAzMzMgNDQzIDUwMCAzMzMg NzIyDQogICAgIDc3NyAzMzMgMjUwIDYxMCA1NTYgNDQzIDU1NiAyNzcNCiAg ICAgNTU2IDUwMCAyNzcgNjEwIDU1NiA4MzMgNDQzIDU1Ng0KICAgICA3MjIg NzIyIDM4OSA1NTYgNTAwIDk0MyA1MDAgNjY2DQogICAgIDcyMiAzMzMgNTU2 IDUwMCAyNzcgXQ0KICAgL0ZvbnREZXNjcmlwdG9yIDEzIDAgUg0KICAgL1Rv VW5pY29kZSAxNCAwIFINCj4+DQplbmRvYmoNCg0KMTYgMCBvYmoNCjw8IC9M ZW5ndGggMTcgMCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KICAgL0xl bmd0aDEgNDAzMjgNCj4+DQpzdHJlYW0NCnic7L17fFTVuTe+nrX3nvtk9tzv t0wmyWQmmUkmCQkXs4UAEURCjJiAIYGGu0pQ1FqlBOWioBXlJqXVABFUWh01 tahtTU9TT21LpUe09e2xYkF6bM2RY5G3FTJ511p7ZjJcbE9/7++P3+/zOTNk z7o867LXWs+zvs+zLqy57Y7FSId6EYekr9yysOf4899+ACH0S4TA9JU71wSM jcVO4j6BkEqzpGfpLXd+/cB9CKk/QUg5uvTmu5fsSHx3DUJG4u9JL1u8sPvx nYN2hO4jflS7jARsS9+tROj+IuIvWnbLmq922j/xEn8TybP05lVfWei9IdKJ 0IYeEr/rloVf7Xlf9S6P0EYV8QduXXjL4uBLn32L+EsRsgg9q25f042KRhHa k6DxPbct7nFW/2UP8TcjxNeSMCBf+tERp4L6MccLCqVKrdHq9AUG0WgyW6w2 u8Ppcnu8Pn8gWBgqCheXlEbKorHyiniisipZXVM7rq5+/ISJk65qkK6ePKVx 6rTpTdeg/59+hIcR6T/h2rFn/od7Wg4Z/ePFz/QMlnYFcqZXyKEZvwH/2+h/ /XM1UGX++P/nLyF/HkfTkH502eiro39BZ9G1yDqqGx0Y/TMO42dJrDh6hlE1 8bSkGaMvow/Qr9GPURv6IboBvYq+g/rRk+gJNJ2EUffj6GXUQuh/hFrRVxDt 37tRJ4l9CG1HW1E3C7md/P2YfNeTb3nm+0fytzBXp9+j34MNpqEatOCy+s5h X0KBHkOTYD2p/UThQbQN7Sf5lqK1JM/bUVGOumH0x2S4/itejpagQnQPCZHI X2T0N+h98q1FE9E30Gk0hKrQz2AQzUDPkvS3ohdIyZ2kvtv/bxv3fz7/8/mf z/98/ufz//HPZLQv43qazFzZzyQym1Who2guGMCAFmW+E8j3a+y7G0XJhDK5 5ZqmqyZNnDC+vm5cbU11sqoyEa8oj0XLIqUlxeGiUGEw4Pd5PW6X02G3WS1m k1E0FOh1Wo1apVQIPIcBxcCRckxpm7oi5ZzSldKFGkNiIKW77syseAqZ3MGQ MZCMt5dnqFJCNIXMM1OW5rYXkFTXnlJELyW5LsWFxc+CJPEsd2Bqig+Tf6EZ C7tTpS1twZD4rjsX307SpFxT2oJBdwqHyb9rSBT5N2NhoDslNpPwoFsOuSaF mtvo35HRP9SRQFQXbCfPlraUL+ttb79SJV8h6GfwkmpeB1vEF3TOKY0pZHkB 6f6QQlZKdqYOpdDEVGmUVEQkLpYbiqfA8lkKzCmwziJVvrgImuxE3RXaYGr3 itDU7uWkRbu7xtr0jNyiwcCWwJaWNmOSOFmlZ6Z+NqftBa1mSmjKYk0uAL2g 0ZIQrRuRIEQy6XkBdFcBc2Dd1PEvYKTSkwY00QpPpX8rUtLWLuIINZKWIzHm sZgjo4MP5UchkizrMssuudSUYkpKKVcjsDwlLUyhrYEXYoNbHjoiokVdUV13 qHvhTW0pbiEheAFx4anLWlOemc3zSBApivx1LQvQDm9kD9p9ganLAluIn9J2 kWeokXb7ReHdyxZ30YECXaFGEqee0rY5OOhOmcjv1JQxmppOyKZ/7ZSbhLa3 O0jNtkwNkcwI7dQVk2mbx3P9wobbNd2s9aWtCwOp3kUr5MG18KHsAA9uEVO6 c0HS/KQDSEqWMNNS3V0raI1WLKRvMXVFYMvWxexNHmI1JwMyMHVFI/2jCcnw RjeQ1PPapi4LTR0rkLwXcXDhS9MGgylnlCbcsmUqreLCblJ7ucokYqz+dNC7 o0DqMyUltbIf1MqamJQoLWxszwRlCObRZDSmq7G9PSh3KyFNKcObhYpQYAvN URlOWaJicIjEDZbHZra0TW10s7dP4Sltk4Yd7mHintmcCwYHodkSH3bLbTTz +tDMOXInL8s+ulplDsW5jiWkGXqW61GH+yhxTwtN69qyZVooMG1L15aFR0Z7 F4UCYmjLCzrdlp6pXQHG2kDCX93qTk17qD0ldi2D8aST6XCa1jIzZZ4zn3bP tMCyhbI0aAgF69xBY3uWpvnLojOMRAY0GdYyI20RPyG10xGh4w5MoxLkCGF8 d0qso5xI6nJDGxnoX2GDkj0IA1xPsndTVuDaw1OXX59pIncwO2SoaJuTCSWZ BIOUSbYekdAi4kn1zmmT/QG0yP0ikuJR0ntdNGYwG2O9gcb0ZmNyybtCpLcc M6//B6M6f0RvMYZMgfo46wEmUbtTg63kHf9al1LVZTrcPKWNc+OMC7s56tJE iYSamLJHWULaJkQQbhFDgWOhlBhNCVPaBt0T2wOikUgwyA2HTI6QklxUaB4L vQlUVCKLmIKJKbDRKEREJ5PgnL2ORObSBqZu6cqMtfxXzMj77mVXfk9CI4bI q7pleqMpRN/2l0x+ZQRzeBrlLHdQppjRniqg4jdV8Al7kPdzT2kLEFFDeHcO cwSmBpbRjk8FuhqZUGh35wcfGT3R1UhlHKkyJXFnBjl5tv/jUp1ysY7/Phv0 EjZY/1D7svGXNvPM1pyrpW2t+2vt5Qhh8BAtvl5BFH+kRJbvKzCP6F/86PGj 7FGZCBqDxjB5gIf3XvgK571wUoG+QL0CoraVJqLFf5NaEfBKaRSJdrA7BNOj Dk6jP6iDfmTrt0tIC9o+hUEHSk7XZzTaFeirExTrjJLLbVzXnTC4IT3qhg/c 8LobHnHDOjd0umG2G0jEGTe85YYnWXgPC/Sz8E8ZPYlKsdheliTOYpEbfvUp y+t5N6xyQ7MbGlgcSUaKOcai+lgxs1lUgIW/xcKfZOFdLCrBknz7U5bmeRax imUksgSfZtOQvLZlkkk/pBmSVCcufhm5FBK+Un6hvste6Eze2zzCCiLJJFYJ +Z0+YLHyiyZYyIRRVo6c7JFsoyVYXieygT3ZBAGW5gzLaDDbaD3ZtpHL6Mh9 Vmc/t2U+Cy4JvywmP+7SmI4vTXOlqCi4HOKs4SiQ56nOBR3iqQ6XOCwOo/jI YMPIoPh+x2BlAkLVxaGQ0WKzJa3Bmqra2hpjqFBhDRmD/DerFy/+hem6rpHX u2Ybf75kcZJv4T7a/MAFsXt2YTxeOLubO/PAZlhKx66TDPozwsOoBKxS3HXI /awXaXf7fEb1zoBYgg2mQxIyogNFIKl0tbBf2FgkRYqWYfdk4wGrSPCQ1KVS 1Yr7fbqNVqnUuhj3ReBEBAYjIEYARaCeeLZFoCcCXRFojoAUgUQEAhHws2gS 1ZuNJVHHWMpUBPrywvMb6bbbLmq+1XI7jQyeYi119lTGL3tPofiga2RwcLBh 2FQfH274fLgyQdGQpMVBKOJUPpenNnhk9H+9pBTlX4+/tpD8vkj8ECUfIC1P kABp2hojaepCJWlruamZP1QTThprk1U2Kw3nzqTbmpNtnYu6q+ak29oi4WQ9 iOHHHlm/LtIWTy6FnV/vaRl5a2kyHq9bxL09sSzaNfLclqceTY9fVIcwahr9 kJvH/ZQ0tQOdlay63Q4Htu6WVKJkBGQ8YcR2zkha+yWHs5b+Sm1KXa3R8Dg2 I9P9Wkkreby1Lu1ybBBAFBy6TYLkFJbgQRekXNDngm0u6HVBjwu6XNDsAuSC q8iP5IKECwIuEF1whtERomwjjw3PTJv+lDRGNDMu30ANI29Eo4gEdTgaXLNY +2YaN+pSblFijaXMQibFKLeV467V3KTBGo1LU6bhdHaYpp+rX6LneD0Y5EJo D7eHcagQ11SbaHMGSXNWjeNokyuU3LzHPj18+vQL+389snP/tsO3f+crN8xf aziZToPz7ffB/ZfBV/+8F1o2PvHtTUSOIwuR4y8KK4jLj6cQWWwUQcQmM5g5 8NeJAOs53sJR4zeYAZnv8/ktPp+fxI3zmUWed+NHycRsMrlICK/SOtwH1a4I X89jkV+neUTzpOZ1DR/QgKZPnVIPqjm1OgjtfpjrW+Lb5OOKfGD2GZxxZ4Nz tpNXOiWXK8D5AUEAsJGDQCAIk02Js0E4FYTjQRgKwkAQ+oOwIwgbgrAmCN1B aA1CYxCqyfAMgiUIfBD+Wfr6/ATS/EuS5NPzjGowCDgVhL4gbAtCbxB6gtBM EgYhEQRSYzEIJxjRJQSzg3Cp9Fq9ujOfQS+RcZfJTvaJQh0ZQ8Zk0lTviLuO LuiorydURjKcOo52UA9h4VmMhSlJvGPYZK+Pbi6ocMyKqtaKQ5tVFY5oAXFE KxOiUpg4UVROnMhGYU3SB3eJcBd/iMevoI8RLuZqubncEo6f4IeIf7kf91sH rPgZ/St6rAUyKSMAvUAHNPk3Ngm0A8cB+LCdcD2Rr9UlJUGFwmqxyf5xwD36 x0+gFo4Wx2+cOvKnaxuK54x80uWePD8997obEvAfWMShkfe5eedf6Zh7FReP c2Xxqpbv/q85pqJiRTyuurGHv5lI4OtGT+IPCO/H4SFJa5TU6lqjUYxECZ+f kZ7QaGojAfrYZjZazGaj0axzRiOoyBD0B7GWC0oB0SNpTbUeT9Fup4hUoiqg 6lH1qk6oFBpOpZAEyeyoFZDCrNuNzEazwRaNlJf4C/uDksnWFDSUS4ZyCHCV 5cuxWtEvKW0lUqistkSyOmtLbBKygZZL2Jbg3kroqYSuSmiuhEAlPF8JnZUw uxKyXcpEJRENR6NU8h53kT7LBR2PEh/p0nr6hxqGG0h3IRpB4htmDdfHo4jI EOrLEpEOnkXE72bV2iFHNCNWYoYIeAStxeWtfdP+nv1jO/emFr5iPmDGXcYe I1ZEgfzTc4YoWBTaI6O/ldQGU22olDwiR0b/8JJBpL+fSGqttjZepRZrHUdG f/Ui+UVM0MuynvxbLUs8KviFwhIq80PGJJlgicivLi6pIBKKCHw7FU9JY4jK JzoYbDarRQF9nTf7bQ5tPG771upru2Y8Nr9n9vMbGjr8Kp8+Hq98/bqbp2/7 +ernvH5NCVStua91avW8qyNTbrv+rh1eTUn64/fmSKUzJt+0rWXTXjorW8iY mMA/i2yo/yWFuFtFx0JUpdMbnreBzbITmw0GowGBEglaUaszbpQMSr8SKwUk iAJWcwKdI6xWRxMBohsLEk86iHYODQ6IO2iX3UZemLyhQ3yjg/TUsaN14hBp /Po4leodDUd/WjcymGl1n9ni8dXypZ4weSgttcRbVMuVekrIg3jpLEkbsD2s CBUWE/hBmSJpTFopKiFthCfcu7btxnUtGzRT33orGr128qqH7roLPzrR1Dcv nZ42cv/UxvHkXd1EcL9Ixr8f9UhqBRQD1up3I6IwSONUegKtzRgpoYBTah/H oueQ91mfaLQcMqv5oOkAKthol7zPmQ/YA/bFuDMIfia7iBjKAAKXSMCBePxN Bpw+H24YGZLHWTxK5ivC6aQ3Sd+F5K6+fHqH6269Y32dr7Q44J04feqqdElb JETm9YIwF/3mqpKacGDeyKnFNXRKx5oJ0ehCMu9MGz3JvUreRovsUErmAC24 lGAVwAqAbaAXwcCZbPqCWvKC/ymplepa024Jibojo3+SzCRYYSJBut2SwmzQ GE211iOj5yQ1cRg0BQWyr5c4DPdzkpNbjq33qyWHegkOOAmQgxNOaHZCwgmi E84w7zEnDDoh5YQ+J2xzQq8TepzQ5QTJCXKSCU+yoGYWlGChIovIT9/HUsrJ yPPvQdmMQKDtn0Gw8g8dKAwpjP1WJhh+YMIWqkxWSwYBmCmvYcZaJox/+pe/ vP3K58Nnlt65e8uyu/ZwP01/dPSP6WHw/PJDcF7o/pfn3wD/T1/8cfoPWSz7 EWn7EjBmsKz4T2HZ7ouxbH8ETkVgKAKWCPAEyxLPjgisiUB3BFoj0BiB6ggU RcDNoglsxf8snu38fwfRfm8MyxJ2zWLai7DsP8Cx1jEc+1F6cVukrbNzacU1 6e62SFE1xbE7Hl6/rqKJjHOKY1tHfr2kemzQP/QQhbFLqjM9oAiSHriKr5Pm H6sDrha4SnNlqJKzc7FD5c/GSYdUL6m+s3pTNefdnagm31CVW72zapx4FTZa gkWHwByq1voKSB/pm2gfoQMTUKFYiFVc4f64b2OJVP5c6EAJ7a3RxSpVvb2k YMLiCRJ1IpNoImSm/QUbJTNNbt5vb5DsG7sTd0owTYKIBBYJFBL89ZQE/ybB kAQDEuyXYIcE90mwRoJFErQy0mIJbIz0MwkI8XFG/KIE/RLskoBkt0SCuRLU SlDEKHkJzkpwWoJ3GeXLjGwDo2yXoFGCapaniVH+7Fw2R1L8QVb8Jgluk6Bb gmYJJjPqoiw1If4Do3+DFb+D5cvqKo1CC8s8Vw0Fq0Z+hfdfnP3cbN5ynR8/ l1fpgezryfWem81arjfOvuHx7BvuyKPMr8G5bA3eyGZImpW+GMkuwegsrPBl Z7KEA+yFpGzd5Mb8nQSDEqRYHhuybdOYpREpmXQnJTzGKnRYgm2McKUEEyQI ZEupk4vok6CLda5ciiXbUEPsPXpZBXKxbpbyFKsATrHoHlY8KdUggSoj7zr/ vi3gUrh7KSru/LtEVwbQl8Dnv0/992gXZFQ7KlSirpFTTLnLnzOZ0YGIHQba 4oODVOoQuTMoQ7l4XBzuEMcE0CuobvTES0qiDROg8pJSX1tPp28vwVcJnVpf i+rEOtyT7E0eS3IoKSYDSU5JKAdftHuaohR0MQjWTmFXR0e+oJJFkvUfii57 bU5+KYLpRW2ReYtWL9HEZ8jOxctklVwWZTsfOzzxmpdmrH0wcQ2TZ19b01Jb kx4va+bUS8Sb7MmKt22N1+7bKUs4jBrIQyQaphF50TPSascfTEhzSPss0oFS JxrxIUAHCjYKWjggWD+UDG6/G/s5t+DzCxtLExY/8H6iovlhmx9wjx+6/NDs B8kPg35I+aGPeQN+EIne6IczLISQ5lNe3Lm0LztZdzLgTSH3rGHx7JA4copB ngUdBPSQTgpebLWgcr7KxpBPMYG0WEzH50+Qm2fyDcMVklRRcfXV8fFdcguM 8N21wgQWVlEhUXtnxlrhQUPSEvLmap1xt0I87HrNhSOuetceF+c6hJyis8fZ 6+Sd9seR+RbDWgPmDGoa2ufktILT5bNs4iQvtwQjH1wl+SDhg4APRB+c8cEx H/T5oNcHJPx5H3T6IM8AlDOPib+vIi/87pudHUStON4x3NHRMEyQbAa7+lus i6x4vnmlGXdjeA/DXNvLNnyPADfDvfAJcLQlEVPyhJzlgTVISQbXEwBrVyjg vcOnP/7Jptfi4ViJtfjOVZv3PXr49tD13/eD8+0PwNl7Y2mytuGOf9v2+qd7 w4/cjjIIcCNpnRCKoX+XbiraJQh65czi+cW4OBq+RteuwzpleLdepddHRYPN byNqnE3c7SbKGzoUCj7BRZ9QmvVFwkYJ+Sv8yzA2g4k3OxylGzVSuYboYhXQ WQFSBRBHxxjSqo+/SZmYjIIhqn4NkiY5Nvz+cB1pkgzkrSOggTqYJ8e4Xsq4 BU1OqmHonN6mqHqCGv/NAx7KwSYSQ3sUqxJ6sUkV8AaaCKN2RDvQaob6SXPV ZMZQWDbXsKDqDDeSFgwbFXJbchtL7xx361efWfi198F//Q11s7W6WPG1z393 566JhbH028c2zbh65U01jbt2bVy5dqD55dvHV05MzGtae999ade6YCtMmtR7 w6x2MvYaCcy4IDxM+C8l3U05T4dyXCdRtjOZKasdN8OQGQbM0G+GHWbYYIY1 Zug2Q5EZLGbgzYQLGcU2M2FEM3SZodkMkhkGzZAyQx/zitRGBGeYl9Dlk13E hRkmvEj+yrJ0yJVlxM+vyIRwYcxUWDUnZxk8P3FpkqKpa0c/FL5DZE0J3CrZ C/0HDYF4oCEwO8AruUDAYSyQ9LyGIqFtelOtxrhdwTu2I/PXDGD4rq5fX+zv Iy2HisViMsCKI5a1nIQ4MAil3M34zggsicC0CBRH4FwE/i0CFKgORKCfQdwN zFabw7cU+5K/s1k4PMCIctEiAb4n8lBvIINxO8fmnryWycyaWfMA5WLi+uXI afH4yEeUkcmAlS0CdJiSqFk5bbS12AabKBOHzaAKGExNH/PwGg9D9uP2U3Zu jX2Hvd/O3Wa7z/aijSuyVdu6bads/BrTBtOAiSs21ZrwqyKsETYI+FoB1gDs ApgJkGfx71hN5EF0dcfqdiGAjCIK5jR9HCxERouJ+mqqi4tDNUErERFGBT6b fiv9IOyBqlufavGUacsjC9Lf+ff0f2z6rwefus903ULsnt/wiR8ehjooh91F 5nHpxdCSHki/PZQ++XjzZ8waf9Vd6V/cg5gN+CT3BRnZLhRG70mL3Ls5PSf4 dmtF0yHzsxZEROqzYC7aKZhNB/Scm4iHA7YS2zIc3KCSkAq0HHkUCMUqIlBL YHpzCUglkCiBQAkQ/2AJ9LIQ2dHFwjMjOLfmIJtA8lYeXCNVVadol3zO/g3T mT9n5zWE/WEcCwAqDBRuK+wrTBUKep0aDHXqJjV+WnFE8TMFZ1D4FVjk2Ly+ oIM+28PKUImCaXqIzNs1ecyQDBtzkpf7Ih2y7Nyy74eAj8xfFk6OB3NhuLo+ /Yv5K9Y9/I2vdzQt3LQFxB++Cw3es4xjrp0QnYAfveq91w7/Ics5BYRzvGj/ QI5NKiibmAibeETPQbfzMWSuI7yi64/rgdN7/NYMhyh8hEPoTJs/Rt/t7Bj5 KZtnmEiVR2imKRK77Yfs37dzD6geV2HebrE32lvt3Ww4DthVat7casaae4zA GQQwAGgFBnQ6WYsgOv9cMtrIAMsMt8A4O8bvp0+kH4EHoXzVkYm6iKY8UvKb vt+m/7bh04dB9UPfz/zwKFRDgrBkARleT303/XL616+mzz30A1/6z7IliTvH PY2C6L+kDdbdnGi2NXEikeYcVyC49IfcBYYgGVnYbCYjy+AGlXs/Z90oBQ94 EGkmbOVCnmVYf8CwUS0hNRllherFuC8EJ0IwGAIxBCgE9cQjhSARggDzp0LQ E4IuFkjchLo3G0II8q0EeWpvtqlPMydxnSaj79SCjszwk4FnPBrNjj+3MqDU NxWZqk2NJu5XCpipmK9YqeAUNBSiJHcUzY61YipzKdPKVqk8T5I790XYtvOh 9etsySmQuLGzayl1xMmAa2R6LfyqcaJYObKfKL14HHOWTywjrapKN3H/SVq1 jPtP6cZgMGC12iyFlmDA0RIsDGwmQILaBAtNLYUP0AUHjrcFgoWcYPWUliHe echlsJiCvNVk6inoLdhWwBWo3Et50GpJGp4jlGoXikCE6bg6Q1MESQbkR1jN xdAKPJsuU/a5iaLrdklR11J8dwyWx6A9BjNjUB+DSAycMdDG4K/nY/DnGLwZ g2disCcGW2MwlxHJFOoY/I0RvBKDwzF4MAYko5UxmB+DWTGYFINoDNwxOBeD 0zF4l2WyNwYPx+CebHk2VszPSDHDrJhcRrnq5Mp4Lwa/yBLcmUcwgRXjZMW8 m1dRuQySXBp9XM7hd6yIgRgcjMEulsk1MaiNQVEMLDFQ5OVAYjfEYE0MlrAX xjH4LAanYnA8Bm/E4GVWQxLbFYPmGEyOQVVeJsvkXP4lBi/GoD8Gj+Xl1RqD aYy6MAamGPAxOJttm6FszWT622KwKAYtMWiMQXUMillTyfS5egxcnP8l9HJt 6khtpJuP59VnRzb//PoUsfrQLYhnYnAiBseyFdqRzb2bvauc+1lGgAdjkIrB thj0xqAnBrNjYIjlNNtLVNvVDN38M+s6/03F9MpEX5LTlynWV8qCYWK6pNAx tjLRYbLXx1ejhqMdRH2ly0kNs4bt9UY7XW6IRsUhuqwUVRGHqFRNVE3MiBnN g8o9SryJ38VjIMK6HQjGhQIsY155KaB2HBQXl1BIYLXYzWa6TkTlC/efpY3F 6RerZz18y7ipdWXBaLE7Nq0j/XZJYw303+L+9b5pxqm1MI27e1z7hS/WPr+q Jh5NWsyNH+Ffd9Yq4/HxsYaRUbhr/ySTpzCOOFSTvpZ7h2gVEVSNrsaDksMs EfXaRB/aGtAbwcRNSNj8tSUUt1+v1DUNeY97sTeg1DYJG001ErKHOV/Z7tml 8HopdJUCKu0pxcpSX2hXQEISRLmApLTUBibHd/vE8bslndtg8VuwkqsxTbLw CqwupOKoWK2pLVQjKAgFkJ13xTaGJQoD4mHOwoUlEhmetEktqdnqg8Fei9Si mogt9ZRxmwwuvMkiWWjM5xZfraVqI+8CjWvywBTomwI7pkDvFFgzBbqnQOsU aJwC1VOgaApYpgA/BU5MgeNTYHAKEOJ+RrzhYmKZEk2Bs1PgFCMeupi4+7I8 6/NJ+7NE+WXzlxHkipQYTWAKYJEVe4bV8RirY4q90Db2Qj1ToItMK4z0Ygbo vPIA/u+bcMR3F3QQGJJRhI8Pi2905vTiobHZlIz5BR1vRCG7tEbCZft7w8hH bP0+k54aYVZTasIZZIaFaIe8JEZ+ZDVxIlEPNQQ1rKmDxiQk6SCzGC1N7nKY WQ7lAeIspkPNTSOMxHG/Erhvm0Dv8XqwlmdZoU5qYyJzPcm1HRjOC1Kdm5eZ aZz8oE/KWEFrSNbHx1XVVGdwISeDQ8ZghbC1+domKPhqb/q3f3rh/evWLph4 6+o75h7oeXge8AOVg08b3M/1zL1h3q3j73rgtr1vtT//JkxqKnMV3rr40Q/u 7q5YNKdB8s1pK3xi6dwn5k1ua7p14/emffTVfQ+suf2R9Kr2m2YserRjfBVF 5Yr0DO4Is3WUgCiVksn7WY9YshshVXgnFguMh0S3f7fKXLhBkAyCX8B6ISIs xwV0oI+32GsLkFe7UXIdMB6wlFoWY4ktBNCNMYnsRpnerN6UczdEINf5dETI i1mnGRx/IzrWuUxZqrp0d0sjH7QEcWtwQ/BskNOFPCH8UOhCCLeHloewQmFT 4LmKTYo3FO8qzimEXfxB/mWe43kLjxUOp6dpJ/cU9z2O446M/odkcHmbqrlG DvOEu4kkoOWSzotSo8lq+m91O10/M1ktKFRYYr18b0yuq5QwYfcD+36YThMs X7kqPZGovNX1BNHLYH7eSq7+ofSZH76b/rH3P1dWxON1C7kfE1C/8MKBSe+9 +p0/tJJeWMTN5SIEzxOYjF+Vqt02TUp40RhEL0kib5SUplpEH9yA/gWkVYJS qTQ6XrAM7PD1+wZ83HHfKR/2yXDK2KT1uX1Y7dOGYORUCI6HYCgEe0OwIQTV DNDyITgbgl+E4LUQ9OdBVxJbFAJLCP7MUt0Tgu4QtIagMQTuEJDsjpJkco6H Q7CN5biGEU1guNfCsib5DoRgK0u/kiFkOd/zLO0OVpicr5vRf/vP2Tr2Z8us ZqXl6rj34pJydfxdCN5i+Luf5Uto5oek741Vd8X5bHUH8pK78xrgMEvYnVdF OdshlmQHe4H8BhgvVzRbGMy8uELyq/dnX11Oqc2+utxsvXlViYbAHwJDCHDn lUTi3wMG/wA0fCnk+Ad4ZCwqToQtEZjDVVXElRzJLWvW158lfxlO1KGAGMDI IBqwUqASkEg9IsHsY4bXccKlAVyktbtlyeRxk2/aviHd3No9Z+mUWuoWapzL xs0oMM+Nj9swZ/XTxVlvopZ5qc7bAmtxG3YTrPCM9NV7MGAtuGE+rAReB0jg AfSQEKBIAIsAvABnBTglwHEBBgToF2CDAGsEaBRghwC9AuAeAboEaBZAEmiy gEDygPozAgwKcEKAY8yREqCPkfcwunVC/uLwFcAkbTzSYOKvEHke7SATTbAm iNtGvsAKWPsE4fPk6CfCEuFaVIQqIC7VCBy3PuCzBAK+inCMtmYiwOmFQCGH fXZhe1iy6cLbnQnbwdh2O4cOFhUexGaNnloyZ7r9TfqDurYAXBMARQAIukHN JP+nfb/14R0+uNMHgk8ZWetOIK2oJcJN21ehXGeU7Lp9xrhxJRYTcCwBPQmQ EpkdE9ScN5hbGvl3agshEUMdVVXkB8VHooMNI+8SeTzMNrfMGjbW069set0s VETXikNZAf1aGZQFbM6msgDR7lpLu0vXlA6UnioVlnhf9mLeZXHtcPW7BlzH XQrlL6MXoniaH+x+UPGg451w1glcwglAmnU1a2FEn2RebQ9SswoXyq2Q1GbV XmbYVproNpZxkJPJwpLF9/b+9uSumQ+NPL3wOhO1ViU///zF+3/99W01htIL 112VeuvlLVUzLYDg1vSzG5vlfaON1GaVSt37dlH6V/u/xuO79u984EnxYgmN VksFQSN6SXzR5hZSkoZnWxepkKYy2J8V1AYqqC0DvheURoPD78AOWdR2dMQ7 koSlLmKskYsZyxDwB7DB4B9jLLY7qzhjeSZvG740AJtaF7dkmIkwVs7NbXUt rbvGYCKMdf+c2whjXewlfFUy+rHwHBmTheg5qUjhsrmw0u1yr1coLQqF0q1U uFDAQUBAk+Ng0MUpzDrDkdG/StM8/ibDwQK2TUvJBfuKFK2KbgWHFGAUFO5e qXCfUCTcinV9LmWvWXJ+t2CfOWReiVERNEhFECiCE0XQV0SXPW5b0DG2MFd1 OmeZo+9Nx6I89hoGyZOtzW2uiG5eOwSUuQqJdDGG4KItwvKQgMyv8FzXbGPi wjdM13WlS8gocNy4AG7mODIY4D3BSzr8/D5+04WduW3DjdffUB6/UID/k4bQ 9f7RD5V3k7ap4H4hjfb6IO4D32wvGLzrvG95P/XyXp/X6bA7WhxO+31qlUVt t6pVJcWOluL7BN4iFBcJvFKpdjjsToWzKOxoCa9XOC2KcInCabM6WmwO63qt xqLVagQtaHhQqp1O5x7nm07eJCjUSAN2TqPVqJQKnl1dQC8sMBhiKIF6MBJF URI5LScapLjhFmwjcJQobiajxx9DtrBSodYUHCz3GjiNuT0BMxMEj0E0Ac4E KBLwt9MJeDkBdyZgSQJaE9CYgFoWp03AuQScSsC7CXglAc8kYE8C5iZgGiOQ RosTYGM5DCSgPwG7ErAom0F1AkisKQE4AW+eTQAp4ngChhgpyeRBlg+pxBss 2SaWYTEr9G8J+DgB75FkjOzuBKxMwPwEXMPoI9mK7fkby5TU7GA2iztZzXKV OscI3mDv1p+l6WYFywSkmN8xAjmHJXnvVswIlp/LlkHe/r4EUAHZzRqEvMvh hLQK9iZgayIT3MqkJ3nxogRY8l63n9E0s1icSAAiL3ImAW8l4PUEbEuAyIKI +B1MQIplRkJO5IXMTkA8Af7EFbaGL7jyuvptGQvGl9gQvlQB+3I0cUW9LBOP GhqIFmWkqldnRyJni2Brc0TFctJVjWQ8yQzimc2s0exm1pz9IedlDkoAxmTS Ee9YHe/oqGRicKqlCDY4IOGQHM0Oblx4eviuMNdaBLYicBa+V4ipVR77XdDg mO3odHB2611WnDKDXQ2/UUOpGhaTfwIwJJ97LwruqZGDMEuIfTOrHQSlQNJc gTNLHxa7OWnOGDqUd0+aURhI31OSPsqn346kFxRffQN8vtFPcMaH0yKzZ2BT V2XNF/wXlTNnwi7BO356x/n9XMuF5/jNtzTF43P9cy+cw7cOLpwWjydi1dtH rsM/eDg6roxKl1XpZ2Ej+hGZU2ZLGjqfaFKSYGaziD0ziyglpDSalC9UJY6Z oMsE1OJjTLI9U8MZTHY2oxm9PDZhtJsvnR5WXb+4ZcmUminzt9+f/iAzBSRq 72/JYCtx9KTwMvc0KsHCK8hFyt+s0ja5XH4D2+39iPMDp6B0Oq2CoLBYzFbe GgiaWgL+4AOYs2DM+QPEt5knqm4gyFvNFlOL2WR5gNAKFpugMJuI32LarFJa VCqlit3MEgz46TljvbLA4XKHS5BSe0hnUNpqrdOsd1o3WXdZhXGq6ZT0yOgR 6WnTNbxiN5lNVUorjwUdW/MrzlmNI2gFRnpQcXqdVKpbiuWta/LCnbysN8B2 qMkLf2tYbIIRyKuB8m43qrPKK4CtTFvF8jkO+ZhH72XnO45F4PW8fW+dY8uC l66aZrjmYm7KY5qM/a6DcQ7hm2iyg9ow8q13qnw2GWOciw16ZFg44nSzeTy7 p7i8KEDXg/cKhwVMYHFxYFoAR8xQ64e7LbBYAdOFG4Wlwm7hkCDYBMhjEArk CX9wjD3GLH8Z7qBuExledHp9eW4y/V70ZPpsOH0yWD0V1s01D/2k0jthInzv buu/fC/QBQHuLsXGC/8bt4w8hz+7sUFXWSl5ykc+hoGNDaWVldcax6d1cGqO r66SYKzu9AzFhwRj1aCpME/abpla+1GwiCCM2qkWwTZxt7dkl2HyTpvXxpWf UvNdNVCTPMV5FAlbojixKcHvKYNNOliu2KPAQYIxilDDRidyFnGKslMGuodj ekJhmA6j0+HEdDg2HQanQ2o69E2HM9kQcTqg6SCRIGk69EyHrizFtungnw4k sSrblxf36m3xo8xeRe1Lw3HSibKUHB7qyKwpHhuO08gEbCYAe1CWbtJA5dlK /H4cvsnDFjtwFfAnFfykCsSqrqreKs4Q88dmxzpjq2ICdXbGRmO8anZpZyk2 ePyeuIfTUFOUx2RtataAUwV7VM+o8GwVHNS+rMXneUB8Zul3NdHkOuSd36sz +0EUfEhekmNPppmNk02+pqJklX1ckqNqW7IK1WRpggEybkoq6BZWZqIyjVNs XJ9+7KfpTWk99sJ2qIOd6R+em3JD5Gcvtd9+GIwP33TDggnfGK9t6gNNenv6 D+kH00H4HrTD1nS6TbDpS5O+R89OuLrtfwsbtz8Bn8Pd8CgOpr+ePp4+l77l 6viEDelfP7jiW3DNzysq0s43rraPg3nvgw06Rv6LED2dvhrc3HQx5gyZ0r1P dlwPFWYqxR4d/RBWEXmqRR6pAKUUZu55taTTq5/vTmRMh4huFgrnbQ0CxHb9 XH31j/L2/7gR4nXCw0RH+5HUWVYWJWJLHVF7PaYWzwPqiEWtjqiUphaVWrk5 WmaJRst2qPvV2KYuVteqOcch57Mu5PFGyqJKlVplKAwfKjLoKwDz4iGDMxqJ 1kfbo/zeyOEIbi6CUBEV9m61rqloNnTCOngSngcBVMpoWcTjLVKp2WTwgsHU RGAfk3H7PeqNBFAbDpjj5sU4xRCFjDUI1AgwLHEmD0v0MYJeBjO6GGWC0cjh PSxEBiR1Z7IoJHVZGimbTM46P6NcSbnsSF65hZYvNTtcAV+MbSkZPE110Hei RPwd7YhHjzINlIjDhuEqwkUNnw8zXCFLQ/4iVCFLvoEnFc8rMGQPt1WXcMor mO+KMvO7laIBJdhsdl6XnhsL+D9tibSl52W3woNxZkUdPBytr1g0COpbJo+L Gx32MpjY+LNFdfJht0kl5V0XOj+b4fPY43G9r/359P5vRDAZR0mEFB8T7SEC V0ub1F5Vnc/rvY9Og16PSunxeterNRa116fWkLhxTytBo/RypoDroM/DqQxq vzqu5sjAw4a7TGA6iIwG8AOGfT7lurAf7QtTHQCrOLHPo+m1SW7jPiIZveGV k1RqrzdQFvVOLk2ciMKxKAxGIRWFvig0RDNSPgp1BGyNKf1VTOk/O0hd9EzS yOrBwUEymbANkaTJO6J01pkVFbKHkgT5UBITZNcv9cAmzy7PG553PXy1p9HT 6lnjGfAIdH094OEmqGeq71FvVe9Vv6ZWONVgIK+FubgXtN4J3pnee7xbvXu9 r3mVSqJk+poMmtkarOep6T5Kd89n0a7claT34DJ9j6p7wHrRymIUH7NjoSN/ Dab1Wb2vcS2sh7fhNNzbRU0BXUzZW35+O78qT/mb1nt9/Pz7fIh6LvyABFP7 OOlD4R7Sh1YUQJ9IzdaDtoDDtx1xS3WgO+jYrl2igPfcoCEaM/6mGzj3WoWk VbjpUr1aUahYhW3rRAlp94lBkWi/hUT7LYRAIZwohL5C6ClkJ4xyGjDpiuEx 83cnBa5k3A+vbhg21tdn7d/XtahgoxI2cTCfg7kumOsh6qjfO5uopHwB5y1T m2sNTj9BbeucxO+k/qdUsFx1t2qPiivmN/EHeS7MwUcc3M3t4TDDx5l1RHlJ JAMBzMEq3kaPLfChPNUaiPCXJw1lEqN/hcLTd7+QHjgxslM2scD6lQvOQST9 zoWVc4Vrq15Kf9T3Rvqnh3OmlfPTXXADKEELc5y0dZ8jEnsrl6KnSdBz0t26 lMmsSCGDgXtesqodTiq5jzthyAkDTuh3wgYnrHFCd/Y0R5ETLE7gnQS5MaLe bHSrExrZ6Y5cyoATcO7kh3xaRD4qIh8NyYmrznyJdJGyFAVx0OWYNTLIliUq E5A3i5jzZxRvZn9pReaXS11dHpeurii/eqQgN8nQlZfRk9wRMstYkB+UUo/x kOlZC/h3oz6UQliDNEjl3YlFndm+W2V2ZZdfCoSgsBxrtDpk3SiZDuiQDrRc QLcYS+z0IgpC/ba8Y42p7LHGLnZwaDDrDgQhTwrfllmFkTemnHIRnq+vv3gd RgYy8fxN0ZLlcydo3W43Pu+G5W6gay6Yp9ZJI5mv2JrLsB28vnIf5o6M/vYl p6eJ/koaGju25BKNria4JMqQSnbBheCMEmXoSxdaRn54/91Nhdk1lvVbx9ZY fpd+ozLKv0S3TH3xu0nv/Iitrozenr4WHqW3GqIw/FgaDfzBhWyH7M8iBxCh I6oBqaFAXbCbc6ONCvsBo/dDyRCCUaIdGg1GELniEuPG0oS7BLQlkD5VAsdL YGsJ3FMCK0ugqAR+VwKHS+B8CbzGHDsY3a9IXDRLNL8EZpbAL7IUe0ugm8XK WT5Bkv6Z5TrEMp7JIuRkjSVQnc17A6O+RaYmRBPy8tibrZJcVDWj+V22wHsY zYS+EsB0l1xFD9sh18w2yR1je+ZSeXvpiDtHYCgZw7w5xui8eBLPZ5YrMU++ tTzPjpEZbsc7VtMt3aeG6DA7SnBqbk93Zo0BRMBmjg8YTLVsRbc9nOU0otqy /Qm5KT1/zzfc/eSTN64u9ftCzorK8hp58/fcDEvaPzp9w1VFicKKloULuPvp HnB4Kg//XYcQt5pwZhF+RSqMa1Zp6Olo/lPNqAZrDLt5sBXulijgVHLI4PJ6 6ZAf9ZTUeg95THt0z+iwTlRKSiwpe5R9Sk4ZtLjN9o1BKWTwgOcACjYHe4Pb gn3BY8ETQQUKpoJkEg8XBzdWJaLFwBfD+bPFcKoYjhfD3mJYUwytxdDIIuTw HcXQy8K7WVRRNmqoGDZkw0lG7mJAxfCL/Lzk6Py8BvLStGbDL8mFBO69PBdS rCUvo8PS6yxGzsedjXntSrmtlLMaYsXvyCabmZfmMAufz9LIpfwiG55rDzl8 /J9ZRv3FsC2vqOps/UgL4DPFcKIYjhVDH2u4nmKQiiFQDGIxpJhXZHQXgdL8 /UBfvoj2j2MuX1i71LyWF8MYYrU46Jh1tuMNioKPD1HueJNqklFEwhtI/CDd /E4YpWN15mgck7qY6ILfV+qauAB5QBRFiSTN2X7o6U+2wcCaObiau02jBtDR gc5HE8XxRHByWeP0P/+57faRz2deLb7IPd165L2bpoYr59QX3bHr0Rkjzz3c HI8Xt3biuTPY+V3CIR9zT6NybJNGI5FSn8/vLSMYTmU2mywKSyRSplQqVKUq n89rNltMfj9Rl0pVD5j8FpPJrzC1EOLNhM5iUZhU/lKLV1GmEl2FRWHefshh 0JfL2tLTpUdKcU+oN4RDRaIz4Oxy9jlTTsHpyKZxOENFOgOFxXGiPK0iqtPr QJB8zjIURytwZwGgAlBzBQapwrAUvxaHw3HYG4etcbDEgY/DqTgcj8NQHPrj sCEO3XFojEN1HIricJbFkqiBbGwjC5cT1pOgHSRUuo6lKmKBuSQy/RoW1ZpN mCtLznBHHo0UB5yIA4rDmIm34/LF2SuZaLPq02V7whawPWFEhTpKFahZTIOS jUoV0c0FUdmCtJmPDjHdSbzsmZHBRq0SdNTqgI1CQCow1XqoUioWWGvbInCN ZbkFP8O/QveP0XU6KqIz14rQI+Xy6Qg64sbl2Y9k6xGB7EqlmSB27uP0jNbQ 5gOldeH0U7NbR74zrTkJT8/evHMGtFQvH//t349vT1TWuNp//PPZbqensnIZ TBztnpRMVgbffLGuMplsuuan6YG2GWRcRtCr/E38LqRA10lRXhBepwZKQYE5 BXGTYQsCD2ToBgSMJiOs41XoBFbCB1jedYKccdfRo5UJWdnhs8oOdYShhh5x 5m86f5RPXljEPfEqvFMF77SnV6ZXyJoev5Vqeug7Uj1ygSuwXTK4Qce5LTqw PFqaEAt6C3CB9qB5u47rioAhQnT5yDkM+GDRdvA4+12uYMRAJ5K42dZk6C/Q l3pLy0s5kS/tj0TNwXUKSQf7FGWKlfgEU+V6otAcBSmj0OUt34q/H6aHhobp ybY4AatEf+igJ2Q6GoaHhzqiyCEOsVNUI0MdmRMbuUUzI71wJ2gM0qBkxsM2 MREvv/V8ZhWVDyVvfiZ9EAxtNxRXVrasT/9X2VSwbdldObZ+mv6XB1eO/NHV Oj8dvn9aWpxY9u1vXNo3mONeR2BBHI+AJ26FYFFwmPQSBDg9zIJ/pm+A9A35 R/uGe+LCIj6JH0lH22AX7GxPR6m0UhGkTXczu+Azqc5oMrUYRVNm4zJxtRhN 4mZavkJAioACWwRBNJo4XiHoHC7Eqw8RxCrYFEdGz0qjKlPtAwoo5qZxmBcU AkcIFRrklJzNRDrxzpzk8VCbtLZPS6Z2rUZya5biNR7o9kCrBxo9UO2BIg9Y PMB74KwHTnnguAeGPDDggX4P7PDABg/8HfoT/wx9/f9lAX359FJRNkXCAwEP iCzFEMu11wO4xwNdnowAW33J57ZLPv/tTbZfZitPdtDh3ECXQJhQo7E5s1DW Ns5WiZWXGLIv2cIaSf/kiptW8RdX2KlKxMfoSVxP0CGHbpQmcoAgswpCRpr5 TgwKvATvwgfxaXwOK5ROBGpUj65BD6I9SNAjIngEmNjHNp+sXr2gIy4OLqAb HVajhgYyuAV5cZvUF9en7c3wifDwF3OFZ0mp3WQM9xMJo0G9UgFnbiHlbsyU S6WxWW+sVSJuj0aBnaROGLQCpuJET5QtjFVIp3xGJakopU1rqFURaUI0xxM6 6NNBlw6IV+6BeHbH5a+M9XF6iQa90qRhpP6NKKsc4bzNUVa9oHwTF9efTj4H n6U93ZOqOEko+eIH/DuL74RVpC1Gz6Sn8WL6m6SdCgYAcwKOi2+g+FF5Uwwv nj/BB9LTWjM2Fr6G3VIfgohkcm1XSaJTtV1MOA8GtyNOL5I3+b7b3yQelAxM wVynVNf61hp4P49VfBjpRX1Az5GvS71OQuI+S5FlJX4kDOvCsCoM8TAYwvBB GF4Pw5MsZHYYGlj4KAt/iwV2MrI6me51llhO+TxLto6l8bMQVZ7+c6lFc8yU ebrKNVJFt62Kv1/QQRfr4kTqRgfHttBkpteyqDBBwEVcNbeD6+eGOMETAF3A E7g28FCA13k8HlzAISxiLPKZI0zMkE8NNAzehS7b/zC2CSaJI/8+MnrmscDy O0bWZ000j31t1/7NE64Srv3NwX/5bfqtjhtCY3tfRpZ8d/ej36H/jQJaO/oh ryJacyVMkCbWlh8sx9PLbyxfWs7Vlk0ru7OMKzNajOvLyyzl5WXVFii2gNGi c+rLJ5VjVXkZChuCYKL39/BeOuoW6M213vCjTh6pmlVdKk7HqSSlmZf0Yi2v exSZLUaboay8NO4v7F8VXBfEQcO6eFKh7leVrkO2hE2yNdt4la3qTBJOJOFY EgaTcIY9E0kIJOXRe1tm2/C7bBY83nHRtTxDuWt4GmbleWis/GQ2ZTK+C9YO UQNY9i41R0CpaRrQDmlxJV1wMRDfwQi84n7TjfvtYKdholLbNICHMD6cgATd JUx3AJMs6C7j/841O9l7dnyYdCe+6Y49swMxIncM//HdNY+t+l9f37PyTz+4 ekOTpUodj3uefWL1I8uOPfD0XcP+iPUqeO7Z1JrFsx5ZffXix5fu/1nQlEzf su/JexdMuGPF1FueXNF/EsnYBN9BuMsOXulNAkF0nJ3IB78CHwQ92mfOQAuH U7GuO5G7RCVnRJNvTOGzN6bkrHFybDUzwp3KC+93wo68m1hksnxb3YQcdc6a J2fEZ69kwbk7XbqyN77Itchd99LrvEhf67zyHoYra1p5e93OEng0QpWqBnoG 82IwNGZPxneM/CizgWyy/DuGdMZMxfQk2odCirSzAz6QFghGvs5kNN7HcxaC MXgCFIzr6YK40URgg5EfpxAJwhCQTac+KDk0nMEIWiMvmANGyYj1CigwcGDi OYfBWFvGjedmcCu4ZzmBMyF7nx0r7ZSjDGpdk93vmO1Y5+AcIr0UalDq15ua /FrQSgZNg6ZTs0rzpEZQaQRe4+CNzUaQjF3GbcaUkWdmLWPA6TJONiU6XeB3 wacueN4F61ww2wUNLjC4YNQFH7Ab9nrYXXoEPU3I3bgnX7Qn37An374XYJfs nXDBsctu5cu/i4/kcmn3XGlhiPZSHZN0Rjtb1nYd7YjW02vTouwSNQYFFrCF 8sEkYWmmFg8OsuvTGEAsuOT6NMbM1RrTDBPeZYBrBJgnrBCw4CDcegMPT/Og IY2MVbuMoDGWGWcY5xl5Ne0VTfbStA5g+xBpFdtzkCK3dQQy6+Gp65vGpyvD aUPtnPk4urseroNxddtgv+Cds+X8k/yqe1ri8YXR+0cU+LP7x8+Lk7mPnuS8 h0hZagH/pmQwbUe8bju9HoloyvRCpE8kNXEYLGqN7PMSh2EtvR5pFbaupdcj 3YyRExrkK48opPiyq4lyNrWSHSLoRa+IOwq+XYBxgakAm3jwEgXOBthmsmG9 xWvBBXznGC+1Q96CMVSZjCJdCibgGZ+EUuhJb0+/k34vvQ16oOTdkyfffefk SWFFek36Z+k307fBQ1APdfDQFz+BG6GQfNvTh9K/J99nqHRqTU/Dawma0qKJ kl95UoG0J5FHUINS0YyAoWkVUq9LcBKHuXgHvf+go0o+NZl5nReXaoHUr4jW LGwlzAZ4bfov6VPgAX16NyxPT9sGf4QYlMMft437fOSBkT3pv5Fyo6Tc1ky5 PlImImV7NKRc1KkApBAVWKVQrwtwQODHu1cuV0nKNfO0XKGGPMNR0IE3fTJ9 FpalHxce3pZ2pt9OH087t9WAEi/FX/2cvm+YqJ/ziC5iRielb/IF+oLNsiKi 0Nv0xXpOzTm5CMep9fzuuAY0OgNXsBshEQUQpyUooIDn9OqnNHoNZ34KSVa0 HFu4JfgRK0hWCFgBWeGYFVJW+MAK26zQY4XmbPjER9jPCRa9jbnPMO8g8/Zm qWezKNWCiwRoHncyCZoZW2xvQ5zdoEKVyuH6hiHyoLu+ZBxLoB4XrIEQXWCl rAJUtRzHzdNd+A2eMLxwVqmmHP9m5F+hZtmNUQ04038Mc5OMM29Khy/8xDZ3 aWbuErYTmZpEx6X7VY8GJZch+Gh3oqzEY3CC82DExSWxHolkNiPYEBlKASSl qhb6Qop1cSmS3Bevid+K3QV9AfU6C0m7z1JNkGF1DRTVgIVojDUwfqgGumug Mes/WwOnmFcmOlED+FgN9NVATw001zDZ1Zm3IW/BJdr32UHmOSfvpKZLRgT2 UeFEZxl2vwz9yeG/7JQTvMIWVnkCCl42HQnb5eXN/WQiumhiwguMs7vw1WML nPBg+q6xna1ZV3oPLL146iLtfISMyknCMmRFs6WE9hmdqLTiZ0CLn1ZYnzZu UUgGBZkwbHbFloKEZAcCJU7Yoc8OXXYgXnlg5NaLRk6L5wjQH65qOD6cP6uG QsQ1Lslegps0sun2bk/ZtG/cdrir3D1vSdw5cSq3t760Mj7l/MKpE51EMs4Y /ZB7OSMZ75SkCQqoJhLB5DfFTZzpW0iJdKIuoOO0gu5bCqfhQSoS78XWB6lI vAdL2Rvj+rI3u2VrmS8cCTtTQDg8hvfUAR66McSZNas9X9KZ86UeGvrssyH6 d8fau+++Y+29RNo9nH6efB+CNTCHfG//4nWYBuPgKmhIv0qk4L+mf0Bv36aa Dt0R4ECFKAZ9ktOAyCSgF1Bsu1MyqZzbnQnjwcB2E6emm6y3EJ1HfTC8XUUl ALZxKOT9us2mKyXiv4KIf2donU4yfVe1T1euW4n7KmAbuzSlpwK62AUqJyrg SRZCvM0sJFABH1TAIAtJMC+qgPFvsWixAs6wLBBLeawC+lhecsr82foKCk/+ fYQ54RAnf2wDN9F4xrQeGpSdj1FCZ6pdjKGLTBzYAkVQDdxeBzwc+WFkOMLN j6yM3BP5ReR3EYEvgYGSUyVnSzh2/nOmziCfc1rpu8e31Xfex1uoNWONZ4OH M1tDVrzdesD6kpXjrRYrdgqwRwCFAOcEohW7BaycwM/kMbcN9+EU5thFBfIe UfpYHWXr4fSi4Gg7sKsvFaHsxhF22oBkqhByGlZucTLEHdz9nds/fm5k+e31 lCVv/yug9SO7f9O3f+iphbOXr+l7+9TP9+MfWJ/rXf78wnjzZm4y5cLXn1u0 l3vo3i07befXuHZs2PlNdlNGegb3MfdTZENB9BfpRvtuhULl2l0g2vAhcAd2 qsxwQLQLGyXbAXPIvAx7N2jZ/esceRQIhdolWGInjejVBc3Z+wnk6woGs+7M RQWsA3OLvxfdjnE6dztG9gxeptecy5V3Kx9UclRPeyTIPeT5xIO/4rufHUH7 rZSwOpqGdcA9rDuqe1/H7dUc1rxG8K3Gr8HdblAHnJ6mb6u/q/4hQVdqvxor 5bOTUbbpoDOLr+T2HrtGY5x8m0ze/Rkfpyd2T8xcoLHonqWFkbb0v2fuzkjP iAfuhvmZ+zOCwfOzFtbhmuzlGYBMBHG9SHiwFDzSbUGfVnUwoOYsjyGzwe/3 YyXn73P1SoF94bLwrVjTZ1gnqfbxEX4l5sugobsMWsugsQyqy6CoDCxlMFAG /WWwoww2lMGabLhYBoT6bBmcKCPzRxmkyqCvDHrKoLksc3fMZYpJZg8IafVT 2SMQ7PRDA7sbYjB7R0yb0wxCCXxeAj8xwzzrz61Ybyu3TbLNsq21PWz7tm3Y pjpKHiM2zpYgTIJNsMh0m+k+0x9Mn5kEN6yEe4Cj56b2wmHgLaXAl1pKd5T2 l/KQG/10OX41vSOmyHjZ5FN1Fb5EQUL4j+lz6XPZSeia76xYMbjEwQ5YkFkq /Vf/eVDjr2QnnJGT73x//qxHBu6Fv+aC+tPpv7C5fvQT4R3SL5XwtnRjLFYu CLwiqvjX6G+ieJf/oB8H/f77FFHCjlGBExTc+oqYpaIiNisGmMMV8Wti4Bdi wahQKimaFVihKCgNux4gGvrBYgeHDlbGt2OztoBKVWpJKjio3xs9HH0tynHB qL+4hMg8JYqJMWwWKrgYKbgy6fyurs+vWGeSHPp9pirTStyfhG1J2JCE7iS0 JmFCEnhmhDiVhIEk7E3CGhbVmIRqZqIYSgJJsiNLL4cHkmBhCetJhJQkbw1Y NmoMJiGVhN4k9LAI2a4hGzv6ktCcvHyF8kq7/S/TcQfPnhLfMdrrmb707lF6 RjrvOJe804tePU13eZnqicBm4I3dPs1n1CfUQU/byEtCbBCGbQK9m+J0DMpE g6lpIAA15cDdWLa07K4y7pUQtIVgOidvP+1kezvIcGKnt0D5pUAH1Y4tCgEi TD9OeGfNvQ+fT//bPa65C0eeywM6sKhx9T3w2dTdt6R/CRLEuw0VFvDBizen Bxa0hi6FO2vgqoaNwavi8bavpE+nS9Ov8WSsBQm2MJGx5kPvSWuR56CXM+hB p7dsV5kVRpsRG41ard+zz74O7ROEgP+RAKwLwOwA+ANgCMBoAN4KwPMBeDIA clScRX2QFxhnlBM/DcDrAVgVgAaWhrj7WIJAADoDgAIXX/x2eVfSVZzTI6fJ 800mDI4SuJK9MOp76oDO1KSkE6Ke6LGagE5sUjD7k3zdoMyg+ZslsrslmPHb RJDiy9/q7I2G3XGfK2ytqGX4kR2LGpn+znuLmkoqQ1eP93Vfy61mx6Ey61wT SLsVQ1iKSHrQm7dLswugQInojgcVF3Ypt1clMgoLKjqo2B7mHG7KdXrCde6D LoOuX6+3ADXibjU7mqBfVvE4VOrsU1jW+aWwa5+/xL8SD5RCfynsKIXeUlhT Ct1UVMGZUjhVCsdZ+Bp2zUNrKTSWwrFSGCqFXJIN2SQkViqFRCkESoEJO6g/ y7KQ6Yh/sBRwqhSyN9V+yf0El3PVKXat13A0s8gm23Xp+hrb1DKUXWCj/4cF XUZLjq2pXW6urQnyE5LVt92aHjzb3lpcWTnnvrN59lpexYcWdfpGfuG6/qZ0 0f3T0usvMthSG0LD6EfcAEHKJoIXnpNqkdq8l+MMnm+pleIzBidyiqLC+aBO Cunuxf4HFVKh4jhFCIjdctSXhQZXwsfk7UzsTvMMmstMQtaZvvk+HHNNdF3r +paL5xKmHhM20XFIjaXUHI/V7NxpAb2wHRt4PqAXmwSpwFgbRVEmiej54k75 xLC88TxJ4TUK1tSiMJlkxo3LXJFsw59UH2zr+91/HHl3NN2afvEcVKb/WtE2 czrgx+9Z+rWv4Ttmtg9/709E1f95+vfpp9IVVQVw+/bCCW3G4s/Ad+z7B9+i J4cJt9P/v8aFfi5dYyU/4PqG3WaxE4ZAdqt5L8Yq1x7JrtBKBkutVv8tldNu czptGvFBQfII92K3higUHvg/1T0LdFRFllXv9S+f7tfpT36dR7+QL7yQdBIS aKZ30wSISEQQIhARsEl3kpYkHbo74ScGRiJ/hQVGQXTYHVBBRzvgwbiu6DmL 6I4iuCt6dmZdYHUdPWdYPeq6exSavVWvXqeTIDOjZzxn06lX9W7dunXr1r23 6r2q9x6iK2OH6BqXN08VWNK1cMVZ+uEIlPhmxOkMt9ul+lMt2/hv/dCEOYT1 xozHM36d8UqGxqjR0F3gIJ5+YZ/AHdDhCl2dbo6O55fz2IhwCt0PS1fVqIKR W1HNVmV7B3k3waShDXIl1nx7/oedu89/Hj//1a595gdWPvPbx7btWF09neu9 9i4vT7p46v34l55plRdeePSFBQbuF3tBPg1wafIo6E8u2vgSMl3/2jvRaK5F qdjKpxr2m/S5nH0/tnParRk5R3PzvGmcg7uJPMBGzuSa/332lfdBBGAZ7tPK KxrVm3ApFg028jhDYx68fv5FaLPdbMsir12kbSQbB5CFtaWW7WBBeroGzT96 9Tn8j28+1PXefbL77N5Tlw/EV/bic4tnuWbhE9i7se/ARfPAwMXB+/4n/qvu uWQNClVe/4iPQcuK0fPeOmvGYwjpgOsUPi/3gKRPSYMLx6ytBVYRWcWCYq3B BBeRpXARWWK4yHnJK2TwpVJ8iPoZOB3R31nQ3xVXSIcr7SOe4Iw6RU615do4 fZ1mjmaZhidb2MgVjiaF5wavHzghWMg7rC+dSEmvTSUyAM941PGSAy45ZSaF pUuUSw/N8M6tqa0dIRk9d/cTJ+Ov/+9Le8Rt+5/9lwPrK2btOeRvOrFr3Jy3 dz744tYQL2ec3fPht3dNaXj92OZDwqziQy2z7n06Z/fWv4ve/ati8h0R6Pu3 4MrfClcbPyevIKzN5DLt9ofMgs1sFm4VtgpHBR4uu/nM/SaT3qzXGo7qBQN5 WF4Pxp1h543bkPZpCWOcLXjN1pmCNxujbHwpGx/KxvdkY292YmnR/P6ST6qu ZbnPVCylG/qr6oiNwLyj0rW5nG4px0twgX1oh1JNfg2uzqjOz8D8W+emrb92 KOrPu3aO6+48F++PV+LIMR/0QY5nxrGNfPTqAW7nNfp+0lnQ56egRcQbPku8 YQ54wxTwhHrrwZQc5DSb0zPBCxboLoA3TPeOTV/347zheI1kk6ISn2azF9q5 NMvPLI0WPt1CXGFaqiNVTuWN9OsFAnma7dMTxBOSdwMnOUOZdTnrVeUmA8q3 6xBmXW/i9HqbBVuIL/ztpy9+EMfP4tu/iZ/DqG3tuqXMH3L/Sn1h/Es8Cefj u/G7lab4zqsriRMsmAIO8au4uh6k2Qje0IEXeT8zpaUZ8py1ZFXIsZlsR8k8 hXMPI4fkcDl4Pe8QjYkVojwdjMoiPizivSLeJOKoiFtFvEDEDSIuFnGmiHUi /lrEn4j4PRGfEfFJET8p4l6K1qSivS/i0yJOppNAmC7iKhFjScQ2ESMRxmoR f0yJAaJfxBPVDO4LEV8S8XkRvybibhF7RewSSTlzEjwm4kM0dy5FGLUelNjj t3TJsB1X3/Pg7NDY/7H5fTL00535p5WteeyxE5SDLXzio0qjlpLYTpqN3x1n k9lAeIm9UsYVOzbWJE1aSxZ2XP2g768eHyCrA/F12m/AfzlQCfpyIMtG3luT mmKptfUZDFoHfamtZMqYmbOHQzazzWXjbYaxe0yavD1egxUVuYo4QVtEVg3q yaqBs84J506ylKClA3M6b0CGFCuf5lyf4RUysKAblxHiitbT2wmCrjStg0Pj cJ3yzlNlaWHoFkHSK5hOkyd+3UOPEKjrDRb3EpgZnaGPvcmvIWX4c2rG2MZw aZJD4jTFtmIurdBRyJk0FsxvEMnudEzfpLRUuRFAJgfFJcUlherqA3jVrDEc edFD0u047TcdyzYc721aUBn/Q3yQLEKQRYkvfvdww72rb8kvuXqFrUnE92R7 Fs9fWJKJt+ECsiRBlii+ie+Zsbl+1ngDXo4XAVhdn/gw/jS5Y1d3/ff8P4A3 scGMtgy7vXMKU3ciOyq0T7RzyI4ztCjVXqjROg6a9eMPanOyd1jtiBuzvTA1 32g1GvK3c95y7gJXssPgnWCAaZd6e+2QepPuxo6GeBo3eeqjQnkLkoVewC0h jw+qw+imsr1lHExiS8m8637wKosLnil4uYBfPHbF2O1jHxur+VbCeyU8XfKD c9orHZZekHTkURsuh0zG9mbi7Zn4tOU9C/eYCTvS4H972ndpvJ3Hf8+TnW5H 8Ov4Aua16Aji9Pv0R/QceRclJ5t+ZuJkPS7kMe9KxXVkPwwWcMKGkHozTfnS jGJRMulKDd2KWlgzsag48Vyylg1oZKKHE7sFq2q5g1j69swr1xHO33T/N88+ cyV+cuGSg9GWnd34qcNvtXT9+sHV+7gvHv7u6Q/e2ff1/Q2/DO4++/Kmd24Z t21e5/6NCxofvHZy9S+bXM+0bDryMKJfMKTh8bkzPlwmeP4bOQz048nHj9x2 p/oh5euReIN+jY4k9RSfldPnx2eghYnvLWM0/G+Wzo3zNB+hmRqEcvidaCYH QO0byMaL6HbOjWzcMeSAvAaSr3OjHIDVETwIDZCeDri3Qd5M7QIa2yAYINRA 0AHOcig/D/KqSRpwS/Q7gQZCIUib9UuRH9K7AdehF1E1wKqB5nOkLOe+HoGy t1OaD6BxwGM1jYE+4CCI/Rp0/QtNBOARtB5wSXkb4QfSTRBkqLOI0ATcQQiz CB+U1zeQhcChjfm0PEJ1EOaxdlZCcBJ8UidrXx2IxYnXc17uY+5jzV9rZ2pP 6Yp0H+kPp9pTH0krTruQ3misN35q6hSyM+6wGq3n7cvtpzP/NsuUdTDnrVyz Y35eJO8R8eUxjztvc/5G6st/pKC0MFoYK6ov6it+svhyyZSSOaW5pfFxx8ef lWfLW+XXy+6eYJ5w14TT5R9UPOiaV7mlqrDq8+q+icLE+2qMNb21utp/m/T4 5D7Wo7NgBszT/uTgynUMmg/yGWvoBRjJzcK5iX4/mdABjFLgDLNSevQqS/Mo B51haQ3gXGRpLUpHn7K0DuBfs7QetaJrpCZNChDtwC0sjZGFO8fSHDJxl1ma R1Xc5yytQRY+n6W1KJuvZmkdwBtZWo/e5pewtAFVacaxdAqarFnM0qnYoNnD 0mmoVvsYS6ejbu27LG1Mb9BNZWkT8ls2Tw+2BaPBtQG/5PdFfVJLqHtNONjW HpWOSlUuV6U0ta3VJ80OdYWia7oD0rRQuDsU9kWDoa5yaWpHh0RxI1I4EAmE ewP+cqmpPRTu8vs6AsekYETySdGwzx/o9IVXSKHW7ycm+br8UqdvjbQ8ALTa gpFoIAwsBbuklkA46oP43p5wMOIPthDsSHmilnmBtp4OX3g44QlDXCQSCwLh CKmostzlGp37F2UWTUdB1AYhCmEtCiA/DEJ+5INzH6RaUAh1ozUoTLHaASqh oxCqkAt+lZCaCvBWijsbcLsgRAG/GyhJaBqchSFNjj5aA8Eop6U64Ccl0Y3Q swDEAYh7KScEswlySfkuylUHCuSPBWiQ4pNao5S2H/A7IQ6jFQALAUc/hDNC sYtKgNBaA/Fyik34aqN1Ril3ipSCtEQLhRBpKef3oh7aqgjgBCFXpR2B1oxq C5pHKfdAmvB+M44n3EgWN4AsoPxEEi2qhHpJX/0JZf8fS/bP5+hmJaZTzFW0 3jY4nwOYrbTOPy41RX+DVE4qRVJPC6VMUp2Q20Fl4Kf6Tiygi7U8CrRV2XTC MUpptdCalDLEIjuBqtKS5bQnJcprFDgjOhKkJQk/t0O8CuJ5tAzpgedQGaXf Qy2Z2HaU4g/ZfittHWlHC+2PAJW9n7awm+rpGipxYrNRgExBFfBbRX/lkNvG 2jhcpuWM7x9WqoKW64TaK0bILJyALKO9RdKrGXcE34hSQQpzQCq3wgB8K+jC VJqeA1DSrw1wvI3CZwBkPhyJdt8CEpsBv9kU2gQwQocE0vtKX4/uWxXeTs+6 gbcQxQhT3B9jO6VQajbUPS7JjoLMZ/ZQjSN9SupYAyV6ErwQ6fUm2VUPk1A4 iU/F7jopvsIh4a2DaXsXo056SNGGTgqNUt/czGprh/xeihcCPlSLVTX6+yUW oTVGQQd8lLoEIcg4CzOtI3Bi64r2t1KpdlI5zqY9E2KtCQGHgaSyQxYxuhY/ 8zhhakE9VAb+hAxDlHdVGqqchiTSQuUwJC+Fk/Ibasnouoc8RS+16h44qlbs g7wIbcVo2ndCzR203khSPw9JXumV4T5U8SaKV+qmcgwyP/an9LBEIT6aVj2h Wi8ZF/xs1kDk5Rs1mpclsMNJWjok05vLp4N5pShK9otDVLroWXcih7RKkUMp qqF2sopqxgraz8m2pPq3Id5CgNtFLbaH9gThoD3RYqXOZG1XRzDFdofmSKou 3ki7btbmZM25lcpndO+SXiA1rAR4gFJXxz6l/i42WnaN6KkwGjnHUmlH6DhG Zh5+pIzDvYCnjBejdf77dUSlp9hpgPWDf5gFqvRG97YiMaUFUeoXokm2rfaV b4SUb2yXN/NUqnxv5n1bqJTV0Xc4T0qLiB5NSaJ2J4wYU+F8MpqIJsEMbRLM tiZD7IJzMueS6O9O1AjHifArBdg4wJmEqiFIEGpBW900DFEloYG1fGTrkr21 OhIQDfVR7zfaArupz/Cx0r1UA4PMv/QwPxmAFksMHki0knDxQ8ZnNa9iBO/D x2QSbmOzji44LqcSVnS3hx4DzMaVNt5O7Wgty4swbWtnHLcmxn5SZj7VY9KO HqopPYyDMBsZFtIWR9hYE/hJ2jo3Ie9u6vMj1E+UUL4VLe9M8lKjrdrHrK2D jTx+Og6qcwBCqYeWVrxXsr8LDCv3/f5Dme0TXScYHaxEGdWaAMCCDLY2USJC vUeUwRRZhZmd/5SS9VHO1blHgM0LpRGyJWPfV+xKRJFqCy3lZ14kxOYon1H8 IOUwkpQ/NPoHabk1SaX8TLtaqE8dKtVDPV7ZMMsLUFmpvRCmo1ckMZJKTIcD dDxdyGyTwH4aWQaY1xnygH5qpYq2BEdoS5Rqi4/SlRLzDnXeFqT5wYR+jpaF j8kjSFurSHy4TEJJHkq5Biphtq7UsBZ+ob+4bH78Vcsfr4fe11PuE+dD827w 541dvJSZlffeBTisuy/T4V1ntrnX3ZezbHX36g2r+Xf/GeC9q+DQ2Q2HjhAc VnRlOuauuLSCW9HVF86N9tjseW33wqE1CIdAu80hBbHQ7myvaOWF9lfbr7fz znZXwBvoDmwI7Aq8FjgfMHjbTZnuV9txLIB3tWNzIkMbaO9fmZsTyVw7LSd/ DQSO88bMFnfseY0sHMfeU4VFbrLlIP/3APT+zprtnnMaH31KkA9DOALhSQje p6qmEawTl6trlDjbSUulXDZBqf8wGin0mFSsxGlm9yD/2fF9vEyQbFeynO4/ 7Ofk/Tt4ec9uXv6b3TTj5O6iYvf5RzF9hOmJCS73nCfwE48g+RePQDb/X8e3 kOiK1wWlvvoSyV/2c/Jv6o3Of3oTyW9C2vsqsO59BQ67PsefAeCT/hznf/ZT 0icGcvMIKy8OWO3ugecx5aPs+aw89/P9WH6n3pX/NISzbyP57W2cvHMbkndA 2L6Nl7du08jbNiFKZEMBbY/38s8Li90b+5B8f59GXg/B21dR4+7r18i7oNot /UjeDOkH+w3ypgd08gOQ9vbXTnZ7+0tkt2OSPbvWbq+xWybahWp7epU9pdKu c9n5CjsqtxeXmEpLhPGyqUwWxhaYCguEMU6T5BQEc0Z6Smpauk5vSOc12nSE uXQd73d6kcnk9iKL1Y34FPk8jwUBC7wg1AnLBE2KIDh5Tu/AojFbn2u0m7OM Fo3NWOYZ7yn1FHsKPWM9kmeMx+HJ9tg9Fo/gSfHoPLwHeeZW45ilETU21ces GOL59bFquXGQl+bFquTGmH7u4kUDGD/UDNAYt2UQo6aYZssgB5Fl2l2LFw3i HJLd73gJYYxijff072we4FB9DG+JFcxfRCLvHYti0pZBM2paNMDh+ubm5tik xrmLCFazLMb8jYC2QWyOVZHELrEZNcam3BFzFNTLN/pbGlkaiUZHAAdKNTMK ZrT7YqUF05Ph+IYkkv4iiRSS5WjS6TAMCANWUoP/ntgbBdPxtEWOZhJkOZYd Gw8iAxTCVDTa05NEVjkOpBA5zp1X3xgzzIMwd3EstwBO3oSTWjhJL6hH6P8A CoVMWg0KZW5kc3RyZWFtDQplbmRvYmoNCg0KMTcgMCBvYmoNCjIzMTA5DQpl bmRvYmoNCg0KMTggMCBvYmoNCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvcg0K ICAgL0ZvbnROYW1lIC9DQUFBQUErVGhvcm5kYWxlDQogICAvRmxhZ3MgNA0K ICAgL0ZvbnRCQm94IFsgLTE2NiAtMzA2IDEwMDcgMTAwNCBdDQogICAvSXRh bGljQW5nbGUgMA0KICAgL0FzY2VudCA4OTENCiAgIC9EZXNjZW50IC0yMTYN CiAgIC9DYXBIZWlnaHQgMTAwNA0KICAgL1N0ZW1WIDgwDQogICAvRm9udEZp bGUyIDE2IDAgUg0KPj4NCmVuZG9iag0KDQoxOSAwIG9iag0KPDwgL0xlbmd0 aCA1NDgNCiAgIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+DQpzdHJlYW0NCnic XZRNj5swEIbvSPwHH7eHFXjGQFaKkLLJRsqhH2q2P4CAkyI1gAg55N8X3te7 qnpJ9ODxeB7GTLI97A5dO5nkx9jXRz+Zc9s1o7/197H25uQvbRdHVkzT1tMH 4q++VkMcJfP+4+M2+euhO/dmvY4jY5Kfc8BtGh/madP0J/8FD7+PjR/b7mKe fm2PfHS8D8Mff/XdZNI4KkvT+POS82s1fKuu3iTY/nxo5oh2ejzPG/8JeX8M 3ggfWNZW942/DVXtx6q7+Dhap2lp1vt9GUe+a/5fLZS7Tuf6dzUu0XaOTtPM lQsIIF8BlJABHEBSQAZwFpADCgUUBGZbEQTwwmx7wIbwBngl7ABbwgtgR2Dq NwIP3RO2C9iU5RQA+uSowNLHIYGlTwEfS58C51j65EwQfGBqFx9JLc+hj6BQ S58McnbDMK7Qx0HO0idjavoIs9Gn4Ap9HA4V+ggSSPB5BQQfnCP0cTAV+ugG EHxQm9An5wr7k+eA0B90W+ijqE3YH4dXJfRRlkOfggmCD3oq9FH4CH0yrCh9 MshpuG9oiQYfdEHpkyG10scxAX0EhSp9hHvCfYOc0scxLPjguih9lBWE/uDt aPBhGH0yaCt9HF68hv7gHBfuGwp19FGU4+ijSODoozjHhf5A29FH0TlHH2U2 +jh0wdEnQ20u+Kz4XX98v8snjqn0OUDq+zjOswPDCzNjmRZt5z8H3NAP2Bd+ /gLEVxwmZW5kc3RyZWFtDQplbmRvYmoNCg0KMjAgMCBvYmoNCjw8IC9UeXBl IC9Gb250DQogICAvU3VidHlwZSAvVHJ1ZVR5cGUNCiAgIC9CYXNlRm9udCAv Q0FBQUFBK1Rob3JuZGFsZQ0KICAgL0ZpcnN0Q2hhciAwDQogICAvTGFzdENo YXIgNzMNCiAgIC9XaWR0aHMgWyA3NzcgNjEwIDUwMCA0NDMgMjUwIDcyMiAz ODkgMjc3DQogICAgIDMzMyA1MDAgNTAwIDc3NyAyNzcgNDQzIDQ0MyAyNzcN CiAgICAgNzIyIDUwMCA2NjYgNTAwIDUwMCA1MDAgNTAwIDQ0Mw0KICAgICAz MzMgNjY2IDQ0MyA3MjIgOTQzIDI1MCA3MjIgOTIwDQogICAgIDI1MCA1MDAg ODg5IDcyMiAyNzcgNTAwIDI3NyAzMzMNCiAgICAgNTAwIDU2MyA2MTAgNTYz IDUwMCAyNzcgNTAwIDUwMA0KICAgICA1NTYgNTU2IDMzMyA3MjIgNzIyIDMz MyAzMzMgNDQzDQogICAgIDcyMiA1MDAgNTAwIDY2NiA1MDAgNzIyIDcyMiAz ODkNCiAgICAgNTU2IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDYxMA0KICAg ICA3MjIgNTAwIF0NCiAgIC9Gb250RGVzY3JpcHRvciAxOCAwIFINCiAgIC9U b1VuaWNvZGUgMTkgMCBSDQo+Pg0KZW5kb2JqDQoNCjIxIDAgb2JqDQo8PCAv VHlwZSAvRm9udA0KICAgL1N1YnR5cGUgL1R5cGUxDQogICAvQmFzZUZvbnQg L1N5bWJvbA0KPj4NCmVuZG9iag0KDQoyMiAwIG9iag0KPDwgL1R5cGUgL0Zv bnQNCiAgIC9TdWJ0eXBlIC9UeXBlMQ0KICAgL0Jhc2VGb250IC9UaW1lcy1S b21hbg0KICAgL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNCj4+DQplbmRv YmoNCg0KMjMgMCBvYmoNCjw8IC9GMSAxNSAwIFINCiAgIC9GMiAyMCAwIFIN CiAgIC9GMyAyMiAwIFINCiAgIC9GNCAyMSAwIFINCiAgID4+DQplbmRvYmoN Cg0KMjQgMCBvYmoNCjw8DQogICAvRm9udCAyMyAwIFINCiAgIC9Qcm9jU2V0 IFsgL1BERiBdDQo+Pg0KZW5kb2JqDQoNCjcgMCBvYmoNCjw8IC9UeXBlIC9Q YWdlcw0KICAgL1Jlc291cmNlcyAyNCAwIFINCiAgIC9NZWRpYUJveCBbIDAg MCA1OTUgODQyIF0NCiAgIC9LaWRzIFsgOCAwIFINCiAgICAgICAgICAgOSAw IFINCiAgICAgICAgICAgMTAgMCBSDQogICAgICAgICAgIF0NCiAgIC9Db3Vu dCAzDQo+Pg0KZW5kb2JqDQoNCjI1IDAgb2JqDQo8PCAvVHlwZSAvQ2F0YWxv Zw0KICAgL1BhZ2VzIDcgMCBSDQo+Pg0KZW5kb2JqDQoNCnhyZWYNCjAgMjYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAw MDA0NTg0IDAwMDAwIG4NCjAwMDAwMDQ2MTEgMDAwMDAgbg0KMDAwMDAwOTAx NCAwMDAwMCBuDQowMDAwMDA5MDQxIDAwMDAwIG4NCjAwMDAwMTI0MjEgMDAw MDAgbg0KMDAwMDA1MTc3NSAwMDAwMCBuDQowMDAwMDEyNDQ4IDAwMDAwIG4N CjAwMDAwMTI1NTUgMDAwMDAgbg0KMDAwMDAxMjY2MiAwMDAwMCBuDQowMDAw MDEyNzcwIDAwMDAwIG4NCjAwMDAwMjU2NDMgMDAwMDAgbg0KMDAwMDAyNTY3 MCAwMDAwMCBuDQowMDAwMDI1OTE3IDAwMDAwIG4NCjAwMDAwMjYzODkgMDAw MDAgbg0KMDAwMDAyNjc2MCAwMDAwMCBuDQowMDAwMDQ5OTc3IDAwMDAwIG4N CjAwMDAwNTAwMDQgMDAwMDAgbg0KMDAwMDA1MDI0NiAwMDAwMCBuDQowMDAw MDUwODc3IDAwMDAwIG4NCjAwMDAwNTE0MjEgMDAwMDAgbg0KMDAwMDA1MTUw MyAwMDAwMCBuDQowMDAwMDUxNjIxIDAwMDAwIG4NCjAwMDAwNTE3MDggMDAw MDAgbg0KMDAwMDA1MTk0OSAwMDAwMCBuDQp0cmFpbGVyDQo8PCAvU2l6ZSAy Ng0KICAgL1Jvb3QgMjUgMCBSDQo+Pg0Kc3RhcnR4cmVmDQo1MjAwOQ0KJSVF T0YNCg== --1870910533-250209383-1061565162=:2290-- From owner-ivoa@eso.org Sat Sep 20 00:39:27 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JMYtUa027720 for ; Sat, 20 Sep 2003 00:34:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8JMYteI027718 for ivoa-outgoing; Sat, 20 Sep 2003 00:34:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ivoa@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JMYLUa027565; Sat, 20 Sep 2003 00:34:22 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8JMYLI01660; Sat, 20 Sep 2003 00:34:21 +0200 (MEST) Received: from postal.sdsc.edu(132.249.20.114) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAdvaypd; Sat, 20 Sep 03 00:34:19 +0200 Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/62) id h8JMYF306217; Fri, 19 Sep 2003 15:34:15 -0700 (PDT) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu Message-Id: In-Reply-To: References: Date: Fri, 19 Sep 2003 14:59:43 -0700 To: Nicholas Walton From: Reagan Moore Subject: Re: GGF Astro BOF Cc: ivoa@ivoa.net, Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ivoa@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Nic: There are multiple grid related topics that would be worthwhile to mention at the GGF Astro BOF. The goal would be to identify which of the issues are of most interest, and then pursue a description for a GGF report. Examples are: - processing pipelines versus the Grid workflow environment (Chimera/Pegasus) - IVOA registries versus Grid metadata management systems (MCS, SRB) - Standard IVOA services versus grid service environment (WSDL/OGSA) - Image archive management systems versus grid data management systems (RLS, SRB) - long term preservation of image archives versus data grid-based persistent archives In each of these areas there is either a grid implementation or a GGF working group. We would like to understand how the IVOA requirements will impact ongoing development across these areas. Reagan Moore >Dear All, > >at the upcoming Global Grid Forum meeting in Chicago (5-8 Oct 2003) - see >www.ggf.org - there will be a Birds of a Feather session which starts of >the process of forming a Astronomy Research Group at the GGF. I attach the >draft charter to this message. > >This will give the Astro and IVOA VO communities a chance to input astro >requirements into the 'grid' standards process. > >I would encourage those of you interested in this area to aim to attend >this GGF meeting. Hope to see you there. (Note that early registration >closes sept 26.) > >Please forward this message to those that may be interested. > >Yours > >Nic Walton > >======================================================================== >Dr N. A. Walton >(AstroGrid Project Scientist) Tel: +44 1223 337503 >Institute of Astronomy FAX: +44 1223 337523 >University of Cambridge WWW: http://www.astrogrid.org >Madingley Road WWW: http://www.ast.cam.ac.uk/~naw >Cambridge, CB3 0HA email: naw@ast.cam.ac.uk >======================================================================== > > >----------- > >>From spartz@ggf.org Fri Sep 19 10:16:21 2003 >Date: Thu, 18 Sep 2003 13:38:01 -0500 >From: Clare Spartz >To: ggf-membership@ggf.org >Cc: membership@ggf.org >Subject: [ggf-membership] Just Over Two Weeks Away -- GGF9 - October 4-8 - > Chicago > >GGF9 - The Ninth Global Grid Forum >October 5-8, Chicago, IL USA >Chicago Sheraton Hotel and Towers > > >42 working groups and research groups gathering for 4 days working >together to build a standards-based foundation for Grid computing. > >Nine sessions will focus on finalizing proposed charters for new >working groups and research groups, including: > * Business Process Grid > * Configuration Description, Deployment, and Lifecycle >Management > * Workflow Management > * Grid API > >In addition to working sessions where community practices and >specifications are being developed, GGF9 will include four full-day >workshops: > * Designing and Building Grid Services (OGSA/OGSI teams) > * Life Sciences Grid (Applications and requirements for > bioinformatics, pharmaceuticals, etc.) > * Peer-to-Peer and Grids: Synergies and Opportunities > * Semantic Grid > > >***Important dates are approaching*** > >Advance Registration - available through September 26 - GGF MEMBERS >save MORE MONEY >http://www.globalgridforum.org/Meetings/ggf9/reg.htm >Hotel Availability - space and special GGF rate guaranteed through >September 26 >http://www.ggf.org/Meetings/ggf9/lodging.htm > >***GGF9 Schedule*** >http://www.globalgridforum.org/Meetings/ggf9/schedule.htm >Find "Click here to download the full GGF9 Schedule at a Glance" > > >The Complete List of Sessions/Workshops and BOFs: >WORKSHOPS = 4 > Designing and Building Grid Services, led by Ian Foster >et. al. > P2P and Grids: Synergies and Opportunities, led by >Andrew Chien et. al. > Semantic Grid Workshop, led by David de Roure et. al. > Life Sciences Grid Workshop, led by Abbas Farazdel >et.al. > >WG/RG SESSIONS = 56 > Grid Checkpoint Recovery (GridCPR-WG) > Grid Remote Procedure Call (GridRPC-WG) > Advanced Collaborative Environments (ACE-RG) > Applications and Test Beds (APPS-RG) > Grid Computing Environments (GCE-RG) > Grid User Services (GUS-RG) > Life Sciences Grid (LSG-RG) > Production Grid Management (PGM-RG) > User Program Development Tools for the Grid (UPDT-RG) > Open Grid Service Common Management Model (CMM-WG) > Open Grid Services Architecture (OGSA-WG) > Open Grid Services Infrastructure (OGSI-WG) > Grid Policy Architecture (Policy-RG) > Grid Protocol Architecture (GPA-RG) > Semantic Grid (SEM-RG) > Data Access and Integration Services (DAIS-WG) > Data Format Description Language (DFDL-WG) > GridFTP-WG > IPv6 (IPv6-WG) > OGSA Data Replication Services (OREP-WG) > Data Transport (DT-RG) > Grid High-Performance Networking (GHPN-RG) > Persistent Archives (PA-RG) > Authorization Frameworks and Mechanisms (AuthZ-WG) > CA Ops (CAOPs-WG) > Open Grid Service Architecture Authorization (OGSA >AUTHZ-WG) > Site Authentication, Authorization, and Accounting >Requirements (SAAA-RG) > CIM based Grid Schema (CGS-WG) > Network Measurement (NM-WG) > Grid Information Retrieval (GIR-WG) > Grid Benchmarking (GB-RG) > Relational Grid Information Services (RGIS-RG) > Appliance Aggregation (APPAGG-RG) > OGSA-P2P-Security (OGSAP2P-RG) > Distributed Resource Management Application API >(DRMAA-WG) > Grid Economic Services Architecture (GESA-WG) > Grid Resource Allocation Agreement Protocol (GRAAP-WG) > Job Submission Description Language (JSDL-WG) > OGSA Resource Usage Service (RUS-WG) > Usage Record (UR-WG) > Grid File Systems > > >BOF's = 9 > Astronomical Grid Community-RG > Grid Support for Ubiquitous Computing-RG > Grid Federations > Grid Scheduling Ontology-WG > Workflow Management-RG > Business Process Grid-WG > Metadata Management Services Architecture-WG > Grid API-WG > Configuration Description, Deployment, and Lifecycle >Management-WG > > >GGF Sponsors at GGF9: >http://www.globalgridforum.org/L_Involved_Sponsors/2003_spons.htm >GGF9 Participants (as of September 12): >http://www.globalgridforum.org/Meetings/ggf9/participants.htm >Exploring Chicago: >http://www.ci.chi.il.us/Tourism/ > >GGF Members Register NOW: Right Price and Guaranteed Room Rate; Meeting >with the CORE >international Grid COMMUNITY ; Learning through Workshops; Continue to >BE a part of the GRID action!! > >Contact membership@ggf.org if you've forgotten your Y2003 GGF Individual >Membership number!! > >See you in Chicago!! > >Clare Spartz >Director of Marketing and Membership >Global Grid Forum >work: +1.630.252.0924 >cell: +1.917.860-9126 >fax: +1.630-252-4466 >spartz@ggf.org > > > > > > > >Content-Type: APPLICATION/PDF; NAME="Astro-RG-charter.pdf" >Content-ID: >Content-Description: pdf >Content-Disposition: ATTACHMENT; FILENAME="Astro-RG-charter.pdf" > >Attachment converted: Macintosh HD:Astro-RG-charter.pdf (PDF /CARO) (000835EB) From owner-grid@eso.org Sat Sep 20 00:39:43 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JMZUUa027946 for ; Sat, 20 Sep 2003 00:35:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8JMZUSS027945 for grid-outgoing; Sat, 20 Sep 2003 00:35:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JMYLUa027565; Sat, 20 Sep 2003 00:34:22 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8JMYLI01660; Sat, 20 Sep 2003 00:34:21 +0200 (MEST) Received: from postal.sdsc.edu(132.249.20.114) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAdvaypd; Sat, 20 Sep 03 00:34:19 +0200 Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/62) id h8JMYF306217; Fri, 19 Sep 2003 15:34:15 -0700 (PDT) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu Message-Id: In-Reply-To: References: Date: Fri, 19 Sep 2003 14:59:43 -0700 To: Nicholas Walton From: Reagan Moore Subject: Re: GGF Astro BOF Cc: ivoa@ivoa.net, Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Nic: There are multiple grid related topics that would be worthwhile to mention at the GGF Astro BOF. The goal would be to identify which of the issues are of most interest, and then pursue a description for a GGF report. Examples are: - processing pipelines versus the Grid workflow environment (Chimera/Pegasus) - IVOA registries versus Grid metadata management systems (MCS, SRB) - Standard IVOA services versus grid service environment (WSDL/OGSA) - Image archive management systems versus grid data management systems (RLS, SRB) - long term preservation of image archives versus data grid-based persistent archives In each of these areas there is either a grid implementation or a GGF working group. We would like to understand how the IVOA requirements will impact ongoing development across these areas. Reagan Moore >Dear All, > >at the upcoming Global Grid Forum meeting in Chicago (5-8 Oct 2003) - see >www.ggf.org - there will be a Birds of a Feather session which starts of >the process of forming a Astronomy Research Group at the GGF. I attach the >draft charter to this message. > >This will give the Astro and IVOA VO communities a chance to input astro >requirements into the 'grid' standards process. > >I would encourage those of you interested in this area to aim to attend >this GGF meeting. Hope to see you there. (Note that early registration >closes sept 26.) > >Please forward this message to those that may be interested. > >Yours > >Nic Walton > >======================================================================== >Dr N. A. Walton >(AstroGrid Project Scientist) Tel: +44 1223 337503 >Institute of Astronomy FAX: +44 1223 337523 >University of Cambridge WWW: http://www.astrogrid.org >Madingley Road WWW: http://www.ast.cam.ac.uk/~naw >Cambridge, CB3 0HA email: naw@ast.cam.ac.uk >======================================================================== > > >----------- > >>From spartz@ggf.org Fri Sep 19 10:16:21 2003 >Date: Thu, 18 Sep 2003 13:38:01 -0500 >From: Clare Spartz >To: ggf-membership@ggf.org >Cc: membership@ggf.org >Subject: [ggf-membership] Just Over Two Weeks Away -- GGF9 - October 4-8 - > Chicago > >GGF9 - The Ninth Global Grid Forum >October 5-8, Chicago, IL USA >Chicago Sheraton Hotel and Towers > > >42 working groups and research groups gathering for 4 days working >together to build a standards-based foundation for Grid computing. > >Nine sessions will focus on finalizing proposed charters for new >working groups and research groups, including: > * Business Process Grid > * Configuration Description, Deployment, and Lifecycle >Management > * Workflow Management > * Grid API > >In addition to working sessions where community practices and >specifications are being developed, GGF9 will include four full-day >workshops: > * Designing and Building Grid Services (OGSA/OGSI teams) > * Life Sciences Grid (Applications and requirements for > bioinformatics, pharmaceuticals, etc.) > * Peer-to-Peer and Grids: Synergies and Opportunities > * Semantic Grid > > >***Important dates are approaching*** > >Advance Registration - available through September 26 - GGF MEMBERS >save MORE MONEY >http://www.globalgridforum.org/Meetings/ggf9/reg.htm >Hotel Availability - space and special GGF rate guaranteed through >September 26 >http://www.ggf.org/Meetings/ggf9/lodging.htm > >***GGF9 Schedule*** >http://www.globalgridforum.org/Meetings/ggf9/schedule.htm >Find "Click here to download the full GGF9 Schedule at a Glance" > > >The Complete List of Sessions/Workshops and BOFs: >WORKSHOPS = 4 > Designing and Building Grid Services, led by Ian Foster >et. al. > P2P and Grids: Synergies and Opportunities, led by >Andrew Chien et. al. > Semantic Grid Workshop, led by David de Roure et. al. > Life Sciences Grid Workshop, led by Abbas Farazdel >et.al. > >WG/RG SESSIONS = 56 > Grid Checkpoint Recovery (GridCPR-WG) > Grid Remote Procedure Call (GridRPC-WG) > Advanced Collaborative Environments (ACE-RG) > Applications and Test Beds (APPS-RG) > Grid Computing Environments (GCE-RG) > Grid User Services (GUS-RG) > Life Sciences Grid (LSG-RG) > Production Grid Management (PGM-RG) > User Program Development Tools for the Grid (UPDT-RG) > Open Grid Service Common Management Model (CMM-WG) > Open Grid Services Architecture (OGSA-WG) > Open Grid Services Infrastructure (OGSI-WG) > Grid Policy Architecture (Policy-RG) > Grid Protocol Architecture (GPA-RG) > Semantic Grid (SEM-RG) > Data Access and Integration Services (DAIS-WG) > Data Format Description Language (DFDL-WG) > GridFTP-WG > IPv6 (IPv6-WG) > OGSA Data Replication Services (OREP-WG) > Data Transport (DT-RG) > Grid High-Performance Networking (GHPN-RG) > Persistent Archives (PA-RG) > Authorization Frameworks and Mechanisms (AuthZ-WG) > CA Ops (CAOPs-WG) > Open Grid Service Architecture Authorization (OGSA >AUTHZ-WG) > Site Authentication, Authorization, and Accounting >Requirements (SAAA-RG) > CIM based Grid Schema (CGS-WG) > Network Measurement (NM-WG) > Grid Information Retrieval (GIR-WG) > Grid Benchmarking (GB-RG) > Relational Grid Information Services (RGIS-RG) > Appliance Aggregation (APPAGG-RG) > OGSA-P2P-Security (OGSAP2P-RG) > Distributed Resource Management Application API >(DRMAA-WG) > Grid Economic Services Architecture (GESA-WG) > Grid Resource Allocation Agreement Protocol (GRAAP-WG) > Job Submission Description Language (JSDL-WG) > OGSA Resource Usage Service (RUS-WG) > Usage Record (UR-WG) > Grid File Systems > > >BOF's = 9 > Astronomical Grid Community-RG > Grid Support for Ubiquitous Computing-RG > Grid Federations > Grid Scheduling Ontology-WG > Workflow Management-RG > Business Process Grid-WG > Metadata Management Services Architecture-WG > Grid API-WG > Configuration Description, Deployment, and Lifecycle >Management-WG > > >GGF Sponsors at GGF9: >http://www.globalgridforum.org/L_Involved_Sponsors/2003_spons.htm >GGF9 Participants (as of September 12): >http://www.globalgridforum.org/Meetings/ggf9/participants.htm >Exploring Chicago: >http://www.ci.chi.il.us/Tourism/ > >GGF Members Register NOW: Right Price and Guaranteed Room Rate; Meeting >with the CORE >international Grid COMMUNITY ; Learning through Workshops; Continue to >BE a part of the GRID action!! > >Contact membership@ggf.org if you've forgotten your Y2003 GGF Individual >Membership number!! > >See you in Chicago!! > >Clare Spartz >Director of Marketing and Membership >Global Grid Forum >work: +1.630.252.0924 >cell: +1.917.860-9126 >fax: +1.630-252-4466 >spartz@ggf.org > > > > > > > >Content-Type: APPLICATION/PDF; NAME="Astro-RG-charter.pdf" >Content-ID: >Content-Description: pdf >Content-Disposition: ATTACHMENT; FILENAME="Astro-RG-charter.pdf" > >Attachment converted: Macintosh HD:Astro-RG-charter.pdf (PDF /CARO) (000835EB) From owner-ivoa@eso.org Sat Sep 20 00:39:27 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JMYtUa027720 for ; Sat, 20 Sep 2003 00:34:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8JMYteI027718 for ivoa-outgoing; Sat, 20 Sep 2003 00:34:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ivoa@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JMYLUa027565; Sat, 20 Sep 2003 00:34:22 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8JMYLI01660; Sat, 20 Sep 2003 00:34:21 +0200 (MEST) Received: from postal.sdsc.edu(132.249.20.114) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAdvaypd; Sat, 20 Sep 03 00:34:19 +0200 Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/62) id h8JMYF306217; Fri, 19 Sep 2003 15:34:15 -0700 (PDT) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu Message-Id: In-Reply-To: References: Date: Fri, 19 Sep 2003 14:59:43 -0700 To: Nicholas Walton From: Reagan Moore Subject: Re: GGF Astro BOF Cc: ivoa@ivoa.net, Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ivoa@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Nic: There are multiple grid related topics that would be worthwhile to mention at the GGF Astro BOF. The goal would be to identify which of the issues are of most interest, and then pursue a description for a GGF report. Examples are: - processing pipelines versus the Grid workflow environment (Chimera/Pegasus) - IVOA registries versus Grid metadata management systems (MCS, SRB) - Standard IVOA services versus grid service environment (WSDL/OGSA) - Image archive management systems versus grid data management systems (RLS, SRB) - long term preservation of image archives versus data grid-based persistent archives In each of these areas there is either a grid implementation or a GGF working group. We would like to understand how the IVOA requirements will impact ongoing development across these areas. Reagan Moore >Dear All, > >at the upcoming Global Grid Forum meeting in Chicago (5-8 Oct 2003) - see >www.ggf.org - there will be a Birds of a Feather session which starts of >the process of forming a Astronomy Research Group at the GGF. I attach the >draft charter to this message. > >This will give the Astro and IVOA VO communities a chance to input astro >requirements into the 'grid' standards process. > >I would encourage those of you interested in this area to aim to attend >this GGF meeting. Hope to see you there. (Note that early registration >closes sept 26.) > >Please forward this message to those that may be interested. > >Yours > >Nic Walton > >======================================================================== >Dr N. A. Walton >(AstroGrid Project Scientist) Tel: +44 1223 337503 >Institute of Astronomy FAX: +44 1223 337523 >University of Cambridge WWW: http://www.astrogrid.org >Madingley Road WWW: http://www.ast.cam.ac.uk/~naw >Cambridge, CB3 0HA email: naw@ast.cam.ac.uk >======================================================================== > > >----------- > >>From spartz@ggf.org Fri Sep 19 10:16:21 2003 >Date: Thu, 18 Sep 2003 13:38:01 -0500 >From: Clare Spartz >To: ggf-membership@ggf.org >Cc: membership@ggf.org >Subject: [ggf-membership] Just Over Two Weeks Away -- GGF9 - October 4-8 - > Chicago > >GGF9 - The Ninth Global Grid Forum >October 5-8, Chicago, IL USA >Chicago Sheraton Hotel and Towers > > >42 working groups and research groups gathering for 4 days working >together to build a standards-based foundation for Grid computing. > >Nine sessions will focus on finalizing proposed charters for new >working groups and research groups, including: > * Business Process Grid > * Configuration Description, Deployment, and Lifecycle >Management > * Workflow Management > * Grid API > >In addition to working sessions where community practices and >specifications are being developed, GGF9 will include four full-day >workshops: > * Designing and Building Grid Services (OGSA/OGSI teams) > * Life Sciences Grid (Applications and requirements for > bioinformatics, pharmaceuticals, etc.) > * Peer-to-Peer and Grids: Synergies and Opportunities > * Semantic Grid > > >***Important dates are approaching*** > >Advance Registration - available through September 26 - GGF MEMBERS >save MORE MONEY >http://www.globalgridforum.org/Meetings/ggf9/reg.htm >Hotel Availability - space and special GGF rate guaranteed through >September 26 >http://www.ggf.org/Meetings/ggf9/lodging.htm > >***GGF9 Schedule*** >http://www.globalgridforum.org/Meetings/ggf9/schedule.htm >Find "Click here to download the full GGF9 Schedule at a Glance" > > >The Complete List of Sessions/Workshops and BOFs: >WORKSHOPS = 4 > Designing and Building Grid Services, led by Ian Foster >et. al. > P2P and Grids: Synergies and Opportunities, led by >Andrew Chien et. al. > Semantic Grid Workshop, led by David de Roure et. al. > Life Sciences Grid Workshop, led by Abbas Farazdel >et.al. > >WG/RG SESSIONS = 56 > Grid Checkpoint Recovery (GridCPR-WG) > Grid Remote Procedure Call (GridRPC-WG) > Advanced Collaborative Environments (ACE-RG) > Applications and Test Beds (APPS-RG) > Grid Computing Environments (GCE-RG) > Grid User Services (GUS-RG) > Life Sciences Grid (LSG-RG) > Production Grid Management (PGM-RG) > User Program Development Tools for the Grid (UPDT-RG) > Open Grid Service Common Management Model (CMM-WG) > Open Grid Services Architecture (OGSA-WG) > Open Grid Services Infrastructure (OGSI-WG) > Grid Policy Architecture (Policy-RG) > Grid Protocol Architecture (GPA-RG) > Semantic Grid (SEM-RG) > Data Access and Integration Services (DAIS-WG) > Data Format Description Language (DFDL-WG) > GridFTP-WG > IPv6 (IPv6-WG) > OGSA Data Replication Services (OREP-WG) > Data Transport (DT-RG) > Grid High-Performance Networking (GHPN-RG) > Persistent Archives (PA-RG) > Authorization Frameworks and Mechanisms (AuthZ-WG) > CA Ops (CAOPs-WG) > Open Grid Service Architecture Authorization (OGSA >AUTHZ-WG) > Site Authentication, Authorization, and Accounting >Requirements (SAAA-RG) > CIM based Grid Schema (CGS-WG) > Network Measurement (NM-WG) > Grid Information Retrieval (GIR-WG) > Grid Benchmarking (GB-RG) > Relational Grid Information Services (RGIS-RG) > Appliance Aggregation (APPAGG-RG) > OGSA-P2P-Security (OGSAP2P-RG) > Distributed Resource Management Application API >(DRMAA-WG) > Grid Economic Services Architecture (GESA-WG) > Grid Resource Allocation Agreement Protocol (GRAAP-WG) > Job Submission Description Language (JSDL-WG) > OGSA Resource Usage Service (RUS-WG) > Usage Record (UR-WG) > Grid File Systems > > >BOF's = 9 > Astronomical Grid Community-RG > Grid Support for Ubiquitous Computing-RG > Grid Federations > Grid Scheduling Ontology-WG > Workflow Management-RG > Business Process Grid-WG > Metadata Management Services Architecture-WG > Grid API-WG > Configuration Description, Deployment, and Lifecycle >Management-WG > > >GGF Sponsors at GGF9: >http://www.globalgridforum.org/L_Involved_Sponsors/2003_spons.htm >GGF9 Participants (as of September 12): >http://www.globalgridforum.org/Meetings/ggf9/participants.htm >Exploring Chicago: >http://www.ci.chi.il.us/Tourism/ > >GGF Members Register NOW: Right Price and Guaranteed Room Rate; Meeting >with the CORE >international Grid COMMUNITY ; Learning through Workshops; Continue to >BE a part of the GRID action!! > >Contact membership@ggf.org if you've forgotten your Y2003 GGF Individual >Membership number!! > >See you in Chicago!! > >Clare Spartz >Director of Marketing and Membership >Global Grid Forum >work: +1.630.252.0924 >cell: +1.917.860-9126 >fax: +1.630-252-4466 >spartz@ggf.org > > > > > > > >Content-Type: APPLICATION/PDF; NAME="Astro-RG-charter.pdf" >Content-ID: >Content-Description: pdf >Content-Disposition: ATTACHMENT; FILENAME="Astro-RG-charter.pdf" > >Attachment converted: Macintosh HD:Astro-RG-charter.pdf (PDF /CARO) (000835EB) From owner-grid@eso.org Mon Sep 22 20:30:16 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MIU4FD026561 for ; Mon, 22 Sep 2003 20:30:04 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MIU4cF026560 for grid-outgoing; Mon, 22 Sep 2003 20:30:04 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MITtFD026496 for ; Mon, 22 Sep 2003 20:29:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MITtvI026494 for ws-outgoing; Mon, 22 Sep 2003 20:29:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MITpFD026451 for ; Mon, 22 Sep 2003 20:29:51 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MITpV11951 for ; Mon, 22 Sep 2003 20:29:51 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA_daOvx; Mon, 22 Sep 03 20:29:49 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 6953145F5D; Mon, 22 Sep 2003 19:29:49 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 17207; Mon, 22 Sep 2003 19:29:49 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CF63745F5F; Mon, 22 Sep 2003 19:29:48 +0100 (BST) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 7495945F5D; Mon, 22 Sep 2003 19:29:48 +0100 (BST) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id h8MITme01994; Mon, 22 Sep 2003 19:29:48 +0100 Message-Id: <200309221829.h8MITme01994@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: Tim Naylor , ws@ivoa.net Subject: Re: Web Cone Searches Date: Mon, 22 Sep 2003 19:29:48 +0100 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.3 required=1000.0 tests=QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The cone search is a really simple search, put together so that database owners can publish their data as straightforwardly as possible as a web service. Other more comprehensive searches, such as those based on ADQL and so on, will cover everything anyone can possibly ask about anything. Or about 80% of it anyway. So what is the minimum set of things we need to handle to make the results accurate and usable? > 1) Epoch. If you change the epoch of a cone search the answer should > change, that's because some high proper motion objects will move through > the cone with time. So, a database with proper motions should accept and > use an epoch. A database without proper motions should return what epoch > the data refer to. Without this, cetrain science programmes will be > impossible (e.g. proper motion studies). The 'answer' here sounds like the querier wants the results to be given in the 'now' epoch. Whereas in both cases (db with and without proper motions) the publisher should provide the epochs for each object, and proper motions if they're available, and we get accurate and usable results... Presumably if proper motions are not available the publisher cannot re-epoch the results anyway? And proper motion studies would not be possible anyway? And if those *with* proper motions return them, then the science can be done at the client. > 2) Equinox really should be dealt with, and dealt with properly. Its all > very well to say "everything in the VO will be equinox 2000", but it seems > to me to be building in a serious limitation at an early stage. Folks > should be making the data available in what ever equinox is needed, and > then it should be converted (on the fly?) to what the user wants. If not, > how are we going to cope if there is another change such as that from > Besselian to Julian equinoxes? I can't see that using a particular one is a *limitation*, given the conversion can be made anywhere - no information is hidden or distorted because the query is in J2000, even if many years down the line a new origin is introduced. So should we say at the moment that the *results* are presented in whatever equinox they are stored in (and some metadata page describes this) to simplify the publishing process. And many years from now, if a new one is introduced and the cone search still exists, we can add that to the cone search if it still exists, leaving it's absence as defaulting to J2000. In summary, the cone search is a great 'starter' web service for people learning to publish data. I feel we should (if I haven't misunderstood and it does limit queries) keep it as simple as possible, and devote our efforts to the richer, more complex web interfaces for full services. (We can always build services 'in front of' services - so we could provide a standard front end cone search that takes any epoch/equinox, converts the query to the right values for a basic cone search, and converts the results to the given epoch/equinox before returning them. This gives us a layered approach, but is it worth it?) Cheers, Martin -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From owner-grid@eso.org Mon Sep 22 20:01:52 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MI1cFD013305 for ; Mon, 22 Sep 2003 20:01:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MI1c42013300 for grid-outgoing; Mon, 22 Sep 2003 20:01:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MI1YFD013273 for ; Mon, 22 Sep 2003 20:01:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MI1YJ3013272 for ws-outgoing; Mon, 22 Sep 2003 20:01:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Date: Mon, 22 Sep 2003 18:44:14 +0100 (BST) From: Tim Naylor To: ws@ivoa.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Tim Naylor X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > Okay, I'd like to bring up my current pet peeve about the NVO cone search > standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it > doesn't include either equinox or epoch. Let me add my take (as an astrophysicist) on this. 1) Epoch. If you change the epoch of a cone search the answer should change, that's because some high proper motion objects will move through the cone with time. So, a database with proper motions should accept and use an epoch. A database without proper motions should return what epoch the data refer to. Without this, cetrain science programmes will be impossible (e.g. proper motion studies). 2) Equinox really should be dealt with, and dealt with properly. Its all very well to say "everything in the VO will be equinox 2000", but it seems to me to be building in a serious limitation at an early stage. Folks should be making the data available in what ever equinox is needed, and then it should be converted (on the fly?) to what the user wants. If not, how are we going to cope if there is another change such as that from Besselian to Julian equinoxes? Tim -- ----------------------------------------------------------------------------- Prof. Tim Naylor, School of Physics, University of Exeter, Stocker Road, Exeter EX4 4QL E-mail: T.Naylor@exeter.ac.uk tel: 01392 264172 ----------------------------------------------------------------------------- From owner-grid@eso.org Tue Sep 23 06:20:19 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N4JrBi014702 for ; Tue, 23 Sep 2003 06:19:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N4Jr0v014701 for grid-outgoing; Tue, 23 Sep 2003 06:19:53 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N4J2Bi014531 for ; Tue, 23 Sep 2003 06:19:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N4J21T014530 for ws-outgoing; Tue, 23 Sep 2003 06:19:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N4IIBi014372 for ; Tue, 23 Sep 2003 06:18:29 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8N4IHI15277 for ; Tue, 23 Sep 2003 06:18:17 +0200 (MEST) Received: from unknown(211.167.66.198) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAARqaa1D; Tue, 23 Sep 03 06:18:06 +0200 Received: from RsProxy ([192.168.3.158]) by lamost.org (8.10.2/8.10.2) with SMTP id h8N4JUX03087 for ; Tue, 23 Sep 2003 12:19:30 +0800 Message-ID: <3F6FC99A.5050809@bao.ac.cn> Date: Tue, 23 Sep 2003 12:18:34 +0800 From: Chenzhou Cui User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-hk MIME-Version: 1.0 CC: IVOA Web Services List Subject: Re: ADASS discussions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Chenzhou Cui X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: > On Mon, 22 Sep 2003, Alasdair Allan wrote: > > ... > Recently, I'm beginning to wonder if OGSI is worth the bother. Here in Java > land, we're stuck with GT3 as the only implementation, which makes development > slow and difficult. Parastatidis et al. have questioned the usefulness of > OGSI as a standard, proposing an alternative that matches better to web > services standards. If we don't do OGSI now, I'm wondering if it will have > become obsolete by the time we need to exploit it. > >... I think it is suitable for a small VO project, such as China-VO, to focus its effort on one choice or just a few choices. We can adopt other technologies after they have been implemented successfully in other VO projects. What's more, the flag of Grid can absorb many eyes from IT community. It's very useful for VO development. > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 -- ============================================================ Chenzhou Cui National Astronomical Observatory | Tel: (8610)64877703-1328 Chinese Academy of Sciences | FAX: (8610)64878240 Datun Road 20A, Chaoyang District | Email: ccz@bao.ac.cn Beijing 100012, China | WWW: www.lamost.org/~cb ============================================================ From owner-grid@eso.org Tue Sep 23 09:13:59 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N7DXBi000356 for ; Tue, 23 Sep 2003 09:13:33 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N7DWEn000355 for grid-outgoing; Tue, 23 Sep 2003 09:13:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N7DLBi000312 for ; Tue, 23 Sep 2003 09:13:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N7DLZw000311 for ws-outgoing; Tue, 23 Sep 2003 09:13:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@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.6/8.12.6) with ESMTP id h8N7DABi000261; Tue, 23 Sep 2003 09:13:10 +0200 (MEST) Received: from arclux2.hq.eso.org (pc003189.hq.eso.org [134.171.3.55]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id h8N7DAx24534; Tue, 23 Sep 2003 09:13:10 +0200 (MEST) From: Andreas Wicenec Organization: European Southern Observatory To: Martin Hill , Tim Naylor , ws@ivoa.net Subject: Re: Web Cone Searches Date: Tue, 23 Sep 2003 09:13:09 +0200 User-Agent: KMail/1.5.1 References: <200309221829.h8MITme01994@fannich.roe.ac.uk> In-Reply-To: <200309221829.h8MITme01994@fannich.roe.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309230913.09401.awicenec@eso.org> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andreas Wicenec X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I totally agree with Martin's view, even more so because we can see that a lot of people are doing some quite advanced science programs using the very simple access we are providing to our catalogues and the DSS1 and DSS2. Also from the user point of view a simple access is much easier to go along. Of course the information returned has to be complete and suited to the science case. On the other hand carrying out scientific reduction using services offered by the providers directly is a very convenient and fast way to do at least basic things like epoch and equinox calculations or the basic calibration of images and spectra. Cheers, Andreas On Monday 22 September 2003 20:29, Martin Hill wrote: > The cone search is a really simple search, put together so that database > owners can publish their data as straightforwardly as possible as a web > service. Other more comprehensive searches, such as those based on ADQL > and so on, will cover everything anyone can possibly ask about anything. > Or about 80% of it anyway. > > So what is the minimum set of things we need to handle to make the results > accurate and usable? > > > 1) Epoch. If you change the epoch of a cone search the answer should > > change, that's because some high proper motion objects will move through > > the cone with time. So, a database with proper motions should accept and > > use an epoch. A database without proper motions should return what epoch > > the data refer to. Without this, cetrain science programmes will be > > impossible (e.g. proper motion studies). > > The 'answer' here sounds like the querier wants the results to be given in > the 'now' epoch. Whereas in both cases (db with and without proper > motions) the publisher should provide the epochs for each object, and > proper motions if they're available, and we get accurate and usable > results... Presumably if proper motions are not available the publisher > cannot re-epoch the results anyway? And proper motion studies would not be > possible anyway? And if those *with* proper motions return them, then the > science can be done at the client. > > > 2) Equinox really should be dealt with, and dealt with properly. Its all > > very well to say "everything in the VO will be equinox 2000", but it > > seems to me to be building in a serious limitation at an early stage. > > Folks should be making the data available in what ever equinox is needed, > > and then it should be converted (on the fly?) to what the user wants. If > > not, how are we going to cope if there is another change such as that > > from Besselian to Julian equinoxes? > > I can't see that using a particular one is a *limitation*, given the > conversion can be made anywhere - no information is hidden or distorted > because the query is in J2000, even if many years down the line a new > origin is introduced. So should we say at the moment that the *results* > are presented in whatever equinox they are stored in (and some metadata > page describes this) to simplify the publishing process. And many years > from now, if a new one is introduced and the cone search still exists, we > can add that to the cone search if it still exists, leaving it's absence as > defaulting to J2000. > > In summary, the cone search is a great 'starter' web service for people > learning to publish data. I feel we should (if I haven't misunderstood and > it does limit queries) keep it as simple as possible, and devote our > efforts to the richer, more complex web interfaces for full services. > > (We can always build services 'in front of' services - so we could provide > a standard front end cone search that takes any epoch/equinox, converts the > query to the right values for a basic cone search, and converts the results > to the given epoch/equinox before returning them. This gives us a layered > approach, but is it worth it?) > > Cheers, > > Martin From owner-grid@eso.org Tue Sep 23 11:32:58 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9WIve028716 for ; Tue, 23 Sep 2003 11:32:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N9WItZ028711 for grid-outgoing; Tue, 23 Sep 2003 11:32:18 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9Vkve028358 for ; Tue, 23 Sep 2003 11:31:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N9VkqG028354 for ws-outgoing; Tue, 23 Sep 2003 11:31:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9VHve028022; Tue, 23 Sep 2003 11:31:17 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8N9VGH02792; Tue, 23 Sep 2003 11:31:16 +0200 (MEST) Received: from brown.csi.cam.ac.uk(131.111.8.14) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA1Na4Cf; Tue, 23 Sep 03 11:31:15 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1jVp-0003lQ-VY; Tue, 23 Sep 2003 10:31:13 +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.9+Sun/8.12.9) with ESMTP id h8N9VDZC018347; Tue, 23 Sep 2003 10:31:13 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8N9VDsj020038; Tue, 23 Sep 2003 10:31:13 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8N9VD6c020035; Tue, 23 Sep 2003 10:31:13 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 23 Sep 2003 10:31:13 +0100 (BST) From: Guy Rixon To: Andreas Wicenec cc: Martin Hill , Tim Naylor , ws@ivoa.net Subject: Re: Web Cone Searches In-Reply-To: <200309230913.09401.awicenec@eso.org> Message-ID: References: <200309221829.h8MITme01994@fannich.roe.ac.uk> <200309230913.09401.awicenec@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: OK...I think there's a general principle up for debate here. If job X, which has many variations and parameters in its general form, can be done either by a general ADQL service, or by a specialized, simpler service on the same data, is it required that the specialized service cover the general form of X, or can the general form be deferred to the ADQL service. In this case, if I want cone search for B1950 positions, with known epochs and PMs, must the cone-search service support this, or must I go to the ADQL service? (In this case, I'm considering the cone-search service to be "Cone Search 2: the Web Service", not a revision to the CGI-based services.) On Tue, 23 Sep 2003, Andreas Wicenec wrote: > Hi, > > I totally agree with Martin's view, even more so because we can see that a lot > of people are doing some quite advanced science programs using the very > simple access we are providing to our catalogues and the DSS1 and DSS2. Also > from the user point of view a simple access is much easier to go along. Of > course the information returned has to be complete and suited to the science > case. > > On the other hand carrying out scientific reduction using services offered by > the providers directly is a very convenient and fast way to do at least basic > things like epoch and equinox calculations or the basic calibration of images > and spectra. > > Cheers, > Andreas > > On Monday 22 September 2003 20:29, Martin Hill wrote: > > The cone search is a really simple search, put together so that database > > owners can publish their data as straightforwardly as possible as a web > > service. Other more comprehensive searches, such as those based on ADQL > > and so on, will cover everything anyone can possibly ask about anything. > > Or about 80% of it anyway. > > > > So what is the minimum set of things we need to handle to make the results > > accurate and usable? > > > > > 1) Epoch. If you change the epoch of a cone search the answer should > > > change, that's because some high proper motion objects will move through > > > the cone with time. So, a database with proper motions should accept and > > > use an epoch. A database without proper motions should return what epoch > > > the data refer to. Without this, cetrain science programmes will be > > > impossible (e.g. proper motion studies). > > > > The 'answer' here sounds like the querier wants the results to be given in > > the 'now' epoch. Whereas in both cases (db with and without proper > > motions) the publisher should provide the epochs for each object, and > > proper motions if they're available, and we get accurate and usable > > results... Presumably if proper motions are not available the publisher > > cannot re-epoch the results anyway? And proper motion studies would not be > > possible anyway? And if those *with* proper motions return them, then the > > science can be done at the client. > > > > > 2) Equinox really should be dealt with, and dealt with properly. Its all > > > very well to say "everything in the VO will be equinox 2000", but it > > > seems to me to be building in a serious limitation at an early stage. > > > Folks should be making the data available in what ever equinox is needed, > > > and then it should be converted (on the fly?) to what the user wants. If > > > not, how are we going to cope if there is another change such as that > > > from Besselian to Julian equinoxes? > > > > I can't see that using a particular one is a *limitation*, given the > > conversion can be made anywhere - no information is hidden or distorted > > because the query is in J2000, even if many years down the line a new > > origin is introduced. So should we say at the moment that the *results* > > are presented in whatever equinox they are stored in (and some metadata > > page describes this) to simplify the publishing process. And many years > > from now, if a new one is introduced and the cone search still exists, we > > can add that to the cone search if it still exists, leaving it's absence as > > defaulting to J2000. > > > > In summary, the cone search is a great 'starter' web service for people > > learning to publish data. I feel we should (if I haven't misunderstood and > > it does limit queries) keep it as simple as possible, and devote our > > efforts to the richer, more complex web interfaces for full services. > > > > (We can always build services 'in front of' services - so we could provide > > a standard front end cone search that takes any epoch/equinox, converts the > > query to the right values for a basic cone search, and converts the results > > to the given epoch/equinox before returning them. This gives us a layered > > approach, but is it worth it?) > > > > Cheers, > > > > Martin > 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-grid@eso.org Tue Sep 23 12:51:13 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NAp29A000868 for ; Tue, 23 Sep 2003 12:51:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8NAp2K8000862 for grid-outgoing; Tue, 23 Sep 2003 12:51:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NAof9A000740 for ; Tue, 23 Sep 2003 12:50:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8NAofJG000737 for ws-outgoing; Tue, 23 Sep 2003 12:50:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NAoG9A000592 for ; Tue, 23 Sep 2003 12:50:16 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8NAoG908050 for ; Tue, 23 Sep 2003 12:50:16 +0200 (MEST) Received: from purple.csi.cam.ac.uk(131.111.8.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAlYaiUp; Tue, 23 Sep 03 12:50:15 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1kkH-00033b-An; Tue, 23 Sep 2003 11:50:13 +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.9+Sun/8.12.9) with ESMTP id h8NAoCZC021122; Tue, 23 Sep 2003 11:50:12 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8NAoCsj020260; Tue, 23 Sep 2003 11:50:12 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8NAoC0u020257; Tue, 23 Sep 2003 11:50:12 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 23 Sep 2003 11:50:12 +0100 (BST) From: Guy Rixon To: Tim Naylor cc: ws@ivoa.net Subject: Re: your mail In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 22 Sep 2003, Tim Naylor wrote: > > Okay, I'd like to bring up my current pet peeve about the NVO cone search > > standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it > > doesn't include either equinox or epoch. > > Let me add my take (as an astrophysicist) on this. > > 1) Epoch. If you change the epoch of a cone search the answer should > change, that's because some high proper motion objects will move through > the cone with time. So, a database with proper motions should accept and > use an epoch. A database without proper motions should return what epoch > the data refer to. Without this, cetrain science programmes will be > impossible (e.g. proper motion studies). What should a DB without proper motions do? Reject the query? Do a best-efforts approximation of the results? > 2) Equinox really should be dealt with, and dealt with properly. Its all > very well to say "everything in the VO will be equinox 2000", but it seems > to me to be building in a serious limitation at an early stage. Folks > should be making the data available in what ever equinox is needed, and > then it should be converted (on the fly?) to what the user wants. If not, > how are we going to cope if there is another change such as that from > Besselian to Julian equinoxes? This is maybe getting a bit off-topic. Do we, the services group, want to specify cone-search-as-a-web-service, or is that the job of another IVOA group, such as DAL? I _would_ like to explore the general principle of what to do when a resource can't answer a query exactly as phrased. Is it acceptable to return an approximate answer (e.g. assume zero proper motion if no proper motions are known)? If so, how would we inform the "user" of the approximation, and how might the user limit the approximations made in the processing? 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-grid@eso.org Tue Sep 23 14:37:23 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NA3RxE012883 for ; Tue, 23 Sep 2003 12:03:27 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8NA3R6N012882 for grid-outgoing; Tue, 23 Sep 2003 12:03:27 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NA390i012617 for ; Tue, 23 Sep 2003 12:03:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N9taEv010496 for ws-outgoing; Tue, 23 Sep 2003 11:55:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9smve010224 for ; Tue, 23 Sep 2003 11:54:48 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8N9sm104311 for ; Tue, 23 Sep 2003 11:54:48 +0200 (MEST) Received: from unknown(211.167.66.198) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAr6aqzi; Tue, 23 Sep 03 11:54:33 +0200 Received: from RsProxy ([192.168.3.158]) by lamost.org (8.10.2/8.10.2) with SMTP id h8N9tqX04362; Tue, 23 Sep 2003 17:55:52 +0800 Message-ID: <3F70186F.5010307@bao.ac.cn> Date: Tue, 23 Sep 2003 17:54:55 +0800 From: Chenzhou Cui User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-hk MIME-Version: 1.0 To: Guy Rixon CC: IVOA Web Services List Subject: Re: ADASS discussions References: <3F6FC99A.5050809@bao.ac.cn> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Chenzhou Cui X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: hi. Guy, I am sorry for my misunderstanding of your words. Maybe it is too early to decide whether OGSI services become _mandatory_ for any part of IVOA. Cheers, Chenzhou Guy Rixon wrote: > On Tue, 23 Sep 2003, Chenzhou Cui wrote: > > >>Guy Rixon wrote: >> >> >>>On Mon, 22 Sep 2003, Alasdair Allan wrote: >>> >>>... >>>Recently, I'm beginning to wonder if OGSI is worth the bother. Here in Java >>>land, we're stuck with GT3 as the only implementation, which makes development >>>slow and difficult. Parastatidis et al. have questioned the usefulness of >>>OGSI as a standard, proposing an alternative that matches better to web >>>services standards. If we don't do OGSI now, I'm wondering if it will have >>>become obsolete by the time we need to exploit it. >>> >>>... >> >>I think it is suitable for a small VO project, such as China-VO, to >>focus its effort on one choice or just a few choices. We can adopt other >>technologies after they have been implemented successfully in other VO >>projects. > > > China-VO can do whatever works best internally, of course. We wouldn't dream > to trying to stop you using OGSI. However, we need to decide whether OGSI > services become _mandatory_ for any part of IVOA. I.e., to connect a > hypothetical Xxx-VO to the global Virtual Observatory, do the Xxx-VO people > _have_ to add some OGSI services, or can they do it all with "standard" web > services? > > > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 -- ============================================================ Chenzhou Cui National Astronomical Observatory | Tel: (8610)64877703-1328 Chinese Academy of Sciences | FAX: (8610)64878240 Datun Road 20A, Chaoyang District | Email: ccz@bao.ac.cn Beijing 100012, China | WWW: www.lamost.org/~cb ============================================================ From owner-grid@eso.org Tue Sep 23 14:37:26 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NA3SxE012889 for ; Tue, 23 Sep 2003 12:03:28 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8NA3So8012887 for grid-outgoing; Tue, 23 Sep 2003 12:03:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NA3B0U012635 for ; Tue, 23 Sep 2003 12:03:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N9Nkj8023519 for ws-outgoing; Tue, 23 Sep 2003 11:23:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9MSve023021 for ; Tue, 23 Sep 2003 11:22:28 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8N9MRU02089 for ; Tue, 23 Sep 2003 11:22:27 +0200 (MEST) Received: from brown.csi.cam.ac.uk(131.111.8.14) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAFFaafe; Tue, 23 Sep 03 11:22:26 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1jNF-0002Zb-K4; Tue, 23 Sep 2003 10:22:21 +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.9+Sun/8.12.9) with ESMTP id h8N9MKZC017881; Tue, 23 Sep 2003 10:22:21 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8N9MKsj019988; Tue, 23 Sep 2003 10:22:20 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8N9MJU2019985; Tue, 23 Sep 2003 10:22:20 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 23 Sep 2003 10:22:19 +0100 (BST) From: Guy Rixon To: Chenzhou Cui cc: IVOA Web Services List Subject: Re: ADASS discussions In-Reply-To: <3F6FC99A.5050809@bao.ac.cn> Message-ID: References: <3F6FC99A.5050809@bao.ac.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 23 Sep 2003, Chenzhou Cui wrote: > > Guy Rixon wrote: > > > On Mon, 22 Sep 2003, Alasdair Allan wrote: > > > > ... > > Recently, I'm beginning to wonder if OGSI is worth the bother. Here in Java > > land, we're stuck with GT3 as the only implementation, which makes development > > slow and difficult. Parastatidis et al. have questioned the usefulness of > > OGSI as a standard, proposing an alternative that matches better to web > > services standards. If we don't do OGSI now, I'm wondering if it will have > > become obsolete by the time we need to exploit it. > > > >... > > I think it is suitable for a small VO project, such as China-VO, to > focus its effort on one choice or just a few choices. We can adopt other > technologies after they have been implemented successfully in other VO > projects. China-VO can do whatever works best internally, of course. We wouldn't dream to trying to stop you using OGSI. However, we need to decide whether OGSI services become _mandatory_ for any part of IVOA. I.e., to connect a hypothetical Xxx-VO to the global Virtual Observatory, do the Xxx-VO people _have_ to add some OGSI services, or can they do it all with "standard" web services? > What's more, the flag of Grid can absorb many eyes from IT community. > It's very useful for VO development. I see your point, but actually I doubt if we'll get that many eyes on OGSI. It can go two ways. Firstly, all of e-Science (outside our VO movement) picks up on OGSI, and a part of the IT industry too. That way, we get scrutiny by many eyes and lots of product to use. Secondly, only the super-computer community continues with OGSI (because they use it to build compute grids), other scientists don't adopt it, and the industry forgets it. That way, we get no proper product and no eyes on the residual code-base. I don't think OGSI, in its current form, is going to become common and long-lived in science. I think that industry will side-step it and that later science projects (e.g. biologists) will use the industry-standard techniques. Sad, but true IMHO. Remember, if the only eyes on OGSI are inside the VO movement, then we're paying heavily to support aomebody else's ideas and 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-grid@eso.org Fri Sep 19 11:51:30 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8J9pF5x024356 for ; Fri, 19 Sep 2003 11:51:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8J9pFH0024355 for grid-outgoing; Fri, 19 Sep 2003 11:51:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8J9p85x024297 for ; Fri, 19 Sep 2003 11:51:09 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8J9p8X2024296 for ws-outgoing; Fri, 19 Sep 2003 11:51:08 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8J9p55x024281 for ; Fri, 19 Sep 2003 11:51:05 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8J9p5x17721 for ; Fri, 19 Sep 2003 11:51:05 +0200 (MEST) Received: from rose.csi.cam.ac.uk(131.111.8.13) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAQVaaNI; Fri, 19 Sep 03 11:51:04 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A0Hub-0002gd-4m for ws@eso.org; Fri, 19 Sep 2003 10:50:49 +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.9+Sun/8.12.9) with ESMTP id h8J9omZC025994 for ; Fri, 19 Sep 2003 10:50:48 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8J9omsj014729 for ; Fri, 19 Sep 2003 10:50:48 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8J9omTn014726 for ; Fri, 19 Sep 2003 10:50:48 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 19 Sep 2003 10:50:48 +0100 (BST) From: Guy Rixon To: ws@eso.org Subject: Test: please ignore Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: 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 - Tue Jul 1 22:08:21 2003 X-UIDL: 3e5baf6500001413 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h61K5pG0022857 for ; Tue, 1 Jul 2003 22:05:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h61K5pLg022856 for ws-outgoing; Tue, 1 Jul 2003 22:05:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h61K5lG0022832 for ; Tue, 1 Jul 2003 22:05:47 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h61K5lU04141 for ; Tue, 1 Jul 2003 22:05:47 +0200 (MEST) Received: from newb6.u-strasbg.fr(130.79.128.16) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAosaGfi; Tue, 1 Jul 03 22:05:46 +0200 Received: (from nobody@localhost) by newb6.u-strasbg.fr (8.9.3/8.9.3) id WAA12202 for ws@ivoa.net; Tue, 1 Jul 2003 22:05:31 +0200 (MET DST) X-Authentication-Warning: newb6.u-strasbg.fr: nobody set sender to schaaff@astro.u-strasbg.fr using -f To: ws@ivoa.net Subject: Web Services at CDS Message-ID: <1057089931.3f01e98b130ce@astro.u-strasbg.fr> Date: Tue, 01 Jul 2003 22:05:31 +0200 (MET DST) From: Andre Schaaff MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-MIME-Autoconverted: from 8bit to quoted-printable by newb6.u-strasbg.fr id WAA12202 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h61K5oG0022853 Sender: owner-ws@eso.org Precedence: bulk Reply-To: Andre Schaaff Status: Hello, As said during the Cambridge Web Service meeting in May, if somebody needs an access to CDS resources through Web Services, we will study all propositions. So all replies are welcome. Regards, André From - Tue May 20 18:29:11 2003 X-UIDL: 3e5baf6500000a6f X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4KGTpC6016917; Tue, 20 May 2003 18:29:51 +0200 (MEST) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h4KGUQL29853; Tue, 20 May 2003 18:30:26 +0200 (MEST) Message-ID: <3ECA57CF.8070506@eso.org> Date: Tue, 20 May 2003 18:29:03 +0200 From: Markus Dolensky Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en, de-AT MIME-Version: 1.0 To: Clive Page CC: ws@ivoa.net, twiki@ivoa.net Subject: Web Service & WG status Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Dear Clive, since the Web Service discussion forum has been promoted to an IVOA working group under your guidance it has got - like all WGs - a collaborative page (http://www.ivoa.net/twiki/bin/view/IVOA/IvoaWebServices) and mailing list . This mailing list itself is now a subscriber of which is the list for general postings to all the WGs (incl. the IVOA exec comprised of VO project managers). Markus +--- | Markus Dolensky Mailto:Markus.Dolensky@eso.org | AVO Technical Lead Web: www.euro-vo.org | Voice: ++49 89 32006/261 Fax: ++49 89 32006/480 +--- From - Mon May 19 18:20:18 2003 X-UIDL: 3e5baf6500000a1f X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4JGJWG1000850 for ; Mon, 19 May 2003 18:19:32 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4JGJWM01440 for ; Mon, 19 May 2003 18:19:32 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAiRaWZc; Mon, 19 May 03 18:19:31 +0200 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h4JGIFHT034773 for ; Mon, 19 May 2003 18:18:15 +0200 (CEST) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id h4JGMsA20671 for ; Mon, 19 May 2003 18:22:54 +0200 (MEST) Message-ID: <3EC904E2.473D9194@astro.u-strasbg.fr> Date: Mon, 19 May 2003 18:22:58 +0200 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ws@ivoa.net" Subject: News services Content-Type: multipart/mixed; boundary="------------75FB317349E4CAB8FB4E88A4" X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------75FB317349E4CAB8FB4E88A4 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JGIFHT034773 Hello, The UCD resolver will be available as a Web Service. I will send you a mail as soon as it will be available. Regards, Andr=E9 --------------75FB317349E4CAB8FB4E88A4 Content-Type: text/x-vcard; charset=us-ascii; name="schaaff.vcf" Content-Description: Card for Andre Schaaff Content-Disposition: attachment; filename="schaaff.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JGIFHT034773 begin:vcard=20 n:Schaaff;Andr=E9 x-mozilla-html:FALSE url:http://cdsweb.u-strasbg.fr org:Observatoire Astronomique;CDS adr:;;11, rue de l'Universit=E9;Strasbourg;;67000;France version:2.1 fn:Andr=E9 Schaaff end:vcard --------------75FB317349E4CAB8FB4E88A4-- From - Mon May 19 15:50:18 2003 X-UIDL: 3e5baf6500000a14 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4JDo0G1001872 for ; Mon, 19 May 2003 15:50:00 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4JDnxW22082 for ; Mon, 19 May 2003 15:49:59 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAfnaiiR; Mon, 19 May 03 15:49:58 +0200 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h4JDmhHT028579 for ; Mon, 19 May 2003 15:48:43 +0200 (CEST) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id h4JDrMA20994 for ; Mon, 19 May 2003 15:53:22 +0200 (MEST) Message-ID: <3EC8E1D6.68F154F7@astro.u-strasbg.fr> Date: Mon, 19 May 2003 15:53:26 +0200 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ws@ivoa.net Subject: CDS Web Services Content-Type: multipart/mixed; boundary="------------A14CAEFEF0B5EBECA4A0D3DA" X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------A14CAEFEF0B5EBECA4A0D3DA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JDmhHT028579 Hello, The Web Services portal link is available on the CDS webpage : http://cdsweb.u-strasbg.fr/ Andr=E9 --------------A14CAEFEF0B5EBECA4A0D3DA Content-Type: text/x-vcard; charset=us-ascii; name="schaaff.vcf" Content-Description: Card for Andre Schaaff Content-Disposition: attachment; filename="schaaff.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JDmhHT028579 begin:vcard=20 n:Schaaff;Andr=E9 x-mozilla-html:FALSE url:http://cdsweb.u-strasbg.fr org:Observatoire Astronomique;CDS adr:;;11, rue de l'Universit=E9;Strasbourg;;67000;France version:2.1 fn:Andr=E9 Schaaff end:vcard --------------A14CAEFEF0B5EBECA4A0D3DA-- From - Thu May 15 02:40:08 2003 X-UIDL: 3e5baf650000099c X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4F0detj027246 for ; Thu, 15 May 2003 02:39:40 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4F0der05828 for ; Thu, 15 May 2003 02:39:40 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAplayyl; Thu, 15 May 03 02:39:39 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 19G6lL-00RYMJ-2O for ws@ivoa.net; Thu, 15 May 2003 01:38:23 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Thu, 15 May 2003 01:38:21 +0100 Date: Thu, 15 May 2003 01:38:21 +0100 (BST) From: Alasdair Allan To: IVOA WebServices List cc: Alasdair Allan Subject: Perl Cookie Daemon Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: As requested after the WebServices session at the IVOA meeting, I've attached a tarball containing some sample Perl code to do authenticated SOAP requests, using SOAP cookies, to my Wiki users page see http://www.ivoa.net/twiki/bin/view/IVOA/AlasdairAllan You'll need Perl 5.8.0 compiled with "ithreads" enabled, SOAP::Lite and BerkelyDB along with the associated DB_File Perl module (see CPAN), but I can't recall any other dependancies. The CookieDaemon module sits ontop of the Daemon.pm module, but there isn't any reason why this code is Transport specific, you could equally easilly sit it ontop of one of the other Transport modules. Additonally, I don't see why the module could be (easily?) modified to pass certificates, and hence become the building block of an OGSI Perl module. Al. From - Thu Mar 20 20:55:41 2003 X-UIDL: 3e5baf6500000284 X-Mozilla-Status: 9001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h2KJssHA008234; Thu, 20 Mar 2003 20:54:54 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h2KJsrd04023; Thu, 20 Mar 2003 20:54:53 +0100 (MET) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAryaW2h; Thu, 20 Mar 03 20:54:52 +0100 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h2KJro803190; Thu, 20 Mar 2003 14:53:50 -0500 Date: Thu, 20 Mar 2003 14:53:50 -0500 From: "Wil O'Mullane" To: registry@us-vo.org, interop@ivoa.net, ws@ivoa.net, metadata@us-vo.op Subject: WebServices/ DIME in Java Message-ID: <20030320145350.E24599@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: As you may know there are several web services availabel at JHU - we have started to try to list them here http://skyservice.pha.jhu.edu/develop/vo/ We have also developed a DIME service to return SDSS images and a java clinet which consumes this service. The java client was running on linux showing interoperability of DIME attachments (the server is a .NET service on a windows machine). The client was developed using AXIS (which is free). Here is a link to the code and some information for anyone who would like to try it. http://skyservice.pha.jhu.edu/develop/vo/imgcutoutclient.html Of course feel free to mail me directly for further information/discussion. Also appologies for the cross post. wil From - Sat Feb 22 23:54:03 2003 X-UIDL: 3df25b31000009af X-Mozilla-Status: 9001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1MMp4o3005288 for ; Sat, 22 Feb 2003 23:51:08 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1MMp4414950 for ; Sat, 22 Feb 2003 23:51:04 +0100 (MET) Received: from rings.gsfc.nasa.gov(128.183.190.139) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAWJaGmD; Sat, 22 Feb 03 23:51:03 +0100 Received: from rings.gsfc.nasa.gov (rings.gsfc.nasa.gov [128.183.190.139]) by rings.gsfc.nasa.gov (8.9.3/8.9.3) with SMTP id RAA17165; Sat, 22 Feb 2003 17:47:16 -0500 (EST) Message-Id: <200302222247.RAA17165@rings.gsfc.nasa.gov> Date: Sat, 22 Feb 2003 17:47:16 -0500 (EST) From: Kirk Borne Reply-To: Kirk Borne Subject: WWW 2003 Workshop on E-Services and the Semantic Web (fwd) To: gswsg@listserv.gsfc.nasa.gov, adec@stsci.edu, ws@ivoa.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bWQpVamgEU11O0+XFnKqww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: ---------- Forwarded message ---------- Date: Fri, 21 Feb 2003 13:52:04 -0600 From: Mike Wilde To: all@griphyn.org Subject: WWW 2003 Workshop on E-Services and the Semantic Web CALL FOR PAPERS WWW 2003 Workshop on E-Services and the Semantic Web Budapest, Hungary Tuesday, May 20, 2003 Workshop Co-Chairs: Fabio Casati (Hewlett-Packard Labs, Palo Alto, USA), E-mail: fabio_casati@hp.com Dimitris Plexousakis (ICS-FORTH and University of Crete, Greece) E-mail: dp@ics.forth.gr Workshop web page: http://www.ics.forth.gr/isl/essw2003/ Theme of the Workshop --------------------- Two important trends are emerging in the World Wide Web. The first is the proliferation of electronic services (e-services) and in particular of Web services. The second is the emergence of the so-called "Semantic Web". The confluence of these trends forms the basis for this workshop. The application of Semantic Web technologies to e-services requires the specification of service capabilities and behaviors. Such descriptions will enable the automation of a variety of tasks, including e-service discovery, invocation, composition and interoperation. The upcoming technology of electronic services enables the development and deployment of loosely coupled, interoperable, distributed, heterogeneous systems. These will help establish relationships amongst service providers, customers and intermediaries more rapidly and with reduced setup time and cost. The industry has provided the initial building blocks for programmatic access to e-services, through standards such as UDDI, WSDL, ebXML, BPEL and SOAP, and through e-service platforms such as WebLogic, .Net and WebSphere. Nevertheless, many issues remain largely unresolved. In particular, many of the initial goals of the early e-service and Semantic Web visionaries, such as dynamic discovery, binding, and composition of e-services as well as their secure and reliable execution, are yet to be reached. The resolution of these issues, possibly through the provision of machine-interpretable e-service descriptions through the emergence of the Semantic Web, could enable fundamentally new approaches to finding, assembling, executing, and monitoring e-services. Workshop Topics and Objectives ----------------------------- The "E-Services and the Semantic Web" workshop will provide a forum for presentation and discussion of theoretical foundations, computational techniques, and emerging systems technologies for e-service description, discovery, and composition. This will include investigation of e-services issues in: - the application of the Semantic Web paradigm to e-services - workflow and distributed systems (e.g., process models for e-services, transactional properties, security, optimization) - AI (e.g., knowledge representation and reasoning, ontologies, planning, and verification) - databases (e.g., metadata, data management) The workshop will also address principled applications of these technologies in areas such as e-commerce, e-business, health care, scientific computing, education, and e-government. The following is a non-exhaustive list of topics of interest to the workshop: Formal Models and Languages for Service Description Process Models for Composite Services Service Descriptions and Ontologies Service Registration, Discovery, and Selection Service Assembly, Interoperation, and Re-use Execution and Monitoring of Composite Services Reasoning about Services and Composite Services Verification, Proof and Trust Agents Personalization and Preference Languages Security Cross-enterprise service interoperation Transactional Aspects Performance Aspects Distributed and Ambient Computing Database Services for the Semantic Web Business and Payment Models Standards Applications in Business, Education, Healthcare, Science, Government Paper Submission and Review -------------------------- Papers should be submitted via email to the workshop co-chairs (fabio_casati@hp.com, dp@ics.forth.gr). Papers submitted to the workshop will undergo a peer-review process overseen by the program committee co-chairs. Each paper will be reviewed by three program commitee members. Accepted papers will appear in informal electronic and/or printed proceedings that will be made available prior to the workshop. Selected workshop papers will possibly be invited for inclusion in a special issue of an international journal. Papers should not exceed 5000 words (approximately 12 pages) in length and must be submitted in Postscript or PDF. Short papers (up to 6 pages) describing early research results are also welcome. Important Dates --------------- Deadline of electronic submission: March 10, 2003 Author notification: April 14, 2003 Workshop: May 20, 2003 Workshop Program Committee: Gustavo Alonso (ETH Zurich) Boualem Benatallah (Univ. of South Wales) Bernard Burg (Hewlett-Packard Corp.) Chris Bussler (Oracle Corp., USA) Vassilis Christophides (ICS-FORTH, Greece) Sara Comai (Politecnico di Milano, Italy) Jonathan Dale (Fujitsu Labs of America, USA) Asuman Dogac (Middle East Technical University, Turkey) Alon Halevy (Univ. of Washington, USA) Sheila McIlraith (Stanford University, USA) Peter Patel-Schneider (Bell Labs, USA) Barbara Pernici (Politechnico Di Milano, Italy) Jerome Simeon (Bell Labs, USA) Mike Wilde (Argonne National Laboratory, USA) Steven Willmott (Universitat Politecnica de Catalunya, Spain) Workshop Steering Committee: Fabio Casati (Hewlett-Packard) Vassilis Christophides (ICS-FORTH Crete, Greece) Rick Hull (Lucent) Sheila McIlraith (Stanford University) Dimitris Plexousakis (University of Crete, Greece) ------------- End Forwarded Message ------------- From - Fri Feb 21 09:59:00 2003 X-UIDL: 3df25b3100000979 X-Mozilla-Status: 9001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1L8uW2v001684 for ; Fri, 21 Feb 2003 09:56:32 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1L8uV828906 for ; Fri, 21 Feb 2003 09:56:31 +0100 (MET) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAiiaiD4; Fri, 21 Feb 03 09:56:31 +0100 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.3/jtpda-5.4) with ESMTP id h1L8tFIh082901 for ; Fri, 21 Feb 2003 09:55:15 +0100 (CET) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.9.3+Sun/8.9.3) with ESMTP id JAA05528 for ; Fri, 21 Feb 2003 09:59:01 +0100 (MET) Message-ID: <3E55EA30.E0CBA0BD@astro.u-strasbg.fr> Date: Fri, 21 Feb 2003 09:58:25 +0100 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ws@ivoa.net" Subject: Work around Web Services at CDS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: http://cdsweb.u-strasbg.fr/cdsws/new3.gml From - Fri Feb 21 09:29:00 2003 X-UIDL: 3df25b3100000978 X-Mozilla-Status: 9011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1L8Ti2v023003; Fri, 21 Feb 2003 09:29:44 +0100 (MET) Received: from eso.org (arcdev2.hq.eso.org [134.171.10.25]) by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h1L8Vdd26839; Fri, 21 Feb 2003 09:31:39 +0100 (MET) Sender: amicol@eso.org Message-ID: <3E55E378.D0159777@eso.org> Date: Fri, 21 Feb 2003 09:29:44 +0100 From: Alberto Micol Organization: ESA/RSSD/SN/ST-ECF X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: el MIME-Version: 1.0 To: schaaff@newb6.u-strasbg.fr CC: ws@ivoa.net Subject: Re: CDS Web Services References: <3E5555DA.1077CD00@astro.u-strasbg.fr> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: I just found a previous message of yours with the ws portal address ... sorry. From - Fri Feb 21 09:29:00 2003 X-UIDL: 3df25b3100000977 X-Mozilla-Status: 9011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1L8RK2v022512; Fri, 21 Feb 2003 09:27:20 +0100 (MET) Received: from eso.org (arcdev2.hq.eso.org [134.171.10.25]) by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h1L8TFd26777; Fri, 21 Feb 2003 09:29:15 +0100 (MET) Sender: amicol@eso.org Message-ID: <3E55E2E8.56B2AD0A@eso.org> Date: Fri, 21 Feb 2003 09:27:20 +0100 From: Alberto Micol Organization: ESA/RSSD/SN/ST-ECF X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: el MIME-Version: 1.0 To: schaaff@newb6.u-strasbg.fr CC: "ws@ivoa.net" Subject: Re: Web Services at CDS References: <3E556FD2.6F78B98B@astro.u-strasbg.fr> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: It would be nice if you could provide links to those two new web services ... Thanks, Alberto From - Fri Feb 21 01:14:00 2003 X-UIDL: 3df25b3100000974 X-Mozilla-Status: 9001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1L0ER2v022979 for ; Fri, 21 Feb 2003 01:14:27 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1L0EQK14709 for ; Fri, 21 Feb 2003 01:14:26 +0100 (MET) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAdAaGUC; Fri, 21 Feb 03 01:14:25 +0100 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.3/jtpda-5.4) with ESMTP id h1L0D5Ih026305 for ; Fri, 21 Feb 2003 01:13:05 +0100 (CET) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.9.3+Sun/8.9.3) with ESMTP id BAA23625 for ; Fri, 21 Feb 2003 01:16:52 +0100 (MET) Message-ID: <3E556FD2.6F78B98B@astro.u-strasbg.fr> Date: Fri, 21 Feb 2003 01:16:18 +0100 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ws@ivoa.net" Subject: Web Services at CDS Content-Type: text/plain; charset=iso-8859-1 X-Antivirus: scanned by sophos at u-strasbg.fr X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h1L0D5Ih026305 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h1L0EU2v022986 Status: Hello, Two Web Services are available. New Web Services (more GLU features, ...) will be put on the server in the next weeks. Regards, André http://cdsweb.u-strasbg.fr/cdsws/new2.gml From - Thu Feb 20 23:24:00 2003 X-UIDL: 3df25b3100000972 X-Mozilla-Status: 9001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1KMMO3v011261 for ; Thu, 20 Feb 2003 23:22:24 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1KMMOp11318 for ; Thu, 20 Feb 2003 23:22:24 +0100 (MET) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAljaGgw; Thu, 20 Feb 03 23:22:23 +0100 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.3/jtpda-5.4) with ESMTP id h1KMMJIh090816 for ; Thu, 20 Feb 2003 23:22:19 +0100 (CET) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.9.3+Sun/8.9.3) with ESMTP id XAA15372 for ; Thu, 20 Feb 2003 23:26:05 +0100 (MET) Message-ID: <3E5555DA.1077CD00@astro.u-strasbg.fr> Date: Thu, 20 Feb 2003 23:25:30 +0100 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ws@ivoa.net Subject: CDS Web Services Content-Type: multipart/mixed; boundary="------------D9F85752AB69D02B14136F9A" X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------D9F85752AB69D02B14136F9A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://cdsweb.u-strasbg.fr/cdsws.gml --------------D9F85752AB69D02B14136F9A Content-Type: text/html; charset=iso-8859-1; name="cdsws.gml" Content-Disposition: inline; filename="cdsws.gml" Content-Base: "http://cdsweb.u-strasbg.fr/cdsws.gml" Content-Location: "http://cdsweb.u-strasbg.fr/cdsws.gml" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h1KMMJIh090816 CDS Web Services Web Services at CDS
3D"Jump

Web Services at CDS
CDS · Simbad · VizieR &= #183 Aladin · Catalogues · Nomenclature · Biblio · StarPages · AstroWeb

=20 =20 =20 =20
News    
New server
New We= b Services
=20
=20 =20 =20 =20 =20
Documentation    &nbs= p; 
=20 A Web Servi= ce ? What ?
Quick int= roduction to SOAP
How to use a= Web Service ?
FAQ
A SOA= P day at CDS - 29 april 2002

=20 =20 =20 =20
Available=20 Web Services        =
Name resolver
GLU tag resolver

=20 =20 =20 =20
Miscellaneous     &= nbsp;
=20 Soap 1.1 W3C reference
Soap 1.= 2 W3C candidate reference
Apache Tomcat4 Site WSDL description

=20 =20 =20 =20
Administration - Private   &n= bsp;  
Server Administra= tion
=20 Server Man= ager
     

Welcome to CDS Web Services portal=20


Important : on these pages the expression "Web Services&quo= t; means=20 a web service accessible through the SOAP protocol.

CDS Web Services are based on Tomcat4 and Axis technologies.

 

=20

Questions or comments can be send to :

 

Please, read the using conditions before any=20 use our services.

Tomcat4 and Axis are copyright Apache fundation.


  Copyright © 2002-2003 Centre de Donn=E9e= s astronomiques de Strasbourg
All Rights Reserved
 

 
©ULP/CNRS - Centre de Données astronomiques de=20 Strasbourg 3D"Question@simbad"
--------------D9F85752AB69D02B14136F9A-- From - Mon May 05 10:00:59 2003 X-UIDL: 3df3b749000019b1 X-Mozilla-Status: 1001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h42EpC5a000545 for ; Fri, 2 May 2003 16:51:12 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h42EpCT28948 for ; Fri, 2 May 2003 16:51:12 +0200 (MEST) Received: from mailsend.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAr3aiI4; Fri, 2 May 03 16:51:10 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by apollo.le.ac.uk with smtp (Exim 4.14) id 19Bboo-0007PC-Og for Marco.Leoni@eso.org; Fri, 02 May 2003 15:47:22 +0100 Received: (qmail 17344 invoked from network); 2 May 2003 14:47:37 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 2 May 2003 14:47:37 -0000 Date: Fri, 2 May 2003 15:47:15 +0100 (BST) From: Clive Page To: allen@newb6.u-strasbg.fr, , , David Giaretta , , Bob Hanisch , , , , Bob Mann , , Keith Noddle , Francois Ochsenbein , , , Anita Richards , Mark Taylor , Subject: Web Services discussions at Cambridge IVOA meeting? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: (---) -3.6 X-Scanner: exiscan for exim4 *19Bboo-0007PC-Og*qcliz/DHi9g* X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Greetings You are receiving this message because you were unwise enough to give a non-zero mark to "Web Services" in response to a message from Bob Hanisch recently. Bob has now asked me to find out if there is enough interest in the subject for us to hold a discussion meeting on Web Services at the Cambridge meeting. I have no expertise in the subject, but am prepared to act as chair if there is enough interest from others willing to stand up and express thoughts, experiences, or whatever. These meetings have been provisionally scheduled for Tue 13th May, but I suspect we may not need all day, so might not need to take place in parallel with both the other sessions that day. Please let me know if you have anything you would like to contribute. Regards -- Clive Page, Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From - Mon May 05 10:00:59 2003 X-UIDL: 3df3b749000019b2 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h42F4F5a007119 for ; Fri, 2 May 2003 17:04:15 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h42F4FW00564 for ; Fri, 2 May 2003 17:04:15 +0200 (MEST) Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAEfaifb; Fri, 2 May 03 17:04:13 +0200 Received: from aria (aria.stsci.edu [130.167.236.125]) by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEC94399; Fri, 2 May 2003 11:02:37 -0400 (EDT) Message-ID: <005a01c310bb$dea8a970$7deca782@stsci.edu> From: "Robert Hanisch" To: "Clive Page" , , , , "David Giaretta" , , , , , "Bob Mann" , , "Keith Noddle" , "Francois Ochsenbein" , , , "Anita Richards" , "Mark Taylor" , References: Subject: Re: Web Services discussions at Cambridge IVOA meeting? Date: Fri, 2 May 2003 11:02:37 -0400 Organization: Space Telescope Science Institute MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: To follow up on Clive's message, the idea behind this session is to discuss the role web services should play in the VO, time scales for implementation, experiences with various web services tool kits, etc. This discussion group is a bit less structured/formal than the others. On the other hand, the IVOA roadmap calls for working published web services in May 2003 (now!). Guess we lost our way on this one. Cheers, Bob ----- Original Message ----- From: "Clive Page" To: ; ; ; "David Giaretta" ; ; "Bob Hanisch" ; ; ; ; "Bob Mann" ; ; "Keith Noddle" ; "Francois Ochsenbein" ; ; ; "Anita Richards" ; "Mark Taylor" ; Sent: Friday, May 02, 2003 10:47 AM Subject: Web Services discussions at Cambridge IVOA meeting? > Greetings > > You are receiving this message because you were unwise enough to give a > non-zero mark to "Web Services" in response to a message from Bob Hanisch > recently. Bob has now asked me to find out if there is enough > interest in the subject for us to hold a discussion meeting on Web > Services at the Cambridge meeting. I have no expertise in the subject, > but am prepared to act as chair if there is enough interest from others > willing to stand up and express thoughts, experiences, or whatever. > > These meetings have been provisionally scheduled for Tue 13th May, but I > suspect we may not need all day, so might not need to take place in > parallel with both the other sessions that day. > > Please let me know if you have anything you would like to contribute. > > Regards > > -- > Clive Page, > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > From - Mon May 05 10:00:59 2003 X-UIDL: 3df3b749000019b4 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h42FJZ5a015086 for ; Fri, 2 May 2003 17:19:35 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h42FJXR02629 for ; Fri, 2 May 2003 17:19:33 +0200 (MEST) Received: from exchange07.rl.ac.uk(130.246.135.148) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAjGaiif; Fri, 2 May 03 17:19:33 +0200 Received: by exchange07.rl.ac.uk with Internet Mail Service (5.5.2656.59) id <1JPGX67H>; Fri, 2 May 2003 16:18:43 +0100 Message-ID: <49F73BEED865D3119F8700902773C9F9013FF901@exchange09.rl.ac.uk> From: "Giaretta, DL (David) " To: "'Robert Hanisch'" , Clive Page , allen@newb6.u-strasbg.fr, banday@mpa-garching.mpg.de, dide@discovery.saclay.cea.fr, "Giaretta, DL (David) " , gray@microsoft.com, sckim@kao.re.kr, lemson@mpa-garching.mpg.de, Marco.Leoni@eso.org, Bob Mann , tam@lheapop.gsfc.nasa.gov, Keith Noddle , Francois Ochsenbein , womullan@pha.jhu.edu, rplante@ncsa.uiuc.edu, Anita Richards , Mark Taylor , esm@laeff.esa.es Subject: RE: Web Services discussions at Cambridge IVOA meeting? Date: Fri, 2 May 2003 16:18:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: I would have liked to go but this clashes with Data Models I think. ...David -----Original Message----- From: Robert Hanisch [mailto:hanisch@stsci.edu] Sent: 02 May 2003 16:03 To: Clive Page; allen@newb6.u-strasbg.fr; banday@mpa-garching.mpg.de; dide@discovery.saclay.cea.fr; David Giaretta; gray@microsoft.com; sckim@kao.re.kr; lemson@mpa-garching.mpg.de; Marco.Leoni@eso.org; Bob Mann; tam@lheapop.gsfc.nasa.gov; Keith Noddle; Francois Ochsenbein; womullan@pha.jhu.edu; rplante@ncsa.uiuc.edu; Anita Richards; Mark Taylor; esm@laeff.esa.es Subject: Re: Web Services discussions at Cambridge IVOA meeting? To follow up on Clive's message, the idea behind this session is to discuss the role web services should play in the VO, time scales for implementation, experiences with various web services tool kits, etc. This discussion group is a bit less structured/formal than the others. On the other hand, the IVOA roadmap calls for working published web services in May 2003 (now!). Guess we lost our way on this one. Cheers, Bob ----- Original Message ----- From: "Clive Page" To: ; ; ; "David Giaretta" ; ; "Bob Hanisch" ; ; ; ; "Bob Mann" ; ; "Keith Noddle" ; "Francois Ochsenbein" ; ; ; "Anita Richards" ; "Mark Taylor" ; Sent: Friday, May 02, 2003 10:47 AM Subject: Web Services discussions at Cambridge IVOA meeting? > Greetings > > You are receiving this message because you were unwise enough to give a > non-zero mark to "Web Services" in response to a message from Bob Hanisch > recently. Bob has now asked me to find out if there is enough > interest in the subject for us to hold a discussion meeting on Web > Services at the Cambridge meeting. I have no expertise in the subject, > but am prepared to act as chair if there is enough interest from others > willing to stand up and express thoughts, experiences, or whatever. > > These meetings have been provisionally scheduled for Tue 13th May, but I > suspect we may not need all day, so might not need to take place in > parallel with both the other sessions that day. > > Please let me know if you have anything you would like to contribute. > > Regards > > -- > Clive Page, > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > From - Fri May 09 13:16:18 2003 X-UIDL: 3df3b74900001aa6 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h49BFTOl010192 for ; Fri, 9 May 2003 13:15:29 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h49BFS700577 for ; Fri, 9 May 2003 13:15:28 +0200 (MEST) Received: from exchange07.rl.ac.uk(130.246.135.148) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAACsaaib; Fri, 9 May 03 13:15:28 +0200 Received: by exchange07.rl.ac.uk with Internet Mail Service (5.5.2656.59) id <1JPGYFX6>; Fri, 9 May 2003 12:14:37 +0100 Message-ID: <49F73BEED865D3119F8700902773C9F9013FF929@exchange09.rl.ac.uk> From: "Giaretta, DL (David) " To: "'Clive Page'" , allen@newb6.u-strasbg.fr, banday@mpa-garching.mpg.de, dide@discovery.saclay.cea.fr, "Giaretta, DL (David) " , gray@microsoft.com, Bob Hanisch , sckim@kao.re.kr, lemson@mpa-garching.mpg.de, Marco.Leoni@eso.org, Bob Mann , tam@lheapop.gsfc.nasa.gov, Keith Noddle , Francois Ochsenbein , womullan@pha.jhu.edu, rplante@ncsa.uiuc.edu, Anita Richards , Mark Taylor , esm@laeff.esa.es Subject: RE: Web Services discussions at Cambridge IVOA meeting? Date: Fri, 9 May 2003 12:14:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: CLive sorry to be so late in replying. If this does not overlap with Data Modelling then I would be keen to describe some of the things that we have been doing in Starlink - things that work, as well as some of the problems we have had. If there is an overlap then maybe I can find someone else to say a few words about this. ...David -----Original Message----- From: Clive Page [mailto:cgp@star.le.ac.uk] Sent: 02 May 2003 15:47 To: allen@newb6.u-strasbg.fr; banday@mpa-garching.mpg.de; dide@discovery.saclay.cea.fr; David Giaretta; gray@microsoft.com; Bob Hanisch; sckim@kao.re.kr; lemson@mpa-garching.mpg.de; Marco.Leoni@eso.org; Bob Mann; tam@lheapop.gsfc.nasa.gov; Keith Noddle; Francois Ochsenbein; womullan@pha.jhu.edu; rplante@ncsa.uiuc.edu; Anita Richards; Mark Taylor; esm@laeff.esa.es Subject: Web Services discussions at Cambridge IVOA meeting? Greetings You are receiving this message because you were unwise enough to give a non-zero mark to "Web Services" in response to a message from Bob Hanisch recently. Bob has now asked me to find out if there is enough interest in the subject for us to hold a discussion meeting on Web Services at the Cambridge meeting. I have no expertise in the subject, but am prepared to act as chair if there is enough interest from others willing to stand up and express thoughts, experiences, or whatever. These meetings have been provisionally scheduled for Tue 13th May, but I suspect we may not need all day, so might not need to take place in parallel with both the other sessions that day. Please let me know if you have anything you would like to contribute. Regards -- Clive Page, Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From - Mon May 19 07:57:15 2003 X-UIDL: 3df3b74900001b1d X-Mozilla-Status: 1001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4F0detj027246 for ; Thu, 15 May 2003 02:39:40 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4F0der05828 for ; Thu, 15 May 2003 02:39:40 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAplayyl; Thu, 15 May 03 02:39:39 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 19G6lL-00RYMJ-2O for ws@ivoa.net; Thu, 15 May 2003 01:38:23 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Thu, 15 May 2003 01:38:21 +0100 Date: Thu, 15 May 2003 01:38:21 +0100 (BST) From: Alasdair Allan To: IVOA WebServices List cc: Alasdair Allan Subject: Perl Cookie Daemon Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: RO As requested after the WebServices session at the IVOA meeting, I've attached a tarball containing some sample Perl code to do authenticated SOAP requests, using SOAP cookies, to my Wiki users page see http://www.ivoa.net/twiki/bin/view/IVOA/AlasdairAllan You'll need Perl 5.8.0 compiled with "ithreads" enabled, SOAP::Lite and BerkelyDB along with the associated DB_File Perl module (see CPAN), but I can't recall any other dependancies. The CookieDaemon module sits ontop of the Daemon.pm module, but there isn't any reason why this code is Transport specific, you could equally easilly sit it ontop of one of the other Transport modules. Additonally, I don't see why the module could be (easily?) modified to pass certificates, and hence become the building block of an OGSI Perl module. Al. From - Mon May 19 15:51:08 2003 X-UIDL: 3df3b74900001b69 X-Mozilla-Status: 1001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4JDo0G1001872 for ; Mon, 19 May 2003 15:50:00 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4JDnxW22082 for ; Mon, 19 May 2003 15:49:59 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAfnaiiR; Mon, 19 May 03 15:49:58 +0200 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h4JDmhHT028579 for ; Mon, 19 May 2003 15:48:43 +0200 (CEST) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id h4JDrMA20994 for ; Mon, 19 May 2003 15:53:22 +0200 (MEST) Message-ID: <3EC8E1D6.68F154F7@astro.u-strasbg.fr> Date: Mon, 19 May 2003 15:53:26 +0200 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ws@ivoa.net Subject: CDS Web Services Content-Type: multipart/mixed; boundary="------------A14CAEFEF0B5EBECA4A0D3DA" X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------A14CAEFEF0B5EBECA4A0D3DA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JDmhHT028579 Hello, The Web Services portal link is available on the CDS webpage : http://cdsweb.u-strasbg.fr/ Andr=E9 --------------A14CAEFEF0B5EBECA4A0D3DA Content-Type: text/x-vcard; charset=us-ascii; name="schaaff.vcf" Content-Description: Card for Andre Schaaff Content-Disposition: attachment; filename="schaaff.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JDmhHT028579 begin:vcard=20 n:Schaaff;Andr=E9 x-mozilla-html:FALSE url:http://cdsweb.u-strasbg.fr org:Observatoire Astronomique;CDS adr:;;11, rue de l'Universit=E9;Strasbourg;;67000;France version:2.1 fn:Andr=E9 Schaaff end:vcard --------------A14CAEFEF0B5EBECA4A0D3DA-- From - Mon May 19 15:52:03 2003 X-UIDL: 3df3b74900001b6a X-Mozilla-Status: 1001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4JDolG1002318 for ; Mon, 19 May 2003 15:50:47 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4JDokg22145 for ; Mon, 19 May 2003 15:50:46 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAALQa4pR; Mon, 19 May 03 15:50:45 +0200 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h4JDnUHT029083 for ; Mon, 19 May 2003 15:49:30 +0200 (CEST) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id h4JDs9A21073 for ; Mon, 19 May 2003 15:54:09 +0200 (MEST) Message-ID: <3EC8E205.7471700E@astro.u-strasbg.fr> Date: Mon, 19 May 2003 15:54:13 +0200 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: grid@ivoa.net Subject: CDS Web Services Content-Type: multipart/mixed; boundary="------------5AFED61E307197B042438E1F" X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------5AFED61E307197B042438E1F Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JDnUHT029083 Hello, The Web Services portal link is available on the CDS webpage : http://cdsweb.u-strasbg.fr/ Andr=E9 --------------5AFED61E307197B042438E1F Content-Type: text/x-vcard; charset=us-ascii; name="schaaff.vcf" Content-Description: Card for Andre Schaaff Content-Disposition: attachment; filename="schaaff.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JDnUHT029083 begin:vcard=20 n:Schaaff;Andr=E9 x-mozilla-html:FALSE url:http://cdsweb.u-strasbg.fr org:Observatoire Astronomique;CDS adr:;;11, rue de l'Universit=E9;Strasbourg;;67000;France version:2.1 fn:Andr=E9 Schaaff end:vcard --------------5AFED61E307197B042438E1F-- From - Mon May 19 18:20:05 2003 X-UIDL: 3df3b74900001b78 X-Mozilla-Status: 1001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4JGJWG1000850 for ; Mon, 19 May 2003 18:19:32 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4JGJWM01440 for ; Mon, 19 May 2003 18:19:32 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAiRaWZc; Mon, 19 May 03 18:19:31 +0200 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h4JGIFHT034773 for ; Mon, 19 May 2003 18:18:15 +0200 (CEST) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id h4JGMsA20671 for ; Mon, 19 May 2003 18:22:54 +0200 (MEST) Message-ID: <3EC904E2.473D9194@astro.u-strasbg.fr> Date: Mon, 19 May 2003 18:22:58 +0200 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ws@ivoa.net" Subject: News services Content-Type: multipart/mixed; boundary="------------75FB317349E4CAB8FB4E88A4" X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------75FB317349E4CAB8FB4E88A4 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JGIFHT034773 Hello, The UCD resolver will be available as a Web Service. I will send you a mail as soon as it will be available. Regards, Andr=E9 --------------75FB317349E4CAB8FB4E88A4 Content-Type: text/x-vcard; charset=us-ascii; name="schaaff.vcf" Content-Description: Card for Andre Schaaff Content-Disposition: attachment; filename="schaaff.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4JGIFHT034773 begin:vcard=20 n:Schaaff;Andr=E9 x-mozilla-html:FALSE url:http://cdsweb.u-strasbg.fr org:Observatoire Astronomique;CDS adr:;;11, rue de l'Universit=E9;Strasbourg;;67000;France version:2.1 fn:Andr=E9 Schaaff end:vcard --------------75FB317349E4CAB8FB4E88A4-- From - Tue May 20 18:30:04 2003 X-UIDL: 3df3b74900001bd6 X-Mozilla-Status: 1001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4KGTpC6016917; Tue, 20 May 2003 18:29:51 +0200 (MEST) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h4KGUQL29853; Tue, 20 May 2003 18:30:26 +0200 (MEST) Message-ID: <3ECA57CF.8070506@eso.org> Date: Tue, 20 May 2003 18:29:03 +0200 From: Markus Dolensky Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en, de-AT MIME-Version: 1.0 To: Clive Page CC: ws@ivoa.net, twiki@ivoa.net Subject: Web Service & WG status Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Dear Clive, since the Web Service discussion forum has been promoted to an IVOA working group under your guidance it has got - like all WGs - a collaborative page (http://www.ivoa.net/twiki/bin/view/IVOA/IvoaWebServices) and mailing list . This mailing list itself is now a subscriber of which is the list for general postings to all the WGs (incl. the IVOA exec comprised of VO project managers). Markus +--- | Markus Dolensky Mailto:Markus.Dolensky@eso.org | AVO Technical Lead Web: www.euro-vo.org | Voice: ++49 89 32006/261 Fax: ++49 89 32006/480 +--- From - Tue May 27 11:57:27 2003 X-UIDL: 3df3b74900001ccd X-Mozilla-Status: 1001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4R9uUKL019426; Tue, 27 May 2003 11:56:30 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4R9uU300171; Tue, 27 May 2003 11:56:30 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAuYaqva; Tue, 27 May 03 11:56:28 +0200 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h4R9tDHT023439 ; Tue, 27 May 2003 11:55:13 +0200 (CEST) Received: from astro.u-strasbg.fr (zeltron.u-strasbg.fr [130.79.129.150]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id h4R9xqR29741; Tue, 27 May 2003 11:59:57 +0200 (MEST) Message-ID: <3ED33720.8424CD86@astro.u-strasbg.fr> Date: Tue, 27 May 2003 12:00:00 +0200 From: Andre Schaaff Reply-To: schaaff@newb6.u-strasbg.fr Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ws@ivoa.net" , grid@ivoa.net, ucd@ivoa.net Subject: New Web Service at CDS Content-Type: multipart/mixed; boundary="------------5B8B6C3FDB5EB8A463F8403D" X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------5B8B6C3FDB5EB8A463F8403D Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4R9tDHT023439 Hello, A UCD resolver is now available as a Web Service at CDS. See http://cdsweb.u-strasbg.fr/cdsws.gml for more details and an example of use. Regards, Andr=E9 --------------5B8B6C3FDB5EB8A463F8403D Content-Type: text/x-vcard; charset=us-ascii; name="schaaff.vcf" Content-Description: Card for Andre Schaaff Content-Disposition: attachment; filename="schaaff.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h4R9tDHT023439 begin:vcard=20 n:Schaaff;Andr=E9 x-mozilla-html:FALSE url:http://cdsweb.u-strasbg.fr org:Observatoire Astronomique;CDS adr:;;11, rue de l'Universit=E9;Strasbourg;;67000;France version:2.1 fn:Andr=E9 Schaaff end:vcard --------------5B8B6C3FDB5EB8A463F8403D-- From - Wed Jul 02 10:47:28 2003 X-UIDL: 3df3b749000020ab X-Mozilla-Status: 1001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h61K5pG0022857 for ; Tue, 1 Jul 2003 22:05:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h61K5pLg022856 for ws-outgoing; Tue, 1 Jul 2003 22:05:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h61K5lG0022832 for ; Tue, 1 Jul 2003 22:05:47 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h61K5lU04141 for ; Tue, 1 Jul 2003 22:05:47 +0200 (MEST) Received: from newb6.u-strasbg.fr(130.79.128.16) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAosaGfi; Tue, 1 Jul 03 22:05:46 +0200 Received: (from nobody@localhost) by newb6.u-strasbg.fr (8.9.3/8.9.3) id WAA12202 for ws@ivoa.net; Tue, 1 Jul 2003 22:05:31 +0200 (MET DST) X-Authentication-Warning: newb6.u-strasbg.fr: nobody set sender to schaaff@astro.u-strasbg.fr using -f To: ws@ivoa.net Subject: Web Services at CDS Message-ID: <1057089931.3f01e98b130ce@astro.u-strasbg.fr> Date: Tue, 01 Jul 2003 22:05:31 +0200 (MET DST) From: Andre Schaaff MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-MIME-Autoconverted: from 8bit to quoted-printable by newb6.u-strasbg.fr id WAA12202 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h61K5oG0022853 Sender: owner-ws@eso.org Precedence: bulk Reply-To: Andre Schaaff Status: Hello, As said during the Cambridge Web Service meeting in May, if somebody needs an access to CDS resources through Web Services, we will study all propositions. So all replies are welcome. Regards, André From - Mon Oct 06 08:43:11 2003 X-UIDL: 3df3b749000027b3 X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8J9MK5x014645 for ; Fri, 19 Sep 2003 11:22:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8J9MK35014642 for net-outgoing; Fri, 19 Sep 2003 11:22:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-net@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8J9MF5x014601; Fri, 19 Sep 2003 11:22:15 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8J9MFI16262; Fri, 19 Sep 2003 11:22:15 +0200 (MEST) Received: from rose.csi.cam.ac.uk(131.111.8.13) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAqyaOWF; Fri, 19 Sep 03 11:22:14 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A0HSt-0004Yu-TD; Fri, 19 Sep 2003 10:22:11 +0100 Received: from cappc57.ast.cam.ac.uk (iwasawa [131.111.68.188]) by cass41.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8J9MBZD025164; Fri, 19 Sep 2003 10:22:11 +0100 (BST) Date: Fri, 19 Sep 2003 10:22:11 +0100 (BST) From: Nicholas Walton To: ivoa@ivoa.net, cc: semantic@ivoa.net, Subject: GGF Astro BOF Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870910533-250209383-1061565162=:2290" Content-ID: X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-net@eso.org Precedence: bulk Reply-To: Nicholas Walton Status: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1870910533-250209383-1061565162=:2290 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Dear All, at the upcoming Global Grid Forum meeting in Chicago (5-8 Oct 2003) - see www.ggf.org - there will be a Birds of a Feather session which starts of the process of forming a Astronomy Research Group at the GGF. I attach the draft charter to this message. This will give the Astro and IVOA VO communities a chance to input astro requirements into the 'grid' standards process. I would encourage those of you interested in this area to aim to attend this GGF meeting. Hope to see you there. (Note that early registration closes sept 26.) Please forward this message to those that may be interested. Yours Nic Walton ======================================================================== Dr N. A. Walton (AstroGrid Project Scientist) Tel: +44 1223 337503 Institute of Astronomy FAX: +44 1223 337523 University of Cambridge WWW: http://www.astrogrid.org Madingley Road WWW: http://www.ast.cam.ac.uk/~naw Cambridge, CB3 0HA email: naw@ast.cam.ac.uk ======================================================================== ----------- >From spartz@ggf.org Fri Sep 19 10:16:21 2003 Date: Thu, 18 Sep 2003 13:38:01 -0500 From: Clare Spartz To: ggf-membership@ggf.org Cc: membership@ggf.org Subject: [ggf-membership] Just Over Two Weeks Away -- GGF9 - October 4-8 - Chicago GGF9 - The Ninth Global Grid Forum October 5-8, Chicago, IL USA Chicago Sheraton Hotel and Towers 42 working groups and research groups gathering for 4 days working together to build a standards-based foundation for Grid computing. Nine sessions will focus on finalizing proposed charters for new working groups and research groups, including: * Business Process Grid * Configuration Description, Deployment, and Lifecycle Management * Workflow Management * Grid API In addition to working sessions where community practices and specifications are being developed, GGF9 will include four full-day workshops: * Designing and Building Grid Services (OGSA/OGSI teams) * Life Sciences Grid (Applications and requirements for bioinformatics, pharmaceuticals, etc.) * Peer-to-Peer and Grids: Synergies and Opportunities * Semantic Grid ***Important dates are approaching*** Advance Registration - available through September 26 - GGF MEMBERS save MORE MONEY http://www.globalgridforum.org/Meetings/ggf9/reg.htm Hotel Availability - space and special GGF rate guaranteed through September 26 http://www.ggf.org/Meetings/ggf9/lodging.htm ***GGF9 Schedule*** http://www.globalgridforum.org/Meetings/ggf9/schedule.htm Find "Click here to download the full GGF9 Schedule at a Glance" The Complete List of Sessions/Workshops and BOFs: WORKSHOPS = 4 Designing and Building Grid Services, led by Ian Foster et. al. P2P and Grids: Synergies and Opportunities, led by Andrew Chien et. al. Semantic Grid Workshop, led by David de Roure et. al. Life Sciences Grid Workshop, led by Abbas Farazdel et.al. WG/RG SESSIONS = 56 Grid Checkpoint Recovery (GridCPR-WG) Grid Remote Procedure Call (GridRPC-WG) Advanced Collaborative Environments (ACE-RG) Applications and Test Beds (APPS-RG) Grid Computing Environments (GCE-RG) Grid User Services (GUS-RG) Life Sciences Grid (LSG-RG) Production Grid Management (PGM-RG) User Program Development Tools for the Grid (UPDT-RG) Open Grid Service Common Management Model (CMM-WG) Open Grid Services Architecture (OGSA-WG) Open Grid Services Infrastructure (OGSI-WG) Grid Policy Architecture (Policy-RG) Grid Protocol Architecture (GPA-RG) Semantic Grid (SEM-RG) Data Access and Integration Services (DAIS-WG) Data Format Description Language (DFDL-WG) GridFTP-WG IPv6 (IPv6-WG) OGSA Data Replication Services (OREP-WG) Data Transport (DT-RG) Grid High-Performance Networking (GHPN-RG) Persistent Archives (PA-RG) Authorization Frameworks and Mechanisms (AuthZ-WG) CA Ops (CAOPs-WG) Open Grid Service Architecture Authorization (OGSA AUTHZ-WG) Site Authentication, Authorization, and Accounting Requirements (SAAA-RG) CIM based Grid Schema (CGS-WG) Network Measurement (NM-WG) Grid Information Retrieval (GIR-WG) Grid Benchmarking (GB-RG) Relational Grid Information Services (RGIS-RG) Appliance Aggregation (APPAGG-RG) OGSA-P2P-Security (OGSAP2P-RG) Distributed Resource Management Application API (DRMAA-WG) Grid Economic Services Architecture (GESA-WG) Grid Resource Allocation Agreement Protocol (GRAAP-WG) Job Submission Description Language (JSDL-WG) OGSA Resource Usage Service (RUS-WG) Usage Record (UR-WG) Grid File Systems BOF's = 9 Astronomical Grid Community-RG Grid Support for Ubiquitous Computing-RG Grid Federations Grid Scheduling Ontology-WG Workflow Management-RG Business Process Grid-WG Metadata Management Services Architecture-WG Grid API-WG Configuration Description, Deployment, and Lifecycle Management-WG GGF Sponsors at GGF9: http://www.globalgridforum.org/L_Involved_Sponsors/2003_spons.htm GGF9 Participants (as of September 12): http://www.globalgridforum.org/Meetings/ggf9/participants.htm Exploring Chicago: http://www.ci.chi.il.us/Tourism/ GGF Members Register NOW: Right Price and Guaranteed Room Rate; Meeting with the CORE international Grid COMMUNITY ; Learning through Workshops; Continue to BE a part of the GRID action!! Contact membership@ggf.org if you've forgotten your Y2003 GGF Individual Membership number!! See you in Chicago!! Clare Spartz Director of Marketing and Membership Global Grid Forum work: +1.630.252.0924 cell: +1.917.860-9126 fax: +1.630-252-4466 spartz@ggf.org --1870910533-250209383-1061565162=:2290 Content-Type: APPLICATION/PDF; NAME="Astro-RG-charter.pdf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: pdf Content-Disposition: ATTACHMENT; FILENAME="Astro-RG-charter.pdf" JVBERi0xLjQNCiXk9tzfDQoxIDAgb2JqDQo8PCAvTGVuZ3RoIDIgMCBSDQog ICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJzlXduKJMcR fV/Yf+hngcYVmXUFYZhLt59lL/gDZMlgLIP2xb/vrJ7OiJg8EdFZs7s2wggk u6YqL3E5cc3s307D6fvhgU4zpfLvZdv//fnn01+/O/3r44ffyl/3fz7//eOH p08fPxDRw3yat+lhOn362+kPFzrRePr0y+mHgf54+vSPjx+2h628X/72w5Be n0wPY32SX5+M8mR8fTKXSW9PpvqEx5nrV3N9srw+oaE+WOuDh7U+2uCrx+Hp 9hrJ4HUB/vTPr0+Wh8V/h7ea65MX2NgZxnnkdY8PqT68vD7KshOYjoZ2KCJY Eo6jpyNgQF0ApfrhEqycMpKS17k6xKWxDsRPJh5mkmVW9mZ5iOTsILlQBVYk 253hqyVkFFIORXeFDS++ND3SCvuVNcwde+EFsH7NQJPUfHUu2vwjKvh2hYIp lferfqdX/V6GlyENL0TDSHNd3zgr9brJTaOTm5p6mGisFEijcK75lG66uwo9 iCVlUpurSu5shtJOmzmvRUavu0m8G6r05cWlgUW6IVVu+CvLGuZClso9UthT d1QeLvKwws/UCEMGGZ5kXWd4wprd8pTpN8BCVxG81EjUBBLF46T6zRps4qny mRUoW9vHvS7tE4pl88bOtEvA12DnWudnBMvV1myy7uxzJBiJ+Sh4VednFJ+A /rdx2Dpu9Q3+Jle80qRtN3au0xd7OPprhNELFI04+lMd/+oguNycB0T3ZZgq RWkVAhadqZOTSDGttNFAN9FJSs87IGvatgaw6JGeCkNf6tdlQLaWbOLGhhfK e2kxaaWloFBi8FKolurHrfMRCvK07it6K8hlyc/IgZc6Q3nIHNgqDmzKxTDk F0BsEB4zvD7j+AHu+BpsytRLRaMWZ96Qh5g8KaXCGIs8xRCfG62mcx2duXvh l1iC2IVk1FrSwFpCoiXn4an84fZ9WYc4IGlgn6e+najZB912onfw068fPwzl v/++/e3Pfyr///Q9nX49bbsylv/1z9NfIjlZ9sEaOdkAmTtwykAcxLLHyp1V UOe50KRKzcIikqpUKpTZYAaUCEYiWbvISIvWnoxc8cQiDdoja1HinahFXO6K TfF+Zt5065wK6dPNACdlWqq5FcnNnvSovQXSsw4FIQPpecXFcd/1N0XGCk7a 6ySDSmOZkamQlMyM9MzmQBnMxx4MzalGoiwAllgimIE5TKRimsWVgBZPU66S KzogyMzToXY+glDCXIk9NNbEUTSlDWFdTdmDdYtQhucGExrqi2Yg2BwG8bI5 0bfI25pZNoSfhn4Vja6iaiiUkCCC432Cuwo1TA/gaoghgdCTFavSbRYwQWV7 quaMlOlpPZFLGazK+AQGAB28DKob6tS4JXCwjYhCO/ltABq6xqyL/NVFQllR K8sRmguyFB+9ClPxwoLwwgrC0giv9cQc47KVDz45MUdgZ1rna2aMUcKMVhlR 50UMlu+Dy0gbMCTdpUBIEcET2vbBLIp0AW+a6/wJyOZ7CBEwMdUqnPEbCmB4 oMmw/EBInC6xqxssYK3cVWM/VayiaL8udGlqB9BFOUXIldPi8AxCfnangyQF uv0JttQK1SJREhpFN0THmVCgV+DDck+p5z2SHWdII/Sqp6gj5QCCjE/vbxmC ebSIgA5IJg6wxW8jgGI6c1bNd3BK2MsBo2hWLjPUxyqwQ7t/5oSRyvflGuW/ 8Q8bx2ojwW/xf9gbkHQbZSAzL46BX7KsJJR84khRLQ7lHT0el0m+J2VAWF8C aq50EFRJTz1Ga0oYQBf447BXEjVDGp5Ttbdi4RNHgh6T7tmKJXsLQcRYqhgr D2luOZvG9NK+VZ+oVNKZ/Sgxz3QuITzDfyLFceLiFaMKq5QVM26+5B3Dexmq bgItgKJhZAHSvoh73ut4lQzPkTGSpy2ea2dv0unvEtBFSSCgE76D0Uids60W aj+bEyESQogORckRw6GSPNsGuXU958Don4zMhy8cHBVn8BD18GyCZ3f51bLE IxmWIjDmrVkmxDsj6zb7I2Od4sJLxJElrTR1Sd9leGYHX9iQCPL+nHixaAXq HoCzK7IO+r1qXFncegj85kZa/o/ATzaRzkmEpa0wiz3KAwcds+t74ugy0MwD tYTNJcouQLgAkyswK/YGuJyuVZPINx+SIyaVmJ2h6nU9eR3R1obVMbTtIoFn hQUshFzlBm9I10W53CheOQAECxAUK9QSwAXp8c+w+QFGVjAT1sZ15LtLkEnh /403gyxkL87KfmMGJshXoyePNhRMh6Fp5zc18sVdFEYnO1D4XpHiRRgX77nF SPvyYHN0rKYTC2KSoWbTksBfwEaRryfUvroYdWezFwF18VyXsELi0dJ07MEQ ewtiXiw1ZsnrW/7QICPVLo1AbfWVlV68Ue4QzARZKSkZ4E6BsI+Q27FgeyGs 8fUEjKjK6MksldYCxsTFH6YbemtGjR/8SRQk7NZrY0aXrwZcA3986Yj40zbz veUPu4OjyhM25DHcQVUvaj38oKcG3zgbrVJI12fgD/YKwTs0Q8Fc+uuUjZhF IHRKBnNPYBbudxEZSGZ1j3DHm0qzQUdJJDtux8OLYhT5/FxVSUPkG0sT/w2s 0M1krQBZGez3yaLdKLTUhUkoUr2KcPHGd1Y5r4WQ6nuE8DiOUMXeWxKIJN5L i18xW2u/IjN2b2Nk/w8L+W3GQfdHvB278lUJku6waRVHpUAXJj4mSvg1Alkr rjuPr5uE6alGNbRCx4eK2iqT3P0M/A13BcxWXxiX/RcgX9uCcqhLdFX9g5sW r6P9pwrWRyETN6CGAndtwfh0JIxC50J4M0jih2Q/K4xn940CuLiZstkI5hgO NgnmfHuexRppsiFnE3AWZzTaUEMrKvJ2fztWIcjqjUTj0wHWkkPUwIhrsOyY 1JAma7RgR9YyLkBCtMkdRTLpHg/md7v5Dn6FwXCGJzwO83yv61fKWRGHnzmW sCCQfjNn6xZ+LbEOgic0c67CaKxXtaweeRXflOE4GVsOWiLi9o9X5BtG7Ja3 6qLoXsiTIGWKQr7Ud9qAeQzGSfxVy6hAUYzw5QtAmBtUkoGT99too/0aoV+g 9q21bS2RoqOVHsBmtaDDS9VKFoAmDFF6KkEM9i3QqnWfhScNiRYwvF+LjJhQ 7omLVFQH2E2jt3ldoTHKV7gzTrAqJwD9fcSlnij/EY9OzNVL3yIuGQ6SZwqQ uKN2oG1/SR0aaLtEQ8xx/aUICNNG2AbX03bNLO05QiLxaNVNFZWnKkCAcSJS vbVI9o0wMTkZRbx2N0v0VWweNngSVZX8eiQ2V6zgJkwqvQ/zczcDRndBPiup GgjygetHSZ9b5JUXtkJKoceBi7sZsXsfjUuLHbLHnAvGVKFRtZeluGBGO8yl paOx+TFJH1Gb4NXBBSy3OfAkeYYewI48euUhBdzGA31B1l2YM2AGCPH/ZTCU 4qUlnbGocwc2LSt08lmpPsPZGriZCJt2hS3FF0/IUXSX2XYHFYLAX/criIGQ wvrZ0mJ0IRLa6n6arKDMIEViduusIHfX+QcKJCjHCJK3OeWUJeoZebmcyxHg zf5ZBKPEeKSPwejJzWZmEFThbhHHSO0faKzYjDAMCz1B0NUzF5KViYglvMhQ eL5OWN+ejGN8W5I0sDgRidMp4PH6RCLW42wofEDdRUp2Qfamg08Zxsk93tcM p1WM9EjCSkY2Moo9h28suBZBaAWcFfUITHnGGsuZggNJH6BFwfKPWRgp+7MR svUE6OiMGE6vnEvyaGVVL40VJVg3s5QGjJmP6KMbtuGlCgcYfP+kfsRgT8nE TS8QUcLf4TkvdYY8qIUYVRfTV5wFP4IQrl3f6ksMp33QG8rcTKz1ko9JtWa/ PS0yu2wWMBGnxEjhvHVlx4YdIe5MBL0gr1q476BuK9+R4cAhxag+rIpiBRSl rBnnXa6T3+ItIiq18F0keQJVWL7KaKVHShGE9GSGDjQOeMVfIwWExzQQKpUV CZppAYaxrcIoj3e1VRhC3XG8pIi9YRFbb6bj4o+wSUFSMrAT5OEeAs89Nd6U pmOt6WS4ZwEWf93kb0sLavguS5KMacuH8DIVrtxg7QSJfOBuFcTWmGqSjQwO eQI5jJNPPceGMXWGZDzQk+Izw8hOQTdz1x4szJZjkEFc2bNVnM44x07SxzoZ AfX9VGxcSTTUfrO6VOzjwKrC1V57YEVgyDC/tck8vAVtWzwZxkiRYsISL3J8 G8fGkdRVN+yeBd5Bx10A1HbCWhB6ZUgDoQf0ZQH5UfObJXF5iEc69OlloJTl NfXcdLW95a9xownc52asx00hLuipPwA2w3rR/Mk7Sj0Xo6Cjyj6QmLPOHBsJ c7zv5J0ZZk8sQ6KgyBvjRF5JcGcE5wmxxCd9XPdhzaCjWxqPjuoSeiO4nnee n5ZyXkuPxQjXUJB7Km4tuh7konuc62AjBK75i+rG2EmICVIsXqh3DlQtI/Cl bcUbVg6aFtUxFDdmvseWWOlMlV2EiN3oDLAipfoE/Zj7jShWY1HQZmP5AHwn V9BbZNlAdXQDnSZZuaByINEXjKxJnUOMzmtYaVYMLoLGGnXk/QwgGxyD+nLa zGQ4BF2mR+pnkppB/yqqn+B5FxXBoYk0UsegExejqhd0esFFP8Yq29t5D5Y1 3WNaWIi2TsQwo+Ig2m9020tTNfuTBjiFGYLhOmH/bE9C1sp4dZiZIKURpSt6 YiKMHXEudDmehcL+NjCVOqvbMoI1IcajUcX9H0mfqXCt6zLXtEiCU6OnurY3 WNmscvyymK5TBwgAmJ4ICqeRrw3CgTBipCcsyx0Vl3TdUYQfrWDgG7V50vCu nSAhdkj40ZeOUm3AN+NCYqNlB4+YH4DkEAx+F0G/XLsZ5BXxHrL3+a8LGY2/ vowcKj0aeqtyB+7tMlbS2RdSf7Iej+pinFHV7mUQ5C/4acexuPdUQILeJ+zC dg/EvaeOMonGUggH95dsBjdGezw86YlJreQkjT0FCBqn4JK/zgIEN+tIW4/0 6L9p6wlStUGFKMCBrpvRDGaIu48/emGEbCwQd4FpHSAs6vHlrCZA1VwZWfGv 5Whb9gLOuXf1Ch5KiPQk5+SqNXEXKOxL8v2FsAkcJjTi3vYrUrcc69IAl5AD l+x5eCI+75QoKnj3ZAZcdA0ENrjCCduT/Vppj9dS0/nZwBDfj+pq8e/JuKlk gXCTfQ3DiqE+qcZ8COd7ihX7lZV3vQ3LJ8PkAbfM+LGsYfDB4sjxDKlMGffY IH1neIJB+KEM67cDlGMZVv9a9jiBBBoRHD8M+oTxOtsDPeXaH5XO6Cgb8D4i nY0GziADFHbjMSn9ZGrfTWXSWBAdZLS6f7pShmaMC4yw7vLGbgKjrSW6P92/ 0InOzGZ1W1WQsY7qGEY1Gzweo/iiyqEBFoAxl454P4loNR8Ur1wuAhfJ7vJ2 aT16UVjQLWyY87xYwdOh4wFB3vdQLs+XmS+F5UDWvyEsgwnGfbkhhGWkfGpc 7/mVzBzqUOAvLlFK/4gdkGrRMYHoq8B0pPl6iszihPRsrUfxuYEevso9BIG0 UH4CV6ZDkiyXU7IyAV0P3T0qwOv/WpC+uq/lR+Ry+6eC3i80Dt5ZvfqGnQKj a9z+1tOsTMOEt4bZ1wNJqxSSFXvood3GEJBDnfdBG5Z/n8CQIxfJbzU0jlkH WWNUV8nQy5ncwNsNfHR/7CP1BusqQVkjjeyrzEHQbwRAh+4Y8xmHrYzWhexy MaXviEETrdvikSNHCVZonGLoOhIE73QJDUCD1f3Wca9L7AcHiuT/rqDhdbcV VPyl0FDVj+Zy/Vtcem7q0Tef+KsM0qeIyqO/RJSRoO7sewb1nQjJr7+6/BbI 40uY3QqB0Q0Id2dcuxK5tUX9FJeb1PV5dJb7nCkoErUDmdBqaMX9as/vpJD3 RgZ+3G+wvd0snLZdLPOud2nvt7kmuD//fPrlu11W9r+u+1/3AxLlD7Qnudyf 576NtVWvIPMRJmrm/w/nIX7TZW5kc3RyZWFtDQplbmRvYmoNCg0KMiAwIG9i ag0KICA0NDgyDQplbmRvYmoNCg0KMyAwIG9iag0KPDwgL0xlbmd0aCA0IDAg Ug0KICAgL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnic7V3N buQ4Dr430O9Q5wE2a0m2XAYGC1QqyX2AAPsCOzPAHhaYfv/D2knxp/VRNF3J bM9h0UAfHEuWSIr8+Kf64zSc/jY8pFNNef1/Xrb/v/16+udPp/98/fLH+tft 37ffv355fP36ZdnenIfloZxe/3X6+0s+pXx6/e3085D+cXr999cv80NeX1// 9vOQh/L+bJ14pofj+6Px4UxPnt+fTDLwQk+cd17SONTb9EWmv9LD5aH2P7nQ dMvtSZ7pSX9UyaWU29M88NBhuq1ieJj6X3yCDSywyZf3J2WlLT0hCp4fxv5M M4y7whP82oXJtzG8u/AzTcX7LeU2fUo8MJWV8mfm91k+fPtIlSfwjXSjYO1/ 85oSU3npLxYpUYBaSL/cSsNKm4W3OPfZA0RNUxpZJh1pwHUudHqcUTWVRDyr vHx6NDnibVB0pun75CSaq3n4HLLEzPQsDZ4YoUReaAmLcAK5JVI6yBG45mtv 6POqo37pqK261FZpPcF+kHaPTHTiTSpAcuMMkhpb5JRMeaBn7XEoMhc/oQ3n Sz6zWCXgBdPgET6IsoFSXBSJWw7KGoZnEiKZXvjVak01DikjdiHJaziQ1cni yTpK9pIrLpQ4rcXI0ZuopUU3kEJzaNW1L6PMjKNA+vNVUYo/d2YdMzizpTrA ISEpUuQrJBBnR/7SM73DfL4S9ao8Qz1qnHoa5dCBBbvVhaJTC1C4XBLLJ++E MQkRr9yOSH+vxprhWMkK6R0yYZqy9KSFPsWz5T8cFQTU6HmDc40i5a85O6H9 kzROLQ8NvYprBnqImep9yVCV7RuVzufUpyiupbRyYEDXmcbJSclMLWef+P1m zQTDkH61v2+UJtR5IDkr1B5J4sQswqlYlCGZYAn82nV4IjPoitm0qdjXuJOR jJMWxO6LoWoc1lRgO4wSS+VgMANrIFEjAjVcSAGtYN7Zykw62sJcLRB0SSCg SCFIpZim/o4KHZKEIFINtBDVApOxPXF27Vjj/qiEdLmIRU3NTC5Tz0SEZIE8 Eto0rS+Kn7M4r1p+jgVwDMcGnkQMDmwpoeoeQSaREaiOUMkZp8RSKxUGRj5n 2NKbJPRneWQHZ+RhuRqieA7otDGvEzc6DZdZicGzi3P73HU8QfQRiHNAgtTn Es7bJe1BZ/xDoFztHAw62ZxiAHcUInpSBlAwyK+ud+2Cryd6JkrPsBqR6Bh+ jXePJlHZYXBQDX4g3Cqso5KBdtnXCBA3ERpnlVXAgBREHrCVMrUMKE80isS6 pJaRpabbW0gkXvME63FWiBpbVpjZ6OmgGbosqGtBurwl8HZrO4o26zEEt2vr omHZrBVbKom+grBgCMmgDXFrBS8sCM9FwpOl2YKrYvMG5r5XsUIwJs9IZF2n 54cvdNpkS3QiHUh9oWWtrG1JO4kPnYmMwkZi20rC1gDJwDLRUI1wEVZf2E4p CTMieETXVi4mbw1ZdMXcnxs19bM45axRA9Ira2oBmkVQlstQAELIxAesSJ7i Y2uS88OjEEaiqzmvJ+qZl8CTOb5a37MlgqNGVbJPAtvneFqSxAXPGppcgezP ioIzy4dQcDrC1aFd7hEV7CqGt5h5oxjAcMj3eY3o5KO9D4SI0G63yEsMUu0H TYCdaeEMlCRZDG0DAg3xhKngkbI8M0Mu5a2x2S4apHMjDuBEe5JraG38dCT/ gVj0OTFoAITIo8ganp1AUSS6MZ23BOXrkehGPxo6TJuZpk3mwfPcgBLrSR9Y ftBKs5ihHARic/IEMRYD88nNB7C4VtKlysVNleMQSd5cDFwVSA0mhoiIkDh0 B4Fe8XwxGqQ0vBN4Qc+LZTtLmiwpITxzCMXxSkIBYInFhPzmPhfLewaYFosh Xcej4elR/ETD503I161T7q+o15+NYxlQAiHWTbQ8TaKgChwEGWLOrE/LdT9t iExkE5dagb+ODNSAbporlndEMqVmsjYihhhxLlbmy/F8HcWFOUPDgxcvB/1s x2agXamZEQSkw/ucO6r5RUGY2JURwexJmRPYxhAJL/VOVQZFHnyE+mGd9cij T+MpIyfBElEHbfqEUR1uizHtwdSoVxBBo/pyYhhhw+cZnnpvudrD8ktEEY1i czHfZtQGGO4hSVd/CejNQEAsVNIQyaaBB51Z08cqHORE9CTZVbIVVKxXKdHy zbH7weixsvyzPKRMBcv3CHNxcU/fov8v2PY5iW5vX4YI4zykI+QoQFRXvtVq rEMx5QI2IrJiFmAWc7OoJKCNDRbC5Cn1tuqJy3DhkDJqdWugU3bheHr7yF+Z ngG+zmARK+aYROhAR3K8rQzJ2URySGKV2Tiq8zJk5C2iya1MdniMhFOncYFi j1S9uPV+kaN6577MElgqiW07GCuQSQmhbLSTgQhRvsLerYyQxNy86idtbxGD RRCfCL6Js6U0M3VXa6S+r1iY5FF0gplEmji7MDisSMVyOLCIKBTM+GhBmyN5 fgnkn4TuI0frke29hHhTsZCB47PxwFGqW6GKuU8c3/Vh+XNO3SEX5y5+gWeA ViZQODeV7auNLrWo7ZlxAQhkjxdDpbQqzgppYaWNUxEfqGaMrNpQg6oCtR/A NbCHaf+cCEHfh0O75JXrfjbZVjx2ZW2n0vMzCZ1OKrCH0p3O8qKBKMZhQg9O eOUgN8fIfzDuZpQnGCYHD6LpEK2nRTJULAlPG5GZ9qpppUgqwJF3dP0jBqPb f2KpJFR2qjMCYyMGqyNVOF3HnBdkFUEZUlSlNUND10BvxpQLVnsaRbmq28TJ k+IWoSLYqpdD1nRp9d2m2Ud2qwSkagZkyhkG6Wqn843mU01SBra6rw61WaqX /XcEBHWm0evVzpOnVJB2BxI6TmV4yAEhCVPQ0CllU1WtXKjrZCV00LyXCjVK 5cfdrfmos5viNPQnspHYNnt0c4pNHUFDDOMf+u4RDwFg+Pwjy5qEb7CTxkO/ npobl0rVSYnUXM4SslVGSCCPJPVzSlm60SCY1Z4Edaim4SpDdQV8luhUW3Gh IEQSICmxjsTUa/GO+rBTXYRHp61cHuHAjZANKmo9ijaYXBROKe2PCcMO+1Le 2hHGum32jX/jaRu7MfBx9keOW5+WGskGLpehsL1cNBhjSNzHqBYkBmm2au2J kBj43AfE2PKggjDoeBsnBw3SSp8r5LMpsmc1xCrLq/LBaTESoY4ykNhBcjYV iswakM5TGR+rhzarRsk/NaKnoSiLR4JYGzBs7hlspkNct4rRqEEezbbggQuo VNFoiKdI9ye2lYOLeFtFRSvA3hK9gMGoBk4RLTKx/RCYbBSfGRFfoGG1UBVi 6Q8mXIIBkpt6HQvV6B1VrzLyL6FeSxfL9duRjIx24Ag6bKF3eit55GsOYikk tKldFGklIYNO0aFksi9O+W5rndFaj9gKYuS/zI5tsBiffKiM+NIHpM2LYx2y ZmfpksLOMRUARGVoTIYxQTP63+5F3SLgxJKNyWGdht1XNmI8HRHMxGr8qGAm NAAlqTozdYxQy4HYGQEjo6rTaDg1eoRhpq5D6jhkreIzcs5GrZ9Ry8GXJOiQ gdE4f1dAAEkEW/sBvW6+yA13m9YBTet7Yapx30/gLh+rWNOvTP1M5Ra7Lsco B4x0kxqJaS4bCJjyfTRtVObxvsRszv2dYZSKtagahwqyn0jrMX6f7gYkNU47 Zoe6a/luXBXaq1CJkfnFJBUqRYQ3BYh2lluJnIScbTO4E7HbndG2h+8qWVUu /mNaw9sCeS8uVmbDr3Ezw739R3w7Q+8K7/oek3nzgpEhMPIB96CwO+O3kyQH ZN1GuBavy9k6QfjIyA1ViUva/Ar43Yhs6LIE4Faog27XMKB4Z18s361mGe/1 INRIZTVbAnx2/Q2nLdW1XSFrC0ed472YN+9zT/LmzqgDeXNnlkBB72oS2+RZ DO8GYFnEXesnWo28t9eqVq4cqqma23iqzd58hwWtAFjROocJV64fUk3a1Suj 5pW6wRRAQiPqO+ls7LaDWtf6YJzDiU84OAwrMLz61sC3OmldR4iwXEBh7DsD jKVU6Ev8syCrHbjkM1v7ToUjTo4D1i0O8k1ALtQNddQEyEiJSV4yd4rpvuoX s9rHUd1iyJnV2ahM7t8jJboaRzkHADtZOPeAEfc+M9B6GfYs5EMb16sZRWag eA2XwUByEmDCovu+4VFxzWyk2fB2TtmxUYZ1Vy9TLCnwpNAHpiv6nX6e7PDu 3hwWVmjQIXBE6O68xRdYvBimKeDBWLZdiYZz6rrFFBixHRXidcua2+oWXwcN CEO/A/QOJjCa1owrgz7JbTH6S6EZybi8KlqsvOOEvqv6vLDxO6jq1UhB+5gv sNqwYJORTooflhtIA98WQK+M7DQuXpOEARC6Xc4aaVjZoEDg/0612W7XPor0 mop7Rq5HsFpnuyXb/aC4d1Qd29nM0mkugG3w9StdMTp2dNGvb31OV/F2Ew9s /QNlWHke3g+rFGFx17ZUg66gLNN9K7rXIlDSxG0vfGyGFw7DSVduqOYoT5Va sI5qJRmpkuKw0QNBGGiNBnHbL8VHkfxOcpzWN41lMGh9sCjR6Vx7ZPuYjeJg rMY3KjfVa4G7Z+gqX7w1Splew9sHoke9aiFfq2SC5UItqlVRF8gAyZVR7fGY 8fOeR6kj2QpdGFeYODk7J6FsJQ0T8h2WakSVIlW0XUSHTcn+tRs0yj0wO/U3 7wpjRI/V20qkJ9KrnKcnvHDd1KNq4GcOS2eDf61Ha9yyy6viH1JwwvxW7cpV XbHsXSOu7uYfvfnKutVI2jaX4T7VT+P+Qor/SE2UMct+OcEdKChVyznB9l0n daGuxZR7nh0PEHcW6TsJtIq08zqXbzJ3g/D2nsPWb87vZ3L3l3yPWVD3W4T8 f6t2pN2cmRSLAPNI9rqF6oErMyMXO62OODWgMvBdpZb1GjPBIBNU5OMFv+kp 5Q3misNfVFhpSo9yPUFGPe6qwTRXuDjbdEVv2opXOe62AJWpjFsnID3PcsbH nM5jYtsjLtBYyqWQfEmad2xckVKJSHhpR2+7dfs1rlQLpMNzkR83U7Hx4SkZ Cgwtq5WVNpCpgauL1X5jFcMZV090VIKzAqMST13xt++DOsbA+gWjUBlj957o vtbCa1esdC1G02CcV+fjwN1QKyMzu/Otz4mhrJLh/HKURNFD2Q4IjuzWHTmX +ESKDnb6zY1MfQTWpWmAmjpTn9EPHemrsfftBVxrm+lsqiMc6mwJHOqsLnnm nKzx+0x7qx6h0IPG1O4cY8P9skP8d+1aqlGasTUr8fWV1ag2i1QCOv3GeFuD 1YVft4t52BApSCb3gI794tV7XKLAFVvBQgqjTdYpnMAI6H7hhFPxE7j3qUBe sPuzlfudw3aFcQC4xfRDLpiG39EP/NHdX95aIc/LljkRpJ9lhWPF4ywgSH6G oYeB7jqRb8j9/yfyJjT8uwAIG61IhpFQdpLaRjjOq5U4iCgAZN59QWbA7wuo CRilb5sOH/YP9l99BA9zye+huxgwtBi5fxGb4EYOaYzaSegXarlabYGb5IKQ Z0Q4ZnpxoI1Wtw5+qMmQgH0QOzZxMIQiLVgZp5DqOxdI0RiNZparYDX47EtG oBfNcFXQah/IJR+5oWJfkiMdXqpgUpcFWCkUJeCoWLyYpnndipmYUs0CYmnE qugysE62huIKXpzMuVxRVUtYxxmVf3Oafzmlt3+b5OZlG1q2C8XyhjnSpmy/ /Xr67adNwre/nre/pu2v0/bX2v8x+dtcCwWlSlsozd//L42+F21lbmRzdHJl YW0NCmVuZG9iag0KDQo0IDAgb2JqDQogIDQzMTgNCmVuZG9iag0KDQo1IDAg b2JqDQo8PCAvTGVuZ3RoIDYgMCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29k ZQ0KPj4NCnN0cmVhbQ0KeJzlXNuKbLcRfT9w/qGfDZ6oJO0bmEBf8+zkQD4g sQMhDtgv+f1IPbuqNFoltabnGBKbgMnZo60tlVbdVpX654M7fOte6DCTT/9d tvzfX344/PWbw78/f/o5/TX/75d/fP50+vL5E/k5D3LbSzh8+fvhDzd/IH/4 8uPhO3Lk/nj48s80ZkkvpD9+F13Y9kf+JfLD+Prommb73vjAnL8/b3M1fdwn n1+mfSJ3dsfXZ1t6Y392dbfXZ6uO2z8Y9n8Tvf57etl4xLqP0CdXHuP3J36B MfLEN77ktvpLOsvaekdGyBMP6w316mCW4Pc9EYlwaObX1vZEqzu/Plv0GY46 wkwXGINvzbzM5WVuCjqNmuFYQ37qTq/PfRAw6UcCLE3PiT87v3QwAGelWxIB Bl4CTe+RzeJdF/PbXf2mrFl30JPo1I3lpXImSiC/uMiwCF5WTAvvk8VLPEgl duYxS7Vgkc3KGiTvTDTxvnXqiU9JPu9ZGiV2WIybHhFiZRd+rJbUlVf0SSpv jYR7YFvuxmv2W7INlfHyIOgRrduXySIJC4zwvLWkh6vACBBSmyjPYyioqpzp UuMYX8R98IlvPYheaQ38yUWgESJDYWl8MEy1QQsnWMLEs8wwL584by2ozsPW +EiSTGQ5pg+oTyHMKrmtmv4NVEigEnxsQMVA7yUsrKme5Gz8xCshWdrGlmAt RI/zecdfoUJza6Wgfc3lWv/20+dPLonnP/vf/vyn9O/Dt3T4KTntJP/0//51 +EtPO2hOC3noew2P6Y6y6LnQbAN+u32PL2hFm6fvXMDTPxra5c8GuC88XxrI yxjbVdu/qEl2gW0mRTkuVicL9XNjl6pNalN9CMTw9RPgN3yl3aDXazvyZ/Qp Lg1w0ZR8hByk98VBqv6oC74loO348U4FufBuF3AqRfS1y6jwmKEeQytPX0SQ 1uxXDVMYjz75yWSlZDRqaiGFjqZSUugwoKoub6SS5gbWF8UwYRzISy7M6MPw NqwgqCsDqjgyNgBFRIsGAFHn3/pWUYGmBtBJPdg7/FfYQ0FyamlJHhbGRpYo 7/q2GsiYC1gBAkVF/1goWB0jtBTMzWn9FiSMSAZdztEy0xq6iRB8UkBWP3V1 SUFmjFThI2evVpzU9RNrIepLsamOvqxLGvVQXaZ1e6mzypCD6SOHsj40cWIF VqR7kYc3wHoNiCsoDerHqXBY6hPx1a/jY4wlTTwPLWp6H4ZoxkRifERCK0Og H7HVYaVKpKkAS/qsdciWufGs4GqlktRvggNJ+wk2gMoz4GjytvnpnWfh6du+ othPD/tuxFVMywyEjZvEWMdCGdUTYOIjUMCDrsORRZy316z7ypOnhxr72YEj ZPaKAIE2GE7jqIciA3KwIYyeRE+9CAssK7oXMRwSJSwpn+YNT00J+iOJE2pb CohG1bljjLNWe4t6oBgSiHN77NrEHKGBeiJSXNYWYFHzwNyyCqte4zki0wMR rqHARppWI3QkvmSDgvpe7Luj77NPC3is7zNqu5/FXS1tQBlkmWHWlQiLRb6L GDIi+BTWC5FRWEJAVwAsgWsjwHGyscIHiOdALcVt4+kamhwuHAakAF0GTiAd MEviOluTF8teZNlGSGZSG48UKph4QIYbXB0+EfVyesggTAR9SpGv8iLKHPUH CWp5a8UTNpi5JYWa5zZjsouko2dbfv5Yz2I+sEqyxBZfaZ8iLZLzjaAu6ENl C9TlrmH/PV8pMJ3VN5Yh7AedIy6ztb8wxaW21niSqKsdhqKTYWJdxSh+sKI2 08ULG0PNMQc0kLL3M7GCdie4m2jZpimpFdigXV4T7FVFdc70mNdtCfLrOLBi l/2AdR1QrJAzv7fCCtHdnJLUdezSSni8eiGtXmDkYET6GNef6ycDtMQmtMSs 5OAIMeHp5ISeCEW2PdUv00k8KjUTP9ooMIxoLdN8qfhpjqOBm+GjmzDPQa51 chwt9Au1T56A5ZLMyjDwdTn3T5qxtvmHYkc9SOc9PIa0D1zg69F1aJXATxrR usHsOsGYCM+LqGJTwsYTtPaYEYLDyXQcw9xPXQLuTnFLvhFUTQzzS07JGqXL 6gW2uYome+DzSRtHZGDXkJlmzXqQgsxZXwUznsK8GU8FXJyRkATJDwt6vM2k 6f76xnmgRjS5DUqvBpKvFIXFKlLNE8MyGtLrYO7s1Ca5prlNuXWyclrNTHYT E4g2GBldRcOKI5Kqv0AuuoKiK8iM6Y2NLVoQ1oIPkdHIFgLH8GqKH1Yrs7O3 jsUMlwflDYubc/Vlx+Gb2ot8QrtlvNSjkBDuRGnn5+o4CWtN5Bey6dVcXG4q eAj9uM1QEbbMqtHWAnu9ckz6RhXUGshAJPARJjWSBeu9WZS13zqjFH7awxFu QeuxBB9th/xgqcUcaKai5LN8jYUnEc/loQQEqwUVgB1QAwXeZ0gsygK0wGKG QnO9UAM/mL9slufoYEWjfFap4qC66OiNqmdPNkJz1qW9H7MVwl1gRzxMVj/X J8+naoRvego91Q80Uj+KaxjpjEBeZVIiB0OIpisyZjYi2BEm60jC1La8pge2 jTZxhQX1sJ+/aMZAtSllbZLE+EXnf1xN8oz5N1X3G2lMIenUExrqcieIdaY0 Y9+O5agw+z4WEZ+c0OLmnH0PNy0YamGwtM0wT3fVC/PCCLkV5w2KyQYsDfIN 1mv1F9Rsl6RhxcHmTE7xS2vzbaOGHowaJsLTH6XWX/a9cUpRxIHvzin8lCVg SZFmtmJSgz1b2BnhtQrA9FI4zhkBMuUqe3UHNwCYaYbiqw/uykk7bZ2i9wBf SE5ZDu1IgL2CBXyOMc1pqSaw4wGNdxObUx819PADyYvRZWCYc4xhjEzwLYUz GrX4dH4fPEXvRKGmTkL71c7thlJFCWF2M8B9Gou+NiMNlVw3yYgjTFGMAa9X sPSLosKNbaqmXdqV3UOQtHNTu3ItEYHmJsVrnQKNwG5pU5FYUZgCMrvPtB8b yVhyikW27oWIMFtKV6lshjJCP1JUffJ4faNZe8uplXmeqk/xkYhz4o3Rw6k+ fc1uVF1S6HESuerA3KcoXy8qjs0kutjHA3yPBBbB1dI4OcF30XGnFKYgB9TA uvGDrYvoEdFI1CB9ULR1k+RfRfV8qNmkaIOp72VY3SXtbDqgw8CdNsvRnaKF 4YjGSv5DlcEC5e1YBz3yk9W36W6bAXMpsqzjfO1rEp0QFoF6PUZFwz4VJJA7 aeHNF7zfxTsNdlmWzbqarL9Xrs4C7yje/cpMdMShqF4xOibdC6pqBVWPl4fw zk99eUiDUb08VGMkmZ8oLZdUSIUHyudOYqELuzdwXQm+qBeYigaLFKkU7ajY 1oPBS80RacMmq4sgKZnCFAj5tFduGdGcnZRRVkvNAVHh7Oqdejql5DQlwIyp UEqPNb97+SksAbKRX/96R223RFyy1Y597ljsq6aVnWuHt4cmwtNqSsawb9jQ ejSaO4ygyyiioecaNDdjJDkFvcyQvH/XSRkc5MPbDCq1B+TaQMNamB0mHUO8 uhHaF43ZyuDg3dOU1PD1oSIEw5rMyBXP2eM1gmTlHgMvpnVbm0eeeOjO6rtW vzUh5qlLRxS9Axts20ikth7/UIig3481wNHmCzZ1pG0xqbARpKyaDGkRrF8F Pp2Sntlm9AAXtE4f2k3SWyXTlq+w4Fsyc7um+ai++F1ZdE1RAxTKXfeg4Ieg EKAL5X+qMa958pnCNhb/G+oU0z1+uE8sV3frprrfYFNNy33c6X5LBr2uFasP wOpaaQLqTc9K+wrfR3tWyt19uGclX6epder3U7jvhB/RFE2/TN0Jc/tl6vdI 5ndTpi5P4eNlar9FbDPMuYA0Y/lCClvBu8kNjdWwFOonh2/k0ZqNm7meKSch r3e5S/IkWgZangDh2bul0+4Wz4lRxzXpmvs3Tgdsjr/7sEqxnr91h/UwDgUx HpN3rCs4I79u5JcB7+PsLRr3LeW3OwpzckUlspZxE3EVfbtoihrFdMI4ePyK P/oCZgTKNK/qP+/nzCKz/v3/AXDNC/6MTYNG9wiBonrUtfA1MYz8OwhJMgp0 CgVv9IRB8fcin7XxLpcrtHdBrnQ6cn9dNrfcwwf43B0DU8T2FeMXIKRlhgYO tvjhBj7K2bg30bmgY5UKjCiyUV9peZMt+0drxyNXPCmm0+eyBxn+AulfzX4L PPhSWzqFp04ybZTCjRaOd0XKpWy65Tnq51T3KoEn/GGt/0PD0vvtMNqMnwAz ssYUp8gvmnjf5oZ6KWCnMCe4rfPUxtrj1Fo8MBSQjMcNU9dwo8whRKkH+ubx 8IRSisMu2WNUK9Nowvs+Y3XX6RxjZd4vHd1dtHdO6pcfDj9+kzee/7rmv9Lh bmopk07NX6Xc59o4jQnCloXq+/8FTRXmcGVuZHN0cmVhbQ0KZW5kb2JqDQoN CjYgMCBvYmoNCiAgMzI5NQ0KZW5kb2JqDQoNCjggMCBvYmoNCjw8IC9UeXBl IC9QYWdlDQogICAvUGFyZW50IDcgMCBSDQogICAvTWVkaWFCb3ggWyAwIDAg NjEyIDc5MiBdDQogICAvQ29udGVudHMgMSAwIFINCj4+DQplbmRvYmoNCg0K OSAwIG9iag0KPDwgL1R5cGUgL1BhZ2UNCiAgIC9QYXJlbnQgNyAwIFINCiAg IC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0NCiAgIC9Db250ZW50cyAzIDAg Ug0KPj4NCmVuZG9iag0KDQoxMCAwIG9iag0KPDwgL1R5cGUgL1BhZ2UNCiAg IC9QYXJlbnQgNyAwIFINCiAgIC9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0N CiAgIC9Db250ZW50cyA1IDAgUg0KPj4NCmVuZG9iag0KDQoxMSAwIG9iag0K PDwgL0xlbmd0aCAxMiAwIFINCiAgIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQog ICAvTGVuZ3RoMSAyMzg0OA0KPj4NCnN0cmVhbQ0KeJztfAt8VNW1917nnHkl k5kz71eSOZOZyYMTMiGBwEDGHEiCQEQRARMwJIEkJLwSkoAgYoIaQEDBior1 Wp7io94yWEXsC9qira0U26p92F6fpbWVar3q1yqZfGvvOZMHoL2393fv7/vu rzOcc/Zee+3X2mv919p7DunpWttCjKSP8ERZuqqp84mnnzhICHmRELAuXdcj PVBbFMT0G4To9a2dy1atu+XQrYQY/kCIbnDZyg2tO+reuYYQC+bHiW0tTc13 3jndRci0v2IbZW1IWJHYoCOkshjzobZVPeu/Zoa7MD8P83tWdixtOvFL/Xcx j/XJVaua1ndeLZzjCakaj3lpddOqlmn2A5swj/z2gs6O7p7vk9AgIbV9tLyz q6Vzn/MPizC/nxBhG9IAv/RjxKSW5jle0Gh1ekNaujHDZBYtVpvd4XS5PV5f Zla2XwrkBEPkf/NHcyfx4P2q4fvID/9okjL4+9H3xCxWdznxJJYnqWrezP1s 8C//uRHo1Uv4xyeR/Bwh04l9cOHgNwbfIwlyA3EMcoOHB//ERfksLC0dPEP8 g2+S64RuoZvMGjwOMSgAP1nOLgkckEY+BoEshQjkQTbYyKfkKFlKPiA7STdp J4vJ++Rxche2+wH5KTlBNmDZXGz3G+QsuZFsJlXq9/d4NaWGBFfht5O7n1SS XZeM9zb6hTTs91WiwBFyNanV3EHOkNdJKxmPz5+TtaR0iLtiEO2Ac3C7sHQi eQopNWQjCQ++BqVQSiaTcnIXmMBEriAJ+ITMI78kT5C3sJUl5Bbsu4E8z8nk IT6NfPhfFfM/P//8/PPzz88/P/9Pfl4mYy9DjZHjpAS9wQIwgxl9QvI7Bb83 se/9yrS5M2dcESufMjk6aWLZhPGlJeOKI0VjC+UxBfl5ueFQMCcg+bOzMn1e j9vldNhtVotoNmUY09MMep1WI/AckEJwx92VtdXL457KxrgxWBUUpbjx6g9m R+LE6gsELVJppG6syhXXyHFiq4nb59QeI8qkurhWvpjl6jgfFj8MYOXZPqk6 LoTxX3BWU3M8f25tICi+6hsqr8M6cW9lbSDgi3Nh/DcTi/DfrCapOS7OQXrA l6TMjJM5tfQ6MfjWJCSSSYE6vM+tjWensnV1lxvksxj5nLpomFfDdvGY0VNZ FSf2Y8T4Vpw4KNsHk0iclMfzZRyIiCnWGonEwf5hHGxxcMzGIY/uglZ7Y9Jl ZFDdvDxY3dyOEm1uHJbpB0mJBqTt0va5tZZSTLJB18R/eG3tsfS0ymBlS9oQ gRxLS0dKuo8giWAjncfAeAWwBGesnnyMI/oMFKCVDriaXsvjyo5GTASrUHJY YhsuOTF4aufIIoLVUilbMpXsNa6tjOuSw5Da40pTnOyQjhWe2r7zhEiWNMrG 5mBz0w21cb4JGY4RPlzdNi+eWTNnIZKwK7wa2yS64FXsRpdPqm6TtmOe8jbi PVhFl30UvbmtpZEqCjQGq7DMUFm7NXDKF7fiszpukeNXItuVN73jQ2pdnRtH tr06iI0hb/XyaVTmkaF1Yeo2s5lJX9nRJMX7lixPKlfTzpSCB7aLceMnARQ/ LgDWZBVVSTU3LqcjWt5EZ1G9XNq+o4XNZCcbOSqkVL28il60Iqo3mY+1F9ZW twWrhzvEeWGCD19cNxCIe2Racfv2ajrEpmYcfXLIWDA8fqr0PhlwPJVxZR57 kHlMxNij0lRVp5JUhoW0Gi1prKqrCySXFVnjuvBWTVFQ2k5b1IXjdlkMnMay U2MLa+bWVlf52OzjXGVt7Lzbdx7TNXOGyOBGnu2R876kjGquC9Zcm1zkttSt cV7SQrmhhUVWlZ+1esbtO4Pp6cHpjdu3Tw9K07c3bm86Mdi3JCiJwe3HjMbt ndWNEjNtQPo3dvji03fWxcXGNpiMi0zVafrcmrjt2kV0eaZLbU1JNKgIBib5 Apa6FM+czytWDQkVGtU6aUjbxfdwdEYEHZ80nSLICTR8X1ycRC0RxzK/FhV9 KVNKdkMDuA6b91FT4OvC1e3XqSLyBVIqQ6HtWpWKjQQC1Eh2nFDIEszE+66t TeYlssT3JFEiMq5eIy05lSpxzKclfamSoeqNQVwtd811f0erR2r0dkvQKkUj bAUYojbHT83DOf51Ulw/SV1wW2Ut7+PUFOfjaSpNRoQqj7tkVpHKBIFwuxiU XgrGRTmuqaw95Suvk0QLIhgMqYPaIsQVLwXNl4IvAIVKYhfjUB4HJy0iCJ0M wXnXJCwcqitVb29UdW3kFFW8b267/DyRRwziVH1Jfos1SGf7IsMvFZjD06ll +QJJjll1cROF37jpPXbD+fkqayWEGrTda1lCqpba6MLHpcYqBgp1vpHkE4Nv NFZRjMMhUxafquR4r/v7vXqS3br/42bQh2aweWdd2+SLxVwzbyg1t3aT76Y6 DBk4yMQdfFSLm36iI/ZntJxA6BU58/IZdhtXHLAELGG8QaaQdWEpn3XhbS1u kvs0GF9wxI61n9Qsx1QWhJRDJM0ABi7dCEYwuOcCZ9jscds9HjcYMUeMtzpd dqfTxd2Tnm51CYJGzBJsR6wL3BD1tHs4j+jxz1Bc0no3lLmnuzm3oJitM4gA 6bzAK/Ssxun26Hirn+/k5lgaLZ0W3mzBQotVybau4uJ+2O2HPj/M8YPiB8kP oh/e8MNLftjP6J1+KPZDPfusSX5k8LrFMw2L6+tlsFhdUTUnR+rrvWe8cn09 icw+74pWWKOR88VbTUWyXhZP49PNEuNEnaa8XNSVl1NXo2Q+BuACEFx2V8jF b9Tv0D+o5wXOzoU4Xg+LWb91wPMQmFCGsVZeQOuwO10OmpuI2/lszsXHvvUc /8nAhqsqrkqEa6cuSkydunAS/GEsPJcbub4aPoDnE5MTYhU3prj4mRfzQ7ma qiphVp9Q+9mZ+vkVHD3nmjH4Nvc6/xxGfT9XjLl7FbHYVSAQr5iNDlyZ580p yw7kKOnGspyAmLGXOAViEA2SodPQZ9Ck8Qa9Uwo+nCP+uVgZX9zOFfzZpUt7 2KAQA5j4UkMrZx4PR8dD73joGA8N4+Ga8RAZn5KnDCg3FN/s8yWvnmdinX3+ 5fMlpILK83TF+YozMnGLp/FWQeU8+/y4Yiq0p0skg6nMgzaieDDBF91WdE8R z2NQaXb4HRHHLoeQIdD1aaiX5TpNTl5uMEfrCFpKnc7SEhRibl4RN2F8WWmJ C/MTSi3BXMaAcs3mHHYt7CrvKTIYLZWVjk2LY9PLb7q2+cqjd01alqvPqqx0 ds2cOC267rr2mqeystPdZihZ3aNMLF5QWThr46K1uxz6rMS7i5dNm1IwKybP 2riwfw/K147yPSj8mDjJYqUgTasx7U0377OD3Xo/cWZkmIij2MHpHe50U79G UJjquoQWLiWcMygd8fnF9ZZohFQMPF9fcT4aPZMUhJLmkFzeGaDoxDKZ0Knm TrAEqWqUWkpxwnac30SXFm5bv753/cOOhWfPRvIqZoQ3Z914I7dpjuXw+sRv Fw4cjE2LTtlJ9aAADXoj6oFEXlQKTHsJsZv1sEu/Tz+o54keDHrjfZyY9Uj2 45JodTyi2IkGvLyGKslMi6VMk0Osu637rXGrgPZGzP1K1iHHIXfA3cI9lQOH c2BPDtyeA405wM3JASUHxBx4KQdO5UA8B3bnQCcrG7K0hjVd+JEBdeLcOe9A yfMoDfF5JhTijqAulFR8fL7i/Blc5jXU0lTVIGng0gCO6UmdsYxx1wGuNG5D tEGmCDoqFbQfVATL+NxgcEK4FJ66++b5LZVlYyePD0+ou/LWgSdqC0Ljw3B1 lDc+23LVpJnTlTWJwKIxVVUFN8DHUwormiiKTR98m/8GSiudOMh3lG6D1qPl tLjGnM6yl4jGvVqn2eQ3cQbedBuvuPh2znabahZONIuQC95xQbMLqlww3gWY tbsQBSD6sgtOj8h/5II3XMC95IJTLmh0geIC4oJ9LKEiUsMaJqquJFiMMivV pqjM0JrOI0dKce61PmzlvpzxeAZH8aXE6rBzwRy0CquthIolB6XEcS+8/++v fO+PH766s+7a7dfzzyXef/P1xPtgef0NsF5YDxtfeivRe/a3VHPGQQe3gYuh PzA9hbs7DUTEn6AnGFeMsBXgNgyc4GZAx0+o1CKD72l+obmKhEmEvKnUagT3 XGGz5LdLkl8SOL9bsycvL2PsHtcRNx/cw9nSTUcyxtyijM+syuTGZkKmVGww zkj3L/JzGX6a5PxW/5f8B/1P+jWikOmX+LBuXHgVl06V0qVLL0s/kKvrVVym A9Zi6wrupXFQPA4oblOtKkGtOicnMZziN/5zUwyffZ5EULtQXuepYlmilmiU wriGondSfJnn/DBGAw/x/8p/m+fXFcCWbMjIHpsdy+Z1PKHQU081uS6ASsfx 1BBVnWNKlxucECgRUCN1VopIiOMMlVA3Nb945ubNr/+mxnt910Bk9ZVe99wW 7ssJEB6758/X3xM151+YfsO2A4fWTyy1Qxq0JY40znJWVXmVVr6qfpan6lvH er8fShxds17DbTq87q4d6bgyNwy+qbWir82Ducq3AtlH/H4t2WXaZzpq4k1p aRkm3rJHK7j3EJvxsPmwKUSyxWxOn73f12sOgCGwXwl1oiMKFfTZoZMH+yZe IXwxr/B8miafX8mdKoDOAlAKwFwAHxTAGwXwUgEgMV4A+wtgdwE0FoBUAGIB HGXZBsZcXIBYA5OSFZB1sADOsuK+ApjDyvaxdhtZ1s9a1y8e6YOHtX3N0CcJ FynNr68XX22oP7e4fgAv8eXz55kBuEojkXoLXdUSdSXHPqz5nYbbDpBrhX4B ttjA4Qw7n3by91phlvgNkduiofqs28CBg8M1TRkZW16NRCwiCTA/gpAb5AI5 nMVupTlqRBMCDnQrFq2WlxPfTKyDO6Fq/a/mW8ekTY31JHZ+99e9v9vasqS8 n9vaVX4g4Yd+UKAY9uSJExPl0Jo4nPjk24n37paBu/WKqqqirsSPq8uoBX1t 8E34lOGOixQpXm0cwSZutRl481GH4vY4jhYX7/fAbg/TcyaLaJRNHq1RxcFc 9H62EWmYV93UVD3i4p9LJQfaUilmvYQIB9lvP0GYr/y7RgNrNf2ajzW8hoe1 fD//Mc/79uh05sAezxHCZ4hHzP5syL5FUIQ23Uy/AL3CLuGswAtKdnDGjcJW gWsXIEPIEsYKDwmCng8LHRzJEDOkDB6/XkOv4hEP2EN2tNwwxMPQG4aGMFSE IRIGfxheD8PRMOwOQ2cYisMghUEMwwdhOBmGfWHYxfg7GD8ym8Mw8f0wnGUN 9bE6c1g1LBtkbZ1NdRBh3Eh8f0QH2DoJg24IZIeVbiT2XlwwjDTUfzH1xGVB iE4qaRJozif9F9SvqV9jY8ggBC7FjGGUiHA3XABf4reJP8/JarxpwJcECvhz 9U0Pfbk3J6C56hfxk68lftVQMwIcBvoP33nPoXRcQ1dilhBA/ckkeeT3SlUe +nlO73nE+3imGL6fE/179U6T5RExc4PmDg2n1Tg1uRpeZ84BA59zm0Yp0LRz xAQ63pSXRvoVyyHPIYeDom0k3TQj39HCkZTFY2LKS8yChwChk2WTCKCKKyk6 dFlyytGXnGaSSjkuLEbtZXCMDt8y7OoV/wPCYwIX0gIJiAEpwJvC/ASeIzxY eCKZLBgRUWkvZgE0hgDo4giGAI5L3L/FOSRZOLh5bfxXid/+USkpWT3wyqLc 8PgQzJ4sV667ZUXrzBl87arEpz/4IPGa+Y1FYyor8+v5J2JjKpouPBR8+dTD J6emooLFKF0tcWM0nandiwhhkSx066ExWCw6fq+SIRInjtFJpTY7LaPMab9P 0TmJYsgoI7crLtEs+kUMG7xiO6e13J6Gm5gH0jg9BjYm3pPWyr3vhbNeOOmF o17o9UKHFxq8UOGFiBeGlJApWhIJB55jGbf4PDo2Gknj4zQTDUuiPBfXpyTq /qPxUyP3oAa+bIQH9PCwCeZYG62dVh7hjiQhD6ictDobixVoXBVQg0xuyhXj Cyfxm55+5xffePp0Qrxp/h0dE3u52LZD+3YOHAHTb34Plgt/+NL3tk/+lMpp 3uDbwkbNnSQNI4EfKitZVEnIXpNJ5Pc6xfAj6Y9nOA33i86sQ24T6ln4UCAv 0MZJWlhn22LjDDaPrcDG67S32RRiQ8Hk2lo59HFSHoh5gIkpL+XBnDw4lQfx PNifB50sq+RBcd4lmpdyGcw0mb1SLXyHMIWrYMaJCVVE9jpLu4WT7VBhAbPG r4loeBOvOvy6sEXdSJSWaDTBCVoWURHcZ0xIqRoWlXKvj52x7rbOZVfD7xL/ MunWm479GxS8W1kWGh+FJdHApOiT3J6cV75z4Pty04pVoHv+LxAy/xSDzsbP Zo0LoEfHbTcXRslZyBqlJo0Kili4R8ByyJR2iDuEewjFatP0FxfHbbDfBrtt 0GeDOTZQbJCkNNrAb4M3bHCKUXbZoMIGEduIPW4KuphUzp0TzzGYoiIIjDYc nA0XHviwLt8/Gcc+Obe+qrCO/2FZHo61fGY5rrIWV3ksjtVO/OSXStTyiPVx TCLi6LMQalwINWlG52ig8SLQeBFoAgg0/iTEZGSkAEbKQIAJgBQAMYBmj8sc gDkBOBWAeAD2B6CTZZUAFAcuDzBedIYXYUtpxSWLHGDIUpfZnrkhk6cA4xE9 koc3XYQt6qqPABdd8LKgQtc48Yt3V61dPjE0IQrNk6gCdLRdPZMCyt+e/0vi N+Nk4eslUkXjp68EX8Wln6oiyYeIJHoyhryi3AB7nU6TaM4Ckc9S0jJmZHn2 5ohj8u9Pd2rvE7EIJWU4lFuY28b5CS/yCCB8v02RqV0UQs2cQnijEPoKobEQ MK0U0p9gkllMD8dVI5H3NDOGd7znS0qoLQw8X4HAgXRrdBiDc5bgarid3hkt of7QvaGHQ0KBHSK+Ch/HZziyHJxZCJ4YfPUZjMQtxQbcpDK5NVAokVFwEwRm K2UaFoeowUiYCQ0zbIvudFjsiC/cgsSF2NjgAvj2iq3XXb/u6+23vA1jq+Yt CmQ3rPjl148/Vy75gbw38VBFVeymjoVXP3pHx91fKT/Uu3n5yrrbdh5PrOrF fRn6O8IVMMvJIn3KXPdbVkLth2SgO8sQqRE53vQpGpPvzeJiy8Ehc8r2U3NK HhDF2blQox/87JjoFKPs8kOFHyL+USY0wnzUJLMinP7HLBa71JRGRmdcwUCi tiBcSjehxVcm/nrFooUVFYsWsQ0odTkDwoKIZuaiK5BWccUiRAUamT2OkVku TH3apKQZy9gWKEQT+7X3mPbbbF6iuSd0JMy7fUe8pvTDRjhMlHxyI+emjP9q NJcRN7i1tl4lRPwoEN8Bf54fA698iOdDbz405ENFPkTywZ8Pr+fD0XzYnQ+d +VCcD1I+iPnwQT6czId9+bCL8XcwfmQ252PglQ9nWUN9rM4cVg3LBllbZ1Md RBg3EpE/2fFQN435oLCeSP5wEPafDsRQ+iwWq5fVNXn1fIkag51GCDg3gPtB DMSCuCoBSykNvTCqp8HX5bZwwuPT5/9r4pu/WjQzs6rKN6P+V9Ky/gFtMhgT NvIXtjQNvGebVZ8I18+0Jr4yKhqrwhUbi9jYyD9Ksslbyi0ijcIcdsMjaWbf I5mPZztN9yuc067oM8rsB4nYr/gOuSRXG0fSER7T0dQPav3aFi4kwSIJ7BII EkRfluC0BLdL0CPBHAk4RYJiCUQJPpDgDQniEjSyAr8Ep1h2vwSdEkQkGL2z ahgS5BrVHZ5nEZnqGc+pQQRzjtHoiIDMmg6QYQa7YBZNtjJe0WWoBo+ekel1 clPEDDqVRH/o0AS55+7effPtkRmwuTu2rPhK2IzOMPGV6PKt++6H568vqhrY +p15nHdBpGpg6hS5oil5VqXdjOg4hf+tMjWtxLe3qKg4MOYR+fGxouf+YlF/ /3gRONFi80/R5TyiBMwcmDk/18Dt4gQbzylGsYzT9CtTDk76OKMkQ6QmYENZ iwfp9gOxM6PfqRRl+il9EOn+g5n9yphDOYfCHzvNNjDb/LYG2y4bNmWjTdmc 5TEnYkRuDDwxSI/Bp5/F4FwMXojBszE4EoMHYnBHDDbEoD0GdTGoiUE0BgUx MMTgbzH4VQxOx+A4Y0vyLIjBTMaAzb3L2vlmDB6LwYOsnY0xaGUtyIwBG/kR Mr0WgzOM774YbEk1tCjVWbKnd1lnL4zobEUM6hmPJ8Xw2xg8n2LYgZ0pg4xr UYoLW9qL03snNegjrMfbY7CO9TgvBtNiMD4GKAwhBi8ztqcYGzIsYQzTY1DG GFBUH7GmXmWdJiWFg++JQXOK08PaaftwBN8expSUAbaiTRUlu0kOpZlJEccR ioGTrcb3Ugx3jBBzFRtKclqTsJWfxQBOMcbDbPqNMVCq5jG+0IjxvsSmFY/B V2PQyTqrSk0Xa3NY0McK5sSgIgYkNnR+0XDxkQX7NIwErlGnGsM8ozkuz/If Zvv7vaW4qN0nj13XIAB8RLdo6NAspWxvgVSWYSXeAZUveT7rio7cs5WmDlws /ATbhOAEnh9nGxccx3v4CWhkX0eoGIfP4/hML4L0xRSgGXCk3CSGBDQUGN67 XfYk10EP9dWowVmq3ZzIi/o3XdHGRWYkU63FVw771d13H5395Xtv2RmZgWEr xL+zYKIvMRnBJpmbN3AO8WbI4W7btmfPwT20nJ53pnZ5mWS7YjQbIY03WvYq WtFDAaMozVTmcd2nEKfBm+1di2ji4Tmd/TZeifKAIaSJz+JxG5cNZ7PhaDak tmupTQgTOFG3aQxp6a8hKYj9uQP+poEdAMucsMsMC/TA9mW4PavTDO3JWBSR N7QXwd2ZFt488favX7jv+ISxpTO9UllsRmfD5rUTq49jPPnrP4B486JxV0Sv an720PEXtk/evIHO0YMRxVUYLeWCFhF2b1aWX2SnBER/v18knClXsDyiiGZu H8dRaK1g4KpJgatZg44KETb3YDA/2MaZqGAWIJKaDmah+/Icshyy59nRgeXD onyw54OQjw4sH07nw+350MNCBE5hYQLGFW+wWKCRUTFqOMWy+1lcgCHDKO91 ifM6p57yJr0XSvJSJR11rPC0WQcejYTjfUYnlmW501JObKQqXqp5liGtE65K 5E2SmB+jupbc1u2+m7o3qllfOzWkWfx36LZuIL5t3/1MsdhpraZNsxz16ogy rcPUa9qVOqa17tEKxAtpXvfdybNaxeQz+3b5OAuf7evgHJt4xcxDuiaLX8mR bOjMhghVrVG/BbBjgFdx1vQw9PTievU8VFWt/AkaWOfa4uLWwRHgfmkByVns 5LbY77MfsfOvaGCL5j4NR49CVeygrV9yAkp/SeOQQpWOGz723HRiSkZB2rQr 8t86+N1fg/Z3fzspnxs68CwwTUyUP/ENeuCJ35+ejiXOU/3LG3xXcw9GtDlk n5Lhw6DKu1mntet0Wh3VpSgiBZECvPuIT6fx8kbzEZPG5tWZJbRFab/W16eQ A5qQZjVn3K/rsylu8wFb0LaCmxOCZCTzyfNekQJZUi2i59i+hlTQWBD3N6gX 44rlrZoi92xZkMXTTEDiPF+zr8fHG3yQTnRg5NU9YB3kaLUOSxAuEyOC+tTc s1KxT7/wmmPGwoS9o9qVWbsUXueWmMpuhj9p9L7y9s8OCAsuPLd4pgdDyYpW ft7V0zOrLhznptcpeVUkGd9z76E0XKRJucKUfsTIu7gjYHIdsKVzB2y9WsXt 0fYWF7/hgVMe6PSA4oFiD0gsG/dAnwcaUsQRoD+0SykRz6mBcIm6NRmagoPN jk6Ne2+gUv1R4tsd073ua1uHA1o66gvfwlQyNhOuQnTMJQOjkEP8340czxKJ gkZGCjS+GDAcFwNGyjklf3kcBoxRroj++LhtGC/ExAz+Q9xDFPCCMmgyZaCm FJgLMowmY4HZvM3jtXs8XpPRZDZuBWIHIDqbwykIj2jMwbz7sjKPeCEXymA6 8GEygVQTngDyerw6zW479Nqhwg52h2J2RBycjpcdy7le7S4tR7SiltNpFUmD YODhx2iWcdNl0MrwGcrniAxbZGiVAUm5jIo29qoMyaL7ZFjA0lsYA5b++BMZ XpDhMRkekGGHDO0y1MlQI0OBDB4Z0mX4mwzvIp8MzzI25NnA2JBnygi2z2Rl kDL+irX3zVSTd8iwMdXqTFYDR+VkXe9NtnxphU0ywAoZFslQIYNPhkEZuNdl OCnDPhl6UQdYgZ8VDNF3saIOVnoNY4gwHrMMy5Dv/RGsn9dEkq7IIMpAZJjY l0p9IMMbMrwkwykZ4jLsl2G3DFjaKUMjqyAxNsWTZDzFWPpYYbJkeMO8Zs3o YO8y2+XLxo/JX+MbPifIvEzDoxhHURer8Y5bPO09k8rQ9xzq19RbXVEay1Rg zIPOKZp8e2aT+vYMPkWdqVzU6cv15eMYJKdHMisyOzJ7M/dlamgEBCnEoi9z 2KxlE8YnszrQqgcryZc+yuD1xLNy6Rj4fqgoPbbrvoIGmJwbzU3cO/5La2av nJIvjy3KLbzOyr1Wf0VVldPiGHNn4jjcvMozpapq7JILa27bOC9aNDkUnq8i s24xIvMYOKmsyPZnZ/lv1enRT+mzsrM3G9Lshmy/IU1Mk9I4nT4t26/JMhtA zxsCviNZPHDmMYL1iEWv0Hdqig2KYY5ht2G/QWcUDHpDFnLr0jhFl1bGHdD1 KmPMYdDxgQPhwvBqzkxx8SEsMh9I61N81gNO2bmCm1IIciH4CiG9ED4rhD8V wmuF8ONCOFkIRwthXyFw1xRCRSFIhfB6IZxNUXcVQm8hdBRCQyFECsFfCOZC mHQ2VQ9J719SoYMxfcAOFl9KETvZkaLEjhd1lyjXmotVh2nWcNHQr2Up2E2e 15xL/kbvjlBFOaO+XXW+hGapwmzVF8kaqiT0DatNQ7/Rh8Rs4MYYwJ4NdX7I 8o/1c1uz7s/iwhjyZoFG79CH9bzqAlDnGtQADxEaLu/KYYQr1C0eqEJXOPCX vMRYccItCUH1i1nQCl/ivJjzXNvCvOPhz2qFRy/csKwsOOL450Inv3vYY/Ik kriKf4V5zBJSAS5lmVh6ryCE06W9WXl7icOdlaOhPz6Gx+71iZP2KumZ5iyw 8mMUQ3rZmC3E4cuSwlq3P6dUnMJ9ZMuxuad8pFfMer++Qn+NfpdeY+Cn6tdy Ez4yFW9xK8SNOxDF3cpJU2FEePjy+eE0O+Glt+dRvufVd27Ymc/5lxfXIyly ftSP6FcIRnjH+JGRe2UitGjXarl7tXDEedzJPRZ6NsQd8R73cpqQIxQO8bzZ 4/dEPLxBYyk2WMoyJPT4WvoilwkTUzJqMribDLDHwCLX5BawIbVCa+oAzbo0 QPc3AjPmibmpGzXrgCOY3PlMVA/eKQjwyR1QkgB3ztsDprX9id+cO/HO18ZV fGvF+p8e370c9E+M+9G3xcyK6fNnTK2ef23NjYu3fXvhjjMQiwblW5bd/dGN zfX1UlPBvDWhQ0t2f2vayum1d8UXrW9a13/zis5NiXFXXD11wa014zPVU9g/ Ixb4MEqbwqK0uA/MPvA592C05j3sU8w+vy/i43V8FkbtJozcFIzftJnaFdz+ LOjMAiULirOYVo4whqGFwRDt/On6+i+I0lA+ZRNKhT9/NlXVyJ/eMts9pgos O24boX9V2VWLL2yMjXnwYfVXfc1yHLWVZJElSoH1iG8P4Q1HHHt01kUCEEER uHSNe5Og+IUODkdsNRzIyM5YwaVGOOI1I/pbLX1xRlWMjPu08CMO9nDAV6Gt AV3MOlsguWkY+ds2rpHVInLsx+0dMBOWJbYmnh64I/XL9sToj1595UyRorkq 8UDiB4mzif6huXy2zAal4IJsKMkgMPgJIfwu3LXmcN1K5Bpbg+2ojbe592aQ bJ92r8Gcwz0CmZnZLzmhw7nLyTmJWCxyoijhg2engIMm6wwxRHIQaHN8hux+ ncId0ga1LVx6CAY/C8HpEDwVggdDsCMEvhCYQ/BRCN4JwVcZcWMI5oVgSgi+ ySh7QlDDsvYQCCH4Cdb/Mat/mNVPH1GzmdXEFv8UgpdZN0NNyKzyg1jwGqt/ mFF3sN4WseJk84MheD9FX8Fa/4xVeZCNAtn8jNj+UartB0e0khxnJKRspLWG +vpmimtFiqsihE4r1dnrITgbgqMh6A1BRwgaWB9YGsWyl0JwMgS7Q4B7LiUE xSGQQkBYTayzn9X5IAR9IWhMVRvyFZeLM4Y8xeVPxS4feVxccvnXN4ZOt88M RKPsRcOX5fo1Z+pxSxhJ7oqi6HDODL08NyYdeHM6GDTohP/4ZLpYpiJVKuIP TihVf7waOolxONQXMrlZA7+ty3/yydd+vO3ZCZGCqlD+lP733hvfjKE+t3nx jB+8euP8SNmYaxf+9e7FA73zi2mE0T34puDTLCfF4FAy+ougJQ80eU/ncbq8 E4N/UPINxhl/csAOx4MOrsYEi0w7TA+avmoSMkxgcuQVCcSNm2I9L2WeGHxR mWfzlmXS9+RCe9wC0e/Wc3q9WQCbIGj1fPoeYssOHJboG9SS2QRFvGl3kVJS 1MHl7XZoDYcxStGLekmP6DVOv5K7pgQqSiBSMnSCddGbvEh5WaZv89JjhsX1 EfXAQSbMkVtYrLcGcR63VCnJGh9OQ8my9x80rhODr7J3+MzF/mLu6QiECycU zi/kryx4poBjAEn33wgp6hu+uqCl1Bq45P3eiRe/3ytws9r31PiKNFOnjodr V21c9Ozmg90fP1u/pcIxxjBtWtZXv7Kw+4ZvbXl0Q+L/+HMspfC1RHxVY6yr obLjqb6DP/Rl5CdWPfAvS+ZOXlk/rePJ3ifO0RUig2/zb9L/AQ/zld9nmNxz cQu2ze2xu92eDCPmTKkN2BEPLHQvd3M6q83BNmLEmdyCHQEhuQl7mAi4Dcsw edw6TZ9tt43rtYGN/uBrsytme8SOWzGffdRWjNdqFC/uwl7zwTd98KAPbvdB sw+qfBDygeCDd3xw2geHR9CROPE0y49nmY8Y08uMD4k9jM/Oij5LVW70ATfH B4oPJB8QnxrdNYyK/S9jYaPellcDfVkN9ElFBQ3lilGBLn1NnurDUws893k4 GB3Yj47r4eeJp8YkA3nDT/4lZzFEx5UGEmezuHPJ0D3PmRgLty+zYOReMWfA hB7i08E3uQr0EDwZr1h5IHCS4+0cx6MntBENF6GHrxXjirdqiuStm9jJzzNX wlbgZhAAetiD0SFXkZi1C45r7vx0nuYJtv70WhP+2ZsN5vKPiU/P/iPlk9+r nJH6T5WDnyRm6BZrKZ9O/bsSrI4ukKgm1w/930sgoz9hbRQyNT8gdj6LzOAe x+edpEAgZDqmxyE9oo2SGzD9NQ6ZhbdJROgmLuSZjs95XJRo8all/FGSp5aP 1T5OClQeD7ZxA1552D4to22LujsxTUhEswAv7IN7fPATLOumf3WBiw5+ig8/ +T3cD3/ibuX1fBb/ivAd4YJwQfNv2jt1Ad139Hb9k4ZFhhfSDqZPzejL+ND0 hLnE/KxoFk9bt9gete+0/94x2/mMa5t7sXsbm3GYKLgahP3fEBGjkevQh18v /IaeRyDNBd4huRwfkhEQA+ZArSWQk2qaJ9nk+2paICbypprWECN5X01rkf6Z mtaRVjDQngQDNroSOtQ0ENz9qWmO6Lnzapon5dzHalogmfw4Na0hbn62mtYi vUVN68iL/GY1rSclQorHQCYJvWo6DfTCM2o6nZRpTqppI+nUpPrKME7Xpto0 kWbrV6val7X3tN/U0iw1N/U0SUs7Ojd0tS9r65Eek0qKi8dJU5e1NkmzO1Z3 9GzobJEqO7o6O7qaeto7VhdJU1eulBhvt9TV0t3Sta6luUia19bRtbq5aWXL 41J7t9Qk9XQ1NbesaupaIXW0fn5jUtPqZmlV0wZpSQu2tay9u6elC4fUvlpa 2tLV04TP5Wu72rub25dS7u6ioV6mdaxsHt3q2OEhSLR0dG5BS1c37W9cUXHx UMnYUXz/rQMnVaSdLMOrB6+bSAtpJhJeTZhvwtRS0kE6yQbSxbjakCqRx/Aq IcX4HYepqUhvZbyzkXc1Xj3I34ktSaQSc12Ypvcm1gPlKGK1VuJXGtFuN8u1 4LMFn+vYSCjnPCyl9VezUa0kLYEcpLYzftprD2u7GflX4bOLrEBaB47oHxkZ bXE1kwBtawM+lzBuOq5lrM8eNrqklNpZjaWMQqWVzC8na9msupGnHUtTbXfj bC6ZC5mG+ZWY+6Kxjr2cFJCWqvtFZQvY6LqH5jcOR0FX7tI6Yz+/vf+PJf6f H9EX1ahinDeyfpdh/hrkbGV9tvxdqSX1up3JKdUi7Wcpa5mmVmHpSiaDZmYH 1DJWqzPvwbZTslmF9x7W1lLWU7IOtdRV2GpyJktUPbiRWXYb06B2VpOO52p8 3ojPuawOXYGvkULW/lpm4dTmexj/MCa0stnReSxl69HCZN/MZtiJvdHVoxKn ttyDlMno8CLYC/0WYekydY6jZVqkjvsfqxVh9VZh75GLZNY1RGlgq0XT69XR Uf4MkoZSuAalMpNMx6sS152mr0EqXdfpeL+K0auRch3eqXZfiRKrxu9sRp2H NNoOvejqJ9f60rVN0dtYrhPH1sE4uhjvf8V28rHWbOy7YIQdtatYupZpHF1T 2scGrLF2aCxUeutG2NVaVUJdI8aZtLtVjD85Qjq2laq2r1ZbpyuU1IZVjNrD MLtO7a0Ny9cxvg4cR8piUxr9+RLrZj32oA40sdYlvNrVkXWpWkfp1NaT2t/K pLqKyXE2W5kOdTYdOMKWEXWHLeLSXppVxOliFrSWyaB5SIYdbOwpaaTkNCyR pUwOw/JKjqToslpyad/DSLGOWfVavKesuAnLutksLm17Pva8kvXbPWKdhyWf XJXRGJpEkyQqdTI5tqs49h9ZYYlRmlg6hYSpfqlfaFajCSqvpku8fOEQd9cI LR2W6RfLZ6WKSj1kJC4Ot7Ka5TqHSuisknLIx11oAVv/Duazupk+DttSCt+G x9aBvKuZxa5lK0FH0DY042SfI7U95cGStjscO6V08XLa9UVzHqk5M5l8Ll1d ugq0hzVIb2Gtp3xfsv/VqrdcfdFKdZGLY69U293Mj61lkUDSD69DvqS/uFTn P19HUu0l7bRFXYfmURaYau/S1U5KLDmDHoYLPSNsO7VWTRdJ+fJ2+UVIlZLv F6HvUibllPcdPabkjKgeTR7R2nz0GFMxP4mMJxMxspqIcdckfBZjnkZfEvvO JzV4H4/ffKQVIM9EUoqXhFcZamuUXcOt0mu6OvOLZzcSrVOegGpoE0O/Sy2w k2FGk1p7HdPAdhVf1qo42YIzllR6y9As6Sj+Ef+cKotcNPbRPpleV6lRx2q8 L2ESTuruWnZvUW08OcermR3dpJZ1q9rWpo64dcj30zrXMT2m81jLNGWtOoIu 1TNcz2bcrfqalv+Ruc4Zkncnw/xuhhN5bNxJLV81AqUuteom1dpWqp6nmfnB VAxAW1rLaifRayTetYyq9/n4kYz2qa5TjpVqjUKmNS1Ia1dpNw3V6Gbo0aPS krLqUu38f1KyTWzkqdijRY0LpYtkS33fv6s7kaRUl7JazSqKdKgxyruMv52N sHtE+bD3b2f1Noyo1axq11KGqcO11jLEKxxleS1MVqlV6GLeq3vIk0qqDrcw f3q9apuU9j8jyxYVdYYRsJlZaVJb2i/Slh6mLU2sXWko7kjFbe2svH1IPy+V RZMqj3Y226TER8ukYwRCJfdAeaqtJ3ugf9Ct479dNv/1Xcvf74ed/SXPWgPk +5f7c3fKv73+htOV+fIreNt4s9OnbDTboxtv9jSs71zft57/6c+Qvu5GvK3q xNvKDrytWO30mVcDWQEVq69Z3bCaX7G6t8vbs9buyFy2HG+RFihuVVq51nbM CK321lArf7r15dZ3Wj9qFeytcE1bQxvX0mb3+dsq2riOtn0tZ1v411veb+Eq Wna17Ws72Xa2TdPS1r/G6+l23lTpCWzAi+O+e0qQ40cF2fyk/0lOeVKni5r/ 6P9jwx/5o++efJfrfQ0ee8QsH8brYbyO4KU8MqYwSt+jflzKTT7TRfY87/LT p1L8ZY83qnzZaIo+sJOXv/IQJz+0h5fvwetLeN29h8h9e+Cae6Hi3qP3nrz3 7L0CrWR8y2CMvvVmmnzf/Tb/Cf7dZ7bxsvJeuom1/NfsnOTT6WY95J0ymqPm j5WPP/iY/9G0DP8LPyRy4w/h3X5OPtfPy7/D6+RTZ5/iKG/2MTqaYzp99Ogm jfyTacWBR/Ga82jjo9yZFzUyZUl70ZMZVV6EXXfRP+ahZN4ZzoveiUO/Y7tB 3r5TJ+/YKcg7+wW571ae8j9za1YguntafoAOaXe2RIf0zG6nN7q7l2PtTduv M0T79gM5AI0HYHNvmnxLryBvwqsXR/ZnvA4e4uU38bmtn8hb+7WysiV2RXRL v06+/TatfBs+aTNf7588OWru9/dH+o/2C76JDneZwzHBYR3vMJc6jCUOwziH ttjBRxykyJGbZ8rPM4+RTYWyOSdoCgXN2X6T5DebRYuR/mEirU5v5AWNkQBn 1PLNfoWYTFGFWG1Rwhvkl3gwm8HMm80V5gazYDCb/Tyn80FWhlvnzXCIrgyr YM8oLB9Tnl+eWx4qzymXyrPLfeXucke5tdxcbijXlvPlpHxOKcStNaRm3rS4 DfB53bR4qVxzgpfmxkvkmrhuzqLaYwB31SE1zm07AWReXNh2gsOHtXLhotoT 4KHF/b5nCQCJ1zT231l3jCPT4rAtHryulj6Ua2vj0rYTIplXe4yDaXV1dfGJ NXNqKVednBVvpn9oqy+rLl5CE7uz6khNfPK1cV9wmny5z+Luxd09PRcRj+UL 9I/vNcXzg1Uj6dA9mq+7ZzShey1eyVTySmYIY724E7m7u5syHLPRzpob4z8I VkFlra+OXrIcd8eLUHqUrWetvJbeurtHNJRs+piBSnXO3Gk1cf1cvOYsinuD mPkhZsowYwxO+7+UZti2DQplbmRzdHJlYW0NCmVuZG9iag0KDQoxMiAwIG9i ag0KMTI3NjUNCmVuZG9iag0KDQoxMyAwIG9iag0KPDwgL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yDQogICAvRm9udE5hbWUgL0JBQUFBQStUaG9ybmRhbGUtQm9s ZA0KICAgL0ZsYWdzIDQNCiAgIC9Gb250QkJveCBbIC0xNzYgLTMwNiAxMDgw IDEwMjUgXQ0KICAgL0l0YWxpY0FuZ2xlIDANCiAgIC9Bc2NlbnQgODkxDQog ICAvRGVzY2VudCAtMjE2DQogICAvQ2FwSGVpZ2h0IDEwMjUNCiAgIC9TdGVt ViA4MA0KICAgL0ZvbnRGaWxlMiAxMSAwIFINCj4+DQplbmRvYmoNCg0KMTQg MCBvYmoNCjw8IC9MZW5ndGggMzg5DQogICAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+Pg0Kc3RyZWFtDQp4nF2Sy27CMBBF95HyD162iyqxMYZKKBKFIrHoQ6X9 gJAMNFJxIhMW/H2Te92q6ibR8cx4fOzJVtv11je9yl5DW+2kV4fG10HO7SVU ovZybHyaaKPqpup/EL/qVHZpkg31u+u5l9PWH1q1WKSJUtnbkHDuw1XdLOt2 L7dYfAm1hMYf1c3Hasel3aXrvuQkvld5mhSFquUw7vlUds/lSVSG8rttPWQ0 /fVuKPyT8n7tRBkuaJ6tams5d2UlofRHSZNFnhdqsdkUaSK+/h+dOFbtD9Vn GcZsPWTnudXFCAYwmwAmBAuwBAOYAtwG4ABmDZgBpkybc+sZ4B4wWQKWrMkB D6whrNiHsGafKeCRwONsCKsRdE5AU00fBx9NH3cPoI91gOiDrXX0gYKmj8Md aPq4OSD6MEIf+wigj2Uf+jhGog8j9LHsE31wO5o+Fj6GPhamJvrg1IY+U5zA xPdhhD4mPvvP844TgKH9na/qEsIwWphtjNQ4TI2X3/nv2g518fMNoOvDaGVu ZHN0cmVhbQ0KZW5kb2JqDQoNCjE1IDAgb2JqDQo8PCAvVHlwZSAvRm9udA0K ICAgL1N1YnR5cGUgL1RydWVUeXBlDQogICAvQmFzZUZvbnQgL0JBQUFBQStU aG9ybmRhbGUtQm9sZA0KICAgL0ZpcnN0Q2hhciAwDQogICAvTGFzdENoYXIg MzYNCiAgIC9XaWR0aHMgWyA3NzcgNzIyIDM4OSAzMzMgNDQzIDUwMCAzMzMg NzIyDQogICAgIDc3NyAzMzMgMjUwIDYxMCA1NTYgNDQzIDU1NiAyNzcNCiAg ICAgNTU2IDUwMCAyNzcgNjEwIDU1NiA4MzMgNDQzIDU1Ng0KICAgICA3MjIg NzIyIDM4OSA1NTYgNTAwIDk0MyA1MDAgNjY2DQogICAgIDcyMiAzMzMgNTU2 IDUwMCAyNzcgXQ0KICAgL0ZvbnREZXNjcmlwdG9yIDEzIDAgUg0KICAgL1Rv VW5pY29kZSAxNCAwIFINCj4+DQplbmRvYmoNCg0KMTYgMCBvYmoNCjw8IC9M ZW5ndGggMTcgMCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KICAgL0xl bmd0aDEgNDAzMjgNCj4+DQpzdHJlYW0NCnic7L17fFTVuTe+nrX3nvtk9tzv t0wmyWQmmUkmCQkXs4UAEURCjJiAIYGGu0pQ1FqlBOWioBXlJqXVABFUWh01 tahtTU9TT21LpUe09e2xYkF6bM2RY5G3FTJ511p7ZjJcbE9/7++P3+/zOTNk z7o867LXWs+zvs+zLqy57Y7FSId6EYekr9yysOf4899+ACH0S4TA9JU71wSM jcVO4j6BkEqzpGfpLXd+/cB9CKk/QUg5uvTmu5fsSHx3DUJG4u9JL1u8sPvx nYN2hO4jflS7jARsS9+tROj+IuIvWnbLmq922j/xEn8TybP05lVfWei9IdKJ 0IYeEr/rloVf7Xlf9S6P0EYV8QduXXjL4uBLn32L+EsRsgg9q25f042KRhHa k6DxPbct7nFW/2UP8TcjxNeSMCBf+tERp4L6MccLCqVKrdHq9AUG0WgyW6w2 u8Ppcnu8Pn8gWBgqCheXlEbKorHyiniisipZXVM7rq5+/ISJk65qkK6ePKVx 6rTpTdeg/59+hIcR6T/h2rFn/od7Wg4Z/ePFz/QMlnYFcqZXyKEZvwH/2+h/ /XM1UGX++P/nLyF/HkfTkH502eiro39BZ9G1yDqqGx0Y/TMO42dJrDh6hlE1 8bSkGaMvow/Qr9GPURv6IboBvYq+g/rRk+gJNJ2EUffj6GXUQuh/hFrRVxDt 37tRJ4l9CG1HW1E3C7md/P2YfNeTb3nm+0fytzBXp9+j34MNpqEatOCy+s5h X0KBHkOTYD2p/UThQbQN7Sf5lqK1JM/bUVGOumH0x2S4/itejpagQnQPCZHI X2T0N+h98q1FE9E30Gk0hKrQz2AQzUDPkvS3ohdIyZ2kvtv/bxv3fz7/8/mf z/98/ufz//HPZLQv43qazFzZzyQym1Who2guGMCAFmW+E8j3a+y7G0XJhDK5 5ZqmqyZNnDC+vm5cbU11sqoyEa8oj0XLIqUlxeGiUGEw4Pd5PW6X02G3WS1m k1E0FOh1Wo1apVQIPIcBxcCRckxpm7oi5ZzSldKFGkNiIKW77syseAqZ3MGQ MZCMt5dnqFJCNIXMM1OW5rYXkFTXnlJELyW5LsWFxc+CJPEsd2Bqig+Tf6EZ C7tTpS1twZD4rjsX307SpFxT2oJBdwqHyb9rSBT5N2NhoDslNpPwoFsOuSaF mtvo35HRP9SRQFQXbCfPlraUL+ttb79SJV8h6GfwkmpeB1vEF3TOKY0pZHkB 6f6QQlZKdqYOpdDEVGmUVEQkLpYbiqfA8lkKzCmwziJVvrgImuxE3RXaYGr3 itDU7uWkRbu7xtr0jNyiwcCWwJaWNmOSOFmlZ6Z+NqftBa1mSmjKYk0uAL2g 0ZIQrRuRIEQy6XkBdFcBc2Dd1PEvYKTSkwY00QpPpX8rUtLWLuIINZKWIzHm sZgjo4MP5UchkizrMssuudSUYkpKKVcjsDwlLUyhrYEXYoNbHjoiokVdUV13 qHvhTW0pbiEheAFx4anLWlOemc3zSBApivx1LQvQDm9kD9p9ganLAluIn9J2 kWeokXb7ReHdyxZ30YECXaFGEqee0rY5OOhOmcjv1JQxmppOyKZ/7ZSbhLa3 O0jNtkwNkcwI7dQVk2mbx3P9wobbNd2s9aWtCwOp3kUr5MG18KHsAA9uEVO6 c0HS/KQDSEqWMNNS3V0raI1WLKRvMXVFYMvWxexNHmI1JwMyMHVFI/2jCcnw RjeQ1PPapi4LTR0rkLwXcXDhS9MGgylnlCbcsmUqreLCblJ7ucokYqz+dNC7 o0DqMyUltbIf1MqamJQoLWxszwRlCObRZDSmq7G9PSh3KyFNKcObhYpQYAvN URlOWaJicIjEDZbHZra0TW10s7dP4Sltk4Yd7mHintmcCwYHodkSH3bLbTTz +tDMOXInL8s+ulplDsW5jiWkGXqW61GH+yhxTwtN69qyZVooMG1L15aFR0Z7 F4UCYmjLCzrdlp6pXQHG2kDCX93qTk17qD0ldi2D8aST6XCa1jIzZZ4zn3bP tMCyhbI0aAgF69xBY3uWpvnLojOMRAY0GdYyI20RPyG10xGh4w5MoxLkCGF8 d0qso5xI6nJDGxnoX2GDkj0IA1xPsndTVuDaw1OXX59pIncwO2SoaJuTCSWZ BIOUSbYekdAi4kn1zmmT/QG0yP0ikuJR0ntdNGYwG2O9gcb0ZmNyybtCpLcc M6//B6M6f0RvMYZMgfo46wEmUbtTg63kHf9al1LVZTrcPKWNc+OMC7s56tJE iYSamLJHWULaJkQQbhFDgWOhlBhNCVPaBt0T2wOikUgwyA2HTI6QklxUaB4L vQlUVCKLmIKJKbDRKEREJ5PgnL2ORObSBqZu6cqMtfxXzMj77mVXfk9CI4bI q7pleqMpRN/2l0x+ZQRzeBrlLHdQppjRniqg4jdV8Al7kPdzT2kLEFFDeHcO cwSmBpbRjk8FuhqZUGh35wcfGT3R1UhlHKkyJXFnBjl5tv/jUp1ysY7/Phv0 EjZY/1D7svGXNvPM1pyrpW2t+2vt5Qhh8BAtvl5BFH+kRJbvKzCP6F/86PGj 7FGZCBqDxjB5gIf3XvgK571wUoG+QL0CoraVJqLFf5NaEfBKaRSJdrA7BNOj Dk6jP6iDfmTrt0tIC9o+hUEHSk7XZzTaFeirExTrjJLLbVzXnTC4IT3qhg/c 8LobHnHDOjd0umG2G0jEGTe85YYnWXgPC/Sz8E8ZPYlKsdheliTOYpEbfvUp y+t5N6xyQ7MbGlgcSUaKOcai+lgxs1lUgIW/xcKfZOFdLCrBknz7U5bmeRax imUksgSfZtOQvLZlkkk/pBmSVCcufhm5FBK+Un6hvste6Eze2zzCCiLJJFYJ +Z0+YLHyiyZYyIRRVo6c7JFsoyVYXieygT3ZBAGW5gzLaDDbaD3ZtpHL6Mh9 Vmc/t2U+Cy4JvywmP+7SmI4vTXOlqCi4HOKs4SiQ56nOBR3iqQ6XOCwOo/jI YMPIoPh+x2BlAkLVxaGQ0WKzJa3Bmqra2hpjqFBhDRmD/DerFy/+hem6rpHX u2Ybf75kcZJv4T7a/MAFsXt2YTxeOLubO/PAZlhKx66TDPozwsOoBKxS3HXI /awXaXf7fEb1zoBYgg2mQxIyogNFIKl0tbBf2FgkRYqWYfdk4wGrSPCQ1KVS 1Yr7fbqNVqnUuhj3ReBEBAYjIEYARaCeeLZFoCcCXRFojoAUgUQEAhHws2gS 1ZuNJVHHWMpUBPrywvMb6bbbLmq+1XI7jQyeYi119lTGL3tPofiga2RwcLBh 2FQfH274fLgyQdGQpMVBKOJUPpenNnhk9H+9pBTlX4+/tpD8vkj8ECUfIC1P kABp2hojaepCJWlruamZP1QTThprk1U2Kw3nzqTbmpNtnYu6q+ak29oi4WQ9 iOHHHlm/LtIWTy6FnV/vaRl5a2kyHq9bxL09sSzaNfLclqceTY9fVIcwahr9 kJvH/ZQ0tQOdlay63Q4Htu6WVKJkBGQ8YcR2zkha+yWHs5b+Sm1KXa3R8Dg2 I9P9Wkkreby1Lu1ybBBAFBy6TYLkFJbgQRekXNDngm0u6HVBjwu6XNDsAuSC q8iP5IKECwIuEF1whtERomwjjw3PTJv+lDRGNDMu30ANI29Eo4gEdTgaXLNY +2YaN+pSblFijaXMQibFKLeV467V3KTBGo1LU6bhdHaYpp+rX6LneD0Y5EJo D7eHcagQ11SbaHMGSXNWjeNokyuU3LzHPj18+vQL+389snP/tsO3f+crN8xf aziZToPz7ffB/ZfBV/+8F1o2PvHtTUSOIwuR4y8KK4jLj6cQWWwUQcQmM5g5 8NeJAOs53sJR4zeYAZnv8/ktPp+fxI3zmUWed+NHycRsMrlICK/SOtwH1a4I X89jkV+neUTzpOZ1DR/QgKZPnVIPqjm1OgjtfpjrW+Lb5OOKfGD2GZxxZ4Nz tpNXOiWXK8D5AUEAsJGDQCAIk02Js0E4FYTjQRgKwkAQ+oOwIwgbgrAmCN1B aA1CYxCqyfAMgiUIfBD+Wfr6/ATS/EuS5NPzjGowCDgVhL4gbAtCbxB6gtBM EgYhEQRSYzEIJxjRJQSzg3Cp9Fq9ujOfQS+RcZfJTvaJQh0ZQ8Zk0lTviLuO LuiorydURjKcOo52UA9h4VmMhSlJvGPYZK+Pbi6ocMyKqtaKQ5tVFY5oAXFE KxOiUpg4UVROnMhGYU3SB3eJcBd/iMevoI8RLuZqubncEo6f4IeIf7kf91sH rPgZ/St6rAUyKSMAvUAHNPk3Ngm0A8cB+LCdcD2Rr9UlJUGFwmqxyf5xwD36 x0+gFo4Wx2+cOvKnaxuK54x80uWePD8997obEvAfWMShkfe5eedf6Zh7FReP c2Xxqpbv/q85pqJiRTyuurGHv5lI4OtGT+IPCO/H4SFJa5TU6lqjUYxECZ+f kZ7QaGojAfrYZjZazGaj0axzRiOoyBD0B7GWC0oB0SNpTbUeT9Fup4hUoiqg 6lH1qk6oFBpOpZAEyeyoFZDCrNuNzEazwRaNlJf4C/uDksnWFDSUS4ZyCHCV 5cuxWtEvKW0lUqistkSyOmtLbBKygZZL2Jbg3kroqYSuSmiuhEAlPF8JnZUw uxKyXcpEJRENR6NU8h53kT7LBR2PEh/p0nr6hxqGG0h3IRpB4htmDdfHo4jI EOrLEpEOnkXE72bV2iFHNCNWYoYIeAStxeWtfdP+nv1jO/emFr5iPmDGXcYe I1ZEgfzTc4YoWBTaI6O/ldQGU22olDwiR0b/8JJBpL+fSGqttjZepRZrHUdG f/Ui+UVM0MuynvxbLUs8KviFwhIq80PGJJlgicivLi6pIBKKCHw7FU9JY4jK JzoYbDarRQF9nTf7bQ5tPG771upru2Y8Nr9n9vMbGjr8Kp8+Hq98/bqbp2/7 +ernvH5NCVStua91avW8qyNTbrv+rh1eTUn64/fmSKUzJt+0rWXTXjorW8iY mMA/i2yo/yWFuFtFx0JUpdMbnreBzbITmw0GowGBEglaUaszbpQMSr8SKwUk iAJWcwKdI6xWRxMBohsLEk86iHYODQ6IO2iX3UZemLyhQ3yjg/TUsaN14hBp /Po4leodDUd/WjcymGl1n9ni8dXypZ4weSgttcRbVMuVekrIg3jpLEkbsD2s CBUWE/hBmSJpTFopKiFthCfcu7btxnUtGzRT33orGr128qqH7roLPzrR1Dcv nZ42cv/UxvHkXd1EcL9Ixr8f9UhqBRQD1up3I6IwSONUegKtzRgpoYBTah/H oueQ91mfaLQcMqv5oOkAKthol7zPmQ/YA/bFuDMIfia7iBjKAAKXSMCBePxN Bpw+H24YGZLHWTxK5ivC6aQ3Sd+F5K6+fHqH6269Y32dr7Q44J04feqqdElb JETm9YIwF/3mqpKacGDeyKnFNXRKx5oJ0ehCMu9MGz3JvUreRovsUErmAC24 lGAVwAqAbaAXwcCZbPqCWvKC/ymplepa024Jibojo3+SzCRYYSJBut2SwmzQ GE211iOj5yQ1cRg0BQWyr5c4DPdzkpNbjq33qyWHegkOOAmQgxNOaHZCwgmi E84w7zEnDDoh5YQ+J2xzQq8TepzQ5QTJCXKSCU+yoGYWlGChIovIT9/HUsrJ yPPvQdmMQKDtn0Gw8g8dKAwpjP1WJhh+YMIWqkxWSwYBmCmvYcZaJox/+pe/ vP3K58Nnlt65e8uyu/ZwP01/dPSP6WHw/PJDcF7o/pfn3wD/T1/8cfoPWSz7 EWn7EjBmsKz4T2HZ7ouxbH8ETkVgKAKWCPAEyxLPjgisiUB3BFoj0BiB6ggU RcDNoglsxf8snu38fwfRfm8MyxJ2zWLai7DsP8Cx1jEc+1F6cVukrbNzacU1 6e62SFE1xbE7Hl6/rqKJjHOKY1tHfr2kemzQP/QQhbFLqjM9oAiSHriKr5Pm H6sDrha4SnNlqJKzc7FD5c/GSYdUL6m+s3pTNefdnagm31CVW72zapx4FTZa gkWHwByq1voKSB/pm2gfoQMTUKFYiFVc4f64b2OJVP5c6EAJ7a3RxSpVvb2k YMLiCRJ1IpNoImSm/QUbJTNNbt5vb5DsG7sTd0owTYKIBBYJFBL89ZQE/ybB kAQDEuyXYIcE90mwRoJFErQy0mIJbIz0MwkI8XFG/KIE/RLskoBkt0SCuRLU SlDEKHkJzkpwWoJ3GeXLjGwDo2yXoFGCapaniVH+7Fw2R1L8QVb8Jgluk6Bb gmYJJjPqoiw1If4Do3+DFb+D5cvqKo1CC8s8Vw0Fq0Z+hfdfnP3cbN5ynR8/ l1fpgezryfWem81arjfOvuHx7BvuyKPMr8G5bA3eyGZImpW+GMkuwegsrPBl Z7KEA+yFpGzd5Mb8nQSDEqRYHhuybdOYpREpmXQnJTzGKnRYgm2McKUEEyQI ZEupk4vok6CLda5ciiXbUEPsPXpZBXKxbpbyFKsATrHoHlY8KdUggSoj7zr/ vi3gUrh7KSru/LtEVwbQl8Dnv0/992gXZFQ7KlSirpFTTLnLnzOZ0YGIHQba 4oODVOoQuTMoQ7l4XBzuEMcE0CuobvTES0qiDROg8pJSX1tPp28vwVcJnVpf i+rEOtyT7E0eS3IoKSYDSU5JKAdftHuaohR0MQjWTmFXR0e+oJJFkvUfii57 bU5+KYLpRW2ReYtWL9HEZ8jOxctklVwWZTsfOzzxmpdmrH0wcQ2TZ19b01Jb kx4va+bUS8Sb7MmKt22N1+7bKUs4jBrIQyQaphF50TPSascfTEhzSPss0oFS JxrxIUAHCjYKWjggWD+UDG6/G/s5t+DzCxtLExY/8H6iovlhmx9wjx+6/NDs B8kPg35I+aGPeQN+EIne6IczLISQ5lNe3Lm0LztZdzLgTSH3rGHx7JA4copB ngUdBPSQTgpebLWgcr7KxpBPMYG0WEzH50+Qm2fyDcMVklRRcfXV8fFdcguM 8N21wgQWVlEhUXtnxlrhQUPSEvLmap1xt0I87HrNhSOuetceF+c6hJyis8fZ 6+Sd9seR+RbDWgPmDGoa2ufktILT5bNs4iQvtwQjH1wl+SDhg4APRB+c8cEx H/T5oNcHJPx5H3T6IM8AlDOPib+vIi/87pudHUStON4x3NHRMEyQbAa7+lus i6x4vnmlGXdjeA/DXNvLNnyPADfDvfAJcLQlEVPyhJzlgTVISQbXEwBrVyjg vcOnP/7Jptfi4ViJtfjOVZv3PXr49tD13/eD8+0PwNl7Y2mytuGOf9v2+qd7 w4/cjjIIcCNpnRCKoX+XbiraJQh65czi+cW4OBq+RteuwzpleLdepddHRYPN byNqnE3c7SbKGzoUCj7BRZ9QmvVFwkYJ+Sv8yzA2g4k3OxylGzVSuYboYhXQ WQFSBRBHxxjSqo+/SZmYjIIhqn4NkiY5Nvz+cB1pkgzkrSOggTqYJ8e4Xsq4 BU1OqmHonN6mqHqCGv/NAx7KwSYSQ3sUqxJ6sUkV8AaaCKN2RDvQaob6SXPV ZMZQWDbXsKDqDDeSFgwbFXJbchtL7xx361efWfi198F//Q11s7W6WPG1z393 566JhbH028c2zbh65U01jbt2bVy5dqD55dvHV05MzGtae999ade6YCtMmtR7 w6x2MvYaCcy4IDxM+C8l3U05T4dyXCdRtjOZKasdN8OQGQbM0G+GHWbYYIY1 Zug2Q5EZLGbgzYQLGcU2M2FEM3SZodkMkhkGzZAyQx/zitRGBGeYl9Dlk13E hRkmvEj+yrJ0yJVlxM+vyIRwYcxUWDUnZxk8P3FpkqKpa0c/FL5DZE0J3CrZ C/0HDYF4oCEwO8AruUDAYSyQ9LyGIqFtelOtxrhdwTu2I/PXDGD4rq5fX+zv Iy2HisViMsCKI5a1nIQ4MAil3M34zggsicC0CBRH4FwE/i0CFKgORKCfQdwN zFabw7cU+5K/s1k4PMCIctEiAb4n8lBvIINxO8fmnryWycyaWfMA5WLi+uXI afH4yEeUkcmAlS0CdJiSqFk5bbS12AabKBOHzaAKGExNH/PwGg9D9uP2U3Zu jX2Hvd/O3Wa7z/aijSuyVdu6bads/BrTBtOAiSs21ZrwqyKsETYI+FoB1gDs ApgJkGfx71hN5EF0dcfqdiGAjCIK5jR9HCxERouJ+mqqi4tDNUErERFGBT6b fiv9IOyBqlufavGUacsjC9Lf+ff0f2z6rwefus903ULsnt/wiR8ehjooh91F 5nHpxdCSHki/PZQ++XjzZ8waf9Vd6V/cg5gN+CT3BRnZLhRG70mL3Ls5PSf4 dmtF0yHzsxZEROqzYC7aKZhNB/Scm4iHA7YS2zIc3KCSkAq0HHkUCMUqIlBL YHpzCUglkCiBQAkQ/2AJ9LIQ2dHFwjMjOLfmIJtA8lYeXCNVVadol3zO/g3T mT9n5zWE/WEcCwAqDBRuK+wrTBUKep0aDHXqJjV+WnFE8TMFZ1D4FVjk2Ly+ oIM+28PKUImCaXqIzNs1ecyQDBtzkpf7Ih2y7Nyy74eAj8xfFk6OB3NhuLo+ /Yv5K9Y9/I2vdzQt3LQFxB++Cw3es4xjrp0QnYAfveq91w7/Ics5BYRzvGj/ QI5NKiibmAibeETPQbfzMWSuI7yi64/rgdN7/NYMhyh8hEPoTJs/Rt/t7Bj5 KZtnmEiVR2imKRK77Yfs37dzD6geV2HebrE32lvt3Ww4DthVat7casaae4zA GQQwAGgFBnQ6WYsgOv9cMtrIAMsMt8A4O8bvp0+kH4EHoXzVkYm6iKY8UvKb vt+m/7bh04dB9UPfz/zwKFRDgrBkARleT303/XL616+mzz30A1/6z7IliTvH PY2C6L+kDdbdnGi2NXEikeYcVyC49IfcBYYgGVnYbCYjy+AGlXs/Z90oBQ94 EGkmbOVCnmVYf8CwUS0hNRllherFuC8EJ0IwGAIxBCgE9cQjhSARggDzp0LQ E4IuFkjchLo3G0II8q0EeWpvtqlPMydxnSaj79SCjszwk4FnPBrNjj+3MqDU NxWZqk2NJu5XCpipmK9YqeAUNBSiJHcUzY61YipzKdPKVqk8T5I790XYtvOh 9etsySmQuLGzayl1xMmAa2R6LfyqcaJYObKfKL14HHOWTywjrapKN3H/SVq1 jPtP6cZgMGC12iyFlmDA0RIsDGwmQILaBAtNLYUP0AUHjrcFgoWcYPWUliHe echlsJiCvNVk6inoLdhWwBWo3Et50GpJGp4jlGoXikCE6bg6Q1MESQbkR1jN xdAKPJsuU/a5iaLrdklR11J8dwyWx6A9BjNjUB+DSAycMdDG4K/nY/DnGLwZ g2disCcGW2MwlxHJFOoY/I0RvBKDwzF4MAYko5UxmB+DWTGYFINoDNwxOBeD 0zF4l2WyNwYPx+CebHk2VszPSDHDrJhcRrnq5Mp4Lwa/yBLcmUcwgRXjZMW8 m1dRuQySXBp9XM7hd6yIgRgcjMEulsk1MaiNQVEMLDFQ5OVAYjfEYE0MlrAX xjH4LAanYnA8Bm/E4GVWQxLbFYPmGEyOQVVeJsvkXP4lBi/GoD8Gj+Xl1RqD aYy6MAamGPAxOJttm6FszWT622KwKAYtMWiMQXUMillTyfS5egxcnP8l9HJt 6khtpJuP59VnRzb//PoUsfrQLYhnYnAiBseyFdqRzb2bvauc+1lGgAdjkIrB thj0xqAnBrNjYIjlNNtLVNvVDN38M+s6/03F9MpEX5LTlynWV8qCYWK6pNAx tjLRYbLXx1ejhqMdRH2ly0kNs4bt9UY7XW6IRsUhuqwUVRGHqFRNVE3MiBnN g8o9SryJ38VjIMK6HQjGhQIsY155KaB2HBQXl1BIYLXYzWa6TkTlC/efpY3F 6RerZz18y7ipdWXBaLE7Nq0j/XZJYw303+L+9b5pxqm1MI27e1z7hS/WPr+q Jh5NWsyNH+Ffd9Yq4/HxsYaRUbhr/ySTpzCOOFSTvpZ7h2gVEVSNrsaDksMs EfXaRB/aGtAbwcRNSNj8tSUUt1+v1DUNeY97sTeg1DYJG001ErKHOV/Z7tml 8HopdJUCKu0pxcpSX2hXQEISRLmApLTUBibHd/vE8bslndtg8VuwkqsxTbLw CqwupOKoWK2pLVQjKAgFkJ13xTaGJQoD4mHOwoUlEhmetEktqdnqg8Fei9Si mogt9ZRxmwwuvMkiWWjM5xZfraVqI+8CjWvywBTomwI7pkDvFFgzBbqnQOsU aJwC1VOgaApYpgA/BU5MgeNTYHAKEOJ+RrzhYmKZEk2Bs1PgFCMeupi4+7I8 6/NJ+7NE+WXzlxHkipQYTWAKYJEVe4bV8RirY4q90Db2Qj1ToItMK4z0Ygbo vPIA/u+bcMR3F3QQGJJRhI8Pi2905vTiobHZlIz5BR1vRCG7tEbCZft7w8hH bP0+k54aYVZTasIZZIaFaIe8JEZ+ZDVxIlEPNQQ1rKmDxiQk6SCzGC1N7nKY WQ7lAeIspkPNTSOMxHG/Erhvm0Dv8XqwlmdZoU5qYyJzPcm1HRjOC1Kdm5eZ aZz8oE/KWEFrSNbHx1XVVGdwISeDQ8ZghbC1+domKPhqb/q3f3rh/evWLph4 6+o75h7oeXge8AOVg08b3M/1zL1h3q3j73rgtr1vtT//JkxqKnMV3rr40Q/u 7q5YNKdB8s1pK3xi6dwn5k1ua7p14/emffTVfQ+suf2R9Kr2m2YserRjfBVF 5Yr0DO4Is3WUgCiVksn7WY9YshshVXgnFguMh0S3f7fKXLhBkAyCX8B6ISIs xwV0oI+32GsLkFe7UXIdMB6wlFoWY4ktBNCNMYnsRpnerN6UczdEINf5dETI i1mnGRx/IzrWuUxZqrp0d0sjH7QEcWtwQ/BskNOFPCH8UOhCCLeHloewQmFT 4LmKTYo3FO8qzimEXfxB/mWe43kLjxUOp6dpJ/cU9z2O446M/odkcHmbqrlG DvOEu4kkoOWSzotSo8lq+m91O10/M1ktKFRYYr18b0yuq5QwYfcD+36YThMs X7kqPZGovNX1BNHLYH7eSq7+ofSZH76b/rH3P1dWxON1C7kfE1C/8MKBSe+9 +p0/tJJeWMTN5SIEzxOYjF+Vqt02TUp40RhEL0kib5SUplpEH9yA/gWkVYJS qTQ6XrAM7PD1+wZ83HHfKR/2yXDK2KT1uX1Y7dOGYORUCI6HYCgEe0OwIQTV DNDyITgbgl+E4LUQ9OdBVxJbFAJLCP7MUt0Tgu4QtIagMQTuEJDsjpJkco6H Q7CN5biGEU1guNfCsib5DoRgK0u/kiFkOd/zLO0OVpicr5vRf/vP2Tr2Z8us ZqXl6rj34pJydfxdCN5i+Luf5Uto5oek741Vd8X5bHUH8pK78xrgMEvYnVdF OdshlmQHe4H8BhgvVzRbGMy8uELyq/dnX11Oqc2+utxsvXlViYbAHwJDCHDn lUTi3wMG/wA0fCnk+Ad4ZCwqToQtEZjDVVXElRzJLWvW158lfxlO1KGAGMDI IBqwUqASkEg9IsHsY4bXccKlAVyktbtlyeRxk2/aviHd3No9Z+mUWuoWapzL xs0oMM+Nj9swZ/XTxVlvopZ5qc7bAmtxG3YTrPCM9NV7MGAtuGE+rAReB0jg AfSQEKBIAIsAvABnBTglwHEBBgToF2CDAGsEaBRghwC9AuAeAboEaBZAEmiy gEDygPozAgwKcEKAY8yREqCPkfcwunVC/uLwFcAkbTzSYOKvEHke7SATTbAm iNtGvsAKWPsE4fPk6CfCEuFaVIQqIC7VCBy3PuCzBAK+inCMtmYiwOmFQCGH fXZhe1iy6cLbnQnbwdh2O4cOFhUexGaNnloyZ7r9TfqDurYAXBMARQAIukHN JP+nfb/14R0+uNMHgk8ZWetOIK2oJcJN21ehXGeU7Lp9xrhxJRYTcCwBPQmQ EpkdE9ScN5hbGvl3agshEUMdVVXkB8VHooMNI+8SeTzMNrfMGjbW069set0s VETXikNZAf1aGZQFbM6msgDR7lpLu0vXlA6UnioVlnhf9mLeZXHtcPW7BlzH XQrlL6MXoniaH+x+UPGg451w1glcwglAmnU1a2FEn2RebQ9SswoXyq2Q1GbV XmbYVproNpZxkJPJwpLF9/b+9uSumQ+NPL3wOhO1ViU///zF+3/99W01htIL 112VeuvlLVUzLYDg1vSzG5vlfaON1GaVSt37dlH6V/u/xuO79u984EnxYgmN VksFQSN6SXzR5hZSkoZnWxepkKYy2J8V1AYqqC0DvheURoPD78AOWdR2dMQ7 koSlLmKskYsZyxDwB7DB4B9jLLY7qzhjeSZvG740AJtaF7dkmIkwVs7NbXUt rbvGYCKMdf+c2whjXewlfFUy+rHwHBmTheg5qUjhsrmw0u1yr1coLQqF0q1U uFDAQUBAk+Ng0MUpzDrDkdG/StM8/ibDwQK2TUvJBfuKFK2KbgWHFGAUFO5e qXCfUCTcinV9LmWvWXJ+t2CfOWReiVERNEhFECiCE0XQV0SXPW5b0DG2MFd1 OmeZo+9Nx6I89hoGyZOtzW2uiG5eOwSUuQqJdDGG4KItwvKQgMyv8FzXbGPi wjdM13WlS8gocNy4AG7mODIY4D3BSzr8/D5+04WduW3DjdffUB6/UID/k4bQ 9f7RD5V3k7ap4H4hjfb6IO4D32wvGLzrvG95P/XyXp/X6bA7WhxO+31qlUVt t6pVJcWOluL7BN4iFBcJvFKpdjjsToWzKOxoCa9XOC2KcInCabM6WmwO63qt xqLVagQtaHhQqp1O5x7nm07eJCjUSAN2TqPVqJQKnl1dQC8sMBhiKIF6MBJF URI5LScapLjhFmwjcJQobiajxx9DtrBSodYUHCz3GjiNuT0BMxMEj0E0Ac4E KBLwt9MJeDkBdyZgSQJaE9CYgFoWp03AuQScSsC7CXglAc8kYE8C5iZgGiOQ RosTYGM5DCSgPwG7ErAom0F1AkisKQE4AW+eTQAp4ngChhgpyeRBlg+pxBss 2SaWYTEr9G8J+DgB75FkjOzuBKxMwPwEXMPoI9mK7fkby5TU7GA2iztZzXKV OscI3mDv1p+l6WYFywSkmN8xAjmHJXnvVswIlp/LlkHe/r4EUAHZzRqEvMvh hLQK9iZgayIT3MqkJ3nxogRY8l63n9E0s1icSAAiL3ImAW8l4PUEbEuAyIKI +B1MQIplRkJO5IXMTkA8Af7EFbaGL7jyuvptGQvGl9gQvlQB+3I0cUW9LBOP GhqIFmWkqldnRyJni2Brc0TFctJVjWQ8yQzimc2s0exm1pz9IedlDkoAxmTS Ee9YHe/oqGRicKqlCDY4IOGQHM0Oblx4eviuMNdaBLYicBa+V4ipVR77XdDg mO3odHB2611WnDKDXQ2/UUOpGhaTfwIwJJ97LwruqZGDMEuIfTOrHQSlQNJc gTNLHxa7OWnOGDqUd0+aURhI31OSPsqn346kFxRffQN8vtFPcMaH0yKzZ2BT V2XNF/wXlTNnwi7BO356x/n9XMuF5/jNtzTF43P9cy+cw7cOLpwWjydi1dtH rsM/eDg6roxKl1XpZ2Ej+hGZU2ZLGjqfaFKSYGaziD0ziyglpDSalC9UJY6Z oMsE1OJjTLI9U8MZTHY2oxm9PDZhtJsvnR5WXb+4ZcmUminzt9+f/iAzBSRq 72/JYCtx9KTwMvc0KsHCK8hFyt+s0ja5XH4D2+39iPMDp6B0Oq2CoLBYzFbe GgiaWgL+4AOYs2DM+QPEt5knqm4gyFvNFlOL2WR5gNAKFpugMJuI32LarFJa VCqlit3MEgz46TljvbLA4XKHS5BSe0hnUNpqrdOsd1o3WXdZhXGq6ZT0yOgR 6WnTNbxiN5lNVUorjwUdW/MrzlmNI2gFRnpQcXqdVKpbiuWta/LCnbysN8B2 qMkLf2tYbIIRyKuB8m43qrPKK4CtTFvF8jkO+ZhH72XnO45F4PW8fW+dY8uC l66aZrjmYm7KY5qM/a6DcQ7hm2iyg9ow8q13qnw2GWOciw16ZFg44nSzeTy7 p7i8KEDXg/cKhwVMYHFxYFoAR8xQ64e7LbBYAdOFG4Wlwm7hkCDYBMhjEArk CX9wjD3GLH8Z7qBuExledHp9eW4y/V70ZPpsOH0yWD0V1s01D/2k0jthInzv buu/fC/QBQHuLsXGC/8bt4w8hz+7sUFXWSl5ykc+hoGNDaWVldcax6d1cGqO r66SYKzu9AzFhwRj1aCpME/abpla+1GwiCCM2qkWwTZxt7dkl2HyTpvXxpWf UvNdNVCTPMV5FAlbojixKcHvKYNNOliu2KPAQYIxilDDRidyFnGKslMGuodj ekJhmA6j0+HEdDg2HQanQ2o69E2HM9kQcTqg6SCRIGk69EyHrizFtungnw4k sSrblxf36m3xo8xeRe1Lw3HSibKUHB7qyKwpHhuO08gEbCYAe1CWbtJA5dlK /H4cvsnDFjtwFfAnFfykCsSqrqreKs4Q88dmxzpjq2ICdXbGRmO8anZpZyk2 ePyeuIfTUFOUx2RtataAUwV7VM+o8GwVHNS+rMXneUB8Zul3NdHkOuSd36sz +0EUfEhekmNPppmNk02+pqJklX1ckqNqW7IK1WRpggEybkoq6BZWZqIyjVNs XJ9+7KfpTWk99sJ2qIOd6R+em3JD5Gcvtd9+GIwP33TDggnfGK9t6gNNenv6 D+kH00H4HrTD1nS6TbDpS5O+R89OuLrtfwsbtz8Bn8Pd8CgOpr+ePp4+l77l 6viEDelfP7jiW3DNzysq0s43rraPg3nvgw06Rv6LED2dvhrc3HQx5gyZ0r1P dlwPFWYqxR4d/RBWEXmqRR6pAKUUZu55taTTq5/vTmRMh4huFgrnbQ0CxHb9 XH31j/L2/7gR4nXCw0RH+5HUWVYWJWJLHVF7PaYWzwPqiEWtjqiUphaVWrk5 WmaJRst2qPvV2KYuVteqOcch57Mu5PFGyqJKlVplKAwfKjLoKwDz4iGDMxqJ 1kfbo/zeyOEIbi6CUBEV9m61rqloNnTCOngSngcBVMpoWcTjLVKp2WTwgsHU RGAfk3H7PeqNBFAbDpjj5sU4xRCFjDUI1AgwLHEmD0v0MYJeBjO6GGWC0cjh PSxEBiR1Z7IoJHVZGimbTM46P6NcSbnsSF65hZYvNTtcAV+MbSkZPE110Hei RPwd7YhHjzINlIjDhuEqwkUNnw8zXCFLQ/4iVCFLvoEnFc8rMGQPt1WXcMor mO+KMvO7laIBJdhsdl6XnhsL+D9tibSl52W3woNxZkUdPBytr1g0COpbJo+L Gx32MpjY+LNFdfJht0kl5V0XOj+b4fPY43G9r/359P5vRDAZR0mEFB8T7SEC V0ub1F5Vnc/rvY9Og16PSunxeterNRa116fWkLhxTytBo/RypoDroM/DqQxq vzqu5sjAw4a7TGA6iIwG8AOGfT7lurAf7QtTHQCrOLHPo+m1SW7jPiIZveGV k1RqrzdQFvVOLk2ciMKxKAxGIRWFvig0RDNSPgp1BGyNKf1VTOk/O0hd9EzS yOrBwUEymbANkaTJO6J01pkVFbKHkgT5UBITZNcv9cAmzy7PG553PXy1p9HT 6lnjGfAIdH094OEmqGeq71FvVe9Vv6ZWONVgIK+FubgXtN4J3pnee7xbvXu9 r3mVSqJk+poMmtkarOep6T5Kd89n0a7claT34DJ9j6p7wHrRymIUH7NjoSN/ Dab1Wb2vcS2sh7fhNNzbRU0BXUzZW35+O78qT/mb1nt9/Pz7fIh6LvyABFP7 OOlD4R7Sh1YUQJ9IzdaDtoDDtx1xS3WgO+jYrl2igPfcoCEaM/6mGzj3WoWk VbjpUr1aUahYhW3rRAlp94lBkWi/hUT7LYRAIZwohL5C6ClkJ4xyGjDpiuEx 83cnBa5k3A+vbhg21tdn7d/XtahgoxI2cTCfg7kumOsh6qjfO5uopHwB5y1T m2sNTj9BbeucxO+k/qdUsFx1t2qPiivmN/EHeS7MwUcc3M3t4TDDx5l1RHlJ JAMBzMEq3kaPLfChPNUaiPCXJw1lEqN/hcLTd7+QHjgxslM2scD6lQvOQST9 zoWVc4Vrq15Kf9T3Rvqnh3OmlfPTXXADKEELc5y0dZ8jEnsrl6KnSdBz0t26 lMmsSCGDgXtesqodTiq5jzthyAkDTuh3wgYnrHFCd/Y0R5ETLE7gnQS5MaLe bHSrExrZ6Y5cyoATcO7kh3xaRD4qIh8NyYmrznyJdJGyFAVx0OWYNTLIliUq E5A3i5jzZxRvZn9pReaXS11dHpeurii/eqQgN8nQlZfRk9wRMstYkB+UUo/x kOlZC/h3oz6UQliDNEjl3YlFndm+W2V2ZZdfCoSgsBxrtDpk3SiZDuiQDrRc QLcYS+z0IgpC/ba8Y42p7LHGLnZwaDDrDgQhTwrfllmFkTemnHIRnq+vv3gd RgYy8fxN0ZLlcydo3W43Pu+G5W6gay6Yp9ZJI5mv2JrLsB28vnIf5o6M/vYl p6eJ/koaGju25BKNria4JMqQSnbBheCMEmXoSxdaRn54/91Nhdk1lvVbx9ZY fpd+ozLKv0S3TH3xu0nv/Iitrozenr4WHqW3GqIw/FgaDfzBhWyH7M8iBxCh I6oBqaFAXbCbc6ONCvsBo/dDyRCCUaIdGg1GELniEuPG0oS7BLQlkD5VAsdL YGsJ3FMCK0ugqAR+VwKHS+B8CbzGHDsY3a9IXDRLNL8EZpbAL7IUe0ugm8XK WT5Bkv6Z5TrEMp7JIuRkjSVQnc17A6O+RaYmRBPy8tibrZJcVDWj+V22wHsY zYS+EsB0l1xFD9sh18w2yR1je+ZSeXvpiDtHYCgZw7w5xui8eBLPZ5YrMU++ tTzPjpEZbsc7VtMt3aeG6DA7SnBqbk93Zo0BRMBmjg8YTLVsRbc9nOU0otqy /Qm5KT1/zzfc/eSTN64u9ftCzorK8hp58/fcDEvaPzp9w1VFicKKloULuPvp HnB4Kg//XYcQt5pwZhF+RSqMa1Zp6Olo/lPNqAZrDLt5sBXulijgVHLI4PJ6 6ZAf9ZTUeg95THt0z+iwTlRKSiwpe5R9Sk4ZtLjN9o1BKWTwgOcACjYHe4Pb gn3BY8ETQQUKpoJkEg8XBzdWJaLFwBfD+bPFcKoYjhfD3mJYUwytxdDIIuTw HcXQy8K7WVRRNmqoGDZkw0lG7mJAxfCL/Lzk6Py8BvLStGbDL8mFBO69PBdS rCUvo8PS6yxGzsedjXntSrmtlLMaYsXvyCabmZfmMAufz9LIpfwiG55rDzl8 /J9ZRv3FsC2vqOps/UgL4DPFcKIYjhVDH2u4nmKQiiFQDGIxpJhXZHQXgdL8 /UBfvoj2j2MuX1i71LyWF8MYYrU46Jh1tuMNioKPD1HueJNqklFEwhtI/CDd /E4YpWN15mgck7qY6ILfV+qauAB5QBRFiSTN2X7o6U+2wcCaObiau02jBtDR gc5HE8XxRHByWeP0P/+57faRz2deLb7IPd165L2bpoYr59QX3bHr0Rkjzz3c HI8Xt3biuTPY+V3CIR9zT6NybJNGI5FSn8/vLSMYTmU2mywKSyRSplQqVKUq n89rNltMfj9Rl0pVD5j8FpPJrzC1EOLNhM5iUZhU/lKLV1GmEl2FRWHefshh 0JfL2tLTpUdKcU+oN4RDRaIz4Oxy9jlTTsHpyKZxOENFOgOFxXGiPK0iqtPr QJB8zjIURytwZwGgAlBzBQapwrAUvxaHw3HYG4etcbDEgY/DqTgcj8NQHPrj sCEO3XFojEN1HIricJbFkqiBbGwjC5cT1pOgHSRUuo6lKmKBuSQy/RoW1ZpN mCtLznBHHo0UB5yIA4rDmIm34/LF2SuZaLPq02V7whawPWFEhTpKFahZTIOS jUoV0c0FUdmCtJmPDjHdSbzsmZHBRq0SdNTqgI1CQCow1XqoUioWWGvbInCN ZbkFP8O/QveP0XU6KqIz14rQI+Xy6Qg64sbl2Y9k6xGB7EqlmSB27uP0jNbQ 5gOldeH0U7NbR74zrTkJT8/evHMGtFQvH//t349vT1TWuNp//PPZbqensnIZ TBztnpRMVgbffLGuMplsuuan6YG2GWRcRtCr/E38LqRA10lRXhBepwZKQYE5 BXGTYQsCD2ToBgSMJiOs41XoBFbCB1jedYKccdfRo5UJWdnhs8oOdYShhh5x 5m86f5RPXljEPfEqvFMF77SnV6ZXyJoev5Vqeug7Uj1ygSuwXTK4Qce5LTqw PFqaEAt6C3CB9qB5u47rioAhQnT5yDkM+GDRdvA4+12uYMRAJ5K42dZk6C/Q l3pLy0s5kS/tj0TNwXUKSQf7FGWKlfgEU+V6otAcBSmj0OUt34q/H6aHhobp ybY4AatEf+igJ2Q6GoaHhzqiyCEOsVNUI0MdmRMbuUUzI71wJ2gM0qBkxsM2 MREvv/V8ZhWVDyVvfiZ9EAxtNxRXVrasT/9X2VSwbdldObZ+mv6XB1eO/NHV Oj8dvn9aWpxY9u1vXNo3mONeR2BBHI+AJ26FYFFwmPQSBDg9zIJ/pm+A9A35 R/uGe+LCIj6JH0lH22AX7GxPR6m0UhGkTXczu+Azqc5oMrUYRVNm4zJxtRhN 4mZavkJAioACWwRBNJo4XiHoHC7Eqw8RxCrYFEdGz0qjKlPtAwoo5qZxmBcU AkcIFRrklJzNRDrxzpzk8VCbtLZPS6Z2rUZya5biNR7o9kCrBxo9UO2BIg9Y PMB74KwHTnnguAeGPDDggX4P7PDABg/8HfoT/wx9/f9lAX359FJRNkXCAwEP iCzFEMu11wO4xwNdnowAW33J57ZLPv/tTbZfZitPdtDh3ECXQJhQo7E5s1DW Ns5WiZWXGLIv2cIaSf/kiptW8RdX2KlKxMfoSVxP0CGHbpQmcoAgswpCRpr5 TgwKvATvwgfxaXwOK5ROBGpUj65BD6I9SNAjIngEmNjHNp+sXr2gIy4OLqAb HVajhgYyuAV5cZvUF9en7c3wifDwF3OFZ0mp3WQM9xMJo0G9UgFnbiHlbsyU S6WxWW+sVSJuj0aBnaROGLQCpuJET5QtjFVIp3xGJakopU1rqFURaUI0xxM6 6NNBlw6IV+6BeHbH5a+M9XF6iQa90qRhpP6NKKsc4bzNUVa9oHwTF9efTj4H n6U93ZOqOEko+eIH/DuL74RVpC1Gz6Sn8WL6m6SdCgYAcwKOi2+g+FF5Uwwv nj/BB9LTWjM2Fr6G3VIfgohkcm1XSaJTtV1MOA8GtyNOL5I3+b7b3yQelAxM wVynVNf61hp4P49VfBjpRX1Az5GvS71OQuI+S5FlJX4kDOvCsCoM8TAYwvBB GF4Pw5MsZHYYGlj4KAt/iwV2MrI6me51llhO+TxLto6l8bMQVZ7+c6lFc8yU ebrKNVJFt62Kv1/QQRfr4kTqRgfHttBkpteyqDBBwEVcNbeD6+eGOMETAF3A E7g28FCA13k8HlzAISxiLPKZI0zMkE8NNAzehS7b/zC2CSaJI/8+MnrmscDy O0bWZ000j31t1/7NE64Srv3NwX/5bfqtjhtCY3tfRpZ8d/ej36H/jQJaO/oh ryJacyVMkCbWlh8sx9PLbyxfWs7Vlk0ru7OMKzNajOvLyyzl5WXVFii2gNGi c+rLJ5VjVXkZChuCYKL39/BeOuoW6M213vCjTh6pmlVdKk7HqSSlmZf0Yi2v exSZLUaboay8NO4v7F8VXBfEQcO6eFKh7leVrkO2hE2yNdt4la3qTBJOJOFY EgaTcIY9E0kIJOXRe1tm2/C7bBY83nHRtTxDuWt4GmbleWis/GQ2ZTK+C9YO UQNY9i41R0CpaRrQDmlxJV1wMRDfwQi84n7TjfvtYKdholLbNICHMD6cgATd JUx3AJMs6C7j/841O9l7dnyYdCe+6Y49swMxIncM//HdNY+t+l9f37PyTz+4 ekOTpUodj3uefWL1I8uOPfD0XcP+iPUqeO7Z1JrFsx5ZffXix5fu/1nQlEzf su/JexdMuGPF1FueXNF/EsnYBN9BuMsOXulNAkF0nJ3IB78CHwQ92mfOQAuH U7GuO5G7RCVnRJNvTOGzN6bkrHFybDUzwp3KC+93wo68m1hksnxb3YQcdc6a J2fEZ69kwbk7XbqyN77Itchd99LrvEhf67zyHoYra1p5e93OEng0QpWqBnoG 82IwNGZPxneM/CizgWyy/DuGdMZMxfQk2odCirSzAz6QFghGvs5kNN7HcxaC MXgCFIzr6YK40URgg5EfpxAJwhCQTac+KDk0nMEIWiMvmANGyYj1CigwcGDi OYfBWFvGjedmcCu4ZzmBMyF7nx0r7ZSjDGpdk93vmO1Y5+AcIr0UalDq15ua /FrQSgZNg6ZTs0rzpEZQaQRe4+CNzUaQjF3GbcaUkWdmLWPA6TJONiU6XeB3 wacueN4F61ww2wUNLjC4YNQFH7Ab9nrYXXoEPU3I3bgnX7Qn37An374XYJfs nXDBsctu5cu/i4/kcmn3XGlhiPZSHZN0Rjtb1nYd7YjW02vTouwSNQYFFrCF 8sEkYWmmFg8OsuvTGEAsuOT6NMbM1RrTDBPeZYBrBJgnrBCw4CDcegMPT/Og IY2MVbuMoDGWGWcY5xl5Ne0VTfbStA5g+xBpFdtzkCK3dQQy6+Gp65vGpyvD aUPtnPk4urseroNxddtgv+Cds+X8k/yqe1ri8YXR+0cU+LP7x8+Lk7mPnuS8 h0hZagH/pmQwbUe8bju9HoloyvRCpE8kNXEYLGqN7PMSh2EtvR5pFbaupdcj 3YyRExrkK48opPiyq4lyNrWSHSLoRa+IOwq+XYBxgakAm3jwEgXOBthmsmG9 xWvBBXznGC+1Q96CMVSZjCJdCibgGZ+EUuhJb0+/k34vvQ16oOTdkyfffefk SWFFek36Z+k307fBQ1APdfDQFz+BG6GQfNvTh9K/J99nqHRqTU/Dawma0qKJ kl95UoG0J5FHUINS0YyAoWkVUq9LcBKHuXgHvf+go0o+NZl5nReXaoHUr4jW LGwlzAZ4bfov6VPgAX16NyxPT9sGf4QYlMMft437fOSBkT3pv5Fyo6Tc1ky5 PlImImV7NKRc1KkApBAVWKVQrwtwQODHu1cuV0nKNfO0XKGGPMNR0IE3fTJ9 FpalHxce3pZ2pt9OH087t9WAEi/FX/2cvm+YqJ/ziC5iRielb/IF+oLNsiKi 0Nv0xXpOzTm5CMep9fzuuAY0OgNXsBshEQUQpyUooIDn9OqnNHoNZ34KSVa0 HFu4JfgRK0hWCFgBWeGYFVJW+MAK26zQY4XmbPjER9jPCRa9jbnPMO8g8/Zm qWezKNWCiwRoHncyCZoZW2xvQ5zdoEKVyuH6hiHyoLu+ZBxLoB4XrIEQXWCl rAJUtRzHzdNd+A2eMLxwVqmmHP9m5F+hZtmNUQ04038Mc5OMM29Khy/8xDZ3 aWbuErYTmZpEx6X7VY8GJZch+Gh3oqzEY3CC82DExSWxHolkNiPYEBlKASSl qhb6Qop1cSmS3Bevid+K3QV9AfU6C0m7z1JNkGF1DRTVgIVojDUwfqgGumug Mes/WwOnmFcmOlED+FgN9NVATw001zDZ1Zm3IW/BJdr32UHmOSfvpKZLRgT2 UeFEZxl2vwz9yeG/7JQTvMIWVnkCCl42HQnb5eXN/WQiumhiwguMs7vw1WML nPBg+q6xna1ZV3oPLL146iLtfISMyknCMmRFs6WE9hmdqLTiZ0CLn1ZYnzZu UUgGBZkwbHbFloKEZAcCJU7Yoc8OXXYgXnlg5NaLRk6L5wjQH65qOD6cP6uG QsQ1Lslegps0sun2bk/ZtG/cdrir3D1vSdw5cSq3t760Mj7l/MKpE51EMs4Y /ZB7OSMZ75SkCQqoJhLB5DfFTZzpW0iJdKIuoOO0gu5bCqfhQSoS78XWB6lI vAdL2Rvj+rI3u2VrmS8cCTtTQDg8hvfUAR66McSZNas9X9KZ86UeGvrssyH6 d8fau+++Y+29RNo9nH6efB+CNTCHfG//4nWYBuPgKmhIv0qk4L+mf0Bv36aa Dt0R4ECFKAZ9ktOAyCSgF1Bsu1MyqZzbnQnjwcB2E6emm6y3EJ1HfTC8XUUl ALZxKOT9us2mKyXiv4KIf2donU4yfVe1T1euW4n7KmAbuzSlpwK62AUqJyrg SRZCvM0sJFABH1TAIAtJMC+qgPFvsWixAs6wLBBLeawC+lhecsr82foKCk/+ fYQ54RAnf2wDN9F4xrQeGpSdj1FCZ6pdjKGLTBzYAkVQDdxeBzwc+WFkOMLN j6yM3BP5ReR3EYEvgYGSUyVnSzh2/nOmziCfc1rpu8e31Xfex1uoNWONZ4OH M1tDVrzdesD6kpXjrRYrdgqwRwCFAOcEohW7BaycwM/kMbcN9+EU5thFBfIe UfpYHWXr4fSi4Gg7sKsvFaHsxhF22oBkqhByGlZucTLEHdz9nds/fm5k+e31 lCVv/yug9SO7f9O3f+iphbOXr+l7+9TP9+MfWJ/rXf78wnjzZm4y5cLXn1u0 l3vo3i07befXuHZs2PlNdlNGegb3MfdTZENB9BfpRvtuhULl2l0g2vAhcAd2 qsxwQLQLGyXbAXPIvAx7N2jZ/esceRQIhdolWGInjejVBc3Z+wnk6woGs+7M RQWsA3OLvxfdjnE6dztG9gxeptecy5V3Kx9UclRPeyTIPeT5xIO/4rufHUH7 rZSwOpqGdcA9rDuqe1/H7dUc1rxG8K3Gr8HdblAHnJ6mb6u/q/4hQVdqvxor 5bOTUbbpoDOLr+T2HrtGY5x8m0ze/Rkfpyd2T8xcoLHonqWFkbb0v2fuzkjP iAfuhvmZ+zOCwfOzFtbhmuzlGYBMBHG9SHiwFDzSbUGfVnUwoOYsjyGzwe/3 YyXn73P1SoF94bLwrVjTZ1gnqfbxEX4l5sugobsMWsugsQyqy6CoDCxlMFAG /WWwoww2lMGabLhYBoT6bBmcKCPzRxmkyqCvDHrKoLksc3fMZYpJZg8IafVT 2SMQ7PRDA7sbYjB7R0yb0wxCCXxeAj8xwzzrz61Ybyu3TbLNsq21PWz7tm3Y pjpKHiM2zpYgTIJNsMh0m+k+0x9Mn5kEN6yEe4Cj56b2wmHgLaXAl1pKd5T2 l/KQG/10OX41vSOmyHjZ5FN1Fb5EQUL4j+lz6XPZSeia76xYMbjEwQ5YkFkq /Vf/eVDjr2QnnJGT73x//qxHBu6Fv+aC+tPpv7C5fvQT4R3SL5XwtnRjLFYu CLwiqvjX6G+ieJf/oB8H/f77FFHCjlGBExTc+oqYpaIiNisGmMMV8Wti4Bdi wahQKimaFVihKCgNux4gGvrBYgeHDlbGt2OztoBKVWpJKjio3xs9HH0tynHB qL+4hMg8JYqJMWwWKrgYKbgy6fyurs+vWGeSHPp9pirTStyfhG1J2JCE7iS0 JmFCEnhmhDiVhIEk7E3CGhbVmIRqZqIYSgJJsiNLL4cHkmBhCetJhJQkbw1Y NmoMJiGVhN4k9LAI2a4hGzv6ktCcvHyF8kq7/S/TcQfPnhLfMdrrmb707lF6 RjrvOJe804tePU13eZnqicBm4I3dPs1n1CfUQU/byEtCbBCGbQK9m+J0DMpE g6lpIAA15cDdWLa07K4y7pUQtIVgOidvP+1kezvIcGKnt0D5pUAH1Y4tCgEi TD9OeGfNvQ+fT//bPa65C0eeywM6sKhx9T3w2dTdt6R/CRLEuw0VFvDBizen Bxa0hi6FO2vgqoaNwavi8bavpE+nS9Ov8WSsBQm2MJGx5kPvSWuR56CXM+hB p7dsV5kVRpsRG41ard+zz74O7ROEgP+RAKwLwOwA+ANgCMBoAN4KwPMBeDIA clScRX2QFxhnlBM/DcDrAVgVgAaWhrj7WIJAADoDgAIXX/x2eVfSVZzTI6fJ 800mDI4SuJK9MOp76oDO1KSkE6Ke6LGagE5sUjD7k3zdoMyg+ZslsrslmPHb RJDiy9/q7I2G3XGfK2ytqGX4kR2LGpn+znuLmkoqQ1eP93Vfy61mx6Ey61wT SLsVQ1iKSHrQm7dLswugQInojgcVF3Ypt1clMgoLKjqo2B7mHG7KdXrCde6D LoOuX6+3ADXibjU7mqBfVvE4VOrsU1jW+aWwa5+/xL8SD5RCfynsKIXeUlhT Ct1UVMGZUjhVCsdZ+Bp2zUNrKTSWwrFSGCqFXJIN2SQkViqFRCkESoEJO6g/ y7KQ6Yh/sBRwqhSyN9V+yf0El3PVKXat13A0s8gm23Xp+hrb1DKUXWCj/4cF XUZLjq2pXW6urQnyE5LVt92aHjzb3lpcWTnnvrN59lpexYcWdfpGfuG6/qZ0 0f3T0usvMthSG0LD6EfcAEHKJoIXnpNqkdq8l+MMnm+pleIzBidyiqLC+aBO Cunuxf4HFVKh4jhFCIjdctSXhQZXwsfk7UzsTvMMmstMQtaZvvk+HHNNdF3r +paL5xKmHhM20XFIjaXUHI/V7NxpAb2wHRt4PqAXmwSpwFgbRVEmiej54k75 xLC88TxJ4TUK1tSiMJlkxo3LXJFsw59UH2zr+91/HHl3NN2afvEcVKb/WtE2 czrgx+9Z+rWv4Ttmtg9/709E1f95+vfpp9IVVQVw+/bCCW3G4s/Ad+z7B9+i J4cJt9P/v8aFfi5dYyU/4PqG3WaxE4ZAdqt5L8Yq1x7JrtBKBkutVv8tldNu czptGvFBQfII92K3higUHvg/1T0LdFRFllXv9S+f7tfpT36dR7+QL7yQdBIS aKZ30wSISEQQIhARsEl3kpYkHbo74ScGRiJ/hQVGQXTYHVBBRzvgwbiu6DmL 6I4iuCt6dmZdYHUdPWdYPeq6exSavVWvXqeTIDOjZzxn06lX9W7dunXr1r23 6r2q9x6iK2OH6BqXN08VWNK1cMVZ+uEIlPhmxOkMt9ul+lMt2/hv/dCEOYT1 xozHM36d8UqGxqjR0F3gIJ5+YZ/AHdDhCl2dbo6O55fz2IhwCt0PS1fVqIKR W1HNVmV7B3k3waShDXIl1nx7/oedu89/Hj//1a595gdWPvPbx7btWF09neu9 9i4vT7p46v34l55plRdeePSFBQbuF3tBPg1wafIo6E8u2vgSMl3/2jvRaK5F qdjKpxr2m/S5nH0/tnParRk5R3PzvGmcg7uJPMBGzuSa/332lfdBBGAZ7tPK KxrVm3ApFg028jhDYx68fv5FaLPdbMsir12kbSQbB5CFtaWW7WBBeroGzT96 9Tn8j28+1PXefbL77N5Tlw/EV/bic4tnuWbhE9i7se/ARfPAwMXB+/4n/qvu uWQNClVe/4iPQcuK0fPeOmvGYwjpgOsUPi/3gKRPSYMLx6ytBVYRWcWCYq3B BBeRpXARWWK4yHnJK2TwpVJ8iPoZOB3R31nQ3xVXSIcr7SOe4Iw6RU615do4 fZ1mjmaZhidb2MgVjiaF5wavHzghWMg7rC+dSEmvTSUyAM941PGSAy45ZSaF pUuUSw/N8M6tqa0dIRk9d/cTJ+Ov/+9Le8Rt+5/9lwPrK2btOeRvOrFr3Jy3 dz744tYQL2ec3fPht3dNaXj92OZDwqziQy2z7n06Z/fWv4ve/ati8h0R6Pu3 4MrfClcbPyevIKzN5DLt9ofMgs1sFm4VtgpHBR4uu/nM/SaT3qzXGo7qBQN5 WF4Pxp1h543bkPZpCWOcLXjN1pmCNxujbHwpGx/KxvdkY292YmnR/P6ST6qu ZbnPVCylG/qr6oiNwLyj0rW5nG4px0twgX1oh1JNfg2uzqjOz8D8W+emrb92 KOrPu3aO6+48F++PV+LIMR/0QY5nxrGNfPTqAW7nNfp+0lnQ56egRcQbPku8 YQ54wxTwhHrrwZQc5DSb0zPBCxboLoA3TPeOTV/347zheI1kk6ISn2azF9q5 NMvPLI0WPt1CXGFaqiNVTuWN9OsFAnma7dMTxBOSdwMnOUOZdTnrVeUmA8q3 6xBmXW/i9HqbBVuIL/ztpy9+EMfP4tu/iZ/DqG3tuqXMH3L/Sn1h/Es8Cefj u/G7lab4zqsriRMsmAIO8au4uh6k2Qje0IEXeT8zpaUZ8py1ZFXIsZlsR8k8 hXMPI4fkcDl4Pe8QjYkVojwdjMoiPizivSLeJOKoiFtFvEDEDSIuFnGmiHUi /lrEn4j4PRGfEfFJET8p4l6K1qSivS/i0yJOppNAmC7iKhFjScQ2ESMRxmoR f0yJAaJfxBPVDO4LEV8S8XkRvybibhF7RewSSTlzEjwm4kM0dy5FGLUelNjj t3TJsB1X3/Pg7NDY/7H5fTL00535p5WteeyxE5SDLXzio0qjlpLYTpqN3x1n k9lAeIm9UsYVOzbWJE1aSxZ2XP2g768eHyCrA/F12m/AfzlQCfpyIMtG3luT mmKptfUZDFoHfamtZMqYmbOHQzazzWXjbYaxe0yavD1egxUVuYo4QVtEVg3q yaqBs84J506ylKClA3M6b0CGFCuf5lyf4RUysKAblxHiitbT2wmCrjStg0Pj cJ3yzlNlaWHoFkHSK5hOkyd+3UOPEKjrDRb3EpgZnaGPvcmvIWX4c2rG2MZw aZJD4jTFtmIurdBRyJk0FsxvEMnudEzfpLRUuRFAJgfFJcUlherqA3jVrDEc edFD0u047TcdyzYc721aUBn/Q3yQLEKQRYkvfvdww72rb8kvuXqFrUnE92R7 Fs9fWJKJt+ECsiRBlii+ie+Zsbl+1ngDXo4XAVhdn/gw/jS5Y1d3/ff8P4A3 scGMtgy7vXMKU3ciOyq0T7RzyI4ztCjVXqjROg6a9eMPanOyd1jtiBuzvTA1 32g1GvK3c95y7gJXssPgnWCAaZd6e+2QepPuxo6GeBo3eeqjQnkLkoVewC0h jw+qw+imsr1lHExiS8m8637wKosLnil4uYBfPHbF2O1jHxur+VbCeyU8XfKD c9orHZZekHTkURsuh0zG9mbi7Zn4tOU9C/eYCTvS4H972ndpvJ3Hf8+TnW5H 8Ov4Aua16Aji9Pv0R/QceRclJ5t+ZuJkPS7kMe9KxXVkPwwWcMKGkHozTfnS jGJRMulKDd2KWlgzsag48Vyylg1oZKKHE7sFq2q5g1j69swr1xHO33T/N88+ cyV+cuGSg9GWnd34qcNvtXT9+sHV+7gvHv7u6Q/e2ff1/Q2/DO4++/Kmd24Z t21e5/6NCxofvHZy9S+bXM+0bDryMKJfMKTh8bkzPlwmeP4bOQz048nHj9x2 p/oh5euReIN+jY4k9RSfldPnx2eghYnvLWM0/G+Wzo3zNB+hmRqEcvidaCYH QO0byMaL6HbOjWzcMeSAvAaSr3OjHIDVETwIDZCeDri3Qd5M7QIa2yAYINRA 0AHOcig/D/KqSRpwS/Q7gQZCIUib9UuRH9K7AdehF1E1wKqB5nOkLOe+HoGy t1OaD6BxwGM1jYE+4CCI/Rp0/QtNBOARtB5wSXkb4QfSTRBkqLOI0ATcQQiz CB+U1zeQhcChjfm0PEJ1EOaxdlZCcBJ8UidrXx2IxYnXc17uY+5jzV9rZ2pP 6Yp0H+kPp9pTH0krTruQ3misN35q6hSyM+6wGq3n7cvtpzP/NsuUdTDnrVyz Y35eJO8R8eUxjztvc/5G6st/pKC0MFoYK6ov6it+svhyyZSSOaW5pfFxx8ef lWfLW+XXy+6eYJ5w14TT5R9UPOiaV7mlqrDq8+q+icLE+2qMNb21utp/m/T4 5D7Wo7NgBszT/uTgynUMmg/yGWvoBRjJzcK5iX4/mdABjFLgDLNSevQqS/Mo B51haQ3gXGRpLUpHn7K0DuBfs7QetaJrpCZNChDtwC0sjZGFO8fSHDJxl1ma R1Xc5yytQRY+n6W1KJuvZmkdwBtZWo/e5pewtAFVacaxdAqarFnM0qnYoNnD 0mmoVvsYS6ejbu27LG1Mb9BNZWkT8ls2Tw+2BaPBtQG/5PdFfVJLqHtNONjW HpWOSlUuV6U0ta3VJ80OdYWia7oD0rRQuDsU9kWDoa5yaWpHh0RxI1I4EAmE ewP+cqmpPRTu8vs6AsekYETySdGwzx/o9IVXSKHW7ycm+br8UqdvjbQ8ALTa gpFoIAwsBbuklkA46oP43p5wMOIPthDsSHmilnmBtp4OX3g44QlDXCQSCwLh CKmostzlGp37F2UWTUdB1AYhCmEtCiA/DEJ+5INzH6RaUAh1ozUoTLHaASqh oxCqkAt+lZCaCvBWijsbcLsgRAG/GyhJaBqchSFNjj5aA8Eop6U64Ccl0Y3Q swDEAYh7KScEswlySfkuylUHCuSPBWiQ4pNao5S2H/A7IQ6jFQALAUc/hDNC sYtKgNBaA/Fyik34aqN1Ril3ipSCtEQLhRBpKef3oh7aqgjgBCFXpR2B1oxq C5pHKfdAmvB+M44n3EgWN4AsoPxEEi2qhHpJX/0JZf8fS/bP5+hmJaZTzFW0 3jY4nwOYrbTOPy41RX+DVE4qRVJPC6VMUp2Q20Fl4Kf6Tiygi7U8CrRV2XTC MUpptdCalDLEIjuBqtKS5bQnJcprFDgjOhKkJQk/t0O8CuJ5tAzpgedQGaXf Qy2Z2HaU4g/ZfittHWlHC+2PAJW9n7awm+rpGipxYrNRgExBFfBbRX/lkNvG 2jhcpuWM7x9WqoKW64TaK0bILJyALKO9RdKrGXcE34hSQQpzQCq3wgB8K+jC VJqeA1DSrw1wvI3CZwBkPhyJdt8CEpsBv9kU2gQwQocE0vtKX4/uWxXeTs+6 gbcQxQhT3B9jO6VQajbUPS7JjoLMZ/ZQjSN9SupYAyV6ErwQ6fUm2VUPk1A4 iU/F7jopvsIh4a2DaXsXo056SNGGTgqNUt/czGprh/xeihcCPlSLVTX6+yUW oTVGQQd8lLoEIcg4CzOtI3Bi64r2t1KpdlI5zqY9E2KtCQGHgaSyQxYxuhY/ 8zhhakE9VAb+hAxDlHdVGqqchiTSQuUwJC+Fk/Ibasnouoc8RS+16h44qlbs g7wIbcVo2ndCzR203khSPw9JXumV4T5U8SaKV+qmcgwyP/an9LBEIT6aVj2h Wi8ZF/xs1kDk5Rs1mpclsMNJWjok05vLp4N5pShK9otDVLroWXcih7RKkUMp qqF2sopqxgraz8m2pPq3Id5CgNtFLbaH9gThoD3RYqXOZG1XRzDFdofmSKou 3ki7btbmZM25lcpndO+SXiA1rAR4gFJXxz6l/i42WnaN6KkwGjnHUmlH6DhG Zh5+pIzDvYCnjBejdf77dUSlp9hpgPWDf5gFqvRG97YiMaUFUeoXokm2rfaV b4SUb2yXN/NUqnxv5n1bqJTV0Xc4T0qLiB5NSaJ2J4wYU+F8MpqIJsEMbRLM tiZD7IJzMueS6O9O1AjHifArBdg4wJmEqiFIEGpBW900DFEloYG1fGTrkr21 OhIQDfVR7zfaArupz/Cx0r1UA4PMv/QwPxmAFksMHki0knDxQ8ZnNa9iBO/D x2QSbmOzji44LqcSVnS3hx4DzMaVNt5O7Wgty4swbWtnHLcmxn5SZj7VY9KO HqopPYyDMBsZFtIWR9hYE/hJ2jo3Ie9u6vMj1E+UUL4VLe9M8lKjrdrHrK2D jTx+Og6qcwBCqYeWVrxXsr8LDCv3/f5Dme0TXScYHaxEGdWaAMCCDLY2USJC vUeUwRRZhZmd/5SS9VHO1blHgM0LpRGyJWPfV+xKRJFqCy3lZ14kxOYon1H8 IOUwkpQ/NPoHabk1SaX8TLtaqE8dKtVDPV7ZMMsLUFmpvRCmo1ckMZJKTIcD dDxdyGyTwH4aWQaY1xnygH5qpYq2BEdoS5Rqi4/SlRLzDnXeFqT5wYR+jpaF j8kjSFurSHy4TEJJHkq5Biphtq7UsBZ+ob+4bH78Vcsfr4fe11PuE+dD827w 541dvJSZlffeBTisuy/T4V1ntrnX3ZezbHX36g2r+Xf/GeC9q+DQ2Q2HjhAc VnRlOuauuLSCW9HVF86N9tjseW33wqE1CIdAu80hBbHQ7myvaOWF9lfbr7fz znZXwBvoDmwI7Aq8FjgfMHjbTZnuV9txLIB3tWNzIkMbaO9fmZsTyVw7LSd/ DQSO88bMFnfseY0sHMfeU4VFbrLlIP/3APT+zprtnnMaH31KkA9DOALhSQje p6qmEawTl6trlDjbSUulXDZBqf8wGin0mFSsxGlm9yD/2fF9vEyQbFeynO4/ 7Ofk/Tt4ec9uXv6b3TTj5O6iYvf5RzF9hOmJCS73nCfwE48g+RePQDb/X8e3 kOiK1wWlvvoSyV/2c/Jv6o3Of3oTyW9C2vsqsO59BQ67PsefAeCT/hznf/ZT 0icGcvMIKy8OWO3ugecx5aPs+aw89/P9WH6n3pX/NISzbyP57W2cvHMbkndA 2L6Nl7du08jbNiFKZEMBbY/38s8Li90b+5B8f59GXg/B21dR4+7r18i7oNot /UjeDOkH+w3ypgd08gOQ9vbXTnZ7+0tkt2OSPbvWbq+xWybahWp7epU9pdKu c9n5CjsqtxeXmEpLhPGyqUwWxhaYCguEMU6T5BQEc0Z6Smpauk5vSOc12nSE uXQd73d6kcnk9iKL1Y34FPk8jwUBC7wg1AnLBE2KIDh5Tu/AojFbn2u0m7OM Fo3NWOYZ7yn1FHsKPWM9kmeMx+HJ9tg9Fo/gSfHoPLwHeeZW45ilETU21ces GOL59bFquXGQl+bFquTGmH7u4kUDGD/UDNAYt2UQo6aYZssgB5Fl2l2LFw3i HJLd73gJYYxijff072we4FB9DG+JFcxfRCLvHYti0pZBM2paNMDh+ubm5tik xrmLCFazLMb8jYC2QWyOVZHELrEZNcam3BFzFNTLN/pbGlkaiUZHAAdKNTMK ZrT7YqUF05Ph+IYkkv4iiRSS5WjS6TAMCANWUoP/ntgbBdPxtEWOZhJkOZYd Gw8iAxTCVDTa05NEVjkOpBA5zp1X3xgzzIMwd3EstwBO3oSTWjhJL6hH6P8A CoVMWg0KZW5kc3RyZWFtDQplbmRvYmoNCg0KMTcgMCBvYmoNCjIzMTA5DQpl bmRvYmoNCg0KMTggMCBvYmoNCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvcg0K ICAgL0ZvbnROYW1lIC9DQUFBQUErVGhvcm5kYWxlDQogICAvRmxhZ3MgNA0K ICAgL0ZvbnRCQm94IFsgLTE2NiAtMzA2IDEwMDcgMTAwNCBdDQogICAvSXRh bGljQW5nbGUgMA0KICAgL0FzY2VudCA4OTENCiAgIC9EZXNjZW50IC0yMTYN CiAgIC9DYXBIZWlnaHQgMTAwNA0KICAgL1N0ZW1WIDgwDQogICAvRm9udEZp bGUyIDE2IDAgUg0KPj4NCmVuZG9iag0KDQoxOSAwIG9iag0KPDwgL0xlbmd0 aCA1NDgNCiAgIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+DQpzdHJlYW0NCnic XZRNj5swEIbvSPwHH7eHFXjGQFaKkLLJRsqhH2q2P4CAkyI1gAg55N8X3te7 qnpJ9ODxeB7GTLI97A5dO5nkx9jXRz+Zc9s1o7/197H25uQvbRdHVkzT1tMH 4q++VkMcJfP+4+M2+euhO/dmvY4jY5Kfc8BtGh/madP0J/8FD7+PjR/b7mKe fm2PfHS8D8Mff/XdZNI4KkvT+POS82s1fKuu3iTY/nxo5oh2ejzPG/8JeX8M 3ggfWNZW942/DVXtx6q7+Dhap2lp1vt9GUe+a/5fLZS7Tuf6dzUu0XaOTtPM lQsIIF8BlJABHEBSQAZwFpADCgUUBGZbEQTwwmx7wIbwBngl7ABbwgtgR2Dq NwIP3RO2C9iU5RQA+uSowNLHIYGlTwEfS58C51j65EwQfGBqFx9JLc+hj6BQ S58McnbDMK7Qx0HO0idjavoIs9Gn4Ap9HA4V+ggSSPB5BQQfnCP0cTAV+ugG EHxQm9An5wr7k+eA0B90W+ijqE3YH4dXJfRRlkOfggmCD3oq9FH4CH0yrCh9 MshpuG9oiQYfdEHpkyG10scxAX0EhSp9hHvCfYOc0scxLPjguih9lBWE/uDt aPBhGH0yaCt9HF68hv7gHBfuGwp19FGU4+ijSODoozjHhf5A29FH0TlHH2U2 +jh0wdEnQ20u+Kz4XX98v8snjqn0OUDq+zjOswPDCzNjmRZt5z8H3NAP2Bd+ /gLEVxwmZW5kc3RyZWFtDQplbmRvYmoNCg0KMjAgMCBvYmoNCjw8IC9UeXBl IC9Gb250DQogICAvU3VidHlwZSAvVHJ1ZVR5cGUNCiAgIC9CYXNlRm9udCAv Q0FBQUFBK1Rob3JuZGFsZQ0KICAgL0ZpcnN0Q2hhciAwDQogICAvTGFzdENo YXIgNzMNCiAgIC9XaWR0aHMgWyA3NzcgNjEwIDUwMCA0NDMgMjUwIDcyMiAz ODkgMjc3DQogICAgIDMzMyA1MDAgNTAwIDc3NyAyNzcgNDQzIDQ0MyAyNzcN CiAgICAgNzIyIDUwMCA2NjYgNTAwIDUwMCA1MDAgNTAwIDQ0Mw0KICAgICAz MzMgNjY2IDQ0MyA3MjIgOTQzIDI1MCA3MjIgOTIwDQogICAgIDI1MCA1MDAg ODg5IDcyMiAyNzcgNTAwIDI3NyAzMzMNCiAgICAgNTAwIDU2MyA2MTAgNTYz IDUwMCAyNzcgNTAwIDUwMA0KICAgICA1NTYgNTU2IDMzMyA3MjIgNzIyIDMz MyAzMzMgNDQzDQogICAgIDcyMiA1MDAgNTAwIDY2NiA1MDAgNzIyIDcyMiAz ODkNCiAgICAgNTU2IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDYxMA0KICAg ICA3MjIgNTAwIF0NCiAgIC9Gb250RGVzY3JpcHRvciAxOCAwIFINCiAgIC9U b1VuaWNvZGUgMTkgMCBSDQo+Pg0KZW5kb2JqDQoNCjIxIDAgb2JqDQo8PCAv VHlwZSAvRm9udA0KICAgL1N1YnR5cGUgL1R5cGUxDQogICAvQmFzZUZvbnQg L1N5bWJvbA0KPj4NCmVuZG9iag0KDQoyMiAwIG9iag0KPDwgL1R5cGUgL0Zv bnQNCiAgIC9TdWJ0eXBlIC9UeXBlMQ0KICAgL0Jhc2VGb250IC9UaW1lcy1S b21hbg0KICAgL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNCj4+DQplbmRv YmoNCg0KMjMgMCBvYmoNCjw8IC9GMSAxNSAwIFINCiAgIC9GMiAyMCAwIFIN CiAgIC9GMyAyMiAwIFINCiAgIC9GNCAyMSAwIFINCiAgID4+DQplbmRvYmoN Cg0KMjQgMCBvYmoNCjw8DQogICAvRm9udCAyMyAwIFINCiAgIC9Qcm9jU2V0 IFsgL1BERiBdDQo+Pg0KZW5kb2JqDQoNCjcgMCBvYmoNCjw8IC9UeXBlIC9Q YWdlcw0KICAgL1Jlc291cmNlcyAyNCAwIFINCiAgIC9NZWRpYUJveCBbIDAg MCA1OTUgODQyIF0NCiAgIC9LaWRzIFsgOCAwIFINCiAgICAgICAgICAgOSAw IFINCiAgICAgICAgICAgMTAgMCBSDQogICAgICAgICAgIF0NCiAgIC9Db3Vu dCAzDQo+Pg0KZW5kb2JqDQoNCjI1IDAgb2JqDQo8PCAvVHlwZSAvQ2F0YWxv Zw0KICAgL1BhZ2VzIDcgMCBSDQo+Pg0KZW5kb2JqDQoNCnhyZWYNCjAgMjYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAw MDA0NTg0IDAwMDAwIG4NCjAwMDAwMDQ2MTEgMDAwMDAgbg0KMDAwMDAwOTAx NCAwMDAwMCBuDQowMDAwMDA5MDQxIDAwMDAwIG4NCjAwMDAwMTI0MjEgMDAw MDAgbg0KMDAwMDA1MTc3NSAwMDAwMCBuDQowMDAwMDEyNDQ4IDAwMDAwIG4N CjAwMDAwMTI1NTUgMDAwMDAgbg0KMDAwMDAxMjY2MiAwMDAwMCBuDQowMDAw MDEyNzcwIDAwMDAwIG4NCjAwMDAwMjU2NDMgMDAwMDAgbg0KMDAwMDAyNTY3 MCAwMDAwMCBuDQowMDAwMDI1OTE3IDAwMDAwIG4NCjAwMDAwMjYzODkgMDAw MDAgbg0KMDAwMDAyNjc2MCAwMDAwMCBuDQowMDAwMDQ5OTc3IDAwMDAwIG4N CjAwMDAwNTAwMDQgMDAwMDAgbg0KMDAwMDA1MDI0NiAwMDAwMCBuDQowMDAw MDUwODc3IDAwMDAwIG4NCjAwMDAwNTE0MjEgMDAwMDAgbg0KMDAwMDA1MTUw MyAwMDAwMCBuDQowMDAwMDUxNjIxIDAwMDAwIG4NCjAwMDAwNTE3MDggMDAw MDAgbg0KMDAwMDA1MTk0OSAwMDAwMCBuDQp0cmFpbGVyDQo8PCAvU2l6ZSAy Ng0KICAgL1Jvb3QgMjUgMCBSDQo+Pg0Kc3RhcnR4cmVmDQo1MjAwOQ0KJSVF T0YNCg== --1870910533-250209383-1061565162=:2290-- From - Mon Oct 06 08:43:14 2003 X-UIDL: 3df3b749000027c9 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JMZUUa027946 for ; Sat, 20 Sep 2003 00:35:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8JMZUSS027945 for grid-outgoing; Sat, 20 Sep 2003 00:35:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JMYLUa027565; Sat, 20 Sep 2003 00:34:22 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8JMYLI01660; Sat, 20 Sep 2003 00:34:21 +0200 (MEST) Received: from postal.sdsc.edu(132.249.20.114) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAdvaypd; Sat, 20 Sep 03 00:34:19 +0200 Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/62) id h8JMYF306217; Fri, 19 Sep 2003 15:34:15 -0700 (PDT) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu Message-Id: In-Reply-To: References: Date: Fri, 19 Sep 2003 14:59:43 -0700 To: Nicholas Walton From: Reagan Moore Subject: Re: GGF Astro BOF Cc: ivoa@ivoa.net, Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore Status: Nic: There are multiple grid related topics that would be worthwhile to mention at the GGF Astro BOF. The goal would be to identify which of the issues are of most interest, and then pursue a description for a GGF report. Examples are: - processing pipelines versus the Grid workflow environment (Chimera/Pegasus) - IVOA registries versus Grid metadata management systems (MCS, SRB) - Standard IVOA services versus grid service environment (WSDL/OGSA) - Image archive management systems versus grid data management systems (RLS, SRB) - long term preservation of image archives versus data grid-based persistent archives In each of these areas there is either a grid implementation or a GGF working group. We would like to understand how the IVOA requirements will impact ongoing development across these areas. Reagan Moore >Dear All, > >at the upcoming Global Grid Forum meeting in Chicago (5-8 Oct 2003) - see >www.ggf.org - there will be a Birds of a Feather session which starts of >the process of forming a Astronomy Research Group at the GGF. I attach the >draft charter to this message. > >This will give the Astro and IVOA VO communities a chance to input astro >requirements into the 'grid' standards process. > >I would encourage those of you interested in this area to aim to attend >this GGF meeting. Hope to see you there. (Note that early registration >closes sept 26.) > >Please forward this message to those that may be interested. > >Yours > >Nic Walton > >======================================================================== >Dr N. A. Walton >(AstroGrid Project Scientist) Tel: +44 1223 337503 >Institute of Astronomy FAX: +44 1223 337523 >University of Cambridge WWW: http://www.astrogrid.org >Madingley Road WWW: http://www.ast.cam.ac.uk/~naw >Cambridge, CB3 0HA email: naw@ast.cam.ac.uk >======================================================================== > > >----------- > >>From spartz@ggf.org Fri Sep 19 10:16:21 2003 >Date: Thu, 18 Sep 2003 13:38:01 -0500 >From: Clare Spartz >To: ggf-membership@ggf.org >Cc: membership@ggf.org >Subject: [ggf-membership] Just Over Two Weeks Away -- GGF9 - October 4-8 - > Chicago > >GGF9 - The Ninth Global Grid Forum >October 5-8, Chicago, IL USA >Chicago Sheraton Hotel and Towers > > >42 working groups and research groups gathering for 4 days working >together to build a standards-based foundation for Grid computing. > >Nine sessions will focus on finalizing proposed charters for new >working groups and research groups, including: > * Business Process Grid > * Configuration Description, Deployment, and Lifecycle >Management > * Workflow Management > * Grid API > >In addition to working sessions where community practices and >specifications are being developed, GGF9 will include four full-day >workshops: > * Designing and Building Grid Services (OGSA/OGSI teams) > * Life Sciences Grid (Applications and requirements for > bioinformatics, pharmaceuticals, etc.) > * Peer-to-Peer and Grids: Synergies and Opportunities > * Semantic Grid > > >***Important dates are approaching*** > >Advance Registration - available through September 26 - GGF MEMBERS >save MORE MONEY >http://www.globalgridforum.org/Meetings/ggf9/reg.htm >Hotel Availability - space and special GGF rate guaranteed through >September 26 >http://www.ggf.org/Meetings/ggf9/lodging.htm > >***GGF9 Schedule*** >http://www.globalgridforum.org/Meetings/ggf9/schedule.htm >Find "Click here to download the full GGF9 Schedule at a Glance" > > >The Complete List of Sessions/Workshops and BOFs: >WORKSHOPS = 4 > Designing and Building Grid Services, led by Ian Foster >et. al. > P2P and Grids: Synergies and Opportunities, led by >Andrew Chien et. al. > Semantic Grid Workshop, led by David de Roure et. al. > Life Sciences Grid Workshop, led by Abbas Farazdel >et.al. > >WG/RG SESSIONS = 56 > Grid Checkpoint Recovery (GridCPR-WG) > Grid Remote Procedure Call (GridRPC-WG) > Advanced Collaborative Environments (ACE-RG) > Applications and Test Beds (APPS-RG) > Grid Computing Environments (GCE-RG) > Grid User Services (GUS-RG) > Life Sciences Grid (LSG-RG) > Production Grid Management (PGM-RG) > User Program Development Tools for the Grid (UPDT-RG) > Open Grid Service Common Management Model (CMM-WG) > Open Grid Services Architecture (OGSA-WG) > Open Grid Services Infrastructure (OGSI-WG) > Grid Policy Architecture (Policy-RG) > Grid Protocol Architecture (GPA-RG) > Semantic Grid (SEM-RG) > Data Access and Integration Services (DAIS-WG) > Data Format Description Language (DFDL-WG) > GridFTP-WG > IPv6 (IPv6-WG) > OGSA Data Replication Services (OREP-WG) > Data Transport (DT-RG) > Grid High-Performance Networking (GHPN-RG) > Persistent Archives (PA-RG) > Authorization Frameworks and Mechanisms (AuthZ-WG) > CA Ops (CAOPs-WG) > Open Grid Service Architecture Authorization (OGSA >AUTHZ-WG) > Site Authentication, Authorization, and Accounting >Requirements (SAAA-RG) > CIM based Grid Schema (CGS-WG) > Network Measurement (NM-WG) > Grid Information Retrieval (GIR-WG) > Grid Benchmarking (GB-RG) > Relational Grid Information Services (RGIS-RG) > Appliance Aggregation (APPAGG-RG) > OGSA-P2P-Security (OGSAP2P-RG) > Distributed Resource Management Application API >(DRMAA-WG) > Grid Economic Services Architecture (GESA-WG) > Grid Resource Allocation Agreement Protocol (GRAAP-WG) > Job Submission Description Language (JSDL-WG) > OGSA Resource Usage Service (RUS-WG) > Usage Record (UR-WG) > Grid File Systems > > >BOF's = 9 > Astronomical Grid Community-RG > Grid Support for Ubiquitous Computing-RG > Grid Federations > Grid Scheduling Ontology-WG > Workflow Management-RG > Business Process Grid-WG > Metadata Management Services Architecture-WG > Grid API-WG > Configuration Description, Deployment, and Lifecycle >Management-WG > > >GGF Sponsors at GGF9: >http://www.globalgridforum.org/L_Involved_Sponsors/2003_spons.htm >GGF9 Participants (as of September 12): >http://www.globalgridforum.org/Meetings/ggf9/participants.htm >Exploring Chicago: >http://www.ci.chi.il.us/Tourism/ > >GGF Members Register NOW: Right Price and Guaranteed Room Rate; Meeting >with the CORE >international Grid COMMUNITY ; Learning through Workshops; Continue to >BE a part of the GRID action!! > >Contact membership@ggf.org if you've forgotten your Y2003 GGF Individual >Membership number!! > >See you in Chicago!! > >Clare Spartz >Director of Marketing and Membership >Global Grid Forum >work: +1.630.252.0924 >cell: +1.917.860-9126 >fax: +1.630-252-4466 >spartz@ggf.org > > > > > > > >Content-Type: APPLICATION/PDF; NAME="Astro-RG-charter.pdf" >Content-ID: >Content-Description: pdf >Content-Disposition: ATTACHMENT; FILENAME="Astro-RG-charter.pdf" > >Attachment converted: Macintosh HD:Astro-RG-charter.pdf (PDF /CARO) (000835EB) From - Mon Oct 06 08:43:16 2003 X-UIDL: 3df3b749000027dd X-Mozilla-Status: 1001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MBe91v022359 for ; Mon, 22 Sep 2003 13:40:09 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MBe4AR022328 for grid-outgoing; Mon, 22 Sep 2003 13:40:04 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MBdn1v022221 for ; Mon, 22 Sep 2003 13:39:49 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MBdmgP022219 for ws-outgoing; Mon, 22 Sep 2003 13:39:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MBdZ1v022172 for ; Mon, 22 Sep 2003 13:39:35 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MBdYH10117 for ; Mon, 22 Sep 2003 13:39:34 +0200 (MEST) Received: from brown.csi.cam.ac.uk(131.111.8.14) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAVuaGWt; Mon, 22 Sep 03 13:39:34 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1P2Q-0007LU-Sw for ws@ivoa.net; Mon, 22 Sep 2003 12:39:30 +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.9+Sun/8.12.9) with ESMTP id h8MBdUZC015680 for ; Mon, 22 Sep 2003 12:39:30 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8MBdUsj017886 for ; Mon, 22 Sep 2003 12:39:30 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8MBdSjm017883 for ; Mon, 22 Sep 2003 12:39:30 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 22 Sep 2003 12:39:27 +0100 (BST) From: Guy Rixon To: ws@ivoa.net Subject: ADASS discussions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: Hi folks, we need to set an agenda for the discussion at the meeting following ADASS. Suggestions are welcomed. My own feeling is that we aren't yet in a position to be drafting actual IVOA standards about web-service usage. Rather, we could use the run-up to the meeting and the session at the meeting itself to define crisply the areas were we actually need standards. I.e., we would be planning documents to be debated at the _next_ meeting. Your opinion? I would also like to see a little more debate about how OGSI, OGSA and grid services fit into the IVOA architecture. In particular, can we accept OGSI services as a critical part of the architecture or is OGSI too new, too raw, or just too wierd to live? Finally I'd like to make, and to show at the meeting, head counts of which groups use which toolkits, languages, service containers etc for web services. Please reply to this list if you'd like to be counted. 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 - Mon Oct 06 08:43:17 2003 X-UIDL: 3df3b749000027df X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCZp1v011746 for ; Mon, 22 Sep 2003 14:35:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCZpi4011745 for grid-outgoing; Mon, 22 Sep 2003 14:35:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCZi1v011698 for ; Mon, 22 Sep 2003 14:35:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCZio9011696 for ws-outgoing; Mon, 22 Sep 2003 14:35:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCZa1v011651 for ; Mon, 22 Sep 2003 14:35:36 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MCZas13633 for ; Mon, 22 Sep 2003 14:35:36 +0200 (MEST) Received: from unknown(211.167.66.198) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA1Ca4LA; Mon, 22 Sep 03 14:35:33 +0200 Received: from RsProxy (titan.lamost.org [211.167.66.199]) by lamost.org (8.10.2/8.10.2) with SMTP id h8MCaUX01325; Mon, 22 Sep 2003 20:36:33 +0800 Message-ID: <3F6EEC9B.4000308@bao.ac.cn> Date: Mon, 22 Sep 2003 20:35:39 +0800 From: Chenzhou Cui User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-hk MIME-Version: 1.0 To: Guy Rixon CC: ws@ivoa.net Subject: Re: ADASS discussions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Chenzhou Cui Status: Guy Rixon wrote: > Hi folks, > > ... > As for the China-VO, its architecture is OGSA based and service oriented. Our development will be on the GT3 and its future version. > Finally I'd like to make, and to show at the meeting, head counts of which > groups use which toolkits, languages, service containers etc for web services. > Please reply to this list if you'd like to be counted. > We use Globus Toolkit, Java and C, Tomcat, etc. > 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 -- ============================================================ Chenzhou Cui National Astronomical Observatory | Tel: (8610)64877703-1328 Chinese Academy of Sciences | FAX: (8610)64878240 Datun Road 20A, Chaoyang District | Email: ccz@bao.ac.cn Beijing 100012, China | WWW: www.lamost.org/~cb ============================================================ From - Mon Oct 06 08:43:17 2003 X-UIDL: 3df3b749000027e0 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCeo1v013617 for ; Mon, 22 Sep 2003 14:40:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCeoQB013609 for grid-outgoing; Mon, 22 Sep 2003 14:40:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCeA1v013295 for ; Mon, 22 Sep 2003 14:40:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCeAOt013291 for ws-outgoing; Mon, 22 Sep 2003 14:40:10 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCda1v013057 for ; Mon, 22 Sep 2003 14:39:36 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MCda113927 for ; Mon, 22 Sep 2003 14:39:36 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAMMaWmB; Mon, 22 Sep 03 14:39:35 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 1A1PyZ-00HCZ8-50; Mon, 22 Sep 2003 13:39:35 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Mon, 22 Sep 2003 13:39:34 +0100 Date: Mon, 22 Sep 2003 13:39:34 +0100 (BST) From: Alasdair Allan To: IVOA Web Services List cc: Alasdair Allan , Guy Rixon , Tim Naylor Subject: Re: ADASS discussions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan Status: > we need to set an agenda for the discussion at the meeting following ADASS. > Suggestions are welcomed. Okay, I'd like to bring up my current pet peeve about the NVO cone search standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it doesn't include either equinox or epoch. Both of these are vital for people wanting to do real science with the catalogues. If the adopted standard doesn't include these things, people doing galactic work won't use the interface because the retrieved catalogues aren't going to be valid. We can _not_ assume J2000 for both equinox and epoch, it just won't work! One of the things I'm doing for eSTAR at the moment is a catalogue brokering service... Have a look at http://www.astro.ex.ac.uk/estar/services/services.html Basically this is the testbed broker service, there is both a REST and a SOAP interface (and documentation for the same), the REST service isn't currently NVO complient, but I guess I should modify it so it is... The service does a name resolution, if necessary, initallity using the CDS Sesame SOAP service, but falling back to use CDS SIMBAD if Sesame is unavailable. It then goes off and tries to retrieve the cone search you specified on whatever catalogue you specified, falling back to alternative sources to retrieve the catalogue if its first choice of 3rd party service is unavailable. The returned catalogue is parsed and then output in the formatted as per user specifications (currently supported formats are Cluster and JCMT pointing, because the infrastructure was written by myself and Tim Jenness and those are out internal formats!), I'm in the process of adding VOTABLE support now. At that point any Vizier and SkyCat cvatalogues (and a few others), are available via this service in VOTABLE format irrespective of the original format that the 3rd party service returned, for instance for Vizier this is TST format...! > My own feeling is that we aren't yet in a position to be drafting actual IVOA > standards about web-service usage. Rather, we could use the run-up to the > meeting and the session at the meeting itself to define crisply the areas were > we actually need standards. I.e., we would be planning documents to be > debated at the _next_ meeting. Your opinion? Personally, I'm not sure. One of the problems I'm having now is that I'm actually trying to deploy stuff, and the infrastructure is changing under my feet. This is very frustrating. I'd really like to emphasise that the returned "result" of a webservice query (be it a VOTABLE, a parsable document, or whatever) is part of the service's API. You can't just go and change it, its not just how the service is called that defines the API. That said, I take your point. > I would also like to see a little more debate about how OGSI, OGSA and grid > services fit into the IVOA architecture. In particular, can we accept OGSI > services as a critical part of the architecture or is OGSI too new, too raw, > or just too wierd to live? I would certainly anticpate a "web service" stage before everyone moves on to full OGSA/OGSI grid services, I mean, alot of what we want to do doesn't need the complications of OGSI. Why make life difficult for people trying to access your service? It would be rather nice if you could talk to a service endpoint using straight SOAP as well as a full OGSI compliant toolkit if persistence isn't needed for your query... > Finally I'd like to make, and to show at the meeting, head counts of which > groups use which toolkits, languages, service containers etc for web services. Perl and SOAP::Lite. V0.6-beta has just gotten released, this plugs alot of holes in the compatibility between SOAP::Lite and other SOAP toolkits such as AXIS, and it looks like active development of the toolkit is again underway (much to everyone's relief!). See http://www.soaplite.com/beta/ for more information about the new release, the new release also has much expended documentation! I've been talking to Paul, Randy and Byrne about adding OGSA/OGSI support to the toolkit and it looks like this might be happening on a reasonable timescale. Cheers, Al. -- Dr. A. Allan, School of Physics, University of Exeter From - Mon Oct 06 08:43:17 2003 X-UIDL: 3df3b749000027e1 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCei1v013593 for ; Mon, 22 Sep 2003 14:40:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCeiWA013591 for grid-outgoing; Mon, 22 Sep 2003 14:40:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCeU1v013476 for ; Mon, 22 Sep 2003 14:40:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCeUKV013464 for ws-outgoing; Mon, 22 Sep 2003 14:40:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@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.6/8.12.6) with ESMTP id h8MCeI1v013348; Mon, 22 Sep 2003 14:40:18 +0200 (MEST) Received: from arclux2.hq.eso.org (pc003189.hq.eso.org [134.171.3.55]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id h8MCeIx06137; Mon, 22 Sep 2003 14:40:18 +0200 (MEST) From: Andreas Wicenec Organization: European Southern Observatory To: Guy Rixon Subject: Re: ADASS discussions Date: Mon, 22 Sep 2003 14:40:17 +0200 User-Agent: KMail/1.5.1 Cc: ws@ivoa.net References: <3F6EEC9B.4000308@bao.ac.cn> In-Reply-To: <3F6EEC9B.4000308@bao.ac.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309221440.17849.awicenec@eso.org> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andreas Wicenec Status: Hi Guy, for the ALMA archive we are using Java and Tomcat and we are investigating the DB2 WebServices. Andreas On Monday 22 September 2003 14:35, Chenzhou Cui wrote: > Guy Rixon wrote: > > Hi folks, > > > > ... > > As for the China-VO, its architecture is OGSA based and service > oriented. Our development will be on the GT3 and its future version. > > > Finally I'd like to make, and to show at the meeting, head counts of > > which groups use which toolkits, languages, service containers etc for > > web services. Please reply to this list if you'd like to be counted. > > We use Globus Toolkit, Java and C, Tomcat, etc. > > > 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 - Mon Oct 06 08:43:17 2003 X-UIDL: 3df3b749000027e2 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCfs1v014149 for ; Mon, 22 Sep 2003 14:41:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCfsSF014145 for grid-outgoing; Mon, 22 Sep 2003 14:41:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCfJ1v013884 for ; Mon, 22 Sep 2003 14:41:19 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCfJAI013882 for ws-outgoing; Mon, 22 Sep 2003 14:41:19 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCed1v013517 for ; Mon, 22 Sep 2003 14:40:39 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MCedV14019 for ; Mon, 22 Sep 2003 14:40:39 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAw2aqyB; Mon, 22 Sep 03 14:40:38 +0200 Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id h8MCeadi028521 ; Mon, 22 Sep 2003 14:40:36 +0200 (CEST) Received: from astro.u-strasbg.fr (titeuf.u-strasbg.fr [130.79.129.106]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id h8MCkZd26115; Mon, 22 Sep 2003 14:46:35 +0200 (MEST) Message-ID: <3F6EEDC4.572906EC@astro.u-strasbg.fr> Date: Mon, 22 Sep 2003 14:40:36 +0200 From: Andre Schaaff Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,fr-FR MIME-Version: 1.0 To: Guy Rixon CC: ws@ivoa.net Subject: Re: ADASS discussions References: Content-Type: text/plain; charset=iso-8859-1 X-Antivirus: scanned by sophos at u-strasbg.fr X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h8MCeadi028521 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h8MCfI1v013869 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andre Schaaff Status: Hello, Ready to participate. We use mainly Tomcat/Axis/Java. André Guy Rixon wrote: > Hi folks, > > we need to set an agenda for the discussion at the meeting following ADASS. > Suggestions are welcomed. > > My own feeling is that we aren't yet in a position to be drafting actual IVOA > standards about web-service usage. Rather, we could use the run-up to the > meeting and the session at the meeting itself to define crisply the areas were > we actually need standards. I.e., we would be planning documents to be > debated at the _next_ meeting. Your opinion? > > I would also like to see a little more debate about how OGSI, OGSA and grid > services fit into the IVOA architecture. In particular, can we accept OGSI > services as a critical part of the architecture or is OGSI too new, too raw, > or just too wierd to live? > > Finally I'd like to make, and to show at the meeting, head counts of which > groups use which toolkits, languages, service containers etc for web services. > Please reply to this list if you'd like to be counted. > > 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 -- André Schaaff Observatoire Astronomique CDS - http://cdsweb.u-strasbg.fr/ 11, rue de l'Université F-67000 Strasbourg From - Mon Oct 06 08:43:17 2003 X-UIDL: 3df3b749000027e3 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCpT1v017856 for ; Mon, 22 Sep 2003 14:51:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCpS55017853 for grid-outgoing; Mon, 22 Sep 2003 14:51:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCoq1v017619 for ; Mon, 22 Sep 2003 14:50:52 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCoqK4017617 for ws-outgoing; Mon, 22 Sep 2003 14:50:52 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCoA1v017389 for ; Mon, 22 Sep 2003 14:50:10 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MCo9G14682 for ; Mon, 22 Sep 2003 14:50:09 +0200 (MEST) Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAulaiRC; Mon, 22 Sep 03 14:50:08 +0200 Received: from EON (eon.stsci.edu [130.167.14.29]) by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGH81690; Mon, 22 Sep 2003 08:50:03 -0400 (EDT) From: "Alberto Conti" To: "Guy Rixon" , Subject: RE: ADASS discussions Date: Mon, 22 Sep 2003 08:50:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Alberto Conti" Status: Hi Guy, The MAST/GALEX archive uses .NET (C# and ASP.NET) and SQL Server. Ciao, Alberto -- Dr Alberto Conti Space Telescope Science Institute 3700 San Martin Drive Baltimore, MD 21218 USA Tel: +1 (410) 338 4534 Fax: +1 (410) 338 4767 -----Original Message----- From: owner-grid@eso.org [mailto:owner-grid@eso.org]On Behalf Of Guy Rixon Sent: Monday, September 22, 2003 7:39 AM To: ws@ivoa.net Subject: ADASS discussions Hi folks, we need to set an agenda for the discussion at the meeting following ADASS. Suggestions are welcomed. My own feeling is that we aren't yet in a position to be drafting actual IVOA standards about web-service usage. Rather, we could use the run-up to the meeting and the session at the meeting itself to define crisply the areas were we actually need standards. I.e., we would be planning documents to be debated at the _next_ meeting. Your opinion? I would also like to see a little more debate about how OGSI, OGSA and grid services fit into the IVOA architecture. In particular, can we accept OGSI services as a critical part of the architecture or is OGSI too new, too raw, or just too wierd to live? Finally I'd like to make, and to show at the meeting, head counts of which groups use which toolkits, languages, service containers etc for web services. Please reply to this list if you'd like to be counted. 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 - Mon Oct 06 08:43:17 2003 X-UIDL: 3df3b749000027e4 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCv71v019844 for ; Mon, 22 Sep 2003 14:57:07 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCv7vK019841 for grid-outgoing; Mon, 22 Sep 2003 14:57:07 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCv21v019774 for ; Mon, 22 Sep 2003 14:57:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MCv2uM019772 for ws-outgoing; Mon, 22 Sep 2003 14:57:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MCus1v019738 for ; Mon, 22 Sep 2003 14:56:54 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MCusB15199 for ; Mon, 22 Sep 2003 14:56:54 +0200 (MEST) Received: from gold.csi.cam.ac.uk(131.111.8.12) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAe5aORD; Mon, 22 Sep 03 14:56:53 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1QFC-0002VD-TV; Mon, 22 Sep 2003 13:56:46 +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.9+Sun/8.12.9) with ESMTP id h8MCukZC017989; Mon, 22 Sep 2003 13:56:46 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8MCuksj018274; Mon, 22 Sep 2003 13:56:46 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8MCuka5018271; Mon, 22 Sep 2003 13:56:46 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 22 Sep 2003 13:56:46 +0100 (BST) From: Guy Rixon To: Alasdair Allan cc: IVOA Web Services List , Tim Naylor Subject: Re: ADASS discussions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: On Mon, 22 Sep 2003, Alasdair Allan wrote: > > I would certainly anticpate a "web service" stage before everyone moves on > to full OGSA/OGSI grid services, I mean, alot of what we want to do doesn't > need the complications of OGSI. Why make life difficult for people trying > to access your service? It would be rather nice if you could talk to a > service endpoint using straight SOAP as well as a full OGSI compliant > toolkit if persistence isn't needed for your query... Quite. I never expected to deploy dynamic grid services where stateless web services would do the whole job. I've been expecting to have a mixed architecture with some OGSI services (e.g. AstroGrid mySpace) amongst ordinary web-services. Recently, I'm beginning to wonder if OGSI is worth the bother. Here in Java land, we're stuck with GT3 as the only implementation, which makes development slow and difficult. Parastatidis et al. have questioned the usefulness of OGSI as a standard, proposing an alternative that matches better to web services standards. If we don't do OGSI now, I'm wondering if it will have become obsolete by the time we need to exploit it. AstroGrid's new tack is to be able to use OGSI services at the bottom of the architecure, mainly as data-selection services. E.g., we want to be able to talk, via some gateway to be designed in detail next month, to an OGSA-DAI instance as if it were one of the catalogue services in our data-access layer. (Which is not yet the IVOA DAL, BTW.) This puts us in the position of wrapping grid services inside advanced web services. We probably won't be using OGSI at critical locations elsewhere in the architecture. 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 - Mon Oct 06 08:43:17 2003 X-UIDL: 3df3b749000027e5 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MD6b4A023564 for ; Mon, 22 Sep 2003 15:06:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MD6bct023563 for grid-outgoing; Mon, 22 Sep 2003 15:06:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MD634A023358 for ; Mon, 22 Sep 2003 15:06:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MD63bb023357 for ws-outgoing; Mon, 22 Sep 2003 15:06:03 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MD5S4A023160 for ; Mon, 22 Sep 2003 15:05:28 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MD5RR15987 for ; Mon, 22 Sep 2003 15:05:27 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA9waqoF; Mon, 22 Sep 03 15:05:26 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 83457458A8; Mon, 22 Sep 2003 14:05:26 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 23388; Mon, 22 Sep 2003 14:05:26 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DAB2545AB3; Mon, 22 Sep 2003 14:05:25 +0100 (BST) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 527D2458A8; Mon, 22 Sep 2003 14:05:25 +0100 (BST) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id h8MD5PJ00378; Mon, 22 Sep 2003 14:05:25 +0100 Message-Id: <200309221305.h8MD5PJ00378@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: Alasdair Allan , IVOA Web Services List Subject: Re: ADASS discussions Date: Mon, 22 Sep 2003 14:05:25 +0100 X-Mailer: KMail [version 1.3.2] Cc: Guy Rixon , Tim Naylor References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-9.9 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill Status: On Monday 22 September 2003 1:39 pm, Alasdair Allan wrote: > > Okay, I'd like to bring up my current pet peeve about the NVO cone search > standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it > doesn't include either equinox or epoch. > > Both of these are vital for people wanting to do real science with the > catalogues. If the adopted standard doesn't include these things, people > doing galactic work won't use the interface because the retrieved > catalogues aren't going to be valid. We can _not_ assume J2000 for both > equinox and epoch, it just won't work! Errm, as I understand it, the business of converting from one equinox to another is straightforward and well understood. So can we assume that the cgi *query* is always J2000, and the catalogue database behind it converts to that using standard libraries? As for the epoch, as most databases provide the viewing epoch for each object, that should provide enough information? It may create more work at the client end, but it makes it much easier to publish databases, which encourages people to do so. > I would certainly anticpate a "web service" stage before everyone moves on > to full OGSA/OGSI grid services, I mean, alot of what we want to do doesn't > need the complications of OGSI. Why make life difficult for people trying > to access your service? It would be rather nice if you could talk to a > service endpoint using straight SOAP as well as a full OGSI compliant > toolkit if persistence isn't needed for your query... Agree lots. Publishing data easily, using readily available (whether SOAP and/or cgi-like querying and/or other) techniques, gives us a framework for building all kinds of industry-wide tools, including but not limited to grids. However I would like to keep an eye on the inherant limitations of using http: it's a simple request/response protocol, with no concept of session state. This makes it simple to use for small queries (which may be 90%? 99%? of likely queries?) but really awkward to use for large queries. State can be added, yes, but it's a layer of extra stuff to add on *top* of http - seems a waste given there's state in TCP/IP connections (*under* http)! Cheers, Martin -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From - Mon Oct 06 08:43:17 2003 X-UIDL: 3df3b749000027e6 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDDp4A026697 for ; Mon, 22 Sep 2003 15:13:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDDppb026695 for grid-outgoing; Mon, 22 Sep 2003 15:13:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDCw4A026408 for ; Mon, 22 Sep 2003 15:12:58 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDCwjG026398 for ws-outgoing; Mon, 22 Sep 2003 15:12:58 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDCD4A026173 for ; Mon, 22 Sep 2003 15:12:13 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MDCC816520 for ; Mon, 22 Sep 2003 15:12:12 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAARaa4qG; Mon, 22 Sep 03 15:12:11 +0200 Received: from mail-hub.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2/3.7W00121514) with ESMTP id WAA18757; Mon, 22 Sep 2003 22:12:12 +0900 (JST) Received: from Cassiopeia.mtk.nao.ac.jp (dhcp-208-183.mtk.nao.ac.jp [133.40.208.183]) by mail-hub.mtk.nao.ac.jp (8.9.3p2/3.7W00121511) with ESMTP id WAA17745; Mon, 22 Sep 2003 22:12:40 +0900 (JST) Message-Id: <5.0.2.7.2.20030922220727.0368fec8@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Mon, 22 Sep 2003 22:11:38 +0900 To: Guy Rixon , ws@ivoa.net From: Masatoshi OHISHI Subject: Re: ADASS discussions In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI Status: Dear Guy, At 12:39 03/09/22 +0100, Guy Rixon wrote: >Finally I'd like to make, and to show at the meeting, head counts of which >groups use which toolkits, languages, service containers etc for web services. >Please reply to this list if you'd like to be counted. JVO uses Globus Toolkit 2, Java, C, and Tomcat. GTK2 will be replaced with OGSA. We plan to utilize OGSA-DAI. Cheers, Masatoshi From - Mon Oct 06 08:43:18 2003 X-UIDL: 3df3b749000027e8 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDSa4A002671 for ; Mon, 22 Sep 2003 15:28:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDSaDE002668 for grid-outgoing; Mon, 22 Sep 2003 15:28:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDRo4C002320 for ; Mon, 22 Sep 2003 15:27:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDGdWL027818 for ws-outgoing; Mon, 22 Sep 2003 15:16:39 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDFj4A027447 for ; Mon, 22 Sep 2003 15:15:45 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MDFjI16825 for ; Mon, 22 Sep 2003 15:15:45 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAnfa42G; Mon, 22 Sep 03 15:15:44 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 1A1QXX-00HDnp-UH; Mon, 22 Sep 2003 14:15:43 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Mon, 22 Sep 2003 14:15:43 +0100 Date: Mon, 22 Sep 2003 14:15:43 +0100 (BST) From: Alasdair Allan To: Guy Rixon cc: Alasdair Allan , IVOA Web Services List , Tim Naylor Subject: Re: ADASS discussions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan Status: > > Why make life difficult for people trying to access your service? It > > would be rather nice if you could talk to a service endpoint using > > straight SOAP as well as a full OGSI compliant toolkit if persistence > > isn't needed for your query... > > Quite. I never expected to deploy dynamic grid services where stateless > web services would do the whole job. I've been expecting to have a > mixed architecture with some OGSI services (e.g. AstroGrid mySpace) > amongst ordinary web-services. Thats good to know, I was hoping that this was the case! > Recently, I'm beginning to wonder if OGSI is worth the bother. Here in > Java land, we're stuck with GT3 as the only implementation... You're better off than those of use in Perl country, we currently don't have an implementation at all... > ...which makes development slow and difficult. There also isn't a DIME implementation, although SOAP::MIME does exist and works well with the testbed services I've tried. > Parastatidis et al. Is this conference proceedings/journal paper? I haven't seen it, do you have a full reference handy? > ...have questioned the usefulness of OGSI as a standard, proposing an > alternative that matches better to web services standards. If we don't > do OGSI now, I'm wondering if it will have become obsolete by the time > we need to exploit it. I was sort of thinking about this as well, and had come to a similar tentative conclusion. The eSTAR prototype used GlobusIO for its transport layer, this has disappeared (for good reasons, it was bloody horrible to use), and we're now totally SOAP based, with a mixture of document literal and RPC interfaces depending to which bit of eSTAR you're talking to, with the "external" interfaces tending to be document literal, although this isn't globally adopted, yet... ...virtually veryone can talk SOAP, OGSA is a different matter. > AstroGrid's new tack is to be able to use OGSI services at the bottom of > the architecure, mainly as data-selection services. E.g., we want to be > able to talk, via some gateway to be designed in detail next month, to > an OGSA-DAI instance as if it were one of the catalogue services in our > data-access layer. (Which is not yet the IVOA DAL, BTW.) This puts us > in the position of wrapping grid services inside advanced web services. > We probably won't be using OGSI at critical locations elsewhere in the > architecture. I think this is a good interim compromise, it puts the external API as SOAP (presumably!?) which at least has had a little time to settle down, rather than something which is "subject to change without notice". This at least means that the infrastructure is usable _now_ which is starting to become very, very, important. If persistance becomes vital it can be introduced by using cookies at the web service level in the short term, before moving to a full Grid-enabled service (although perhaps still allowing simpler queries to the service to be via a pure-SOAP call?). Al. -- Dr. A. Allan, School of Physics, University of Exeter From - Mon Oct 06 08:43:18 2003 X-UIDL: 3df3b749000027e9 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDUP4A003731 for ; Mon, 22 Sep 2003 15:30:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDUO4H003728 for grid-outgoing; Mon, 22 Sep 2003 15:30:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDTX4A003222 for ; Mon, 22 Sep 2003 15:29:33 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDTXhM003219 for ws-outgoing; Mon, 22 Sep 2003 15:29:33 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDT04A002898 for ; Mon, 22 Sep 2003 15:29:00 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MDSxF18078 for ; Mon, 22 Sep 2003 15:28:59 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAEdaGtJ; Mon, 22 Sep 03 15:28:58 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 1A1QkM-00HDWV-DV; Mon, 22 Sep 2003 14:28:58 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Mon, 22 Sep 2003 14:28:58 +0100 Date: Mon, 22 Sep 2003 14:28:58 +0100 (BST) From: Alasdair Allan To: Martin Hill cc: Alasdair Allan , IVOA Web Services List , Guy Rixon , Tim Naylor Subject: Re: ADASS discussions In-Reply-To: <200309221305.h8MD5PJ00378@fannich.roe.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan Status: > > Okay, I'd like to bring up my current pet peeve about the NVO cone search > > standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it > > doesn't include either equinox or epoch. > > > > Both of these are vital for people wanting to do real science with the > > catalogues. If the adopted standard doesn't include these things, people > > doing galactic work won't use the interface because the retrieved > > catalogues aren't going to be valid. We can _not_ assume J2000 for both > > equinox and epoch, it just won't work! > > Errm, as I understand it, the business of converting from one equinox to > another is straightforward and well understood. So can we assume that the > cgi *query* is always J2000, and the catalogue database behind it converts to > that using standard libraries? Err, not exactly... > As for the epoch, as most databases provide the viewing epoch for each > object, that should provide enough information? Depends, does your DB contain proper motion information for instance? > It may create more work at the client end, but it makes it much easier > to publish databases, which encourages people to do so. I might want to let Tim Naylor comment on this perhaps? He's currently doing interviews but I think he might want to chip in here, I'll catch him later today and ask him to throw a mail to the list about this one... Its an important point, and something that people are currently ignoring. > Agree lots. Publishing data easily, using readily available (whether SOAP > and/or cgi-like querying and/or other) techniques, gives us a framework for > building all kinds of industry-wide tools, including but not limited to grids. Agree lots... > However I would like to keep an eye on the inherant limitations of using > http: it's a simple request/response protocol, with no concept of session > state. This makes it simple to use for small queries (which may be 90%? 99%? > of likely queries?) but really awkward to use for large queries. State can > be added, yes, but it's a layer of extra stuff to add on *top* of http - > seems a waste given there's state in TCP/IP connections (*under* http)! This is a valid point, but I'm not convinced that OGSA/OGSI is the answer we're looking for... Cheers, Al. -- Dr. A. Allan, School of Physics, University of Exeter From - Mon Oct 06 08:43:18 2003 X-UIDL: 3df3b749000027ea X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDV34A004077 for ; Mon, 22 Sep 2003 15:31:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDV3Ci004072 for grid-outgoing; Mon, 22 Sep 2003 15:31:03 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDUb4A003820 for ; Mon, 22 Sep 2003 15:30:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDUbTP003815 for ws-outgoing; Mon, 22 Sep 2003 15:30:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDUD4A003625 for ; Mon, 22 Sep 2003 15:30:13 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MDUC418186 for ; Mon, 22 Sep 2003 15:30:12 +0200 (MEST) Received: from snow.csi.cam.ac.uk(131.111.8.15) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAV1aaHJ; Mon, 22 Sep 03 15:30:11 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1QlT-0007yG-4C; Mon, 22 Sep 2003 14:30:07 +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.9+Sun/8.12.9) with ESMTP id h8MDU6ZC019330; Mon, 22 Sep 2003 14:30:06 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8MDU6sj018360; Mon, 22 Sep 2003 14:30:06 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8MDU6v9018357; Mon, 22 Sep 2003 14:30:06 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 22 Sep 2003 14:30:06 +0100 (BST) From: Guy Rixon To: Alasdair Allan cc: IVOA Web Services List , Tim Naylor Subject: Re: ADASS discussions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: On Mon, 22 Sep 2003, Alasdair Allan wrote: > > Parastatidis et al. > > Is this conference proceedings/journal paper? I haven't seen it, do you > have a full reference handy? http://www.neresc.ac.uk/projects/gaf/A%20Grid%20Application%20Framework%20based%20on%20Web%20Services%20Specifications%20and%20Practices%20v1.0.pdf It's a white paper. I'd urge anybody planning to use OGSI to read this. > This at least means that the infrastructure is usable _now_ which is > starting to become very, very, important. If persistance becomes vital > it can be introduced by using cookies at the web service level in the > short term, before moving to a full Grid-enabled service (although perhaps > still allowing simpler queries to the service to be via a pure-SOAP > call?). I'm not familiar with "SOAP cookies". I know of the WS-Context standard, which is what Parastatidis et al. recommend as (part of) the alternative to OGSI; are they the same? 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 - Mon Oct 06 08:43:18 2003 X-UIDL: 3df3b749000027ef X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDxO4A015383 for ; Mon, 22 Sep 2003 15:59:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDxOP3015382 for grid-outgoing; Mon, 22 Sep 2003 15:59:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDvo4I014741 for ; Mon, 22 Sep 2003 15:59:04 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDWEbl004620 for ws-outgoing; Mon, 22 Sep 2003 15:32:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDVE4A004171 for ; Mon, 22 Sep 2003 15:31:14 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MDVDG18303 for ; Mon, 22 Sep 2003 15:31:13 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAsYaGVJ; Mon, 22 Sep 03 15:31:12 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 62D1745B14; Mon, 22 Sep 2003 14:31:12 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 25345; Mon, 22 Sep 2003 14:31:12 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E4B3045907; Mon, 22 Sep 2003 14:31:11 +0100 (BST) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 8CD7445907; Mon, 22 Sep 2003 14:31:11 +0100 (BST) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id h8MDVBJ00691; Mon, 22 Sep 2003 14:31:11 +0100 Message-Id: <200309221331.h8MDVBJ00691@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: Guy Rixon , ws@ivoa.net Subject: Re: ADASS discussions Date: Mon, 22 Sep 2003 14:31:11 +0100 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.3 required=1000.0 tests=QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill Status: > Finally I'd like to make, and to show at the meeting, head counts of which > groups use which toolkits, languages, service containers etc for web > services. Please reply to this list if you'd like to be counted. In case you've lost track: We're publishing data using SOAP with Apache/Tomcat/Axis, also using direct TCP/IP socket connections, both of them XML document based. Intending to add Java servlets for CGI-like queries, and possibly SOAP parameter-based (rather than document based) access. All at once on any particular dataset. MC -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From - Mon Oct 06 08:43:18 2003 X-UIDL: 3df3b749000027ec X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDeF4A007875 for ; Mon, 22 Sep 2003 15:40:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDeFtq007865 for grid-outgoing; Mon, 22 Sep 2003 15:40:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDdx4A007711 for ; Mon, 22 Sep 2003 15:39:59 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDdx8e007710 for ws-outgoing; Mon, 22 Sep 2003 15:39:59 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDdk4A007636 for ; Mon, 22 Sep 2003 15:39:46 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MDdjo18997 for ; Mon, 22 Sep 2003 15:39:45 +0200 (MEST) Received: from snow.csi.cam.ac.uk(131.111.8.15) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAOUaGgL; Mon, 22 Sep 03 15:39:44 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1Qul-0000V7-BW; Mon, 22 Sep 2003 14:39:43 +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.9+Sun/8.12.9) with ESMTP id h8MDdgZC019709; Mon, 22 Sep 2003 14:39:42 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8MDdgsj018408; Mon, 22 Sep 2003 14:39:42 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8MDdgAt018404; Mon, 22 Sep 2003 14:39:42 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 22 Sep 2003 14:39:42 +0100 (BST) From: Guy Rixon To: Alasdair Allan cc: ws@ivoa.net Subject: Re: ADASS discussions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: It must have been moved. I got that URL from my browser history. Try this (worked today; no knowing how long before it moves again): http://esc.dl.ac.uk/WebServices/A%20Grid%20Application%20Framework%20based%20on%20Web%20Services%20Specifications%20and%20Practises%20v1.0.pdf On Mon, 22 Sep 2003, Alasdair Allan wrote: > > Guy, > > > > Is this conference proceedings/journal paper? I haven't seen it, do you > > > have a full reference handy? > > > > http://www.neresc.ac.uk/projects/gaf/A%20Grid%20Application%20Framework%20based%20on%20Web%20Services%20Specifications%20and%20Practices%20v1.0.pdf > > Are you sure about the URL, I get a document not found error...? > > Al. > 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 - Mon Oct 06 08:43:18 2003 X-UIDL: 3df3b749000027ed X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDp84A011909 for ; Mon, 22 Sep 2003 15:51:08 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDp8RH011908 for grid-outgoing; Mon, 22 Sep 2003 15:51:08 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDoC4A011525 for ; Mon, 22 Sep 2003 15:50:12 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDoBTT011524 for ws-outgoing; Mon, 22 Sep 2003 15:50:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDn54A011095 for ; Mon, 22 Sep 2003 15:49:05 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MDn4x19635 for ; Mon, 22 Sep 2003 15:49:04 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA6laiwM; Mon, 22 Sep 03 15:49:03 +0200 Received: from localhost (nieto@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id h8MDmxu03244; Mon, 22 Sep 2003 09:48:59 -0400 Date: Mon, 22 Sep 2003 09:48:59 -0400 (EDT) From: "Maria A. Nieto-Santisteban" To: Guy Rixon cc: Alasdair Allan , Subject: Re: ADASS discussions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Maria A. Nieto-Santisteban" Status: On Mon, 22 Sep 2003, Guy Rixon wrote: > It must have been moved. I got that URL from my browser history. > > Try this (worked today; no knowing how long before it moves again): > If you start from http://www.neresc.ac.uk/projects/gaf/ you should have no problems. Maria > http://esc.dl.ac.uk/WebServices/A%20Grid%20Application%20Framework%20based%20on%20Web%20Services%20Specifications%20and%20Practises%20v1.0.pdf > > On Mon, 22 Sep 2003, Alasdair Allan wrote: > > > > > Guy, > > > > > > Is this conference proceedings/journal paper? I haven't seen it, do you > > > > have a full reference handy? > > > > > > http://www.neresc.ac.uk/projects/gaf/A%20Grid%20Application%20Framework%20based%20on%20Web%20Services%20Specifications%20and%20Practices%20v1.0.pdf > > > > Are you sure about the URL, I get a document not found error...? > > > > Al. > > > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > -- ------------------------------------------------ Maria A. Nieto-Santisteban (nieto@pha.jhu.edu) Johns Hopkins University 3400 N. Charles St. Physics & Astronomy Department Baltimore, MD 21218 (USA) Tel: 1 410 516-7679 Fax: 1 410 516-5096 From - Mon Oct 06 08:43:18 2003 X-UIDL: 3df3b749000027ee X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDs34A013163 for ; Mon, 22 Sep 2003 15:54:04 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDs3Wi013162 for grid-outgoing; Mon, 22 Sep 2003 15:54:03 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDre4A013007 for ; Mon, 22 Sep 2003 15:53:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MDredH013002 for ws-outgoing; Mon, 22 Sep 2003 15:53:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MDrE4A012743 for ; Mon, 22 Sep 2003 15:53:14 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MDrEi20034 for ; Mon, 22 Sep 2003 15:53:14 +0200 (MEST) Received: from snow.csi.cam.ac.uk(131.111.8.15) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA_faaiN; Mon, 22 Sep 03 15:53:13 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1R7i-0003vy-9F; Mon, 22 Sep 2003 14:53:06 +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.9+Sun/8.12.9) with ESMTP id h8MDr5ZC020306; Mon, 22 Sep 2003 14:53:05 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8MDr5sj018429; Mon, 22 Sep 2003 14:53:05 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8MDr30T018426; Mon, 22 Sep 2003 14:53:05 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 22 Sep 2003 14:53:03 +0100 (BST) From: Guy Rixon To: "Maria A. Nieto-Santisteban" cc: Alasdair Allan , ws@ivoa.net Subject: Re: ADASS discussions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: On Mon, 22 Sep 2003, Maria A. Nieto-Santisteban wrote: > On Mon, 22 Sep 2003, Guy Rixon wrote: > > > It must have been moved. I got that URL from my browser history. > > > > > Try this (worked today; no knowing how long before it moves again): > > > > > If you start from http://www.neresc.ac.uk/projects/gaf/ you should have no > problems. > > Maria If I _start_ from ... ???? Why can't I/we just use the full URL? > > > http://esc.dl.ac.uk/WebServices/A%20Grid%20Application%20Framework%20based%20on%20Web%20Services%20Specifications%20and%20Practises%20v1.0.pdf > > > > On Mon, 22 Sep 2003, Alasdair Allan wrote: > > > > > > > > Guy, > > > > > > > > Is this conference proceedings/journal paper? I haven't seen it, do you > > > > > have a full reference handy? > > > > > > > > http://www.neresc.ac.uk/projects/gaf/A%20Grid%20Application%20Framework%20based%20on%20Web%20Services%20Specifications%20and%20Practices%20v1.0.pdf > > > > > > Are you sure about the URL, I get a document not found error...? > > > > > > Al. > > > > > > > Guy Rixon gtr@ast.cam.ac.uk > > Institute of Astronomy Tel: +44-1223-337542 > > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > > > -- > ------------------------------------------------ > Maria A. Nieto-Santisteban (nieto@pha.jhu.edu) > Johns Hopkins University > 3400 N. Charles St. > Physics & Astronomy Department > Baltimore, MD 21218 (USA) > > Tel: 1 410 516-7679 Fax: 1 410 516-5096 > 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 - Mon Oct 06 08:43:19 2003 X-UIDL: 3df3b749000027f0 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8ME1t4A016585 for ; Mon, 22 Sep 2003 16:01:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8ME1tJr016584 for grid-outgoing; Mon, 22 Sep 2003 16:01:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8ME1K4A016327 for ; Mon, 22 Sep 2003 16:01:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8ME1Jj5016326 for ws-outgoing; Mon, 22 Sep 2003 16:01:19 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@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.6/8.12.6) with ESMTP id h8ME0Z4A015985; Mon, 22 Sep 2003 16:00:35 +0200 (MEST) Received: from eso.org (arcdev2.hq.eso.org [134.171.10.25]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id h8ME0Zx08772; Mon, 22 Sep 2003 16:00:35 +0200 (MEST) Message-ID: <3F6F0083.7EFD4C2C@eso.org> Date: Mon, 22 Sep 2003 16:00:35 +0200 From: Alberto Micol Organization: ESA/RSSD/SN/ST-ECF X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: el MIME-Version: 1.0 To: Guy Rixon CC: ws@ivoa.net Subject: Re: ADASS discussions References: Content-Type: multipart/alternative; boundary="------------D78074D0EA874A387E54661E" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alberto Micol Status: --------------D78074D0EA874A387E54661E Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit ST-ECF/HST Archive: experimenting with SOAP::Lite for Perl Alberto -- Alberto.Micol@eso.org Tel: +49 89 32006365 HST Archive Scientist ST-ECF Fax: +49 89 32006480 ESA/RSSD/SN-M c/o ESO Karl Schwarzschild Str.2, http://archive.eso.org/ Garching bei Muenchen, http://www.stecf.org/ D-85748 Germany --------------D78074D0EA874A387E54661E Content-Type: text/html; charset=iso-8859-15 Content-Transfer-Encoding: 7bit  
ST-ECF/HST Archive: experimenting with SOAP::Lite for Perl

Alberto 

-- 
Alberto.Micol@eso.org                         Tel: +49 89 32006365
HST Archive Scientist     ST-ECF              Fax: +49 89 32006480
ESA/RSSD/SN-M             c/o ESO             Karl Schwarzschild Str.2,
http://archive.eso.org/                       Garching bei Muenchen,
http://www.stecf.org/                         D-85748 Germany
  --------------D78074D0EA874A387E54661E-- From - Mon Oct 06 08:43:19 2003 X-UIDL: 3df3b749000027f1 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MECK4A020918 for ; Mon, 22 Sep 2003 16:12:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MECK7r020914 for grid-outgoing; Mon, 22 Sep 2003 16:12:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEBe4A020594 for ; Mon, 22 Sep 2003 16:11:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEBe4H020593 for ws-outgoing; Mon, 22 Sep 2003 16:11:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEAu4A020281 for ; Mon, 22 Sep 2003 16:10:56 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MEAt621548 for ; Mon, 22 Sep 2003 16:10:55 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAACkaifQ; Mon, 22 Sep 03 16:10:54 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 1A1ROv-00H4iR-PS; Mon, 22 Sep 2003 15:10:53 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Mon, 22 Sep 2003 15:10:53 +0100 Date: Mon, 22 Sep 2003 15:10:53 +0100 (BST) From: Alasdair Allan To: Martin Hill cc: Guy Rixon , Subject: Re: ADASS discussions In-Reply-To: <200309221331.h8MDVBJ00691@fannich.roe.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan Status: > We're publishing data using SOAP with Apache/Tomcat/Axis, also using direct > TCP/IP socket connections, both of them XML document based. What format does the SOAP request take, is it RPC or document literal? ie have you slipped an XML VOQL past me while I wasn't looking? > Intending to add Java servlets for CGI-like queries, and possibly SOAP > parameter-based (rather than document based) access. Oh, you obviously have some sort of XML query language then... Err, what is it? I've obviously not being paying attention here? Cheers, Al. -- Dr. A. Allan, School of Physics, University of Exeter From - Mon Oct 06 08:43:19 2003 X-UIDL: 3df3b749000027f2 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEF54A022027 for ; Mon, 22 Sep 2003 16:15:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEF5Cp022023 for grid-outgoing; Mon, 22 Sep 2003 16:15:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEED4A021729 for ; Mon, 22 Sep 2003 16:14:13 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEEDNK021724 for ws-outgoing; Mon, 22 Sep 2003 16:14:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEDH4A021267; Mon, 22 Sep 2003 16:13:17 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MEDGB21779; Mon, 22 Sep 2003 16:13:16 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAPNaqIQ; Mon, 22 Sep 03 16:13:15 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 1A1RRC-00HF3x-Tu; Mon, 22 Sep 2003 15:13:14 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Mon, 22 Sep 2003 15:11:41 +0100 Date: Mon, 22 Sep 2003 15:11:41 +0100 (BST) From: Alasdair Allan To: Alberto Micol cc: Guy Rixon , Subject: Re: ADASS discussions In-Reply-To: <3F6F0083.7EFD4C2C@eso.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan Status: > ST-ECF/HST Archive: experimenting with SOAP::Lite for Perl Well I'm glad there is someone else! If you haven't already, you need to look at V0.60... Cheers, Al. -- Dr. A. Allan, School of Physics, University of Exeter From - Mon Oct 06 08:43:19 2003 X-UIDL: 3df3b749000027f5 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEaO4A001171 for ; Mon, 22 Sep 2003 16:36:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEaOug001168 for grid-outgoing; Mon, 22 Sep 2003 16:36:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEZt4A000967 for ; Mon, 22 Sep 2003 16:35:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEZtht000961 for ws-outgoing; Mon, 22 Sep 2003 16:35:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEZd4A000856 for ; Mon, 22 Sep 2003 16:35:39 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MEZcj24069 for ; Mon, 22 Sep 2003 16:35:38 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAU5aq_U; Mon, 22 Sep 03 16:35:35 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h8MEZXV04338; Mon, 22 Sep 2003 10:35:33 -0400 Date: Mon, 22 Sep 2003 10:35:33 -0400 From: "Wil O'Mullane" To: Guy Rixon Cc: ws@ivoa.net Subject: Re: ADASS discussions Message-ID: <20030922103533.C3949@skysrv.pha.jhu.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gtr@ast.cam.ac.uk on Mon, Sep 22, 2003 at 12:39:27PM +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" Status: At JHU most of our stuff is .NET/C#/ SqlServer. Geroges is doing some stuff with Condor and I think GLobus. I do some things with Apache/AXIS and Resin (mainly for demos) and to check compatability with .NET The SkyNode doc is in pretty good shape and is a WebService document. But in general yes we need to discuss what basic standards we need - the only call I have put in is that any VO site should have a MetaData service which returns an approporiate VOResource describing the service/s available (i.e. inaddition and differnt to WSDL). wil On Mon, Sep 22, 2003 at 12:39:27PM +0100, Guy Rixon wrote: > Hi folks, > > we need to set an agenda for the discussion at the meeting following ADASS. > Suggestions are welcomed. > > My own feeling is that we aren't yet in a position to be drafting actual IVOA > standards about web-service usage. Rather, we could use the run-up to the > meeting and the session at the meeting itself to define crisply the areas were > we actually need standards. I.e., we would be planning documents to be > debated at the _next_ meeting. Your opinion? > > I would also like to see a little more debate about how OGSI, OGSA and grid > services fit into the IVOA architecture. In particular, can we accept OGSI > services as a critical part of the architecture or is OGSI too new, too raw, > or just too wierd to live? > > Finally I'd like to make, and to show at the meeting, head counts of which > groups use which toolkits, languages, service containers etc for web services. > Please reply to this list if you'd like to be counted. > > 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 - Mon Oct 06 08:43:19 2003 X-UIDL: 3df3b749000027f6 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEb74A001438 for ; Mon, 22 Sep 2003 16:37:07 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEb6NH001432 for grid-outgoing; Mon, 22 Sep 2003 16:37:06 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEac4A001262 for ; Mon, 22 Sep 2003 16:36:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEacwn001256 for ws-outgoing; Mon, 22 Sep 2003 16:36:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEa04A000990 for ; Mon, 22 Sep 2003 16:36:00 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MEa0m24109 for ; Mon, 22 Sep 2003 16:36:00 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAVMaGfV; Mon, 22 Sep 03 16:35:59 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id C753944C9B; Mon, 22 Sep 2003 15:35:58 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 31928; Mon, 22 Sep 2003 15:35:58 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 44F47458A8; Mon, 22 Sep 2003 15:35:58 +0100 (BST) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id D9E8E44C9B; Mon, 22 Sep 2003 15:35:57 +0100 (BST) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id h8MEZve01461; Mon, 22 Sep 2003 15:35:57 +0100 Message-Id: <200309221435.h8MEZve01461@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: Alasdair Allan Subject: Re: ADASS discussions Date: Mon, 22 Sep 2003 15:35:57 +0100 X-Mailer: KMail [version 1.3.2] Cc: Guy Rixon , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-9.9 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill Status: On Monday 22 September 2003 3:10 pm, Alasdair Allan wrote: > > We're publishing data using SOAP with Apache/Tomcat/Axis, also using > > direct TCP/IP socket connections, both of them XML document based. > > What format does the SOAP request take, is it RPC or document literal? ie > have you slipped an XML VOQL past me while I wasn't looking? > > > Intending to add Java servlets for CGI-like queries, and possibly SOAP > > parameter-based (rather than document based) access. > > Oh, you obviously have some sort of XML query language then... Err, what > is it? I've obviously not being paying attention here? Document literal. We put together a simple XML version of SQL (to test the querying with, certainly not intended as a standard!) but we've been looking at the ADQL being specified under the SkyNode folks and implemented that too. This is just to give us something to work with; we expect standards to come and go and change and are ready to plug anything in when it settles! -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From - Mon Oct 06 08:43:19 2003 X-UIDL: 3df3b749000027f7 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEfp4A003021 for ; Mon, 22 Sep 2003 16:41:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEfpxI003018 for grid-outgoing; Mon, 22 Sep 2003 16:41:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEf84A002731 for ; Mon, 22 Sep 2003 16:41:08 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MEf8gX002729 for ws-outgoing; Mon, 22 Sep 2003 16:41:08 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MEeV4A002510 for ; Mon, 22 Sep 2003 16:40:31 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MEeUd24424 for ; Mon, 22 Sep 2003 16:40:30 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAtNa4SV; Mon, 22 Sep 03 16:40:29 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 1A1RrZ-00HGt0-6A; Mon, 22 Sep 2003 15:40:29 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Mon, 22 Sep 2003 15:40:29 +0100 Date: Mon, 22 Sep 2003 15:40:29 +0100 (BST) From: Alasdair Allan To: Guy Rixon cc: Alasdair Allan , IVOA Web Services List , Tim Naylor Subject: Re: ADASS discussions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan Status: > > This at least means that the infrastructure is usable _now_ which is > > starting to become very, very, important. If persistance becomes vital > > it can be introduced by using cookies at the web service level in the > > short term, before moving to a full Grid-enabled service (although > > perhaps still allowing simpler queries to the service to be via a > > pure-SOAP call?). > > I'm not familiar with "SOAP cookies". I know of the WS-Context standard, > which is what Parastatidis et al. recommend as (part of) the alternative > to OGSI; are they the same? Sorry, I was talking about using the HTTP cookie jar to carry state information between SOAP calls, much like I do here... http://www.astro.ex.ac.uk/estar/software/cookie_daemon.tar.gz although WS-Context is probably a better way of going about things as its not transport layer specific... ;) Cheers, Al. -- Dr. A. Allan, School of Physics, University of Exeter From - Mon Oct 06 08:43:21 2003 X-UIDL: 3df3b74900002806 X-Mozilla-Status: 1001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MI1cFD013305 for ; Mon, 22 Sep 2003 20:01:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MI1c42013300 for grid-outgoing; Mon, 22 Sep 2003 20:01:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MI1YFD013273 for ; Mon, 22 Sep 2003 20:01:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MI1YJ3013272 for ws-outgoing; Mon, 22 Sep 2003 20:01:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Date: Mon, 22 Sep 2003 18:44:14 +0100 (BST) From: Tim Naylor To: ws@ivoa.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Tim Naylor Status: > Okay, I'd like to bring up my current pet peeve about the NVO cone search > standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it > doesn't include either equinox or epoch. Let me add my take (as an astrophysicist) on this. 1) Epoch. If you change the epoch of a cone search the answer should change, that's because some high proper motion objects will move through the cone with time. So, a database with proper motions should accept and use an epoch. A database without proper motions should return what epoch the data refer to. Without this, cetrain science programmes will be impossible (e.g. proper motion studies). 2) Equinox really should be dealt with, and dealt with properly. Its all very well to say "everything in the VO will be equinox 2000", but it seems to me to be building in a serious limitation at an early stage. Folks should be making the data available in what ever equinox is needed, and then it should be converted (on the fly?) to what the user wants. If not, how are we going to cope if there is another change such as that from Besselian to Julian equinoxes? Tim -- ----------------------------------------------------------------------------- Prof. Tim Naylor, School of Physics, University of Exeter, Stocker Road, Exeter EX4 4QL E-mail: T.Naylor@exeter.ac.uk tel: 01392 264172 ----------------------------------------------------------------------------- From - Mon Oct 06 08:43:21 2003 X-UIDL: 3df3b74900002807 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MIU4FD026561 for ; Mon, 22 Sep 2003 20:30:04 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MIU4cF026560 for grid-outgoing; Mon, 22 Sep 2003 20:30:04 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MITtFD026496 for ; Mon, 22 Sep 2003 20:29:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MITtvI026494 for ws-outgoing; Mon, 22 Sep 2003 20:29:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MITpFD026451 for ; Mon, 22 Sep 2003 20:29:51 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MITpV11951 for ; Mon, 22 Sep 2003 20:29:51 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA_daOvx; Mon, 22 Sep 03 20:29:49 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 6953145F5D; Mon, 22 Sep 2003 19:29:49 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 17207; Mon, 22 Sep 2003 19:29:49 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CF63745F5F; Mon, 22 Sep 2003 19:29:48 +0100 (BST) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 7495945F5D; Mon, 22 Sep 2003 19:29:48 +0100 (BST) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id h8MITme01994; Mon, 22 Sep 2003 19:29:48 +0100 Message-Id: <200309221829.h8MITme01994@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: Tim Naylor , ws@ivoa.net Subject: Re: Web Cone Searches Date: Mon, 22 Sep 2003 19:29:48 +0100 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.3 required=1000.0 tests=QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill Status: The cone search is a really simple search, put together so that database owners can publish their data as straightforwardly as possible as a web service. Other more comprehensive searches, such as those based on ADQL and so on, will cover everything anyone can possibly ask about anything. Or about 80% of it anyway. So what is the minimum set of things we need to handle to make the results accurate and usable? > 1) Epoch. If you change the epoch of a cone search the answer should > change, that's because some high proper motion objects will move through > the cone with time. So, a database with proper motions should accept and > use an epoch. A database without proper motions should return what epoch > the data refer to. Without this, cetrain science programmes will be > impossible (e.g. proper motion studies). The 'answer' here sounds like the querier wants the results to be given in the 'now' epoch. Whereas in both cases (db with and without proper motions) the publisher should provide the epochs for each object, and proper motions if they're available, and we get accurate and usable results... Presumably if proper motions are not available the publisher cannot re-epoch the results anyway? And proper motion studies would not be possible anyway? And if those *with* proper motions return them, then the science can be done at the client. > 2) Equinox really should be dealt with, and dealt with properly. Its all > very well to say "everything in the VO will be equinox 2000", but it seems > to me to be building in a serious limitation at an early stage. Folks > should be making the data available in what ever equinox is needed, and > then it should be converted (on the fly?) to what the user wants. If not, > how are we going to cope if there is another change such as that from > Besselian to Julian equinoxes? I can't see that using a particular one is a *limitation*, given the conversion can be made anywhere - no information is hidden or distorted because the query is in J2000, even if many years down the line a new origin is introduced. So should we say at the moment that the *results* are presented in whatever equinox they are stored in (and some metadata page describes this) to simplify the publishing process. And many years from now, if a new one is introduced and the cone search still exists, we can add that to the cone search if it still exists, leaving it's absence as defaulting to J2000. In summary, the cone search is a great 'starter' web service for people learning to publish data. I feel we should (if I haven't misunderstood and it does limit queries) keep it as simple as possible, and devote our efforts to the richer, more complex web interfaces for full services. (We can always build services 'in front of' services - so we could provide a standard front end cone search that takes any epoch/equinox, converts the query to the right values for a basic cone search, and converts the results to the given epoch/equinox before returning them. This gives us a layered approach, but is it worth it?) Cheers, Martin -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From - Mon Oct 06 08:43:23 2003 X-UIDL: 3df3b74900002814 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N4JrBi014702 for ; Tue, 23 Sep 2003 06:19:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N4Jr0v014701 for grid-outgoing; Tue, 23 Sep 2003 06:19:53 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N4J2Bi014531 for ; Tue, 23 Sep 2003 06:19:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N4J21T014530 for ws-outgoing; Tue, 23 Sep 2003 06:19:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N4IIBi014372 for ; Tue, 23 Sep 2003 06:18:29 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8N4IHI15277 for ; Tue, 23 Sep 2003 06:18:17 +0200 (MEST) Received: from unknown(211.167.66.198) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAARqaa1D; Tue, 23 Sep 03 06:18:06 +0200 Received: from RsProxy ([192.168.3.158]) by lamost.org (8.10.2/8.10.2) with SMTP id h8N4JUX03087 for ; Tue, 23 Sep 2003 12:19:30 +0800 Message-ID: <3F6FC99A.5050809@bao.ac.cn> Date: Tue, 23 Sep 2003 12:18:34 +0800 From: Chenzhou Cui User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-hk MIME-Version: 1.0 CC: IVOA Web Services List Subject: Re: ADASS discussions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Chenzhou Cui Status: Guy Rixon wrote: > On Mon, 22 Sep 2003, Alasdair Allan wrote: > > ... > Recently, I'm beginning to wonder if OGSI is worth the bother. Here in Java > land, we're stuck with GT3 as the only implementation, which makes development > slow and difficult. Parastatidis et al. have questioned the usefulness of > OGSI as a standard, proposing an alternative that matches better to web > services standards. If we don't do OGSI now, I'm wondering if it will have > become obsolete by the time we need to exploit it. > >... I think it is suitable for a small VO project, such as China-VO, to focus its effort on one choice or just a few choices. We can adopt other technologies after they have been implemented successfully in other VO projects. What's more, the flag of Grid can absorb many eyes from IT community. It's very useful for VO development. > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 -- ============================================================ Chenzhou Cui National Astronomical Observatory | Tel: (8610)64877703-1328 Chinese Academy of Sciences | FAX: (8610)64878240 Datun Road 20A, Chaoyang District | Email: ccz@bao.ac.cn Beijing 100012, China | WWW: www.lamost.org/~cb ============================================================ From - Mon Oct 06 08:43:24 2003 X-UIDL: 3df3b7490000281c X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N7DXBi000356 for ; Tue, 23 Sep 2003 09:13:33 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N7DWEn000355 for grid-outgoing; Tue, 23 Sep 2003 09:13:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N7DLBi000312 for ; Tue, 23 Sep 2003 09:13:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N7DLZw000311 for ws-outgoing; Tue, 23 Sep 2003 09:13:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@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.6/8.12.6) with ESMTP id h8N7DABi000261; Tue, 23 Sep 2003 09:13:10 +0200 (MEST) Received: from arclux2.hq.eso.org (pc003189.hq.eso.org [134.171.3.55]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id h8N7DAx24534; Tue, 23 Sep 2003 09:13:10 +0200 (MEST) From: Andreas Wicenec Organization: European Southern Observatory To: Martin Hill , Tim Naylor , ws@ivoa.net Subject: Re: Web Cone Searches Date: Tue, 23 Sep 2003 09:13:09 +0200 User-Agent: KMail/1.5.1 References: <200309221829.h8MITme01994@fannich.roe.ac.uk> In-Reply-To: <200309221829.h8MITme01994@fannich.roe.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309230913.09401.awicenec@eso.org> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andreas Wicenec Status: Hi, I totally agree with Martin's view, even more so because we can see that a lot of people are doing some quite advanced science programs using the very simple access we are providing to our catalogues and the DSS1 and DSS2. Also from the user point of view a simple access is much easier to go along. Of course the information returned has to be complete and suited to the science case. On the other hand carrying out scientific reduction using services offered by the providers directly is a very convenient and fast way to do at least basic things like epoch and equinox calculations or the basic calibration of images and spectra. Cheers, Andreas On Monday 22 September 2003 20:29, Martin Hill wrote: > The cone search is a really simple search, put together so that database > owners can publish their data as straightforwardly as possible as a web > service. Other more comprehensive searches, such as those based on ADQL > and so on, will cover everything anyone can possibly ask about anything. > Or about 80% of it anyway. > > So what is the minimum set of things we need to handle to make the results > accurate and usable? > > > 1) Epoch. If you change the epoch of a cone search the answer should > > change, that's because some high proper motion objects will move through > > the cone with time. So, a database with proper motions should accept and > > use an epoch. A database without proper motions should return what epoch > > the data refer to. Without this, cetrain science programmes will be > > impossible (e.g. proper motion studies). > > The 'answer' here sounds like the querier wants the results to be given in > the 'now' epoch. Whereas in both cases (db with and without proper > motions) the publisher should provide the epochs for each object, and > proper motions if they're available, and we get accurate and usable > results... Presumably if proper motions are not available the publisher > cannot re-epoch the results anyway? And proper motion studies would not be > possible anyway? And if those *with* proper motions return them, then the > science can be done at the client. > > > 2) Equinox really should be dealt with, and dealt with properly. Its all > > very well to say "everything in the VO will be equinox 2000", but it > > seems to me to be building in a serious limitation at an early stage. > > Folks should be making the data available in what ever equinox is needed, > > and then it should be converted (on the fly?) to what the user wants. If > > not, how are we going to cope if there is another change such as that > > from Besselian to Julian equinoxes? > > I can't see that using a particular one is a *limitation*, given the > conversion can be made anywhere - no information is hidden or distorted > because the query is in J2000, even if many years down the line a new > origin is introduced. So should we say at the moment that the *results* > are presented in whatever equinox they are stored in (and some metadata > page describes this) to simplify the publishing process. And many years > from now, if a new one is introduced and the cone search still exists, we > can add that to the cone search if it still exists, leaving it's absence as > defaulting to J2000. > > In summary, the cone search is a great 'starter' web service for people > learning to publish data. I feel we should (if I haven't misunderstood and > it does limit queries) keep it as simple as possible, and devote our > efforts to the richer, more complex web interfaces for full services. > > (We can always build services 'in front of' services - so we could provide > a standard front end cone search that takes any epoch/equinox, converts the > query to the right values for a basic cone search, and converts the results > to the given epoch/equinox before returning them. This gives us a layered > approach, but is it worth it?) > > Cheers, > > Martin From - Mon Oct 06 08:43:26 2003 X-UIDL: 3df3b7490000282c X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NA3SxE012889 for ; Tue, 23 Sep 2003 12:03:28 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8NA3So8012887 for grid-outgoing; Tue, 23 Sep 2003 12:03:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NA3B0U012635 for ; Tue, 23 Sep 2003 12:03:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N9Nkj8023519 for ws-outgoing; Tue, 23 Sep 2003 11:23:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9MSve023021 for ; Tue, 23 Sep 2003 11:22:28 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8N9MRU02089 for ; Tue, 23 Sep 2003 11:22:27 +0200 (MEST) Received: from brown.csi.cam.ac.uk(131.111.8.14) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAFFaafe; Tue, 23 Sep 03 11:22:26 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1jNF-0002Zb-K4; Tue, 23 Sep 2003 10:22:21 +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.9+Sun/8.12.9) with ESMTP id h8N9MKZC017881; Tue, 23 Sep 2003 10:22:21 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8N9MKsj019988; Tue, 23 Sep 2003 10:22:20 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8N9MJU2019985; Tue, 23 Sep 2003 10:22:20 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 23 Sep 2003 10:22:19 +0100 (BST) From: Guy Rixon To: Chenzhou Cui cc: IVOA Web Services List Subject: Re: ADASS discussions In-Reply-To: <3F6FC99A.5050809@bao.ac.cn> Message-ID: References: <3F6FC99A.5050809@bao.ac.cn> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: On Tue, 23 Sep 2003, Chenzhou Cui wrote: > > Guy Rixon wrote: > > > On Mon, 22 Sep 2003, Alasdair Allan wrote: > > > > ... > > Recently, I'm beginning to wonder if OGSI is worth the bother. Here in Java > > land, we're stuck with GT3 as the only implementation, which makes development > > slow and difficult. Parastatidis et al. have questioned the usefulness of > > OGSI as a standard, proposing an alternative that matches better to web > > services standards. If we don't do OGSI now, I'm wondering if it will have > > become obsolete by the time we need to exploit it. > > > >... > > I think it is suitable for a small VO project, such as China-VO, to > focus its effort on one choice or just a few choices. We can adopt other > technologies after they have been implemented successfully in other VO > projects. China-VO can do whatever works best internally, of course. We wouldn't dream to trying to stop you using OGSI. However, we need to decide whether OGSI services become _mandatory_ for any part of IVOA. I.e., to connect a hypothetical Xxx-VO to the global Virtual Observatory, do the Xxx-VO people _have_ to add some OGSI services, or can they do it all with "standard" web services? > What's more, the flag of Grid can absorb many eyes from IT community. > It's very useful for VO development. I see your point, but actually I doubt if we'll get that many eyes on OGSI. It can go two ways. Firstly, all of e-Science (outside our VO movement) picks up on OGSI, and a part of the IT industry too. That way, we get scrutiny by many eyes and lots of product to use. Secondly, only the super-computer community continues with OGSI (because they use it to build compute grids), other scientists don't adopt it, and the industry forgets it. That way, we get no proper product and no eyes on the residual code-base. I don't think OGSI, in its current form, is going to become common and long-lived in science. I think that industry will side-step it and that later science projects (e.g. biologists) will use the industry-standard techniques. Sad, but true IMHO. Remember, if the only eyes on OGSI are inside the VO movement, then we're paying heavily to support aomebody else's ideas and 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 - Mon Oct 06 08:43:24 2003 X-UIDL: 3df3b74900002820 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9WIve028716 for ; Tue, 23 Sep 2003 11:32:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N9WItZ028711 for grid-outgoing; Tue, 23 Sep 2003 11:32:18 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9Vkve028358 for ; Tue, 23 Sep 2003 11:31:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N9VkqG028354 for ws-outgoing; Tue, 23 Sep 2003 11:31:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9VHve028022; Tue, 23 Sep 2003 11:31:17 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8N9VGH02792; Tue, 23 Sep 2003 11:31:16 +0200 (MEST) Received: from brown.csi.cam.ac.uk(131.111.8.14) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA1Na4Cf; Tue, 23 Sep 03 11:31:15 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1jVp-0003lQ-VY; Tue, 23 Sep 2003 10:31:13 +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.9+Sun/8.12.9) with ESMTP id h8N9VDZC018347; Tue, 23 Sep 2003 10:31:13 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8N9VDsj020038; Tue, 23 Sep 2003 10:31:13 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8N9VD6c020035; Tue, 23 Sep 2003 10:31:13 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 23 Sep 2003 10:31:13 +0100 (BST) From: Guy Rixon To: Andreas Wicenec cc: Martin Hill , Tim Naylor , ws@ivoa.net Subject: Re: Web Cone Searches In-Reply-To: <200309230913.09401.awicenec@eso.org> Message-ID: References: <200309221829.h8MITme01994@fannich.roe.ac.uk> <200309230913.09401.awicenec@eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: OK...I think there's a general principle up for debate here. If job X, which has many variations and parameters in its general form, can be done either by a general ADQL service, or by a specialized, simpler service on the same data, is it required that the specialized service cover the general form of X, or can the general form be deferred to the ADQL service. In this case, if I want cone search for B1950 positions, with known epochs and PMs, must the cone-search service support this, or must I go to the ADQL service? (In this case, I'm considering the cone-search service to be "Cone Search 2: the Web Service", not a revision to the CGI-based services.) On Tue, 23 Sep 2003, Andreas Wicenec wrote: > Hi, > > I totally agree with Martin's view, even more so because we can see that a lot > of people are doing some quite advanced science programs using the very > simple access we are providing to our catalogues and the DSS1 and DSS2. Also > from the user point of view a simple access is much easier to go along. Of > course the information returned has to be complete and suited to the science > case. > > On the other hand carrying out scientific reduction using services offered by > the providers directly is a very convenient and fast way to do at least basic > things like epoch and equinox calculations or the basic calibration of images > and spectra. > > Cheers, > Andreas > > On Monday 22 September 2003 20:29, Martin Hill wrote: > > The cone search is a really simple search, put together so that database > > owners can publish their data as straightforwardly as possible as a web > > service. Other more comprehensive searches, such as those based on ADQL > > and so on, will cover everything anyone can possibly ask about anything. > > Or about 80% of it anyway. > > > > So what is the minimum set of things we need to handle to make the results > > accurate and usable? > > > > > 1) Epoch. If you change the epoch of a cone search the answer should > > > change, that's because some high proper motion objects will move through > > > the cone with time. So, a database with proper motions should accept and > > > use an epoch. A database without proper motions should return what epoch > > > the data refer to. Without this, cetrain science programmes will be > > > impossible (e.g. proper motion studies). > > > > The 'answer' here sounds like the querier wants the results to be given in > > the 'now' epoch. Whereas in both cases (db with and without proper > > motions) the publisher should provide the epochs for each object, and > > proper motions if they're available, and we get accurate and usable > > results... Presumably if proper motions are not available the publisher > > cannot re-epoch the results anyway? And proper motion studies would not be > > possible anyway? And if those *with* proper motions return them, then the > > science can be done at the client. > > > > > 2) Equinox really should be dealt with, and dealt with properly. Its all > > > very well to say "everything in the VO will be equinox 2000", but it > > > seems to me to be building in a serious limitation at an early stage. > > > Folks should be making the data available in what ever equinox is needed, > > > and then it should be converted (on the fly?) to what the user wants. If > > > not, how are we going to cope if there is another change such as that > > > from Besselian to Julian equinoxes? > > > > I can't see that using a particular one is a *limitation*, given the > > conversion can be made anywhere - no information is hidden or distorted > > because the query is in J2000, even if many years down the line a new > > origin is introduced. So should we say at the moment that the *results* > > are presented in whatever equinox they are stored in (and some metadata > > page describes this) to simplify the publishing process. And many years > > from now, if a new one is introduced and the cone search still exists, we > > can add that to the cone search if it still exists, leaving it's absence as > > defaulting to J2000. > > > > In summary, the cone search is a great 'starter' web service for people > > learning to publish data. I feel we should (if I haven't misunderstood and > > it does limit queries) keep it as simple as possible, and devote our > > efforts to the richer, more complex web interfaces for full services. > > > > (We can always build services 'in front of' services - so we could provide > > a standard front end cone search that takes any epoch/equinox, converts the > > query to the right values for a basic cone search, and converts the results > > to the given epoch/equinox before returning them. This gives us a layered > > approach, but is it worth it?) > > > > Cheers, > > > > Martin > 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 - Mon Oct 06 08:43:26 2003 X-UIDL: 3df3b7490000282b X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NA3RxE012883 for ; Tue, 23 Sep 2003 12:03:27 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8NA3R6N012882 for grid-outgoing; Tue, 23 Sep 2003 12:03:27 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NA390i012617 for ; Tue, 23 Sep 2003 12:03:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8N9taEv010496 for ws-outgoing; Tue, 23 Sep 2003 11:55:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8N9smve010224 for ; Tue, 23 Sep 2003 11:54:48 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8N9sm104311 for ; Tue, 23 Sep 2003 11:54:48 +0200 (MEST) Received: from unknown(211.167.66.198) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAr6aqzi; Tue, 23 Sep 03 11:54:33 +0200 Received: from RsProxy ([192.168.3.158]) by lamost.org (8.10.2/8.10.2) with SMTP id h8N9tqX04362; Tue, 23 Sep 2003 17:55:52 +0800 Message-ID: <3F70186F.5010307@bao.ac.cn> Date: Tue, 23 Sep 2003 17:54:55 +0800 From: Chenzhou Cui User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-hk MIME-Version: 1.0 To: Guy Rixon CC: IVOA Web Services List Subject: Re: ADASS discussions References: <3F6FC99A.5050809@bao.ac.cn> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Chenzhou Cui Status: hi. Guy, I am sorry for my misunderstanding of your words. Maybe it is too early to decide whether OGSI services become _mandatory_ for any part of IVOA. Cheers, Chenzhou Guy Rixon wrote: > On Tue, 23 Sep 2003, Chenzhou Cui wrote: > > >>Guy Rixon wrote: >> >> >>>On Mon, 22 Sep 2003, Alasdair Allan wrote: >>> >>>... >>>Recently, I'm beginning to wonder if OGSI is worth the bother. Here in Java >>>land, we're stuck with GT3 as the only implementation, which makes development >>>slow and difficult. Parastatidis et al. have questioned the usefulness of >>>OGSI as a standard, proposing an alternative that matches better to web >>>services standards. If we don't do OGSI now, I'm wondering if it will have >>>become obsolete by the time we need to exploit it. >>> >>>... >> >>I think it is suitable for a small VO project, such as China-VO, to >>focus its effort on one choice or just a few choices. We can adopt other >>technologies after they have been implemented successfully in other VO >>projects. > > > China-VO can do whatever works best internally, of course. We wouldn't dream > to trying to stop you using OGSI. However, we need to decide whether OGSI > services become _mandatory_ for any part of IVOA. I.e., to connect a > hypothetical Xxx-VO to the global Virtual Observatory, do the Xxx-VO people > _have_ to add some OGSI services, or can they do it all with "standard" web > services? > > > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 -- ============================================================ Chenzhou Cui National Astronomical Observatory | Tel: (8610)64877703-1328 Chinese Academy of Sciences | FAX: (8610)64878240 Datun Road 20A, Chaoyang District | Email: ccz@bao.ac.cn Beijing 100012, China | WWW: www.lamost.org/~cb ============================================================ From - Mon Oct 06 08:43:25 2003 X-UIDL: 3df3b74900002824 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NAp29A000868 for ; Tue, 23 Sep 2003 12:51:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8NAp2K8000862 for grid-outgoing; Tue, 23 Sep 2003 12:51:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NAof9A000740 for ; Tue, 23 Sep 2003 12:50:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8NAofJG000737 for ws-outgoing; Tue, 23 Sep 2003 12:50:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8NAoG9A000592 for ; Tue, 23 Sep 2003 12:50:16 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8NAoG908050 for ; Tue, 23 Sep 2003 12:50:16 +0200 (MEST) Received: from purple.csi.cam.ac.uk(131.111.8.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAlYaiUp; Tue, 23 Sep 03 12:50:15 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A1kkH-00033b-An; Tue, 23 Sep 2003 11:50:13 +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.9+Sun/8.12.9) with ESMTP id h8NAoCZC021122; Tue, 23 Sep 2003 11:50:12 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.9) with ESMTP id h8NAoCsj020260; Tue, 23 Sep 2003 11:50:12 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.9+Sun/8.12.8/Submit) with ESMTP id h8NAoC0u020257; Tue, 23 Sep 2003 11:50:12 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 23 Sep 2003 11:50:12 +0100 (BST) From: Guy Rixon To: Tim Naylor cc: ws@ivoa.net Subject: Re: your mail In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: On Mon, 22 Sep 2003, Tim Naylor wrote: > > Okay, I'd like to bring up my current pet peeve about the NVO cone search > > standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it > > doesn't include either equinox or epoch. > > Let me add my take (as an astrophysicist) on this. > > 1) Epoch. If you change the epoch of a cone search the answer should > change, that's because some high proper motion objects will move through > the cone with time. So, a database with proper motions should accept and > use an epoch. A database without proper motions should return what epoch > the data refer to. Without this, cetrain science programmes will be > impossible (e.g. proper motion studies). What should a DB without proper motions do? Reject the query? Do a best-efforts approximation of the results? > 2) Equinox really should be dealt with, and dealt with properly. Its all > very well to say "everything in the VO will be equinox 2000", but it seems > to me to be building in a serious limitation at an early stage. Folks > should be making the data available in what ever equinox is needed, and > then it should be converted (on the fly?) to what the user wants. If not, > how are we going to cope if there is another change such as that from > Besselian to Julian equinoxes? This is maybe getting a bit off-topic. Do we, the services group, want to specify cone-search-as-a-web-service, or is that the job of another IVOA group, such as DAL? I _would_ like to explore the general principle of what to do when a resource can't answer a query exactly as phrased. Is it acceptable to return an approximate answer (e.g. assume zero proper motion if no proper motions are known)? If so, how would we inform the "user" of the approximation, and how might the user limit the approximations made in the processing? 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 - Mon Oct 06 08:43:50 2003 X-UIDL: 3df3b749000028f0 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UEhqBE017079 for ; Tue, 30 Sep 2003 16:44:04 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8UEF5o0006817 for grid-outgoing; Tue, 30 Sep 2003 16:15:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UEE9AT006495 for ; Tue, 30 Sep 2003 16:14:09 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8UEE98R006494 for ws-outgoing; Tue, 30 Sep 2003 16:14:09 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UED8AT006184 for ; Tue, 30 Sep 2003 16:13:08 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8UDKQF21021 for ; Tue, 30 Sep 2003 15:20:26 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAgWaadP; Tue, 30 Sep 03 15:20:25 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 1C69546031 for ; Tue, 30 Sep 2003 14:20:25 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 11139; Tue, 30 Sep 2003 14:20:24 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2C08A4602A for ; Tue, 30 Sep 2003 14:20:24 +0100 (BST) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 9C56F4602A for ; Tue, 30 Sep 2003 14:20:23 +0100 (BST) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id h8UDKNJ03832 for ws@ivoa.net; Tue, 30 Sep 2003 14:20:23 +0100 Message-Id: <200309301320.h8UDKNJ03832@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: ws@ivoa.net Subject: Re: Web Cone Searches Date: Tue, 30 Sep 2003 14:20:23 +0100 X-Mailer: KMail [version 1.3.2] References: <200309230913.09401.awicenec@eso.org> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-9.9 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill Status: Hmmm, I would have thought that the decision on whether to use a cone search or an ADQL search (assuming the query is simple enough to use either) would be made at the workflow stage, probably based on performance. Again, I think that if you want to do more than the simple cone search, you use an ADQL service, rather than get everyone to extend the cone search - is that what you meant? What advantages do we get from "Cone Search 2: The Web Search" over the CGI one? I would have thought the CGI one is easier for most people to implement and simple to call. If a client wants to go to the effort of using web services, they could use the full ADQL one? Or do people think it would be useful to offer a service call that auto-generated the ADQL for a conesearch, for a simple interface? On Tuesday 23 September 2003 10:31 am, Guy Rixon wrote: > OK...I think there's a general principle up for debate here. > > If job X, which has many variations and parameters in its general form, can > be done either by a general ADQL service, or by a specialized, simpler > service on the same data, is it required that the specialized service cover > the general form of X, or can the general form be deferred to the ADQL > service. > > In this case, if I want cone search for B1950 positions, with known epochs > and PMs, must the cone-search service support this, or must I go to the > ADQL service? > > (In this case, I'm considering the cone-search service to be "Cone Search > 2: the Web Service", not a revision to the CGI-based services.) > > On Tue, 23 Sep 2003, Andreas Wicenec wrote: > > Hi, > > > > I totally agree with Martin's view, even more so because we can see that > > a lot of people are doing some quite advanced science programs using the > > very simple access we are providing to our catalogues and the DSS1 and > > DSS2. Also from the user point of view a simple access is much easier to > > go along. Of course the information returned has to be complete and > > suited to the science case. > > > > On the other hand carrying out scientific reduction using services > > offered by the providers directly is a very convenient and fast way to do > > at least basic things like epoch and equinox calculations or the basic > > calibration of images and spectra. > > > > Cheers, > > Andreas > > > > On Monday 22 September 2003 20:29, Martin Hill wrote: > > > The cone search is a really simple search, put together so that > > > database owners can publish their data as straightforwardly as possible > > > as a web service. Other more comprehensive searches, such as those > > > based on ADQL and so on, will cover everything anyone can possibly ask > > > about anything. Or about 80% of it anyway. > > > > > > So what is the minimum set of things we need to handle to make the > > > results accurate and usable? > > > > > > > 1) Epoch. If you change the epoch of a cone search the answer should > > > > change, that's because some high proper motion objects will move > > > > through the cone with time. So, a database with proper motions > > > > should accept and use an epoch. A database without proper motions > > > > should return what epoch the data refer to. Without this, cetrain > > > > science programmes will be impossible (e.g. proper motion studies). > > > > > > The 'answer' here sounds like the querier wants the results to be given > > > in the 'now' epoch. Whereas in both cases (db with and without proper > > > motions) the publisher should provide the epochs for each object, and > > > proper motions if they're available, and we get accurate and usable > > > results... Presumably if proper motions are not available the publisher > > > cannot re-epoch the results anyway? And proper motion studies would > > > not be possible anyway? And if those *with* proper motions return them, > > > then the science can be done at the client. > > > > > > > 2) Equinox really should be dealt with, and dealt with properly. Its > > > > all very well to say "everything in the VO will be equinox 2000", but > > > > it seems to me to be building in a serious limitation at an early > > > > stage. Folks should be making the data available in what ever equinox > > > > is needed, and then it should be converted (on the fly?) to what the > > > > user wants. If not, how are we going to cope if there is another > > > > change such as that from Besselian to Julian equinoxes? > > > > > > I can't see that using a particular one is a *limitation*, given the > > > conversion can be made anywhere - no information is hidden or distorted > > > because the query is in J2000, even if many years down the line a new > > > origin is introduced. So should we say at the moment that the > > > *results* are presented in whatever equinox they are stored in (and > > > some metadata page describes this) to simplify the publishing process. > > > And many years from now, if a new one is introduced and the cone search > > > still exists, we can add that to the cone search if it still exists, > > > leaving it's absence as defaulting to J2000. > > > > > > In summary, the cone search is a great 'starter' web service for people > > > learning to publish data. I feel we should (if I haven't misunderstood > > > and it does limit queries) keep it as simple as possible, and devote > > > our efforts to the richer, more complex web interfaces for full > > > services. > > > > > > (We can always build services 'in front of' services - so we could > > > provide a standard front end cone search that takes any epoch/equinox, > > > converts the query to the right values for a basic cone search, and > > > converts the results to the given epoch/equinox before returning them. > > > This gives us a layered approach, but is it worth it?) > > > > > > Cheers, > > > > > > Martin > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From - Mon Oct 06 08:43:50 2003 X-UIDL: 3df3b749000028ef X-Mozilla-Status: 1001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UDteAh000095 for ; Tue, 30 Sep 2003 15:58:31 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8UDRSqX020181 for grid-outgoing; Tue, 30 Sep 2003 15:27:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UDQIAT019761 for ; Tue, 30 Sep 2003 15:26:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8UDQIYc019760 for ws-outgoing; Tue, 30 Sep 2003 15:26:18 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UDPNAT019361 for ; Tue, 30 Sep 2003 15:25:23 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8UDPNK21375 for ; Tue, 30 Sep 2003 15:25:23 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAkoaWVP; Tue, 30 Sep 03 15:25:22 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 0641745FA8 for ; Tue, 30 Sep 2003 14:25:22 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 11546; Tue, 30 Sep 2003 14:25:21 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8999A45F84 for ; Tue, 30 Sep 2003 14:25:21 +0100 (BST) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 3BFD745F84 for ; Tue, 30 Sep 2003 14:25:21 +0100 (BST) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id h8UDPLM03842 for ws@ivoa.net; Tue, 30 Sep 2003 14:25:21 +0100 Message-Id: <200309301325.h8UDPLM03842@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: ws@ivoa.net Subject: Impossible Queries Date: Tue, 30 Sep 2003 14:25:20 +0100 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-3.3 required=1000.0 tests=QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill Status: > I _would_ like to explore the general principle of what to do when a > resource can't answer a query exactly as phrased. Is it acceptable to > return an approximate answer (e.g. assume zero proper motion if no proper > motions are known)? If so, how would we inform the "user" of the > approximation, and how might the user limit the approximations made in the > processing? My feeling on this is that a query that cannot be properly processed should be rejected at submission. That way the astronomer (or calling service) can redraft it so that the results are known properly. I feel that data services at least should be very explicit and straightforward; any 'vaguenesses' and 'best guesses' should be made at some higher workflow level, so that astronomers always have direct access to predictable results. Over to you all... -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From - Mon Oct 06 08:43:51 2003 X-UIDL: 3df3b749000028f5 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UHeZPb020621 for ; Tue, 30 Sep 2003 19:40:35 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8UHeZhQ020619 for grid-outgoing; Tue, 30 Sep 2003 19:40:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UHdtPb020330 for ; Tue, 30 Sep 2003 19:39:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8UHdsGB020327 for ws-outgoing; Tue, 30 Sep 2003 19:39:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UHdBPb020096 for ; Tue, 30 Sep 2003 19:39:11 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8UFJEN00853 for ; Tue, 30 Sep 2003 17:19:14 +0200 (MEST) Received: from brown.csi.cam.ac.uk(131.111.8.14) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAApXaOPb; Tue, 30 Sep 03 17:19:12 +0200 Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A4MGg-000160-TN; Tue, 30 Sep 2003 16:18:26 +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 h8UFIQax006045; Tue, 30 Sep 2003 16:18:26 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id h8UFIQfI013440; Tue, 30 Sep 2003 16:18:26 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id h8UFIQ03013437; Tue, 30 Sep 2003 16:18:26 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 30 Sep 2003 16:18:26 +0100 (BST) From: Guy Rixon To: Martin Hill cc: ws@ivoa.net Subject: Re: Web Cone Searches In-Reply-To: <200309301320.h8UDKNJ03832@fannich.roe.ac.uk> Message-ID: References: <200309230913.09401.awicenec@eso.org> <200309301320.h8UDKNJ03832@fannich.roe.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: On Tue, 30 Sep 2003, Martin Hill wrote: > Hmmm, I would have thought that the decision on whether to use a cone search > or an ADQL search (assuming the query is simple enough to use either) would > be made at the workflow stage, probably based on performance. > > Again, I think that if you want to do more than the simple cone search, you > use an ADQL service, rather than get everyone to extend the cone search - is > that what you meant? > > What advantages do we get from "Cone Search 2: The Web Search" over the CGI > one? I would have thought the CGI one is easier for most people to implement > and simple to call. If a client wants to go to the effort of using web > services, they could use the full ADQL one? Or do people think it would be > useful to offer a service call that auto-generated the ADQL for a conesearch, > for a simple interface? Advantage 1: client gets to work in epoch and equinox of choice, not in the default epoch and equinox of the cone-search standard (where we came in...) Advantage 2: given good tooling, it's _easier_ to build a client for a web service than for a CGI. > On Tuesday 23 September 2003 10:31 am, Guy Rixon wrote: > > OK...I think there's a general principle up for debate here. > > > > If job X, which has many variations and parameters in its general form, can > > be done either by a general ADQL service, or by a specialized, simpler > > service on the same data, is it required that the specialized service cover > > the general form of X, or can the general form be deferred to the ADQL > > service. > > > > In this case, if I want cone search for B1950 positions, with known epochs > > and PMs, must the cone-search service support this, or must I go to the > > ADQL service? > > > > (In this case, I'm considering the cone-search service to be "Cone Search > > 2: the Web Service", not a revision to the CGI-based services.) > > > > On Tue, 23 Sep 2003, Andreas Wicenec wrote: > > > Hi, > > > > > > I totally agree with Martin's view, even more so because we can see that > > > a lot of people are doing some quite advanced science programs using the > > > very simple access we are providing to our catalogues and the DSS1 and > > > DSS2. Also from the user point of view a simple access is much easier to > > > go along. Of course the information returned has to be complete and > > > suited to the science case. > > > > > > On the other hand carrying out scientific reduction using services > > > offered by the providers directly is a very convenient and fast way to do > > > at least basic things like epoch and equinox calculations or the basic > > > calibration of images and spectra. > > > > > > Cheers, > > > Andreas > > > > > > On Monday 22 September 2003 20:29, Martin Hill wrote: > > > > The cone search is a really simple search, put together so that > > > > database owners can publish their data as straightforwardly as possible > > > > as a web service. Other more comprehensive searches, such as those > > > > based on ADQL and so on, will cover everything anyone can possibly ask > > > > about anything. Or about 80% of it anyway. > > > > > > > > So what is the minimum set of things we need to handle to make the > > > > results accurate and usable? > > > > > > > > > 1) Epoch. If you change the epoch of a cone search the answer should > > > > > change, that's because some high proper motion objects will move > > > > > through the cone with time. So, a database with proper motions > > > > > should accept and use an epoch. A database without proper motions > > > > > should return what epoch the data refer to. Without this, cetrain > > > > > science programmes will be impossible (e.g. proper motion studies). > > > > > > > > The 'answer' here sounds like the querier wants the results to be given > > > > in the 'now' epoch. Whereas in both cases (db with and without proper > > > > motions) the publisher should provide the epochs for each object, and > > > > proper motions if they're available, and we get accurate and usable > > > > results... Presumably if proper motions are not available the publisher > > > > cannot re-epoch the results anyway? And proper motion studies would > > > > not be possible anyway? And if those *with* proper motions return them, > > > > then the science can be done at the client. > > > > > > > > > 2) Equinox really should be dealt with, and dealt with properly. Its > > > > > all very well to say "everything in the VO will be equinox 2000", but > > > > > it seems to me to be building in a serious limitation at an early > > > > > stage. Folks should be making the data available in what ever equinox > > > > > is needed, and then it should be converted (on the fly?) to what the > > > > > user wants. If not, how are we going to cope if there is another > > > > > change such as that from Besselian to Julian equinoxes? > > > > > > > > I can't see that using a particular one is a *limitation*, given the > > > > conversion can be made anywhere - no information is hidden or distorted > > > > because the query is in J2000, even if many years down the line a new > > > > origin is introduced. So should we say at the moment that the > > > > *results* are presented in whatever equinox they are stored in (and > > > > some metadata page describes this) to simplify the publishing process. > > > > And many years from now, if a new one is introduced and the cone search > > > > still exists, we can add that to the cone search if it still exists, > > > > leaving it's absence as defaulting to J2000. > > > > > > > > In summary, the cone search is a great 'starter' web service for people > > > > learning to publish data. I feel we should (if I haven't misunderstood > > > > and it does limit queries) keep it as simple as possible, and devote > > > > our efforts to the richer, more complex web interfaces for full > > > > services. > > > > > > > > (We can always build services 'in front of' services - so we could > > > > provide a standard front end cone search that takes any epoch/equinox, > > > > converts the query to the right values for a basic cone search, and > > > > converts the results to the given epoch/equinox before returning them. > > > > This gives us a layered approach, but is it worth it?) > > > > > > > > Cheers, > > > > > > > > Martin > > > > Guy Rixon gtr@ast.cam.ac.uk > > Institute of Astronomy Tel: +44-1223-337542 > > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > -- > Martin Hill > Astrogrid/AVO, ROE > Tel: 07901 55 24 66 > 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 - Mon Oct 06 08:43:50 2003 X-UIDL: 3df3b749000028f1 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UG33Pb017023 for ; Tue, 30 Sep 2003 18:03:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8UG33h6017021 for grid-outgoing; Tue, 30 Sep 2003 18:03:03 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UG22Pb016649 for ; Tue, 30 Sep 2003 18:02:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8UG22sv016648 for ws-outgoing; Tue, 30 Sep 2003 18:02:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8UG16Pb016296 for ; Tue, 30 Sep 2003 18:01:06 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8UG15A04500 for ; Tue, 30 Sep 2003 18:01:05 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA3ZaGXi; Tue, 30 Sep 03 18:01:03 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 3A0E345FEC; Tue, 30 Sep 2003 17:01:03 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 22666; Tue, 30 Sep 2003 17:01:02 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 69EAE45FE5; Tue, 30 Sep 2003 17:01:02 +0100 (BST) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 0DA2B45FE3; Tue, 30 Sep 2003 17:01:02 +0100 (BST) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id h8UG11904415; Tue, 30 Sep 2003 17:01:01 +0100 Message-Id: <200309301601.h8UG11904415@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: Guy Rixon Subject: Re: Web Cone Searches Date: Tue, 30 Sep 2003 17:01:01 +0100 X-Mailer: KMail [version 1.3.2] Cc: ws@ivoa.net References: <200309301320.h8UDKNJ03832@fannich.roe.ac.uk> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-9.9 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill Status: On Tuesday 30 September 2003 4:18 pm, Guy Rixon wrote: > On Tue, 30 Sep 2003, Martin Hill wrote: > > Hmmm, I would have thought that the decision on whether to use a cone > > search or an ADQL search (assuming the query is simple enough to use > > either) would be made at the workflow stage, probably based on > > performance. > > > > Again, I think that if you want to do more than the simple cone search, > > you use an ADQL service, rather than get everyone to extend the cone > > search - is that what you meant? > > > > What advantages do we get from "Cone Search 2: The Web Search" over the > > CGI one? I would have thought the CGI one is easier for most people to > > implement and simple to call. If a client wants to go to the effort of > > using web services, they could use the full ADQL one? Or do people think > > it would be useful to offer a service call that auto-generated the ADQL > > for a conesearch, for a simple interface? > > Advantage 1: client gets to work in epoch and equinox of choice, not in the > default epoch and equinox of the cone-search standard (where we came in...) Then you use the ADQL case... (where I came in!) > Advantage 2: given good tooling, it's _easier_ to build a client for a web > service than for a CGI. Assuming you start from scratch (ie, no tooling let alone good tooling) which is easier, CGI or web? Has anyone done both from scratch (ie no previous knowledge?). If you're installing tooling anyway then a few extra installations (eg Astrogrid's datacenter services, or presumably SkyNode libraries) give you all the ADQL stuff 'for free'. We might say that cone searches are much simpler to implement at the back end, even if you get a load of ADQL-handling stuff for free, but as soon as the service provider has to start doing more than 'trivial' RA/DEC searches, and include proper motion stuff, then presumably they might as well do the full ADQL integration? Perhaps we need to try a few cases to see what the workload is like. Any volunteers?! I thought so... -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From - Mon Oct 06 08:43:53 2003 X-UIDL: 3df3b74900002908 X-Mozilla-Status: 1011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h918oHsE025830 for ; Wed, 1 Oct 2003 10:50:17 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h918oHLJ025829 for grid-outgoing; Wed, 1 Oct 2003 10:50:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h918oFsE025820 for ; Wed, 1 Oct 2003 10:50:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h918oFV9025819 for ws-outgoing; Wed, 1 Oct 2003 10:50:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h918oFsE025814 for ; Wed, 1 Oct 2003 10:50:15 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h918oEs29607 for ; Wed, 1 Oct 2003 10:50:14 +0200 (MEST) Received: from artemis.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA5waq05; Wed, 1 Oct 03 10:50:13 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A4caz-0006UM-Rc for ws@ivoa.net; Wed, 01 Oct 2003 09:44:29 +0100 Received: (qmail 9043 invoked from network); 1 Oct 2003 08:50:28 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 1 Oct 2003 08:50:28 -0000 Date: Wed, 1 Oct 2003 09:50:30 +0100 (BST) From: Clive Page To: ws@ivoa.net Subject: Re: Impossible Queries In-Reply-To: <200309301325.h8UDPLM03842@fannich.roe.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-grid@eso.org Precedence: bulk Reply-To: Clive Page Status: On Tue, 30 Sep 2003, Martin Hill wrote: > > I _would_ like to explore the general principle of what to do when a > > resource can't answer a query exactly as phrased. > My feeling on this is that a query that cannot be properly processed should > be rejected at submission. I support the general idea that a misleading answer should not be returned. In many cases it should be possible to make use of nulls, which are very important in astronomical data. To digress for a moment: upper (or lower) limits are almost equally important, but existing software can sometimes manage to handle nulls (e.g. common-or-garden DBMS) but support for upper/lower limits is contained in only a few packages specially written by astronomers. Here's a trivial example: if you do a query asking for proper motions alone of a service which doesn't have them for the objects specified, then an exception might be the right result, but if you ask for postions and magnitudes and proper motions, than returning a table with just proper motions set to NULL would be better. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From - Fri Oct 10 18:45:40 2003 X-UIDL: 3df3b74900002a41 X-Mozilla-Status: 1001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9AGhkB5026134 for ; Fri, 10 Oct 2003 18:43:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9AGhktM026132 for grid-outgoing; Fri, 10 Oct 2003 18:43:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9AGgpB5025832 for ; Fri, 10 Oct 2003 18:42:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9AGgoZg025828 for ws-outgoing; Fri, 10 Oct 2003 18:42:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@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.6/8.12.6) with SMTP id h9AGfWB5025462 for ; Fri, 10 Oct 2003 18:41:32 +0200 (MEST) Received: from snow.csi.cam.ac.uk (snow.csi.cam.ac.uk [131.111.8.15]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9AGfVCL018580 for ; Fri, 10 Oct 2003 18:41:32 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1A80KU-0002sP-Jc for ws@ivoa.net; Fri, 10 Oct 2003 17:41:26 +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 h9AGfQtu000505 for ; Fri, 10 Oct 2003 17:41:26 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id h9AGfQbe016621 for ; Fri, 10 Oct 2003 17:41:26 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id h9AGfPlh016617 for ; Fri, 10 Oct 2003 17:41:26 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 10 Oct 2003 17:41:25 +0100 (BST) From: Guy Rixon To: ws@ivoa.net Subject: Rough agenda for the meeting on Thursday Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon Status: This is all still negotiable...send me email if you don't like it. I've put down names of people who might introduce some of the topics: i.e. a couple of minutes verbal intriduction, not a long presentation. Meeting of Web/Grid services groups of IVOA Thursday, 16th October 2003 14:00 to 16:00 1. Brief review of who's using which technology (Rixon) 2. Cone-search web service (Alasdair - Do we want one distinct from an ADQL service? - Do we want it to deal in variable equinox, epoch etc.? 3. Metadata service (Wil O'Mullane) - What role do we see for it? 4. What other standard services does IVOA need? - What are we missing? - What exists already in projects that needs to be made standard? 5. Can we use grid services? (Rixon) - Can we migrate everything to OGSI services? - Can we add a few OGSI services into a web-service architecture? - WS-GAF vs OGSI 6. Pan-service issues - How should a service react to a query it can't answer exactly? - What interface style? XML documents? "SOAPy beans"? RPCs? 7. AOB. 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-grid@eso.org Thu Oct 30 17:08:40 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9UFxi7B018724 for ; Thu, 30 Oct 2003 16:59:44 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9UFxig0018723 for grid-outgoing; Thu, 30 Oct 2003 16:59:44 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id h9UFqW7P016955 for ; Thu, 30 Oct 2003 16:58:45 +0100 (MET) Received: from mssltz.mssl.ucl.ac.uk (mssltz.mssl.ucl.ac.uk [128.40.71.165]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9UFlZs3027390 for ; Thu, 30 Oct 2003 16:47:35 +0100 (CET) Received: (from root@localhost) by mssltz.mssl.ucl.ac.uk (8.11.6p2-20031002/8.11.6) id h9UFlZu03405 for grid@ivoa.net.scanned; Thu, 30 Oct 2003 15:47:35 GMT Received: from alpha2.mssl.ucl.ac.uk (msslai.mssl.ucl.ac.uk [128.40.71.160]) by mssltz.mssl.ucl.ac.uk (8.11.6p2-20031002/8.11.6) with ESMTP id h9UFlVn03318; Thu, 30 Oct 2003 15:47:31 GMT Received: from localhost by alpha2.mssl.ucl.ac.uk (8.9.3/1.1.29.3/18Jun03-0405PM) id PAA0001560160; Thu, 30 Oct 2003 15:47:31 GMT X-Authentication-Warning: msslai.mssl.ucl.ac.uk: kmb owned process doing -bs Date: Thu, 30 Oct 2003 15:47:31 +0000 (GMT) From: Kevin Benson To: cc: Subject: policy/authorization and terminology on grid styles Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Kevin Benson X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hello I am on an action item from the conference to explain how Astrogrid deals with credentials, authorization, and authentication. I will try to have it by early to middle of next week sorry for the delay. Also I would like to mention something that probably several of you already know, but it is just a terminology thing that I noticed at the conference and also at Astrogrid that gets people confused. Blame Axis toolkit on this. That is like the different syles you can do. 1.) RPC which needs no real explaining 2.) document style - well here is the confusion, much like Guy mentioned this is about inserting an xml document into the soap envelope hence building the message yourself. Well Axis document style is much like RPC except the encoding is literal and it has a java binding mechanism for your java objects you have. But when you look at it in many other websites document style is about building the soap xml message itself. So I just wanted to clear that up. 3.) Wrapped style is just like document style and I think this is the default for .Net again Axis does the java binding much like it's document style. Only difference i think is wrapped style in Axis is more parameter based and does not let you do complex type (java bean objects) as parameters to your webservices 4.) Axis-message style now we finally have what is known as document style to many other websites. This is what you use to do all the building of soap messages yourself. Also on a side note: To give my 2 cents about standard styles to use. Well I would sort of vote on getting rid of RPC style. I believe WS-I has banned it or really warns on not to use it correct me if I am wrong. Plus look at this link for its performance not good. http://www-106.ibm.com/developerworks/webservices/library/ws-soapenc/ Keep in mind the above link says document style(doc-style) this is Axis-message style. The Axis document and wrapped style is sort of in between on their graphs (in between their RPC and Doc-style graphs) because Axis and I would think .Net would be the same do the binding mechanism to bind things into objects, but still has better performance than RPC probably because of its encoding. And also I must say I am usually not in favor of the doc-style(axis message style) either. I like what Guy mentions Document style with bindings which is what .Net does and Axis Document and wrapped style) Okay this e-mail is getting long. I am logging off for awhile Kevin From owner-avoteam@eso.org Thu Dec 4 20:04:43 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hB4J3vlK023354 for ; Thu, 4 Dec 2003 20:03:57 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB4J3vrT023349 for avoteam-outgoing; Thu, 4 Dec 2003 20:03:57 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-avoteam@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.6/8.12.6) with ESMTP id hB4J2E1u022783; Thu, 4 Dec 2003 20:02:14 +0100 (MET) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hB4J2Et07715; Thu, 4 Dec 2003 20:02:14 +0100 (MET) Message-ID: <3FCF84B6.9070507@eso.org> Date: Thu, 04 Dec 2003 20:02:14 +0100 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: mleoni@eso.org Subject: Server down X-Priority: 1 (highest) Content-Type: multipart/alternative; boundary="------------000202050900060205000601" Sender: owner-avoteam@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Mozilla-Status: c001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------000202050900060205000601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Due to maintenance of the electrical systems this week-end in Garching, we have been requested to switch off all computer systems during this period. For this reason all the services (mailing lists, web sites, twikis) will be unavailable on Saturday Dec. 6 . Sorry for the short notice. Best regards, Marco -- Marco C. Leoni Astrophysical Virtual Observatory - http://www.euro-vo.org tel 0049 89 3200 6560 fax 0049 89 3200 6480 mleoni@eso.org --------------000202050900060205000601 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Due to maintenance of the electrical systems this week-end in Garching, we have been requested to switch off all computer systems during this period.
For this reason all the services (mailing lists, web sites, twikis) will be unavailable on Saturday Dec. 6 .

Sorry for the short notice.


Best regards,
    Marco




--
Marco C. Leoni

Astrophysical Virtual Observatory - http://www.euro-vo.org
tel 0049 89 3200 6560
fax 0049 89 3200 6480
mleoni@eso.org
--------------000202050900060205000601-- From owner-grid@eso.org Fri Dec 12 01:11:14 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBC02Tg2018363 for ; Fri, 12 Dec 2003 01:02:29 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBC02TIV018360 for grid-outgoing; Fri, 12 Dec 2003 01:02:29 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBC01ug2018298 for ; Fri, 12 Dec 2003 01:01:56 +0100 (MET) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBC01s5E006971 for ; Fri, 12 Dec 2003 01:01:55 +0100 (CET) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id QAA09734 for ; Thu, 11 Dec 2003 16:01:53 -0800 (PST) Date: Thu, 11 Dec 2003 16:01:53 -0800 (PST) From: Matthew Graham To: grid@ivoa.net Subject: VOTable class Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Is anyone trying to pass VOTable around directly between Java web services and clients? If so, what class are you using to represent VOTable? I have found the following all have associated problems: (1) JAVOT: requires com.tbf.xml package which has non-bean classes: XmlNameSpace, XmlObject (both lack default constructors) (2) SAVOT: compilation errors (cannot find savot/model/SavotSet; class is cds.savot.model.SavotSet in cds.savot.model package); VOTable is also not a bean (not serializable, no default constructor) (3) uk.ac.starlink.votable: not a bean (VOTable, VOElement) but easy enough to alter source code to make them (serializable, default constructor); however, use java.net.URL and javax.xml.transform.Source which are not beans. (4) voi.vowrite.VOTable: this is a bean but is really only for writing not reading. I realise that lack of beanness does not stop the objects being passed about but it does mean that they end up being represented as anyType in the wsdl which does not make for easy translation at the other end. Cheers, Matthew From owner-grid@eso.org Fri Dec 12 07:55:34 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBC6q3g2021120 for ; Fri, 12 Dec 2003 07:52:03 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBC6q3oh021119 for grid-outgoing; Fri, 12 Dec 2003 07:52:03 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBC6pTg2021051 for ; Fri, 12 Dec 2003 07:51:29 +0100 (MET) Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBC6pSUp018313 for ; Fri, 12 Dec 2003 07:51:28 +0100 (CET) Received: (from nobody@localhost) by newb6.u-strasbg.fr (8.9.3/8.9.3) id HAA16816; Fri, 12 Dec 2003 07:51:25 +0100 (MET) X-Authentication-Warning: newb6.u-strasbg.fr: nobody set sender to schaaff@astro.u-strasbg.fr using -f To: Matthew Graham Subject: Re: VOTable class Message-ID: <1071211884.3fd9656ced7cb@astro.u-strasbg.fr> Date: Fri, 12 Dec 2003 07:51:24 +0100 (MET) From: Andre Schaaff Cc: grid@ivoa.net References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-MIME-Autoconverted: from 8bit to quoted-printable by newb6.u-strasbg.fr id HAA16816 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id hBC6q2g2021114 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andre Schaaff X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hello Matthew, My answer concerning SAVOT. SAVOT2 will be published soon with the following main evolutions : . optimization of input/output (example : high speed VOTable writer which can be usefull for Web Services or Servlets) . savot data model is now serializable . two possible ways of TD storage (object oriented like in SAVOT1 or direct array storage in each TR object) . a VOTable WS (VOTable submission, SAVOT serialized data model return) ... It will also be a beta version for the new VOTable. Regards, André Quoting Matthew Graham : > > Hi, > > Is anyone trying to pass VOTable around directly between Java web > services > and clients? If so, what class are you using to represent VOTable? > > I have found the following all have associated problems: > > (1) JAVOT: requires com.tbf.xml package which has non-bean classes: > XmlNameSpace, XmlObject (both lack default constructors) > > (2) SAVOT: compilation errors (cannot find savot/model/SavotSet; class > is > cds.savot.model.SavotSet in cds.savot.model package); VOTable is also > not > a bean (not serializable, no default constructor) > > (3) uk.ac.starlink.votable: not a bean (VOTable, VOElement) but easy > enough to alter source code to make them (serializable, default > constructor); however, use java.net.URL and javax.xml.transform.Source > which are not beans. > > (4) voi.vowrite.VOTable: this is a bean but is really only for writing > not > reading. > > I realise that lack of beanness does not stop the objects being passed > about but it does mean that they end up being represented as anyType in > the wsdl which does not make for easy translation at the other end. > > Cheers, > > Matthew > From owner-grid@eso.org Fri Dec 12 11:22:10 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBCAIig2006012 for ; Fri, 12 Dec 2003 11:18:44 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBCAIikQ006011 for grid-outgoing; Fri, 12 Dec 2003 11:18:44 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBCAIBg2005895 for ; Fri, 12 Dec 2003 11:18:11 +0100 (MET) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBCAIAUp022903 for ; Fri, 12 Dec 2003 11:18:10 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1AUkMz-0004Kp-1r for grid@ivoa.net; Fri, 12 Dec 2003 10:18:01 +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.12.10+Sun/8.12.10) with ESMTP id hBCAI0aI019919 for ; Fri, 12 Dec 2003 10:18:00 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id hBCAI0Cp007963 for ; Fri, 12 Dec 2003 10:18:00 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id hBCAI0wc007960 for ; Fri, 12 Dec 2003 10:18:00 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 12 Dec 2003 10:18:00 +0000 (GMT) From: Guy Rixon To: grid@ivoa.net Subject: Delegate interfaces vs. stubs vs. XML interfaces Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The question was raised at an AVO meeting "for a web-service that returns a VOTable can the service return a Java object so we don't have to parse the VOTable?" Well, the web service itself is defined to return XML, so it will return VOTable; it can't return Java directly. In any case, a public service needs to support clients in many languages. The conversion from VOTable to Java _has_ to be done in the client, but there are three ways to do this: - make the author of the client application write the parser; - have the service publisher supply a stub that does the parsing; - have the service publisher supply a delegate that does the parsing. Both stubs and delegates are classes in the programming language that provide the function of the XML interface. They do serialization of objects to XML and deserialization of objects from XML to the programming language. Stubs and delegates are both compiled into client programmes. Stubs and delegates operate at different levels of abtraction. Stubs are low level. They match the XML interface closely. Typically, a stub has one object method for each operation in the XML interface. Arguments and return values of methods in the stub may be objects; the stub maps these to XML fragments in the XML interface. Stubs are usually generated from WSDL by tools. I.e. the inteface of a stub is usually fixed by the XML interface. Delegates are high level. They are usually hand-coded. The methods in a delegate class don't always map one-to-one with operations in the WSDL. Arguments and return values of delegate classes don't always map trivially to the structures in the XML interfaces. I.e., the interface of the delegate can be tuned to help the author of client applications. A delegate can be written to call a stub. This lets the delegate use the tool-generated code in the stub and hence to be simpler. Stubs are hard to produce and use when complex data structures are being exchanged. They work best when all the objects that are arguments or return values are Java beans (or the equivalent in other languages): these can be serialized to and deserialized from XML by standard libraries. The fall-back position is to have the stub return a DOM: i.e. to do only the lowest level of parsing of the XML. Trying to generate stubs for services that return VOTable is going to be hard. For the use case in the original question, it seems sensible to provide a stub that returns a VOTable as a DOM and then provide a delegate that calls the stub and returns the VOTable as an object, using a VOTable-specific parser. AstroGrid provides delegate classes in Java for its services, and these are typically based on Java stubs made with Apache-Axis. Authors of applications in other languages can still used the published XML interfaces in their own stubs and delegates. The XML interfaces remain the definitions of the services. Stubs and delegates are just helper classes to make things easier for authors of clients. 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-grid@eso.org Fri Dec 12 15:14:16 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBCEAcg2028171 for ; Fri, 12 Dec 2003 15:10:38 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBCEAbCQ028164 for grid-outgoing; Fri, 12 Dec 2003 15:10:37 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBCE9xg2027967 for ; Fri, 12 Dec 2003 15:09:59 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBCE9u5E023682 for ; Fri, 12 Dec 2003 15:09:59 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id hBCE9pL18792; Fri, 12 Dec 2003 09:09:51 -0500 Date: Fri, 12 Dec 2003 09:09:51 -0500 From: "Wil O'Mullane" To: Guy Rixon Cc: grid@ivoa.net Subject: Re: Delegate interfaces vs. stubs vs. XML interfaces Message-ID: <20031212090951.C18560@skysrv.pha.jhu.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gtr@ast.cam.ac.uk on Fri, Dec 12, 2003 at 10:18:00AM +0000 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: May I suggest someone points ther java wsdl2java at something like http://skyservice.pha.jhu.edu/devel/CasService/CasService.asmx?wsdl it returns a VOTable from GetVOtable Pass it sql like select top 10 * from galaxy That will give yo a VOTable set of Java classes and you will not have to parse the result ... wil On Fri, Dec 12, 2003 at 10:18:00AM +0000, Guy Rixon wrote: > The question was raised at an AVO meeting "for a web-service that returns a > VOTable can the service return a Java object so we don't have to parse the > VOTable?" > > Well, the web service itself is defined to return XML, so it will return > VOTable; it can't return Java directly. In any case, a public service needs > to support clients in many languages. > > The conversion from VOTable to Java _has_ to be done in the client, but there > are three ways to do this: > > - make the author of the client application write the parser; > > - have the service publisher supply a stub that does the parsing; > > - have the service publisher supply a delegate that does the parsing. > > Both stubs and delegates are classes in the programming language that provide > the function of the XML interface. They do serialization of objects to XML and > deserialization of objects from XML to the programming language. Stubs > and delegates are both compiled into client programmes. Stubs > and delegates operate at different levels of abtraction. > > Stubs are low level. They match the XML interface closely. Typically, a stub > has one object method for each operation in the XML interface. Arguments and > return values of methods in the stub may be objects; the stub maps these to > XML fragments in the XML interface. Stubs are usually generated from WSDL by > tools. I.e. the inteface of a stub is usually fixed by the XML interface. > > Delegates are high level. They are usually hand-coded. The methods in a > delegate class don't always map one-to-one with operations in the WSDL. > Arguments and return values of delegate classes don't always map trivially to > the structures in the XML interfaces. I.e., the interface of the delegate can > be tuned to help the author of client applications. > > A delegate can be written to call a stub. This lets the delegate use the > tool-generated code in the stub and hence to be simpler. > > Stubs are hard to produce and use when complex data structures are being > exchanged. They work best when all the objects that are arguments or return > values are Java beans (or the equivalent in other languages): these can be > serialized to and deserialized from XML by standard libraries. The fall-back > position is to have the stub return a DOM: i.e. to do only the lowest level of > parsing of the XML. > > Trying to generate stubs for services that return VOTable is going to be hard. > For the use case in the original question, it seems sensible to provide a stub > that returns a VOTable as a DOM and then provide a delegate that calls the > stub and returns the VOTable as an object, using a VOTable-specific parser. > > AstroGrid provides delegate classes in Java for its services, and these are > typically based on Java stubs made with Apache-Axis. Authors of applications > in other languages can still used the published XML interfaces in their own > stubs and delegates. > > The XML interfaces remain the definitions of the services. Stubs and > delegates are just helper classes to make things easier for authors of > clients. > > 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-grid@eso.org Fri Dec 12 15:23:20 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBCEKxg2000975 for ; Fri, 12 Dec 2003 15:20:59 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBCEKx8d000972 for grid-outgoing; Fri, 12 Dec 2003 15:20:59 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBCEKOg2000692 for ; Fri, 12 Dec 2003 15:20:24 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBCEKM5E023937 for ; Fri, 12 Dec 2003 15:20:23 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id hBCEKME18924 for grid@ivoa.net; Fri, 12 Dec 2003 09:20:22 -0500 Date: Fri, 12 Dec 2003 09:20:22 -0500 From: "Wil O'Mullane" To: grid@ivoa.net Subject: Another WebService returning VOTable Message-ID: <20031212092022.D18560@skysrv.pha.jhu.edu> References: <20031212090951.C18560@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031212090951.C18560@skysrv.pha.jhu.edu>; from womullan@skysrv.pha.jhu.edu on Fri, Dec 12, 2003 at 09:09:51AM -0500 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: actually now that I think back the SdssCOne is a webservice which uses the HTTPget since thats what the protocol demands so you may also try http://skyservice.pha.jhu.edu/devel/ConeSearch/sdssConeSearch.asmx?wsdl also returns VOTable ... On Fri, Dec 12, 2003 at 09:09:51AM -0500, Wil O'Mullane wrote: > May I suggest someone points ther java wsdl2java at something like > > http://skyservice.pha.jhu.edu/devel/CasService/CasService.asmx?wsdl > > it returns a VOTable from > GetVOtable > > Pass it sql like > > select top 10 * from galaxy > > > That will give yo a VOTable set of Java classes and you > will not have to parse the result ... > > > wil > On Fri, Dec 12, 2003 at 10:18:00AM +0000, Guy Rixon wrote: > > The question was raised at an AVO meeting "for a web-service that returns a > > VOTable can the service return a Java object so we don't have to parse the > > VOTable?" > > > > Well, the web service itself is defined to return XML, so it will return > > VOTable; it can't return Java directly. In any case, a public service needs > > to support clients in many languages. > > > > The conversion from VOTable to Java _has_ to be done in the client, but there > > are three ways to do this: > > > > - make the author of the client application write the parser; > > > > - have the service publisher supply a stub that does the parsing; > > > > - have the service publisher supply a delegate that does the parsing. > > > > Both stubs and delegates are classes in the programming language that provide > > the function of the XML interface. They do serialization of objects to XML and > > deserialization of objects from XML to the programming language. Stubs > > and delegates are both compiled into client programmes. Stubs > > and delegates operate at different levels of abtraction. > > > > Stubs are low level. They match the XML interface closely. Typically, a stub > > has one object method for each operation in the XML interface. Arguments and > > return values of methods in the stub may be objects; the stub maps these to > > XML fragments in the XML interface. Stubs are usually generated from WSDL by > > tools. I.e. the inteface of a stub is usually fixed by the XML interface. > > > > Delegates are high level. They are usually hand-coded. The methods in a > > delegate class don't always map one-to-one with operations in the WSDL. > > Arguments and return values of delegate classes don't always map trivially to > > the structures in the XML interfaces. I.e., the interface of the delegate can > > be tuned to help the author of client applications. > > > > A delegate can be written to call a stub. This lets the delegate use the > > tool-generated code in the stub and hence to be simpler. > > > > Stubs are hard to produce and use when complex data structures are being > > exchanged. They work best when all the objects that are arguments or return > > values are Java beans (or the equivalent in other languages): these can be > > serialized to and deserialized from XML by standard libraries. The fall-back > > position is to have the stub return a DOM: i.e. to do only the lowest level of > > parsing of the XML. > > > > Trying to generate stubs for services that return VOTable is going to be hard. > > For the use case in the original question, it seems sensible to provide a stub > > that returns a VOTable as a DOM and then provide a delegate that calls the > > stub and returns the VOTable as an object, using a VOTable-specific parser. > > > > AstroGrid provides delegate classes in Java for its services, and these are > > typically based on Java stubs made with Apache-Axis. Authors of applications > > in other languages can still used the published XML interfaces in their own > > stubs and delegates. > > > > The XML interfaces remain the definitions of the services. Stubs and > > delegates are just helper classes to make things easier for authors of > > clients. > > > > 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-grid@eso.org Fri Dec 12 16:00:23 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBCF00g2010411 for ; Fri, 12 Dec 2003 16:00:00 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBCExx4a010408 for grid-outgoing; Fri, 12 Dec 2003 15:59:59 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBCEx3g2010120 for ; Fri, 12 Dec 2003 15:59:04 +0100 (MET) Received: from kintyre.roe.ac.uk (kintyre.roe.ac.uk [195.194.120.72]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBCEx35E025181 for ; Fri, 12 Dec 2003 15:59:03 +0100 (CET) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id B927E460AB; Fri, 12 Dec 2003 14:59:02 +0000 (GMT) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 19107; Fri, 12 Dec 2003 14:59:02 +0000 (GMT) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1C6A5460D0; Fri, 12 Dec 2003 14:59:02 +0000 (GMT) Received: from dial.pipex.com (IFA19P.roe.ac.uk [195.194.122.109]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 47E92460AB; Fri, 12 Dec 2003 14:59:01 +0000 (GMT) Message-ID: <3FD9D7BA.30604@dial.pipex.com> Date: Fri, 12 Dec 2003 14:59:06 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Graham Cc: grid@ivoa.net Subject: Re: VOTable class References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.9 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,USER_AGENT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This may sound a bit strange but we're passing VOTables around as XML documents :-) ie based on the schema. That way we don't have to worry about what object model is being used by the client - or even if the client is java at all. Matthew Graham wrote: > Hi, > > Is anyone trying to pass VOTable around directly between Java web services > and clients? If so, what class are you using to represent VOTable? > > I have found the following all have associated problems: > > (1) JAVOT: requires com.tbf.xml package which has non-bean classes: > XmlNameSpace, XmlObject (both lack default constructors) > > (2) SAVOT: compilation errors (cannot find savot/model/SavotSet; class is > cds.savot.model.SavotSet in cds.savot.model package); VOTable is also not > a bean (not serializable, no default constructor) > > (3) uk.ac.starlink.votable: not a bean (VOTable, VOElement) but easy > enough to alter source code to make them (serializable, default > constructor); however, use java.net.URL and javax.xml.transform.Source > which are not beans. > > (4) voi.vowrite.VOTable: this is a bean but is really only for writing not > reading. > > I realise that lack of beanness does not stop the objects being passed > about but it does mean that they end up being represented as anyType in > the wsdl which does not make for easy translation at the other end. > > Cheers, > > Matthew > > From owner-grid@eso.org Fri Dec 12 18:10:13 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBCH7Bg2009273 for ; Fri, 12 Dec 2003 18:07:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBCH7Atw009272 for grid-outgoing; Fri, 12 Dec 2003 18:07:10 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBCH6bg2009171 for ; Fri, 12 Dec 2003 18:06:37 +0100 (MET) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBCH6aUp004109 for ; Fri, 12 Dec 2003 18:06:36 +0100 (CET) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id JAA28250; Fri, 12 Dec 2003 09:06:23 -0800 (PST) Date: Fri, 12 Dec 2003 09:06:23 -0800 (PST) From: Matthew Graham To: Martin Hill cc: grid@ivoa.net Subject: Re: VOTable class In-Reply-To: <3FD9D7BA.30604@dial.pipex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, > This may sound a bit strange but we're passing VOTables around as XML documents > :-) ie based on the schema. That way we don't have to worry about what object > model is being used by the client - or even if the client is java at all. That is true but it is not just the metadata I want access to but the actual data as well and with big files people will not want to have to handle big XML files so how do you then handle whether the VOTable contains binary or FITS? If you use a dedicated class for this then this is easier :-) Matthew From owner-grid@eso.org Fri Dec 12 19:41:47 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBCIcUg2028136 for ; Fri, 12 Dec 2003 19:38:30 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBCIcUgN028135 for grid-outgoing; Fri, 12 Dec 2003 19:38:30 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBCIbtg2028029 for ; Fri, 12 Dec 2003 19:37:55 +0100 (MET) Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBCIbrUp006351 for ; Fri, 12 Dec 2003 19:37:54 +0100 (CET) Received: from Pisolo (pcp914809pcs.brndml01.va.comcast.net [68.57.150.176]) by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AHP58852 (AUTH aconti); Fri, 12 Dec 2003 13:37:50 -0500 (EST) Message-Id: <200312121837.AHP58852@donner.stsci.edu> From: "Alberto Conti" To: "'Wil O'Mullane'" , Cc: "'Randy Thompson'" Subject: RE: Another WebService returning VOTable Date: Fri, 12 Dec 2003 13:38:42 -0500 Organization: Space Telescope Science Institute MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20031212092022.D18560@skysrv.pha.jhu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPAu5GPXxmSjQKgRJaPjlNvVaYOLgAIyq5g X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu) X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Alberto Conti" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: It might be of interest to some of you that the results of any search in the MultiMission Archives at STScI also returns a VO table. These are not Web-Services (i.e. no wsld files) but it's a quick and dirty way to get VO-tables. Ultimately GALEX will add a XML web-services which also return VO-TAbles. http://archive.stsci.edu/data.html http://galex.stsci.edu Ciao, Alberto > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Wil O'Mullane > Sent: Friday, December 12, 2003 9:20 AM > To: grid@ivoa.net > Subject: Another WebService returning VOTable > > actually now that I think back the SdssCOne is a webservice which uses > the HTTPget since thats what the protocol demands so you may also try > > http://skyservice.pha.jhu.edu/devel/ConeSearch/sdssConeSearch. > asmx?wsdl > > also returns VOTable ... > > > On Fri, Dec 12, 2003 at 09:09:51AM -0500, Wil O'Mullane wrote: > > May I suggest someone points ther java wsdl2java at something like > > > > http://skyservice.pha.jhu.edu/devel/CasService/CasService.asmx?wsdl > > > > it returns a VOTable from > > GetVOtable > > > > Pass it sql like > > > > select top 10 * from galaxy > > > > > > That will give yo a VOTable set of Java classes and you > > will not have to parse the result ... > > > > > > wil > > On Fri, Dec 12, 2003 at 10:18:00AM +0000, Guy Rixon wrote: > > > The question was raised at an AVO meeting "for a > web-service that returns a > > > VOTable can the service return a Java object so we don't > have to parse the > > > VOTable?" > > > > > > Well, the web service itself is defined to return XML, so > it will return > > > VOTable; it can't return Java directly. In any case, a > public service needs > > > to support clients in many languages. > > > > > > The conversion from VOTable to Java _has_ to be done in > the client, but there > > > are three ways to do this: > > > > > > - make the author of the client application write the parser; > > > > > > - have the service publisher supply a stub that does the parsing; > > > > > > - have the service publisher supply a delegate that does > the parsing. > > > > > > Both stubs and delegates are classes in the programming > language that provide > > > the function of the XML interface. They do serialization > of objects to XML and > > > deserialization of objects from XML to the programming > language. Stubs > > > and delegates are both compiled into client programmes. Stubs > > > and delegates operate at different levels of abtraction. > > > > > > Stubs are low level. They match the XML interface > closely. Typically, a stub > > > has one object method for each operation in the XML > interface. Arguments and > > > return values of methods in the stub may be objects; the > stub maps these to > > > XML fragments in the XML interface. Stubs are usually > generated from WSDL by > > > tools. I.e. the inteface of a stub is usually fixed by > the XML interface. > > > > > > Delegates are high level. They are usually hand-coded. > The methods in a > > > delegate class don't always map one-to-one with > operations in the WSDL. > > > Arguments and return values of delegate classes don't > always map trivially to > > > the structures in the XML interfaces. I.e., the > interface of the delegate can > > > be tuned to help the author of client applications. > > > > > > A delegate can be written to call a stub. This lets the > delegate use the > > > tool-generated code in the stub and hence to be simpler. > > > > > > Stubs are hard to produce and use when complex data > structures are being > > > exchanged. They work best when all the objects that are > arguments or return > > > values are Java beans (or the equivalent in other > languages): these can be > > > serialized to and deserialized from XML by standard > libraries. The fall-back > > > position is to have the stub return a DOM: i.e. to do > only the lowest level of > > > parsing of the XML. > > > > > > Trying to generate stubs for services that return VOTable > is going to be hard. > > > For the use case in the original question, it seems > sensible to provide a stub > > > that returns a VOTable as a DOM and then provide a > delegate that calls the > > > stub and returns the VOTable as an object, using a > VOTable-specific parser. > > > > > > AstroGrid provides delegate classes in Java for its > services, and these are > > > typically based on Java stubs made with Apache-Axis. > Authors of applications > > > in other languages can still used the published XML > interfaces in their own > > > stubs and delegates. > > > > > > The XML interfaces remain the definitions of the > services. Stubs and > > > delegates are just helper classes to make things easier > for authors of > > > clients. > > > > > > 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-grid@eso.org Fri Dec 12 19:53:44 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBCIpKg2000833 for ; Fri, 12 Dec 2003 19:51:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBCIpK6A000829 for grid-outgoing; Fri, 12 Dec 2003 19:51:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBCIoig2000670 for ; Fri, 12 Dec 2003 19:50:44 +0100 (MET) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBCIogUp006660 for ; Fri, 12 Dec 2003 19:50:43 +0100 (CET) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id KAA09439 for ; Fri, 12 Dec 2003 10:50:41 -0800 (PST) Date: Fri, 12 Dec 2003 10:50:41 -0800 (PST) From: Matthew Graham To: grid@ivoa.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Can I reiterate that my interest is in serializable Java representations of VOTable, i.e. VOTable as a Java bean, which seems bleeding edge and not in general passing of VOTable by web services in XML or other form, which is well developed. I appreciate that I might have to resort to the latter if the former does not work but I have a specific Java service/client application in mind and so it seems silly not to try and use beans if at all possible. Cheers, Matthew From owner-grid@eso.org Sun Dec 14 17:52:10 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBEGl1Gl002185 for ; Sun, 14 Dec 2003 17:47:01 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBEGl1Y2002184 for grid-outgoing; Sun, 14 Dec 2003 17:47:01 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id hBEGkRGl002084 for ; Sun, 14 Dec 2003 17:46:27 +0100 (MET) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBEGkQUp018145 for ; Sun, 14 Dec 2003 17:46:27 +0100 (CET) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.30) id 1AVZNy-00dkEu-6i; Sun, 14 Dec 2003 16:46:26 +0000 Received: from localhost by dastardly.astro.ex.ac.uk; Sun, 14 Dec 2003 16:46:25 GMT Date: Sun, 14 Dec 2003 16:46:25 +0000 (GMT) From: Alasdair Allan To: Matthew Graham cc: grid@ivoa.net Subject: Re: VOTable and Java Beans In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Matthew Graham wrote: > Guy Rixon wrote: > > Well, the web service itself is defined to return XML, so it will > > return VOTable; it can't return Java directly. In any case, a public > > service needs to support clients in many languages. > > Can I reiterate that my interest is in serializable Java representations > of VOTable, i.e. VOTable as a Java bean, which seems bleeding edge and not > in general passing of VOTable by web services in XML or other form, which > is well developed. I appreciate that I might have to resort to the latter > if the former does not work but I have a specific Java service/client > application in mind and so it seems silly not to try and use beans if at > all possible. I'd really like to hammer Guy's point home, not everyone uses Java, passing around Java objects is not the way to go for a public service. For private interfaces, its obviously fine, although you have to be (very) careful because sometimes supposedly private interfaces become "public" ones. However, public interfaces should be language neutral. Cheers, Al. -- Dr. A. Allan, School of Physics, University of Exeter From owner-grid@eso.org Tue Dec 16 17:10:22 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBGF7G5t013920 for ; Tue, 16 Dec 2003 16:07:16 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBGF7FEh013911 for grid-outgoing; Tue, 16 Dec 2003 16:07:15 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hBGF6i5t013773 for ; Tue, 16 Dec 2003 16:06:44 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBGF6h7c013772 for ws-outgoing; Tue, 16 Dec 2003 16:06:43 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@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.6/8.12.6) with SMTP id hBGF5V61013486 for ; Tue, 16 Dec 2003 16:06:29 +0100 (MET) Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBGEnT4B013144 for ; Tue, 16 Dec 2003 15:49:29 +0100 (CET) Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id hBGEnKuu090562 for ; Tue, 16 Dec 2003 15:49:24 +0100 (CET) Received: from astro.u-strasbg.fr (titeuf.u-strasbg.fr [130.79.129.106]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id hBGEnSr24514 for ; Tue, 16 Dec 2003 15:49:31 +0100 (MET) Message-ID: <3FDF1B6B.8EEE9791@astro.u-strasbg.fr> Date: Tue, 16 Dec 2003 15:49:15 +0100 From: Andre Schaaff Organization: CDS X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,fr-FR MIME-Version: 1.0 To: "ws@ivoa.net" Subject: News Content-Type: text/plain; charset=iso-8859-1 X-Antivirus: scanned by sophos at u-strasbg.fr X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id hBGEnKuu090562 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id hBGF6d5t013759 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andre Schaaff X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hello, The CDS XML Web Service portal has been updated : . Astronomical coordinate translation is now provided as an XML Web Service. . The documentation (examples, ...) available on the portal has been updated. . Other minor changes For any question send a mail to question@simbad.u-strasbg.fr. We can provide other XML Web Services through this portal and you can submit us suggestions. Regards, André http://cdsweb.u-strasbg.fr/cdsws.gml -- André Schaaff Observatoire Astronomique CDS - http://cdsweb.u-strasbg.fr/ 11, rue de l'Université F-67000 Strasbourg From owner-grid@eso.org Wed Jan 14 12:03:12 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0EAw5i6018945 for ; Wed, 14 Jan 2004 11:58:05 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0EAw5Ai018943 for grid-outgoing; Wed, 14 Jan 2004 11:58:05 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0EAw2i6018905 for ; Wed, 14 Jan 2004 11:58:02 +0100 (MET) Received: from artemis.le.ac.uk (artemis.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0EAw0t4024291 for ; Wed, 14 Jan 2004 11:58:01 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1Agiim-00063K-0l for grid@ivoa.net; Wed, 14 Jan 2004 10:58:00 +0000 Received: (qmail 11495 invoked from network); 14 Jan 2004 10:58:17 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 14 Jan 2004 10:58:17 -0000 From: "Tony Linde" To: "Grid_Ivoa_List" Subject: StandardInterfaces V0.1 Date: Wed, 14 Jan 2004 10:58:56 -0000 Organization: University of Leicester Message-ID: <004b01c3da8d$68393790$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i0EAw4i6018938 Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil posted a draft for a standard interface at: http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/StandardInterfaces- 0.1.pdf but I don't remember a notice here. So this is it. Apologies if I missed it. Cheers, Tony. __ Tony Linde Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk Post: Department of Physics & Astronomy, University of Leicester Leicester, UK LE1 7RH Project Manager, Director, AstroGrid Leicester e-Science Centre http://www.astrogrid.org http://www.e-science.le.ac.uk/ From owner-grid@eso.org Wed Jan 14 12:51:09 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0EBk4i6026324 for ; Wed, 14 Jan 2004 12:46:04 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0EBk4ks026323 for grid-outgoing; Wed, 14 Jan 2004 12:46:04 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0EBjui6026289 for ; Wed, 14 Jan 2004 12:45:56 +0100 (MET) Received: from artemis.le.ac.uk (artemis.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0EBjst4025155 for ; Wed, 14 Jan 2004 12:45:54 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1AgjT7-0001Aw-LL for grid@ivoa.net; Wed, 14 Jan 2004 11:45:53 +0000 Received: (qmail 19009 invoked from network); 14 Jan 2004 11:46:14 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 14 Jan 2004 11:46:14 -0000 From: "Tony Linde" To: "'Grid_Ivoa_List'" Subject: RE: StandardInterfaces V0.1 Date: Wed, 14 Jan 2004 11:46:53 -0000 Organization: University of Leicester Message-ID: <005001c3da94$1af848c0$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <004b01c3da8d$68393790$6124d28f@STAR.LE.AC.UK> X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i0EBk2i6026315 Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Firstly, I'm glad Wil has done this and given us something to shoot at. We need to agree this before we set any more specific services. General: - why restrict this to web services? We should be able to agree more than one way of implementing services: web service and cgi as a minimum I guess. 2.1: - most s/w will view the registry as the authoritative source of metadata. If the service administrator has not updated the entry in the registry (or caused it to be harvested) then it won't be recognised by services using the registry. - metadata document is the RM (Resource Metadata) : not RSM (Resource & Metadata) - maybe a link to the document area would be useful here SI-1: - chicken and egg here: does the metadata returned include the authorityId and resourceKey? If so, how is this got? Manually by administrator first, I guess. SI-2: - do we really need this? Most harvesting will be done by using the Metadata i/f and a "since" keyword, so will return changes since some date. General: - do we need to have services harvestable for their metadata? How often will a service's metadata change? If infrequently, it is a waste of time for the registry to ask it each night (or whenever) for metadata changes. And if we end up with tens of thousands of services will burden the registry. Can we not put the onus on the service to update its metadata on the registry whenever a change is made? And then the registries just harvest data from each other. So replace SI-1 and SI-2 with... SI-1: All VO services will update the registry with which they are registered with any changes to metadata. SI-3: - I'm not sure this is necessary. Uptime might be used. ValidTo is unlikely to be kept up to date. ContactDetails are in the metadata. Position: why do we need this? SI-4: - there may be privacy issues with returning what people are doing. This should be optional I think. I'll flag this spec up to the AstroGrid developers and get them to provide their own comments. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Tony Linde > Sent: 14 January 2004 10:59 > To: Grid_Ivoa_List > Subject: StandardInterfaces V0.1 > > > Wil posted a draft for a standard interface at: > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/Stand > ardInterfaces- > 0.1.pdf > > but I don't remember a notice here. So this is it. Apologies > if I missed it. > > Cheers, > Tony. > > __ > Tony Linde > Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 > Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk > Post: Department of Physics & Astronomy, > University of Leicester > Leicester, UK LE1 7RH > > Project Manager, Director, > AstroGrid Leicester e-Science Centre > http://www.astrogrid.org http://www.e-science.le.ac.uk/ > > From owner-grid@eso.org Thu Jan 15 16:29:40 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0FFOhtK009884 for ; Thu, 15 Jan 2004 16:24:43 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0FFOhsA009883 for grid-outgoing; Thu, 15 Jan 2004 16:24:43 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0FFOdtK009857 for ; Thu, 15 Jan 2004 16:24:39 +0100 (MET) Received: from msslty.mssl.ucl.ac.uk (msslty.mssl.ucl.ac.uk [128.40.71.164]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0FFOZt4000105 for ; Thu, 15 Jan 2004 16:24:35 +0100 (CET) Received: from msslai.mssl.ucl.ac.uk (msslai.mssl.ucl.ac.uk [128.40.71.160]) by msslty.mssl.ucl.ac.uk (8.12.10/8.12.10) with ESMTP id i0FFOUn0005620; Thu, 15 Jan 2004 15:24:30 GMT Date: Thu, 15 Jan 2004 15:24:30 +0000 (GMT) From: Elizabeth Auden To: Tony Linde cc: "'Grid_Ivoa_List'" Subject: RE: StandardInterfaces V0.1 In-Reply-To: <005001c3da94$1af848c0$6124d28f@STAR.LE.AC.UK> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MSSL-MailScanner-Information: Please contact the ISP for more information X-MSSL-MailScanner: No virus found X-MSSL-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.524, required 5, BAYES_01 -1.52) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Elizabeth Auden X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > General: > - why restrict this to web services? We should be able to agree more than > one way of implementing services: web service and cgi as a minimum I guess. Is the category of grid / ogsa-dai services included in "web services"? What about GLU? Just curious. > General: > - do we need to have services harvestable for their metadata? How often will > a service's metadata change? If infrequently, it is a waste of time for the > registry to ask it each night (or whenever) for metadata changes. And if we > end up with tens of thousands of services will burden the registry. Can we > not put the onus on the service to update its metadata on the registry > whenever a change is made? What if there is an enumeration element that the service administrator can fill in to let the registry know how often the metadata will change? I.e.: (or something) Hourly Daily Weekly Monthly Yearly Never cheers, Elizabeth From owner-registry@eso.org Fri Jan 16 13:24:32 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0GCNsiL000265 for ; Fri, 16 Jan 2004 13:23:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GCNsal000263 for registry-outgoing; Fri, 16 Jan 2004 13:23:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@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.6/8.12.6) with SMTP id i0GCNgiL000185; Fri, 16 Jan 2004 13:23:42 +0100 (MET) Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GCNet4023625; Fri, 16 Jan 2004 13:23:41 +0100 (CET) Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id i0GCNeGp022461 ; Fri, 16 Jan 2004 13:23:40 +0100 (CET) Received: from simbad.u-strasbg.fr (pclx5.u-strasbg.fr [130.79.129.154]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id i0GCOBi19728; Fri, 16 Jan 2004 13:24:11 +0100 (MET) Message-ID: <4007E0F3.8060009@simbad.u-strasbg.fr> Date: Fri, 16 Jan 2004 14:02:43 +0100 From: Pierre Fernique User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elizabeth Auden CC: registry@ivoa.net, "'Grid_Ivoa_List'" Subject: Re: StandardInterfaces V0.1 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: scanned by sophos at u-strasbg.fr X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-registry@eso.org Precedence: bulk Reply-To: Pierre Fernique X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Elizabeth Auden wrote: >>General: >>- why restrict this to web services? We should be able to agree more than >>one way of implementing services: web service and cgi as a minimum I guess. > > > Is the category of grid / ogsa-dai services included in "web services"? > What about GLU? Just curious. In Glu dictionary, presently there are mainly CGI services. There are also a few records describing the Web services at CDS. By this way one can retrieve the WS base URL and technical documentation for each of them and WS mirror sites can be managed. Try http://simbad.u-strasbg.fr/glu/cgi-bin/GluBrowser.pl?frame=d&p=CDS/ws to browse them. For "GLU service" itself, there are three methods to access it: CGI, WS and language libraries (java,C and Perl). In my mind, I would be very surprise if the future of the astronomy will be only WS. I think that after this fashion time, this technology will take its real place : an open remote procedure call mechanism. Not more, not less. And it certainly won't replace simple CGIs for which there is no real client side. Regards, Pierre Fernique From owner-grid@eso.org Fri Jan 16 13:26:36 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0GCNliL000226 for ; Fri, 16 Jan 2004 13:23:47 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GCNl9U000224 for grid-outgoing; Fri, 16 Jan 2004 13:23:47 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0GCNgiL000185; Fri, 16 Jan 2004 13:23:42 +0100 (MET) Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GCNet4023625; Fri, 16 Jan 2004 13:23:41 +0100 (CET) Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id i0GCNeGp022461 ; Fri, 16 Jan 2004 13:23:40 +0100 (CET) Received: from simbad.u-strasbg.fr (pclx5.u-strasbg.fr [130.79.129.154]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id i0GCOBi19728; Fri, 16 Jan 2004 13:24:11 +0100 (MET) Message-ID: <4007E0F3.8060009@simbad.u-strasbg.fr> Date: Fri, 16 Jan 2004 14:02:43 +0100 From: Pierre Fernique User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elizabeth Auden CC: registry@ivoa.net, "'Grid_Ivoa_List'" Subject: Re: StandardInterfaces V0.1 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: scanned by sophos at u-strasbg.fr X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Pierre Fernique X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Elizabeth Auden wrote: >>General: >>- why restrict this to web services? We should be able to agree more than >>one way of implementing services: web service and cgi as a minimum I guess. > > > Is the category of grid / ogsa-dai services included in "web services"? > What about GLU? Just curious. In Glu dictionary, presently there are mainly CGI services. There are also a few records describing the Web services at CDS. By this way one can retrieve the WS base URL and technical documentation for each of them and WS mirror sites can be managed. Try http://simbad.u-strasbg.fr/glu/cgi-bin/GluBrowser.pl?frame=d&p=CDS/ws to browse them. For "GLU service" itself, there are three methods to access it: CGI, WS and language libraries (java,C and Perl). In my mind, I would be very surprise if the future of the astronomy will be only WS. I think that after this fashion time, this technology will take its real place : an open remote procedure call mechanism. Not more, not less. And it certainly won't replace simple CGIs for which there is no real client side. Regards, Pierre Fernique From owner-registry@eso.org Fri Jan 16 15:47:28 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0GEkwiL007407 for ; Fri, 16 Jan 2004 15:46:58 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GEkwtQ007404 for registry-outgoing; Fri, 16 Jan 2004 15:46:58 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@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.6/8.12.6) with SMTP id i0GEkqiL007381; Fri, 16 Jan 2004 15:46:52 +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 SMTP id i0GEknJX029464; Fri, 16 Jan 2004 15:46:50 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0GEkO930830; Fri, 16 Jan 2004 09:46:24 -0500 Date: Fri, 16 Jan 2004 09:46:24 -0500 From: "Wil O'Mullane" To: Pierre Fernique Cc: Elizabeth Auden , registry@ivoa.net, "'Grid_Ivoa_List'" Subject: Re: StandardInterfaces V0.1 Message-ID: <20040116094624.A30657@skysrv.pha.jhu.edu> References: <4007E0F3.8060009@simbad.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4007E0F3.8060009@simbad.u-strasbg.fr>; from fernique@simbad.u-strasbg.fr on Fri, Jan 16, 2004 at 02:02:43PM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-registry@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > >>- why restrict this to web services? We should be able to agree more than > >>one way of implementing services: web service and cgi as a minimum I guess. > In my mind, I would be very surprise if the future of the astronomy will > be only WS. I think that after this fashion time, this technology will > take its real place : an open remote procedure call mechanism. Not more, > not less. And it certainly won't replace simple CGIs for which there is > no real client side. Yes of course .. I took this out of SkyNode which is SOAP based and it was in the WEb/Grid Servives section. Hence the WS leaning. Then I have a question. If we have these standard interfaces for any CGI how do we relate that to the cgi. DO we add a single parameter like SI where SI=metadata returns metadata and SI=HarvetLog&fromDate=1-1-2000 returns the log. I presume we may still asume XML is returned from these type fo calls. Or should we assume for each CGI a seperate CGI so if i have ../cgi-bin/X I should have ../cgi-bin/stdifX which implenets the standard interfaces.. I rather like option 2 as it means no changes to existing code. For SOAP services of course the document as stands would be fine. XSD may be worked up for the indidvidual return types... wil > > Regards, > Pierre Fernique From owner-grid@eso.org Fri Jan 16 15:49:53 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0GEl8iL007454 for ; Fri, 16 Jan 2004 15:47:08 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GEl8R6007450 for grid-outgoing; Fri, 16 Jan 2004 15:47:08 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0GEkqiL007381; Fri, 16 Jan 2004 15:46:52 +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 SMTP id i0GEknJX029464; Fri, 16 Jan 2004 15:46:50 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0GEkO930830; Fri, 16 Jan 2004 09:46:24 -0500 Date: Fri, 16 Jan 2004 09:46:24 -0500 From: "Wil O'Mullane" To: Pierre Fernique Cc: Elizabeth Auden , registry@ivoa.net, "'Grid_Ivoa_List'" Subject: Re: StandardInterfaces V0.1 Message-ID: <20040116094624.A30657@skysrv.pha.jhu.edu> References: <4007E0F3.8060009@simbad.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4007E0F3.8060009@simbad.u-strasbg.fr>; from fernique@simbad.u-strasbg.fr on Fri, Jan 16, 2004 at 02:02:43PM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > >>- why restrict this to web services? We should be able to agree more than > >>one way of implementing services: web service and cgi as a minimum I guess. > In my mind, I would be very surprise if the future of the astronomy will > be only WS. I think that after this fashion time, this technology will > take its real place : an open remote procedure call mechanism. Not more, > not less. And it certainly won't replace simple CGIs for which there is > no real client side. Yes of course .. I took this out of SkyNode which is SOAP based and it was in the WEb/Grid Servives section. Hence the WS leaning. Then I have a question. If we have these standard interfaces for any CGI how do we relate that to the cgi. DO we add a single parameter like SI where SI=metadata returns metadata and SI=HarvetLog&fromDate=1-1-2000 returns the log. I presume we may still asume XML is returned from these type fo calls. Or should we assume for each CGI a seperate CGI so if i have ../cgi-bin/X I should have ../cgi-bin/stdifX which implenets the standard interfaces.. I rather like option 2 as it means no changes to existing code. For SOAP services of course the document as stands would be fine. XSD may be worked up for the indidvidual return types... wil > > Regards, > Pierre Fernique From owner-grid@eso.org Sat Jan 17 09:56:34 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0H8puNY002541 for ; Sat, 17 Jan 2004 09:51:56 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0H8pu3v002539 for grid-outgoing; Sat, 17 Jan 2004 09:51:56 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0H8psNY002523 for ; Sat, 17 Jan 2004 09:51:54 +0100 (MET) Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0H8pqt4014918 for ; Sat, 17 Jan 2004 09:51:52 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040117085145.THXC10284.mta01-svc.ntlworld.com@gnowee> for ; Sat, 17 Jan 2004 08:51:45 +0000 From: "Tony Linde" To: "'Grid_Ivoa_List'" Subject: RE: StandardInterfaces V0.1 Date: Sat, 17 Jan 2004 08:52:54 -0000 Organization: University of Leicester Message-ID: <006a01c3dcd7$4c41dcd0$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040116094624.A30657@skysrv.pha.jhu.edu> X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Or we could specify in the service's registry entry how each of the methods and its parameters is implemented. Maybe with default values in the xsd. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Wil O'Mullane > Sent: 16 January 2004 14:46 > To: Pierre Fernique > Cc: Elizabeth Auden; registry@ivoa.net; 'Grid_Ivoa_List' > Subject: Re: StandardInterfaces V0.1 > > > > >>- why restrict this to web services? We should be able to > agree more > > >>than one way of implementing services: web service and cgi as a > > >>minimum I guess. > > In my mind, I would be very surprise if the future of the astronomy > > will > > be only WS. I think that after this fashion time, this > technology will > > take its real place : an open remote procedure call > mechanism. Not more, > > not less. And it certainly won't replace simple CGIs for > which there is > > no real client side. > > Yes of course .. I took this out of SkyNode which is SOAP > based and it was in the WEb/Grid Servives section. Hence the > WS leaning. > > Then I have a question. > If we have these standard interfaces for any CGI how do we > relate that to the cgi. DO we add a single parameter like SI > where SI=metadata returns metadata and > SI=HarvetLog&fromDate=1-1-2000 returns the log. > I presume we may still asume XML is returned from these type fo calls. > > Or should we assume for each CGI a seperate CGI so if i have > ../cgi-bin/X I should have ../cgi-bin/stdifX which implenets > the standard interfaces.. > > I rather like option 2 as it means no changes to existing code. > > > For SOAP services of course the document as stands would be fine. > XSD may be worked up for the indidvidual return types... > > > wil > > > > > > Regards, > > Pierre Fernique > From owner-grid@eso.org Mon Jan 19 17:27:14 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0JGOgKC020069 for ; Mon, 19 Jan 2004 17:24:42 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0JGOf0w020068 for grid-outgoing; Mon, 19 Jan 2004 17:24:41 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0JGOcKC020033 for ; Mon, 19 Jan 2004 17:24:38 +0100 (MET) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0JGOb0a006125 for ; Mon, 19 Jan 2004 17:24:37 +0100 (CET) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.30) id 1AicCb-00jCf1-8Z for grid@ivoa.net; Mon, 19 Jan 2004 16:24:37 +0000 Received: from localhost by dastardly.astro.ex.ac.uk; Mon, 19 Jan 2004 16:24:37 GMT Date: Mon, 19 Jan 2004 16:24:37 +0000 (GMT) From: Alasdair Allan To: grid@ivoa.net Subject: OGSI::Lite Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Just noticed a Perl package called OGSI::Lite from the Manchester Supercomputing, Visualization & e-Science Centre. It isn't on CPAN, which is why nobody in the Perl world is talking about it, and why I'd never heard of it before. Has anyone had any experience with it? See http://www.sve.man.ac.uk/Research/AtoZ/ILCT for details. Cheers, Al. From owner-grid@eso.org Tue Jan 20 21:14:07 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0KK9fKQ002016 for ; Tue, 20 Jan 2004 21:09:41 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0KK9fXT002015 for grid-outgoing; Tue, 20 Jan 2004 21:09:41 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0KK9dKQ002001 for ; Tue, 20 Jan 2004 21:09:39 +0100 (MET) Received: from snow.csi.cam.ac.uk (snow.csi.cam.ac.uk [131.111.8.15]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0KK9a5H008496 for ; Tue, 20 Jan 2004 21:09:36 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Aj2Bq-0005bR-3w for grid@ivoa.net; Tue, 20 Jan 2004 20:09:34 +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.12.10+Sun/8.12.10) with ESMTP id i0KK9XB6001046 for ; Tue, 20 Jan 2004 20:09:33 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i0KK9WCp006468 for ; Tue, 20 Jan 2004 20:09:33 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i0KK9WdX006465 for ; Tue, 20 Jan 2004 20:09:32 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 20 Jan 2004 20:09:32 +0000 (GMT) From: Guy Rixon To: grid@ivoa.net Subject: [Globus] Important announcement from GlobusWORLD (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: ---------- Forwarded message ---------- Date: Tue, 20 Jan 2004 10:25:51 -0800 From: Lee Liming To: Announce@globus.org Subject: [Globus] Important announcement from GlobusWORLD The following announcement was made this morning at GlobusWorld, and it should be of interest to the Grid community at large. Please see our website at http://www.globus.org/wsrf for all of the details. -- The Globus Alliance Team Grid and Web Services Standards to Converge New Specifications Will Ease Development and Deployment of Web Services SAN FRANCISCO, CA -- (MARKET WIRE) -- 01/20/2004 -- GLOBUSWORLD -- Akamai, The Globus Alliance, HP, IBM, Sonic Software and TIBCO today proposed new Web services specifications that will integrate Grid and Web services standards. The new WS-Notification and WS-Resource Framework represent the first time a common, standards-based infrastructure will be available for business applications, Grid resources and systems management. These new specifications will help customers lower costs, speed deployment and enable integration across and outside of the enterprise. "These new Web services specifications will significantly extend the types of enterprise solutions customers can easily deploy," said Karla Norsworthy, Director of Dynamic e-Business Technologies, IBM. "These new specifications are important for key business applications and provide customers with the ability to utilize a common Web services based infrastructure that support of Grid and management based solutions." "Web services technology is a key enabler of the Adaptive Enterprise, where business processes and IT are synchronized to capitalize on change. Customers want information technology to behave as a highly efficient, flexible service that can quickly accommodate change in real time," said Al Smith, chief technology officer, Management Software Organization, HP. "The flexibility of an open, standards-based approach is the only way to bring together heterogeneous resources into an effective, manageable IT environment." The WS-Notification specification and the WS-Resource Framework will provide a scalable pub/sub messaging model and the ability to model stateful resources using Web services. Stateful resources are elements that can be modeled including physical entities (such as servers) to logical constructs (such as business agreements and contracts). Access to these stateful resources enables customers to realize business efficiencies including just in time procurement with multiple suppliers, systems outage detection and recovery and Grid-based workload balancing. WS-Notification can automatically trigger an action in the IT infrastructure once certain criteria have been met. This can include suppliers automatically being notified to bid to replenish inventory once current inventory drops to a set level. Several suppliers can be notified of this depletion in inventory and WS-Notification can be set up so that only the supplier with the best bid fills the order. The authors of WS-Notification include Akamai, The Globus Alliance, HP, IBM, SAP, Sonic Software, and TIBCO. "To date, Web Services standards have primarily addressed companies' requirements around definition and management of services. WS-Notification proposes to also specify an agreed upon definition for events," said Derek Collison, vice president of Products and Technologies for TIBCO Software. "Events are what bring a service-oriented architecture to life and a standardized definition for events will accelerate delivery of real-time business to more companies at lower cost." The WS-Resource Framework includes: -- Modeling Stateful Resources with Web services. A white paper describing how to utilize the related specifications to model the resources in the context of Web services. -- WS-Resource Properties defines how data associated with a stateful resource can be queried and changed using Web services technologies. This allows clients to build applications to efficiently read and update data associated with resources, such as contracts, servers or purchase orders. -- WS-Resource Lifetime, which allows the user to specify the period during which a resource definition is valid. For example, WS Resource Lifetime can automatically update suppliers from all systems once contracts or service level agreements expire, or deleting products from inventory systems that are no longer being manufactured. The authors of the new framework include, The Globus Alliance, HP and IBM. "Sonic Software is pleased to be part of the effort to standardize these critical elements of enterprise infrastructure," said Gordon Van Huizen, CTO for Sonic Software. "Scalable, distributed messaging has always been at the heart of an enterprise service bus (ESB), allowing resilient, flexible connectivity and interaction between applications, data sources and business partners. WS-Notification and the WS-Resource Framework promise to speed the adoption of ESBs by offering rich interoperability across enterprise middleware, while supporting a unified, service-oriented fabric for application integration, data access and resource management." "The Globus Alliance is enthusiastic about this latest step in harmonizing Grid services and Web services," said Ian Foster, Argonne National Laboratory associate division director for Mathematics and Computer Science and University of Chicago professor of computer science. "WS-Resource Framework will add clear value for users of the Globus Toolkit and will hasten acceptance of the open standards that are key to the Grid's broad adoption for e-Science and e-Business." "Akamai is excited to collaborate with these new specifications that significantly advance the Open Services Grid Architecture," said Chris Schoettle, Executive Vice President, Technology, Networks & Support, at Akamai. "This effort addresses the growing need for on demand applications that are the underpinning of a resilient, scalable and efficient e-business infrastructure. Akamai's globally distributed computing platform is enabling enterprises to realize new business efficiencies through Web Services and the OSGA." This family of new specifications provides a foundation for the Open Grid Services Architecture. Using WS-Resource Framework and WS-Notification, Grid infrastructures and applications can now be built using Web services specifications. This will facilitate customers' ability to access and share computing resources on demand over the Internet, relying on an infrastructure that is resilient, self-managing and always available. Customers can integrate applications and share data and processing power with huge potential cost and efficiency savings. These specifications provide customers with the ability to share infrastructure across emerging business applications, systems management and grid computing. ---------------------------------------------------------------------------- ---- Contacts: Ron Favali IBM 914 766 4776 favali@us.ibm.com Sherri Stuart HP 856 638 6249 sherri.stuart@hp.com From owner-grid@eso.org Wed Jan 21 11:28:36 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0LAODWB028176 for ; Wed, 21 Jan 2004 11:24:13 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0LAOCto028175 for grid-outgoing; Wed, 21 Jan 2004 11:24:12 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0LAO8WB028160 for ; Wed, 21 Jan 2004 11:24:08 +0100 (MET) Received: from kintyre.roe.ac.uk (kintyre.roe.ac.uk [195.194.120.72]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0LAO6EY027638 for ; Wed, 21 Jan 2004 11:24:06 +0100 (CET) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 48F3A45F9F for ; Wed, 21 Jan 2004 10:24:06 +0000 (GMT) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 18256; Wed, 21 Jan 2004 10:24:05 +0000 (GMT) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id AA9B945F9C for ; Wed, 21 Jan 2004 10:24:05 +0000 (GMT) Received: from relnx02.roe.ac.uk (relnx02.roe.ac.uk [195.194.120.138]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 2842D45F9C for ; Wed, 21 Jan 2004 10:24:05 +0000 (GMT) Date: Wed, 21 Jan 2004 10:24:05 +0000 (GMT) From: Bob Mann To: grid@ivoa.net Subject: Jan 28 Meeting in London on WSRF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=1000.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Bob Mann X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi folks, Further to Guy's posting today about the announcement of the Web Service Resource Framework, here's an announcemnt of a meeting to be held in London on Jan 28th entitled "WSRF: The future of Grid and web services". Registration (details below) is on a first-come, first-served basis. cheers Bob ---------- Forwarded message ---------- Date: Wed, 21 Jan 2004 10:16:06 -0000 From: Lee McLeod To: Everybody Subject: [everybody] News and a Meeting ================== Announcement of Web Service Resource Framework ============================================== Dr Daniel Sabbah, Vice President, Software Development, Strategy and Architecture at IBM, on behalf of IBM and the Globus Alliance, announced proposals for a collection of web service standards that provide conventions for handling stateful resources, e.g., file systems, databases and long-running programs, within the preferred service-oriented architecture of web services. This neatly addresses the requirements of large-scale and long-running systems typical of grid computing while retaining the style of web services favoured by industry. The announcement was made at Globus World (http://www.globusworld.org/) in San Francisco. More information can be found at www.globus.org/wsrf. Professor Tony Hey, Director of the UK e-Science Core Programme said, "The proposed WSRF standards are a very welcome step as they bring the web services and grid communities into closer alignment. This will lead to increased synergy with commercial middleware development that will be of significant value to research communities. In this emerging framework the UK is expected to continue to play a leading role in developing standards and their implementations." Prof Malcolm Atkinson Director of the National e-Science Centre said, "These proposed standards are a very valuable and a much needed step in the integration of web service and grid approaches to large scale distributed systems. I'm delighted to see that they provide an effective framework for handling stateful components which are essential for grids, computational steering and distributed data management. Many European organisations rely on the Globus Toolkit and we are pleased to be at the vanguard of developments which will deliver much greater synergy between commerce and research." Meeting ======= WSRF: The Future of Grid and Web Services ----------------------------------------- We are pleased to announce a presentation and technical discussion on the Web Services Resource Framework. Steve Tuecke and others will present an overview and highlights of the new framework, addressing motivation and technical consequences. This will be followed by a panel discussion with plenty of time for questions. Steve Tuecke of Argonne National Laboratory is the Globus Alliance Systems Architect. He is the leader of the OGSI standardisation working group and is involved in many other GGF and W3C working groups. Date: 28 January 2004 Time: 16:30 for 17:00. The meeting will end by 20:00. Venue: Room 308 (a lecture theatre) of the Huxley building, Imperial College, Queens Gate Agenda ------ 16:30 Registration, Tea, Coffee and biscuits 17:00 High-level Overview of Standards and Technologies Steve Tuecke 17:30 Technical and Engineering Issues Steve Tuecke 18:30 Panel Discussion: What is the impact on e-Science, Grids and Industry? Panel to be announced Please register on the following web site if you intend to attend, places are limited and will be allocated on a first-come-first-served basis. http://www.nesc.ac.uk/esi/events/385/ Steve Tuecke has agreed to be available for further technical discussion on the morning of 29th January from 09:30 to 13:30 before flying back to the USA. If you wish to engage in such further discussion please indicate when you are available and what topic you wish to discuss. We will then endeavour to schedule these meetings. Prof Malcolm Atkinson Director Miss Lee McLeod Conference Administrator/PA to the Assistant Principal National e-Science Centre 13-15 South College Street Edinburgh EH8 9AA +44 (0)131 650 9817 lee@nesc.ac.uk From owner-registry@eso.org Thu Jan 22 15:00:52 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0ME05li026452 for ; Thu, 22 Jan 2004 15:00:05 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0ME051o026450 for registry-outgoing; Thu, 22 Jan 2004 15:00:05 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@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.6/8.12.6) with SMTP id i0MDxxli026386; Thu, 22 Jan 2004 14:59:59 +0100 (MET) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0MDxvWR026743; Thu, 22 Jan 2004 14:59:57 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1AjfN3-0003xx-IF; Thu, 22 Jan 2004 13:59:45 +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.12.10+Sun/8.12.10) with ESMTP id i0MDxhB6017061; Thu, 22 Jan 2004 13:59:43 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i0MDxhCp011623; Thu, 22 Jan 2004 13:59:43 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i0MDxgEu011620; Thu, 22 Jan 2004 13:59:42 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 22 Jan 2004 13:59:42 +0000 (GMT) From: Guy Rixon To: "Wil O'Mullane" cc: Pierre Fernique , Elizabeth Auden , registry@ivoa.net, "'Grid_Ivoa_List'" Subject: Re: StandardInterfaces V0.1 In-Reply-To: <20040116094624.A30657@skysrv.pha.jhu.edu> Message-ID: References: <4007E0F3.8060009@simbad.u-strasbg.fr> <20040116094624.A30657@skysrv.pha.jhu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-registry@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Fri, 16 Jan 2004, Wil O'Mullane wrote: > > >>- why restrict this to web services? We should be able to agree more than > > >>one way of implementing services: web service and cgi as a minimum I guess. > > In my mind, I would be very surprise if the future of the astronomy will > > be only WS. I think that after this fashion time, this technology will > > take its real place : an open remote procedure call mechanism. Not more, > > not less. And it certainly won't replace simple CGIs for which there is > > no real client side. > > Yes of course .. I took this out of SkyNode which is SOAP based and it was in the WEb/Grid Servives section. Hence the WS leaning. > > Then I have a question. > If we have these standard interfaces for any CGI how do we relate that to the > cgi. DO we add a single parameter like SI where > SI=metadata returns metadata > and SI=HarvetLog&fromDate=1-1-2000 returns the log. > I presume we may still asume XML is returned from these type fo calls. At the Strasbourg meeting you suggested (IIRC) a ?metadata prefix on the HTTP GET URL; similar to ?WSDL for Axis SOAP services. Is that idea still feasible? > Or should we assume for each CGI a seperate CGI so if i have > ../cgi-bin/X > I should have > ../cgi-bin/stdifX > which implenets the standard interfaces.. > > I rather like option 2 as it means no changes to existing code. If we do it this way, how do we associate the CGI call for metadata etc with the CGI for the basic service? Should it be like .../cgi-bin/ServiceXyx/TheActualService .../cgi-bin/ServiceXyz/stdifX .../cgi-bin/ServiceXyz/stdifY etc? In that case it won't fit trivially to all existing services without recoding as not all will have the right directory structure. We could also allow .../cgi-bin/TheActualService .../cgi-bin/ServiceXyz/stdifX .../cgi-bin/ServiceXyz/stdifY etc or .../cgi-bin/AnyPathYouLike1/TheActualService .../cgi-bin/AnyPathYouLike2/stdifX .../cgi-bin/AnyPathYouLike3/stdifY and sort the paths out in the registry, with a recommendation to use the same path for all three parts for new work. However, if we do this we don't allow the standard interfaces to be coded as part of the basic service, and some authors may prefer to do that. Is it better to simplify the writing of CGI services by allowing any paths or the writing of clients by prescribing the path? > > For SOAP services of course the document as stands would be fine. > XSD may be worked up for the indidvidual return types... > > > wil > > > > > > Regards, > > Pierre Fernique > 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-grid@eso.org Thu Jan 22 15:20:52 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0MEG5li000260 for ; Thu, 22 Jan 2004 15:16:05 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0MEG5qS000259 for grid-outgoing; Thu, 22 Jan 2004 15:16:05 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0MEFwli000189 for ; Thu, 22 Jan 2004 15:15:58 +0100 (MET) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0MEFuWR027186 for ; Thu, 22 Jan 2004 15:15:56 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1AjfcZ-0000JG-Jk; Thu, 22 Jan 2004 14:15:47 +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.12.10+Sun/8.12.10) with ESMTP id i0MEFeB6017803; Thu, 22 Jan 2004 14:15:41 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i0MEFeCp011795; Thu, 22 Jan 2004 14:15:40 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i0MEFecl011791; Thu, 22 Jan 2004 14:15:40 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 22 Jan 2004 14:15:40 +0000 (GMT) From: Guy Rixon To: Tony Linde cc: "'Grid_Ivoa_List'" Subject: RE: StandardInterfaces V0.1 In-Reply-To: <005001c3da94$1af848c0$6124d28f@STAR.LE.AC.UK> Message-ID: References: <005001c3da94$1af848c0$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 14 Jan 2004, Tony Linde wrote: > Firstly, I'm glad Wil has done this and given us something to shoot at. We > need to agree this before we set any more specific services. > > General: > - why restrict this to web services? We should be able to agree more than > one way of implementing services: web service and cgi as a minimum I guess. > > 2.1: > - most s/w will view the registry as the authoritative source of metadata. > If the service administrator has not updated the entry in the registry (or > caused it to be harvested) then it won't be recognised by services using the > registry. > > - metadata document is the RM (Resource Metadata) : not RSM (Resource & > Metadata) > > - maybe a link to the document area would be useful here > > SI-1: > - chicken and egg here: does the metadata returned include the authorityId > and resourceKey? If so, how is this got? Manually by administrator first, I > guess. > > SI-2: > - do we really need this? Most harvesting will be done by using the Metadata > i/f and a "since" keyword, so will return changes since some date. This interface is useful for checking on harvesting operations. - shows up any cases where new metadata have not yet been harvested, i.e. check harvesting timestamp in registry with curernt value ex service; therefore good for debugging; - allows polling of services for by registries _if_ we decide that any registries want to work that way. I know that you're not much in favour of registries polling services but there may be edge cases where it's desirable. E.g. a private registry monitoring a few, selected services. > General: > - do we need to have services harvestable for their metadata? How often will > a service's metadata change? If infrequently, it is a waste of time for the > registry to ask it each night (or whenever) for metadata changes. And if we > end up with tens of thousands of services will burden the registry. Can we > not put the onus on the service to update its metadata on the registry > whenever a change is made? And then the registries just harvest data from > each other. So replace SI-1 and SI-2 with... > > SI-1: All VO services will update the registry with which they are > registered with any changes to metadata. See above. There may be registries that want to get metadata which the service administrator doesn't know about. Also, one way to implement notification of a registry by a service is for the service to send an "I have changed" message to the registry and for the registry to come back later to harvest. This may be more efficient that the service transmitting all the metadata to the registry in the initial notification. > SI-3: > - I'm not sure this is necessary. Uptime might be used. ValidTo is unlikely > to be kept up to date. ContactDetails are in the metadata. Position: why do > we need this? ValidTo is extremely valuable if the service knows this. Consider the case of a data-warehouse service on which as user plans a job that will take two days to load up and six hours to run. If the service is going down in 40 hours for maintenance then the user need to know that. There has to be some value of validTo that means "don't know". make it a nilable element? Make it optional? Need to agree a format. ISO8601? Or is there an XSD type to use for this? I agree about the contact details. Not sure about Position. Can this be moved to the basic VOResource schema? > SI-4: > - there may be privacy issues with returning what people are doing. This > should be optional I think. I agree that this interface should be optional. Or...if the log is private, perhaps the interface should exist and return an error or an empty log. Logs could be vast if the time-selection parameters are used unwisely; is the service allowed to truncate the response? if so, should it drop earlier or later records? > > I'll flag this spec up to the AstroGrid developers and get them to provide > their own comments. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > Behalf Of Tony Linde > > Sent: 14 January 2004 10:59 > > To: Grid_Ivoa_List > > Subject: StandardInterfaces V0.1 > > > > > > Wil posted a draft for a standard interface at: > > > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/Stand > > ardInterfaces- > > 0.1.pdf > > > > but I don't remember a notice here. So this is it. Apologies > > if I missed it. > > > > Cheers, > > Tony. > > > > __ > > Tony Linde > > Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 > > Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk > > Post: Department of Physics & Astronomy, > > University of Leicester > > Leicester, UK LE1 7RH > > > > Project Manager, Director, > > AstroGrid Leicester e-Science Centre > > http://www.astrogrid.org http://www.e-science.le.ac.uk/ > > > > > > 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-grid@eso.org Thu Jan 22 17:39:33 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0MGZFli007310 for ; Thu, 22 Jan 2004 17:35:15 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0MGZF8b007308 for grid-outgoing; Thu, 22 Jan 2004 17:35:15 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0MGZCli007298 for ; Thu, 22 Jan 2004 17:35:12 +0100 (MET) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0MGZAWR001145 for ; Thu, 22 Jan 2004 17:35:11 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040122163455.UZNF17928.mta07-svc.ntlworld.com@gnowee>; Thu, 22 Jan 2004 16:34:55 +0000 From: "Tony Linde" To: "'Guy Rixon'" Cc: "'Grid_Ivoa_List'" Subject: RE: StandardInterfaces V0.1 Date: Thu, 22 Jan 2004 16:35:43 -0000 Organization: University of Leicester Message-ID: <000c01c3e105$d1da3310$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i0MGZEli007305 Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > I know that you're not much in favour of registries polling > services but there may be edge cases where it's desirable. > E.g. a private registry monitoring a few, selected services. It wasn't that. More that if you're going to call the service anyway, why not just do a 'since' harvest - if you get data returned you know things have changed, if nothing returned then nothing's changed. Don't really need a separate method do you? But we do need different ways for the registry to be kept up to date. For datasets which are changing by the minute then maybe a 'push' is better, for slow changing ones, nightly poll, for static ones, let them ping the registry to come get new stuff. Basically we should have several options from which a sys admin person can chosse per resource. Cheers, Tony. > -----Original Message----- > From: Guy Rixon [mailto:gtr@ast.cam.ac.uk] > Sent: 22 January 2004 14:16 > To: Tony Linde > Cc: 'Grid_Ivoa_List' > Subject: RE: StandardInterfaces V0.1 > ... From owner-grid@eso.org Thu Jan 22 17:53:41 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0MGnHli010091 for ; Thu, 22 Jan 2004 17:49:17 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0MGnHbJ010090 for grid-outgoing; Thu, 22 Jan 2004 17:49:17 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0MGnFli010077 for ; Thu, 22 Jan 2004 17:49:15 +0100 (MET) Received: from snow.csi.cam.ac.uk (snow.csi.cam.ac.uk [131.111.8.15]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0MGnCWR001552 for ; Thu, 22 Jan 2004 17:49:13 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Aji0X-0003l1-BI; Thu, 22 Jan 2004 16:48:41 +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.12.10+Sun/8.12.10) with ESMTP id i0MGmYB6027194; Thu, 22 Jan 2004 16:48:34 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i0MGmYCp013303; Thu, 22 Jan 2004 16:48:34 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i0MGmYOu013299; Thu, 22 Jan 2004 16:48:34 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 22 Jan 2004 16:48:34 +0000 (GMT) From: Guy Rixon To: Tony Linde cc: "'Grid_Ivoa_List'" Subject: RE: StandardInterfaces V0.1 In-Reply-To: <000c01c3e105$d1da3310$6124d28f@STAR.LE.AC.UK> Message-ID: References: <000c01c3e105$d1da3310$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 22 Jan 2004, Tony Linde wrote: > > I know that you're not much in favour of registries polling > > services but there may be edge cases where it's desirable. > > E.g. a private registry monitoring a few, selected services. > > It wasn't that. More that if you're going to call the service anyway, why > not just do a 'since' harvest - if you get data returned you know things > have changed, if nothing returned then nothing's changed. Don't really need > a separate method do you? For harvesting changes, no. For finding out when a change happened, given that regular harvesting has gone wrong for some reason, yes. When debugging, I'd want to find out when the service switched to new metadata and doing this by asking for changes after some cut-off date is clunky. From owner-grid@eso.org Thu Jan 22 18:04:08 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0MGxili011835 for ; Thu, 22 Jan 2004 17:59:44 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0MGxipJ011834 for grid-outgoing; Thu, 22 Jan 2004 17:59:44 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0MGxeli011805 for ; Thu, 22 Jan 2004 17:59:40 +0100 (MET) Received: from snow.csi.cam.ac.uk (snow.csi.cam.ac.uk [131.111.8.15]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0MGxcWR001814 for ; Thu, 22 Jan 2004 17:59:38 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by snow.csi.cam.ac.uk with esmtp (Exim 4.20) id 1AjiAe-0006nA-Em for grid@ivoa.net; Thu, 22 Jan 2004 16:59:08 +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.12.10+Sun/8.12.10) with ESMTP id i0MGx6B6027857 for ; Thu, 22 Jan 2004 16:59:06 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i0MGx6Cp013365 for ; Thu, 22 Jan 2004 16:59:06 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i0MGx6mn013362 for ; Thu, 22 Jan 2004 16:59:06 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 22 Jan 2004 16:59:06 +0000 (GMT) From: Guy Rixon To: grid@ivoa.net Subject: Re: Jan 28 Meeting in London on WSRF In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I've registered to go to this meeting. If anybody on this list has questions about WSRF but can't get to the meeting, then email me and I'lll see if I can get some answers. Cheers, Guy On Wed, 21 Jan 2004, Bob Mann wrote: > > Hi folks, > > Further to Guy's posting today about the announcement of the > Web Service Resource Framework, here's an announcemnt of a meeting > to be held in London on Jan 28th entitled "WSRF: The future of Grid > and web services". Registration (details below) is on a first-come, > first-served basis. > > cheers > > Bob > > > ---------- Forwarded message ---------- > Date: Wed, 21 Jan 2004 10:16:06 -0000 > From: Lee McLeod > To: Everybody > Subject: [everybody] > > News and a Meeting > ================== > > Announcement of Web Service Resource Framework > ============================================== > > Dr Daniel Sabbah, Vice President, Software Development, Strategy and > Architecture at IBM, on behalf of IBM and the Globus Alliance, announced > proposals for a collection of web service standards that provide > conventions for handling stateful resources, e.g., file systems, > databases and long-running programs, within the preferred > service-oriented architecture of web services. This neatly addresses > the requirements of large-scale and long-running systems typical of grid > computing while retaining the style of web services favoured by > industry. > > The announcement was made at Globus World (http://www.globusworld.org/) > in San Francisco. More information can be found at www.globus.org/wsrf. > > Professor Tony Hey, Director of the UK e-Science Core Programme said, > > "The proposed WSRF standards are a very welcome step as they bring the > web services and grid communities into closer alignment. This will lead > to increased synergy with commercial middleware development that will be > of significant value to research communities. In this emerging > framework the UK is expected to continue to play a leading role in > developing standards and their implementations." > > Prof Malcolm Atkinson Director of the National e-Science Centre said, > > "These proposed > standards are a very valuable and a much needed step in the integration > of web service and grid approaches to large scale distributed systems. > I'm delighted to see that they provide an effective framework for > handling stateful components which are essential for grids, > computational steering and distributed data management. Many European > organisations rely on the Globus Toolkit and we are pleased to be at the > vanguard of > developments which will deliver much greater synergy between commerce > and research." > > Meeting > ======= > > WSRF: The Future of Grid and Web Services > ----------------------------------------- > > We are pleased to announce a presentation and technical discussion on > the Web Services Resource Framework. Steve Tuecke and others will > present an overview and highlights of the new framework, addressing > motivation and technical consequences. This will be followed by a panel > discussion with plenty of time for questions. > > Steve Tuecke of Argonne National Laboratory is the Globus Alliance > Systems Architect. He is the leader of the OGSI standardisation working > group and is involved in many other GGF and W3C working groups. > > > Date: 28 January 2004 > Time: 16:30 for 17:00. The meeting will end by 20:00. > Venue: Room 308 (a lecture theatre) of the Huxley building, Imperial > College, Queens Gate > > Agenda > ------ > 16:30 Registration, Tea, Coffee and biscuits > 17:00 High-level Overview of Standards and Technologies Steve > Tuecke > 17:30 Technical and Engineering Issues Steve > Tuecke > > 18:30 Panel Discussion: What is the impact on e-Science, Grids and > Industry? Panel to be announced > > Please register on the following web site if you intend to attend, > places are limited and will be allocated on a first-come-first-served > basis. > > http://www.nesc.ac.uk/esi/events/385/ > > Steve Tuecke has agreed to be available for further technical discussion > on the morning of 29th January from 09:30 to 13:30 before flying back to > the USA. If you wish to engage in such further discussion please > indicate when you are available and what topic you wish to discuss. We > will then endeavour to schedule these meetings. > > Prof Malcolm Atkinson > Director > > Miss Lee McLeod > Conference Administrator/PA to the Assistant Principal > National e-Science Centre > 13-15 South College Street > Edinburgh EH8 9AA > +44 (0)131 650 9817 > lee@nesc.ac.uk > > > > 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-grid@eso.org Fri Jan 23 17:30:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NGRGgK027317 for ; Fri, 23 Jan 2004 17:27:16 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NGRGDD027314 for grid-outgoing; Fri, 23 Jan 2004 17:27:16 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0NGR2gK027199 for ; Fri, 23 Jan 2004 17:27:02 +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 SMTP id i0NGR0EY010840 for ; Fri, 23 Jan 2004 17:27:01 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0NGQod06208; Fri, 23 Jan 2004 11:26:50 -0500 Date: Fri, 23 Jan 2004 11:26:50 -0500 From: "Wil O'Mullane" To: Elizabeth Auden Cc: Tony Linde , "'Grid_Ivoa_List'" Subject: Re: StandardInterfaces V0.1 Message-ID: <20040123112650.D4059@skysrv.pha.jhu.edu> References: <005001c3da94$1af848c0$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from eca@mssl.ucl.ac.uk on Thu, Jan 15, 2004 at 03:24:30PM +0000 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > Is the category of grid / ogsa-dai services included in "web services"? > What about GLU? Just curious. yes these are web services > > What if there is an enumeration element that the service administrator can > fill in to let the registry know how often the metadata will change? > I.e.: > (or something) > Hourly > Daily > Weekly > Monthly > Yearly > Never I had rather though the registry would just periodically (weekly oe daily) ping resources using MedaDataChangedOn and see if it needed to get a new version. The registry could decide how often. It might provide a spcific refresh method to allow someone to tell it get a new vewrsion also. In the same sweep the registry my try the Heartbeat and if it frequently gets no response from a resource flag it up .. From owner-grid@eso.org Fri Jan 23 18:09:42 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NH6vgK006617 for ; Fri, 23 Jan 2004 18:06:57 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NH6vJ7006616 for grid-outgoing; Fri, 23 Jan 2004 18:06:57 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0NH6pgK006554 for ; Fri, 23 Jan 2004 18:06:51 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NGK8WR002497 for ; Fri, 23 Jan 2004 17:20:09 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0NGK7506051 for grid@ivoa.net; Fri, 23 Jan 2004 11:20:07 -0500 Date: Fri, 23 Jan 2004 11:20:07 -0500 From: "Wil O'Mullane" Cc: "'Grid_Ivoa_List'" Subject: Re: StandardInterfaces V0.1 Message-ID: <20040123112007.C4059@skysrv.pha.jhu.edu> References: <004b01c3da8d$68393790$6124d28f@STAR.LE.AC.UK> <005001c3da94$1af848c0$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <005001c3da94$1af848c0$6124d28f@STAR.LE.AC.UK>; from ael@star.le.ac.uk on Wed, Jan 14, 2004 at 11:46:53AM -0000 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > 2.1: > - most s/w will view the registry as the authoritative source of metadata. > If the service administrator has not updated the entry in the registry (or > caused it to be harvested) then it won't be recognised by services using the > registry. I would like howver as a provider to tell the regitry here is my service and have it come get my metadata rather than putting on a form or uploading it. > - metadata document is the RM (Resource Metadata) : not RSM (Resource & > Metadata) ok > > - maybe a link to the document area would be useful here ok > > SI-1: > - chicken and egg here: does the metadata returned include the authorityId > and resourceKey? If so, how is this got? Manually by administrator first, I > guess. Yes I presume so - shall clarify as such in the doc > > SI-2: > - do we really need this? Most harvesting will be done by using the Metadata > i/f and a "since" keywoA rd, so will return changes since some date. Harvisting is a registry thing - this is a single record for one service. Its not quite the same thing. > each other. So replace SI-1 and SI-2 with... > SI-1: All VO services will update the registry with which they are > registered with any changes to metadata. But why if the registry knows there is a service why not let it check on it and get new metadata iif available. > SI-4: > - there may be privacy issues with returning what people are doing. This > should be optional I think. This is a "should" requirement - optional. Perhaps we need more anonymous statistical operations .. Or if we dropped the actual ip for a more anonymous grouping ? From owner-grid@eso.org Fri Jan 23 18:09:49 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NH7CgK006693 for ; Fri, 23 Jan 2004 18:07:12 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NH7Ct6006692 for grid-outgoing; Fri, 23 Jan 2004 18:07:12 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0NH6pgO006554 for ; Fri, 23 Jan 2004 18:07:07 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NFkCWR029361 for ; Fri, 23 Jan 2004 16:46:13 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0NFkBl05189 for grid@ivoa.net; Fri, 23 Jan 2004 10:46:11 -0500 Date: Fri, 23 Jan 2004 10:46:11 -0500 From: "Wil O'Mullane" To: grid@ivoa.net Subject: Re: StandardInterfaces V0.1 Message-ID: <20040123104611.B4059@skysrv.pha.jhu.edu> References: <4007E0F3.8060009@simbad.u-strasbg.fr> <20040116094624.A30657@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gtr@ast.cam.ac.uk on Thu, Jan 22, 2004 at 01:59:42PM +0000 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I would like to put a new spec out with something in it ... I guess it may always be changed I do not like multiple paths specified in the MEtadata as that measn a new piece of metadata for each standard service and it requires me to look at the metadata to call the standard service. I prefer a standard servivce in astandard place i.e. either of the ones I mentioned 1. params to the CGI like discussed in strasbourg. 2. a standard named service e.g. if my service is TheService I have theServiceSTDIF which takes params to do the standard services or 3. Guys first one below. I perfer most 2. Can we get a vote on it ? wil > If we do it this way, how do we associate the CGI call for metadata etc with > the CGI for the basic service? Should it be like > > .../cgi-bin/ServiceXyx/TheActualService > .../cgi-bin/ServiceXyz/stdifX > .../cgi-bin/ServiceXyz/stdifY > etc? > > In that case it won't fit trivially to all existing services without recoding > as not all will have the right directory structure. > > We could also allow > > .../cgi-bin/TheActualService > .../cgi-bin/ServiceXyz/stdifX > .../cgi-bin/ServiceXyz/stdifY > etc > > or > > .../cgi-bin/AnyPathYouLike1/TheActualService > .../cgi-bin/AnyPathYouLike2/stdifX > .../cgi-bin/AnyPathYouLike3/stdifY > > and sort the paths out in the registry, with a recommendation to use the same > path for all three parts for new work. > > However, if we do this we don't allow the standard interfaces to be coded as > part of the basic service, and some authors may prefer to do that. > > Is it better to simplify the writing of CGI services by allowing any paths or > the writing of clients by prescribing the path? > From owner-grid@eso.org Fri Jan 23 19:04:27 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NI1jgK015968 for ; Fri, 23 Jan 2004 19:01:45 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NI1jTl015967 for grid-outgoing; Fri, 23 Jan 2004 19:01:45 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0NI1fgK015956 for ; Fri, 23 Jan 2004 19:01:41 +0100 (MET) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NI1dWR005429 for ; Fri, 23 Jan 2004 19:01:40 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040123180137.JONJ22499.mta06-svc.ntlworld.com@gnowee>; Fri, 23 Jan 2004 18:01:37 +0000 From: "Tony Linde" To: "'Wil O'Mullane'" , Subject: RE: StandardInterfaces V0.1 Date: Fri, 23 Jan 2004 18:02:43 -0000 Organization: University of Leicester Message-ID: <008a01c3e1db$19952cc0$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20040123104611.B4059@skysrv.pha.jhu.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i0NI1igK015964 Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think I like the cgi params better (but I'm neither a cgi programmer nor a web service programmer). Thinking... If a service is registered, we need to specify how it is invoked, so you specify the call method, cgi or ws, and the invocation string. The service will be registered under one of the complexTypes, SkyService, say. Now, does this registry entry include information on how to call the standard methods available under a SkyService? Or do we assume that anything registered as a SkyService must supply the standard list of methods. Or do we allow both: expect the standard methods but allow a service to supply them in different ways if it wants (in which case its registry entry must include how to call each of the standard methods). And if the service includes extra methods, how does the registry entry include a description of them? This musing probably belongs in the registry list but if we're looking to define standard interfaces, it is relevant, or is it? > and it requires me to > look at the metadata to call the standard service. Does that matter? Most software will use the registry to discover services so they'll have the entry to hand. If they already *know* about the service they probably know about how to call the standard methods. > 2. a standard named service e.g. if my service is TheService > I have theServiceSTDIF which takes params to do the > standard services I don't understand this Wil. Do you mean that if the standard interface includes a Metadata method, then a .../cgi-bin/DataLookup service would create a .../cgi-bin/DataLookupMetadata service? Is that what you mean? If not, what is STDIF and how would the Metadata method be invoked? Thanks, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Wil O'Mullane > Sent: 23 January 2004 15:46 > To: grid@ivoa.net > Subject: Re: StandardInterfaces V0.1 > > > I would like to put a new spec out with something in it ... > I guess it may always be changed > I do not like multiple paths specified in the MEtadata as > that measn a new piece of metadata for each standard service > and it requires me to > look at the metadata to call the standard service. > > I prefer a standard servivce in astandard place i.e. either > of the ones I mentioned > 1. params to the CGI like discussed in strasbourg. > 2. a standard named service e.g. if my service is TheService > I have theServiceSTDIF which takes params to do the > standard services or 3. Guys first one below. > > I perfer most 2. > > Can we get a vote on it ? > > wil > > If we do it this way, how do we associate the CGI call for metadata > > etc with the CGI for the basic service? Should it be like > > > > .../cgi-bin/ServiceXyx/TheActualService > > .../cgi-bin/ServiceXyz/stdifX > > .../cgi-bin/ServiceXyz/stdifY > > etc? > > > > In that case it won't fit trivially to all existing > services without > > recoding as not all will have the right directory structure. > > > > We could also allow > > > > .../cgi-bin/TheActualService > > .../cgi-bin/ServiceXyz/stdifX > > .../cgi-bin/ServiceXyz/stdifY > > etc > > > > or > > > > .../cgi-bin/AnyPathYouLike1/TheActualService > > .../cgi-bin/AnyPathYouLike2/stdifX > > .../cgi-bin/AnyPathYouLike3/stdifY > > > > and sort the paths out in the registry, with a > recommendation to use > > the same path for all three parts for new work. > > > > However, if we do this we don't allow the standard interfaces to be > > coded as part of the basic service, and some authors may > prefer to do > > that. > > > > Is it better to simplify the writing of CGI services by > allowing any > > paths or the writing of clients by prescribing the path? > > > From owner-grid@eso.org Fri Jan 23 19:14:12 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NIBWgK017018 for ; Fri, 23 Jan 2004 19:11:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NIBWwW017017 for grid-outgoing; Fri, 23 Jan 2004 19:11:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0NIBSgK017009 for ; Fri, 23 Jan 2004 19:11:28 +0100 (MET) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NIBMEY013577 for ; Fri, 23 Jan 2004 19:11:22 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040123181118.IELC17928.mta07-svc.ntlworld.com@gnowee> for ; Fri, 23 Jan 2004 18:11:18 +0000 From: "Tony Linde" To: "'Grid_Ivoa_List'" Subject: RE: StandardInterfaces V0.1 Date: Fri, 23 Jan 2004 18:12:11 -0000 Organization: University of Leicester Message-ID: <008b01c3e1dc$745c3300$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20040123112007.C4059@skysrv.pha.jhu.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i0NIBVgK017014 Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > I would like howver as a provider to tell the regitry here is > my service and have it come get my metadata rather than > putting on a form or uploading it. That makes sense, but what about services which already exist and which no-one wants to modify: presumably their owner can add the registry entry manually and set a flag saying that the service does not support the Metadata method. > Harvisting is a registry thing - this is a single record for > one service. Its not quite the same thing. Ok. If everyone else wants to keep the MetaDataChangedOn method then that's fine. > But why if the registry knows there is a service why not let > it check on it and get new metadata iif available. Just seemed more efficient for the resource to push its changes to the registry than have the registry keep checking it for changes. I don't mind but I do think, as has been said elsewhere, that we need a range of options: push, pull, poll, notify etc. > > SI-4: This will always be problematic. Maybe we should go for a simpler interface to start with and leave this out. If everyone else wants to keep it then it must be optional. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Wil O'Mullane > Sent: 23 January 2004 16:20 > Cc: 'Grid_Ivoa_List' > Subject: Re: StandardInterfaces V0.1 > > > > 2.1: > > - most s/w will view the registry as the authoritative > source of metadata. > > If the service administrator has not updated the entry in > the registry (or > > caused it to be harvested) then it won't be recognised by > services using the > > registry. > I would like howver as a provider to tell the regitry here is > my service and have it come get my metadata rather than > putting on a form or uploading it. > > > - metadata document is the RM (Resource Metadata) : not RSM > (Resource > > & > > Metadata) > ok > > > > - maybe a link to the document area would be useful here > ok > > > > SI-1: > > - chicken and egg here: does the metadata returned include the > > authorityId and resourceKey? If so, how is this got? Manually by > > administrator first, I guess. > Yes I presume so - shall clarify as such in the doc > > > > SI-2: > > - do we really need this? Most harvesting will be done by using the > > Metadata i/f and a "since" keywoA rd, so will return changes since > > some date. > Harvisting is a registry thing - this is a single record for > one service. Its not quite the same thing. > > each other. So replace SI-1 and SI-2 with... > > > SI-1: All VO services will update the registry with which they are > > registered with any changes to metadata. > But why if the registry knows there is a service why not let > it check on it and get new metadata iif available. > > > SI-4: > > - there may be privacy issues with returning what people are doing. > > This should be optional I think. > This is a "should" requirement - optional. > > Perhaps we need more anonymous statistical operations .. > Or if we dropped the actual ip for a more anonymous grouping > ? > From owner-grid@eso.org Mon Jan 26 12:27:35 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0QBR2dl000627 for ; Mon, 26 Jan 2004 12:27:02 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0QBR2sd000626 for grid-outgoing; Mon, 26 Jan 2004 12:27:02 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0QBQxdl000611 for ; Mon, 26 Jan 2004 12:26:59 +0100 (MET) Received: from brown.csi.cam.ac.uk (brown.csi.cam.ac.uk [131.111.8.14]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0QBQvEY029002 for ; Mon, 26 Jan 2004 12:26:57 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Al4tK-00022q-OB for grid@ivoa.net; Mon, 26 Jan 2004 11:26:54 +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.12.10+Sun/8.12.10) with ESMTP id i0QBQqB6020070 for ; Mon, 26 Jan 2004 11:26:52 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i0QBQqCp023675 for ; Mon, 26 Jan 2004 11:26:52 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i0QBQq3m023672 for ; Mon, 26 Jan 2004 11:26:52 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 26 Jan 2004 11:26:52 +0000 (GMT) From: Guy Rixon To: grid@ivoa.net Subject: WS-Addressing & accrefs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, we will need, sometime soon, a web-service equivalent of the access-reference in SIAP. The current accref is a HTTP-GET URL with request parameters embedded, so doesn't work for SOAP services. The recent proposed-standard WS-Addressing (http://www-106.ibm.com/developerworks/webservices/library/ws-add/) defines an XML vocabulary for representing WS endpoints. It's designed to add routing information to SOAP headers, but we could use it to add accrefs to SOAP bodies. Possibly better than writing our own standard. 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-grid@eso.org Mon Jan 26 19:08:37 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0QI8Hdl027410 for ; Mon, 26 Jan 2004 19:08:17 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0QI8HBk027408 for grid-outgoing; Mon, 26 Jan 2004 19:08:17 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0QI8Cdl027380 for ; Mon, 26 Jan 2004 19:08:12 +0100 (MET) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0QI8AWR000203 for ; Mon, 26 Jan 2004 19:08:10 +0100 (CET) Received: from zia.aoc.nrao.edu (zia [146.88.1.4]) by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i0QI87506324; Mon, 26 Jan 2004 11:08:07 -0700 Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232]) by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i0QI86xq026810; Mon, 26 Jan 2004 11:08:06 -0700 (MST) Date: Mon, 26 Jan 2004 11:08:06 -0700 (MST) From: Doug Tody X-X-Sender: dtody@oak To: Guy Rixon cc: grid@ivoa.net Subject: Re: WS-Addressing & accrefs In-Reply-To: Message-ID: 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=-6.7, required 7, BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37, QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00, USER_AGENT_PINE 0.00) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy - Are you referring to the actual "getImage" acref in SIA, or to the SIA query? The part that is most naturally cast into a web-service is the query since it is a request with parameters. The acref is, at least in the current form of SIA, is a simple link which is opaque to the interface, and does not have any (explicit) request parameters. If it had arguments it would be a natural to promote to a web-service interface, but so long as it remains a simple static link this seems unnecessary. Since the query is basically a request with arguments it would be easy to have equivalent GET, POST, and SOAP requests. The query response, a VOTable document, could possibly be identical in all cases. - Doug On Mon, 26 Jan 2004, Guy Rixon wrote: > Hi, > > we will need, sometime soon, a web-service equivalent of the access-reference > in SIAP. The current accref is a HTTP-GET URL with request parameters > embedded, so doesn't work for SOAP services. > > The recent proposed-standard WS-Addressing > (http://www-106.ibm.com/developerworks/webservices/library/ws-add/) > defines an XML vocabulary for representing WS endpoints. It's designed to add > routing information to SOAP headers, but we could use it to add accrefs to > SOAP bodies. Possibly better than writing our own standard. > > 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-grid@eso.org Mon Jan 26 20:20:53 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0QJKYdl012029 for ; Mon, 26 Jan 2004 20:20:34 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0QJKYpD012028 for grid-outgoing; Mon, 26 Jan 2004 20:20:34 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with SMTP id i0QJKWdl012014 for ; Mon, 26 Jan 2004 20:20:32 +0100 (MET) Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0QJKUEY011736 for ; Mon, 26 Jan 2004 20:20:30 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1AlCHS-0004Az-Pv; Mon, 26 Jan 2004 19:20:18 +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.12.10+Sun/8.12.10) with ESMTP id i0QJKHB6016056; Mon, 26 Jan 2004 19:20:17 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i0QJKGCp024577; Mon, 26 Jan 2004 19:20:16 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i0QJKGJ7024574; Mon, 26 Jan 2004 19:20:16 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 26 Jan 2004 19:20:16 +0000 (GMT) From: Guy Rixon To: Doug Tody cc: grid@ivoa.net Subject: Re: WS-Addressing & accrefs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Doug, I was referring the the accref used in getImage. I agree that we might have a query part as a SOAP service with a HTTP-get service as the target of the accref. I realise that this covers most of the use cases for SIAP. However, there are some edge cases which may become important and for these we will probably need a SOAP service as target of an accref. Best way to explain what I mean is a document I've been preparing: http://wiki.astrogrid.org/bin/view/Astrogrid/AccrefsInWsResource I was going to open this to the group next week when I'd improved it a bit but maybe it's best that you see the first draft. On Mon, 26 Jan 2004, Doug Tody wrote: > Guy - > > Are you referring to the actual "getImage" acref in SIA, or to the SIA > query? The part that is most naturally cast into a web-service is the > query since it is a request with parameters. The acref is, at least in > the current form of SIA, is a simple link which is opaque to the interface, > and does not have any (explicit) request parameters. If it had arguments > it would be a natural to promote to a web-service interface, but so long > as it remains a simple static link this seems unnecessary. > > Since the query is basically a request with arguments it would be easy > to have equivalent GET, POST, and SOAP requests. The query response, > a VOTable document, could possibly be identical in all cases. > > - Doug > > > > > On Mon, 26 Jan 2004, Guy Rixon wrote: > > > Hi, > > > > we will need, sometime soon, a web-service equivalent of the access-reference > > in SIAP. The current accref is a HTTP-GET URL with request parameters > > embedded, so doesn't work for SOAP services. > > > > The recent proposed-standard WS-Addressing > > (http://www-106.ibm.com/developerworks/webservices/library/ws-add/) > > defines an XML vocabulary for representing WS endpoints. It's designed to add > > routing information to SOAP headers, but we could use it to add accrefs to > > SOAP bodies. Possibly better than writing our own standard. > > > > 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-grid@eso.org Wed Apr 14 02:16:06 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3E0FUYm023423 for ; Wed, 14 Apr 2004 02:15:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3E0FU58023422 for grid-outgoing; Wed, 14 Apr 2004 02:15:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i3E0FRYm023418 for ; Wed, 14 Apr 2004 02:15:27 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3E0FPTY011620 for ; Wed, 14 Apr 2004 02:15:25 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id RAA17985 for ; Tue, 13 Apr 2004 17:15:24 -0700 (PDT) Date: Tue, 13 Apr 2004 17:15:24 -0700 (PDT) From: Matthew Graham To: grid@ivoa.net Subject: JNI and web services Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I am trying to expose some C code as a web service via Java and JNI. Everything works fine in a standalone mode but when I put it all together as a web service with Tomcat/Axis, the dynamic library that JNI creates (libfoo.so) cannot be found. This is the classic UnsatisfiedLinkError that JNI throws out because the library is not in java.library.path; however, how does one go about setting java.library.path so that it will get picked up without hardcoding the Tomcat setup? I have tried setting java.library.path just before the C code is called and loading the library is attempted but it does not seem to work; has anyone tried this and if so, got it to work? Cheers, Matthew From owner-grid@eso.org Wed Apr 14 11:29:44 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3E9THYm004374 for ; Wed, 14 Apr 2004 11:29:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3E9THLS004373 for grid-outgoing; Wed, 14 Apr 2004 11:29:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i3E9TFYm004367 for ; Wed, 14 Apr 2004 11:29:15 +0200 (MEST) Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3E9TDXe013921 for ; Wed, 14 Apr 2004 11:29:14 +0200 (CEST) Received: from mach.laeff.esa.es (hubble.laeff.esa.es [193.147.152.202]) by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3E9SeCg015338; Wed, 14 Apr 2004 11:28:40 +0200 (MET DST) Received: from laeff.esa.es (marconi [192.168.130.153]) by mach.laeff.esa.es (8.9.3/8.9.3) with ESMTP id LAA21552; Wed, 14 Apr 2004 11:26:12 +0200 (MET DST) Message-ID: <407D0447.2080109@laeff.esa.es> Date: Wed, 14 Apr 2004 11:28:39 +0200 From: Raul Gutierrez Sanchez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es, en MIME-Version: 1.0 To: Matthew Graham CC: grid@ivoa.net Subject: Re: JNI and web services References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Raul Gutierrez Sanchez X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Matthew, libfoo.so must be placed in a directory listed in the library path, which is a list of directories that the Java runtime system searches when loading libraries. Make sure that the name of the directory where the libfoo.so library lives is in it. You can also change the library path. If you use a UNIX-like system (as it seems), you have to add the directory containing libfoo.so to your system $LD_LIBRARY_PATH (see the following link for more information: http://java.sun.com/docs/books/tutorial/native1.1/stepbystep/_setlibpath.html ). Cheers, Raúl Matthew Graham wrote: >Hi, > >I am trying to expose some C code as a web service via Java and JNI. >Everything works fine in a standalone mode but when I put it all together >as a web service with Tomcat/Axis, the dynamic library that JNI creates >(libfoo.so) cannot be found. This is the classic UnsatisfiedLinkError that >JNI throws out because the library is not in java.library.path; however, >how does one go about setting java.library.path so that it will get picked >up without hardcoding the Tomcat setup? > >I have tried setting java.library.path just before the C code is called >and loading the library is attempted but it does not seem to work; has >anyone tried this and if so, got it to work? > > Cheers, > > Matthew > > > > -- ----------------------------------------------------------------------------- Raúl Gutiérrez Sánchez ( raul@laeff.esa.es ) Laboratorio de Astrofísica Espacial y Física Fundamental (www.laeff.esa.es) Villafranca del Castillo Satellite Tracking Station Villafranca del Castillo - E-28691 Villanueva de la Cañada - Madrid - España Tel.: 34 91 8131260 Fax.: 34 91 8131160 ----------------------------------------------------------------------------- From owner-grid@eso.org Wed Apr 14 18:55:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3EGscHK020125 for ; Wed, 14 Apr 2004 18:54:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3EGsc2f020124 for grid-outgoing; Wed, 14 Apr 2004 18:54:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i3EGsZHK020112 for ; Wed, 14 Apr 2004 18:54:35 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3EGsXXe010965 for ; Wed, 14 Apr 2004 18:54:34 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id JAA20936; Wed, 14 Apr 2004 09:54:28 -0700 (PDT) Date: Wed, 14 Apr 2004 09:54:28 -0700 (PDT) From: Matthew Graham To: Raul Gutierrez Sanchez cc: grid@ivoa.net Subject: Re: JNI and web services In-Reply-To: <407D0447.2080109@laeff.esa.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I have no problem with running a standalone application which uses JNI where I can set LD_LIBRARY_PATH from the command line. The problem here is what to do with a web service that uses JNI: the library path seems to have to be set when Tomcat is started so I can include the path to libfoo.so in $CATALINA_OPTS but: - this is system dependent - what happens if I have a whole suite of libfoo's - I would also have to stop and restart Tomcat when I added a new one - this is not easily deployable to other machines where I might not have control over Tomcat. In the WS code I tried: String jlp = System.getProperty("java.library.path"); String newpath = jlp + ":" + ; System.setProperty("java.library.path", newpath); which does set java.library.path properly but the subsequent call: static (System.loadLibrary("foo")) does not pick the new path up and so I get the UnsatisfiedLinkError. Cheers, Matthew From owner-apps@eso.org Wed Apr 14 22:25:23 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3EKP2HK022913 for ; Wed, 14 Apr 2004 22:25:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3EKP2Fq022912 for apps-outgoing; Wed, 14 Apr 2004 22:25:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@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.6/8.12.6) with ESMTP id i3EKOxHK022903; Wed, 14 Apr 2004 22:24:59 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3EKOvXe025225; Wed, 14 Apr 2004 22:24:58 +0200 (CEST) Received: from localhost (budavari@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id i3EKOsf09932; Wed, 14 Apr 2004 16:24:54 -0400 X-Authentication-Warning: skysrv.pha.jhu.edu: budavari owned process doing -bs Date: Wed, 14 Apr 2004 16:24:54 -0400 (EDT) From: Tamas Budavari To: apps@ivoa.net, cc: Alex Szalay , Jim Gray , "Wil O'Mullane" , "Maria A. Nieto-Santisteban" , Jan vandenBerg , Laszlo Dobos Subject: Python WS toolkit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-apps@eso.org Precedence: bulk Reply-To: Tamas Budavari X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: FYI, the new ZSI module for Python 2+ has a wsdl2py tool that I successfully ran on the NED name resolver's WSDL file as a test to generate the client side code: a module called NED_services. BTW, the NED wrapper WS written in C# is here: http://voservices.net/ned These few lines below invoke the WS and print out RA, Dec for Messier 101 for a start: from NED_services import * ned = NEDLocator().getNEDSoap() #--- build soap message request = ObjByNameSoapInWrapper() request._objname = "Messier 101" #--- make a remote call response = ned.ObjByName(request) print response._ObjByNameResult._ra, response._ObjByNameResult._dec Okay, so it's not as pretty as C# but close to Java ;-) BTW, it took me 10 minutes to build this from scratch including the installation. Cheers, T. -- Tamas Budavari Dept. of Physics and Astronomy The Johns Hopkins University 3400 N. Charles Street Baltimore, MD 21218 Phone: +1 (410) 516-0643 Fax: +1 (410) 516-5096 http://www.sdss.jhu.edu/~budavari From owner-grid@eso.org Thu Apr 15 10:45:35 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3F8fln0021801 for ; Thu, 15 Apr 2004 10:41:47 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3F8flYv021800 for grid-outgoing; Thu, 15 Apr 2004 10:41:47 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i3F8fin0021790 for ; Thu, 15 Apr 2004 10:41:45 +0200 (MEST) Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3F8fhXe013413 for ; Thu, 15 Apr 2004 10:41:43 +0200 (CEST) Received: from mach.laeff.esa.es (hubble.laeff.esa.es [193.147.152.202]) by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3F8f9vT024878; Thu, 15 Apr 2004 10:41:09 +0200 (MET DST) Received: from laeff.esa.es (marconi [192.168.130.153]) by mach.laeff.esa.es (8.9.3/8.9.3) with ESMTP id KAA04276; Thu, 15 Apr 2004 10:38:34 +0200 (MET DST) Message-ID: <407E4A9D.2050905@laeff.esa.es> Date: Thu, 15 Apr 2004 10:41:01 +0200 From: Raul Gutierrez Sanchez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es, en MIME-Version: 1.0 To: Matthew Graham CC: grid@ivoa.net Subject: Re: JNI and web services References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Raul Gutierrez Sanchez X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Have you tried to set $LD_LIBRARY_PATH in the configuration file (just as you set $CATALINA_HOME for example)? Cheers, Raúl Matthew Graham wrote: >Hi, > >I have no problem with running a standalone application which uses JNI >where I can set LD_LIBRARY_PATH from the command line. The problem here is >what to do with a web service that uses JNI: the library path seems to >have to be set when Tomcat is started so I can include the path to >libfoo.so in $CATALINA_OPTS but: >- this is system dependent >- what happens if I have a whole suite of libfoo's - I would also have to >stop and restart Tomcat when I added a new one >- this is not easily deployable to other machines where I might not have >control over Tomcat. > >In the WS code I tried: > >String jlp = System.getProperty("java.library.path"); >String newpath = jlp + ":" + ; >System.setProperty("java.library.path", newpath); > >which does set java.library.path properly but the subsequent call: > >static (System.loadLibrary("foo")) > >does not pick the new path up and so I get the UnsatisfiedLinkError. > > Cheers, > > Matthew > > > > -- ----------------------------------------------------------------------------- Raúl Gutiérrez Sánchez ( raul@laeff.esa.es ) Laboratorio de Astrofísica Espacial y Física Fundamental (www.laeff.esa.es) Villafranca del Castillo Satellite Tracking Station Villafranca del Castillo - E-28691 Villanueva de la Cañada - Madrid - España Tel.: 34 91 8131260 Fax.: 34 91 8131160 ----------------------------------------------------------------------------- From owner-grid@eso.org Thu May 6 19:06:38 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i46H65De010763 for ; Thu, 6 May 2004 19:06:05 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i46H65BR010762 for grid-outgoing; Thu, 6 May 2004 19:06:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i46H61De010757 for ; Thu, 6 May 2004 19:06:01 +0200 (MEST) Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i46H5xXe016672 for ; Thu, 6 May 2004 19:06:00 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BLmJi-0004AS-9O for grid@ivoa.net; Thu, 06 May 2004 18:05:50 +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 i46H5omm023718 for ; Thu, 6 May 2004 18:05:50 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i46H5nsZ017916 for ; Thu, 6 May 2004 18:05:49 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i46H5n80017913 for ; Thu, 6 May 2004 18:05:49 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 6 May 2004 18:05:49 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Proposal for async. activities on web services Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Greetings all. Sometime soon we'll need a standard for doing long-running, asynchronously-invoked activitie on web services. I've posted, on the IVOA wiki-web, a strawman proposal for doing this with WS-ResourceFramework. http://www.ivoa.net/twiki/bin/view/IVOA/AsynchronousActivityProposal Please have a look and see what you think. 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-grid@eso.org Thu May 6 19:14:04 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i46HDjDe011316 for ; Thu, 6 May 2004 19:13:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i46HDjKT011315 for grid-outgoing; Thu, 6 May 2004 19:13:45 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i46HDgDe011309 for ; Thu, 6 May 2004 19:13:42 +0200 (MEST) Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i46HDeTY009712 for ; Thu, 6 May 2004 19:13:40 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BLmRF-0006Y9-GE for grid@ivoa.net; Thu, 06 May 2004 18:13:37 +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 i46HDbmm023989 for ; Thu, 6 May 2004 18:13:37 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i46HDbsZ017925 for ; Thu, 6 May 2004 18:13:37 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i46HDa6m017922 for ; Thu, 6 May 2004 18:13:36 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 6 May 2004 18:13:36 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Agenda for theMay 2004 interop meeting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, we need an agenda for the meeting at the end of this month. These are the topics that seem relevant to me: * Basic SOAP interoperation - Does WS-I sort it all out or do we need something more? * The standard-interfaces proposal - Standardize just the bits on which we have consensus? - Concrete definition with WSDL and XSD? * Proposals for handling asychronous operations * Proposals for authentication and authorization Your additions and objections are invited. 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-grid@eso.org Thu May 6 20:56:17 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i46ItnDe022269 for ; Thu, 6 May 2004 20:55:49 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i46ItnBx022268 for grid-outgoing; Thu, 6 May 2004 20:55:49 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i46ItkDe022262 for ; Thu, 6 May 2004 20:55:46 +0200 (MEST) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i46ItiTY012422 for ; Thu, 6 May 2004 20:55:44 +0200 (CEST) Message-Id: <200405061855.i46ItiTY012422@apollo.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by apollo.le.ac.uk with smtp (Exim 4.30) id 1BLo23-0007B0-JW for grid@ivoa.net; Thu, 06 May 2004 19:55:43 +0100 Received: (qmail 12401 invoked from network); 6 May 2004 18:56:04 -0000 Received: from morpheus.star.le.ac.uk (HELO gnowee) (143.210.36.121) by mail.star.le.ac.uk with SMTP; 6 May 2004 18:56:04 -0000 From: "Tony Linde" To: "'Guy Rixon'" , Subject: RE: Agenda for theMay 2004 interop meeting Date: Thu, 6 May 2004 19:55:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQzjkuaxE0XgLW4Q2e0vpuP9b/x9AADGliw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi all, All the rest of the groups really need a base standard for VObs services: what does a VObs service look like: properties and methods? There was a proposal some time ago from (? - Wil I think). Any chance of something like this being ratified? Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 06 May 2004 18:14 > To: grid@ivoa.net > Subject: Agenda for theMay 2004 interop meeting > > Hi, > > we need an agenda for the meeting at the end of this month. > These are the topics that seem relevant to me: > > * Basic SOAP interoperation > - Does WS-I sort it all out or do we need something more? > > * The standard-interfaces proposal > - Standardize just the bits on which we have consensus? > - Concrete definition with WSDL and XSD? > > * Proposals for handling asychronous operations > > * Proposals for authentication and authorization > > Your additions and objections are invited. > > 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-grid@eso.org Thu May 6 23:20:03 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i46LJODe007203 for ; Thu, 6 May 2004 23:19:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i46LJOgE007202 for grid-outgoing; Thu, 6 May 2004 23:19:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i46LJKDe007196 for ; Thu, 6 May 2004 23:19:20 +0200 (MEST) Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i46LJJXe025234 for ; Thu, 6 May 2004 23:19:19 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BLqGs-0006r6-4p; Thu, 06 May 2004 22:19:10 +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 i46LJ9mm002022; Thu, 6 May 2004 22:19:09 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i46LJ9sZ018160; Thu, 6 May 2004 22:19:09 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i46LJ9JB018157; Thu, 6 May 2004 22:19:09 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 6 May 2004 22:19:09 +0100 (BST) From: Guy Rixon To: Tony Linde cc: grid@ivoa.net Subject: RE: Agenda for theMay 2004 interop meeting In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Yes, I hope we can agree on this. That was the Standard Interfaces item. On Thu, 6 May 2004, Tony Linde wrote: > Hi all, > > All the rest of the groups really need a base standard for VObs services: > what does a VObs service look like: properties and methods? There was a > proposal some time ago from (? - Wil I think). Any chance of something like > this being ratified? > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > Behalf Of Guy Rixon > > Sent: 06 May 2004 18:14 > > To: grid@ivoa.net > > Subject: Agenda for theMay 2004 interop meeting > > > > Hi, > > > > we need an agenda for the meeting at the end of this month. > > These are the topics that seem relevant to me: > > > > * Basic SOAP interoperation > > - Does WS-I sort it all out or do we need something more? > > > > * The standard-interfaces proposal > > - Standardize just the bits on which we have consensus? > > - Concrete definition with WSDL and XSD? > > > > * Proposals for handling asychronous operations > > > > * Proposals for authentication and authorization > > > > Your additions and objections are invited. > > > > 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-grid@eso.org Thu May 6 23:22:24 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i46LM6De007389 for ; Thu, 6 May 2004 23:22:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i46LM5io007388 for grid-outgoing; Thu, 6 May 2004 23:22:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i46LM2De007384 for ; Thu, 6 May 2004 23:22:02 +0200 (MEST) 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 i46LM0TY017862 for ; Thu, 6 May 2004 23:22:01 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i46LLxQ09517 for grid@ivoa.net; Thu, 6 May 2004 17:21:59 -0400 Date: Thu, 6 May 2004 17:21:59 -0400 From: "Wil O'Mullane" Cc: grid@ivoa.net Subject: Re: Agenda for theMay 2004 interop meeting Message-ID: <20040506172159.F30071@skysrv.pha.jhu.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gtr@ast.cam.ac.uk on Thu, May 06, 2004 at 10:19:09PM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Indeed I agreed to write up something last time its on the twiki http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/StandardInterfaces-0.1.pdf On Thu, May 06, 2004 at 10:19:09PM +0100, Guy Rixon wrote: > Yes, I hope we can agree on this. That was the Standard Interfaces item. > > On Thu, 6 May 2004, Tony Linde wrote: > > > Hi all, > > > > All the rest of the groups really need a base standard for VObs services: > > what does a VObs service look like: properties and methods? There was a > > proposal some time ago from (? - Wil I think). Any chance of something like > > this being ratified? > > > > Cheers, > > Tony. > > > > > -----Original Message----- > > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > > Behalf Of Guy Rixon > > > Sent: 06 May 2004 18:14 > > > To: grid@ivoa.net > > > Subject: Agenda for theMay 2004 interop meeting > > > > > > Hi, > > > > > > we need an agenda for the meeting at the end of this month. > > > These are the topics that seem relevant to me: > > > > > > * Basic SOAP interoperation > > > - Does WS-I sort it all out or do we need something more? > > > > > > * The standard-interfaces proposal > > > - Standardize just the bits on which we have consensus? > > > - Concrete definition with WSDL and XSD? > > > > > > * Proposals for handling asychronous operations > > > > > > * Proposals for authentication and authorization > > > > > > Your additions and objections are invited. > > > > > > 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-grid@eso.org Fri May 7 14:20:40 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i47CJmQX001618 for ; Fri, 7 May 2004 14:19:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i47CJejX001590 for grid-outgoing; Fri, 7 May 2004 14:19:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i47CJFQX001496 for ; Fri, 7 May 2004 14:19:15 +0200 (MEST) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i47CJDXe028469 for ; Fri, 7 May 2004 14:19:13 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BM4JX-00044Y-Qc for grid@ivoa.net; Fri, 07 May 2004 13:18:51 +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 i47CIpmm001581 for ; Fri, 7 May 2004 13:18:51 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i47CIpsZ018806 for ; Fri, 7 May 2004 13:18:51 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i47CIpIR018803 for ; Fri, 7 May 2004 13:18:51 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 7 May 2004 13:18:51 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: WSDL/XSD for standard-interfaces proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I've posted, on the IVOA wiki-web, some WSDL and XSD implementing Wil's proposal for standard interfaces in VObs services. http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices (bottom of page). I deviated from Wil's text in a couple of places: - left out for now features that were challenged in discussion on this list (HarvestLog operation; Position and ContactDetails elements in the availability element); - renamed the getMetadata operation to getRegistration (since other ops get metadata and the VOResource is basically a submission to the VObs registries); - the case of some letters is changed. Useful? 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-grid@eso.org Mon May 10 18:34:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4AGXbND020225 for ; Mon, 10 May 2004 18:33:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4AGXaTr020224 for grid-outgoing; Mon, 10 May 2004 18:33:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4AGXWND020210 for ; Mon, 10 May 2004 18:33:32 +0200 (MEST) Received: from plum.csi.cam.ac.uk (plum.csi.cam.ac.uk [131.111.8.3]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4AGXUTY009185 for ; Mon, 10 May 2004 18:33:31 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by plum.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BNDi9-0006rF-QG for grid@ivoa.net; Mon, 10 May 2004 17:33:01 +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 i4AGX1mm012245 for ; Mon, 10 May 2004 17:33:01 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i4AGX1PV002732 for ; Mon, 10 May 2004 17:33:01 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i4AGX1v8002729 for ; Mon, 10 May 2004 17:33:01 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 10 May 2004 17:33:01 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Proposal to prune Standard Interfaces 0.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: When v0.1 of the Standard Interfaces specification was announced, some aspects were challenged: - HarvestLog operation; - Position and ContactDetails metadata in the availabililty interface. Since we don't have consensus on those, and since it's much easier to add features than to retire them, I suggest that we drop these features from the intial version of the standard and keep the bits where we do have consensus. If a need for the other parts arises afterwards, then we can release a revision. This was the approach taken in my WSDL encoding of Wil's words. 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-grid@eso.org Mon May 10 18:54:05 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4AGrmND023875 for ; Mon, 10 May 2004 18:53:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4AGrmge023873 for grid-outgoing; Mon, 10 May 2004 18:53:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4AGrhND023854 for ; Mon, 10 May 2004 18:53:43 +0200 (MEST) Received: from plum.csi.cam.ac.uk (plum.csi.cam.ac.uk [131.111.8.3]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4AGrfTY010508 for ; Mon, 10 May 2004 18:53:41 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by plum.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BNE1a-0004ok-2A for grid@ivoa.net; Mon, 10 May 2004 17:53:06 +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 i4AGr5mm013275 for ; Mon, 10 May 2004 17:53:05 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i4AGr5PV002772 for ; Mon, 10 May 2004 17:53:05 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i4AGr5K1002769 for ; Mon, 10 May 2004 17:53:05 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 10 May 2004 17:53:05 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, we need, as a group, to raise some proposals for how we do single-sign-on authentication in IVOA web-services. I like the idea of using the SOAP-header based protocols from OASIS like WS-Security. I think these are going to get the best support from software authors. I dislike the idea of producing private schemes that don't work with external toolkits or with the grid. However, WS-Security et al don't give a complete, prescriptive solution; they have too many alternatives and options. We would need a profile for our use of those standards. Enter the Basic Security Scenarios from the W/S Interoperability organization: http://www.ws-i.org/Profiles/BasicSecurity/2004-02/SecurityScenarios-0.15-WGD.pdf This, if I read it correctly, suggests using digital signatures (implies certficates and PKI) according to WS-Security and nonces plus timestamps (from a different bit of WS-Security) to avoid replay attacks. I'll try and digest these ideas into a possible Way That IVOA Does Things and post that later this week. In the meantime, could those who wish to debate this on-line and at the MA meeting please have a look at the WS-I document? Thanks, 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-grid@eso.org Mon May 10 22:46:03 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4AKjZND006039 for ; Mon, 10 May 2004 22:45:35 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4AKjZbj006037 for grid-outgoing; Mon, 10 May 2004 22:45:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4AKjTND006003 for ; Mon, 10 May 2004 22:45:30 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4AKjRTY027834 for ; Mon, 10 May 2004 22:45:28 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id NAA14782; Mon, 10 May 2004 13:45:25 -0700 (PDT) Date: Mon, 10 May 2004 13:45:23 -0700 (PDT) From: Matthew Graham To: Guy Rixon cc: grid@ivoa.net Subject: Re: Proposal to prune Standard Interfaces 0.1 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, There was a brief mention of logging at the recent NVO team meeting and I think the consensus is that it is an important thing. Given this, it should be something that is in the spec from the start and not shoehorned in later when all sorts of different implementations might be kicking around. I would therefore be reluctant to remove it from SI-0.1 and would rather see it flagged as optional at this stage. Cheers, Matthew From owner-grid@eso.org Mon May 17 19:10:38 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4HHAEgw010261 for ; Mon, 17 May 2004 19:10:14 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4HHAEiv010260 for grid-outgoing; Mon, 17 May 2004 19:10:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4HHA8gw010247 for ; Mon, 17 May 2004 19:10:08 +0200 (MEST) Received: from receive4.inner-21cn.com ([61.140.60.71]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i4HHA4Xe011065 for ; Mon, 17 May 2004 19:10:05 +0200 (CEST) Received: from rocky.hq.eso.org([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm940a3d52a; Thr, 13 May 2004 20:06:51 +0800 Received: from rocky.hq.eso.org([134.171.42.43]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Thr, 13 May 2004 20:06:50 +0800 Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4DBR3Xe010139; Thu, 13 May 2004 13:27:06 +0200 (CEST) Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4DBQZaE005155 for ; Thu, 13 May 2004 13:26:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4DBQZgu005151 for grid-outgoing; Thu, 13 May 2004 13:26:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4DBQTaE005134 for ; Thu, 13 May 2004 13:26:30 +0200 (MEST) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4DBQSXe010132 for ; Thu, 13 May 2004 13:26:28 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BOELz-0005Ix-Vb for grid@ivoa.net; Thu, 13 May 2004 12:26:19 +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 i4DBQJmm003487 for ; Thu, 13 May 2004 12:26:19 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i4DBQJM1001583 for ; Thu, 13 May 2004 12:26:19 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i4DBQJvX001580 for ; Thu, 13 May 2004 12:26:19 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 13 May 2004 12:26:19 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Agenda for 24/28 May 2004 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-grid@eso.org Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, sincce there was no response to my draft agenda, I've expanded it into a full agenda on the "official" page for the meeting. If you think things should go differently (content, order, timing) then please get back to me soon. The agenda page is http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2004GridAndWebServices on the IVOA wiki-web. It includes links to relevant technical materials. Please add your names to the list of participants before the meeting; it would be good to know who's coming. I'm looking for a volunteer to introduce the segment about the WS-I interoperability profile; we could use a 5-10 minute introduction by somebody who understands the issues. See you in MA! 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-grid@eso.org Tue May 25 17:15:06 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4PFEVkM012475 for ; Tue, 25 May 2004 17:14:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4PFEVQ2012474 for grid-outgoing; Tue, 25 May 2004 17:14:31 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4PFESkM012468 for ; Tue, 25 May 2004 17:14:28 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4PFEQTY028627 for ; Tue, 25 May 2004 17:14:26 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id IAA03974 for ; Tue, 25 May 2004 08:14:24 -0700 (PDT) Date: Tue, 25 May 2004 08:14:24 -0700 (PDT) From: Matthew Graham To: grid@ivoa.net Subject: Shibboleth Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Link for shibboleth: http://shibboleth.internet2.edu Cheers, Matthew From owner-grid@eso.org Tue May 25 23:15:57 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4PLFNkM025046 for ; Tue, 25 May 2004 23:15:23 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4PLFNEO025045 for grid-outgoing; Tue, 25 May 2004 23:15:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4PLFJkM025039 for ; Tue, 25 May 2004 23:15:19 +0200 (MEST) Received: from crux.tip.CSIRO.AU (crux.tip.CSIRO.AU [130.155.194.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i4PLFGTY011464 for ; Tue, 25 May 2004 23:15:17 +0200 (CEST) Received: (from daemon@localhost) by crux.tip.CSIRO.AU (8.9.3/8.9.3/TIPAT-1.2b) id HAA09105 for ; Wed, 26 May 2004 07:15:13 +1000 (EST) Received: from venice.tip.CSIRO.AU(130.155.194.99) via SMTP by crux.tip.CSIRO.AU, id smtpdAAAa09100; Wed May 26 07:15:07 2004 Received: from localhost (mur339@localhost) by venice.tip.CSIRO.AU (8.9.3/8.9.3/TIPAT-1.0a) with ESMTP id HAA09212 for ; Wed, 26 May 2004 07:15:06 +1000 (EST) X-Authentication-Warning: venice.tip.CSIRO.AU: mur339 owned process doing -bs Date: Wed, 26 May 2004 07:15:06 +1000 (EST) From: Tara Murphy X-X-Sender: To: Subject: Web service standards question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Tara Murphy X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I have built a demonstrator web service to provide unit conversion functionality (from the AIPS++ Quanta module). This is part of the ATNF VO effort, and as the aim is to be VO-compatible, I was wondering what standards I should be following at this stage. The two areas I'm aware of are the StandardInterfaces document and VOTable. The service can take and return VOTables, so I think it is ok in that respect. Am I right in thinking the Standard Interfaces are still very much under development (and maybe not worth worrying about at this stage?) It would be good if somebody could summarise what else (if anything) I need to be thinking about. thanks, Tara ----- Tara Murphy Postdoctoral Scientist Australia Telescope National Facility PO Box 76 Epping NSW 1710 Australia From owner-grid@eso.org Wed May 26 09:47:27 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4Q7iXn3008719 for ; Wed, 26 May 2004 09:44:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4Q7iX8G008718 for grid-outgoing; Wed, 26 May 2004 09:44:33 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4Q7iSn3008701 for ; Wed, 26 May 2004 09:44:28 +0200 (MEST) Received: from mpehp1.mpe-garching.mpg.de (mpehp1.mpe-garching.mpg.de [130.183.70.10]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4Q7iQTY026236 for ; Wed, 26 May 2004 09:44:26 +0200 (CEST) Received: from mpe.mpg.de (gavopc2.xray.mpe.mpg.de [130.183.72.144]) by mpehp1.mpe-garching.mpg.de (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id JAA17072; Wed, 26 May 2004 09:44:17 +0200 (METDST) Message-ID: <40B44BB1.9060400@mpe.mpg.de> Date: Wed, 26 May 2004 09:48:01 +0200 From: Hans-Martin Adorf Organization: MPE User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tara Murphy CC: grid@ivoa.net Subject: Re: Web service standards question References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060303080002090501090301" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Hans-Martin Adorf X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------060303080002090501090301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Tara, we at GAVO have developed a simple Web service for accessing the ROSAT database. It implements a simple cone search. We are thinking of other Web services, e.g. a classifier. The main question in my mind is the format in which to pass in the information specifying the request and the format for the response. I personally do not think that VOTables in and out is the right answer. VOTable is an XML format, and thus very appropriate for REST services, where the query is submitted via a simple HTTP GET or POST, and the result is commonly returned in XML. However, these days people, when talking about Web services, usually mean SOAP-based Web services, which I believe is what you are talking about, too. (Please correct me, if I'm wrong.) As the name states, SOAP is a protocol allowing the transfer of objects. I believe, we should not encode tabular data in a VOTable XML format, which is in some sense a serialization of some internal data object, and then let the server-side SOAP mechanism wrap it once more with XML. Not only is this totally inefficient (factors of 10 or more can easily be encountered), but we also do not take advantage of the abilities of the SOAP mechanism. What I would like to see is an internal tabular data object that is populated on the server side, then transparently serialized and transmitted via SOAP, and finally reconstructed on the client side. There are examples for how such a tabular data object might look like, such as our GAVO table object, or the table objects used internally by the SAVOT code, or by the TOPTable code. If data arrives in a data object, no explicit XML-parsing is required. I would be interested in seeing such a common tabular data object adopted by service providers, which would simplify coding a lot. I can imagine that with a common tabular data object at hand it would be much easier to construct Web applications that bind together several existing services. I am interested in hearing your an other people's thoughts. Hans-Martin Tara Murphy wrote: >Hi, >I have built a demonstrator web service to provide unit conversion >functionality (from the AIPS++ Quanta module). >This is part of the ATNF VO effort, and as the aim is to be VO-compatible, >I was wondering what standards I should be following at this stage. > >The two areas I'm aware of are the StandardInterfaces document and >VOTable. The service can take and return VOTables, so I think it is ok in >that respect. Am I right in thinking the Standard Interfaces are still very >much under development (and maybe not worth worrying about at this >stage?) > >It would be good if somebody could summarise what else (if anything) I >need to be thinking about. > >thanks, >Tara > >----- >Tara Murphy >Postdoctoral Scientist > >Australia Telescope National Facility >PO Box 76 >Epping NSW 1710 >Australia > > > > > > -- Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik . Giessenbachstr. 1 . D-85741 Garching b. München . Germany Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: adorf@mpe.mpg.de . WWW: http://www.g-vo.org --------------060303080002090501090301 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Tara,

we at GAVO have developed a simple Web service for accessing the ROSAT database. It implements a simple cone search. We are thinking of other Web services, e.g. a classifier. The main question in my mind is the format in which to pass in the information specifying the request and the format for the response. I personally do not think that VOTables in and out is the right answer.

VOTable is an XML format, and thus very appropriate for REST services, where the query is submitted via a simple HTTP GET or POST, and the result is commonly returned in XML. However, these days people, when talking about Web services, usually mean SOAP-based Web services, which I believe is what you are talking about, too. (Please correct me, if I'm wrong.) As the name states, SOAP is a protocol allowing the transfer of objects. I believe, we should not encode tabular data in a VOTable XML format, which is in some sense a serialization of some internal data object, and then let the server-side SOAP mechanism wrap it once more with XML. Not only is this totally inefficient (factors of 10 or more can easily be encountered), but we also do not take advantage of the abilities of the SOAP mechanism.

What I would like to see is an internal tabular data object that is populated on the server side, then transparently serialized and transmitted via SOAP, and finally reconstructed on the client side. There are examples for how such a tabular data object might look like, such as our GAVO table object, or the table objects used internally by the SAVOT code, or by the TOPTable code. If data arrives in a data object, no explicit XML-parsing is required. I would be interested in seeing such a common tabular data object adopted by service providers, which would simplify coding a lot. I can imagine that with a common tabular data object at hand it would be much easier to construct Web applications that bind together several existing services.

I am interested in hearing your an other people's thoughts.

Hans-Martin


Tara Murphy wrote:
Hi,
I have built a demonstrator web service to provide unit conversion
functionality (from the AIPS++ Quanta module).
This is part of the ATNF VO effort, and as the aim is to be VO-compatible,
I was wondering what standards I should be following at this stage.

The two areas I'm aware of are the StandardInterfaces document and
VOTable. The service can take and return VOTables, so I think it is ok in
that respect. Am I right in thinking the Standard Interfaces are still very
much under development (and maybe not worth worrying about at this
stage?)

It would be good if somebody could summarise what else (if anything) I
need to be thinking about.

thanks,
Tara

-----
Tara Murphy
Postdoctoral Scientist

Australia Telescope National Facility
PO Box 76
Epping NSW 1710
Australia

--
Dr. Hans-Martin Adorf Dr. Hans-Martin Adorf • Max-Planck-Institut f. extraterrestrische Physik • Giessenbachstr. 1 • D-85741 Garching b. München • Germany
Phone: +49-89-30000-3352 • Fax: +49-89-30000-3404 • E-Mail: adorf@mpe.mpg.de • WWW: http://www.g-vo.org
--------------060303080002090501090301-- From owner-grid@eso.org Wed May 26 14:44:37 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QCfPn3009997 for ; Wed, 26 May 2004 14:41:25 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QCfP5o009994 for grid-outgoing; Wed, 26 May 2004 14:41:25 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QCfIn3009973 for ; Wed, 26 May 2004 14:41:18 +0200 (MEST) Received: from brown.csi.cam.ac.uk (brown.csi.cam.ac.uk [131.111.8.14]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QCfGTY004788 for ; Wed, 26 May 2004 14:41:16 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by brown.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BSxib-0005OG-HA; Wed, 26 May 2004 13:41:13 +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 i4QCfCmm010233; Wed, 26 May 2004 13:41:13 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i4QCfCM1016544; Wed, 26 May 2004 13:41:12 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i4QCfCL3016541; Wed, 26 May 2004 13:41:12 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 26 May 2004 13:41:12 +0100 (BST) From: Guy Rixon To: Tara Murphy cc: grid@ivoa.net Subject: Re: Web service standards question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Tara, the "standard interfaces" (renamed at yesterday's meeting to "VObs Support Interfaces") are preliminary. The doc on the IVO wiki-web is actually an internal draft for the working group. Thus, expect most details to change before it becomes a recommendation. Expect something more stable in 3Q2004. Yesterday, the discussion at the interop meeting concluded that, of the support interfaces, - the one that emits VOResources will be optional - the heartbeat one will be mandatory - the log-harvesting one will be optional VOTable is an IVOA standard but it isn't _prescribed_ for all web services. If you want to build a service that emits a different kind of table, that's up to you. You need to judge for yourself which format interoperates better. The GWS session at the curernt interop meeting also supported in outline the proposals for asynchronous activities and single-sign-on authentication. It looks like these don't apply to your service, but you might like to consider them for other services. These are initial, internal drafts, so expect many details to change. You need to check out the registry-metadata spec's so that you can register your service in an IVO resource-registry. Units are considered in the data-model group. Some of their output may be relevant to your unit-conversion service. Finally, we're considering (discussion on Friday) prescribing the WS-I profile for basic SOAP. You might find it useful to download the conformance-testing tools from the WS-I organization's site and check out your messages. This isn't a definitive list of standards. Cheers, Guy On Wed, 26 May 2004, Tara Murphy wrote: > Hi, > I have built a demonstrator web service to provide unit conversion > functionality (from the AIPS++ Quanta module). > This is part of the ATNF VO effort, and as the aim is to be VO-compatible, > I was wondering what standards I should be following at this stage. > > The two areas I'm aware of are the StandardInterfaces document and > VOTable. The service can take and return VOTables, so I think it is ok in > that respect. Am I right in thinking the Standard Interfaces are still very > much under development (and maybe not worth worrying about at this > stage?) > > It would be good if somebody could summarise what else (if anything) I > need to be thinking about. > > thanks, > Tara > > ----- > Tara Murphy > Postdoctoral Scientist > > Australia Telescope National Facility > PO Box 76 > Epping NSW 1710 > Australia > > 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-grid@eso.org Wed May 26 14:49:15 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QCkin3010667 for ; Wed, 26 May 2004 14:46:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QCkhvh010665 for grid-outgoing; Wed, 26 May 2004 14:46:43 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QCkdn3010652 for ; Wed, 26 May 2004 14:46:39 +0200 (MEST) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QCkbTY004955 for ; Wed, 26 May 2004 14:46:38 +0200 (CEST) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.30) id 1BSxnp-01S4le-IK; Wed, 26 May 2004 13:46:37 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Wed, 26 May 2004 13:46:36 +0100 Date: Wed, 26 May 2004 13:46:36 +0100 (BST) From: Alasdair Allan To: Hans-Martin Adorf cc: Tara Murphy , Subject: Re: Web service standards question In-Reply-To: <40B44BB1.9060400@mpe.mpg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > VOTable is an XML format, and thus very appropriate for REST services, > where the query is submitted via a simple HTTP GET or POST, and the > result is commonly returned in XML. However, these days people, when > talking about Web services, usually mean SOAP-based Web services, which > I believe is what you are talking about, too. (Please correct me, if I'm > wrong.) As the name states, SOAP is a protocol allowing the transfer of > objects. I believe, we should not encode tabular data in a VOTable XML > format, which is in some sense a serialization of some internal data > object, and then let the server-side SOAP mechanism wrap it once more > with XML. Not only is this totally inefficient (factors of 10 or more > can easily be encountered), but we also do not take advantage of the > abilities of the SOAP mechanism. Erm, no. It depends very critically whether you're talking about SOAP RPC services, or wrapped, or document liternal services. XML documents are perfectly appropriate things to return from a SOAP service. > What I would like to see is an internal tabular data object that is > populated on the server side, then transparently serialized and > transmitted via SOAP, and finally reconstructed on the client side. That would be highly language specific, document literal, or wrapped document where a language neutral XML document is transmitted is a much better idea IMHO. Not everybody is using Java... Al. -- Dr. A. Allan, School of Physics, University of Exeter From owner-grid@eso.org Wed May 26 15:27:57 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QDPKn3016045 for ; Wed, 26 May 2004 15:25:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QDPK0Y016044 for grid-outgoing; Wed, 26 May 2004 15:25:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QDPDn3016027 for ; Wed, 26 May 2004 15:25:14 +0200 (MEST) Received: from mpehp1.mpe-garching.mpg.de (mpehp1.mpe-garching.mpg.de [130.183.70.10]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QDPCXe017653 for ; Wed, 26 May 2004 15:25:12 +0200 (CEST) Received: from mpe.mpg.de (gavopc2.xray.mpe.mpg.de [130.183.72.144]) by mpehp1.mpe-garching.mpg.de (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id PAA06856; Wed, 26 May 2004 15:25:02 +0200 (METDST) Message-ID: <40B49B8E.2090700@mpe.mpg.de> Date: Wed, 26 May 2004 15:28:46 +0200 From: Hans-Martin Adorf Organization: MPE User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alasdair Allan CC: Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050801060206010304030509" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Hans-Martin Adorf X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------050801060206010304030509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Alasdair, as the name indicates, the SOAP protocol allows the transfer of objects. This has nothing to do with Java. The SOAP protocol is programming language neutral, and I can transmit an object from C# to Java, or from Java to Perl. (We have done the latter.) So I believe your comment that transmitting an object would "be highly language specific" misses the point. Why would you prefer an XML string representation that you have to parse in order to construct an object which you could get immediately? And why would you want to use SOAP at all, if you don't want objects? Where is the benefit compared to a much simpler REST service? What is a "liternal service", please? Regards Hans-Martin Alasdair Allan wrote: >>VOTable is an XML format, and thus very appropriate for REST services, >>where the query is submitted via a simple HTTP GET or POST, and the >>result is commonly returned in XML. However, these days people, when >>talking about Web services, usually mean SOAP-based Web services, which >>I believe is what you are talking about, too. (Please correct me, if I'm >>wrong.) As the name states, SOAP is a protocol allowing the transfer of >>objects. I believe, we should not encode tabular data in a VOTable XML >>format, which is in some sense a serialization of some internal data >>object, and then let the server-side SOAP mechanism wrap it once more >>with XML. Not only is this totally inefficient (factors of 10 or more >>can easily be encountered), but we also do not take advantage of the >>abilities of the SOAP mechanism. >> >> > >Erm, no. It depends very critically whether you're talking about SOAP RPC >services, or wrapped, or document liternal services. XML documents are >perfectly appropriate things to return from a SOAP service. > > > >>What I would like to see is an internal tabular data object that is >>populated on the server side, then transparently serialized and >>transmitted via SOAP, and finally reconstructed on the client side. >> >> > >That would be highly language specific, document literal, or wrapped >document where a language neutral XML document is transmitted is a much >better idea IMHO. Not everybody is using Java... > >Al. > > -- Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik . Giessenbachstr. 1 . D-85741 Garching b. München . Germany Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: adorf@mpe.mpg.de . WWW: http://www.g-vo.org --------------050801060206010304030509 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Alasdair,

as the name indicates, the SOAP protocol allows the transfer of objects. This has nothing to do with Java. The SOAP protocol is programming language neutral, and I can transmit an object from C# to Java, or from Java to Perl. (We have done the latter.) So I believe your comment that transmitting an object would "be highly language specific" misses the point.

Why would you prefer an XML string representation that you have to parse in order to construct an object which you could get immediately? And why would you want to use SOAP at all, if you don't want objects? Where is the benefit compared to a much simpler REST service?

What is a "liternal service", please?

Regards
Hans-Martin

Alasdair Allan wrote:
VOTable is an XML format, and thus very appropriate for REST services, 
where the query is submitted via a simple HTTP GET or POST, and the 
result is commonly returned in XML. However, these days people, when 
talking about Web services, usually mean SOAP-based Web services, which 
I believe is what you are talking about, too. (Please correct me, if I'm 
wrong.) As the name states, SOAP is a protocol allowing the transfer of 
objects. I believe, we should not encode tabular data in a VOTable XML 
format, which is in some sense a serialization of some internal data 
object, and then let the server-side SOAP mechanism wrap it once more 
with XML. Not only is this totally inefficient (factors of 10 or more 
can easily be encountered), but we also do not take advantage of the 
abilities of the SOAP mechanism.
    

Erm, no. It depends very critically whether you're talking about SOAP RPC 
services, or wrapped, or document liternal services. XML documents are
perfectly appropriate things to return from a SOAP service.

  
What I would like to see is an internal tabular data object that is 
populated on the server side, then transparently serialized and 
transmitted via SOAP, and finally reconstructed on the client side. 
    

That would be highly language specific, document literal, or wrapped 
document where a language neutral XML document is transmitted is a much 
better idea IMHO. Not everybody is using Java...

Al.

--
Dr. Hans-Martin Adorf Dr. Hans-Martin Adorf • Max-Planck-Institut f. extraterrestrische Physik • Giessenbachstr. 1 • D-85741 Garching b. München • Germany
Phone: +49-89-30000-3352 • Fax: +49-89-30000-3404 • E-Mail: adorf@mpe.mpg.de • WWW: http://www.g-vo.org
--------------050801060206010304030509-- From owner-grid@eso.org Wed May 26 15:41:00 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QDcTn3018002 for ; Wed, 26 May 2004 15:38:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QDcTVt018001 for grid-outgoing; Wed, 26 May 2004 15:38:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QDcQn3017991 for ; Wed, 26 May 2004 15:38:26 +0200 (MEST) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QDcOXe018207 for ; Wed, 26 May 2004 15:38:25 +0200 (CEST) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.30) id 1BSybw-01QJ2R-Lx; Wed, 26 May 2004 14:38:24 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Wed, 26 May 2004 14:38:24 +0100 Date: Wed, 26 May 2004 14:38:24 +0100 (BST) From: Alasdair Allan To: Hans-Martin Adorf cc: Alasdair Allan , Tara Murphy , Subject: Re: Web service standards question In-Reply-To: <40B49B8E.2090700@mpe.mpg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > as the name indicates, the SOAP protocol allows the transfer of objects. Indeed! I think the important word in that sentense is "allows"... > This has nothing to do with Java. The SOAP protocol is programming > language neutral, and I can transmit an object from C# to Java, or from > Java to Perl. (We have done the latter.) So I believe your comment that > transmitting an object would "be highly language specific" misses the point. In theory, yes. In practice interoperability between the toolsets is somewhat less than perfect. For internal interfaces RPC is defiantely the way to go, for publically available services? I would probably go with wrapped document (mainly because I'm too lazy to code a proper document literal service). > Why would you prefer an XML string representation that you have to parse > in order to construct an object which you could get immediately? And why > would you want to use SOAP at all, if you don't want objects? Where is > the benefit compared to a much simpler REST service? Well, a whole bunch of stuff... Simplistically using SOAP gets you things like WS-RF, WS-I and WS-Security and interoperability with web/grid services. There are lots of other advantages to SOAP over REST that has nothing to do with RPC encoding. While SOAP was originally targeted as RPC, there are alot of document literal (and wrapped document) services now, the original SOAP encoding of the message isn't really heavily used. Parsing an XML document isn't exactly a major overhead... Guy? Didn't the GWS-WG recommend we stuck to wrapped document last year at Strasbourg? I can't remember exactly how the discussion went... > What is a "liternal service", please? Sorry, typing error, I meant "literal service"... Al. -- Dr. A. Allan, School of Physics, University of Exeter From owner-grid@eso.org Wed May 26 15:58:58 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QDwbn3020966 for ; Wed, 26 May 2004 15:58:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QDwb4s020965 for grid-outgoing; Wed, 26 May 2004 15:58:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QDwXn3020952 for ; Wed, 26 May 2004 15:58:34 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QDwVXe019231 for ; Wed, 26 May 2004 15:58:32 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i4QDvLh08470; Wed, 26 May 2004 09:57:21 -0400 Date: Wed, 26 May 2004 09:57:21 -0400 From: "Wil O'Mullane" To: Hans-Martin Adorf Cc: Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question Message-ID: <20040526095721.O2091@skysrv.pha.jhu.edu> References: <40B49B8E.2090700@mpe.mpg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40B49B8E.2090700@mpe.mpg.de>; from adorf@mpe.mpg.de on Wed, May 26, 2004 at 03:28:46PM +0200 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > as the name indicates, the SOAP protocol allows the transfer of objects. No longer true - SOAP is now SOAP it no longer means "Simple Object Access Protocol" and has much more to do with messaging . > This has nothing to do with Java. The SOAP protocol is programming > language neutral, and I can transmit an object from C# to Java, or from > Java to Perl. (We have done the latter.) So I believe your comment that > transmitting an object would "be highly language specific" misses the point. I think the point is that I can certainly send a Dataset from C# to Java via a WebService but what you get in Java is a complex DOM document which is practically useless - you do not get the Same DataSet I have in Java. The DataTable in java is similar. These objects cheat in their own language by having a special sterilizer/sterilizer which make them very useful in a given language but not actually portable. Unfortunately SOAP has not provided a common 'Table' data model which works in all languages in the same manner. A pity indeed. VOTable is not perfect but it does work . There are many other objects (and more to come from data models group) which will work very well with SOAP. But for tabular data for now we need to use VOTABLE.. wil From owner-grid@eso.org Wed May 26 16:38:48 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QEcQn3026597 for ; Wed, 26 May 2004 16:38:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QEcQm3026596 for grid-outgoing; Wed, 26 May 2004 16:38:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QEcMn3026586 for ; Wed, 26 May 2004 16:38:22 +0200 (MEST) Received: from mpehp1.mpe-garching.mpg.de (mpehp1.mpe-garching.mpg.de [130.183.70.10]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QEcKXe021075 for ; Wed, 26 May 2004 16:38:20 +0200 (CEST) Received: from mpe.mpg.de (gavopc2.xray.mpe.mpg.de [130.183.72.144]) by mpehp1.mpe-garching.mpg.de (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id QAA11068; Wed, 26 May 2004 16:38:05 +0200 (METDST) Message-ID: <40B4ACAC.4040800@mpe.mpg.de> Date: Wed, 26 May 2004 16:41:48 +0200 From: Hans-Martin Adorf Organization: MPE User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wil O'Mullane" CC: Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> In-Reply-To: <20040526095721.O2091@skysrv.pha.jhu.edu> Content-Type: multipart/alternative; boundary="------------030206040806050307030800" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Hans-Martin Adorf X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------030206040806050307030800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Wil, your comments are appreciated. If, for the moment, I follow your suggestion, how do I then specify that the result of calling a SOAP service is a VOTable? Am I supposed to specify that the result will be a String, and it will be up to the receiver to use the latest VOTable parser in order to decode the VOTable? OK, and then if SOAP by itself does not provide a table model, but we in the VO community have one (implicitely through VOTable) or more (excplicitly inside of Toptable, SAVOT or the GAVO table system), why don't we go ahead and augment the SOAP standard? Id' really like to download a WSDL and submit it to myWSDL2Java compiler, and start using the client. Hans-Martin Wil O'Mullane wrote: >>as the name indicates, the SOAP protocol allows the transfer of objects. >> >> >No longer true - SOAP is now SOAP it no longer means >"Simple Object Access Protocol" >and has much more to do with messaging . > > > >>This has nothing to do with Java. The SOAP protocol is programming >>language neutral, and I can transmit an object from C# to Java, or from >>Java to Perl. (We have done the latter.) So I believe your comment that >>transmitting an object would "be highly language specific" misses the point. >> >> >I think the point is that I can certainly send a Dataset from C# to Java >via a WebService but what you get in Java is a complex DOM document which >is practically useless - you do not get the Same DataSet I have in Java. >The DataTable in java is similar. These objects cheat in their own language >by having a special sterilizer/sterilizer which make them very useful in >a given language but not actually portable. > >Unfortunately SOAP has not provided a common 'Table' data model which >works in all languages in the same manner. A pity indeed. > >VOTable is not perfect but it does work . > >There are many other objects (and more to come from data models group) which will work very well with SOAP. But for tabular data for now we need to use VOTABLE.. > > >wil > > > > -- Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik . Giessenbachstr. 1 . D-85741 Garching b. München . Germany Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: adorf@mpe.mpg.de . WWW: http://www.g-vo.org --------------030206040806050307030800 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Wil,

your comments are appreciated. If, for the moment, I follow your suggestion, how do I then specify that the result of calling a SOAP service is a VOTable? Am I supposed to specify that the result will be a String, and it will be up to the receiver to use the latest VOTable parser in order to decode the VOTable?

OK, and then if SOAP by itself does not provide a table model, but we in the VO community have one (implicitely through VOTable) or more (excplicitly inside of Toptable, SAVOT or the GAVO table system), why don't we go ahead and augment the SOAP standard? Id' really like to download a WSDL and submit it to myWSDL2Java compiler, and start using the client.

Hans-Martin

Wil O'Mullane wrote:
as the name indicates, the SOAP protocol allows the transfer of objects. 
    
No longer true - SOAP is now SOAP it no longer means
"Simple Object Access Protocol"
and has much more to do with messaging .

  
This has nothing to do with Java. The SOAP protocol is programming 
language neutral, and I can transmit an object from C# to Java, or from 
Java to Perl. (We have done the latter.) So I believe your comment that 
transmitting an object would "be highly language specific" misses the point.
    
I think the point is that I can certainly send a Dataset from C# to Java
via a WebService but what you get in Java is a complex DOM document which
is practically useless - you do not get the Same DataSet I have in Java.
The DataTable in java is similar. These objects cheat in their own language
by having a special sterilizer/sterilizer which make them very useful in
a given language but not actually portable.

Unfortunately SOAP has not provided a common 'Table' data model which
works in all languages in the same manner. A pity indeed.

VOTable is not perfect but it does work .

There are many other objects (and more to come from data models group) which will work very well with SOAP. But for tabular data for now we need to use VOTABLE..


wil

--
Dr. Hans-Martin Adorf Dr. Hans-Martin Adorf • Max-Planck-Institut f. extraterrestrische Physik • Giessenbachstr. 1 • D-85741 Garching b. München • Germany
Phone: +49-89-30000-3352 • Fax: +49-89-30000-3404 • E-Mail: adorf@mpe.mpg.de • WWW: http://www.g-vo.org
--------------030206040806050307030800-- From owner-grid@eso.org Wed May 26 16:46:14 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QEjrn3027697 for ; Wed, 26 May 2004 16:45:53 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QEjrli027694 for grid-outgoing; Wed, 26 May 2004 16:45:53 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QEjln3027668 for ; Wed, 26 May 2004 16:45:47 +0200 (MEST) Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QEjjXe021370 for ; Wed, 26 May 2004 16:45:45 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BSzeM-0003NA-SE; Wed, 26 May 2004 15:44:58 +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 i4QEiwmm015032; Wed, 26 May 2004 15:44:58 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i4QEiwM1016721; Wed, 26 May 2004 15:44:58 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i4QEivfH016718; Wed, 26 May 2004 15:44:57 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 26 May 2004 15:44:57 +0100 (BST) From: Guy Rixon To: Alasdair Allan cc: Hans-Martin Adorf , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 26 May 2004, Alasdair Allan wrote: > > Guy? Didn't the GWS-WG recommend we stuck to wrapped document last year at > Strasbourg? I can't remember exactly how the discussion went... We agree that RPC/encoded had too many problems at that point in time and that we didn't want to use it. We provisionally agreed that we preferred document/literal. Wil suggested that we need document/literal on the wire but with an RPC API. 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-grid@eso.org Wed May 26 16:52:03 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QEphn3028484 for ; Wed, 26 May 2004 16:51:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QEphFN028482 for grid-outgoing; Wed, 26 May 2004 16:51:43 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QEpen3028471 for ; Wed, 26 May 2004 16:51:40 +0200 (MEST) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QEpcTY010478 for ; Wed, 26 May 2004 16:51:38 +0200 (CEST) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.30) id 1BSzko-01SCCX-Im; Wed, 26 May 2004 15:51:38 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Wed, 26 May 2004 15:51:38 +0100 Date: Wed, 26 May 2004 15:51:38 +0100 (BST) From: Alasdair Allan To: Guy Rixon cc: Alasdair Allan , Hans-Martin Adorf , Tara Murphy , Subject: Re: Web service standards question 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > > Guy? Didn't the GWS-WG recommend we stuck to wrapped document last > > year at Strasbourg? I can't remember exactly how the discussion > > went... > > We agree that RPC/encoded had too many problems at that point in time > and that we didn't want to use it. We provisionally agreed that we > preferred document/literal. Wil suggested that we need document/literal > on the wire but with an RPC API. Yes, it's all vaguely coming back. Will were you suggesting that we send our XML documents as an xsd:string? Or were you suggesting something more complicated? Al. -- Dr. A. Allan, School of Physics, University of Exeter From owner-grid@eso.org Wed May 26 16:58:18 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QEvwn3029626 for ; Wed, 26 May 2004 16:57:58 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QEvvJI029619 for grid-outgoing; Wed, 26 May 2004 16:57:57 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QEvqn3029579 for ; Wed, 26 May 2004 16:57:52 +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 i4QEvoTY010734 for ; Wed, 26 May 2004 16:57:50 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 6F69E44016; Wed, 26 May 2004 15:57:50 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 13659; Wed, 26 May 2004 15:57:49 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id EFD3744015; Wed, 26 May 2004 15:57:48 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 26 May 2004 15:57:48 +0100 (BST) Received: from roe.ac.uk (snizort.roe.ac.uk [195.194.120.31]) by katrine.roe.ac.uk (Postfix) with ESMTP id E5E5544015; Wed, 26 May 2004 15:57:47 +0100 (BST) Message-ID: <40B4B082.90608@roe.ac.uk> Date: Wed, 26 May 2004 10:58:10 -0400 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hans-Martin Adorf Cc: "Wil O'Mullane" , Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> In-Reply-To: <40B4ACAC.4040800@mpe.mpg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hans-Martin Adorf wrote: > Wil, > > your comments are appreciated. If, for the moment, I follow your > suggestion, how do I then specify that the result of calling a SOAP > service is a VOTable? Am I supposed to specify that the result will be a > String, and it will be up to the receiver to use the latest VOTable > parser in order to decode the VOTable? That's one way. You can also... > > OK, and then if SOAP by itself does not provide a table model, but we in > the VO community have one (implicitely through VOTable) or more > (excplicitly inside of Toptable, SAVOT or the GAVO table system), why > don't we go ahead and augment the SOAP standard? Id' really like to > download a WSDL and submit it to myWSDL2Java compiler, and start using > the client. ...you can also 'import' the VOTable schema into your WSDL definition (The SkyNode WSDL is, I think, an example), and then your WSDL2Java generator will build you a complete VOTable object model too. This is: Good) because your WSDL 'contract' defines that you expect the parameter to be a VOTable, not just a string. Iffy) because you get an object model built for you by the generator, but sometimes this needs some hand-tweaking Iffy) because you may not want the VOTable to be marshalled/unmarshalled into an object model. For example, if your service is going to transform it using XSLT, there is a big Waste of Power in converting it to an object model and back again, especially if it's a Really Big Huge table. -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Wed May 26 17:03:26 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QF35n3000840 for ; Wed, 26 May 2004 17:03:05 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QF35xY000837 for grid-outgoing; Wed, 26 May 2004 17:03:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QF2xn3000822 for ; Wed, 26 May 2004 17:02:59 +0200 (MEST) 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 i4QF2vTY010954 for ; Wed, 26 May 2004 17:02:57 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i4QF1ot13673; Wed, 26 May 2004 11:01:50 -0400 Date: Wed, 26 May 2004 11:01:50 -0400 From: "Wil O'Mullane" To: Hans-Martin Adorf Cc: Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question Message-ID: <20040526110150.P2091@skysrv.pha.jhu.edu> References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <40B4ACAC.4040800@mpe.mpg.de>; from adorf@mpe.mpg.de on Wed, May 26, 2004 at 04:41:48PM +0200 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The SkyNode spec and WSDL already wraps up VOTABLE for SOAP No you do not return a string you return a VOTable object - we have several SOAP servies which already do this - our CONE and SIAP services are webservices which return VOTable this is the skynode spec http://openskyquery.net/nodes//SDSS/nodeb.asmx?wsdl This uses VOData to allow the node to return one of many types from performQuery. openskyquery.net uses these interfaces ti ass vitbales around between nodes. Ramon has a java version of VOTbale which works well with this and he is able to return VOTable object from SOAP interfaces in Java. wil On Wed, May 26, 2004 at 04:41:48PM +0200, Hans-Martin Adorf wrote: > Wil, > > your comments are appreciated. If, for the moment, I follow your > suggestion, how do I then specify that the result of calling a SOAP > service is a VOTable? Am I supposed to specify that the result will be a > String, and it will be up to the receiver to use the latest VOTable > parser in order to decode the VOTable? > > OK, and then if SOAP by itself does not provide a table model, but we in > the VO community have one (implicitely through VOTable) or more > (excplicitly inside of Toptable, SAVOT or the GAVO table system), why > don't we go ahead and augment the SOAP standard? Id' really like to > download a WSDL and submit it to myWSDL2Java compiler, and start using > the client. > > Hans-Martin > > Wil O'Mullane wrote: > > >>as the name indicates, the SOAP protocol allows the transfer of objects. > >> > >> > >No longer true - SOAP is now SOAP it no longer means > >"Simple Object Access Protocol" > >and has much more to do with messaging . > > > > > > > >>This has nothing to do with Java. The SOAP protocol is programming > >>language neutral, and I can transmit an object from C# to Java, or from > >>Java to Perl. (We have done the latter.) So I believe your comment that > >>transmitting an object would "be highly language specific" misses the point. > >> > >> > >I think the point is that I can certainly send a Dataset from C# to Java > >via a WebService but what you get in Java is a complex DOM document which > >is practically useless - you do not get the Same DataSet I have in Java. > >The DataTable in java is similar. These objects cheat in their own language > >by having a special sterilizer/sterilizer which make them very useful in > >a given language but not actually portable. > > > >Unfortunately SOAP has not provided a common 'Table' data model which > >works in all languages in the same manner. A pity indeed. > > > >VOTable is not perfect but it does work . > > > >There are many other objects (and more to come from data models group) which will work very well with SOAP. But for tabular data for now we need to use VOTABLE.. > > > > > >wil > > > > > > > > > > -- > Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik > . Giessenbachstr. 1 . D-85741 Garching b. München . Germany > Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: > adorf@mpe.mpg.de . WWW: http://www.g-vo.org From owner-grid@eso.org Wed May 26 17:08:43 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QF8Nn3001613 for ; Wed, 26 May 2004 17:08:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QF8NK8001610 for grid-outgoing; Wed, 26 May 2004 17:08:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QF8Hn3001593 for ; Wed, 26 May 2004 17:08:17 +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 i4QF8FTY011142 for ; Wed, 26 May 2004 17:08:16 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id ACBFB44020; Wed, 26 May 2004 16:08:15 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 15120; Wed, 26 May 2004 16:08:14 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3DEC94401F; Wed, 26 May 2004 16:08:14 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 26 May 2004 16:08:14 +0100 (BST) Received: from roe.ac.uk (snizort.roe.ac.uk [195.194.120.31]) by katrine.roe.ac.uk (Postfix) with ESMTP id 41A5D4401F; Wed, 26 May 2004 16:08:13 +0100 (BST) Message-ID: <40B4B2F3.9090004@roe.ac.uk> Date: Wed, 26 May 2004 11:08:35 -0400 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wil O'Mullane" Cc: Hans-Martin Adorf , Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <20040526110150.P2091@skysrv.pha.jhu.edu> In-Reply-To: <20040526110150.P2091@skysrv.pha.jhu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil O'Mullane wrote: > The SkyNode spec and WSDL already wraps up VOTABLE for SOAP > No you do not return a string you return a VOTable object - we have > several SOAP servies which already do this - our CONE and SIAP > services are webservices which return VOTable Being pedantic just to avoid confusion; you return a VOTable *document* that conforms to the VOTable schema, rather than a generically serialised VOTable object. I think. :-) -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Wed May 26 17:12:59 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFCgn3002336 for ; Wed, 26 May 2004 17:12:42 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFCgpS002333 for grid-outgoing; Wed, 26 May 2004 17:12:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFCcn3002323 for ; Wed, 26 May 2004 17:12:38 +0200 (MEST) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QFCaXe022636 for ; Wed, 26 May 2004 17:12:36 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BT04X-0008C1-4b; Wed, 26 May 2004 16:12:01 +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 i4QFC0mm016194; Wed, 26 May 2004 16:12:00 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i4QFC0M1016746; Wed, 26 May 2004 16:12:00 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i4QFBxwT016743; Wed, 26 May 2004 16:11:59 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 26 May 2004 16:11:59 +0100 (BST) From: Guy Rixon To: Hans-Martin Adorf cc: "Wil O'Mullane" , Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question In-Reply-To: <40B4ACAC.4040800@mpe.mpg.de> Message-ID: References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 26 May 2004, Hans-Martin Adorf wrote: > > your comments are appreciated. If, for the moment, I follow your > suggestion, how do I then specify that the result of calling a SOAP > service is a VOTable? Am I supposed to specify that the result will be a > String, and it will be up to the receiver to use the latest VOTable > parser in order to decode the VOTable? VOTable has a schema. In fact, VOTable 1.0 has a schema and VOTable 1.1 has a separate schema with a different namespace. If a service emits a VOTable, then it should wsdl:import the relevant XSD document and use that as the emitted type. 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-grid@eso.org Wed May 26 17:14:53 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFEZn3002577 for ; Wed, 26 May 2004 17:14:35 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFEYWa002576 for grid-outgoing; Wed, 26 May 2004 17:14:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFESn3002558 for ; Wed, 26 May 2004 17:14:28 +0200 (MEST) Received: from mpehp1.mpe-garching.mpg.de (mpehp1.mpe-garching.mpg.de [130.183.70.10]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QFEQXe022728 for ; Wed, 26 May 2004 17:14:27 +0200 (CEST) Received: from mpe.mpg.de (gavopc2.xray.mpe.mpg.de [130.183.72.144]) by mpehp1.mpe-garching.mpg.de (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id RAA12876; Wed, 26 May 2004 17:14:13 +0200 (METDST) Message-ID: <40B4B52A.7030609@mpe.mpg.de> Date: Wed, 26 May 2004 17:18:02 +0200 From: Hans-Martin Adorf Organization: MPE User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Hill CC: "Wil O'Mullane" , Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <40B4B082.90608@roe.ac.uk> In-Reply-To: <40B4B082.90608@roe.ac.uk> Content-Type: multipart/alternative; boundary="------------090001080601010300090802" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Hans-Martin Adorf X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------090001080601010300090802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Martin, we are getting closer to what I want. So, you are saying that I should have a look at the SkyNode WSDL. Where exactly would I find the latter? Hans-Martin Martin Hill wrote: > Hans-Martin Adorf wrote: > >> Wil, >> >> your comments are appreciated. If, for the moment, I follow your >> suggestion, how do I then specify that the result of calling a SOAP >> service is a VOTable? Am I supposed to specify that the result will >> be a String, and it will be up to the receiver to use the latest >> VOTable parser in order to decode the VOTable? > > > That's one way. You can also... > >> >> OK, and then if SOAP by itself does not provide a table model, but we >> in the VO community have one (implicitely through VOTable) or more >> (excplicitly inside of Toptable, SAVOT or the GAVO table system), why >> don't we go ahead and augment the SOAP standard? Id' really like to >> download a WSDL and submit it to myWSDL2Java compiler, and start >> using the client. > > > ...you can also 'import' the VOTable schema into your WSDL definition > (The SkyNode WSDL is, I think, an example), and then your WSDL2Java > generator will build you a complete VOTable object model too. This is: > > Good) because your WSDL 'contract' defines that you expect the > parameter to be a VOTable, not just a string. > > Iffy) because you get an object model built for you by the generator, > but sometimes this needs some hand-tweaking > > Iffy) because you may not want the VOTable to be > marshalled/unmarshalled into an object model. For example, if your > service is going to transform it using XSLT, there is a big Waste of > Power in converting it to an object model and back again, especially > if it's a Really Big Huge table. > > -- Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik . Giessenbachstr. 1 . D-85741 Garching b. München . Germany Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: adorf@mpe.mpg.de . WWW: http://www.g-vo.org --------------090001080601010300090802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Martin,

we are getting closer to what I want. So, you are saying that I should have a look at the SkyNode WSDL. Where exactly would I find the latter?

Hans-Martin


Martin Hill wrote:
Hans-Martin Adorf wrote:

Wil,

your comments are appreciated. If, for the moment, I follow your suggestion, how do I then specify that the result of calling a SOAP service is a VOTable? Am I supposed to specify that the result will be a String, and it will be up to the receiver to use the latest VOTable parser in order to decode the VOTable?

That's one way.  You can also...


OK, and then if SOAP by itself does not provide a table model, but we in the VO community have one (implicitely through VOTable) or more (excplicitly inside of Toptable, SAVOT or the GAVO table system), why don't we go ahead and augment the SOAP standard? Id' really like to download a WSDL and submit it to myWSDL2Java compiler, and start using the client.

...you can also 'import' the VOTable schema into your WSDL definition (The SkyNode WSDL is, I think, an example), and then your WSDL2Java generator will build you a complete VOTable object model too. This is:

Good) because your WSDL 'contract' defines that you expect the parameter to be a VOTable, not just a string.

Iffy) because you get an object model built for you by the generator, but sometimes this needs some hand-tweaking

Iffy) because you may not want the VOTable to be marshalled/unmarshalled into an object model.  For example, if your service is going to transform it using XSLT, there is a big Waste of Power in converting it to an object model and back again, especially if it's a Really Big Huge table.



--
Dr. Hans-Martin Adorf Dr. Hans-Martin Adorf • Max-Planck-Institut f. extraterrestrische Physik • Giessenbachstr. 1 • D-85741 Garching b. München • Germany
Phone: +49-89-30000-3352 • Fax: +49-89-30000-3404 • E-Mail: adorf@mpe.mpg.de • WWW: http://www.g-vo.org
--------------090001080601010300090802-- From owner-grid@eso.org Wed May 26 17:14:58 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFEbn3002589 for ; Wed, 26 May 2004 17:14:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFEbGA002586 for grid-outgoing; Wed, 26 May 2004 17:14:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFEXn3002571 for ; Wed, 26 May 2004 17:14:33 +0200 (MEST) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QFEVXe022734 for ; Wed, 26 May 2004 17:14:32 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BT06a-0000AQ-QR; Wed, 26 May 2004 16:14:08 +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 i4QFE8mm016294; Wed, 26 May 2004 16:14:08 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i4QFE8M1016760; Wed, 26 May 2004 16:14:08 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i4QFE8k2016757; Wed, 26 May 2004 16:14:08 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 26 May 2004 16:14:08 +0100 (BST) From: Guy Rixon To: Alasdair Allan cc: Hans-Martin Adorf , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 26 May 2004, Alasdair Allan wrote: > > > > Guy? Didn't the GWS-WG recommend we stuck to wrapped document last > > > year at Strasbourg? I can't remember exactly how the discussion > > > went... > > > > We agree that RPC/encoded had too many problems at that point in time > > and that we didn't want to use it. We provisionally agreed that we > > preferred document/literal. Wil suggested that we need document/literal > > on the wire but with an RPC API. > > Yes, it's all vaguely coming back. Will were you suggesting that we send > our XML documents as an xsd:string? Or were you suggesting something more > complicated? C.f. the Globus-core technique of declaring a message part as an Any in WSDL and making an API for that operation/message-pair that takes a DOM instance. 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-grid@eso.org Wed May 26 17:22:06 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFLnn3003971 for ; Wed, 26 May 2004 17:21:49 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFLnRo003970 for grid-outgoing; Wed, 26 May 2004 17:21:49 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFLgn3003951 for ; Wed, 26 May 2004 17:21:43 +0200 (MEST) Received: from mpehp1.mpe-garching.mpg.de (mpehp1.mpe-garching.mpg.de [130.183.70.10]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QFLeXe023085 for ; Wed, 26 May 2004 17:21:40 +0200 (CEST) Received: from mpe.mpg.de (gavopc2.xray.mpe.mpg.de [130.183.72.144]) by mpehp1.mpe-garching.mpg.de (8.9.3 (PHNE_25183+JAGae58098)/8.9.3) with ESMTP id RAA13327; Wed, 26 May 2004 17:21:26 +0200 (METDST) Message-ID: <40B4B6DC.60305@mpe.mpg.de> Date: Wed, 26 May 2004 17:25:16 +0200 From: Hans-Martin Adorf Organization: MPE User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wil O'Mullane" CC: Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <20040526110150.P2091@skysrv.pha.jhu.edu> In-Reply-To: <20040526110150.P2091@skysrv.pha.jhu.edu> Content-Type: multipart/alternative; boundary="------------040603050701040602080503" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Hans-Martin Adorf X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------040603050701040602080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit OK. We are getting even closer (though by decyption capabilities do not allow be to decipher "ti ass vitbales"). A VOTable object is close enough to what I want. So I need to get in touch with you guys as soon as I get really going on our Web service project. Who is Ramon, by the way? And what is VOData which I do not remember having seen so far. Hans-Martin Wil O'Mullane wrote: >The SkyNode spec and WSDL already wraps up VOTABLE for SOAP >No you do not return a string you return a VOTable object - we have >several SOAP servies which already do this - our CONE and SIAP >services are webservices which return VOTable > >this is the skynode spec >http://openskyquery.net/nodes//SDSS/nodeb.asmx?wsdl > >This uses VOData to allow the node to return one of many types from >performQuery. > >openskyquery.net uses these interfaces ti ass vitbales around between nodes. > > >Ramon has a java version of VOTbale which works well with this and >he is able to return VOTable object from SOAP interfaces in Java. > >wil > >On Wed, May 26, 2004 at 04:41:48PM +0200, Hans-Martin Adorf wrote: > > >>Wil, >> >>your comments are appreciated. If, for the moment, I follow your >>suggestion, how do I then specify that the result of calling a SOAP >>service is a VOTable? Am I supposed to specify that the result will be a >>String, and it will be up to the receiver to use the latest VOTable >>parser in order to decode the VOTable? >> >>OK, and then if SOAP by itself does not provide a table model, but we in >>the VO community have one (implicitely through VOTable) or more >>(excplicitly inside of Toptable, SAVOT or the GAVO table system), why >>don't we go ahead and augment the SOAP standard? Id' really like to >>download a WSDL and submit it to myWSDL2Java compiler, and start using >>the client. >> >>Hans-Martin >> >>Wil O'Mullane wrote: >> >> >> >>>>as the name indicates, the SOAP protocol allows the transfer of objects. >>>> >>>> >>>> >>>> >>>No longer true - SOAP is now SOAP it no longer means >>>"Simple Object Access Protocol" >>>and has much more to do with messaging . >>> >>> >>> >>> >>> >>>>This has nothing to do with Java. The SOAP protocol is programming >>>>language neutral, and I can transmit an object from C# to Java, or from >>>>Java to Perl. (We have done the latter.) So I believe your comment that >>>>transmitting an object would "be highly language specific" misses the point. >>>> >>>> >>>> >>>> >>>I think the point is that I can certainly send a Dataset from C# to Java >>>via a WebService but what you get in Java is a complex DOM document which >>>is practically useless - you do not get the Same DataSet I have in Java. >>>The DataTable in java is similar. These objects cheat in their own language >>>by having a special sterilizer/sterilizer which make them very useful in >>>a given language but not actually portable. >>> >>>Unfortunately SOAP has not provided a common 'Table' data model which >>>works in all languages in the same manner. A pity indeed. >>> >>>VOTable is not perfect but it does work . >>> >>>There are many other objects (and more to come from data models group) which will work very well with SOAP. But for tabular data for now we need to use VOTABLE.. >>> >>> >>>wil >>> >>> >>> >>> >>> >>> >>-- >>Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik >>. Giessenbachstr. 1 . D-85741 Garching b. München . Germany >>Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: >>adorf@mpe.mpg.de . WWW: http://www.g-vo.org >> >> > > > > -- Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik . Giessenbachstr. 1 . D-85741 Garching b. München . Germany Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: adorf@mpe.mpg.de . WWW: http://www.g-vo.org --------------040603050701040602080503 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit OK. We are getting even closer (though by decyption capabilities do not allow be to decipher "ti ass vitbales"). A VOTable object is close enough to what I want. So I need to get in touch with you guys as soon as I get really going on our Web service project.

Who is Ramon, by the way? And what is VOData which I do not remember having seen so far.

Hans-Martin

Wil O'Mullane wrote:
The SkyNode spec and WSDL already wraps up VOTABLE for SOAP
No you do not return a string you return a VOTable object - we have
several SOAP servies which already do this - our CONE and SIAP
services are webservices which return VOTable 

this is the skynode spec
http://openskyquery.net/nodes//SDSS/nodeb.asmx?wsdl

This uses VOData to allow the node to return one of many types from
performQuery. 

openskyquery.net uses these interfaces ti ass vitbales around between nodes.


Ramon has a java version of VOTbale which works well with this and 
he is able to return VOTable object from SOAP interfaces in Java.

wil

On Wed, May 26, 2004 at 04:41:48PM +0200, Hans-Martin Adorf wrote:
  
Wil,

your comments are appreciated. If, for the moment, I follow your 
suggestion, how do I then specify that the result of calling a SOAP 
service is a VOTable? Am I supposed to specify that the result will be a 
String, and it will be up to the receiver to use the latest VOTable 
parser in order to decode the VOTable?

OK, and then if SOAP by itself does not provide a table model, but we in 
the VO community have one (implicitely through VOTable) or more 
(excplicitly inside of Toptable, SAVOT or the GAVO table system), why 
don't we go ahead and augment the SOAP standard? Id' really like to 
download a WSDL and submit it to myWSDL2Java compiler, and start using 
the client.

Hans-Martin

Wil O'Mullane wrote:

    
as the name indicates, the SOAP protocol allows the transfer of objects. 
   

        
No longer true - SOAP is now SOAP it no longer means
"Simple Object Access Protocol"
and has much more to do with messaging .

 

      
This has nothing to do with Java. The SOAP protocol is programming 
language neutral, and I can transmit an object from C# to Java, or from 
Java to Perl. (We have done the latter.) So I believe your comment that 
transmitting an object would "be highly language specific" misses the point.
   

        
I think the point is that I can certainly send a Dataset from C# to Java
via a WebService but what you get in Java is a complex DOM document which
is practically useless - you do not get the Same DataSet I have in Java.
The DataTable in java is similar. These objects cheat in their own language
by having a special sterilizer/sterilizer which make them very useful in
a given language but not actually portable.

Unfortunately SOAP has not provided a common 'Table' data model which
works in all languages in the same manner. A pity indeed.

VOTable is not perfect but it does work .

There are many other objects (and more to come from data models group) which will work very well with SOAP. But for tabular data for now we need to use VOTABLE..


wil


 

      
-- 
Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik 
. Giessenbachstr. 1 . D-85741 Garching b. München . Germany
Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: 
adorf@mpe.mpg.de . WWW: http://www.g-vo.org

--
Dr. Hans-Martin Adorf Dr. Hans-Martin Adorf • Max-Planck-Institut f. extraterrestrische Physik • Giessenbachstr. 1 • D-85741 Garching b. München • Germany
Phone: +49-89-30000-3352 • Fax: +49-89-30000-3404 • E-Mail: adorf@mpe.mpg.de • WWW: http://www.g-vo.org
--------------040603050701040602080503-- From owner-grid@eso.org Wed May 26 17:29:12 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFSpn3005082 for ; Wed, 26 May 2004 17:28:52 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFSpfw005081 for grid-outgoing; Wed, 26 May 2004 17:28:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFSmn3005075 for ; Wed, 26 May 2004 17:28:48 +0200 (MEST) 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 i4QFSkTY012069 for ; Wed, 26 May 2004 17:28:46 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i4QFRqM15815; Wed, 26 May 2004 11:27:52 -0400 Date: Wed, 26 May 2004 11:27:52 -0400 From: "Wil O'Mullane" To: Martin Hill Cc: Hans-Martin Adorf , Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question Message-ID: <20040526112752.T2091@skysrv.pha.jhu.edu> References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <20040526110150.P2091@skysrv.pha.jhu.edu> <40B4B2F3.9090004@roe.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40B4B2F3.9090004@roe.ac.uk>; from mch@roe.ac.uk on Wed, May 26, 2004 at 11:08:35AM -0400 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Yes absoloutely On Wed, May 26, 2004 at 11:08:35AM -0400, Martin Hill wrote: > > Wil O'Mullane wrote: > > > The SkyNode spec and WSDL already wraps up VOTABLE for SOAP > > No you do not return a string you return a VOTable object - we have > > several SOAP servies which already do this - our CONE and SIAP > > services are webservices which return VOTable > > Being pedantic just to avoid confusion; you return a VOTable *document* that > conforms to the VOTable schema, rather than a generically serialised VOTable object. > > I think. :-) > > -- > Martin Hill > www.mchill.net > +44 7901 55 24 66 > From owner-grid@eso.org Wed May 26 17:30:54 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFUZn3005343 for ; Wed, 26 May 2004 17:30:35 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFUZs1005342 for grid-outgoing; Wed, 26 May 2004 17:30:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFUVn3005328 for ; Wed, 26 May 2004 17:30:31 +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 i4QFUTTY012143 for ; Wed, 26 May 2004 17:30:30 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id CE79F44010; Wed, 26 May 2004 16:30:29 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 18284; Wed, 26 May 2004 16:30:28 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7805C44003; Wed, 26 May 2004 16:30:28 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 26 May 2004 16:30:28 +0100 (BST) Received: from roe.ac.uk (snizort.roe.ac.uk [195.194.120.31]) by katrine.roe.ac.uk (Postfix) with ESMTP id C81BD44005; Wed, 26 May 2004 16:30:27 +0100 (BST) Message-ID: <40B4B82A.3030804@roe.ac.uk> Date: Wed, 26 May 2004 11:30:50 -0400 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hans-Martin Adorf Cc: grid@ivoa.net Subject: Re: Web service standards - what comes first, the doc or the object? References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <20040526110150.P2091@skysrv.pha.jhu.edu> <40B4B2F3.9090004@roe.ac.uk> <40B4B73D.2080804@mpe.mpg.de> In-Reply-To: <40B4B73D.2080804@mpe.mpg.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Well... you always have a document on the wire. The thing is do you start from your objects and auto-generate the document (often invisibly), or do you start from the documents and have special marshallers/serialisers to convert from doc to your objects? The VO approach (and other broad-based services) is to start with the document. This is the most inconvenient from the coders point of view, as you can't just throw your objects to the web interface and have them get magically serialised and sent (or v.v.). However it's the only way that works between languages/webservers, as each has it's own way of doing the 'magically serialised' bit. The only way we can get our services is to agree the documents being transferred, and then work out our own ways to get those docs in and out of our favourite languages. However I think there are now VOTable marshallers for .NET (Wil?) and java (SAVOT) so you can use those to help. Cheers, Martin Hans-Martin Adorf wrote: > Well, having only an XML document would be a pity, and I would again be > somewhat farther away from the desired solution. > > -hma > > Martin Hill wrote: > >> >> Wil O'Mullane wrote: >> >>> The SkyNode spec and WSDL already wraps up VOTABLE for SOAP >>> No you do not return a string you return a VOTable object - we have >>> several SOAP servies which already do this - our CONE and SIAP >>> services are webservices which return VOTable >> >> >> Being pedantic just to avoid confusion; you return a VOTable >> *document* that conforms to the VOTable schema, rather than a >> generically serialised VOTable object. >> >> I think. :-) >> > > -- > Dr. Hans-Martin Adorf • Max-Planck-Institut f. extraterrestrische Physik > • Giessenbachstr. 1 • D-85741 Garching b. München • Germany > Phone: +49-89-30000-3352 • Fax: +49-89-30000-3404 • E-Mail: > adorf@mpe.mpg.de • WWW: http://www.g-vo.org -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Wed May 26 17:33:18 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFX0n3005666 for ; Wed, 26 May 2004 17:33:00 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFX0em005665 for grid-outgoing; Wed, 26 May 2004 17:33:00 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFWun3005659 for ; Wed, 26 May 2004 17:32:56 +0200 (MEST) Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QFWtXe023593 for ; Wed, 26 May 2004 17:32:55 +0200 (CEST) Received: (from nobody@localhost) by newb6.u-strasbg.fr (8.9.3/8.9.3) id RAA00636; Wed, 26 May 2004 17:25:54 +0200 (MET DST) X-Authentication-Warning: newb6.u-strasbg.fr: nobody set sender to schaaff@astro.u-strasbg.fr using -f To: Martin Hill Subject: Re: Web service standards question Message-ID: <1085585154.40b4b70292cfe@astro.u-strasbg.fr> Date: Wed, 26 May 2004 17:25:54 +0200 (MET DST) From: Andre Schaaff Cc: Hans-Martin Adorf , "Wil O'Mullane" , Alasdair Allan , Tara Murphy , grid@ivoa.net References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <40B4B082.90608@roe.ac.uk> In-Reply-To: <40B4B082.90608@roe.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andre Schaaff X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Quoting Martin Hill : > > > > OK, and then if SOAP by itself does not provide a table model, but we > in > > the VO community have one (implicitely through VOTable) or more > > (excplicitly inside of Toptable, SAVOT or the GAVO table system), why > > > don't we go ahead and augment the SOAP standard? Id' really like to > > download a WSDL and submit it to myWSDL2Java compiler, and start using > > > the client. > > ...you can also 'import' the VOTable schema into your WSDL definition > (The > SkyNode WSDL is, I think, an example), and then your WSDL2Java generator > will > build you a complete VOTable object model too. This is: > > Good) because your WSDL 'contract' defines that you expect the parameter > to be a > VOTable, not just a string. > > Iffy) because you get an object model built for you by the generator, > but > sometimes this needs some hand-tweaking > > Iffy) because you may not want the VOTable to be marshalled/unmarshalled > into an > object model. For example, if your service is going to transform it > using XSLT, > there is a big Waste of Power in converting it to an object model and > back > again, especially if it's a Really Big Huge table. In answer to the previous interesting mails of today morning, i think that we need to define in the coming months something like a VO Web Service Basic profile (will be discussed friday). We are all developping WS and we need to follow a few basic rules (what is mandatory, optional, optional but recommanded, ...) VObs Support Interfaces begins to indicate that heartbeat is mandatory, log-harvesting is optional, .... We must go further in this way (object or VOTable for tabular data, etc.) This implies also to provide tools to check the compliance to VO WS recommandations. André > > > -- > Martin Hill > www.mchill.net > +44 7901 55 24 66 > > From owner-grid@eso.org Wed May 26 17:34:49 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFYUn3005890 for ; Wed, 26 May 2004 17:34:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFYUuC005889 for grid-outgoing; Wed, 26 May 2004 17:34:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFYQn3005880 for ; Wed, 26 May 2004 17:34:26 +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 i4QFYOTY012283 for ; Wed, 26 May 2004 17:34:24 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id F337444010; Wed, 26 May 2004 16:34:23 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 18892; Wed, 26 May 2004 16:34:21 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9040D44006; Wed, 26 May 2004 16:34:21 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 26 May 2004 16:34:21 +0100 (BST) Received: from roe.ac.uk (snizort.roe.ac.uk [195.194.120.31]) by katrine.roe.ac.uk (Postfix) with ESMTP id 6A89644006; Wed, 26 May 2004 16:34:19 +0100 (BST) Message-ID: <40B4B912.9000706@roe.ac.uk> Date: Wed, 26 May 2004 11:34:42 -0400 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hans-Martin Adorf Cc: "Wil O'Mullane" , grid@ivoa.net Subject: Re: Web service standards question References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <40B4B082.90608@roe.ac.uk> <40B4B52A.7030609@mpe.mpg.de> In-Reply-To: <40B4B52A.7030609@mpe.mpg.de> X-Security: MIME headers sanitized on katrine See http://www.impsec.org/email-tools/sanitizer-intro.html for details. $Revision: 1.139 $Date: 2003-09-07 10:14:23-07 Content-Type: multipart/mixed; boundary="------------000705090907090408020300" X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.2 required=1000.0 tests=HTML_MESSAGE autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------000705090907090408020300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Attached is *a* version of the SkyNode WSDL as an example. Hans-Martin Adorf wrote: > Martin, > > we are getting closer to what I want. So, you are saying that I should > have a look at the SkyNode WSDL. Where exactly would I find the latter? > > Hans-Martin > > > Martin Hill wrote: > >> Hans-Martin Adorf wrote: >> >>> Wil, >>> >>> your comments are appreciated. If, for the moment, I follow your >>> suggestion, how do I then specify that the result of calling a SOAP >>> service is a VOTable? Am I supposed to specify that the result will >>> be a String, and it will be up to the receiver to use the latest >>> VOTable parser in order to decode the VOTable? >> >> >> That's one way. You can also... >> >>> >>> OK, and then if SOAP by itself does not provide a table model, but we >>> in the VO community have one (implicitely through VOTable) or more >>> (excplicitly inside of Toptable, SAVOT or the GAVO table system), why >>> don't we go ahead and augment the SOAP standard? Id' really like to >>> download a WSDL and submit it to myWSDL2Java compiler, and start >>> using the client. >> >> >> ...you can also 'import' the VOTable schema into your WSDL definition >> (The SkyNode WSDL is, I think, an example), and then your WSDL2Java >> generator will build you a complete VOTable object model too. This is: >> >> Good) because your WSDL 'contract' defines that you expect the >> parameter to be a VOTable, not just a string. >> >> Iffy) because you get an object model built for you by the generator, >> but sometimes this needs some hand-tweaking >> >> Iffy) because you may not want the VOTable to be >> marshalled/unmarshalled into an object model. For example, if your >> service is going to transform it using XSLT, there is a big Waste of >> Power in converting it to an object model and back again, especially >> if it's a Really Big Huge table. >> >> > > -- > Dr. Hans-Martin Adorf • Max-Planck-Institut f. extraterrestrische Physik > • Giessenbachstr. 1 • D-85741 Garching b. München • Germany > Phone: +49-89-30000-3352 • Fax: +49-89-30000-3404 • E-Mail: > adorf@mpe.mpg.de • WWW: http://www.g-vo.org -- Martin Hill www.mchill.net +44 7901 55 24 66 --------------000705090907090408020300 Content-Type: text/xml; name="SkyNode0.7.3.1.wsdl" Content-Disposition: inline; filename="SkyNode0.7.3.1.wsdl" Content-Transfer-Encoding: 7bit [BASIC] Returns MetaColumn[] info for a given table. [BASIC] Returns MetaFunction[] with info for each function supported by the service. These are functions other than the standard ones defined in ADQL. [BASIC] Returns a string[] of available query result formats. [BASIC] Returns VOResource metadata as defined in the RSM document [BASIC] Run a query, get back VOResult [BASIC] Returns uptime infomration about the is service [BASIC] Returns a list of all tables that may be used from vot node. [FULL] Run an ExecPlan, get back a VOResult [FULL] Returns a region which is the intersection of the survey and the given region. [FULL] Returns object count for a given criteria. [FULL] i.e. Crossmatch [BASIC] Returns MetaColumn[] info for a given table. [BASIC] Returns MetaFunction[] with info for each function supported by the service. These are functions other than the standard ones defined in ADQL. [BASIC] Returns a string[] of available query result formats. [BASIC] Returns VOResource metadata as defined in the RSM document [BASIC] Returns uptime infomration about the is service [BASIC] Returns a list of all tables that may be used from vot node. [BASIC] Returns MetaColumn[] info for a given table. [BASIC] Returns MetaFunction[] with info for each function supported by the service. These are functions other than the standard ones defined in ADQL. [BASIC] Returns a string[] of available query result formats. [BASIC] Returns VOResource metadata as defined in the RSM document [BASIC] Returns uptime infomration about the is service [BASIC] Returns a list of all tables that may be used from vot node. Interface for basic and full SkyNodes. --------------000705090907090408020300-- From owner-grid@eso.org Wed May 26 17:40:58 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFebn3006716 for ; Wed, 26 May 2004 17:40:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFebbD006715 for grid-outgoing; Wed, 26 May 2004 17:40:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFeQn3006637 for ; Wed, 26 May 2004 17:40:27 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QFeOXe023934 for ; Wed, 26 May 2004 17:40:25 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i4QFdHW16798; Wed, 26 May 2004 11:39:17 -0400 Date: Wed, 26 May 2004 11:39:17 -0400 From: "Wil O'Mullane" To: Hans-Martin Adorf Cc: Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question Message-ID: <20040526113917.W2091@skysrv.pha.jhu.edu> References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <20040526110150.P2091@skysrv.pha.jhu.edu> <40B4B6DC.60305@mpe.mpg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <40B4B6DC.60305@mpe.mpg.de>; from adorf@mpe.mpg.de on Wed, May 26, 2004 at 05:25:16PM +0200 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: sorry "to pass votables" got a little transcribed > OK. We are getting even closer (though by decyption capabilities do not > allow be to decipher "ti ass vitbales"). A VOTable object is close > Who is Ramon, by the way? And what is VOData which I do not remember > having seen so far. Ramon williamson is working on the Java implementaiton of the Skynode at Ncsa ramonw@ncsa.uiuc.edu wil > > Hans-Martin > > Wil O'Mullane wrote: > > >The SkyNode spec and WSDL already wraps up VOTABLE for SOAP > >No you do not return a string you return a VOTable object - we have > >several SOAP servies which already do this - our CONE and SIAP > >services are webservices which return VOTable > > > >this is the skynode spec > >http://openskyquery.net/nodes//SDSS/nodeb.asmx?wsdl > > > >This uses VOData to allow the node to return one of many types from > >performQuery. > > > >openskyquery.net uses these interfaces ti ass vitbales around between nodes. > > > > > >Ramon has a java version of VOTbale which works well with this and > >he is able to return VOTable object from SOAP interfaces in Java. > > > >wil > > > >On Wed, May 26, 2004 at 04:41:48PM +0200, Hans-Martin Adorf wrote: > > > > > >>Wil, > >> > >>your comments are appreciated. If, for the moment, I follow your > >>suggestion, how do I then specify that the result of calling a SOAP > >>service is a VOTable? Am I supposed to specify that the result will be a > >>String, and it will be up to the receiver to use the latest VOTable > >>parser in order to decode the VOTable? > >> > >>OK, and then if SOAP by itself does not provide a table model, but we in > >>the VO community have one (implicitely through VOTable) or more > >>(excplicitly inside of Toptable, SAVOT or the GAVO table system), why > >>don't we go ahead and augment the SOAP standard? Id' really like to > >>download a WSDL and submit it to myWSDL2Java compiler, and start using > >>the client. > >> > >>Hans-Martin > >> > >>Wil O'Mullane wrote: > >> > >> > >> > >>>>as the name indicates, the SOAP protocol allows the transfer of objects. > >>>> > >>>> > >>>> > >>>> > >>>No longer true - SOAP is now SOAP it no longer means > >>>"Simple Object Access Protocol" > >>>and has much more to do with messaging . > >>> > >>> > >>> > >>> > >>> > >>>>This has nothing to do with Java. The SOAP protocol is programming > >>>>language neutral, and I can transmit an object from C# to Java, or from > >>>>Java to Perl. (We have done the latter.) So I believe your comment that > >>>>transmitting an object would "be highly language specific" misses the point. > >>>> > >>>> > >>>> > >>>> > >>>I think the point is that I can certainly send a Dataset from C# to Java > >>>via a WebService but what you get in Java is a complex DOM document which > >>>is practically useless - you do not get the Same DataSet I have in Java. > >>>The DataTable in java is similar. These objects cheat in their own language > >>>by having a special sterilizer/sterilizer which make them very useful in > >>>a given language but not actually portable. > >>> > >>>Unfortunately SOAP has not provided a common 'Table' data model which > >>>works in all languages in the same manner. A pity indeed. > >>> > >>>VOTable is not perfect but it does work . > >>> > >>>There are many other objects (and more to come from data models group) which will work very well with SOAP. But for tabular data for now we need to use VOTABLE.. > >>> > >>> > >>>wil > >>> > >>> > >>> > >>> > >>> > >>> > >>-- > >>Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik > >>. Giessenbachstr. 1 . D-85741 Garching b. München . Germany > >>Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: > >>adorf@mpe.mpg.de . WWW: http://www.g-vo.org > >> > >> > > > > > > > > > > -- > Dr. Hans-Martin Adorf . Max-Planck-Institut f. extraterrestrische Physik > . Giessenbachstr. 1 . D-85741 Garching b. München . Germany > Phone: +49-89-30000-3352 . Fax: +49-89-30000-3404 . E-Mail: > adorf@mpe.mpg.de . WWW: http://www.g-vo.org From owner-grid@eso.org Wed May 26 17:42:37 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFgEn3006983 for ; Wed, 26 May 2004 17:42:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFgE5E006982 for grid-outgoing; Wed, 26 May 2004 17:42:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFgAn3006970 for ; Wed, 26 May 2004 17:42:10 +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 i4QFg8Xe024012 for ; Wed, 26 May 2004 17:42:09 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id A960F4400E; Wed, 26 May 2004 16:42:08 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 19834; Wed, 26 May 2004 16:42:07 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2E4A344005; Wed, 26 May 2004 16:42:07 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 26 May 2004 16:42:07 +0100 (BST) Received: from roe.ac.uk (snizort.roe.ac.uk [195.194.120.31]) by katrine.roe.ac.uk (Postfix) with ESMTP id 1E7B344005; Wed, 26 May 2004 16:42:06 +0100 (BST) Message-ID: <40B4BAE4.4090203@roe.ac.uk> Date: Wed, 26 May 2004 11:42:28 -0400 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Schaaff Cc: Hans-Martin Adorf , "Wil O'Mullane" , Alasdair Allan , Tara Murphy , grid@ivoa.net Subject: Re: Web service standards question - mandatory vs optional References: <40B49B8E.2090700@mpe.mpg.de> <20040526095721.O2091@skysrv.pha.jhu.edu> <40B4ACAC.4040800@mpe.mpg.de> <40B4B082.90608@roe.ac.uk> <1085585154.40b4b70292cfe@astro.u-strasbg.fr> In-Reply-To: <1085585154.40b4b70292cfe@astro.u-strasbg.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Andre Schaaff wrote: > In answer to the previous interesting mails of today morning, i think that we > need to define in the coming months something like a VO Web Service Basic > profile (will be discussed friday). We are all developping WS and we need to > follow a few basic rules (what is mandatory, optional, optional but recommanded, > ...) > VObs Support Interfaces begins to indicate that heartbeat is mandatory, > log-harvesting is optional, .... > We must go further in this way (object or VOTable for tabular data, etc.) > This implies also to provide tools to check the compliance to VO WS recommandations. A set of 'administration' like minimum features for VO services sounds good. Agreeing which ones are mandatory and which are not might take some time... For example, the optional 'describing itself in VO terms' (ie returning VOResource) is surely necessary to make the VO work, yet I don't see how heartbeat is mandatory to making the VO work! For mission critical systems yes, but the VO is hardly mission critical. Where are the heartbeats going to go? What is monitoring them? What alarms will be raised and where when a heartbeat fails? I suspect 'heartbeat' is not what is being meant, and this is really a 'getStatus' or 'getAvailability' in which case we ought to rename it. A 'heartbeat' is a pushed status message over a regular period (like monitoring a casualty's heartbeat), and there may be a case of having this in some services so we should not use the wrong term. Mr Pedantic -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Wed May 26 17:46:48 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFkNn3007488 for ; Wed, 26 May 2004 17:46:23 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFkN9W007487 for grid-outgoing; Wed, 26 May 2004 17:46:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFkHn3007477 for ; Wed, 26 May 2004 17:46:17 +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 i4QFkFTY012856 for ; Wed, 26 May 2004 17:46:15 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 623A04400E; Wed, 26 May 2004 16:46:15 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 20488; Wed, 26 May 2004 16:46:14 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 10B494400B; Wed, 26 May 2004 16:46:14 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 26 May 2004 16:46:13 +0100 (BST) Received: from roe.ac.uk (snizort.roe.ac.uk [195.194.120.31]) by katrine.roe.ac.uk (Postfix) with ESMTP id 6FE5B4400B; Wed, 26 May 2004 16:46:13 +0100 (BST) Message-ID: <40B4BBDB.8050708@roe.ac.uk> Date: Wed, 26 May 2004 11:46:35 -0400 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tara Murphy Cc: grid@ivoa.net Subject: Re: Web service standards question References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Tara Going back to your original question... We're putting together a 'common execution architecture' to try and tie together tools such as yours so they can be plugged into workflows and each other. But otherwise there's no settled interface yet (as I understand it). We would be very interested in seeing what would be involved in plugging a unit converter into our workflows; do you have a link we can use to access it & try it out? Or even just a description of what it does/how to use it? Tara Murphy wrote: > Hi, > I have built a demonstrator web service to provide unit conversion > functionality (from the AIPS++ Quanta module). > This is part of the ATNF VO effort, and as the aim is to be VO-compatible, > I was wondering what standards I should be following at this stage. > > The two areas I'm aware of are the StandardInterfaces document and > VOTable. The service can take and return VOTables, so I think it is ok in > that respect. Am I right in thinking the Standard Interfaces are still very > much under development (and maybe not worth worrying about at this > stage?) > > It would be good if somebody could summarise what else (if anything) I > need to be thinking about. > > thanks, > Tara > > ----- > Tara Murphy > Postdoctoral Scientist > > Australia Telescope National Facility > PO Box 76 > Epping NSW 1710 > Australia > > > -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Wed May 26 17:50:27 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QFnwn3007943 for ; Wed, 26 May 2004 17:49:59 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QFnw2a007942 for grid-outgoing; Wed, 26 May 2004 17:49:58 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QFntn3007934 for ; Wed, 26 May 2004 17:49:55 +0200 (MEST) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4QFnsTY012999 for ; Wed, 26 May 2004 17:49:54 +0200 (CEST) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.30) id 1BT0fB-01R6C2-Vm; Wed, 26 May 2004 16:49:53 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Wed, 26 May 2004 16:49:53 +0100 Date: Wed, 26 May 2004 16:49:53 +0100 (BST) From: Alasdair Allan To: Martin Hill cc: Andre Schaaff , Hans-Martin Adorf , "Wil O'Mullane" , Tara Murphy , Subject: Re: Web service standards question - mandatory vs optional In-Reply-To: <40B4BAE4.4090203@roe.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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin Hill wrote: > For example, the optional 'describing itself in VO terms' (ie returning > VOResource) is surely necessary to make the VO work, yet I don't see how > heartbeat is mandatory to making the VO work! For mission critical > systems yes, but the VO is hardly mission critical. Where are the > heartbeats going to go? What is monitoring them? What alarms will be > raised and where when a heartbeat fails? Depends what you're using the VO for, remember some of us are talking to real time systems. If I want to data mine your service for useful information I want to know how robust/reliable it is, I can get this from the HeartBeat and Will's proposed statistics gathering services (to find the history). I (my agent) won't do this everytime, but if a service becomes unreliable my software might want to try and find a more reliable alternative. From an agent(ish) point of view all of this should happen autonomously without user intervention. This is what I'm going to be using HeartBeat and associated information for... > I suspect 'heartbeat' is not what is being meant, and this is really a > 'getStatus' or 'getAvailability' in which case we ought to rename it. A > 'heartbeat' is a pushed status message over a regular period (like > monitoring a casualty's heartbeat), and there may be a case of having > this in some services so we should not use the wrong term. I reather like the name actually... :) Al. From owner-grid@eso.org Wed May 26 18:06:59 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4QG6Wn3010100 for ; Wed, 26 May 2004 18:06:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4QG6WA3010099 for grid-outgoing; Wed, 26 May 2004 18:06:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4QG6Sn3010095 for ; Wed, 26 May 2004 18:06:28 +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 i4QG6QXe024919 for ; Wed, 26 May 2004 18:06:26 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 4542944014; Wed, 26 May 2004 17:06:26 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 23260; Wed, 26 May 2004 17:06:25 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E2FDC44011; Wed, 26 May 2004 17:06:24 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 26 May 2004 17:06:24 +0100 (BST) Received: from roe.ac.uk (snizort.roe.ac.uk [195.194.120.31]) by katrine.roe.ac.uk (Postfix) with ESMTP id 466D244011; Wed, 26 May 2004 17:06:24 +0100 (BST) Message-ID: <40B4C096.2060401@roe.ac.uk> Date: Wed, 26 May 2004 12:06:46 -0400 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alasdair Allan Cc: grid@ivoa.net Subject: Re: Web service standards question - heartbeats References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Alasdair Allan wrote: > Martin Hill wrote: > >>For example, the optional 'describing itself in VO terms' (ie returning >>VOResource) is surely necessary to make the VO work, yet I don't see how >>heartbeat is mandatory to making the VO work! For mission critical >>systems yes, but the VO is hardly mission critical. Where are the >>heartbeats going to go? What is monitoring them? What alarms will be >>raised and where when a heartbeat fails? > > > Depends what you're using the VO for, remember some of us are talking to > real time systems. If I want to data mine your service for useful > information I want to know how robust/reliable it is, I can get this from > the HeartBeat and Will's proposed statistics gathering services (to find > the history). Hmmm a confusion of terms. Real time is not (necessarily) mission critical nor v.v. I think you want 'getAvailability' - you (or your agents) are asking the service how robust/reliable it is, and perhaps some prediction about when it is expected to be offline, etc. 'Heartbeats' are used to raise alarms when systems fail and are not even to do with real time stuff. I agree that *some* services might need alarms to be raised immediately they go down - which is why I'm not happy just letting this slide and using this 'heartbeat' term for one feature that is not only incorrect, but liable to get mixed up with a completley different feature. Some services may need to provide both heartbeats *and* availability information, and it would be inconvenient (to put it mildly) to combine the two. > > I reather like the name actually... :) Yes... it's just wrong that's all... >:D Perhaps a get 'Sickness' or 'Health' or 'Life' would be more appealing? :-) -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Fri May 28 03:06:56 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4S13YWF026105 for ; Fri, 28 May 2004 03:03:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4S13Y75026104 for grid-outgoing; Fri, 28 May 2004 03:03:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4S13UWF026097 for ; Fri, 28 May 2004 03:03:30 +0200 (MEST) Received: from crux.tip.CSIRO.AU (crux.tip.CSIRO.AU [130.155.194.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i4S13QTY012841 for ; Fri, 28 May 2004 03:03:28 +0200 (CEST) Received: (from daemon@localhost) by crux.tip.CSIRO.AU (8.9.3/8.9.3/TIPAT-1.2b) id LAA11690; Fri, 28 May 2004 11:03:23 +1000 (EST) Received: from venice.tip.CSIRO.AU(130.155.194.99) via SMTP by crux.tip.CSIRO.AU, id smtpdAAAa11688; Fri May 28 11:03:21 2004 Received: from localhost (mur339@localhost) by venice.tip.CSIRO.AU (8.9.3/8.9.3/TIPAT-1.0a) with ESMTP id LAA01649; Fri, 28 May 2004 11:03:20 +1000 (EST) X-Authentication-Warning: venice.tip.CSIRO.AU: mur339 owned process doing -bs Date: Fri, 28 May 2004 11:03:20 +1000 (EST) From: Tara Murphy X-X-Sender: To: Guy Rixon cc: Subject: Re: Web service standards question 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Tara Murphy X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, thank you Guy (and others) for all the useful information and pointers - you raised a few issues I hadn't thought of - it will be vey useful for me and the other ATNF VO people. Tara > the "standard interfaces" (renamed at yesterday's meeting to "VObs Support > Interfaces") are preliminary. The doc on the IVO wiki-web is actually an > internal draft for the working group. Thus, expect most details to change > before it becomes a recommendation. Expect something more stable in 3Q2004. > > Yesterday, the discussion at the interop meeting concluded that, of the > support interfaces, > > - the one that emits VOResources will be optional > > - the heartbeat one will be mandatory > > - the log-harvesting one will be optional > > VOTable is an IVOA standard but it isn't _prescribed_ for all web services. If > you want to build a service that emits a different kind of table, that's up to > you. You need to judge for yourself which format interoperates better. > > The GWS session at the curernt interop meeting also supported in outline the > proposals for asynchronous activities and single-sign-on authentication. It > looks like these don't apply to your service, but you might like to consider > them for other services. These are initial, internal drafts, so expect many > details to change. > > You need to check out the registry-metadata spec's so that you can register > your service in an IVO resource-registry. > > Units are considered in the data-model group. Some of their output may be > relevant to your unit-conversion service. > > Finally, we're considering (discussion on Friday) prescribing the WS-I profile > for basic SOAP. You might find it useful to download the conformance-testing > tools from the WS-I organization's site and check out your messages. > > This isn't a definitive list of standards. > > Cheers, > Guy > > On Wed, 26 May 2004, Tara Murphy wrote: > > > Hi, > > I have built a demonstrator web service to provide unit conversion > > functionality (from the AIPS++ Quanta module). > > This is part of the ATNF VO effort, and as the aim is to be VO-compatible, > > I was wondering what standards I should be following at this stage. > > > > The two areas I'm aware of are the StandardInterfaces document and > > VOTable. The service can take and return VOTables, so I think it is ok in > > that respect. Am I right in thinking the Standard Interfaces are still very > > much under development (and maybe not worth worrying about at this > > stage?) > > > > It would be good if somebody could summarise what else (if anything) I > > need to be thinking about. > > > > thanks, > > Tara > > > > ----- > > Tara Murphy > > Postdoctoral Scientist > > > > Australia Telescope National Facility > > PO Box 76 > > Epping NSW 1710 > > Australia > > > > > > 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-grid@eso.org Fri May 28 16:39:52 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4SEdNvZ004908 for ; Fri, 28 May 2004 16:39:23 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4SEdNnD004907 for grid-outgoing; Fri, 28 May 2004 16:39:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4SEdGvZ004853 for ; Fri, 28 May 2004 16:39:17 +0200 (MEST) Received: from us20.unix.fas.harvard.edu (us20.unix.fas.harvard.edu [140.247.35.200]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4SEdETY010976 for ; Fri, 28 May 2004 16:39:15 +0200 (CEST) Received: from [140.247.250.24] (roam250-24.fas.harvard.edu [140.247.250.24]) by us20.unix.fas.harvard.edu (8.12.11/8.12.11) with ESMTP id i4SEdBIV015784 for ; Fri, 28 May 2004 10:39:13 -0400 Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu (Unverified) Message-Id: Date: Fri, 28 May 2004 07:25:32 -0700 To: grid@ivoa.net From: Reagan Moore Subject: SOAP interoperability Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: An analysis of SOAP interoperability has been done by Arie Shoshani in Dec 2002. URLs pointing to SOAP interoperability are: http://www.cs.fsu.edu/~engelen/soap.html http://www.ppdg.net/mtgs/srm-4dec02-cern/SRM.issues.v2.1.draft2.pdf The latter URL contains a chart listing functionality across 16 different SOAP implementations on page 25. Reagan Moore From owner-grid@eso.org Fri May 28 16:39:58 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4SEdNvZ004903 for ; Fri, 28 May 2004 16:39:23 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4SEdNle004898 for grid-outgoing; Fri, 28 May 2004 16:39:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4SEdHvZ004855 for ; Fri, 28 May 2004 16:39:17 +0200 (MEST) Received: from us20.unix.fas.harvard.edu (us20.unix.fas.harvard.edu [140.247.35.200]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4SEdEXe022632 for ; Fri, 28 May 2004 16:39:15 +0200 (CEST) Received: from [140.247.250.24] (roam250-24.fas.harvard.edu [140.247.250.24]) by us20.unix.fas.harvard.edu (8.12.11/8.12.11) with ESMTP id i4SEdBIZ015784 for ; Fri, 28 May 2004 10:39:14 -0400 Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu (Unverified) Message-Id: Date: Fri, 28 May 2004 07:25:29 -0700 To: grid@ivoa.net From: Reagan Moore Subject: GSI authentication Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: At SDSC we have worked with both a C library and Java library version of the Grid Security Infrastructure. It turns out that they use slightly different security protocols (set of messages exchanged during authentication). Wayne Schroeder has written a aid library to simplify interactions with the GSI environment. A description of the library is given below. Reagan Moore /* Copyright 1999 The Regents of the University of California * All Rights Reserved * * Permission to use, copy, modify and distribute any part of this * Storage Resource Broker (SRB) software package, for educational, * research and non-profit purposes, without fee, and without a * written agreement is hereby granted, provided that the above * copyright notice, this paragraph and the following three paragraphs * appear in all copies. Those desiring to incorporate this SRB * software into commercial products or use for commercial purposes * should contact the Technology Transfer Office, University of * California, San Diego, 9500 Gilman Drive, La Jolla, CA 92093-0910, * Ph: (619) 534-5815, FAX: (619) 534-7345. * * IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY * PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL * DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SRB * SOFTWARE, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF * THE POSSIBILITY OF SUCH DAMAGE. * * THE SRB SOFTWARE PROVIDED HEREIN IS ON AN "AS IS" BASIS, AND THE * UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO PROVIDE MAINTENANCE, * SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. THE UNIVERSITY * OF CALIFORNIA MAKES NO REPRESENTATIONS AND EXTENDS NO WARRANTIES OF * ANY KIND, EITHER IMPLIED OR EXPRESS, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A * PARTICULAR PURPOSE, OR THAT THE USE OF THE SRB SOFTWARE WILL NOT * INFRINGE ANY PATENT, TRADEMARK OR OTHER RIGHTS. */ /* --------------- This AID library is now being integrated into the SRB source tree rather than maintained as a separate library so that we can better support GSI. In the process, aid.c has been modified a little to fit (GSI for #ifdefs is now GSI_AUTH) into the SRB build environment and the SRB build environment modified to make it easier to configure and build with GSI. Only GSI portion of this has been tested. And this was with the current GSI version, 2.2.4. The Kerberos and DCE code has been left here for now, but isn't being used. We could convert this to use the globus_gss_assist API but that is only simplify it slightly. Wayne Schroeder 3/2003 --------------- LIBAID Authentication and Integrity of Data interface This is an interface library to GSS-API security services, providing a simple API to calling applications. It is to be used in the SDSC Storage Resource Broker (client/server) application in conjunction with the Globus GSS-API implementation on top of SSLeay (see www.globus.org). X.509 Certificates are used for user and server authentication. Data can be exchanged in a secure manner with data signing (not encryption). It also is used for Kerberos authentication/data integrity also via the GSS-API. So that both Kerberos and SSL versions of GSS-API can be linked at the same time, the krb5_gss* routines (or generic_gss_release_buffer) are called for Kerberos instead of the gss_* routines. The gss_* routines are the SSL GSS-API routines, the krb5_gss* routines are the Kerberos GSS-API routines. Fortunately, in the Kerberos GSS-API package, each gss_* routine calls a krb5_gss* counterpart with the same arguments, making this kind of blending possible. Allocation of potentially large data buffers is left to the calling application rather than done in this library or below. This is sometimes important in High Performance Computing as the arrays can get large and applications need to control the memory allocation. This is accomplished primarily by using gss_get_mic/gss_verify_mic instead of gss_wrap and gss_unwrap. Some malloc's of small buffers are also avoided for efficiency and simplicity (matching the large buffers), although there is some risk that the scratch buffer may, someday, be too small. Two defines control whether this package makes GSI and/or Kerberos calls (GSI and Kerberos), so it can be built to link with either one or both. A third define (DCE) controls whether this builds for the DCE environment (and an earlier version of GSS-API). We have not attempted to link DCE simultaneous with either Kerberos or GSI. The aid_setup_creds has a flag for type (AID_Kerberos, AID_GSI, AID_DCE) and so does each aid_establish_context. For aid_read and aid_write this package knows which type of context has been established for the specified socket. The aid_read routine will malloc a (potentially large) buffer if the application's isn't big enough. This allows aid_read to behave like the read system call and cache data if the app's buffer is too small. Currently it prints a message for each malloc so that we can tune applications (the SRB) to avoid a lot of malloc's. I plan to make this (printing these messages) to be under the control of the application. Application callable routines: aid_setup_creds(service_name, client_flag, type_flag) reads user or server X.509 certificate/private key, or Kerberos credential locally; server/client flag indicates if this is a server or client; type_flag indicates Kerberos, GSI, or DCE. For Kerberos servers, environment variable KRB5_KTNAME is the Keytab file for the server (handled in Kerberos layers). For DCE servers, environment variable DCE_KTNAME is the Keytab file for the server (handled at this layer). aid_establish_context_serverside(s,clientName,max_len_clientName,type_flag) mutual secure authentication across a socket, called by a server; also prepares for possible use of aid_read/aid_write for data integrity checking aid_establish_context_clientside(s, service_name, deleg_flag, type_flag) mutual authentication across a socket, called by client; prepare for possible use of aid_read/aid_write for data integrity checking aid_read(fd,buffer,length) like read system call, across a socket, but confirms that data originated from the authenticated party on the other side and has not been altered in transit. aid_write(fd,buffer,length) like write system call, across a socket, adds MIC (Message Integrity Check, an MD5 hash of data and session key, etc) for use by aid_read. aid_close(fd) clear context information from memory. aid_debug(val) adjust verbose level for debug messages. All application callable routines are named aid_*. Internal routines are named aidi_*. In case of errors, messages are printed to stderr (both AID and GSS level) and negative values returned. Loosely based on GSS-API examples developed by Openvision distributed with Kerberos. With the addition of Kerberos, and then DCE, the number of ifdefs has gotten excessive in places and makes the code somewhat hard to read. But I believe it is best to leave it this way, since the calls and flow are quite similar across the three. From owner-grid@eso.org Fri May 28 16:39:52 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4SEdNvZ004900 for ; Fri, 28 May 2004 16:39:23 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4SEdMwx004896 for grid-outgoing; Fri, 28 May 2004 16:39:22 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4SEdGvZ004850 for ; Fri, 28 May 2004 16:39:17 +0200 (MEST) Received: from us20.unix.fas.harvard.edu (us20.unix.fas.harvard.edu [140.247.35.200]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4SEdETY010979 for ; Fri, 28 May 2004 16:39:15 +0200 (CEST) Received: from [140.247.250.24] (roam250-24.fas.harvard.edu [140.247.250.24]) by us20.unix.fas.harvard.edu (8.12.11/8.12.11) with ESMTP id i4SEdBIX015784 for ; Fri, 28 May 2004 10:39:13 -0400 Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu (Unverified) Message-Id: Date: Fri, 28 May 2004 07:19:04 -0700 To: grid@ivoa.net From: Reagan Moore Subject: Get and Put interfaces Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: An interface for "Get" and "Put" is being used in the Storage Resource Broker. The interfaces have been implemented using HTTP, WSDL, Java, Perl, Python, Unix shell commands, Windows load libraries, etc. The Storage Resource Broker is described at http://www.npaci.edu/DICE/SRB A list of Unix shell commands is given at http://www.npaci.edu/DICE/SRB/srbcommands.html Man pages are provided that describe the options that have been implemented at the request of user communities. The versions of Get include: Sget - get a file from the SRB collection and load into the user's disk SgetColl - get metadata about a collection SgetD - get metadata about a file SgetR - get information about storage resources SgetU - get information about users The underlying functionality includes: - logical name space that provides infrastructure independent persistent identifiers - support for replicas - support for containers (aggregation of small files) - support for third party transfer (move data from site A to site B without involving the client - support for recursion across sub-directories - support for bulk operations - support for parallel I/O streams - support for tickets (ticket-based authentication controlling number of accesses and time period for access) - support for GSI authentication, or SSL, or challenge response. The software development started in 1996 and continues today, funded at the level of 10 full time staff (both development and application of the software). Reagan Moore From owner-grid@eso.org Fri May 28 19:56:52 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4SHuFvZ009268 for ; Fri, 28 May 2004 19:56:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4SHuFTC009266 for grid-outgoing; Fri, 28 May 2004 19:56:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i4SHuBvZ009257 for ; Fri, 28 May 2004 19:56:12 +0200 (MEST) Received: from us17.unix.fas.harvard.edu (us17.unix.fas.harvard.edu [140.247.35.197]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4SHu9Xe006241 for ; Fri, 28 May 2004 19:56:10 +0200 (CEST) Received: from [140.247.250.24] (roam250-24.fas.harvard.edu [140.247.250.24]) by us17.unix.fas.harvard.edu (8.12.11/8.12.11) with ESMTP id i4SHu8l4015343; Fri, 28 May 2004 13:56:08 -0400 Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu (Unverified) Message-Id: Date: Fri, 28 May 2004 10:55:57 -0700 To: grid@ivoa.net From: Reagan Moore Subject: Prototyping data grids Cc: kremenek@sdsc.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: SDSC is quite interested in prototyping an environment that integrates myspace interfaces with the Storage Resource Broker. We also want to explore the capabilities provided by digital library interfaces such as DSpace and Fedora. A related effort will integrate DSpace with the SRB this summer. Reagan Moore From owner-grid@eso.org Wed Jun 2 23:11:29 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i52LAuJQ021411 for ; Wed, 2 Jun 2004 23:10:57 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i52LAuwW021410 for grid-outgoing; Wed, 2 Jun 2004 23:10:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i52LAqJQ021405 for ; Wed, 2 Jun 2004 23:10:52 +0200 (MEST) 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 i52LAoTY028327 for ; Wed, 2 Jun 2004 23:10:50 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i52LAlX32357; Wed, 2 Jun 2004 17:10:47 -0400 Date: Wed, 2 Jun 2004 17:10:47 -0400 From: "Wil O'Mullane" To: Reagan Moore Cc: grid@ivoa.net, kremenek@sdsc.edu Subject: Re: Prototyping data grids Message-ID: <20040602171047.O24270@skysrv.pha.jhu.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from moore@sdsc.edu on Fri, May 28, 2004 at 10:55:57AM -0700 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dave has agreed to perhasp jot down an initial spec. We should look at SRB and see if a paired down version might do the trick. If we can all agree on a spec the rest should be fairly easy.. well ok we will have to sort out our Certificate for security wil On Fri, May 28, 2004 at 10:55:57AM -0700, Reagan Moore wrote: > SDSC is quite interested in prototyping an environment that > integrates myspace interfaces with the Storage Resource Broker. We > also want to explore the capabilities provided by digital library > interfaces such as DSpace and Fedora. A related effort will > integrate DSpace with the SRB this summer. > > Reagan Moore From owner-grid@eso.org Thu Jun 3 23:58:19 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i53LvevZ025379 for ; Thu, 3 Jun 2004 23:57:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i53Lvetg025378 for grid-outgoing; Thu, 3 Jun 2004 23:57:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i53LvavZ025369 for ; Thu, 3 Jun 2004 23:57:36 +0200 (MEST) Received: from custmail0.corp.aus.wayport.net (custmail0.corp.aus.wayport.net [216.12.231.21]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i53LvYXe010432 for ; Thu, 3 Jun 2004 23:57:35 +0200 (CEST) Received: from [64.134.81.124] (dhcp64-134-81-124.hat.dca.wayport.net [64.134.81.124]) by custmail0.corp.aus.wayport.net (8.12.10/8.12.10) with ESMTP id i53LulSY002952; Thu, 3 Jun 2004 21:57:33 GMT Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu (Unverified) Message-Id: In-Reply-To: <20040602171047.O24270@skysrv.pha.jhu.edu> References: <20040602171047.O24270@skysrv.pha.jhu.edu> Date: Thu, 3 Jun 2004 14:53:38 -0700 To: "Wil O'Mullane" From: Reagan Moore Subject: Re: Prototyping data grids Cc: grid@ivoa.net, kremenek@sdsc.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil: Once you have your specification, we can identify which of the requirements are met by the SRB software. Reagan >Dave has agreed to perhasp jot down an initial spec. We should look >at SRB and see if a paired down version might do the trick. >If we can all agree on a spec the rest should be fairly easy.. >well ok we will have to sort out our Certificate for security >wil >On Fri, May 28, 2004 at 10:55:57AM -0700, Reagan Moore wrote: >> SDSC is quite interested in prototyping an environment that >> integrates myspace interfaces with the Storage Resource Broker. We >> also want to explore the capabilities provided by digital library >> interfaces such as DSpace and Fedora. A related effort will >> integrate DSpace with the SRB this summer. >> >> Reagan Moore From owner-grid@eso.org Fri Jun 4 19:33:55 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i54HXQvZ013264 for ; Fri, 4 Jun 2004 19:33:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i54HXQnc013263 for grid-outgoing; Fri, 4 Jun 2004 19:33:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i54HXLvZ013252 for ; Fri, 4 Jun 2004 19:33:22 +0200 (MEST) 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 i54HXKTY027763 for ; Fri, 4 Jun 2004 19:33:20 +0200 (CEST) Received: from localhost (nieto@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id i54HXH502443 for ; Fri, 4 Jun 2004 13:33:17 -0400 Date: Fri, 4 Jun 2004 13:33:17 -0400 (EDT) From: "Maria A. Nieto-Santisteban" To: grid@ivoa.net Subject: GGF12 has a date Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Maria A. Nieto-Santisteban" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, It seems GGF12 has finally a date. GGF12 - The Twelfth Global Grid Forum September 20-23, 2004 Brussels, Belgium http://www.ggf.org/Meetings/GGF11/GGF12.htm -- ------------------------------------------------ Maria A. Nieto-Santisteban (nieto@pha.jhu.edu) Johns Hopkins University 3400 N. Charles St. Physics & Astronomy Department Baltimore, MD 21218 (USA) Tel: 1 410 516-7679 Fax: 1 410 516-5096 From owner-grid@eso.org Mon Jun 7 01:40:41 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i56NdlZb021352 for ; Mon, 7 Jun 2004 01:39:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i56NdlIJ021351 for grid-outgoing; Mon, 7 Jun 2004 01:39:47 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i56NdhZb021344 for ; Mon, 7 Jun 2004 01:39: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 i56NdfXe004149 for ; Mon, 7 Jun 2004 01:39:42 +0200 (CEST) Received: from Ropy (dsl-64-30-223-60.lcinet.net [64.30.223.60]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i56Ndclj028971; Sun, 6 Jun 2004 16:39:39 -0700 Message-ID: <131f01c44c1f$884f6be0$2c0d680c@Ropy> From: "Roy Williams" To: Cc: "Roy Williams" , "Alex Szalay" , "Jim Gray" Subject: Three cheers for GET services Date: Sun, 6 Jun 2004 16:39:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Three cheers for GET services (This subject line is just to stir up the SOAP fundamentalists). As I start moving to the world of SOAP, I want to know how to do all the nifty things I used to be able to do with GET. (1) Please find below an email that I sent to myself yesterday. It is a pointer to a GET-based web service, and that is why it is easy to send the email. Just click on it in your email spool. It is a virtual finding chart, bringing not just a picture, but a browser of many layers and other drilldown features. It is nifty to send a complete "service request" to a colleague, and all they need to do is to click on it. But when we are running things on SOAP services, how can we do the same thing? Suppose I write to my colleague saying "use the http://blah service with x=2 and y=3", how long would it take them to figure out how to see the result? (2) On the same topic is the question of partial arguments to SOAP services. For example, under the GET system, I can *derive* a service from another. If service http://blah.edu/siap? returns images of all bandpasses, then the new service http://blah.edu/siap?BANDPASS=z can be derived (by simple concatenation!) that returns only z-images. Or, for example, a client could go to a login screen at http://blah.edu/login and get in return email a URL containing his session number, such as http://blah.edu/login?s=6ac3768ce8ff8. Clicking on this completes the login process. (3) There are a lot of nice read/parse qualities about GET requests. It would be nice to have both GET and SOAP at the same time. To somehow send keyword-value by the GET channel, but the complex objects and binary through the SOAP channel. People know and trust the GET method. Crossing the bridge to SOAP should be possible by gradual steps. Roy -------- California Institute of Technology roy@caltech.edu 626 395 3670 ----- Original Message ----- From: "Roy Williams" To: "Roy Williams" Sent: Saturday, June 05, 2004 9:10 PM Subject: PQ/sdss stack in VS Finding chart PQ-2004-05-18 > http://virtualsky.org/servlet/Page?F=1&RA=230&DE=-.20000&Exp=Go+Here&T=4&P=11&S=11&X=1687&Y=2043&W=4&Z=-1&M=1 From owner-grid@eso.org Mon Jun 7 10:07:31 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5786sZb024636 for ; Mon, 7 Jun 2004 10:06:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5786sTP024635 for grid-outgoing; Mon, 7 Jun 2004 10:06:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5786mZb024621 for ; Mon, 7 Jun 2004 10:06:48 +0200 (MEST) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5786kXe013293 for ; Mon, 7 Jun 2004 10:06:47 +0200 (CEST) Message-Id: <200406070806.i5786kXe013293@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by apollo.le.ac.uk with smtp (Exim 4.30) id 1BXF9a-0001Wm-3s for grid@ivoa.net; Mon, 07 Jun 2004 09:06:46 +0100 Received: (qmail 12505 invoked from network); 7 Jun 2004 08:06:57 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 7 Jun 2004 08:06:57 -0000 From: "Tony Linde" To: Subject: RE: Three cheers for GET services Date: Mon, 7 Jun 2004 09:06:35 +0100 Organization: University of Leicester MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <131f01c44c1f$884f6be0$2c0d680c@Ropy> Thread-Index: AcRMIw5Cs/+US7MGSrewscuho9V5UgAQRHjw X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I thought SOAP was more of a back end technology. If you want to send a link that executes a given process with specific parameters then you'll have to construct a web page/site which performs that task. Having SOAP services behind that page doesn't change the need for the user interface. So if you want a web page which allows the saving and transmission of executable links then you still need to construct that site: whether you build it all using JSP, Javascript, C# or have a thin script layer which calls SOAP services is up to you. But if there is a SOAP service which does what you want then anyone CAN now build an interface to it relatively easily instead of having to code all the access routines themselves. In the eventual VObs world, you could send the person the VOQL/ADQL query and they could plug it into their own favourite query front end. Or you could send them a link to the workflow you saved in VOSpace (having given them permission to 'see' it) and they could use that in their own workflow engine to recreate, not just the query, but the whole flow of your analysis, perhaps tweaking it, using different datasets or applications, then sending it back to you to check out. Or that's the way I saw it all anyway. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Roy Williams > Sent: 07 June 2004 00:40 > To: grid@ivoa.net > Cc: Roy Williams; Alex Szalay; Jim Gray > Subject: Three cheers for GET services > > Three cheers for GET services > > (This subject line is just to stir up the SOAP > fundamentalists). As I start moving to the world of SOAP, I > want to know how to do all the nifty things I used to be able > to do with GET. > > (1) Please find below an email that I sent to myself > yesterday. It is a pointer to a GET-based web service, and > that is why it is easy to send the email. Just click on it in > your email spool. It is a virtual finding chart, bringing not > just a picture, but a browser of many layers and other > drilldown features. It is nifty to send a complete "service > request" to a colleague, and all they need to do is to click on it. > > But when we are running things on SOAP services, how can we > do the same thing? > Suppose I write to my colleague saying "use the http://blah > service with x=2 and y=3", how long would it take them to > figure out how to see the result? > > (2) On the same topic is the question of partial arguments to > SOAP services. For example, under the GET system, I can > *derive* a service from another. If service > http://blah.edu/siap? returns images of all bandpasses, then > the new service http://blah.edu/siap?BANDPASS=z can be > derived (by simple concatenation!) that returns only z-images. > > Or, for example, a client could go to a login screen at > http://blah.edu/login and get in return email a URL > containing his session number, such as > http://blah.edu/login?s=6ac3768ce8ff8. Clicking on this > completes the login process. > > (3) There are a lot of nice read/parse qualities about GET > requests. It would be nice to have both GET and SOAP at the > same time. To somehow send keyword-value by the GET channel, > but the complex objects and binary through the SOAP channel. > > People know and trust the GET method. Crossing the bridge to > SOAP should be possible by gradual steps. > > Roy > > -------- > California Institute of Technology > roy@caltech.edu > 626 395 3670 > > ----- Original Message ----- > From: "Roy Williams" > To: "Roy Williams" > Sent: Saturday, June 05, 2004 9:10 PM > Subject: PQ/sdss stack in VS > > Finding chart PQ-2004-05-18 > > > > http://virtualsky.org/servlet/Page?F=1&RA=230&DE=-.20000&Exp=G > o+Here&T=4&P=11&S=11&X=1687&Y=2043&W=4&Z=-1&M=1 > From owner-grid@eso.org Mon Jun 7 11:14:25 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i579DgZb002981 for ; Mon, 7 Jun 2004 11:13:43 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i579Dg5c002979 for grid-outgoing; Mon, 7 Jun 2004 11:13:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i579DbZb002966 for ; Mon, 7 Jun 2004 11:13:37 +0200 (MEST) Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i579DZXe015658 for ; Mon, 7 Jun 2004 11:13:36 +0200 (CEST) Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i579DXpD089794 ; Mon, 7 Jun 2004 11:13:33 +0200 (CEST) Received: from simbad.u-strasbg.fr (pclx5.u-strasbg.fr [130.79.129.154]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id i579FbC28786; Mon, 7 Jun 2004 11:15:37 +0200 (MEST) Message-ID: <40C437E5.6030607@simbad.u-strasbg.fr> Date: Mon, 07 Jun 2004 11:39:49 +0200 From: Pierre Fernique User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Williams CC: grid@ivoa.net Subject: Re: Three cheers for GET services References: <131f01c44c1f$884f6be0$2c0d680c@Ropy> In-Reply-To: <131f01c44c1f$884f6be0$2c0d680c@Ropy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: scanned by sophos at u-strasbg.fr X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Pierre Fernique X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Roy Williams wrote: > Three cheers for GET services > > (This subject line is just to stir up the SOAP fundamentalists). As I start > moving to the world of SOAP, I want to know how to do all the nifty things I > used to be able to do with GET. (...) > > People know and trust the GET method. Crossing the bridge to SOAP should be > possible by gradual steps. > > Roy > > > http://virtualsky.org/servlet/Page?F=1&RA=230&DE=-.20000&Exp=Go+Here&T=4&P=11&S=11&X=1687&Y=2043&W=4&Z=-1&M=1 Hi all, I'm totally sharing these three cheers for GET services. The GET service is not the ultimate solution but it has some properties allowing people to connect services with very few interactions/standardizations/agreements/interfaces between the providers and the clients. In my mind, this propertie is one key of an "opened" interoperability and certainly one reason of the Web success. My own example built on the Roy's example. From a "get" service to another "get" service by a simple cut-and-paste. http://aladin.u-strasbg.fr/java/nph-aladin.pl?script=get+Local%28http%3A%2F%2Fwww.cacr.caltech.edu%2Fcgi-bin%2FVSmakefits%3FT%3D4%26S%3D10%26P%3D11%26X%3D3372%26Y%3D4087%26W%3D4%2CVirtual+Sky%2CSloan+Digital+Sky+Survey%29%3Bsync%3Bget+simbad%3Bget+VizieR%28USNO2%29%3B Regards, Pierre From owner-grid@eso.org Mon Jun 7 13:12:44 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57BCCZb026386 for ; Mon, 7 Jun 2004 13:12:13 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57BCCOm026383 for grid-outgoing; Mon, 7 Jun 2004 13:12:12 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i57BC4Zb026362 for ; Mon, 7 Jun 2004 13:12:05 +0200 (MEST) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57BC2Xe023487 for ; Mon, 7 Jun 2004 13:12:03 +0200 (CEST) Received: from dial.pipex.com (81-86-235-133.dsl.pipex.com [81.86.235.133]) by pengo.systems.pipex.net (Postfix) with ESMTP id 8C8904C003CF; Mon, 7 Jun 2004 12:11:58 +0100 (BST) Message-ID: <40C44D7D.9020209@dial.pipex.com> Date: Mon, 07 Jun 2004 12:11:57 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roy Williams Cc: grid@ivoa.net, Alex Szalay , Jim Gray Subject: Re: Three cheers for GET services - but we still have to SOAP the VO References: <131f01c44c1f$884f6be0$2c0d680c@Ropy> In-Reply-To: <131f01c44c1f$884f6be0$2c0d680c@Ropy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ooooh flame bait.... All these things are fine about what you call GET. [I'm not sure about this, but I think SOAP is run over http GET too - rather than POST - but I know what you mean]. In fact I will add that although SOAP can also take more complex types, this doesn't preclude GET, which could take URLs to them instead. Similarly you can use GET to run different methods. SOAP gives you a *defined interface* with WSDL; that is, you can define explicitly which parameters are expected and their types, and you can define the different methods that can be called on a service. This gives us enough information that we can use to connect services together; there is no 'service metadata', or descriptions about how to use a service, with a GET. For example, with GET there is no way of knowing that one service allows BANDPASS=z and another doesn't. This is why our VO services as a minimum need to support SOAP (or something similarly well-described); we won't have a VO that can interoperate if we don't! We could of course follow the Astronomer Way and invent our own description language based on GETs, so that we can't interoperate with any non-VO services... :-> (As an aside, it is awkward, but not impossible, to build GET URLs for anything other than a few simple parameters; for example building a reasonable-sized ADQL query would in practice require some kind of client software to help. Imagine trying to build a GET service for SExtractor, with its 100+ arguments, some of which are enumerations. How would the user know what the parameters are, and which parameters take which values?) more below: Roy Williams wrote: > Three cheers for GET services > > (This subject line is just to stir up the SOAP fundamentalists). As I start > moving to the world of SOAP, I want to know how to do all the nifty things I > used to be able to do with GET. > > (1) Please find below an email that I sent to myself yesterday. It is a pointer > to a GET-based web service, and that is why it is easy to send the email. Just > click on it in your email spool. It is a virtual finding chart, bringing not > just a picture, but a browser of many layers and other drilldown features. It is > nifty to send a complete "service request" to a colleague, and all they need to > do is to click on it. > > But when we are running things on SOAP services, how can we do the same thing? > Suppose I write to my colleague saying "use the http://blah service with x=2 and > y=3", how long would it take them to figure out how to see the result? Remember that when a VO service has been called, we would expect the results to be put somewhere in MySpace (or similar). So instead of passing around a URL to the call (and therefore requiring the query to be run again - what a waste of processing power!) you email to your colleages (or yourself) a URL to the results. > (3) There are a lot of nice read/parse qualities about GET requests. It would be > nice to have both GET and SOAP at the same time. To somehow send keyword-value > by the GET channel, but the complex objects and binary through the SOAP channel. As you say, supporting GET is handy for the end user for simple service calls, and so it makes sense that services that provide data to the end user provide a GET interface as well. But do we need to get involved in this? Is this up to the individual service to decide how much they want to implement, or should we specify a minimum for each service type? We certainly don't want to start *mixing* GET and SOAP, if that's what you mean. Let's allow services to provide two separate points of access if they want, but SOAP is what we need for the VO to interoperate. > > People know and trust the GET method. Crossing the bridge to SOAP should be > possible by gradual steps. Unfortunately there's no 'gradual' step to deciding whether you support a (for example) SOAP SkyNode interface or not. What we can do is make sure there are simple interfaces that don't require too much backend code, and so as the SkyNode folks have done is to define a simple SkyNode interface and ways of extending it. But you can't 'gradually' add SOAP methods to build a standard interface and still expect it to interoperate, until the full (minimum) interface has been implemented. I do feel we should also provide standard 'client API' software for the common astronomer languages - (FORTRAN?, Python?, Perl?, .NET?) - so that astronomers can reach remote services easily with all the power of SOAP but without caring about it. Me? Fundamentalist? Is that the same as being Loud? :-) Cheers, Martin -- Martin Hill www.mchill.net 07901 55 24 66 From owner-grid@eso.org Mon Jun 7 13:31:26 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57BV7Zb000688 for ; Mon, 7 Jun 2004 13:31:07 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57BV7R0000687 for grid-outgoing; Mon, 7 Jun 2004 13:31:07 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i57BV2Zb000671 for ; Mon, 7 Jun 2004 13:31:02 +0200 (MEST) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57BV0Xe024993 for ; Mon, 7 Jun 2004 13:31:00 +0200 (CEST) Received: from dial.pipex.com (81-86-235-133.dsl.pipex.com [81.86.235.133]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 72A591C001D2; Mon, 7 Jun 2004 12:30:59 +0100 (BST) Message-ID: <40C451F2.4080601@dial.pipex.com> Date: Mon, 07 Jun 2004 12:30:58 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pierre Fernique Cc: grid@ivoa.net Subject: Re: Three cheers for GET services - wot, no definition? References: <131f01c44c1f$884f6be0$2c0d680c@Ropy> <40C437E5.6030607@simbad.u-strasbg.fr> In-Reply-To: <40C437E5.6030607@simbad.u-strasbg.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Pierre Fernique wrote: > The GET service is not the ultimate solution but it has some properties > allowing people to connect services with very few > interactions/standardizations/agreements/interfaces between the > providers and the clients. In my mind, this propertie is one key of an > "opened" interoperability and certainly one reason of the Web success. Are you saying that if you provide a service 'doIt' that takes 'some parameters', then this is interoperable with any other 'doIt' service that takes 'some parameters'? Even if one is an image cutout service and the other is SExtractor? -- Martin Hill www.mchill.net 07901 55 24 66 From owner-grid@eso.org Mon Jun 7 15:24:24 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57DNxDZ021863 for ; Mon, 7 Jun 2004 15:23:59 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57DNwUB021859 for grid-outgoing; Mon, 7 Jun 2004 15:23:59 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i57DNqDZ021840 for ; Mon, 7 Jun 2004 15:23:53 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57DNoXe003986 for ; Mon, 7 Jun 2004 15:23:51 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i57DNmF11293; Mon, 7 Jun 2004 09:23:48 -0400 Date: Mon, 7 Jun 2004 09:23:48 -0400 From: "Wil O'Mullane" To: Roy Williams Cc: grid@ivoa.net, Alex Szalay , Jim Gray Subject: Re: Three cheers for GET services Message-ID: <20040607092348.T31554@skysrv.pha.jhu.edu> References: <131f01c44c1f$884f6be0$2c0d680c@Ropy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <131f01c44c1f$884f6be0$2c0d680c@Ropy>; from roy@cacr.caltech.edu on Sun, Jun 06, 2004 at 04:39:37PM -0700 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I shall be brief > (1) Please find below an email that I sent to myself yesterday. It is a pointer Pointed out many times and by Tony again. Making what you call a GET over SOAP is very simple if the service is simple enough. In .NET if it is simple enough it does this for you automatically hence this is a SOAP service to the registry http://nvo.stsci.edu/voregistry/registry.asmx/QueryResource?predicate=servicetype%20like%20'%siap%' I did nothing to produce this interface. More complex calls require POST but that is all. > (2) On the same topic is the question of partial arguments to SOAP services. For > example, under the GET system, I can *derive* a service from another. If service > http://blah.edu/siap? returns images of all bandpasses, then the new service > http://blah.edu/siap?BANDPASS=z can be derived (by simple concatenation!) that > returns only z-images. unsure what the point is here .. you may also define SOAP interfaces to take 'extra' parameters but then it s not really the same interface any more better to call it something else. > > Or, for example, a client could go to a login screen at http://blah.edu/login > and get in return email a URL containing his session number, such as > http://blah.edu/login?s=6ac3768ce8ff8. Clicking on this completes the login > process. Have you looked at CasJobs ? http://casjobs.sdss.org/CasJobs/ all web services - seems to do exactly this ... > > (3) There are a lot of nice read/parse qualities about GET requests. It would be > nice to have both GET and SOAP at the same time. To somehow send keyword-value > by the GET channel, but the complex objects and binary through the SOAP channel. I do not know any nice READ/Parse qualities of what you call GET. Unless you mean every time i call you kind of GET I have to READ the response and PARSE out the information I wanted. On the other hand when I call a SOAP service I get back a meaningful object in my language - the reading and parsing are done by the library. > People know and trust the GET method. Crossing the bridge to SOAP should be > possible by gradual steps. see point 1. From owner-grid@eso.org Mon Jun 7 15:52:04 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57DpZDZ027074 for ; Mon, 7 Jun 2004 15:51:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57DpZse027071 for grid-outgoing; Mon, 7 Jun 2004 15:51:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i57DpPDZ027046; Mon, 7 Jun 2004 15:51:25 +0200 (MEST) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i57DpPp23438; Mon, 7 Jun 2004 15:51:25 +0200 (MEST) Message-ID: <40C472F9.7070807@eso.org> Date: Mon, 07 Jun 2004 15:51:53 +0200 From: Markus Dolensky Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en, de-AT MIME-Version: 1.0 To: "Wil O'Mullane" CC: grid@ivoa.net Subject: Re: Three cheers for GET services References: <131f01c44c1f$884f6be0$2c0d680c@Ropy> <20040607092348.T31554@skysrv.pha.jhu.edu> In-Reply-To: <20040607092348.T31554@skysrv.pha.jhu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Markus Dolensky X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Wil, Your response triggered a question concerning SSA: > Pointed out many times and by Tony again. Making what you call a GET over SOAP > is very simple if the service is simple enough. In .NET if it is simple > enough it does this for you automatically hence this is a SOAP service to the > registry > http://nvo.stsci.edu/voregistry/registry.asmx/QueryResource?predicate=servicetype%20like%20'%siap%' One case where we need this is when embedding an access reference in the query output of an SSA service. In the case of SIA the access reference is a URI that tells the client how to retrieve the actual data. SIA was restricted to the GET method, but we don't want to stop there when defining SSA. What your example above tells me is that a service can put an access reference to a data access method into a Votable element similar to the way it's currently done in SIA for HTTP GET services. Is this true in the given context or do you think we need anything more sophisticated? Cheers, Markus From owner-grid@eso.org Mon Jun 7 16:02:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57E1aDZ028843 for ; Mon, 7 Jun 2004 16:01:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57E1abn028841 for grid-outgoing; Mon, 7 Jun 2004 16:01:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i57E1WDZ028831; Mon, 7 Jun 2004 16:01:32 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57E1UXe006943; Mon, 7 Jun 2004 16:01:30 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i57E1T311817; Mon, 7 Jun 2004 10:01:29 -0400 Date: Mon, 7 Jun 2004 10:01:29 -0400 From: "Wil O'Mullane" To: Markus Dolensky Cc: grid@ivoa.net Subject: Re: Three cheers for GET services Message-ID: <20040607100129.W31554@skysrv.pha.jhu.edu> References: <131f01c44c1f$884f6be0$2c0d680c@Ropy> <20040607092348.T31554@skysrv.pha.jhu.edu> <40C472F9.7070807@eso.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40C472F9.7070807@eso.org>; from Markus.Dolensky@eso.org on Mon, Jun 07, 2004 at 03:51:53PM +0200 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Having SOAP doe not mean you cna not have GET and indeed FTP. Th emore sophisticated thing I think will be VOSPACE which we will try to sepc before the next meeting. This would allow us to refer to an image or data set indedpendant of transfer mechanism as something like vospace://endpoint.jhu.edu/vospace/get?handle=SomeImage > What your example above tells me is that a service can put an access reference > to a data access method into a Votable element similar to the way it's > currently done in SIA for HTTP GET services. Is this true in the given context > or do you think we need anything more sophisticated? > > Cheers, > Markus > > From owner-grid@eso.org Mon Jun 7 20:33:32 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57IXEDZ008444 for ; Mon, 7 Jun 2004 20:33:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57IXEba008443 for grid-outgoing; Mon, 7 Jun 2004 20:33:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i57IXADZ008436 for ; Mon, 7 Jun 2004 20:33:11 +0200 (MEST) Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57IX9Xe020131 for ; Mon, 7 Jun 2004 20:33:09 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BXOvh-0003MQ-Tt; Mon, 07 Jun 2004 19:33: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 i57IX5mm019611; Mon, 7 Jun 2004 19:33:05 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i57IX5M1000092; Mon, 7 Jun 2004 19:33:05 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i57IX33Z000089; Mon, 7 Jun 2004 19:33:04 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Mon, 7 Jun 2004 19:33:03 +0100 (BST) From: Guy Rixon To: Roy Williams cc: grid@ivoa.net, Alex Szalay , Jim Gray Subject: Re: Three cheers for GET services In-Reply-To: <131f01c44c1f$884f6be0$2c0d680c@Ropy> Message-ID: References: <131f01c44c1f$884f6be0$2c0d680c@Ropy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Roy, things that HTTP-Get can do that SOAP can't: - express a request in a _compact_ string; - be invoked from an ordinary web-browser or similar HTTP agent. AFAIK that's all. The compact-string thing is important if you want to sent a request in hte body of an email. You _can_ send a canned SOAP request to a colleague: it's just an XML document. It's probably a big document, so you might want put it in an attachment. You can put the address of the target service into the SOAP header using WS-Addressing. You'd need a client to send the message: maybe a web page. Should we write one? Things SOAP can do that HTTP-get can't: - send long lists of parameters (there's a limit on hte length of the URL in HTTP-get) - send structured parameters (HTTP-get only does scalars) - send parameters controlled by a W3C XML schema - protect the request parameters via digital signature (HTTP-get messages can be intercepted and altered) - send self-authenticating messages without pre-agreed passwords - send messages through an intermediary, e.g. to get past a firewall (possible but messy in HTTP-get; built in with SOAP) - send the same message format via many protocols, e.g. HTTP, SMTP, JMS Note that you _can_ describe HTTP-get services in WSDL; W3C has defined bindings for HTTP-get and HTTP-post. However, we don't have any tools that do anything useful with these descriptions (unless .NET has something: Wil?). I agree with Tony that SOAP is for machine-to-machine communications. If we want machine-to-human communications then we have to write a UI, which can itself be a HTTP-get service. 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-grid@eso.org Wed Jun 9 22:33:03 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i59KWdaT011118 for ; Wed, 9 Jun 2004 22:32:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i59KWd6l011117 for grid-outgoing; Wed, 9 Jun 2004 22:32:39 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i59KWaaT011113 for ; Wed, 9 Jun 2004 22:32:36 +0200 (MEST) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i59KWYXe028549 for ; Wed, 9 Jun 2004 22:32:34 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BY9kN-0004kc-PN for grid@ivoa.net; Wed, 09 Jun 2004 21:32:31 +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 i59KWVmm024075 for ; Wed, 9 Jun 2004 21:32:31 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i59KWVM1002846 for ; Wed, 9 Jun 2004 21:32:31 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i59KWVfg002843 for ; Wed, 9 Jun 2004 21:32:31 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 9 Jun 2004 21:32:31 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Comparison of WS-Context and WS-RF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I found an article comparing WS-RF and WS-Context. http://www3.sys-con.com/webservices/rotate2.cfm This is relevant to our Asynchronous Activities profile. 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-grid@eso.org Wed Jun 9 22:38:39 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i59KcJaT011581 for ; Wed, 9 Jun 2004 22:38:19 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i59KcJX9011580 for grid-outgoing; Wed, 9 Jun 2004 22:38:19 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i59KcFaT011573 for ; Wed, 9 Jun 2004 22:38:16 +0200 (MEST) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i59KcEXe028735 for ; Wed, 9 Jun 2004 22:38:14 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BY9pq-0005Vl-In for grid@ivoa.net; Wed, 09 Jun 2004 21:38:10 +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 i59KcAmm024195 for ; Wed, 9 Jun 2004 21:38:10 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i59KcAM1002856 for ; Wed, 9 Jun 2004 21:38:10 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i59KcAe9002853 for ; Wed, 9 Jun 2004 21:38:10 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 9 Jun 2004 21:38:09 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: DIME obsolete Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This page http://roadmap.cbdiforum.com/reports/protocols/summary.php suggests that DIME has been made obsolete by SOAP MTOM. Interesting. 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-grid@eso.org Thu Jun 10 00:14:32 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i59MEDa2020105 for ; Thu, 10 Jun 2004 00:14:13 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i59MEDe7020104 for grid-outgoing; Thu, 10 Jun 2004 00:14:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i59ME9a2020097 for ; Thu, 10 Jun 2004 00:14:09 +0200 (MEST) Received: from plum.csi.cam.ac.uk (plum.csi.cam.ac.uk [131.111.8.3]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i59ME8TY018034 for ; Thu, 10 Jun 2004 00:14:08 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by plum.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BYBKf-0001Fl-Jg; Wed, 09 Jun 2004 23:14: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 i59ME4mm026309; Wed, 9 Jun 2004 23:14:04 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i59ME4M1002934; Wed, 9 Jun 2004 23:14:04 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i59ME4gb002931; Wed, 9 Jun 2004 23:14:04 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 9 Jun 2004 23:14:04 +0100 (BST) From: Guy Rixon To: Ray Plante cc: grid@ivoa.net Subject: How many port-types Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray, we spoke in Boston about how web-service operations should be factored into port types, and particularly about when operation may not appear in the same port-type. I've been looking up the WSDL spec and I now understand these cases when separate port types are required. 1. When two operations MAY NOT be bound to the same protocol then they must be in separate port-types. This lets the service have two separate ports with different bindings. However, when two operations MUST have two different bindings but each operation MAY have both bindings, then they may be in the same port-type. In this case, the service binds the one port-type to both bindings. 2. When two operations MAY NOT appear at the same address, then they must be in separate port-types so that they can be in separate WSDL ports; the WSDL port element states the service endpoint. Conversely, when two operations MUST be available at two endpoints but each operation MAY be provided at both, then only one port-type is needed. The service can provide two ports, with one port-type for one port. 3. When two operations differ in properties not described by WSDL, such as the requirement for WS-Security headers, then they SHOULD be in different port-types. In some programming models, notably JAX-RPC, these properties are handled on a per-port basis. E.g. if operation A must always have security and operation B must be available unsecured, then A and B should appear in separate ports. If they were declared in one port-type which was used in two ports, one secured and one not, then a suurious, unsecured copy of A would be available. 4. If an operation is optional, then it is MUST be in a port type by itself. My reading of the WSDL spec is that a service must implement all declared operations of a port-type which it binds in a port. If operations are optinal as a set (e.g. either all or none may be provided) then they MAY appear in the same port-type. I hope this helps. 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-grid@eso.org Thu Jun 10 01:57:04 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i59Nuha2027707 for ; Thu, 10 Jun 2004 01:56:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i59NuhZW027706 for grid-outgoing; Thu, 10 Jun 2004 01:56:43 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i59Nuea2027700 for ; Thu, 10 Jun 2004 01:56:40 +0200 (MEST) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i59NudTY020295 for ; Thu, 10 Jun 2004 01:56:39 +0200 (CEST) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.30) id 1BYCvv-01XxMJ-23; Thu, 10 Jun 2004 00:56:39 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Thu, 10 Jun 2004 00:56:38 +0100 Date: Thu, 10 Jun 2004 00:56:38 +0100 (BST) From: Alasdair Allan To: Guy Rixon cc: grid@ivoa.net Subject: Re: DIME obsolete 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: > suggests that DIME has been made obsolete by SOAP MTOM. Interesting. So many protocols, so little time... Seriously though, has anyone ever heard of this one? I've never even heard of it! I note with interest that it was initally proposed by "IBM, BEA, others" rather than "IBM, BEA and Microsoft" while DIME itself is a purely Microsoft standard. Stick with MIME, while it doesn't have the feature set of the other two, however at least it's actually a real, honest to God, standard. Al. -- Dr. A. Allan, School of Physics, University of Exeter From owner-grid@eso.org Thu Jun 10 10:44:04 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5A8fTa2029244 for ; Thu, 10 Jun 2004 10:41:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5A8fTls029243 for grid-outgoing; Thu, 10 Jun 2004 10:41:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5A8fPa2029234 for ; Thu, 10 Jun 2004 10:41:26 +0200 (MEST) Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5A8fOTY001632 for ; Thu, 10 Jun 2004 10:41:24 +0200 (CEST) Received: from star1.jb.man.ac.uk ([130.88.24.176]) by gannet.scg.man.ac.uk with esmtp (Exim 4.20) id 1BYL7j-000Pbd-Uk; Thu, 10 Jun 2004 09:41:23 +0100 Received: from astrogrid.jb.man.ac.uk ([130.88.24.101] helo=jb.man.ac.uk) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1BYL7j-0004Qm-00; Thu, 10 Jun 2004 09:41:23 +0100 Message-ID: <40C81EB2.1050501@jb.man.ac.uk> Date: Thu, 10 Jun 2004 09:41:22 +0100 From: Paul Harrison Organization: JBO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040119 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Guy Rixon CC: grid@ivoa.net Subject: Re: Comparison of WS-Context and WS-RF References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BYL7j-000Pbd-Uk*zL8F5yjnXYM* X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: It would appear that the link is actually http://www.sys-con.com/story/?storyid=44675&DE=1 Guy Rixon wrote: >I found an article comparing WS-RF and WS-Context. > >http://www3.sys-con.com/webservices/rotate2.cfm > >This is relevant to our Asynchronous Activities profile. > >Guy Rixon gtr@ast.cam.ac.uk >Institute of Astronomy Tel: +44-1223-337542 >Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > > -- Dr. Paul Harrison, Astrogrid Developer MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572681 (direct), 571321 (switch) - 07904025192 (mobile). From owner-grid@eso.org Thu Jun 10 21:00:50 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5AJ0Ha2022657 for ; Thu, 10 Jun 2004 21:00:17 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5AJ0HHE022654 for grid-outgoing; Thu, 10 Jun 2004 21:00:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5AJ09a2022632 for ; Thu, 10 Jun 2004 21:00:09 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5AJ07Xe004388 for ; Thu, 10 Jun 2004 21:00:08 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id MAA26435; Thu, 10 Jun 2004 12:00:03 -0700 (PDT) Date: Thu, 10 Jun 2004 12:00:03 -0700 (PDT) From: Matthew Graham cc: Guy Rixon , grid@ivoa.net Subject: Re: Comparison of WS-Context and WS-RF In-Reply-To: <40C81EB2.1050501@jb.man.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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I have just read the article and I think it puts a nail into the WS-RF coffin. Do you have any inklings yet of how the asynchronous stuff would need to be amended to use WS-CAF? Cheers, Matthew From owner-grid@eso.org Thu Jun 10 22:31:49 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5AKVQa2002105 for ; Thu, 10 Jun 2004 22:31:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5AKVQGU002104 for grid-outgoing; Thu, 10 Jun 2004 22:31:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5AKVLa2002098 for ; Thu, 10 Jun 2004 22:31:21 +0200 (MEST) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5AKVHXe008514 for ; Thu, 10 Jun 2004 22:31:19 +0200 (CEST) Received: from zia.aoc.nrao.edu (zia [146.88.1.4]) by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i5AKVBN08902; Thu, 10 Jun 2004 14:31:11 -0600 Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232]) by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i5AKV9TU028551; Thu, 10 Jun 2004 14:31:09 -0600 (MDT) Date: Thu, 10 Jun 2004 14:31:09 -0600 (MDT) From: Doug Tody X-X-Sender: dtody@oak To: Roy Williams cc: grid@ivoa.net, Alex Szalay , Jim Gray Subject: Re: Three cheers for GET services In-Reply-To: <131f01c44c1f$884f6be0$2c0d680c@Ropy> Message-ID: 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=-6.7, required 7, BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37, QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00, USER_AGENT_PINE 0.00) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: There has been an ongoing philosophical debate in Web architecture circles about REST vs SOAP which is relevant here. Try doing a google search on "REST SOAP" (REST = the "REpresentational State Transfer" model). Doug On Sun, 6 Jun 2004, Roy Williams wrote: > Three cheers for GET services > > (This subject line is just to stir up the SOAP fundamentalists). As I start > moving to the world of SOAP, I want to know how to do all the nifty things I > used to be able to do with GET. > > (1) Please find below an email that I sent to myself yesterday. It is a pointer > to a GET-based web service, and that is why it is easy to send the email. Just > click on it in your email spool. It is a virtual finding chart, bringing not > just a picture, but a browser of many layers and other drilldown features. It is > nifty to send a complete "service request" to a colleague, and all they need to > do is to click on it. > > But when we are running things on SOAP services, how can we do the same thing? > Suppose I write to my colleague saying "use the http://blah service with x=2 and > y=3", how long would it take them to figure out how to see the result? > > (2) On the same topic is the question of partial arguments to SOAP services. For > example, under the GET system, I can *derive* a service from another. If service > http://blah.edu/siap? returns images of all bandpasses, then the new service > http://blah.edu/siap?BANDPASS=z can be derived (by simple concatenation!) that > returns only z-images. > > Or, for example, a client could go to a login screen at http://blah.edu/login > and get in return email a URL containing his session number, such as > http://blah.edu/login?s=6ac3768ce8ff8. Clicking on this completes the login > process. > > (3) There are a lot of nice read/parse qualities about GET requests. It would be > nice to have both GET and SOAP at the same time. To somehow send keyword-value > by the GET channel, but the complex objects and binary through the SOAP channel. > > People know and trust the GET method. Crossing the bridge to SOAP should be > possible by gradual steps. > > Roy > > -------- > California Institute of Technology > roy@caltech.edu > 626 395 3670 > > ----- Original Message ----- > From: "Roy Williams" > To: "Roy Williams" > Sent: Saturday, June 05, 2004 9:10 PM > Subject: PQ/sdss stack in VS > > Finding chart PQ-2004-05-18 > > > > http://virtualsky.org/servlet/Page?F=1&RA=230&DE=-.20000&Exp=Go+Here&T=4&P=11&S=11&X=1687&Y=2043&W=4&Z=-1&M=1 > > From owner-grid@eso.org Thu Jun 10 23:59:16 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5ALwunj011897 for ; Thu, 10 Jun 2004 23:58:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5ALwtpa011896 for grid-outgoing; Thu, 10 Jun 2004 23:58:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5ALwqnj011892 for ; Thu, 10 Jun 2004 23:58:52 +0200 (MEST) Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5ALwoXe010830 for ; Thu, 10 Jun 2004 23:58:50 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BYXZO-0001Rs-EY; Thu, 10 Jun 2004 22:58:46 +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 i5ALwkmm009770; Thu, 10 Jun 2004 22:58:46 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i5ALwkM1004043; Thu, 10 Jun 2004 22:58:46 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i5ALwhWD004040; Thu, 10 Jun 2004 22:58:43 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 10 Jun 2004 22:58:43 +0100 (BST) From: Guy Rixon To: Matthew Graham cc: grid@ivoa.net Subject: Re: Comparison of WS-Context and WS-RF In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Matthew, I have a general idea, but I would need to go back to the WS-CAF docs to check details. IIRC, WS-CAF does what WS-RF does but doesn't bind the context token to an endpoint address. This allows the same context _token_ to be recognized by multiple endpoints, and that supports transactions. However, it's still a valid use of WS-Context/WS-CAF to generate a context inside the only servcie that will recognise it. I.e., we can use a WS-Context token instead of a WS-Resource to denote an activity. Again IIRC, WS-CAF has the context-management controls of WS-RF: i.e. the ability to negotiate the lifetime of the context. It hhas the ability to notify "end of context", but not the ability to notify arbitrary progress-metadata. When I mailed yesterday, I was in a debate about how DAIS/OGSA-DAI fitted with WS-I, WS-I+WS-CAF and WS-I+WS-RF. The conclusion so far is that all of DAIS, including the stateful stuff, can be done with any of those options. The choice of plumbing only affects the level of support and ease of programming. So far, I can see two open-source implementations of WS-RF and I've found none for WS-CAF (still looking,haven't searched very far yet). If you like, I can look at deatils of async activities in WS-CAF. Any takers? Cheers, Guy On Thu, 10 Jun 2004, Matthew Graham wrote: > > Hi, > > I have just read the article and I think it puts a nail into the WS-RF > coffin. Do you have any inklings yet of how the asynchronous stuff would > need to be amended to use WS-CAF? > > 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-grid@eso.org Fri Jun 11 00:42:50 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5AMgNnj017022 for ; Fri, 11 Jun 2004 00:42:23 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5AMgNC0017021 for grid-outgoing; Fri, 11 Jun 2004 00:42:23 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5AMgKnj017016 for ; Fri, 11 Jun 2004 00:42:20 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5AMgFTY029106 for ; Fri, 11 Jun 2004 00:42:16 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id PAA02832; Thu, 10 Jun 2004 15:42:13 -0700 (PDT) Date: Thu, 10 Jun 2004 15:42:13 -0700 (PDT) From: Matthew Graham To: Guy Rixon cc: grid@ivoa.net Subject: Re: Comparison of WS-Context and WS-RF 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Guy, The impression I have is that WS-CAF is certainly the more scalable of the two (even if there are no open-source implementations yet), which really becomes a concern when we start thinking about workflows involving VO web services. As the article says, the one thing we want to avoid is "... combinatorial explosion of endpoint references that have to be managed, propagated and kept up-to-date." It looks like this is really where the WS-CAF payout comes. I certainly would be interested in seeing the async. activities proposal spec'ed in WS-CAF. Cheers, Matthew From owner-grid@eso.org Wed Jun 16 14:43:08 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5GCgHMl025941 for ; Wed, 16 Jun 2004 14:42:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5GCgHYC025939 for grid-outgoing; Wed, 16 Jun 2004 14:42:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5GCgAMl025920 for ; Wed, 16 Jun 2004 14:42:11 +0200 (MEST) Received: from plum.csi.cam.ac.uk (plum.csi.cam.ac.uk [131.111.8.3]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5GCg9EQ007149 for ; Wed, 16 Jun 2004 14:42:09 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by plum.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BaZju-0002dz-06 for grid@ivoa.net; Wed, 16 Jun 2004 13:42:02 +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 i5GCg1mm003459 for ; Wed, 16 Jun 2004 13:42:01 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i5GCg1M1010489 for ; Wed, 16 Jun 2004 13:42:01 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i5GCg17X010486 for ; Wed, 16 Jun 2004 13:42:01 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 16 Jun 2004 13:42:01 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: GWS-WG plans and actions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Peter Quinn is asking for updated plans of this WG to go before the IVOA exec next week. In particular, we need to explain how our work fits with the demonstrations of January 2005 and with Peter's July-15th cut-off for input. Appended below are my ideas of how it will go. Please get back to me soonest if you think this is wrong. Objecttions received by tomorrow midnight will go in my report to the exec; later ideas before Wednesday 23rd June can be fed in verbally at the exec meeting. Cheers, Guy VO Support Interfaces: concrete spec hoped for before 15th July 2004. Spec should become a formal working draft by that date and should become a recommendation before the Pune meeting. This standard is likely to be stable well before January and would be fine for the demos. Async activities: some work needed. - Clear up points of detail raised in Boston (Rixon, by end June 2004). - Draft alternative proposal using WS-CAF for comparision (Rixon, by end of June 2004). - Debate relative merits of WS-CAF and WS-RF following Matthew's comments (whole WG via mailing list; decision required by end of August 2004). - Revise the proposal to use the selected technology - Prototype to prove ideas in 4Q2004. Given that we haven't got working consensus about which plumbing to use (consensus at Boston that WS-RF would work is not the same as consensus that we prefer it to WS-CAF), this proposal won't be stable by July 15th. This is probably not one to showcase in January. Single-sign-on proposal: some more work needed. If we accept the proposal as presented at Boston, then it can go forward quickly. However, Reagan raised the problem of iteroperating with Shibboleth and that throws some doubt on the whole thing. Shibboleth is based on SAML; our proposal doesn't use SAML, but it could be changed to do so; might be better that way. If we value interoperating with Shib, then we should probably adapt our standard to suit. Therefore, I (at least) need time to research SAML and Shib. I doubt that this proposal will be stable by July 15th. If we need security in the January demos, then we may need to do something ad hoc, in which case the current version of the proposal would be OK. Immediate actions: - Break existing SSO proposal into three docs: wire-protocol spec, PKI spec and non-normative introduction (Rixon, by 7th July 2004). WS-I profile conformance: we accept that it's the right long-term goal, yes? Therefore, we need to ppublish a short doc stating this formally. Andre: can you draft something to go out before 15th July, please? Longer term, we need the collated conformance tests for the WS tool-kits. Can we have that for Pune? Iff we turn out to have some conforming toolkits (at least two of them), then the WS-I facet of the January demos is to show that services from these environments talk to each other without grief. VOSpace: no formal proposals yet, so I'm assuming that there won't be any document drafts by 15th July. Therefore, under Peter's rules, we don't expect the VOSpace standard to appear in the January demos. However, I strongly suspect that the demos will need some VOSpace facilities (e.g. we may be using AstroGrid CEA services), so we'll need at least an ad-hoc VOSpace. Therefore, I suggest that we try to make the demo solution look like the long-term solution of choice even if the standard isn't ratified by January. - Initial, written VOSpace proposal by end of July 2004, please? - Discussion on mailing list plus informal, private prototypes (Morris and O'Mullane leading) by end of August? - Discussion of finding at Pune - Proposed recommendation by Christmas if consensus at Pune. 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-grid@eso.org Thu Jun 17 11:57:56 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5H9vBX9021449 for ; Thu, 17 Jun 2004 11:57:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5H9vBqo021447 for grid-outgoing; Thu, 17 Jun 2004 11:57:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5H9v7X9021438 for ; Thu, 17 Jun 2004 11:57:07 +0200 (MEST) Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5H9v5EQ014624 for ; Thu, 17 Jun 2004 11:57:05 +0200 (CEST) Received: from simbad.u-strasbg.fr (simbad.u-strasbg.fr [130.79.128.4]) by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i5H9v4dg094582 ; Thu, 17 Jun 2004 11:57:05 +0200 (CEST) Received: from astro.u-strasbg.fr (titeuf.u-strasbg.fr [130.79.129.106]) by simbad.u-strasbg.fr (8.11.6+Sun/8.11.6) with ESMTP id i5H9xF010748; Thu, 17 Jun 2004 11:59:15 +0200 (MEST) Message-ID: <40D16AEE.2040400@astro.u-strasbg.fr> Date: Thu, 17 Jun 2004 11:57:02 +0200 From: Andre Schaaff Organization: CDS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en,fr,fr-FR MIME-Version: 1.0 To: Guy Rixon CC: grid@ivoa.net Subject: Re: GWS-WG plans and actions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: scanned by sophos at u-strasbg.fr X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andre Schaaff X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hello Guy, Guy Rixon wrote: >Hi, > >Peter Quinn is asking for updated plans of this WG to go before the IVOA exec >next week. In particular, we need to explain how our work fits with the >demonstrations of January 2005 and with Peter's July-15th cut-off for input. >Appended below are my ideas of how it will go. Please get back to me soonest >if you think this is wrong. Objecttions received by tomorrow midnight will go >in my report to the exec; later ideas before Wednesday 23rd June can be fed in >verbally at the exec meeting. > >Cheers, >Guy > >VO Support Interfaces: concrete spec hoped for before 15th July 2004. Spec >should become a formal working draft by that date and should become a >recommendation before the Pune meeting. This standard is likely to be stable >well before January and would be fine for the demos. > > > ok >... > >WS-I profile conformance: we accept that it's the right long-term goal, yes? >Therefore, we need to ppublish a short doc stating this formally. Andre: can >you draft something to go out before 15th July, please? > ok for this deadline i will provide a first draft for the 5th July so we will have a few days for discussions before a final draft (before the 15th July) >Longer term, we need >the collated conformance tests for the WS tool-kits. Can we have that for >Pune? Iff we turn out to have some conforming toolkits (at least two of >them), then the WS-I facet of the January demos is to show that services from >these environments talk to each other without grief. > > > i think that it is reasonable to plan that for Pune ... -- André Schaaff Observatoire Astronomique CDS - http://cdsweb.u-strasbg.fr/ 11, rue de l'Université F-67000 Strasbourg From owner-grid@eso.org Thu Jun 17 20:59:22 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5HIwZX9024255 for ; Thu, 17 Jun 2004 20:58:35 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5HIwZdc024254 for grid-outgoing; Thu, 17 Jun 2004 20:58:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5HIwWX9024246 for ; Thu, 17 Jun 2004 20:58:32 +0200 (MEST) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5HIwTDP027553 for ; Thu, 17 Jun 2004 20:58:30 +0200 (CEST) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu X-Envelope-To: Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id i5HIwLx08417 for ; Thu, 17 Jun 2004 13:58:22 -0500 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id i5HIwLWh023376 for ; Thu, 17 Jun 2004 13:58:21 -0500 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id i5HIwLYD023372 for ; Thu, 17 Jun 2004 13:58:21 -0500 Date: Thu, 17 Jun 2004 13:58:21 -0500 (CDT) From: Ray Plante To: grid@ivoa.net Subject: requirements for a standard WSDL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, In this week's NVO MWG telecon, we discussed the topic of how best to define standard interfaces using WSDL. Among the issues we discussed were how one supports optional and non-standard arguments (like the HTTP version of SIA allows). This discussion spilled a little onto our NVO metadata mailing list. This led me to jot down a strawman set of requirements for an IVOA standard WSDL document which I thought I would share with this list, too. That message appears below. (Hopefully, this intro gives you enough context to get something out my list.) cheers, Ray ---------- Forwarded message ---------- Date: Thu, 17 Jun 2004 13:51:26 -0500 (CDT) From: Ray Plante Reply-To: Ray Plante To: metadata@us-vo.org Subject: Re: Optional elements in WSDL On Thu, 17 Jun 2004, Matthew Graham wrote: > I suspect that you are using something like: [snip] > > > Yes that is correct. > but what happens if someone comes along with their own version of, say, a > SIAP service which uses an extended schema from the above; is there any > way we can write the standard schema that would allow compatibility with > this so that the same client could handle both types? That's a good question (that I don't have an answer to) and would be good to prototype. I think the base requirements for the standard service definition is something like the following: 1. A client developer (or application) should be able to download the standard WSDL from the IVOA web site (i.e. as a static file) and from it generate a client interface. That client can then interact with any compliant implementation of the WSDL by plugging in the appropriate endpoint address. It should *not* be necessary for the client to download and process the WSDL associated with the specific service instance (apart possibly from determining the endpoint address). 2. To create an implementation of the standard service, it should be sufficient download the WSDL and use it to create a service binding; the standard WSDL is then sufficient to describe that particular instance apart from inserting the endpoint address. 3. Standard WSDLs must defined in such a way that optional operations (i.e. methods) incur no (or negligible) cost to implementers that choose not to support them. 4. It should be straight-forward for a client to determine which (optional) operations an instance supports. 5. When the WSDL is retreived from a particular service instance, it should be possible to determine that whether it (claims to) comply with a standard WSDL. 6. The standard WSDL be able to, in effect, "import" the so-called "VO Support" operations to include them as part of the standard interface. Augmentation of the interface in terms of "added-value" capabilities should be okay as long as the base requirements are met. So here are some of the augmentations that we've come up with that we *might* want to allow. (Whether we do allow it depends on how easy it is leave the door open in the standard WSDL and the cost to the implementor doing the simplest implementation.) o allow an implementation to support additional, non-standard operations. o allow an implementaton to support standard operations using extended types. o allow different portions of the interface to be supported via different endpoints. It is assumed that a client that wishes to make use of this specialized capability would have to retrieve that instance's WSDL (as opposed to the standard one at the IVOA site) to create a proper interface to it. So what we need to develop is a "best practice" specification for defining standard WSDLs that meet these requirements. cheers, Ray From owner-grid@eso.org Thu Jun 17 21:39:56 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5HJdUX9028232 for ; Thu, 17 Jun 2004 21:39:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5HJdU9V028231 for grid-outgoing; Thu, 17 Jun 2004 21:39:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5HJdQX9028218 for ; Thu, 17 Jun 2004 21:39:27 +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 i5HJdODP029232 for ; Thu, 17 Jun 2004 21:39:24 +0200 (CEST) Received: from zia.aoc.nrao.edu (zia [146.88.1.4]) by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i5HJdIN28774 for ; Thu, 17 Jun 2004 13:39:18 -0600 Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232]) by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i5HJdHTU009821; Thu, 17 Jun 2004 13:39:17 -0600 (MDT) Date: Thu, 17 Jun 2004 13:39:17 -0600 (MDT) From: Doug Tody X-X-Sender: dtody@oak To: grid@ivoa.net Subject: Re: requirements for a standard WSDL In-Reply-To: Message-ID: 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=-6.7, required 7, BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37, QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00, USER_AGENT_PINE 0.00) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think I agree with everything Ray said below but I would like to say more about the concept of optional parameters to a service call. The issue here is whether our service has a simple "function with arguments" method call, as when SOAP is used to serialize a distributed method call from some language, or a higher level "parameter" mechanism, where parameters may be optional, may have default values, constraints, and so forth. The higher level parameter mechanism is what is most needed to interface complex services such as SIA/SSA, or to expose most astronomy components (tasks) as services. Such tasks may have many (dozens) of parameters, most of which are optional and have default values. In general, for each service, what we want is to be able to define a "parameter set" schema which defines a set of parameter objects, some of which are required, some of which are optional, each of which may have a default value, and possibly other attributes such as minimum and maximum values, an enumerated list of values, a descriptive string, possibly a units specifier, etc. This could then be used on the client side to compose a valid parameter set instance before invoking the remote service, or it could be used on the service side to implement a parameter handling front-end to the service. The actual invocation would pass parameters as a simple parameter and value whether rendered into in GET or SOAP. Ideally it should be possible to input parameters in any order, and services should be permitted to extend the interface to add service-specific parameters. Below Ray also suggests permitting interfaces to be extended to add non-standard methods, which is also desirable. Doug On Thu, 17 Jun 2004, Ray Plante wrote: > Hi, > > In this week's NVO MWG telecon, we discussed the topic of how best to > define standard interfaces using WSDL. Among the issues we discussed were > how one supports optional and non-standard arguments (like the HTTP > version of SIA allows). This discussion spilled a little onto our NVO > metadata mailing list. This led me to jot down a strawman set of > requirements for an IVOA standard WSDL document which I thought I would > share with this list, too. That message appears below. > > (Hopefully, this intro gives you enough context to get something out my > list.) > > cheers, > Ray > > ---------- Forwarded message ---------- > Date: Thu, 17 Jun 2004 13:51:26 -0500 (CDT) > From: Ray Plante > Reply-To: Ray Plante > To: metadata@us-vo.org > Subject: Re: Optional elements in WSDL > > On Thu, 17 Jun 2004, Matthew Graham wrote: > > I suspect that you are using something like: > [snip] > > > > > > > > Yes that is correct. > > > but what happens if someone comes along with their own version of, say, a > > SIAP service which uses an extended schema from the above; is there any > > way we can write the standard schema that would allow compatibility with > > this so that the same client could handle both types? > > That's a good question (that I don't have an answer to) and would be > good to prototype. > > I think the base requirements for the standard service definition is > something like the following: > > 1. A client developer (or application) should be able to download > the standard WSDL from the IVOA web site (i.e. as a static file) > and from it generate a client interface. That client can then > interact with any compliant implementation of the WSDL by > plugging in the appropriate endpoint address. It should *not* > be necessary for the client to download and process the WSDL > associated with the specific service instance (apart possibly > from determining the endpoint address). > > 2. To create an implementation of the standard service, it should > be sufficient download the WSDL and use it to create a service > binding; the standard WSDL is then sufficient to describe that > particular instance apart from inserting the endpoint address. > > 3. Standard WSDLs must defined in such a way that optional operations > (i.e. methods) incur no (or negligible) cost to implementers > that choose not to support them. > > 4. It should be straight-forward for a client to determine which > (optional) operations an instance supports. > > 5. When the WSDL is retreived from a particular service instance, > it should be possible to determine that whether it (claims to) > comply with a standard WSDL. > > 6. The standard WSDL be able to, in effect, "import" the so-called > "VO Support" operations to include them as part of the standard > interface. > > Augmentation of the interface in terms of "added-value" capabilities > should be okay as long as the base requirements are met. So here are > some of the augmentations that we've come up with that we *might* want > to allow. (Whether we do allow it depends on how easy it is leave the > door open in the standard WSDL and the cost to the implementor doing > the simplest implementation.) > > o allow an implementation to support additional, non-standard > operations. > > o allow an implementaton to support standard operations using > extended types. > > o allow different portions of the interface to be supported via > different endpoints. > > It is assumed that a client that wishes to make use of this > specialized capability would have to retrieve that instance's WSDL (as > opposed to the standard one at the IVOA site) to create a proper > interface to it. > > So what we need to develop is a "best practice" specification for > defining standard WSDLs that meet these requirements. > > cheers, > Ray > > > > From owner-grid@eso.org Fri Jun 18 00:33:09 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5HMWc80012534 for ; Fri, 18 Jun 2004 00:32:39 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5HMWcA5012533 for grid-outgoing; Fri, 18 Jun 2004 00:32:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5HMWY80012528 for ; Fri, 18 Jun 2004 00:32:35 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5HMWWEQ011784 for ; Fri, 18 Jun 2004 00:32:33 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id PAA17228; Thu, 17 Jun 2004 15:32:31 -0700 (PDT) Date: Thu, 17 Jun 2004 15:32:31 -0700 (PDT) From: Matthew Graham To: Ray Plante cc: grid@ivoa.net, metadata@us-vo.org Subject: Re: requirements for a standard WSDL 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Apologies to those who receive this twice. Given the possible problems for tools with the container catch-all element in the types/schema, I was wondering whether the of a WSDL which extends another WSDL can also extend the of the original WSDL - this could be a way around the problem. Of course, there is a way to do this: Standard WSDL imports Standard.xsd Extension WSDL (based on Standard WSDL) imports Extended.xsd (based on Standard.xsd) However, the annoyance with this is then that one is dealing with multiple files instead of having everything defined inline in the one file. Of course, this might be the easiest way around this. Cheers, Matthew From owner-grid@eso.org Fri Jun 18 10:29:15 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5I8Sg80023828 for ; Fri, 18 Jun 2004 10:28:42 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5I8SgEe023826 for grid-outgoing; Fri, 18 Jun 2004 10:28:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5I8Sa80023809 for ; Fri, 18 Jun 2004 10:28:36 +0200 (MEST) Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5I8SYEQ025340 for ; Fri, 18 Jun 2004 10:28:34 +0200 (CEST) Received: from star1.jb.man.ac.uk ([130.88.24.176]) by curlew.cs.man.ac.uk with esmtp (Exim 4.20) id 1BbEjh-000KUC-Me; Fri, 18 Jun 2004 09:28:33 +0100 Received: from astrogrid.jb.man.ac.uk ([130.88.24.101] helo=jb.man.ac.uk) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1BbEjh-0007G2-00; Fri, 18 Jun 2004 09:28:33 +0100 Message-ID: <40D2A7B1.90503@jb.man.ac.uk> Date: Fri, 18 Jun 2004 09:28:33 +0100 From: Paul Harrison Organization: JBO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040119 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Doug Tody CC: grid@ivoa.net Subject: Re: requirements for a standard WSDL References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BbEjh-000KUC-Me*8qaACXBAnpE* X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The Astrogrid Common Execution Architecture (CEA) has been designed, in part, as a possible solution to this problem. The approach that we have taken is to have a single set of WSDL and schema that describe the meta information about the real parameters to a particular service. This meta information for the parameters allows them to have many of the attributes that are desired below e.g. being optional, having defaults, descriptions etc. I am preparing a note on this http://www.astrogrid.org/maven/docs/snapshot/applications/design/CEADesignIVOANote.html It contains links to all the WSDL and schema that we are currently using in our live implementation. Cheers, Paul. Doug Tody wrote: >I think I agree with everything Ray said below but I would like to say more >about the concept of optional parameters to a service call. > >The issue here is whether our service has a simple "function with >arguments" method call, as when SOAP is used to serialize a distributed >method call from some language, or a higher level "parameter" mechanism, >where parameters may be optional, may have default values, constraints, >and so forth. The higher level parameter mechanism is what is most >needed to interface complex services such as SIA/SSA, or to expose most >astronomy components (tasks) as services. Such tasks may have many >(dozens) of parameters, most of which are optional and have default values. > >In general, for each service, what we want is to be able to define a >"parameter set" schema which defines a set of parameter objects, some of >which are required, some of which are optional, each of which may have a >default value, and possibly other attributes such as minimum and maximum >values, an enumerated list of values, a descriptive string, possibly >a units specifier, etc. This could then be used on the client side to >compose a valid parameter set instance before invoking the remote service, >or it could be used on the service side to implement a parameter handling >front-end to the service. The actual invocation would pass parameters as a >simple parameter and value whether rendered into in GET or SOAP. Ideally it >should be possible to input parameters in any order, and services should >be permitted to extend the interface to add service-specific parameters. > >Below Ray also suggests permitting interfaces to be extended to add non-standard >methods, which is also desirable. Doug > > > > >On Thu, 17 Jun 2004, Ray Plante wrote: > > > >>Hi, >> >>In this week's NVO MWG telecon, we discussed the topic of how best to >>define standard interfaces using WSDL. Among the issues we discussed were >>how one supports optional and non-standard arguments (like the HTTP >>version of SIA allows). This discussion spilled a little onto our NVO >>metadata mailing list. This led me to jot down a strawman set of >>requirements for an IVOA standard WSDL document which I thought I would >>share with this list, too. That message appears below. >> >>(Hopefully, this intro gives you enough context to get something out my >>list.) >> >>cheers, >>Ray >> >>---------- Forwarded message ---------- >>Date: Thu, 17 Jun 2004 13:51:26 -0500 (CDT) >>From: Ray Plante >>Reply-To: Ray Plante >>To: metadata@us-vo.org >>Subject: Re: Optional elements in WSDL >> >>On Thu, 17 Jun 2004, Matthew Graham wrote: >> >> >>>I suspect that you are using something like: >>> >>> >>[snip] >> >> >>> >>> >>> >>> >>> >>Yes that is correct. >> >> >> >>>but what happens if someone comes along with their own version of, say, a >>>SIAP service which uses an extended schema from the above; is there any >>>way we can write the standard schema that would allow compatibility with >>>this so that the same client could handle both types? >>> >>> >>That's a good question (that I don't have an answer to) and would be >>good to prototype. >> >>I think the base requirements for the standard service definition is >>something like the following: >> >> 1. A client developer (or application) should be able to download >> the standard WSDL from the IVOA web site (i.e. as a static file) >> and from it generate a client interface. That client can then >> interact with any compliant implementation of the WSDL by >> plugging in the appropriate endpoint address. It should *not* >> be necessary for the client to download and process the WSDL >> associated with the specific service instance (apart possibly >> from determining the endpoint address). >> >> 2. To create an implementation of the standard service, it should >> be sufficient download the WSDL and use it to create a service >> binding; the standard WSDL is then sufficient to describe that >> particular instance apart from inserting the endpoint address. >> >> 3. Standard WSDLs must defined in such a way that optional operations >> (i.e. methods) incur no (or negligible) cost to implementers >> that choose not to support them. >> >> 4. It should be straight-forward for a client to determine which >> (optional) operations an instance supports. >> >> 5. When the WSDL is retreived from a particular service instance, >> it should be possible to determine that whether it (claims to) >> comply with a standard WSDL. >> >> 6. The standard WSDL be able to, in effect, "import" the so-called >> "VO Support" operations to include them as part of the standard >> interface. >> >>Augmentation of the interface in terms of "added-value" capabilities >>should be okay as long as the base requirements are met. So here are >>some of the augmentations that we've come up with that we *might* want >>to allow. (Whether we do allow it depends on how easy it is leave the >>door open in the standard WSDL and the cost to the implementor doing >>the simplest implementation.) >> >> o allow an implementation to support additional, non-standard >> operations. >> >> o allow an implementaton to support standard operations using >> extended types. >> >> o allow different portions of the interface to be supported via >> different endpoints. >> >>It is assumed that a client that wishes to make use of this >>specialized capability would have to retrieve that instance's WSDL (as >>opposed to the standard one at the IVOA site) to create a proper >>interface to it. >> >>So what we need to develop is a "best practice" specification for >>defining standard WSDLs that meet these requirements. >> >>cheers, >>Ray >> >> >> >> >> >> > > > > -- Dr. Paul Harrison, Astrogrid Developer MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572681 (direct), 571321 (switch) - 07904025192 (mobile). From owner-grid@eso.org Fri Jun 18 17:12:37 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5IFBt4j012030 for ; Fri, 18 Jun 2004 17:11:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5IFBtMp012029 for grid-outgoing; Fri, 18 Jun 2004 17:11:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5IFBo4j012018 for ; Fri, 18 Jun 2004 17:11:50 +0200 (MEST) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.49.69]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5IFBlDP003383 for ; Fri, 18 Jun 2004 17:11:48 +0200 (CEST) Received: from earth-dog (earth-dog [192.168.1.3]) by water-ox-postvirus (Postfix) with ESMTP id B8B1826AC07 for ; Fri, 18 Jun 2004 08:11:46 -0700 (PDT) Received: from water-ox ([192.168.1.10]) by earth-dog (MailMonitor for SMTP v1.2.2 ) ; Fri, 18 Jun 2004 08:11:45 -0700 (PDT) Received: from ipac.caltech.edu (unknown [69.166.209.91]) by water-ox.its.caltech.edu (Postfix) with ESMTP id 7922A26AD5F for ; Fri, 18 Jun 2004 08:11:45 -0700 (PDT) Message-ID: <40D305E9.10406@ipac.caltech.edu> Date: Fri, 18 Jun 2004 08:10:33 -0700 From: Joe Chavez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: grid@ivoa.net Subject: Re: Three cheers for GET services References: <131f01c44c1f$884f6be0$2c0d680c@Ropy> In-Reply-To: <131f01c44c1f$884f6be0$2c0d680c@Ropy> Content-Type: multipart/mixed; boundary="------------030304070903000405060903" X-Spam-Status: No, hits=0.0 tagged_above=-100000.0 required=5.0 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Joe Chavez X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------030304070903000405060903 Content-Type: multipart/alternative; boundary="------------060906070404050601050006" --------------060906070404050601050006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit We at the Spitzer Science Archive have deployed a set of Web services for searching and retrieving data from the archive. There support for GET and PUT mainly due to our client access requirements (browser, Java client and scripting languages). An example of the GET/PUT interface can be found here: http://archive.spitzer.caltech.edu/ArchiveWS/edu/caltech/ipac/sirtf/archive/ws/search/ArchiveSearch.jws?.EXPLORE=.TEST The main user interface is here: http://archive.spitzer.caltech.edu/ -- Joe Chavez Roy Williams wrote: >Three cheers for GET services > >(This subject line is just to stir up the SOAP fundamentalists). As I start >moving to the world of SOAP, I want to know how to do all the nifty things I >used to be able to do with GET. > >(1) Please find below an email that I sent to myself yesterday. It is a pointer >to a GET-based web service, and that is why it is easy to send the email. Just >click on it in your email spool. It is a virtual finding chart, bringing not >just a picture, but a browser of many layers and other drilldown features. It is >nifty to send a complete "service request" to a colleague, and all they need to >do is to click on it. > >But when we are running things on SOAP services, how can we do the same thing? >Suppose I write to my colleague saying "use the http://blah service with x=2 and >y=3", how long would it take them to figure out how to see the result? > >(2) On the same topic is the question of partial arguments to SOAP services. For >example, under the GET system, I can *derive* a service from another. If service >http://blah.edu/siap? returns images of all bandpasses, then the new service >http://blah.edu/siap?BANDPASS=z can be derived (by simple concatenation!) that >returns only z-images. > >Or, for example, a client could go to a login screen at http://blah.edu/login >and get in return email a URL containing his session number, such as >http://blah.edu/login?s=6ac3768ce8ff8. Clicking on this completes the login >process. > >(3) There are a lot of nice read/parse qualities about GET requests. It would be >nice to have both GET and SOAP at the same time. To somehow send keyword-value >by the GET channel, but the complex objects and binary through the SOAP channel. > >People know and trust the GET method. Crossing the bridge to SOAP should be >possible by gradual steps. > >Roy > >-------- >California Institute of Technology >roy@caltech.edu >626 395 3670 > >----- Original Message ----- >From: "Roy Williams" >To: "Roy Williams" >Sent: Saturday, June 05, 2004 9:10 PM >Subject: PQ/sdss stack in VS > >Finding chart PQ-2004-05-18 > > > >http://virtualsky.org/servlet/Page?F=1&RA=230&DE=-.20000&Exp=Go+Here&T=4&P=11&S=11&X=1687&Y=2043&W=4&Z=-1&M=1 > > > > -- ******************************************************** * Joe Chavez - jchavez@ipac.caltech.edu * * Voice: 626-395-8679 * * Mobile: 626-497-4490 * * FAX: 626-583-9046 * * Web: http://spider.ipac.caltech.edu/staff/jchavez * ******************************************************** --------------060906070404050601050006 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit We at the Spitzer Science Archive have deployed a set of Web services for searching and retrieving data from the archive. There support for GET and PUT mainly due to our client access requirements (browser, Java client and scripting languages).

An example of the GET/PUT interface can be found here:
http://archive.spitzer.caltech.edu/ArchiveWS/edu/caltech/ipac/sirtf/archive/ws/search/ArchiveSearch.jws?.EXPLORE=.TEST

The main user interface is here:
http://archive.spitzer.caltech.edu/

--
Joe Chavez


Roy Williams wrote:
Three cheers for GET services

(This subject line is just to stir up the SOAP fundamentalists). As I start
moving to the world of SOAP, I want to know how to do all the nifty things I
used to be able to do with GET.

(1) Please find below an email that I sent to myself yesterday. It is a pointer
to a GET-based web service, and that is why it is easy to send the email. Just
click on it in your email spool. It is a virtual finding chart, bringing not
just a picture, but a browser of many layers and other drilldown features. It is
nifty to send a complete "service request" to a colleague, and all they need to
do is to click on it.

But when we are running things on SOAP services, how can we do the same thing?
Suppose I write to my colleague saying "use the http://blah service with x=2 and
y=3", how long would it take them to figure out how to see the result?

(2) On the same topic is the question of partial arguments to SOAP services. For
example, under the GET system, I can *derive* a service from another. If service
http://blah.edu/siap? returns images of all bandpasses, then the new service
http://blah.edu/siap?BANDPASS=z can be derived (by simple concatenation!) that
returns only z-images.

Or, for example, a client could go to a login screen at http://blah.edu/login
and get in return email a URL containing his session number, such as
http://blah.edu/login?s=6ac3768ce8ff8. Clicking on this completes the login
process.

(3) There are a lot of nice read/parse qualities about GET requests. It would be
nice to have both GET and SOAP at the same time. To somehow send keyword-value
by the GET channel, but the complex objects and binary through the SOAP channel.

People know and trust the GET method. Crossing the bridge to SOAP should be
possible by gradual steps.

Roy

--------
California Institute of Technology
roy@caltech.edu
626 395 3670

----- Original Message ----- 
From: "Roy Williams" <roy@cacr.caltech.edu>
To: "Roy Williams" <roy@cacr.caltech.edu>
Sent: Saturday, June 05, 2004 9:10 PM
Subject: PQ/sdss stack in VS

Finding chart PQ-2004-05-18

  
http://virtualsky.org/servlet/Page?F=1&RA=230&DE=-.20000&Exp=Go+Here&T=4&P=11&S=11&X=1687&Y=2043&W=4&Z=-1&M=1

--
********************************************************
* Joe Chavez - jchavez@ipac.caltech.edu                *
* Voice:  626-395-8679                                 *
* Mobile: 626-497-4490                                 *
* FAX:    626-583-9046                                 *
* Web:    http://spider.ipac.caltech.edu/staff/jchavez *
********************************************************
--------------060906070404050601050006-- --------------030304070903000405060903 Content-Type: text/x-vcard; charset=utf8; name="jchavez.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jchavez.vcf" begin:vcard fn:Joe Chavez n:Chavez;Joe org:California Institute of Technology;IPAC adr:M/S 220-6;;1200 E. California Blvd;Pasadena;CA;91125;USA email;internet:jchavez@ipac.caltech.edu title:Computer Scientist tel;work:626-395-8679 x-mozilla-html:TRUE url:http://spider.ipac.caltech.edu/staff/jchavez/ version:2.1 end:vcard --------------030304070903000405060903-- From owner-grid@eso.org Fri Jun 18 18:06:58 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5IG6Y4j017461 for ; Fri, 18 Jun 2004 18:06:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5IG6YNH017459 for grid-outgoing; Fri, 18 Jun 2004 18:06:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5IG6U4j017450 for ; Fri, 18 Jun 2004 18:06:30 +0200 (MEST) Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5IG6PEQ011224 for ; Fri, 18 Jun 2004 18:06:26 +0200 (CEST) Received: from lepus.tuc.noao.edu (dtody [209.155.156.44]) by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i5IG6FJh019431; Fri, 18 Jun 2004 10:06:16 -0600 Date: Fri, 18 Jun 2004 10:06:13 -0600 (MDT) From: Doug Tody X-X-Sender: dtody@lepus.tuc.noao.edu To: Paul Harrison cc: grid@ivoa.net Subject: Re: requirements for a standard WSDL In-Reply-To: <40D2A7B1.90503@jb.man.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Paul - Thanks, I will take a look at this. It looks like we are working on the same problem. Who all is working on this within Astrogrid? What I think we need is a component-framework architecture. At the core is a standard component model which wraps some component, be it a piece of the VO infrastructure, or an astronomy data analysis component. Probably the component interface should be capable of supporting multiple interface protocols, one of which would be SOAP (another might be parameter-based host execution, e.g., as in a unix shell). The parameter abstraction is needed to support all of these models. Your Astrogrid CEA is an example of an execution framework which would use these components. Probably there would be multiple frameworks given the range of execution environments targeted. Ideally we would like to be able to run on a desktop system, on a cluster, or on the grid with a workflow, using the same components. We need standards for things like the component model and interface, including the parameter abstraction. - Doug On Fri, 18 Jun 2004, Paul Harrison wrote: > The Astrogrid Common Execution Architecture (CEA) has been designed, in > part, as a possible solution to this problem. The approach that we have > taken is to have a single set of WSDL and schema that describe the meta > information about the real parameters to a particular service. This meta > information for the parameters allows them to have many of the > attributes that are desired below e.g. being optional, having defaults, > descriptions etc. > > I am preparing a note on this > > http://www.astrogrid.org/maven/docs/snapshot/applications/design/CEADesignIVOANote.html > > It contains links to all the WSDL and schema that we are currently using > in our live implementation. > > Cheers, > Paul. > > > > Doug Tody wrote: > > >I think I agree with everything Ray said below but I would like to say more > >about the concept of optional parameters to a service call. > > > >The issue here is whether our service has a simple "function with > >arguments" method call, as when SOAP is used to serialize a distributed > >method call from some language, or a higher level "parameter" mechanism, > >where parameters may be optional, may have default values, constraints, > >and so forth. The higher level parameter mechanism is what is most > >needed to interface complex services such as SIA/SSA, or to expose most > >astronomy components (tasks) as services. Such tasks may have many > >(dozens) of parameters, most of which are optional and have default values. > > > >In general, for each service, what we want is to be able to define a > >"parameter set" schema which defines a set of parameter objects, some of > >which are required, some of which are optional, each of which may have a > >default value, and possibly other attributes such as minimum and maximum > >values, an enumerated list of values, a descriptive string, possibly > >a units specifier, etc. This could then be used on the client side to > >compose a valid parameter set instance before invoking the remote service, > >or it could be used on the service side to implement a parameter handling > >front-end to the service. The actual invocation would pass parameters as a > >simple parameter and value whether rendered into in GET or SOAP. Ideally it > >should be possible to input parameters in any order, and services should > >be permitted to extend the interface to add service-specific parameters. > > > >Below Ray also suggests permitting interfaces to be extended to add non-standard > >methods, which is also desirable. Doug From owner-grid@eso.org Fri Jun 18 19:01:29 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5IH0g4j021371 for ; Fri, 18 Jun 2004 19:00:43 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5IH0gxU021370 for grid-outgoing; Fri, 18 Jun 2004 19:00:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5IH0d4j021366 for ; Fri, 18 Jun 2004 19:00:39 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5IH0bDP007065 for ; Fri, 18 Jun 2004 19:00:37 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id KAA08442; Fri, 18 Jun 2004 10:00:31 -0700 (PDT) Date: Fri, 18 Jun 2004 10:00:30 -0700 (PDT) From: Matthew Graham To: Doug Tody cc: Paul Harrison , grid@ivoa.net Subject: Re: requirements for a standard WSDL 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, This is exactly the sort of thing that the GRIST project (grist.caltech.edu) is working on here at Caltech and JPL. Cheers, Matthew From owner-grid@eso.org Fri Jun 18 22:42:17 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5IKex4j010248 for ; Fri, 18 Jun 2004 22:40:59 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5IKexJN010247 for grid-outgoing; Fri, 18 Jun 2004 22:40:59 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5IKet4j010238 for ; Fri, 18 Jun 2004 22:40:55 +0200 (MEST) Received: from billthecat.sdsc.edu (billthecat.sdsc.edu [132.249.20.60]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5IKeqEQ018992 for ; Fri, 18 Jun 2004 22:40:53 +0200 (CEST) Received: from [132.249.200.198] (moore-pb.sdsc.edu [132.249.200.198]) by billthecat.sdsc.edu (8.11.7/8.11.7/mx/48) with ESMTP id i5IKenB04234; Fri, 18 Jun 2004 13:40:50 -0700 (PDT) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu Message-Id: In-Reply-To: References: Date: Fri, 18 Jun 2004 09:38:00 -0700 To: grid@ivoa.net, Guy Rixon From: Reagan Moore Subject: Re: GWS-WG plans and actions Cc: kremenek@sdsc.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy: We will need to interoperate with at least two security environments: - GSI security for access to resources authenticated by grid technology - Shibboleth, for access to resources controlled by digital libraries (DSpace) For an early prototype for VOSpace we would like to volunteer the use of the Storage Resource Broker data grid. The system supports GSI authentication, access controls, user defined metadata, collection hierarchies, data replication, access to archives, OAI interface, WSDL interface, and multiple APIs. We would like to add IVOA access mechanisms as they are defined. Reagan Moore >Hi, > >Peter Quinn is asking for updated plans of this WG to go before the IVOA exec >next week. In particular, we need to explain how our work fits with the >demonstrations of January 2005 and with Peter's July-15th cut-off for input. >Appended below are my ideas of how it will go. Please get back to me soonest >if you think this is wrong. Objecttions received by tomorrow midnight will go >in my report to the exec; later ideas before Wednesday 23rd June can be fed in >verbally at the exec meeting. > >Cheers, >Guy > >VO Support Interfaces: concrete spec hoped for before 15th July 2004. Spec >should become a formal working draft by that date and should become a >recommendation before the Pune meeting. This standard is likely to be stable >well before January and would be fine for the demos. > >Async activities: some work needed. > > - Clear up points of detail raised in Boston (Rixon, by end June 2004). > > - Draft alternative proposal using WS-CAF for comparision (Rixon, > by end of June 2004). > > - Debate relative merits of WS-CAF and WS-RF following Matthew's comments > (whole WG via mailing list; decision required by end of August 2004). > > - Revise the proposal to use the selected technology > > - Prototype to prove ideas in 4Q2004. > >Given that we haven't got working consensus about which plumbing to use >(consensus at Boston that WS-RF would work is not the same as consensus that >we prefer it to WS-CAF), this proposal won't be stable by July 15th. This is >probably not one to showcase in January. > > >Single-sign-on proposal: some more work needed. If we accept the proposal as >presented at Boston, then it can go forward quickly. However, Reagan raised >the problem of iteroperating with Shibboleth and that throws some doubt on the >whole thing. Shibboleth is based on SAML; our proposal doesn't use SAML, but >it could be changed to do so; might be better that way. If we value >interoperating with Shib, then we should probably adapt our standard to suit. >Therefore, I (at least) need time to research SAML and Shib. I doubt that this >proposal will be stable by July 15th. If we need security in the January >demos, then we may need to do something ad hoc, in which case the current >version of the proposal would be OK. > >Immediate actions: > > - Break existing SSO proposal into three docs: wire-protocol spec, PKI spec > and non-normative introduction (Rixon, by 7th July 2004). > >WS-I profile conformance: we accept that it's the right long-term goal, yes? >Therefore, we need to ppublish a short doc stating this formally. Andre: can >you draft something to go out before 15th July, please? Longer term, we need >the collated conformance tests for the WS tool-kits. Can we have that for >Pune? Iff we turn out to have some conforming toolkits (at least two of >them), then the WS-I facet of the January demos is to show that services from >these environments talk to each other without grief. > >VOSpace: no formal proposals yet, so I'm assuming that there won't be any >document drafts by 15th July. Therefore, under Peter's rules, we don't expect >the VOSpace standard to appear in the January demos. However, I strongly >suspect that the demos will need some VOSpace facilities (e.g. we may be using >AstroGrid CEA services), so we'll need at least an ad-hoc VOSpace. Therefore, >I suggest that we try to make the demo solution look like the long-term >solution of choice even if the standard isn't ratified by January. > > - Initial, written VOSpace proposal by end of July 2004, please? > > - Discussion on mailing list plus informal, private prototypes > (Morris and O'Mullane leading) by end of August? > > - Discussion of finding at Pune > > - Proposed recommendation by Christmas if consensus at Pune. > >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-grid@eso.org Sun Jun 20 17:51:04 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5KFoGHP017907 for ; Sun, 20 Jun 2004 17:50:16 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5KFoG2N017906 for grid-outgoing; Sun, 20 Jun 2004 17:50:16 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5KFoBHP017871 for ; Sun, 20 Jun 2004 17:50:12 +0200 (MEST) Received: from purple.csi.cam.ac.uk (purple.csi.cam.ac.uk [131.111.8.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5KBMPEQ024268 for ; Sun, 20 Jun 2004 13:22:26 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by purple.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Bc0P0-0003Hi-I5; Sun, 20 Jun 2004 12:22:22 +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 i5KBMLmm015100; Sun, 20 Jun 2004 12:22:21 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i5KBMLM1015881; Sun, 20 Jun 2004 12:22:21 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i5KBMKnh015878; Sun, 20 Jun 2004 12:22:20 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Sun, 20 Jun 2004 12:22:20 +0100 (BST) From: Guy Rixon To: Reagan Moore cc: grid@ivoa.net, kremenek@sdsc.edu Subject: Re: GWS-WG plans and actions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Reagan, we appreciate the chance to try VOSpace with SRB. To facilitiate this we need to make plain what we mean by "GSI security". I understand GSI security to be defined by its API (the GSS one from IETF). IIRC, the only extension of GSS in GSI is ability to do 'delegation by approximation using proxy certificates. I've never seen a definition of the wire protocol for GSI, which leads me to suspect (a) that there may be several, incompatible forms of GSI, and (b) that the wire protocols used in GT3 web services (which follow OASIS standards) may not be GSI. Do you have a better understanding of what GSI really means? Can you tell us what really happens when GSI is used to talk to SRB? Cheers, Guy On Fri, 18 Jun 2004, Reagan Moore wrote: > Guy: > We will need to interoperate with at least two security environments: > > - GSI security for access to resources authenticated by grid technology > - Shibboleth, for access to resources controlled by digital libraries (DSpace) > > For an early prototype for VOSpace we would like to volunteer the use > of the Storage Resource Broker data grid. The system supports GSI > authentication, access controls, user defined metadata, collection > hierarchies, data replication, access to archives, OAI interface, > WSDL interface, and multiple APIs. We would like to add IVOA access > mechanisms as they are defined. > > Reagan Moore > > > >Hi, > > > >Peter Quinn is asking for updated plans of this WG to go before the IVOA exec > >next week. In particular, we need to explain how our work fits with the > >demonstrations of January 2005 and with Peter's July-15th cut-off for input. > >Appended below are my ideas of how it will go. Please get back to me soonest > >if you think this is wrong. Objecttions received by tomorrow midnight will go > >in my report to the exec; later ideas before Wednesday 23rd June can be fed in > >verbally at the exec meeting. > > > >Cheers, > >Guy > > > >VO Support Interfaces: concrete spec hoped for before 15th July 2004. Spec > >should become a formal working draft by that date and should become a > >recommendation before the Pune meeting. This standard is likely to be stable > >well before January and would be fine for the demos. > > > >Async activities: some work needed. > > > > - Clear up points of detail raised in Boston (Rixon, by end June 2004). > > > > - Draft alternative proposal using WS-CAF for comparision (Rixon, > > by end of June 2004). > > > > - Debate relative merits of WS-CAF and WS-RF following Matthew's comments > > (whole WG via mailing list; decision required by end of August 2004). > > > > - Revise the proposal to use the selected technology > > > > - Prototype to prove ideas in 4Q2004. > > > >Given that we haven't got working consensus about which plumbing to use > >(consensus at Boston that WS-RF would work is not the same as consensus that > >we prefer it to WS-CAF), this proposal won't be stable by July 15th. This is > >probably not one to showcase in January. > > > > > >Single-sign-on proposal: some more work needed. If we accept the proposal as > >presented at Boston, then it can go forward quickly. However, Reagan raised > >the problem of iteroperating with Shibboleth and that throws some doubt on the > >whole thing. Shibboleth is based on SAML; our proposal doesn't use SAML, but > >it could be changed to do so; might be better that way. If we value > >interoperating with Shib, then we should probably adapt our standard to suit. > >Therefore, I (at least) need time to research SAML and Shib. I doubt that this > >proposal will be stable by July 15th. If we need security in the January > >demos, then we may need to do something ad hoc, in which case the current > >version of the proposal would be OK. > > > >Immediate actions: > > > > - Break existing SSO proposal into three docs: wire-protocol spec, PKI spec > > and non-normative introduction (Rixon, by 7th July 2004). > > > >WS-I profile conformance: we accept that it's the right long-term goal, yes? > >Therefore, we need to ppublish a short doc stating this formally. Andre: can > >you draft something to go out before 15th July, please? Longer term, we need > >the collated conformance tests for the WS tool-kits. Can we have that for > >Pune? Iff we turn out to have some conforming toolkits (at least two of > >them), then the WS-I facet of the January demos is to show that services from > >these environments talk to each other without grief. > > > >VOSpace: no formal proposals yet, so I'm assuming that there won't be any > >document drafts by 15th July. Therefore, under Peter's rules, we don't expect > >the VOSpace standard to appear in the January demos. However, I strongly > >suspect that the demos will need some VOSpace facilities (e.g. we may be using > >AstroGrid CEA services), so we'll need at least an ad-hoc VOSpace. Therefore, > >I suggest that we try to make the demo solution look like the long-term > >solution of choice even if the standard isn't ratified by January. > > > > - Initial, written VOSpace proposal by end of July 2004, please? > > > > - Discussion on mailing list plus informal, private prototypes > > (Morris and O'Mullane leading) by end of August? > > > > - Discussion of finding at Pune > > > > - Proposed recommendation by Christmas if consensus at Pune. > > > >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-grid@eso.org Mon Jun 21 11:43:37 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5L9h4kJ006310 for ; Mon, 21 Jun 2004 11:43:05 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5L9h4Te006309 for grid-outgoing; Mon, 21 Jun 2004 11:43:04 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5L9gxkJ006301 for ; Mon, 21 Jun 2004 11:42:59 +0200 (MEST) Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5L9gvEQ019746 for ; Mon, 21 Jun 2004 11:42:57 +0200 (CEST) Received: from star1.jb.man.ac.uk ([130.88.24.176]) by curlew.cs.man.ac.uk with esmtp (Exim 4.20) id 1BcLKL-0005mS-3R for grid@ivoa.net; Mon, 21 Jun 2004 10:42:57 +0100 Received: from astrogrid.jb.man.ac.uk ([130.88.24.101] helo=jb.man.ac.uk) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1BcLKK-00050q-00 for grid@ivoa.net; Mon, 21 Jun 2004 10:42:56 +0100 Message-ID: <40D6AD9F.2090904@jb.man.ac.uk> Date: Mon, 21 Jun 2004 10:42:55 +0100 From: Paul Harrison Organization: JBO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040119 X-Accept-Language: en, en-us MIME-Version: 1.0 To: grid@ivoa.net Subject: Re: requirements for a standard WSDL References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BcLKL-0005mS-3R*5ug3JqSexUU* X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Doug Tody wrote: >Hi Paul - > >Thanks, I will take a look at this. It looks like we are working on the >same problem. Who all is working on this within Astrogrid? > > It is mainly myself and Noel Winstanley that are working on this. The primary motivation was to provide a uniform interface for our worklow system to drive. So in terms of what we have implemented right now the principal client of the CEA is the workflow component, the server part being called Job execution system (JES), and all the communication is over SOAP. CEA is implemeted as a layer on top of the SOAP transport at the moment, but as it is a distinct layer, and it should be possible to use other transports. >What I think we need is a component-framework architecture. At the core is >a standard component model which wraps some component, be it a piece of the >VO infrastructure, or an astronomy data analysis component. Probably the >component interface should be capable of supporting multiple interface >protocols, one of which would be SOAP (another might be parameter-based >host execution, e.g., as in a unix shell). The parameter abstraction is >needed to support all of these models. > > > The approach that we have taken with unix shell executables is to create a web services component that can act as an adapter for a unix executable, so that in the simplest of cases we can add web services access to the executable in this framework by deploying the adapter and adding a registry entry describing the parameters of the unix executable. Something more sophisitcated is really needed for the large astronomical packages such as AIPS or IRAF, and we will be exploring the approaches necessary in these cases. >Your Astrogrid CEA is an example of an execution framework which would >use these components. Probably there would be multiple frameworks given >the range of execution environments targeted. Ideally we would like to >be able to run on a desktop system, on a cluster, or on the grid with a >workflow, using the same components. We need standards for things like >the component model and interface, including the parameter abstraction. > > - Doug > > >On Fri, 18 Jun 2004, Paul Harrison wrote: > > > >>The Astrogrid Common Execution Architecture (CEA) has been designed, in >>part, as a possible solution to this problem. The approach that we have >>taken is to have a single set of WSDL and schema that describe the meta >>information about the real parameters to a particular service. This meta >>information for the parameters allows them to have many of the >>attributes that are desired below e.g. being optional, having defaults, >>descriptions etc. >> >>I am preparing a note on this >> >>http://www.astrogrid.org/maven/docs/snapshot/applications/design/CEADesignIVOANote.html >> >>It contains links to all the WSDL and schema that we are currently using >>in our live implementation. >> >>Cheers, >> Paul. >> >> >> >>Doug Tody wrote: >> >> >> >>>I think I agree with everything Ray said below but I would like to say more >>>about the concept of optional parameters to a service call. >>> >>>The issue here is whether our service has a simple "function with >>>arguments" method call, as when SOAP is used to serialize a distributed >>>method call from some language, or a higher level "parameter" mechanism, >>>where parameters may be optional, may have default values, constraints, >>>and so forth. The higher level parameter mechanism is what is most >>>needed to interface complex services such as SIA/SSA, or to expose most >>>astronomy components (tasks) as services. Such tasks may have many >>>(dozens) of parameters, most of which are optional and have default values. >>> >>>In general, for each service, what we want is to be able to define a >>>"parameter set" schema which defines a set of parameter objects, some of >>>which are required, some of which are optional, each of which may have a >>>default value, and possibly other attributes such as minimum and maximum >>>values, an enumerated list of values, a descriptive string, possibly >>>a units specifier, etc. This could then be used on the client side to >>>compose a valid parameter set instance before invoking the remote service, >>>or it could be used on the service side to implement a parameter handling >>>front-end to the service. The actual invocation would pass parameters as a >>>simple parameter and value whether rendered into in GET or SOAP. Ideally it >>>should be possible to input parameters in any order, and services should >>>be permitted to extend the interface to add service-specific parameters. >>> >>>Below Ray also suggests permitting interfaces to be extended to add non-standard >>>methods, which is also desirable. Doug >>> >>> > > > > -- Dr. Paul Harrison, Astrogrid Developer MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572681 (direct), 571321 (switch) - 07904025192 (mobile). From owner-grid@eso.org Tue Jun 22 19:29:56 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5MHTac6022286 for ; Tue, 22 Jun 2004 19:29:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5MHTaEP022285 for grid-outgoing; Tue, 22 Jun 2004 19:29:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5MHTWc6022278 for ; Tue, 22 Jun 2004 19:29:33 +0200 (MEST) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5MHTVEQ022791 for ; Tue, 22 Jun 2004 19:29:31 +0200 (CEST) Message-Id: <200406221729.i5MHTVEQ022791@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1Bcp5O-0005Tf-HV for grid@ivoa.net; Tue, 22 Jun 2004 18:29:30 +0100 Received: (qmail 21901 invoked from network); 22 Jun 2004 17:29:32 -0000 Received: from morpheus.star.le.ac.uk (HELO gnowee) (143.210.36.121) by mail.star.le.ac.uk with SMTP; 22 Jun 2004 17:29:32 -0000 From: "Tony Linde" To: Subject: Deferred port-type Date: Tue, 22 Jun 2004 18:29:10 +0100 Organization: University of Leicester MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcROcn8rCykIXlNOSiWJFFaif6B1VwKBxXnw X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Something I thought of while looking at the SkyNode spec just now was that perhaps we need some way for a service to indicate (through its registry entry? its wsdl?) that it supplies some aspects of a standard interface through another interface: so a port-type is supplied by another service. What I had in mind was about SkyNode. Many data services will not want to have to supply detailed metadata when it is already supplied via the registry. If there was some way for it to indicate that the GetMetadata, Tables, Columns etc port-types were to be resolved by calling another service using set information (eg a registry service with its resourceID as parameter) then it could still meet the interface without needing extra coding. The same could apply to, say, the getAvailability port-type for services which are clustered together with a single management service which looks after their availability. Is this possible? Cheers, Tony. From owner-grid@eso.org Tue Jun 22 19:56:48 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5MHuUc6024613 for ; Tue, 22 Jun 2004 19:56:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5MHuUdo024612 for grid-outgoing; Tue, 22 Jun 2004 19:56:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5MHuQc6024602 for ; Tue, 22 Jun 2004 19:56:26 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5MHuOEQ023578 for ; Tue, 22 Jun 2004 19:56:25 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i5MHuK722072; Tue, 22 Jun 2004 13:56:20 -0400 Date: Tue, 22 Jun 2004 13:56:20 -0400 From: "Wil O'Mullane" To: Tony Linde Cc: grid@ivoa.net Subject: Re: Deferred port-type Message-ID: <20040622135620.U6548@skysrv.pha.jhu.edu> References: <200406221729.i5MHTVEQ022791@rocky.hq.eso.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200406221729.i5MHTVEQ022791@rocky.hq.eso.org>; from ael@star.le.ac.uk on Tue, Jun 22, 2004 at 06:29:10PM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think this came up in one of the boston disucussions. Its kind of nice but will make the registry yet more complex and registring probably also more complex. It is also not difficult in my implementation to simply call this other service and pass back the info. i.e. You skynode may query the registry for its entry and return it from the GetRegistration Interface. Its a few lines of code for the implementer and means a more consistent interface for clients. It also means no changes to VoResource. wil On Tue, Jun 22, 2004 at 06:29:10PM +0100, Tony Linde wrote: > Something I thought of while looking at the SkyNode spec just now was that > perhaps we need some way for a service to indicate (through its registry > entry? its wsdl?) that it supplies some aspects of a standard interface > through another interface: so a port-type is supplied by another service. > > What I had in mind was about SkyNode. Many data services will not want to > have to supply detailed metadata when it is already supplied via the > registry. If there was some way for it to indicate that the GetMetadata, > Tables, Columns etc port-types were to be resolved by calling another > service using set information (eg a registry service with its resourceID as > parameter) then it could still meet the interface without needing extra > coding. > > The same could apply to, say, the getAvailability port-type for services > which are clustered together with a single management service which looks > after their availability. > > Is this possible? > > Cheers, > Tony. From owner-grid@eso.org Tue Jun 29 17:20:14 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i5TFJSoe003305 for ; Tue, 29 Jun 2004 17:19:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i5TFJSd8003304 for grid-outgoing; Tue, 29 Jun 2004 17:19:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i5TFJOoe003291 for ; Tue, 29 Jun 2004 17:19:24 +0200 (MEST) Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i5TFJLEQ011337 for ; Tue, 29 Jun 2004 17:19:21 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BfKO1-0005Lq-Vh for grid@ivoa.net; Tue, 29 Jun 2004 16:19: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 i5TFJ5mm028019 for ; Tue, 29 Jun 2004 16:19:05 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i5TFJ5M1000130 for ; Tue, 29 Jun 2004 16:19:05 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i5TFJ5qP000127 for ; Tue, 29 Jun 2004 16:19:05 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 29 Jun 2004 16:19:05 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Introductory note for SSO proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I've split the introductory material out of the single-sign-on proposal as promised and drafted it as an IVOA note: http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-introduction.htm Let me know if you think this needs changing: content, presentation, whatever. If nobody wants any changes, then I'll pass the note to Marco as v1.0 around the end of next week. The actual profiles will follow. 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-grid@eso.org Thu Jul 1 18:23:36 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i61GNCIR001720 for ; Thu, 1 Jul 2004 18:23:12 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i61GNCnv001718 for grid-outgoing; Thu, 1 Jul 2004 18:23:12 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i61GN6IR001699 for ; Thu, 1 Jul 2004 18:23:06 +0200 (MEST) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i61GN3EQ024043 for ; Thu, 1 Jul 2004 18:23:04 +0200 (CEST) Received: from zia.aoc.nrao.edu (zia [146.88.1.4]) by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i61GMxN10858; Thu, 1 Jul 2004 10:22:59 -0600 Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232]) by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i61GMvOT009471; Thu, 1 Jul 2004 10:22:57 -0600 (MDT) Date: Thu, 1 Jul 2004 10:22:57 -0600 (MDT) From: Doug Tody X-X-Sender: dtody@oak To: Guy Rixon cc: grid@ivoa.net Subject: Re: Introductory note for SSO proposal In-Reply-To: Message-ID: 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=-6.7, required 7, BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37, QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00, USER_AGENT_PINE 0.00) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy - This looks good, but it would be very helpful to do a walk-through of a typical use case to illustrate in concrete terms what is being proposed, down to the level of the specific software required to implement such a capability. For example, suppose we have the following scenario: o Site A maintains a user database of all users of the facility. Probably we want to associate the central sign-on authority for the site with this user database. When a user first accesses the system, e.g., via a Web page, or via a remote Java client, we somehow authorize the user with this authority. o The user runs some Java client, say a proposal submission tool, which wants to query a database at the site, and ultimately update information in the database. The Java client will need to authenticate with the master sign-on authority for the site. This presumably returns some sort of ticket back to the client which it can then pass off to the database front-end to gain secure access. How does this work and what software is used? What is the lifetime and scope of the ticket? Can it be passed around to different clients on different computers or possibly at different sites? How? We will need different "communities" as you say, e.g., for PIs and their CoIs, for the TAC, for the local staff, and so forth. A single person might be in more than one community. o The same authorization mechanism would then be used to retrieve data from the archive. Again, this could have various front ends. A typical scenario might be for a user or client program at site A to perform a query to site B and pass a secure request to site C to initiate a third-party transfer of the data back to site A. Each site would want to maintain its own user database and authentication mechanism since this same mechanism would probably be used for internal operations. We might need to gateway whatever is used internally to whatever is used for site-to-site authentication within the VO, or perhaps this could be another example of a community. Thanks. - Doug On Tue, 29 Jun 2004, Guy Rixon wrote: > Hi, > > I've split the introductory material out of the single-sign-on proposal as > promised and drafted it as an IVOA note: > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-introduction.htm > > Let me know if you think this needs changing: content, presentation, whatever. > If nobody wants any changes, then I'll pass the note to Marco as v1.0 around > the end of next week. > > The actual profiles will follow. > > 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-grid@eso.org Thu Jul 1 19:13:38 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i61HDKIR007790 for ; Thu, 1 Jul 2004 19:13:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i61HDKqJ007789 for grid-outgoing; Thu, 1 Jul 2004 19:13:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i61HDGIR007784 for ; Thu, 1 Jul 2004 19:13:16 +0200 (MEST) Received: from rose.csi.cam.ac.uk (rose.csi.cam.ac.uk [131.111.8.13]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i61HDEEQ025927 for ; Thu, 1 Jul 2004 19:13:14 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by rose.csi.cam.ac.uk with esmtp (Exim 4.20) id 1Bg57R-00041v-Ve; Thu, 01 Jul 2004 18:13: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 i61HD5mm002492; Thu, 1 Jul 2004 18:13:05 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i61HD5M1003457; Thu, 1 Jul 2004 18:13:05 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i61HD5B0003454; Thu, 1 Jul 2004 18:13:05 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 1 Jul 2004 18:13:04 +0100 (BST) From: Guy Rixon To: Doug Tody cc: grid@ivoa.net Subject: Re: Introductory note for SSO proposal In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Doug, here's some preliminary thoughts on your questions. On Thu, 1 Jul 2004, Doug Tody wrote: > Guy - > > This looks good, but it would be very helpful to do a walk-through of a > typical use case to illustrate in concrete terms what is being proposed, > down to the level of the specific software required to implement such > a capability. > > For example, suppose we have the following scenario: > > o Site A maintains a user database of all users of the facility. > Probably we want to associate the central sign-on authority for > the site with this user database. When a user first accesses > the system, e.g., via a Web page, or via a remote Java client, > we somehow authorize the user with this authority. Site A can play it one of three ways. 1. Trust unknown users if they come from Community X, which A trusts a priori, and register automatically in A them when they first show up at A. Wil has suggested this approach for MyDB. 2. Don't trust unknown users coming from X, even if the X community is trusted; don't register unknown users automatically. Instead, poll X regularly (e.g. nightly; interface TBD) and register in A all users in A that are unknown to A. 3. Require users to register explictly and manually at A, stating their identity in X. Trust warrants from X to prove the identity of users, but don't let them into A if they haven't registered in A. Any of these work. #3 is more reassuring for service providers perhaps, since it allows more checks and balances. However, bear in mind that the admins of X may decide to pre-register all their users in A when they join X. This would seem to be a Good Thing for X and the users but reduces the strength of A's defenses. #2 presumes that there is some interface at X whereby A can ask for security assertions about members of X. This is comparable to a Shibboleth asking a community for SAML assertions at the time of authentication. We may need to make this interface anyway. > o The user runs some Java client, say a proposal submission tool, > which wants to query a database at the site, and ultimately > update information in the database. The Java client will need > to authenticate with the master sign-on authority for the site. > This presumably returns some sort of ticket back to the client > which it can then pass off to the database front-end to gain > secure access. How does this work and what software is used? > What is the lifetime and scope of the ticket? Can it be passed > around to different clients on different computers or possibly at > different sites? How? We will need different "communities" as you > say, e.g., for PIs and their CoIs, for the TAC, for the local staff, > and so forth. A single person might be in more than one community. If the "master sign-on authority for the site" is the user's home community, then yes: the community issues tickets in the form of SAML assertions that the user's agent can add to authenticated messages. Bear in mind that one service site typically trusts several, possibly many, communities to issue these credentials; there's no single, master SSO site. Ticket (warrant) lifetimes around a day sound good to me. The scope of the ticket is all the service sites that trust the issuing community; potentially the entire VO. A given ticket is tied to a public-private key-pair of which the client holds the private key (that's how it can sign the messages). Different clients of the same user have different private keys, so have different tickets, but the tickets are for the same identity. PIs. CoIs and staff for the same mission, say, might be different groups inside one community. > o The same authorization mechanism would then be used to retrieve > data from the archive. Again, this could have various front ends. > A typical scenario might be for a user or client program at site > A to perform a query to site B and pass a secure request to site > C to initiate a third-party transfer of the data back to site A. > > Each site would want to maintain its own user database and authentication > mechanism since this same mechanism would probably be used for internal > operations. We might need to gateway whatever is used internally to > whatever is used for site-to-site authentication within the VO, or perhaps > this could be another example of a community. I see the user database being for internal authorization: you convert the external identity to an internal identity and check the authorization of the latter. The SSO authentication doesn't need a user database at the service site since it works of the external identity. 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-grid@eso.org Fri Jul 2 10:57:45 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i628uRLg024370 for ; Fri, 2 Jul 2004 10:56:27 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i628uQvi024368 for grid-outgoing; Fri, 2 Jul 2004 10:56:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i628uGLg024342 for ; Fri, 2 Jul 2004 10:56:16 +0200 (MEST) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i628uEDP015072 for ; Fri, 2 Jul 2004 10:56:14 +0200 (CEST) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BgJqA-0000zm-49 for grid@ivoa.net; Fri, 02 Jul 2004 09:56:14 +0100 Received: (qmail 22544 invoked from network); 2 Jul 2004 08:56:35 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 2 Jul 2004 08:56:35 -0000 Date: Fri, 2 Jul 2004 09:56:13 +0100 (BST) From: Clive Page To: grid@ivoa.net Subject: Free Certification Authority Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I don't know if others have noticed this story from O'Reilly-net which describes a non-profit CAcert http://www.onlamp.com/pub/wlg/5142 It will be interesting to see whether this sort of thing catches on, and if so whether such certificates are treated as "good enough" for the purposes of establishing identity. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-grid@eso.org Fri Jul 2 13:16:01 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i62BFULg010859 for ; Fri, 2 Jul 2004 13:15:31 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i62BFUM0010858 for grid-outgoing; Fri, 2 Jul 2004 13:15:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i62BFRLg010852 for ; Fri, 2 Jul 2004 13:15:27 +0200 (MEST) Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i62BFPEQ025211 for ; Fri, 2 Jul 2004 13:15:26 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BgM0f-0005ev-Ka for grid@ivoa.net; Fri, 02 Jul 2004 12:15:13 +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 i62BFDmm000613 for ; Fri, 2 Jul 2004 12:15:13 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i62BFDM1004453 for ; Fri, 2 Jul 2004 12:15:13 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i62BFCsF004450 for ; Fri, 2 Jul 2004 12:15:12 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 2 Jul 2004 12:15:12 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: VOSpace Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, there's a debate happening in AstroGrid about the naming scheme for things in MySpace/VOSpace: http://forum.astrogrid.org/viewtopic.php?t=776 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-grid@eso.org Fri Jul 2 13:55:22 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i62BsuLg015821 for ; Fri, 2 Jul 2004 13:54:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i62BsuOb015820 for grid-outgoing; Fri, 2 Jul 2004 13:54:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i62BspLg015813 for ; Fri, 2 Jul 2004 13:54:51 +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 i62BsnEQ026778 for ; Fri, 2 Jul 2004 13:54:50 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 95DFF44016; Fri, 2 Jul 2004 12:54:49 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 7278; Fri, 02 Jul 2004 12:54:48 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 445C444013; Fri, 2 Jul 2004 12:54:48 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Fri, 2 Jul 2004 12:54:48 +0100 (BST) Received: from dial.pipex.com (IFA19P.roe.ac.uk [195.194.122.26]) by katrine.roe.ac.uk (Postfix) with ESMTP id 0AAEB44013; Fri, 2 Jul 2004 12:54:48 +0100 (BST) Message-ID: <40E54D07.7020608@dial.pipex.com> Date: Fri, 02 Jul 2004 12:54:47 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon Cc: grid@ivoa.net Subject: Re: VOSpace References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Oh no even more people involved! I ought to point out that the scheme being discussed is a way of making the existing one we use just now in AstroGrid (see http://wiki.astrogrid.org/bin/view/Astrogrid/ResolvingIVORNs) more explicit and less confusing. It is used to identify files both through community homespace, registry-resolvable file-stores, and urls. I expect at some point we will be able to replace bits/all of it with industry-standard forms, (perhaps WS-RF?), that might be common across more components. For example, we may be able to use the same structure to refer to a job, a table in a database, a file, a running query, etc. Guy Rixon wrote: > Hi, > > there's a debate happening in AstroGrid about the naming scheme for things in > MySpace/VOSpace: > > http://forum.astrogrid.org/viewtopic.php?t=776 > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Fri Jul 2 16:32:58 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i62EWTLg010590 for ; Fri, 2 Jul 2004 16:32:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i62EWSJt010562 for grid-outgoing; Fri, 2 Jul 2004 16:32:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i62EU6MS009844 for ; Fri, 2 Jul 2004 16:32:05 +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 i62DMXEQ001532 for ; Fri, 2 Jul 2004 15:22:34 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:55111) by ppsw-9.csi.cam.ac.uk (old-ppsw.cam.ac.uk [131.111.8.3]:25) with esmtp (Exim 4.34) id 1BgNzs-0008LD-EU; Fri, 02 Jul 2004 14:22:32 +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 i62DMWmm006176; Fri, 2 Jul 2004 14:22:32 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i62DMWM1004668; Fri, 2 Jul 2004 14:22:32 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i62DMVEi004665; Fri, 2 Jul 2004 14:22:32 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 2 Jul 2004 14:22:31 +0100 (BST) From: Guy Rixon To: Clive Page cc: grid@ivoa.net Subject: Re: Free Certification Authority In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Interesting. I see that one still has to show up in person (where?) with physical ID. This kind of physical registration step was considered to rule out the UK e-Science CA for VO work. I guess that CAcert is only relevant for the VO work if users already have the certificates before coming to use the VO. Note that users with CAcert credentials would still need to register somewhere in the VO in order to get authorized. Having an identity is not quite the same thing as having an account. On Fri, 2 Jul 2004, Clive Page wrote: > I don't know if others have noticed this story from O'Reilly-net which > describes a non-profit CAcert > http://www.onlamp.com/pub/wlg/5142 > > It will be interesting to see whether this sort of thing catches on, and > if so whether such certificates are treated as "good enough" for the > purposes of establishing identity. > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, > Leicester, LE1 7RH, U.K. > 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-grid@eso.org Fri Jul 2 16:43:34 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i62EgtLg012696 for ; Fri, 2 Jul 2004 16:42:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i62EgrTw012690 for grid-outgoing; Fri, 2 Jul 2004 16:42:53 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i62EglLg012680 for ; Fri, 2 Jul 2004 16:42:47 +0200 (MEST) Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i62EgjDP002198 for ; Fri, 2 Jul 2004 16:42:45 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BgPFP-0004Rg-QO; Fri, 02 Jul 2004 15:42:39 +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 i62Egcmm009929; Fri, 2 Jul 2004 15:42:39 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i62EgcM1004773; Fri, 2 Jul 2004 15:42:38 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i62EgcwE004770; Fri, 2 Jul 2004 15:42:38 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 2 Jul 2004 15:42:38 +0100 (BST) From: Guy Rixon To: Doug Tody cc: grid@ivoa.net Subject: Re: Introductory note for SSO proposal In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Doug, there has been some discussion of this within AstroGrid space: see http://forum.astrogrid.org/viewtopic.php?t=764 It mainly centres on how to retain single-sign on when users need to combine privileges from different communities where they are registered. I think my suggestion, in the AG forum, for federating the communities and authorization services answers your needs for local registration. This federation feature is not yet in the IVOA proposal but I guess it should be. Cheers, Guy On Thu, 1 Jul 2004, Doug Tody wrote: > Guy - > > This looks good, but it would be very helpful to do a walk-through of a > typical use case to illustrate in concrete terms what is being proposed, > down to the level of the specific software required to implement such > a capability. > > For example, suppose we have the following scenario: > > o Site A maintains a user database of all users of the facility. > Probably we want to associate the central sign-on authority for > the site with this user database. When a user first accesses > the system, e.g., via a Web page, or via a remote Java client, > we somehow authorize the user with this authority. > > o The user runs some Java client, say a proposal submission tool, > which wants to query a database at the site, and ultimately > update information in the database. The Java client will need > to authenticate with the master sign-on authority for the site. > This presumably returns some sort of ticket back to the client > which it can then pass off to the database front-end to gain > secure access. How does this work and what software is used? > What is the lifetime and scope of the ticket? Can it be passed > around to different clients on different computers or possibly at > different sites? How? We will need different "communities" as you > say, e.g., for PIs and their CoIs, for the TAC, for the local staff, > and so forth. A single person might be in more than one community. > > o The same authorization mechanism would then be used to retrieve > data from the archive. Again, this could have various front ends. > A typical scenario might be for a user or client program at site > A to perform a query to site B and pass a secure request to site > C to initiate a third-party transfer of the data back to site A. > > Each site would want to maintain its own user database and authentication > mechanism since this same mechanism would probably be used for internal > operations. We might need to gateway whatever is used internally to > whatever is used for site-to-site authentication within the VO, or perhaps > this could be another example of a community. > > Thanks. > > - Doug > > > > On Tue, 29 Jun 2004, Guy Rixon wrote: > > > Hi, > > > > I've split the introductory material out of the single-sign-on proposal as > > promised and drafted it as an IVOA note: > > > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-introduction.htm > > > > Let me know if you think this needs changing: content, presentation, whatever. > > If nobody wants any changes, then I'll pass the note to Marco as v1.0 around > > the end of next week. > > > > The actual profiles will follow. > > > > 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 > > > > > 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-grid@eso.org Fri Jul 2 17:05:06 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i62F4eLg015391 for ; Fri, 2 Jul 2004 17:04:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i62F4dJv015390 for grid-outgoing; Fri, 2 Jul 2004 17:04:39 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i62F4TLi015364 for ; Fri, 2 Jul 2004 17:04:34 +0200 (MEST) Received: from gold.csi.cam.ac.uk (gold.csi.cam.ac.uk [131.111.8.12]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i62D7kDP026991 for ; Fri, 2 Jul 2004 15:07:46 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]) by gold.csi.cam.ac.uk with esmtp (Exim 4.20) id 1BgNlT-0001d1-R1; Fri, 02 Jul 2004 14:07:39 +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 i62D7dmm005552; Fri, 2 Jul 2004 14:07:39 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i62D7dM1004639; Fri, 2 Jul 2004 14:07:39 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i62D7dpf004636; Fri, 2 Jul 2004 14:07:39 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 2 Jul 2004 14:07:39 +0100 (BST) From: Guy Rixon To: Martin Hill cc: grid@ivoa.net Subject: Re: VOSpace In-Reply-To: <40E54D07.7020608@dial.pipex.com> Message-ID: References: <40E54D07.7020608@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Fri, 2 Jul 2004, Martin Hill wrote: > I expect at some point we will be able to replace bits/all of it with > industry-standard forms, (perhaps WS-RF?), that might be common across more > components. For example, we may be able to use the same structure to refer to a > job, a table in a database, a file, a running query, etc. I'd expect the current schemes to be replaced with an IVOA standard on timescales of ~12 months. And yes, the naming scheme should cover all data artifacts stored in the VO on behalf of users. > Guy Rixon wrote: > > > Hi, > > > > there's a debate happening in AstroGrid about the naming scheme for things in > > MySpace/VOSpace: > > > > http://forum.astrogrid.org/viewtopic.php?t=776 > > > > Guy Rixon gtr@ast.cam.ac.uk > > Institute of Astronomy Tel: +44-1223-337542 > > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > > > > -- > Martin Hill > www.mchill.net > +44 7901 55 24 66 > > 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-grid@eso.org Fri Jul 2 17:05:08 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i62F4oLg015416 for ; Fri, 2 Jul 2004 17:04:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i62F4onw015415 for grid-outgoing; Fri, 2 Jul 2004 17:04:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i62F4TLm015364 for ; Fri, 2 Jul 2004 17:04: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 i62DmCDP029253 for ; Fri, 2 Jul 2004 15:48:12 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:57660) by ppsw-9.csi.cam.ac.uk (old-ppsw.cam.ac.uk [131.111.8.3]:25) with esmtp (Exim 4.34) id 1BgOOE-0005Hu-PN; Fri, 02 Jul 2004 14: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 i62Dlgmm007437; Fri, 2 Jul 2004 14:47:42 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i62DlfM1004715; Fri, 2 Jul 2004 14:47:41 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i62Dlf0i004712; Fri, 2 Jul 2004 14:47:41 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 2 Jul 2004 14:47:41 +0100 (BST) From: Guy Rixon To: Clive Page cc: grid@ivoa.net Subject: Re: Free Certification Authority In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I've now got in to CAcert's list of "assurers" (Registration Authorities in grid-speak). Here's the list for the UK: * Home (139) o United Kingdom (13) + Berkshire (3) + Bristol (1) + Hampshire (1) + Hertfordshire (1) + Kent (1) + London (1) + Manchester (1) + Oxfordshire (1) + Scotland (1) + Tyne & Wear (1) + West Sussex (1) And here's the list of countries supported: * Home (139) o Argentina (1) o Australia (20) o Austria (2) o Belgium (2) o Canada (8) o Denmark (1) o France (2) o Germany (25) o Netherlands (6) o New Zealand (3) o Norway (1) o Not Set (1) o Poland PL (1) o Scotland (2) o Singapore (1) o Spain (1) o Thailand (1) o Ukraine (1) o United Kingdom (13) o United States (47) On Fri, 2 Jul 2004, Clive Page wrote: > On Fri, 2 Jul 2004, Guy Rixon wrote: > > > > > I've just tried the "join CAcert link" at www.cacert.org. My browser (Firefox > > 0.9) reckons there's something dodgy about the site certificate for > > www.cacert.org itself. Not promising. > > Perhaps they issued their own certificate to themselves - recursivity may > imply dodginess in this field, I wouldn't know. > > Seriously though, it's the idea that free or at least non-profit CAs might > be set up that was the interesting idea. They appear to be based in > Boston, which as you say isn't the most convenient place to show one's > passport. On the other hand it looks as if many people flying in will get > themselves fingerprinted as well before long. > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > 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-grid@eso.org Fri Jul 2 17:05:06 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i62F4lLg015408 for ; Fri, 2 Jul 2004 17:04:47 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i62F4lok015407 for grid-outgoing; Fri, 2 Jul 2004 17:04:47 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i62F4TLk015364 for ; Fri, 2 Jul 2004 17:04:38 +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 i62Dh3DP029027 for ; Fri, 2 Jul 2004 15:43:03 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:57284) by ppsw-9.csi.cam.ac.uk (old-ppsw.cam.ac.uk [131.111.8.3]:25) with esmtp (Exim 4.34) id 1BgOJc-0004QG-Ie; Fri, 02 Jul 2004 14:42:56 +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 i62Dgumm007257; Fri, 2 Jul 2004 14:42:56 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i62DguM1004697; Fri, 2 Jul 2004 14:42:56 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i62Dgtbw004694; Fri, 2 Jul 2004 14:42:55 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 2 Jul 2004 14:42:55 +0100 (BST) From: Guy Rixon To: Clive Page cc: grid@ivoa.net Subject: Re: Free Certification Authority In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Yes, you're right, they have a self-signed site certificate. I guess that's OK in this context (gotta trust them if you use them, so gotta trust their site cert)... except it would be really sad if A. Ttacker was able to spoof www.cacert.org and grab passwords. I'd have gone with a Verisign cert for the sign-up site. I'm part-way through their registration process. When I get a bit further, they'll tell me where I have to go to register properly. BTW, they have _two-level_ registration. Basic level, which you do by email only, gives you a certficate with a generic name. This lets you do digital signature and encryption, I guess, but doesn't authenticate an individual identity. It's like our community-membership thing. The second level, they call it "assurance", is where you show physical ID and that gets you a certficate for your personal identity. Interesting that the community identity has weaker protection than the personal identity. I guess this is because in _their_ model, more authorization is by personal identity than by community membership. On Fri, 2 Jul 2004, Clive Page wrote: > On Fri, 2 Jul 2004, Guy Rixon wrote: > > > > > I've just tried the "join CAcert link" at www.cacert.org. My browser (Firefox > > 0.9) reckons there's something dodgy about the site certificate for > > www.cacert.org itself. Not promising. > > Perhaps they issued their own certificate to themselves - recursivity may > imply dodginess in this field, I wouldn't know. > > Seriously though, it's the idea that free or at least non-profit CAs might > be set up that was the interesting idea. They appear to be based in > Boston, which as you say isn't the most convenient place to show one's > passport. On the other hand it looks as if many people flying in will get > themselves fingerprinted as well before long. > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > 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-grid@eso.org Fri Jul 2 17:05:15 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i62F4aLg015378 for ; Fri, 2 Jul 2004 17:04:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i62F4aBE015376 for grid-outgoing; Fri, 2 Jul 2004 17:04:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i62F4TLg015364 for ; Fri, 2 Jul 2004 17:04: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 i62DPJDP027877 for ; Fri, 2 Jul 2004 15:25:19 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:55315) by ppsw-9.csi.cam.ac.uk (old-ppsw.cam.ac.uk [131.111.8.3]:25) with esmtp (Exim 4.34) id 1BgO2Y-0000Ok-Fv; Fri, 02 Jul 2004 14:25:18 +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 i62DPImm006282; Fri, 2 Jul 2004 14:25:18 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i62DPIM1004675; Fri, 2 Jul 2004 14:25:18 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i62DPHmL004672; Fri, 2 Jul 2004 14:25:17 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 2 Jul 2004 14:25:17 +0100 (BST) From: Guy Rixon To: Clive Page cc: grid@ivoa.net Subject: Re: Free Certification Authority In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I've just tried the "join CAcert link" at www.cacert.org. My browser (Firefox 0.9) reckons there's something dodgy about the site certificate for www.cacert.org itself. Not promising. 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-grid@eso.org Tue Jul 6 10:19:24 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i668IxRS013686 for ; Tue, 6 Jul 2004 10:18:59 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i668Ixhx013685 for grid-outgoing; Tue, 6 Jul 2004 10:18:59 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i668IqRS013656 for ; Tue, 6 Jul 2004 10:18:52 +0200 (MEST) Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i668IpDP026868 for ; Tue, 6 Jul 2004 10:18:51 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:36080) by ppsw-3.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.143]:25) with esmtp (Exim 4.34) id 1BhlA8-0004Z6-Si for grid@ivoa.net; Tue, 06 Jul 2004 09:18:48 +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 i668Immm008128 for ; Tue, 6 Jul 2004 09:18:48 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i668IlM1009413 for ; Tue, 6 Jul 2004 09:18:47 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i668IlvM009410 for ; Tue, 6 Jul 2004 09:18:47 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 09:18:47 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Message protocol for SSO Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I've posted the message-protocol document for the SSO profile: http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-msg-protocol.html Significant changes since the original proposal: 1. The nonce is now in a wsu:Timestamp element instead of a wss:UsernameToken. UsernameToken is maybe not so appropriate since it implies an alternative authentication that we don't plan to support. wsu:Timestamp doesn't normally contain wss:Nonce but is extensible (contains an Any), so can be used. 2. I've dropped SAML as an allowed type of warrant: X.509 is now the only option. This is because I don't understand enough of SAML to pick the right elements and SAML is a vast standard with gobbledegook documentation. If anybody can honestly tell us the "right" SAML elements to use, then we can put them in our profile. Otherwise, I suggest that we go with X.509 for now and return to SAML when best practice is known (or when the O'Reilly book comes out; post the ISBN if you know it's out already). The PKI document is to follow today or tomorrow. 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-grid@eso.org Tue Jul 6 10:34:05 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i668XiRS015763 for ; Tue, 6 Jul 2004 10:33:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i668Xi6c015762 for grid-outgoing; Tue, 6 Jul 2004 10:33:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i668XeRS015749 for ; Tue, 6 Jul 2004 10:33:41 +0200 (MEST) Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i668XdDP027579 for ; Tue, 6 Jul 2004 10:33:39 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:36973) by ppsw-3.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.143]:25) with esmtp (Exim 4.34) id 1BhlOS-0007lA-Fy for grid@ivoa.net; Tue, 06 Jul 2004 09:33:36 +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 i668Xamm008593 for ; Tue, 6 Jul 2004 09:33:36 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i668XaM1009432 for ; Tue, 6 Jul 2004 09:33:36 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i668XZ0I009429 for ; Tue, 6 Jul 2004 09:33:36 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 09:33:35 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Multiple sign-on Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dave Morris has rightly pointed out that our SSO scheme needs multiple sign-ons when the user uses privileges granted to accounts in different communities. I think we have multiple sign-on (MSO) geographically but not temporally: a user or his/her agent will need to talk to multiple communities once per session, but won't need to sign on again in the middle of a session. I have in mind that there can be multiple accounts, at different communities, for the same user identity. I.e. a user identity is not synonymous with and account name; rather, a user identity _has_ one or more accounts. It should then be possible to determine all accounts (plus hosting communities) for a given user id and to log in to them all at the same time. This can either be done by the user entering one password per community or by federating the communities: user logs into community A using a SSO password; communities B and C trust A as a CA; therefore, user's agent logs into B and C using the warrant got by logging in to A. In respect of "determining all accounts for a given user", we _could_ do this using the resource registry if users and accounts are registered resources. Please see http://wiki.astrogrid.org/bin/view/AG2/MaxRegistryUsage for a discussion of this. At the moment, I _like_ the idea of putting users in the resource registry...but it needs discussion to sort out the true strengths and weaknesses. Regards, 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-grid@eso.org Tue Jul 6 11:26:07 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i669PfRS022973 for ; Tue, 6 Jul 2004 11:25:42 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i669Pf2C022972 for grid-outgoing; Tue, 6 Jul 2004 11:25:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i669PaRS022949 for ; Tue, 6 Jul 2004 11:25:36 +0200 (MEST) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i669PYEQ006139 for ; Tue, 6 Jul 2004 11:25:34 +0200 (CEST) Message-Id: <200407060925.i669PYEQ006139@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1BhmCh-0007nI-Ca for grid@ivoa.net; Tue, 06 Jul 2004 10:25:31 +0100 Received: (qmail 12068 invoked from network); 6 Jul 2004 09:25:52 -0000 Received: from agproject.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 09:25:52 -0000 From: "Tony Linde" To: "'Guy Rixon'" , Subject: RE: Multiple sign-on Date: Tue, 6 Jul 2004 10:25:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRjNlWs0xttfgAgSaOneSbtaVFmvAABFLfA X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think it would be fatal to assume multiple community accounts per user identity. Why on earth would we want it? The whole idea is to have a single identity/account and for that to be valid at all locations. The user will gather multiple privileges from belonging to multiple groups, not multiple communities. Belonging to a community will confer no privileges on a user. Just because I register my account through Leicester does not mean I have any rights over any data. I only gather those rights by being granted membership of various groups. MSO really must be avoided or we'll end up in a complete mess. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 06 July 2004 09:34 > To: grid@ivoa.net > Subject: Multiple sign-on > > Dave Morris has rightly pointed out that our SSO scheme needs > multiple sign-ons when the user uses privileges granted to > accounts in different communities. I think we have multiple > sign-on (MSO) geographically but not > temporally: a user or his/her agent will need to talk to > multiple communities once per session, but won't need to sign > on again in the middle of a session. > > I have in mind that there can be multiple accounts, at > different communities, for the same user identity. I.e. a > user identity is not synonymous with and account name; > rather, a user identity _has_ one or more accounts. > > It should then be possible to determine all accounts (plus hosting > communities) for a given user id and to log in to them all at > the same time. > This can either be done by the user entering one password per > community or by federating the communities: user logs into > community A using a SSO password; communities B and C trust A > as a CA; therefore, user's agent logs into B and C using the > warrant got by logging in to A. > > In respect of "determining all accounts for a given user", we > _could_ do this using the resource registry if users and > accounts are registered resources. > Please see > > http://wiki.astrogrid.org/bin/view/AG2/MaxRegistryUsage > > for a discussion of this. At the moment, I _like_ the idea > of putting users in the resource registry...but it needs > discussion to sort out the true strengths and weaknesses. > > Regards, > 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-grid@eso.org Tue Jul 6 13:17:38 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66BGuRS006065 for ; Tue, 6 Jul 2004 13:16:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66BGukN006064 for grid-outgoing; Tue, 6 Jul 2004 13:16:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66BGpRS006058 for ; Tue, 6 Jul 2004 13:16:52 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66BGoEQ010948 for ; Tue, 6 Jul 2004 13:16:50 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:47906) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1BhnwN-0001dp-3l for grid@ivoa.net; Tue, 06 Jul 2004 12:16:47 +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 i66BGkmm014028 for ; Tue, 6 Jul 2004 12:16:46 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66BGkM1009989 for ; Tue, 6 Jul 2004 12:16:46 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66BGjhs009986 for ; Tue, 6 Jul 2004 12:16:46 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 12:16:45 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: MSO and multiple communities Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: In light of Tony's last message, I ask the group whether we are to proceed with the abilities to have accounts at more than one community, to federate communities and to allow credentials for an SSO session to be collected from more than one server. If not, then the nature of the system is changed; some processes are simplified and some are made impossible. I don't mind changing tack if there is consensus, but I need to know which way we're going before I finish the SSO document-set. 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-grid@eso.org Tue Jul 6 14:24:56 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66CORRS014196 for ; Tue, 6 Jul 2004 14:24:27 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66COR1h014192 for grid-outgoing; Tue, 6 Jul 2004 14:24:27 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66COMRS014157 for ; Tue, 6 Jul 2004 14:24:22 +0200 (MEST) Received: from artemis.le.ac.uk (ntp2c.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66COKDP007571 for ; Tue, 6 Jul 2004 14:24:21 +0200 (CEST) Message-Id: <200407061224.i66COKDP007571@apollo.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1Bhozk-000532-3r for grid@ivoa.net; Tue, 06 Jul 2004 13:24:20 +0100 Received: (qmail 11951 invoked from network); 6 Jul 2004 12:24:42 -0000 Received: from agproject.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 12:24:42 -0000 From: "Tony Linde" To: "'Guy Rixon'" , Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 13:24:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRjT0Lyo6JT53HhQ66nDhBofPf/OgAA5rew X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Is there any reason why we would want to implement MSO? To my mind it adds nothing that cannot be achieved with groups since anyone can be made a member of a group regardless of the community to which they first registered. And it introduces the complexity of trying to recognise where multiple accounts belong to the same person and reconciling the privileges associated with each account. There won't be anything to stop a person having more than one account but if they do so they can only use the privileges associated with their sign-on account - under SSO that is. I suppose that if there is a later need for MSO recognised then it is something that can be added onto the VObs standards. But if we implement MSO, there'll be no going back to SSO - and it'll take a lot more to design it right and get it working I would have thought. Can anyone think of use cases which demonstrate an advantage to MSO? > to federate communities and to allow > credentials for an SSO session to be collected from more than > one server. How do these relate to SSO vs MSO? (My apologies if these have already been discussed - I've been tied up recently - point me at past threads if so.) Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 06 July 2004 12:17 > To: grid@ivoa.net > Subject: MSO and multiple communities > > In light of Tony's last message, I ask the group whether we > are to proceed with the abilities to have accounts at more > than one community, to federate communities and to allow > credentials for an SSO session to be collected from more than > one server. If not, then the nature of the system is changed; > some processes are simplified and some are made impossible. > > I don't mind changing tack if there is consensus, but I need > to know which way we're going before I finish the SSO document-set. > > 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-grid@eso.org Tue Jul 6 14:37:50 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66CbSRS015870 for ; Tue, 6 Jul 2004 14:37:28 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66CbRGV015867 for grid-outgoing; Tue, 6 Jul 2004 14:37:27 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66CbNRS015850 for ; Tue, 6 Jul 2004 14:37:24 +0200 (MEST) Received: from artemis.le.ac.uk (ntp2c.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66CbMDP008097 for ; Tue, 6 Jul 2004 14:37:22 +0200 (CEST) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1BhpCL-0005vJ-II for grid@ivoa.net; Tue, 06 Jul 2004 13:37:21 +0100 Received: (qmail 13128 invoked from network); 6 Jul 2004 12:37:43 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 12:37:43 -0000 Date: Tue, 6 Jul 2004 13:37:20 +0100 (BST) From: Clive Page To: grid@ivoa.net Subject: Re: MSO and multiple communities 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Guy Rixon wrote: > In light of Tony's last message, I ask the group whether we are to proceed > with the abilities to have accounts at more than one community, to federate > communities and to allow credentials for an SSO session to be collected from > more than one server. If not, then the nature of the system is changed; some > processes are simplified and some are made impossible. I think the last two postings appear to be at odds because of different shades of meaning attached to terms like group, community, and account. Surely the functionality requirements for SSO are now as clear (or at least as clear as anything in the VO): - User should only have to log on with a user-id and password only once per computer session, no matter how many sites, at home or abroad, to which the user has privileged access. Now I'm no expert on implementation, but I guess this could be done by the user having a digital certificate (issued by a UK Certification Authority) stored somewhere on the file system of all the computers he/she uses. The user obviously will have to log in *once* with a password at the start of a session with that computer, to some site which will confirm their identity (otherwise any other user of the same computer could impersonate them). Once authenticated, they presumably get some token (via a cookie mechanism?) which can be used elsewhere, indeed everywhere else that they have an account. If the user then access a site which is part of the Erewhon Virtual Observatory where they are part of a group (or community?) with special privileges, they should be able to use their existing UK digital certificate plus the session token to get access to their account without explicitly logging on, i.e. entering a password again. The Erewhon system recognises their digital certificate as identifying them as a member of some local Erewhon group, while the token says they have validly logged in someplace. This seems to conform to the usual security criterion that you use one thing you have (the certificate) as well as one thing you know (your password) for the initial log on. Of course this will only work if the Erewhon authorities recognise UK digital certificates and tokens; presumably (as with visa tit-for-tats) this will depend on the UK recognising the same for the citizens of what Guy means by a federated community. I don't see why it should not work, that that's more sociology than science. Using what I think I understand to be Guy's terminolgy, such a user still belongs only to a UK "community", but also belongs to a Erewhonian "group". The user has an "account" on at least one system in the UK and one in Erewhon, but only has to log on explicitly to one of these. Does this conform to Tony's requirements, and is it feasible? But this raises one extra question: does it have to be the local UK system that is the only one to generate a valid session token, or could the user log on first to Erewhon, and then use the token this generates to access a UK site? If the user's initial password is only decryptable on a UK authentication server, then I guess the user has to log on *first* to a system in the UK. Or is there some way around this? Another question: are these certificates issued per country, or per institution? If the former then I guess we want one PPARC-wide authentication server for us in the UK; if the latter, then a lot more federation and mutual recognition agreements have to be sorted out. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-grid@eso.org Tue Jul 6 14:44:01 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66ChhRS016707 for ; Tue, 6 Jul 2004 14:43:43 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66Chhc6016706 for grid-outgoing; Tue, 6 Jul 2004 14:43:43 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66ChcRS016696 for ; Tue, 6 Jul 2004 14:43:38 +0200 (MEST) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66ChaDP008360 for ; Tue, 6 Jul 2004 14:43:37 +0200 (CEST) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.30) id 1BhpIO-01jYAs-J2; Tue, 06 Jul 2004 13:43:36 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Tue, 6 Jul 2004 13:43:36 +0100 Date: Tue, 6 Jul 2004 13:43:36 +0100 (BST) From: Alasdair Allan To: Guy Rixon cc: grid@ivoa.net Subject: Re: MSO and multiple communities 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > In light of Tony's last message, I ask the group whether we are to > proceed with the abilities to have accounts at more than one community, > to federate communities and to allow credentials for an SSO session to > be collected from more than one server. If not, then the nature of the > system is changed; some processes are simplified and some are made > impossible. I think it's vital for one user "account" to be allowed to be a member of more than one community (think unix groups model here)... Al. -- Dr. A. Allan, School of Physics, University of Exeter From owner-grid@eso.org Tue Jul 6 14:52:39 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66CqCRS017975 for ; Tue, 6 Jul 2004 14:52:12 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66CqCoK017973 for grid-outgoing; Tue, 6 Jul 2004 14:52:12 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66Cq5RS017964 for ; Tue, 6 Jul 2004 14:52:06 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66Cq4DP008982 for ; Tue, 6 Jul 2004 14:52:04 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:55021) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1BhpQX-0006eV-V1; Tue, 06 Jul 2004 13:52:02 +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 i66Cq1mm017341; Tue, 6 Jul 2004 13:52:01 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66Cq1M1010369; Tue, 6 Jul 2004 13:52:01 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66Cq1Dh010366; Tue, 6 Jul 2004 13:52:01 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 13:52:01 +0100 (BST) From: Guy Rixon To: Tony Linde cc: grid@ivoa.net Subject: RE: MSO and multiple communities In-Reply-To: <200407061224.i66COPmm016411@cass41.ast.cam.ac.uk> Message-ID: References: <200407061224.i66COPmm016411@cass41.ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Pure SSO has a problem if service providers are picky about which communities they trust. Suppose user U joins community A. Service providers X and Y trust A, therefore accept requests from U(A). Service provider Z doesn't trust A but does trust community B. Therefore, U joins B as well and Z accepts requests from U(B). U then needs to combine X, Y and Z in one workflow and therefore needs to be U(A) and U(B) at the same time. On Tue, 6 Jul 2004, Tony Linde wrote: > Is there any reason why we would want to implement MSO? > > To my mind it adds nothing that cannot be achieved with groups since anyone > can be made a member of a group regardless of the community to which they > first registered. And it introduces the complexity of trying to recognise > where multiple accounts belong to the same person and reconciling the > privileges associated with each account. > > There won't be anything to stop a person having more than one account but if > they do so they can only use the privileges associated with their sign-on > account - under SSO that is. I suppose that if there is a later need for MSO > recognised then it is something that can be added onto the VObs standards. > But if we implement MSO, there'll be no going back to SSO - and it'll take a > lot more to design it right and get it working I would have thought. > > Can anyone think of use cases which demonstrate an advantage to MSO? > > > to federate communities and to allow > > credentials for an SSO session to be collected from more than > > one server. > > How do these relate to SSO vs MSO? (My apologies if these have already been > discussed - I've been tied up recently - point me at past threads if so.) > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > Behalf Of Guy Rixon > > Sent: 06 July 2004 12:17 > > To: grid@ivoa.net > > Subject: MSO and multiple communities > > > > In light of Tony's last message, I ask the group whether we > > are to proceed with the abilities to have accounts at more > > than one community, to federate communities and to allow > > credentials for an SSO session to be collected from more than > > one server. If not, then the nature of the system is changed; > > some processes are simplified and some are made impossible. > > > > I don't mind changing tack if there is consensus, but I need > > to know which way we're going before I finish the SSO document-set. > > > > 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 > > > 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-grid@eso.org Tue Jul 6 14:57:39 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66CvJRS018586 for ; Tue, 6 Jul 2004 14:57:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66CvJ5v018585 for grid-outgoing; Tue, 6 Jul 2004 14:57:19 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66CvFRS018580 for ; Tue, 6 Jul 2004 14:57:16 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66CvEDP009247 for ; Tue, 6 Jul 2004 14:57:14 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:55491) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1BhpVX-0007pk-CY; Tue, 06 Jul 2004 13:57:11 +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 i66Cupmm017533; Tue, 6 Jul 2004 13:57:03 +0100 (BST) Message-ID: <40EAA192.2080201@ast.cam.ac.uk> Date: Tue, 06 Jul 2004 13:56:50 +0100 From: Dave Morris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Grid and WebServices CC: Guy Rixon Subject: Re: MSO and multiple communities References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Dave Morris X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Both approaches have problems, and neither solves the complexity, it just moves it around. As you say, choosing one or the other makes some things simpler, and others much more complex. So far in AstroGrid Community, we have been working towards one globally unique Account, registered with a single Community. The Community service manages identity for Accounts registered with that Community. The Community service also manages membership of Groups registered with that Community. An Account (identity) is registered with one Community, but will be a member of multiple Groups at multiple Communities. Access rights are checked based on membership of groups (credentials). This is a rough outline of the kind of thing we were aiming for (some of this is out of date now). http://wiki.astrogrid.org/bin/view/Astrogrid/CrossCommunityPolicyChecking Would it work if a Community issued a warrant (certificate) when an Account joined a Group at that Community ? An Account would then have a primary identity certificate signed by their 'home' Community, to prove who they are, plus a set of membership certificates signed by other Communities to prove that they belong to Groups on those Communities. Dave Guy Rixon wrote: >In light of Tony's last message, I ask the group whether we are to proceed >with the abilities to have accounts at more than one community, to federate >communities and to allow credentials for an SSO session to be collected from >more than one server. If not, then the nature of the system is changed; some >processes are simplified and some are made impossible. > >I don't mind changing tack if there is consensus, but I need to know which >way we're going before I finish the SSO document-set. > >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-grid@eso.org Tue Jul 6 14:58:38 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66CwKRS018750 for ; Tue, 6 Jul 2004 14:58:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66CwKnU018746 for grid-outgoing; Tue, 6 Jul 2004 14:58:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66CwGRS018729 for ; Tue, 6 Jul 2004 14:58:16 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66CwEEQ015225 for ; Tue, 6 Jul 2004 14:58:14 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:55632) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1BhpWW-00086G-Lw; Tue, 06 Jul 2004 13:58:12 +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 i66CwBmm017632; Tue, 6 Jul 2004 13:58:11 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66CwBM1010377; Tue, 6 Jul 2004 13:58:11 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66CwBxZ010374; Tue, 6 Jul 2004 13:58:11 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 13:58:10 +0100 (BST) From: Guy Rixon To: Tony Linde cc: grid@ivoa.net Subject: RE: MSO and multiple communities In-Reply-To: <200407061224.i66COPmm016411@cass41.ast.cam.ac.uk> Message-ID: References: <200407061224.i66COPmm016411@cass41.ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Tony Linde wrote: > To my mind it adds nothing that cannot be achieved with groups since anyone > can be made a member of a group regardless of the community to which they > first registered. And it introduces the complexity of trying to recognise > where multiple accounts belong to the same person and reconciling the > privileges associated with each account. Possibly. But federating group membership across communities is about as difficult as federating community memberships directly. I don't see any finesse that makes it easier. If we say that a user can be in a group in a community but not actually in that community, then isn't a bit hard? 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-grid@eso.org Tue Jul 6 15:08:41 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66D8KRS020403 for ; Tue, 6 Jul 2004 15:08:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66D8KQE020401 for grid-outgoing; Tue, 6 Jul 2004 15:08:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66D8FRS020383 for ; Tue, 6 Jul 2004 15:08:15 +0200 (MEST) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66D8EDP009770 for ; Tue, 6 Jul 2004 15:08:14 +0200 (CEST) Message-Id: <200407061308.i66D8EDP009770@apollo.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhpgC-0004K4-W4 for grid@ivoa.net; Tue, 06 Jul 2004 14:08:12 +0100 Received: (qmail 16039 invoked from network); 6 Jul 2004 13:08:34 -0000 Received: from agproject.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 13:08:34 -0000 From: "Tony Linde" To: Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 14:08:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRjWT0CCa4VB2WGTLqXgMNaHJqscAAAKOPg X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > I think it's vital for one user "account" to be allowed to be > a member of more than one community (think unix groups model here)... I think that's the function of groups, not communities. A community means nothing, confers no privileges. It's the same as whether you register a resource at one regsitry or another, it means nothing apart from the identifer you end up with. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Alasdair Allan > Sent: 06 July 2004 13:44 > To: Guy Rixon > Cc: grid@ivoa.net > Subject: Re: MSO and multiple communities > > > > In light of Tony's last message, I ask the group whether we are to > > proceed with the abilities to have accounts at more than one > > community, to federate communities and to allow credentials > for an SSO > > session to be collected from more than one server. If not, then the > > nature of the system is changed; some processes are simplified and > > some are made impossible. > > I think it's vital for one user "account" to be allowed to be > a member of more than one community (think unix groups model here)... > > Al. > -- > Dr. A. Allan, School of Physics, University of Exeter > From owner-grid@eso.org Tue Jul 6 15:10:17 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66D9jRS020755 for ; Tue, 6 Jul 2004 15:09:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66D9iGX020754 for grid-outgoing; Tue, 6 Jul 2004 15:09:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66D9bRS020710 for ; Tue, 6 Jul 2004 15:09:37 +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 i66D9ZEQ015833 for ; Tue, 6 Jul 2004 15:09:35 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:56690) by ppsw-4.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.144]:25) with esmtp (Exim 4.34) id 1BhphT-0007GS-V5 for grid@ivoa.net; Tue, 06 Jul 2004 14:09:31 +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 i66D9Rmm018110; Tue, 6 Jul 2004 14:09:27 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66D9QM1010395; Tue, 6 Jul 2004 14:09:26 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66D9QTY010392; Tue, 6 Jul 2004 14:09:26 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 14:09:26 +0100 (BST) From: Guy Rixon To: Dave Morris cc: Grid and WebServices Subject: Re: MSO and multiple communities In-Reply-To: <40EAA192.2080201@ast.cam.ac.uk> Message-ID: References: <40EAA192.2080201@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Dave Morris wrote: > An Account (identity) is registered with one Community, but will be a > member of multiple Groups at multiple Communities. > Access rights are checked based on membership of groups (credentials). Ah. Terminology problem. I'm using "identity" and "account" as distinct terms. In the IVOA drafts I've written/am writing, I use "identity" to mean just a name. An identity can exist independently of any account in any community. When I write "account", I mean an arrangement between a user and a community that allows the user to request warrants from that community in respect of an agreed identity. You need an account in order to be able to authenticate. Authentication is done one the basis of accounts (because warrants are conencted with accounts). Authorization is done on the basis of identity, not account name. I think any user needs just one identity and at least one account. Sometimes, we may need to support multiple accounts per identity, in order to satisfy nervous service-providers. When a user registers at a community, the community can do one of two things: - create a new identity, and assign an account; - verify a given identity and assign a new account to that. The second one is what the national CAs do. > This is a rough outline of the kind of thing we were aiming for (some of > this is out of date now). > http://wiki.astrogrid.org/bin/view/Astrogrid/CrossCommunityPolicyChecking > > Would it work if a Community issued a warrant (certificate) when an > Account joined a Group at that Community ? > An Account would then have a primary identity certificate signed by > their 'home' Community, to prove who they are, plus a set of membership > certificates signed by other Communities to prove that they belong to > Groups on those Communities. Nearly. The warants are supposed to be short-lived, so the group warrants have to be collected at time of sign-on (start of each session). Therefore, one has to be able to find all the group-granting communities from the primary community. That's doable. > Dave > > Guy Rixon wrote: > > >In light of Tony's last message, I ask the group whether we are to proceed > >with the abilities to have accounts at more than one community, to federate > >communities and to allow credentials for an SSO session to be collected from > >more than one server. If not, then the nature of the system is changed; some > >processes are simplified and some are made impossible. > > > >I don't mind changing tack if there is consensus, but I need to know which > >way we're going before I finish the SSO document-set. > > > >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 > > > > > 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-grid@eso.org Tue Jul 6 15:15:13 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DEtRS021690 for ; Tue, 6 Jul 2004 15:14:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66DEtg3021689 for grid-outgoing; Tue, 6 Jul 2004 15:14:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DEpRS021668 for ; Tue, 6 Jul 2004 15:14:52 +0200 (MEST) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66DEoDP010200 for ; Tue, 6 Jul 2004 15:14:50 +0200 (CEST) Message-Id: <200407061314.i66DEoDP010200@apollo.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Bhpmb-0004g9-Lm for grid@ivoa.net; Tue, 06 Jul 2004 14:14:49 +0100 Received: (qmail 16830 invoked from network); 6 Jul 2004 13:15:10 -0000 Received: from agproject.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 13:15:10 -0000 From: "Tony Linde" To: Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 14:14:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRjWV5iq2wblaJCQymWlmujUTS1gQAAO/+g X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > Suppose user U joins community A. Service providers X and Y > trust A, therefore accept requests from U(A). Service I'm not sure I know what you mean by trust. I would have thought trust was to do with authentication. You authenticate yourself to the server to which you sign on and rely on that server being trusted by downstream servers. If you mean privileges, these reside in the groups. If a person is a member of a group then they have the privileges of that group. That may include access to data, storage rights at a given location etc. How a (data, storage, etc) service knows that it can trust some request that says that the person belongs to a privileged group is another issue, but it still has nothing to do with communities. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 06 July 2004 13:52 > To: Tony Linde > Cc: grid@ivoa.net > Subject: RE: MSO and multiple communities > > Pure SSO has a problem if service providers are picky about > which communities they trust. > > Suppose user U joins community A. Service providers X and Y > trust A, therefore accept requests from U(A). Service > provider Z doesn't trust A but does trust community B. > Therefore, U joins B as well and Z accepts requests from > U(B). U then needs to combine X, Y and Z in one workflow and > therefore needs to be U(A) and U(B) at the same time. > > > On Tue, 6 Jul 2004, Tony Linde wrote: > > > Is there any reason why we would want to implement MSO? > > > > To my mind it adds nothing that cannot be achieved with > groups since > > anyone can be made a member of a group regardless of the > community to > > which they first registered. And it introduces the complexity of > > trying to recognise where multiple accounts belong to the > same person > > and reconciling the privileges associated with each account. > > > > There won't be anything to stop a person having more than > one account > > but if they do so they can only use the privileges associated with > > their sign-on account - under SSO that is. I suppose that > if there is > > a later need for MSO recognised then it is something that > can be added onto the VObs standards. > > But if we implement MSO, there'll be no going back to SSO - > and it'll > > take a lot more to design it right and get it working I > would have thought. > > > > Can anyone think of use cases which demonstrate an advantage to MSO? > > > > > to federate communities and to allow credentials for an > SSO session > > > to be collected from more than one server. > > > > How do these relate to SSO vs MSO? (My apologies if these > have already > > been discussed - I've been tied up recently - point me at > past threads > > if so.) > > > > Cheers, > > Tony. > > > > > -----Original Message----- > > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On Behalf Of > > > Guy Rixon > > > Sent: 06 July 2004 12:17 > > > To: grid@ivoa.net > > > Subject: MSO and multiple communities > > > > > > In light of Tony's last message, I ask the group whether > we are to > > > proceed with the abilities to have accounts at more than one > > > community, to federate communities and to allow > credentials for an > > > SSO session to be collected from more than one server. If > not, then > > > the nature of the system is changed; some processes are > simplified > > > and some are made impossible. > > > > > > I don't mind changing tack if there is consensus, but I > need to know > > > which way we're going before I finish the SSO document-set. > > > > > > 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 > > > > > > > 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-grid@eso.org Tue Jul 6 15:16:42 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DGORS021947 for ; Tue, 6 Jul 2004 15:16:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66DGOiT021946 for grid-outgoing; Tue, 6 Jul 2004 15:16:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DGLRS021934 for ; Tue, 6 Jul 2004 15:16:21 +0200 (MEST) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66DGJEQ016132 for ; Tue, 6 Jul 2004 15:16:19 +0200 (CEST) Message-Id: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Bhpo2-0004l8-MU for grid@ivoa.net; Tue, 06 Jul 2004 14:16:18 +0100 Received: (qmail 17017 invoked from network); 6 Jul 2004 13:16:40 -0000 Received: from agproject.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 13:16:40 -0000 From: "Tony Linde" To: Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 14:16:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRjWPOxZeG7T/3fTAG74PfT92EUsAAAmDlQ X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > If we say that a user can be in a group in a community but > not actually in that community, then isn't a bit hard? Why? The list of members in the group includes that user's account id. No? T. > -----Original Message----- > From: Guy Rixon [mailto:gtr@ast.cam.ac.uk] > Sent: 06 July 2004 13:58 > To: Tony Linde > Cc: grid@ivoa.net > Subject: RE: MSO and multiple communities > > On Tue, 6 Jul 2004, Tony Linde wrote: > > > To my mind it adds nothing that cannot be achieved with > groups since > > anyone can be made a member of a group regardless of the > community to > > which they first registered. And it introduces the complexity of > > trying to recognise where multiple accounts belong to the > same person > > and reconciling the privileges associated with each account. > > Possibly. But federating group membership across communities > is about as difficult as federating community memberships > directly. I don't see any finesse that makes it easier. > > If we say that a user can be in a group in a community but > not actually in that community, then isn't a bit hard? > > > 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-grid@eso.org Tue Jul 6 15:26:17 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DPrRS023553 for ; Tue, 6 Jul 2004 15:25:53 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66DPqSv023552 for grid-outgoing; Tue, 6 Jul 2004 15:25:52 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DPlRS023512 for ; Tue, 6 Jul 2004 15:25:48 +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 i66DPkEQ016578 for ; Tue, 6 Jul 2004 15:25:46 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:58013) by ppsw-4.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.144]:25) with esmtp (Exim 4.34) id 1BhpxA-0002hj-76; Tue, 06 Jul 2004 14:25:44 +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 i66DPimm018758; Tue, 6 Jul 2004 14:25:44 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66DPhM1010413; Tue, 6 Jul 2004 14:25:43 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66DPhet010410; Tue, 6 Jul 2004 14:25:43 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 14:25:43 +0100 (BST) From: Guy Rixon To: Tony Linde cc: grid@ivoa.net Subject: RE: MSO and multiple communities In-Reply-To: <200407061308.i66D8EDP009770@apollo.hq.eso.org> Message-ID: References: <200407061308.i66D8EDP009770@apollo.hq.eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Should communities, therefore, have a harvesting arrangement for user identities like the resource registry, such that every community knows about every user identity and knows the community where that identity originated? On Tue, 6 Jul 2004, Tony Linde wrote: > > I think it's vital for one user "account" to be allowed to be > > a member of more than one community (think unix groups model here)... > > I think that's the function of groups, not communities. A community means > nothing, confers no privileges. It's the same as whether you register a > resource at one regsitry or another, it means nothing apart from the > identifer you end up with. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > Behalf Of Alasdair Allan > > Sent: 06 July 2004 13:44 > > To: Guy Rixon > > Cc: grid@ivoa.net > > Subject: Re: MSO and multiple communities > > > > > > > In light of Tony's last message, I ask the group whether we are to > > > proceed with the abilities to have accounts at more than one > > > community, to federate communities and to allow credentials > > for an SSO > > > session to be collected from more than one server. If not, then the > > > nature of the system is changed; some processes are simplified and > > > some are made impossible. > > > > I think it's vital for one user "account" to be allowed to be > > a member of more than one community (think unix groups model here)... > > > > Al. > > -- > > Dr. A. Allan, School of Physics, University of Exeter > > > 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-grid@eso.org Tue Jul 6 15:32:13 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DViRS024737 for ; Tue, 6 Jul 2004 15:31:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66DVhcW024735 for grid-outgoing; Tue, 6 Jul 2004 15:31:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DVZRS024709 for ; Tue, 6 Jul 2004 15:31:35 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66DVXEQ016934 for ; Tue, 6 Jul 2004 15:31:33 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i66DVWi18908 for grid@ivoa.net; Tue, 6 Jul 2004 09:31:32 -0400 Date: Tue, 6 Jul 2004 09:31:32 -0400 From: "Wil O'Mullane" Cc: grid@ivoa.net Subject: Re: MSO and multiple communities Message-ID: <20040706093132.B8568@skysrv.pha.jhu.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gtr@ast.cam.ac.uk on Tue, Jul 06, 2004 at 12:16:45PM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: We need multiple accounts - we already have multiple accounts. SSO needs to federate the accounts a user has on multiple systems. The IVO (unlike AstroGrid) can not be a monolithic system where I get a single account for everything - this will just not work. I might have to have a single identity which each system maps to my account on that system - this is I believe what Guy is specing and what we agreed pretty much at Boston. wil On Tue, Jul 06, 2004 at 12:16:45PM +0100, Guy Rixon wrote: > In light of Tony's last message, I ask the group whether we are to proceed > with the abilities to have accounts at more than one community, to federate > communities and to allow credentials for an SSO session to be collected from > more than one server. If not, then the nature of the system is changed; some > processes are simplified and some are made impossible. > > I don't mind changing tack if there is consensus, but I need to know which > way we're going before I finish the SSO document-set. > > 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-grid@eso.org Tue Jul 6 15:33:40 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DXDRS024939 for ; Tue, 6 Jul 2004 15:33:13 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66DXDpE024938 for grid-outgoing; Tue, 6 Jul 2004 15:33:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DX7RS024926 for ; Tue, 6 Jul 2004 15:33:07 +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 i66DX5DP011120 for ; Tue, 6 Jul 2004 15:33:06 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 8383944016; Tue, 6 Jul 2004 14:33:05 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 14323; Tue, 06 Jul 2004 14:33:04 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2F9A044011; Tue, 6 Jul 2004 14:33:04 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Tue, 6 Jul 2004 14:33:04 +0100 (BST) Received: from dial.pipex.com (IFA19P.roe.ac.uk [195.194.122.26]) by katrine.roe.ac.uk (Postfix) with ESMTP id DE81244011; Tue, 6 Jul 2004 14:33:03 +0100 (BST) Message-ID: <40EAAA0F.7020105@dial.pipex.com> Date: Tue, 06 Jul 2004 14:33:03 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alasdair Allan Cc: grid@ivoa.net Subject: Re: MSO and multiple communities References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Alasdair Allan wrote: > I think it's vital for one user "account" to be allowed to be a member of > more than one community (think unix groups model here)... Or rather, it's vital for one user 'account' to be allowed to be a member of more than one group (just like unix group models... :-) Communities (I gather?) are to do with who issues the certificates; ie who trusts who. Groups are about permissions to do things once that trust has been established. I remember vaguely this discussion well over a year ago; it was going to be a real pain to try and make the *same* account work across different communities, which is why there are groups. Of course, things have changed since then... -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Tue Jul 6 15:40:08 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DdjRS025890 for ; Tue, 6 Jul 2004 15:39:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66Ddjnf025887 for grid-outgoing; Tue, 6 Jul 2004 15:39:45 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DdfRS025870 for ; Tue, 6 Jul 2004 15:39:41 +0200 (MEST) 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 i66DddDP011388 for ; Tue, 6 Jul 2004 15:39:39 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:59510) by ppsw-4.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.144]:25) with esmtp (Exim 4.34) id 1BhqAa-0005ei-4N; Tue, 06 Jul 2004 14:39:36 +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 i66DdLmm019439; Tue, 6 Jul 2004 14:39:22 +0100 (BST) Message-ID: <40EAAB85.1030908@ast.cam.ac.uk> Date: Tue, 06 Jul 2004 14:39:17 +0100 From: Dave Morris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Grid and WebServices Subject: Re: MSO and multiple communities References: <40EAA192.2080201@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Dave Morris X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: >>Would it work if a Community issued a warrant (certificate) when an >>Account joined a Group at that Community ? >>An Account would then have a primary identity certificate signed by >>their 'home' Community, to prove who they are, plus a set of membership >>certificates signed by other Communities to prove that they belong to >>Groups on those Communities. >> >> > >Nearly. The warants are supposed to be short-lived, so the group warrants >have to be collected at time of sign-on (start of each session). Therefore, >one has to be able to find all the group-granting communities from the primary >community. That's doable. > > Yep, if a Community for an Account keeps a list of Groups that that Account is a member of, then it can use this to get the membership warrants. Could even be delayed, and only done when a warrant is required. Client service could keep a cache of membership warrants for this session, and only call the remote Communitites when it needs to prove group membership. This avoids a message storm of warrant requests when a user logs in to check the news pages. However, there is a useability problem with this model. a) The user needs to be aware of what membership warrants are required for which actions and selects them when designing a workflow. b) All the membership warrants are sent with every message (message bloat - a 2 line status request may end up with 50+ warrants in the header). c) The system works it all out - a complex problem that we havn't solved yet (particularly if workflow execution can dynamically swap between equivalent services based on availability etc.) Dave From owner-grid@eso.org Tue Jul 6 15:53:43 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DrHRS027603 for ; Tue, 6 Jul 2004 15:53:17 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66DrHCN027601 for grid-outgoing; Tue, 6 Jul 2004 15:53:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DrBRS027588 for ; Tue, 6 Jul 2004 15:53:11 +0200 (MEST) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66DrADP011938 for ; Tue, 6 Jul 2004 15:53:10 +0200 (CEST) Message-Id: <200407061353.i66DrADP011938@apollo.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhqN7-0006gr-ES for grid@ivoa.net; Tue, 06 Jul 2004 14:52:33 +0100 Received: (qmail 23027 invoked from network); 6 Jul 2004 13:52:55 -0000 Received: from agproject.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 13:52:55 -0000 From: "Tony Linde" To: Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 14:52:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040706093132.B8568@skysrv.pha.jhu.edu> Thread-Index: AcRjXu0mZ8GU2ETSS5ikEaQDvmARGgAAJJ/A X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > We need multiple accounts - we already have multiple accounts. > SSO needs to federate the accounts a user has on multiple systems. No, yes, no :) > The IVO (unlike AstroGrid) can not be a monolithic system AstroGrid is not a single system at all but a set of separate components working according to set interfaces - the IVO in fact. > where I get a single account for everything - this will just not work. I think there's confusion about accounts and groups. What you mean by accounts, I mean by groups. Groups confer privileges, not accounts. Having an account gives you no rights whatever. Only by being granted membership of certain groups do you gain the rights of those groups. > I might have to have a single identity which each system maps That is what I mean by an account. > to my account on that system - this is I believe what Guy is No. A service confers access rights to a group. A user who is joined to that group gets the rights conferred on that group. It doesn't matter to which community the user originally registered or anything else. If the administrator of a group adds the user to that group then that user has those rights. We absolutely do not want a proliferation of accounts on every server around the world. T. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Wil O'Mullane > Sent: 06 July 2004 14:32 > Cc: grid@ivoa.net > Subject: Re: MSO and multiple communities > > We need multiple accounts - we already have multiple accounts. > SSO needs to federate the accounts a user has on multiple systems. > The IVO (unlike AstroGrid) can not be a monolithic system > where I get a single account for everything - this will just not work. > I might have to have a single identity which each system maps > to my account on that system - this is I believe what Guy is > specing and what we agreed pretty much at Boston. > > wil > > > On Tue, Jul 06, 2004 at 12:16:45PM +0100, Guy Rixon wrote: > > In light of Tony's last message, I ask the group whether we are to > > proceed with the abilities to have accounts at more than one > > community, to federate communities and to allow credentials > for an SSO > > session to be collected from more than one server. If not, then the > > nature of the system is changed; some processes are > simplified and some are made impossible. > > > > I don't mind changing tack if there is consensus, but I > need to know > > which way we're going before I finish the SSO document-set. > > > > 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-grid@eso.org Tue Jul 6 15:54:08 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DroRS027747 for ; Tue, 6 Jul 2004 15:53:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66DroF1027746 for grid-outgoing; Tue, 6 Jul 2004 15:53:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DrjRS027733 for ; Tue, 6 Jul 2004 15:53:45 +0200 (MEST) 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 i66DriDP011968 for ; Tue, 6 Jul 2004 15:53:44 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:60588) by ppsw-4.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.144]:25) with esmtp (Exim 4.34) id 1BhqOD-0000Gb-Bx for grid@ivoa.net; Tue, 06 Jul 2004 14:53:41 +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 i66Dramm019960; Tue, 6 Jul 2004 14:53:36 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66DraM1010445; Tue, 6 Jul 2004 14:53:36 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66Drar5010442; Tue, 6 Jul 2004 14:53:36 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 14:53:36 +0100 (BST) From: Guy Rixon To: Dave Morris cc: Grid and WebServices Subject: Re: MSO and multiple communities In-Reply-To: <40EAAB85.1030908@ast.cam.ac.uk> Message-ID: References: <40EAA192.2080201@ast.cam.ac.uk> <40EAAB85.1030908@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Dave Morris wrote: > Guy Rixon wrote: > > >>Would it work if a Community issued a warrant (certificate) when an > >>Account joined a Group at that Community ? > >>An Account would then have a primary identity certificate signed by > >>their 'home' Community, to prove who they are, plus a set of membership > >>certificates signed by other Communities to prove that they belong to > >>Groups on those Communities. > > > >Nearly. The warants are supposed to be short-lived, so the group warrants > >have to be collected at time of sign-on (start of each session). Therefore, > >one has to be able to find all the group-granting communities from the primary > >community. That's doable. > > > > > Yep, if a Community for an Account keeps a list of Groups that that > Account is a member of, then it can use this to get the membership warrants. > Could even be delayed, and only done when a warrant is required. > Client service could keep a cache of membership warrants for this > session, and only call the remote Communitites when it needs to prove > group membership. > This avoids a message storm of warrant requests when a user logs in to > check the news pages. > > However, there is a useability problem with this model. > a) The user needs to be aware of what membership warrants are required > for which actions and selects them when designing a workflow. This would be a policy look-up on the registry. > b) All the membership warrants are sent with every message (message > bloat - a 2 line status request may end up with 50+ warrants in the header). A good reason for using X.509 instead of SAML - much more compact. > c) The system works it all out - a complex problem that we havn't solved > yet (particularly if workflow execution can dynamically swap between > equivalent services based on availability etc.) (d) Back to the pull model: service knows which groups are relevant (because service has internal authorization tables mapping groups to privileges) and which communities host which groups (because it looked them up when setting up its authZ tables); so service pulls the warrants required from the community services. Pro: minimized warrants sent to service. Con: service has to interact with many communities at time of call; all must be up and there are more (but smaller) messages. Con: user agent has to associate the same key pair with all the communities => user agent has to log in to each community at the start of the session => use ragent has to know which communities are relevant. > 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-grid@eso.org Tue Jul 6 15:56:41 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66DuLRS028116 for ; Tue, 6 Jul 2004 15:56:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66DuLK1028114 for grid-outgoing; Tue, 6 Jul 2004 15:56:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66DuFRS028099 for ; Tue, 6 Jul 2004 15:56:16 +0200 (MEST) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66DuEEQ018131 for ; Tue, 6 Jul 2004 15:56:14 +0200 (CEST) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhqQ5-0006rI-JA for grid@ivoa.net; Tue, 06 Jul 2004 14:55:37 +0100 Received: (qmail 23425 invoked from network); 6 Jul 2004 13:55:29 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 13:55:29 -0000 Date: Tue, 6 Jul 2004 14:55:06 +0100 (BST) From: Clive Page To: Guy Rixon cc: Tony Linde , , Martin Hill , Dave Morris , , Subject: RE: MSO and multiple communities 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think this discussion is getting very confused because (1) We are all using the same words but meaning completely different things by them, especially: account, community, group, user, log-in, warrant, certificate, maybe token. And which is a member of which. (2) There's a delay of 15 to 30 minutes or more on the ivoa mail server, so messages cross frequently, tangling replies. Please can somebody post the IVOA WG agreed meaning of the terms, if such exists? Only then can we start to have a rational discussion. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-grid@eso.org Tue Jul 6 16:04:25 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66E45RS029417 for ; Tue, 6 Jul 2004 16:04:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66E45I8029416 for grid-outgoing; Tue, 6 Jul 2004 16:04:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66E3xRS029390 for ; Tue, 6 Jul 2004 16:03:59 +0200 (MEST) Received: from msslty.mssl.ucl.ac.uk (msslty.mssl.ucl.ac.uk [128.40.71.164]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66E3vEQ018453 for ; Tue, 6 Jul 2004 16:03:58 +0200 (CEST) Received: from alpha2.mssl.ucl.ac.uk (msslai.mssl.ucl.ac.uk [128.40.71.160]) by msslty.mssl.ucl.ac.uk (8.12.10/8.12.10) with ESMTP id i66E3oTf004005 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 6 Jul 2004 15:03:50 +0100 Received: from localhost by alpha2.mssl.ucl.ac.uk (8.12.9/1.1.29.3/18Jun03-0405PM) id i66E3oI31239395; Tue, 6 Jul 2004 15:03:50 +0100 (BST) X-Authentication-Warning: msslai.mssl.ucl.ac.uk: kmb owned process doing -bs Date: Tue, 6 Jul 2004 15:03:49 +0100 (BST) From: Kevin Benson To: Guy Rixon cc: Tony Linde , Subject: RE: MSO and multiple communities In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MSSL-MailScanner-Information: Please contact the ISP for more information X-MSSL-MailScanner: No virus found X-MSSL-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 5, BAYES_00 -4.90) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Kevin Benson X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Thought I would give out this web site that deals with the same type of problems we are dealing with. It seems the web site has came along way since I last viewed it (many months ago). And originally did not give you any benefit dealing with web services, but most of the information we are asking about and debating on they tend to address. Unfortunately it seems to use SAML. http://www.sourceid.org Cheers, Kevin p.s. And to my bit on Guy's question, not certain, but I would say "yes" you might want harvesting, or we may have to keep asking the original community about a particular identity. On Tue, 6 Jul 2004, Guy Rixon wrote: > Should communities, therefore, have a harvesting arrangement for user > identities like the resource registry, such that every community knows about > every user identity and knows the community where that identity originated? > > > On Tue, 6 Jul 2004, Tony Linde wrote: > > > > I think it's vital for one user "account" to be allowed to be > > > a member of more than one community (think unix groups model here)... > > > > I think that's the function of groups, not communities. A community means > > nothing, confers no privileges. It's the same as whether you register a > > resource at one regsitry or another, it means nothing apart from the > > identifer you end up with. > > > > Cheers, > > Tony. > > > > > -----Original Message----- > > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > > Behalf Of Alasdair Allan > > > Sent: 06 July 2004 13:44 > > > To: Guy Rixon > > > Cc: grid@ivoa.net > > > Subject: Re: MSO and multiple communities > > > > > > > > > > In light of Tony's last message, I ask the group whether we are to > > > > proceed with the abilities to have accounts at more than one > > > > community, to federate communities and to allow credentials > > > for an SSO > > > > session to be collected from more than one server. If not, then the > > > > nature of the system is changed; some processes are simplified and > > > > some are made impossible. > > > > > > I think it's vital for one user "account" to be allowed to be > > > a member of more than one community (think unix groups model here)... > > > > > > Al. > > > -- > > > Dr. A. Allan, School of Physics, University of Exeter > > > > > > > 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-grid@eso.org Tue Jul 6 16:08:26 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66E7oRS029939 for ; Tue, 6 Jul 2004 16:07:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66E7oRO029936 for grid-outgoing; Tue, 6 Jul 2004 16:07:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66E7eRS029907 for ; Tue, 6 Jul 2004 16:07:40 +0200 (MEST) Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66E7aDP012675 for ; Tue, 6 Jul 2004 16:07:37 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:61592) by ppsw-5.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.145]:25) with esmtp (Exim 4.34) id 1Bhqbf-0001AB-37; Tue, 06 Jul 2004 15:07:35 +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 i66E7Ymm020434; Tue, 6 Jul 2004 15:07:34 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66E7YM1010463; Tue, 6 Jul 2004 15:07:34 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66E7YG1010460; Tue, 6 Jul 2004 15:07:34 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 15:07:34 +0100 (BST) From: Guy Rixon To: Tony Linde cc: grid@ivoa.net Subject: RE: MSO and multiple communities In-Reply-To: <200407061314.i66DEoDP010200@apollo.hq.eso.org> Message-ID: References: <200407061314.i66DEoDP010200@apollo.hq.eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Tony Linde wrote: > > Suppose user U joins community A. Service providers X and Y > > trust A, therefore accept requests from U(A). Service > > I'm not sure I know what you mean by trust. > > I would have thought trust was to do with authentication. You authenticate > yourself to the server to which you sign on and rely on that server being > trusted by downstream servers. Yes. > If you mean privileges, these reside in the groups. If a person is a member > of a group then they have the privileges of that group. That may include > access to data, storage rights at a given location etc. Yes. > How a (data, storage, etc) service knows that it can trust some request that > says that the person belongs to a privileged group is another issue, but it > still has nothing to do with communities. No. In the proposed model, the community is the certficate authority. The service provider has to trust the operation of the CA in order to accept that CA's warrants _during authentication_. If the service provider doesn't trust a community's CA then authentication fails. In fact, there are three distinct trust relationships between service S and community CA C: 1. S trusts C; 2. S does not know C; 3. S actively distrusts C (thinks C's security is broken). From owner-grid@eso.org Tue Jul 6 16:16:59 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66EGdRS001373 for ; Tue, 6 Jul 2004 16:16:40 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66EGdMM001372 for grid-outgoing; Tue, 6 Jul 2004 16:16:39 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66EGXRS001350 for ; Tue, 6 Jul 2004 16:16:33 +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 i66EGVEQ018901 for ; Tue, 6 Jul 2004 16:16:32 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:62271) by ppsw-5.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.145]:25) with esmtp (Exim 4.34) id 1BhqkG-0003CQ-71; Tue, 06 Jul 2004 15:16: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 i66EGSmm020777; Tue, 6 Jul 2004 15:16:28 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66EGRM1010478; Tue, 6 Jul 2004 15:16:27 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66EGRcH010475; Tue, 6 Jul 2004 15:16:27 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 15:16:27 +0100 (BST) From: Guy Rixon To: Tony Linde cc: grid@ivoa.net Subject: RE: MSO and multiple communities In-Reply-To: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> Message-ID: References: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Tony Linde wrote: > > If we say that a user can be in a group in a community but > > not actually in that community, then isn't a bit hard? > > Why? The list of members in the group includes that user's account id. No? Suppose my identity is in community C1 and my group is in C2. My target service trusts C2 but not C1. I can sign in to C2, to get the group warrant in two ways: 1. directly, without reference to C1; 2. indirectly, by signing in to C1 and having C1 get the warrant from C2. In case 1, the identity registration in C1 has no purpose, since I dont use it to get the warrant. In case 2, C2 is betraying S's trust because it is making its own security dependent on the security at C1, which S distrusts. From owner-grid@eso.org Tue Jul 6 16:18:19 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66EHsRS001581 for ; Tue, 6 Jul 2004 16:17:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66EHsIG001579 for grid-outgoing; Tue, 6 Jul 2004 16:17:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66EHoRS001564 for ; Tue, 6 Jul 2004 16:17:50 +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 i66EHmEQ018945 for ; Tue, 6 Jul 2004 16:17:49 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:62368) by ppsw-5.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.145]:25) with esmtp (Exim 4.34) id 1Bhql6-0003QT-GO; Tue, 06 Jul 2004 15:17: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 i66EH7mm020800; Tue, 6 Jul 2004 15:17:11 +0100 (BST) Message-ID: <40EAB462.3050108@ast.cam.ac.uk> Date: Tue, 06 Jul 2004 15:17:06 +0100 From: Dave Morris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Tony Linde , grid@ivoa.net Subject: Re: MSO and multiple communities References: <200407061308.i66D8EDP009770@apollo.hq.eso.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Dave Morris X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: >Should communities, therefore, have a harvesting arrangement for user >identities like the resource registry, such that every community knows about >every user identity and knows the community where that identity originated? > > No need for a harvest, all you need to know is where to lookup the information you want. This is one of the reasons why AstroGrid has the Community ident as part of the Account ident. eg ivo://ast.cam.ac.uk/community is the ivo identifier for a registered Community service ivo://ast.cam.ac.uk/community#dave is the identifier for an Account in that Community. If you want to check the certificates or group membership for ivo://ast.cam.ac.uk/community#dave ask the Community service at ivo://ast.cam.ac.uk/community It also solves the globally unique naming problem, 'dave' is not unique, but add the community identifier and 'ivo://ast.cam.ac.uk/community#dave' is a globally unique identifier. Each community service can manage the names within its space, without having to check the whole Vo for conflicting names. The group membership information does not need to be globally replicated. If you are registered with the Community at Cambridge, then the Cambridge Community service can keep a list of groups you are a member of. If you are added to a Group at Leicester, then the Leicester Community keeps the 'authoritative' record of this, but it can call the Cambridge Community to update your membership list. Dave From owner-grid@eso.org Tue Jul 6 16:18:39 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66EIKRS001663 for ; Tue, 6 Jul 2004 16:18:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66EIKGn001649 for grid-outgoing; Tue, 6 Jul 2004 16:18:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66EIDRS001613 for ; Tue, 6 Jul 2004 16:18:14 +0200 (MEST) Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66EICDP013168 for ; Tue, 6 Jul 2004 16:18:12 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:62448) by ppsw-5.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.145]:25) with esmtp (Exim 4.34) id 1Bhqlt-0003co-AW; Tue, 06 Jul 2004 15:18:09 +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 i66EI5mm020853; Tue, 6 Jul 2004 15:18:05 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66EI4M1010485; Tue, 6 Jul 2004 15:18:04 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66EI4s1010482; Tue, 6 Jul 2004 15:18:04 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 15:18:04 +0100 (BST) From: Guy Rixon To: Clive Page cc: Tony Linde , grid@ivoa.net, Martin Hill , Dave Morris , aa@astro.ex.ac.uk, womullan@skysrv.pha.jhu.edu Subject: RE: MSO and multiple communities In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Clive, please see http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-introduction.htm for the most-formal description of IVOA usage so far. G. On Tue, 6 Jul 2004, Clive Page wrote: > I think this discussion is getting very confused because > > (1) We are all using the same words but meaning completely different > things by them, especially: account, community, group, user, > log-in, warrant, certificate, maybe token. And which is a member of > which. > > (2) There's a delay of 15 to 30 minutes or more on the ivoa mail server, > so messages cross frequently, tangling replies. > > Please can somebody post the IVOA WG agreed meaning of the terms, if such > exists? Only then can we start to have a rational discussion. > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, > Leicester, LE1 7RH, U.K. > > > > 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-grid@eso.org Tue Jul 6 16:29:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66ESZRS003535 for ; Tue, 6 Jul 2004 16:28:35 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66ESYN0003533 for grid-outgoing; Tue, 6 Jul 2004 16:28:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66ESMRS003498 for ; Tue, 6 Jul 2004 16:28:23 +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 i66ESKEQ019472 for ; Tue, 6 Jul 2004 16:28:20 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:63220) by ppsw-5.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.145]:25) with esmtp (Exim 4.34) id 1BhqvZ-0006PJ-0P for grid@ivoa.net; Tue, 06 Jul 2004 15:28:09 +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 i66ES8mm021250 for ; Tue, 6 Jul 2004 15:28:08 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66ES8M1010496 for ; Tue, 6 Jul 2004 15:28:08 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66ES81O010493 for ; Tue, 6 Jul 2004 15:28:08 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 15:28:07 +0100 (BST) From: Guy Rixon To: Grid and WebServices Subject: Re: MSO and multiple communities In-Reply-To: Message-ID: References: <40EAA192.2080201@ast.cam.ac.uk> <40EAAB85.1030908@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Let's clear something up. Hands up all those who think that service providers to the IVO are required to accept identity warrants from any community CA inside the IVO. Hands up those who think that providers will actually do this. If we get this kind of universal trust, then we can have true SSO while still having multiple communities. If not, then we automatically some form of MSO and _nothing_ we can do changes that without breaking the integrity of the system. I reiterate: if user U is registered at communities C1 and C2, and if service S trusts C1 and distrusts C2, then C1 _cannot_ rightfully act as a sign-on proxy for groups in C2 when talking to S. U _must_, somehow, sign on separately to C1 and C2. On Tue, 6 Jul 2004, Guy Rixon wrote: > On Tue, 6 Jul 2004, Dave Morris wrote: > > > Guy Rixon wrote: > > > > >>Would it work if a Community issued a warrant (certificate) when an > > >>Account joined a Group at that Community ? > > >>An Account would then have a primary identity certificate signed by > > >>their 'home' Community, to prove who they are, plus a set of membership > > >>certificates signed by other Communities to prove that they belong to > > >>Groups on those Communities. > > > > > >Nearly. The warants are supposed to be short-lived, so the group warrants > > >have to be collected at time of sign-on (start of each session). Therefore, > > >one has to be able to find all the group-granting communities from the primary > > >community. That's doable. > > > > > > > > Yep, if a Community for an Account keeps a list of Groups that that > > Account is a member of, then it can use this to get the membership warrants. > > Could even be delayed, and only done when a warrant is required. > > Client service could keep a cache of membership warrants for this > > session, and only call the remote Communitites when it needs to prove > > group membership. > > This avoids a message storm of warrant requests when a user logs in to > > check the news pages. > > > > However, there is a useability problem with this model. > > a) The user needs to be aware of what membership warrants are required > > for which actions and selects them when designing a workflow. > > This would be a policy look-up on the registry. > > > b) All the membership warrants are sent with every message (message > > bloat - a 2 line status request may end up with 50+ warrants in the header). > > A good reason for using X.509 instead of SAML - much more compact. > > > c) The system works it all out - a complex problem that we havn't solved > > yet (particularly if workflow execution can dynamically swap between > > equivalent services based on availability etc.) > > > (d) Back to the pull model: service knows which groups are relevant (because > service has internal authorization tables mapping groups to privileges) and > which communities host which groups (because it looked them up when setting > up its authZ tables); so service pulls the warrants required from the > community services. > > Pro: minimized warrants sent to service. > > Con: service has to interact with many communities at time of call; > all must be up and there are more (but smaller) messages. > > Con: user agent has to associate the same key pair with all the communities > => user agent has to log in to each community at the start of the session > => use ragent has to know which communities are relevant. > > > 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-grid@eso.org Tue Jul 6 16:39:00 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66EcSRS005256 for ; Tue, 6 Jul 2004 16:38:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66EcSkN005254 for grid-outgoing; Tue, 6 Jul 2004 16:38:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66EcNRS005238 for ; Tue, 6 Jul 2004 16:38:23 +0200 (MEST) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66EcMEQ019965 for ; Tue, 6 Jul 2004 16:38:22 +0200 (CEST) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Bhr5N-00014S-Tc for grid@ivoa.net; Tue, 06 Jul 2004 15:38:17 +0100 Received: (qmail 29048 invoked from network); 6 Jul 2004 14:38:39 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 14:38:39 -0000 Date: Tue, 6 Jul 2004 15:38:17 +0100 (BST) From: Clive Page To: Grid and WebServices Subject: Re: MSO and multiple communities 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Guy Rixon wrote: > Let's clear something up. > > Hands up all those who think that service providers to the IVO are required to > accept identity warrants from any community CA inside the IVO. Yes; if they don't then the IVO hardly exists except in name. > Hands up those who think that providers will actually do this. Yes; I grant you that's a greater leap of faith, but I don't see why not. All they are trusting is that the foreign CA works properly aren't they? And compared with present practice, in which they mostly trust user-id/password pairs mostly sent by email, this is going to much more secure. And after all, it's not money we're talking about, it's just astronomical data. The intrinsic value is about zero. We need to keep a sense of proportion. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-grid@eso.org Tue Jul 6 16:48:17 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66EliRS006505 for ; Tue, 6 Jul 2004 16:47:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66EliAH006503 for grid-outgoing; Tue, 6 Jul 2004 16:47:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66ElcRS006488 for ; Tue, 6 Jul 2004 16:47:39 +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 i66ElaEQ020336 for ; Tue, 6 Jul 2004 16:47:37 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:64769) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (Exim 4.34) id 1BhrEH-000458-TL; Tue, 06 Jul 2004 15:47:29 +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 i66ElPmm021961; Tue, 6 Jul 2004 15:47:25 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66ElOM1010527; Tue, 6 Jul 2004 15:47:24 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66ElOIm010524; Tue, 6 Jul 2004 15:47:24 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 15:47:24 +0100 (BST) From: Guy Rixon To: Clive Page cc: Tony Linde , grid@ivoa.net, Martin Hill , Dave Morris , aa@astro.ex.ac.uk, womullan@skysrv.pha.jhu.edu Subject: RE: MSO and multiple communities In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Actually, I'm half-way through writing the document that explains some of this... buts shall go no further sinceI don't think that document will be accepted now. Shall I, instead, revise the SSO introduction with a glossary that defnes these terms? I can do that quickly, if it helps. On Tue, 6 Jul 2004, Clive Page wrote: > I think this discussion is getting very confused because > > (1) We are all using the same words but meaning completely different > things by them, especially: account, community, group, user, > log-in, warrant, certificate, maybe token. And which is a member of > which. > > (2) There's a delay of 15 to 30 minutes or more on the ivoa mail server, > so messages cross frequently, tangling replies. > > Please can somebody post the IVOA WG agreed meaning of the terms, if such > exists? Only then can we start to have a rational discussion. > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, > Leicester, LE1 7RH, U.K. > > > > 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-grid@eso.org Tue Jul 6 16:50:34 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66EoGRS006871 for ; Tue, 6 Jul 2004 16:50:16 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66EoGKP006869 for grid-outgoing; Tue, 6 Jul 2004 16:50:16 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66EoCRS006854 for ; Tue, 6 Jul 2004 16:50:12 +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 i66EoAEQ020463 for ; Tue, 6 Jul 2004 16:50:10 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:64951) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (Exim 4.34) id 1BhrGq-0004dm-4i; Tue, 06 Jul 2004 15:50:08 +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 i66Enwmm022035; Tue, 6 Jul 2004 15:49:59 +0100 (BST) Message-ID: <40EABC16.1090909@ast.cam.ac.uk> Date: Tue, 06 Jul 2004 15:49:58 +0100 From: Dave Morris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Grid and WebServices Subject: Re: MSO and multiple communities References: <40EAA192.2080201@ast.cam.ac.uk> <40EAAB85.1030908@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Dave Morris X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: >>However, there is a useability problem with this model. >>a) The user needs to be aware of what membership warrants are required >>for which actions and selects them when designing a workflow. >> >> > >This would be a policy look-up on the registry. > > Yep, not a technical problem, more of a useability one, the user ends up having to deal with permissions, certificates and stuff that the Vo should be hiding. For a simple query to one data center this is straightforward, but it gets very messy very quickly for a complex workflow that may invoke other nested sub-workflows. The user does not want to fiddle with all of this stuff each time they design a workflow, they just want to concentrate on the science and get the system to work out the plumbing for them. >Pro: minimized warrants sent to service. > >Con: service has to interact with many communities at time of call; >all must be up and there are more (but smaller) messages. > > Yep, I havn't figured out a way to avoid this. As long as the messages are small and the response is quick, then is this really a problem ? This is the model that AstroGrid is working on at the moment, until we come up with a better one. >Con: user agent has to associate the same key pair with all the communities >=> user agent has to log in to each community at the start of the session >=> use ragent has to know which communities are relevant. > > Not sure what you mean here. Dave From owner-grid@eso.org Tue Jul 6 16:58:15 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66EvrRS008008 for ; Tue, 6 Jul 2004 16:57:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66Evr3C008007 for grid-outgoing; Tue, 6 Jul 2004 16:57:53 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66EvmRS007982 for ; Tue, 6 Jul 2004 16:57:48 +0200 (MEST) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66EvkDP014733 for ; Tue, 6 Jul 2004 16:57:47 +0200 (CEST) Message-Id: <200407061457.i66EvkDP014733@apollo.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhrOD-0002H8-TL for grid@ivoa.net; Tue, 06 Jul 2004 15:57:45 +0100 Received: (qmail 1346 invoked from network); 6 Jul 2004 14:58:07 -0000 Received: from agproject.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 14:58:07 -0000 From: "Tony Linde" To: "'Grid and WebServices'" Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 15:57:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRjZhfHfzXdy5xOReOfyPujkbFh/QAAZ6lA X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: If a user has to hunt around finding different communities to register accounts with before they can achieve anything useful with the the IVO then the IVO will have failed. We must find a way that a user can simply construct a workflow consisting of several jobs, having first made sure that they have the relevant authorisations through group membership (1), and then expect that workflow to run through to completion. That is the requirement. Making every user set up an account with every community which manages groups they are joined to (and groups that those groups are joined to? and ...) will simply not work. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 06 July 2004 15:28 > To: Grid and WebServices > Subject: Re: MSO and multiple communities > > Let's clear something up. > > Hands up all those who think that service providers to the > IVO are required to accept identity warrants from any > community CA inside the IVO. Hands up those who think that > providers will actually do this. > > If we get this kind of universal trust, then we can have true > SSO while still having multiple communities. If not, then we > automatically some form of MSO and _nothing_ we can do > changes that without breaking the integrity of the system. > > I reiterate: if user U is registered at communities C1 and > C2, and if service S trusts C1 and distrusts C2, then C1 > _cannot_ rightfully act as a sign-on proxy for groups in C2 > when talking to S. U _must_, somehow, sign on separately to > C1 and C2. > > On Tue, 6 Jul 2004, Guy Rixon wrote: > > > On Tue, 6 Jul 2004, Dave Morris wrote: > > > > > Guy Rixon wrote: > > > > > > >>Would it work if a Community issued a warrant > (certificate) when > > > >>an Account joined a Group at that Community ? > > > >>An Account would then have a primary identity > certificate signed > > > >>by their 'home' Community, to prove who they are, plus a set of > > > >>membership certificates signed by other Communities to > prove that > > > >>they belong to Groups on those Communities. > > > > > > > >Nearly. The warants are supposed to be short-lived, so > the group > > > >warrants have to be collected at time of sign-on (start of each > > > >session). Therefore, one has to be able to find all the > > > >group-granting communities from the primary community. > That's doable. > > > > > > > > > > > Yep, if a Community for an Account keeps a list of Groups > that that > > > Account is a member of, then it can use this to get the > membership warrants. > > > Could even be delayed, and only done when a warrant is required. > > > Client service could keep a cache of membership warrants for this > > > session, and only call the remote Communitites when it needs to > > > prove group membership. > > > This avoids a message storm of warrant requests when a > user logs in > > > to check the news pages. > > > > > > However, there is a useability problem with this model. > > > a) The user needs to be aware of what membership warrants are > > > required for which actions and selects them when > designing a workflow. > > > > This would be a policy look-up on the registry. > > > > > b) All the membership warrants are sent with every > message (message > > > bloat - a 2 line status request may end up with 50+ > warrants in the header). > > > > A good reason for using X.509 instead of SAML - much more compact. > > > > > c) The system works it all out - a complex problem that we havn't > > > solved yet (particularly if workflow execution can > dynamically swap > > > between equivalent services based on availability etc.) > > > > > > (d) Back to the pull model: service knows which groups are relevant > > (because service has internal authorization tables mapping > groups to > > privileges) and which communities host which groups > (because it looked > > them up when setting up its authZ tables); so service pulls the > > warrants required from the community services. > > > > Pro: minimized warrants sent to service. > > > > Con: service has to interact with many communities at time of call; > > all must be up and there are more (but smaller) messages. > > > > Con: user agent has to associate the same key pair with all the > > communities => user agent has to log in to each community > at the start > > of the session => use ragent has to know which communities > are relevant. > > > > > 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-grid@eso.org Tue Jul 6 16:58:22 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66EvqRS007996 for ; Tue, 6 Jul 2004 16:57:52 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66Evq1Y007995 for grid-outgoing; Tue, 6 Jul 2004 16:57:52 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66EvmRS007983 for ; Tue, 6 Jul 2004 16:57:49 +0200 (MEST) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66EvlDP014735 for ; Tue, 6 Jul 2004 16:57:47 +0200 (CEST) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhrOE-0002HG-FA for grid@ivoa.net; Tue, 06 Jul 2004 15:57:46 +0100 Received: (qmail 1348 invoked from network); 6 Jul 2004 14:58:07 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 14:58:07 -0000 Date: Tue, 6 Jul 2004 15:57:45 +0100 (BST) From: Clive Page To: Guy Rixon cc: Tony Linde , , Martin Hill , Dave Morris , , Subject: RE: MSO and multiple communities 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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Guy Rixon wrote: > Actually, I'm half-way through writing the document that explains some of > this... buts shall go no further sinceI don't think that document will be > accepted now. > > Shall I, instead, revise the SSO introduction with a glossary that defnes > these terms? I can do that quickly, if it helps. I think that would help the discussion by avoiding confusion over terminology. For what it's worth, I think your SSO proposal looks the best that I've seen so far. The single-sign-on idea may indeed fall down if some services distrust some CAs; in that case I don't see any way that a user will be able to use that service without signing on again using a CA or something that it _does_ trust. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-grid@eso.org Tue Jul 6 17:00:39 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66F0GRS008445 for ; Tue, 6 Jul 2004 17:00:16 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66F0GPf008441 for grid-outgoing; Tue, 6 Jul 2004 17:00:16 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66F0ARS008424 for ; Tue, 6 Jul 2004 17:00: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 i66F08DP014828 for ; Tue, 6 Jul 2004 17:00:08 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:33192) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (Exim 4.34) id 1BhrQO-0006vv-OV for grid@ivoa.net; Tue, 06 Jul 2004 16:00:00 +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 i66Exumm022501; Tue, 6 Jul 2004 15:59:56 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66ExtM1010548; Tue, 6 Jul 2004 15:59:55 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66Extwd010545; Tue, 6 Jul 2004 15:59:55 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 15:59:55 +0100 (BST) From: Guy Rixon To: Dave Morris cc: Grid and WebServices Subject: Re: MSO and multiple communities In-Reply-To: <40EABC16.1090909@ast.cam.ac.uk> Message-ID: References: <40EAA192.2080201@ast.cam.ac.uk> <40EAAB85.1030908@ast.cam.ac.uk> <40EABC16.1090909@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Dave Morris wrote: > Guy Rixon wrote: > > >>However, there is a useability problem with this model. > >>a) The user needs to be aware of what membership warrants are required > >>for which actions and selects them when designing a workflow. > >> > >> > > > >This would be a policy look-up on the registry. > > > > > Yep, not a technical problem, more of a useability one, Maybe not for end users. The user agent (e.g. web-portal session, not web browser) should hide this. End users don't see it. User-programmers might. > > [words about pull models for warrants] > > > Yep, I havn't figured out a way to avoid this. > As long as the messages are small and the response is quick, then is > this really a problem ? It's OK so long as the community services are rarely off-line. A bit of caching at the enquiring services might help. > >Con: user agent has to associate the same key pair with all the communities > >=> user agent has to log in to each community at the start of the session > >=> use ragent has to know which communities are relevant. > > > > > Not sure what you mean here. The message to the service is signed with a private key. The matching public key has to appear in all the warrants, otherwise they are not applicable to that message. That means that the user agent has to log in to all the communities at the start of the session and arrange to use the same public key for that session. It's not a showstopper. BTW, Shibboleth uses the pull system and we'd be part way to Shib compatability if we had one too. (Except that Shib uses SAML.) But Shibboleth has one big difference: it assumes that there is a user present with a web browser s.t. the system can prompt for sign-ons as needed. That doesn't work for our web services. 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-grid@eso.org Tue Jul 6 17:03:43 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66F3PRS009422 for ; Tue, 6 Jul 2004 17:03:25 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66F3P7R009420 for grid-outgoing; Tue, 6 Jul 2004 17:03:25 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66F3JRS009402 for ; Tue, 6 Jul 2004 17:03:20 +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 i66F3IDP014960 for ; Tue, 6 Jul 2004 17:03:18 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:33466) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (Exim 4.34) id 1BhrTX-0007k1-Fa; Tue, 06 Jul 2004 16:03:15 +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 i66F35mm022627; Tue, 6 Jul 2004 16:03:08 +0100 (BST) Message-ID: <40EABF29.5060406@ast.cam.ac.uk> Date: Tue, 06 Jul 2004 16:03:05 +0100 From: Dave Morris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Tony Linde , grid@ivoa.net Subject: Re: MSO and multiple communities References: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Dave Morris X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: >On Tue, 6 Jul 2004, Tony Linde wrote: > > > >>>If we say that a user can be in a group in a community but >>>not actually in that community, then isn't a bit hard? >>> >>> >>Why? The list of members in the group includes that user's account id. No? >> >> > >Suppose my identity is in community C1 and my group is in C2. My target >service trusts C2 but not C1. > If the service S does not trust your originating community C1, then you can't access the service. End of story. I'm not sure I see the problem though. It puts the responsibility on Community administrators to make their Communities trustworthy. Don't register with an insecure Community. Dave From owner-grid@eso.org Tue Jul 6 17:07:47 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66F7TRS010185 for ; Tue, 6 Jul 2004 17:07:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66F7T4m010184 for grid-outgoing; Tue, 6 Jul 2004 17:07:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66F7NRS010168 for ; Tue, 6 Jul 2004 17:07:23 +0200 (MEST) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66F7MDP015173 for ; Tue, 6 Jul 2004 17:07:22 +0200 (CEST) Message-Id: <200407061507.i66F7MDP015173@apollo.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhrXV-0002nB-8C for grid@ivoa.net; Tue, 06 Jul 2004 16:07:21 +0100 Received: (qmail 4105 invoked from network); 6 Jul 2004 15:07:42 -0000 Received: from agproject.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 15:07:42 -0000 From: "Tony Linde" To: Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 16:07:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <40EABF29.5060406@ast.cam.ac.uk> Thread-Index: AcRjamxtuwLMmHpQRluqQs2HaNWoDQAAHVZA X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > I'm not sure I see the problem though. > It puts the responsibility on Community administrators to > make their Communities trustworthy. > > Don't register with an insecure Community. Agreed. T. > -----Original Message----- > From: Dave Morris [mailto:dave@ast.cam.ac.uk] > Sent: 06 July 2004 16:03 > To: Guy Rixon > Cc: Tony Linde; grid@ivoa.net > Subject: Re: MSO and multiple communities > > Guy Rixon wrote: > > >On Tue, 6 Jul 2004, Tony Linde wrote: > > > > > > > >>>If we say that a user can be in a group in a community but not > >>>actually in that community, then isn't a bit hard? > >>> > >>> > >>Why? The list of members in the group includes that user's > account id. No? > >> > >> > > > >Suppose my identity is in community C1 and my group is in C2. My > >target service trusts C2 but not C1. > > > If the service S does not trust your originating community > C1, then you can't access the service. > End of story. > > I'm not sure I see the problem though. > It puts the responsibility on Community administrators to > make their Communities trustworthy. > > Don't register with an insecure Community. > > Dave > From owner-grid@eso.org Tue Jul 6 17:16:07 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66FFbRS011392 for ; Tue, 6 Jul 2004 17:15:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66FFbnC011391 for grid-outgoing; Tue, 6 Jul 2004 17:15:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66FFXRS011347 for ; Tue, 6 Jul 2004 17:15:33 +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 i66FFVEQ021579 for ; Tue, 6 Jul 2004 17:15:32 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:34652) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (Exim 4.34) id 1BhrfM-0001xl-Tb; Tue, 06 Jul 2004 16:15: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 i66FFOmm023189; Tue, 6 Jul 2004 16:15:24 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66FFOM1010567; Tue, 6 Jul 2004 16:15:24 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66FFOpj010564; Tue, 6 Jul 2004 16:15:24 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 16:15:24 +0100 (BST) From: Guy Rixon To: Dave Morris cc: Tony Linde , grid@ivoa.net Subject: Re: MSO and multiple communities In-Reply-To: <40EABF29.5060406@ast.cam.ac.uk> Message-ID: References: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> <40EABF29.5060406@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Dave Morris wrote: > Guy Rixon wrote: > > >On Tue, 6 Jul 2004, Tony Linde wrote: > > > > > > > >>>If we say that a user can be in a group in a community but > >>>not actually in that community, then isn't a bit hard? > >>> > >>> > >>Why? The list of members in the group includes that user's account id. No? > >> > >> > > > >Suppose my identity is in community C1 and my group is in C2. My target > >service trusts C2 but not C1. > > > If the service S does not trust your originating community C1, then you > can't access the service. > End of story. OK...in that case S only trusts a group warrant from C2 if the warrant is names an indivdual account, at some Ci and S also trusts Ci. I.e., the group warrant can't say 'the bearer of the public key xyz is a member of group G'; it has to say that 'the caller X is a member of group G provided that you can authenticate X as individual user I'. Possible, but we'd better be aware of the distinction. Also bear in mind that it's impossible to make a CA secure retroactively. You have to shut down the CA, kick all the miscreants out of the community (or have all the community members re-register), then rebuild all the remote groups and start over with a new CA with a new certficate. So we'd better start the communities off on a good footing. > I'm not sure I see the problem though. > It puts the responsibility on Community administrators to make their > Communities trustworthy. > > Don't register with an insecure Community. > > 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-grid@eso.org Tue Jul 6 17:27:06 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66FQjRS013180 for ; Tue, 6 Jul 2004 17:26:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66FQjne013179 for grid-outgoing; Tue, 6 Jul 2004 17:26:45 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66FQdRS013167 for ; Tue, 6 Jul 2004 17:26:40 +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 i66FQaDP016066 for ; Tue, 6 Jul 2004 17:26:36 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:35585) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (Exim 4.34) id 1Bhrq3-0004WP-En; Tue, 06 Jul 2004 16:26:31 +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 i66FQVmm023615; Tue, 6 Jul 2004 16:26:31 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66FQVM1010577; Tue, 6 Jul 2004 16:26:31 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66FQU80010574; Tue, 6 Jul 2004 16:26:30 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 16:26:30 +0100 (BST) From: Guy Rixon To: Tony Linde cc: "'Grid and WebServices'" Subject: RE: MSO and multiple communities In-Reply-To: <200407061457.i66EvkDP014733@apollo.hq.eso.org> Message-ID: References: <200407061457.i66EvkDP014733@apollo.hq.eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: In which case, see my last reply to Dave. Group warrants are therefore dependent on individual identity warrants. You can't authenticate group membership by having a group warrant and matching signature because the group warrant isn't associated with a registration; you have to get the individual identity out of the group warrant and authenticate that separately, using a separate warrant. We _still_ have a problem is a service doesn't trust your individual warrant. That now mean that you can not use that service at all, even if you have the group warrant. However, it does mean that group warrants can be given out without sign on, since they don't relate to key pairs. In fact, a group warrant probably isn't an X.509 certficate any more; it's something else we haven't designed yet. On Tue, 6 Jul 2004, Tony Linde wrote: > If a user has to hunt around finding different communities to register > accounts with before they can achieve anything useful with the the IVO then > the IVO will have failed. > > We must find a way that a user can simply construct a workflow consisting of > several jobs, having first made sure that they have the relevant > authorisations through group membership (1), and then expect that workflow > to run through to completion. That is the requirement. > > Making every user set up an account with every community which manages > groups they are joined to (and groups that those groups are joined to? and > ...) will simply not work. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > Behalf Of Guy Rixon > > Sent: 06 July 2004 15:28 > > To: Grid and WebServices > > Subject: Re: MSO and multiple communities > > > > Let's clear something up. > > > > Hands up all those who think that service providers to the > > IVO are required to accept identity warrants from any > > community CA inside the IVO. Hands up those who think that > > providers will actually do this. > > > > If we get this kind of universal trust, then we can have true > > SSO while still having multiple communities. If not, then we > > automatically some form of MSO and _nothing_ we can do > > changes that without breaking the integrity of the system. > > > > I reiterate: if user U is registered at communities C1 and > > C2, and if service S trusts C1 and distrusts C2, then C1 > > _cannot_ rightfully act as a sign-on proxy for groups in C2 > > when talking to S. U _must_, somehow, sign on separately to > > C1 and C2. > > > > On Tue, 6 Jul 2004, Guy Rixon wrote: > > > > > On Tue, 6 Jul 2004, Dave Morris wrote: > > > > > > > Guy Rixon wrote: > > > > > > > > >>Would it work if a Community issued a warrant > > (certificate) when > > > > >>an Account joined a Group at that Community ? > > > > >>An Account would then have a primary identity > > certificate signed > > > > >>by their 'home' Community, to prove who they are, plus a set of > > > > >>membership certificates signed by other Communities to > > prove that > > > > >>they belong to Groups on those Communities. > > > > > > > > > >Nearly. The warants are supposed to be short-lived, so > > the group > > > > >warrants have to be collected at time of sign-on (start of each > > > > >session). Therefore, one has to be able to find all the > > > > >group-granting communities from the primary community. > > That's doable. > > > > > > > > > > > > > > Yep, if a Community for an Account keeps a list of Groups > > that that > > > > Account is a member of, then it can use this to get the > > membership warrants. > > > > Could even be delayed, and only done when a warrant is required. > > > > Client service could keep a cache of membership warrants for this > > > > session, and only call the remote Communitites when it needs to > > > > prove group membership. > > > > This avoids a message storm of warrant requests when a > > user logs in > > > > to check the news pages. > > > > > > > > However, there is a useability problem with this model. > > > > a) The user needs to be aware of what membership warrants are > > > > required for which actions and selects them when > > designing a workflow. > > > > > > This would be a policy look-up on the registry. > > > > > > > b) All the membership warrants are sent with every > > message (message > > > > bloat - a 2 line status request may end up with 50+ > > warrants in the header). > > > > > > A good reason for using X.509 instead of SAML - much more compact. > > > > > > > c) The system works it all out - a complex problem that we havn't > > > > solved yet (particularly if workflow execution can > > dynamically swap > > > > between equivalent services based on availability etc.) > > > > > > > > > (d) Back to the pull model: service knows which groups are relevant > > > (because service has internal authorization tables mapping > > groups to > > > privileges) and which communities host which groups > > (because it looked > > > them up when setting up its authZ tables); so service pulls the > > > warrants required from the community services. > > > > > > Pro: minimized warrants sent to service. > > > > > > Con: service has to interact with many communities at time of call; > > > all must be up and there are more (but smaller) messages. > > > > > > Con: user agent has to associate the same key pair with all the > > > communities => user agent has to log in to each community > > at the start > > > of the session => use ragent has to know which communities > > are relevant. > > > > > > > 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-grid@eso.org Tue Jul 6 17:28:08 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66FRMRS013281 for ; Tue, 6 Jul 2004 17:27:22 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66FRMY6013279 for grid-outgoing; Tue, 6 Jul 2004 17:27:22 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66FRHRS013263 for ; Tue, 6 Jul 2004 17:27:17 +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 i66FRFEQ022025 for ; Tue, 6 Jul 2004 17:27:15 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:35633) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (Exim 4.34) id 1Bhrqf-0004fP-Vs; Tue, 06 Jul 2004 16:27:10 +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 i66FR4mm023640; Tue, 6 Jul 2004 16:27:04 +0100 (BST) Message-ID: <40EAC4C7.9070404@ast.cam.ac.uk> Date: Tue, 06 Jul 2004 16:27:03 +0100 From: Dave Morris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clive Page CC: Grid and WebServices Subject: Re: MSO and multiple communities References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Dave Morris X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Clive Page wrote: >.... And after all, it's not money we're talking about, it's just >astronomical data. The intrinsic value is about zero. We need to keep a >sense of proportion. > > > True, most services will be database providers, and most of the data is (semi) public. So access control on who is allowed to read the data does not need to be highly secure. However, access control on who is allowed to change the data needs to be more secure. In addition some services may allow control over remote instruments, telescopes rovers etc. For example see http://robotics.jpl.nasa.gov/people/jnorris/WITS-IEEEAS00.pdf " ... (the system) was used for generating command sequences for the lander's robotic arm and camera ...." In which case, these services will need a much higher level of access control and security. We are struggling to implement a single signon system that meets all of these conflicting requirements. Dave From owner-grid@eso.org Tue Jul 6 17:28:31 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66FSBRS013653 for ; Tue, 6 Jul 2004 17:28:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66FSBcs013651 for grid-outgoing; Tue, 6 Jul 2004 17:28:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66FS7RS013599 for ; Tue, 6 Jul 2004 17:28:07 +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 i66FS5DP016122 for ; Tue, 6 Jul 2004 17:28:05 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:35739) by ppsw-0.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.140]:25) with esmtp (Exim 4.34) id 1BhrrR-0004s9-Eb; Tue, 06 Jul 2004 16:27:57 +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 i66FRvmm023686; Tue, 6 Jul 2004 16:27:57 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66FRuM1010585; Tue, 6 Jul 2004 16:27:56 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66FRufS010582; Tue, 6 Jul 2004 16:27:56 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 16:27:56 +0100 (BST) From: Guy Rixon To: Tony Linde cc: grid@ivoa.net Subject: RE: MSO and multiple communities In-Reply-To: <200407061507.i66F7MDP015173@apollo.hq.eso.org> Message-ID: References: <200407061507.i66F7MDP015173@apollo.hq.eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: So not anything that grew from an AstroGrid-1 community, then? On Tue, 6 Jul 2004, Tony Linde wrote: > > I'm not sure I see the problem though. > > It puts the responsibility on Community administrators to > > make their Communities trustworthy. > > > > Don't register with an insecure Community. > > Agreed. > > T. > > > -----Original Message----- > > From: Dave Morris [mailto:dave@ast.cam.ac.uk] > > Sent: 06 July 2004 16:03 > > To: Guy Rixon > > Cc: Tony Linde; grid@ivoa.net > > Subject: Re: MSO and multiple communities > > > > Guy Rixon wrote: > > > > >On Tue, 6 Jul 2004, Tony Linde wrote: > > > > > > > > > > > >>>If we say that a user can be in a group in a community but not > > >>>actually in that community, then isn't a bit hard? > > >>> > > >>> > > >>Why? The list of members in the group includes that user's > > account id. No? > > >> > > >> > > > > > >Suppose my identity is in community C1 and my group is in C2. My > > >target service trusts C2 but not C1. > > > > > If the service S does not trust your originating community > > C1, then you can't access the service. > > End of story. > > > > I'm not sure I see the problem though. > > It puts the responsibility on Community administrators to > > make their Communities trustworthy. > > > > Don't register with an insecure Community. > > > > 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-grid@eso.org Tue Jul 6 17:35:48 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66FZRRS015421 for ; Tue, 6 Jul 2004 17:35:27 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66FZQDJ015419 for grid-outgoing; Tue, 6 Jul 2004 17:35:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66FZMRS015401 for ; Tue, 6 Jul 2004 17:35:22 +0200 (MEST) Received: from msslty.mssl.ucl.ac.uk (msslty.mssl.ucl.ac.uk [128.40.71.164]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66FZLEQ022382 for ; Tue, 6 Jul 2004 17:35:21 +0200 (CEST) Received: from msslai.mssl.ucl.ac.uk (msslai.mssl.ucl.ac.uk [128.40.71.160]) by msslty.mssl.ucl.ac.uk (8.12.10/8.12.10) with ESMTP id i66FZETf009194; Tue, 6 Jul 2004 16:35:14 +0100 Date: Tue, 6 Jul 2004 16:35:14 +0100 (BST) From: Elizabeth Auden To: Dave Morris cc: Clive Page , Grid and WebServices Subject: Re: MSO and multiple communities In-Reply-To: <40EAC4C7.9070404@ast.cam.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MSSL-MailScanner-Information: Please contact the ISP for more information X-MSSL-MailScanner: No virus found X-MSSL-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 5, BAYES_00 -4.90) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Elizabeth Auden X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > However, access control on who is allowed to change the data needs to be > more secure. Not to mention services that allow write access to a file system, store user-generated data in MySpace, or execute user-written code on remote processors. Elizabeth From owner-grid@eso.org Tue Jul 6 17:59:58 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66FxQRS019666 for ; Tue, 6 Jul 2004 17:59:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66FxQq7019665 for grid-outgoing; Tue, 6 Jul 2004 17:59:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66FxMRS019660 for ; Tue, 6 Jul 2004 17:59: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 i66FxJDP017749 for ; Tue, 6 Jul 2004 17:59:20 +0200 (CEST) Received: from SARA (roy-nat.cacr.caltech.edu [131.215.144.149]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i66FxIlk023518 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 6 Jul 2004 08:59:18 -0700 Message-ID: <047201c46372$757526d0$0c0ba8c0@cacr.caltech.edu> From: "Roy Williams" To: References: <200407061507.i66F7MDP015173@apollo.hq.eso.org> Subject: Re: MSO and multiple communities Date: Tue, 6 Jul 2004 09:01:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: What is there in the real world? There are credit cards! A User may own several credit cards: Visa, Mastercard, Amex, etc etc. Credit-card companies == Communities == Certificate Authorites. They *authenticate* users -- meaning knowing who they really are. There are lots of these already -- UK Grid, Verisign, Teragrid, etc etc. A Service-provider may take some credit cards but not others. My service will trust the Hungarian VO but not Astrogrid. A Group (within a Community) is like the type of card that you have (Platinum, Frequent-flyer miles, etc etc). That is what determines my credit limit -- it *authorizes* expenditure. The Warrant is like the temporary authorization that a hotel makes when you check in. It allows you to order room-service without showing your credit-card. Roy -------- California Institute of Technology roy@caltech.edu 626 395 3670 From owner-grid@eso.org Tue Jul 6 18:03:07 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66G2lRS020055 for ; Tue, 6 Jul 2004 18:02:47 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66G2lQd020054 for grid-outgoing; Tue, 6 Jul 2004 18:02:47 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66G2fRS020039 for ; Tue, 6 Jul 2004 18:02:41 +0200 (MEST) 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 i66G2dDP017860 for ; Tue, 6 Jul 2004 18:02:40 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:38638) by ppsw-4.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.144]:25) with esmtp (Exim 4.34) id 1BhsOy-0001n4-37; Tue, 06 Jul 2004 17:02:36 +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 i66G2Lmm025000; Tue, 6 Jul 2004 17:02:23 +0100 (BST) Message-ID: <40EACD0D.3010508@ast.cam.ac.uk> Date: Tue, 06 Jul 2004 17:02:21 +0100 From: Dave Morris User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Tony Linde , grid@ivoa.net Subject: Re: MSO and multiple communities References: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> <40EABF29.5060406@ast.cam.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Dave Morris X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: >OK...in that case S only trusts a group warrant from C2 if the warrant is >names an indivdual account, at some Ci and S also trusts Ci. I.e., the group >warrant can't say 'the bearer of the public key xyz is a member of group G'; >it has to say that 'the caller X is a member of group G provided that you >can authenticate X as individual user I'. Possible, but we'd better be aware >of the distinction. > > Yep. To call a service with identity I as a member of group G you would need two warrants. One from your home Community, Ch, to say 'this certifies the bearer is I' One from the Community, Cg, that manages the members of group G to say 'this certifies I is a member of the group G'. The service needs to trust both Ch and Cg. This may sound like a lot of work for the service developer and service provider. However, a lot of it can be off loaded to a (local) Community. If the service S trusts a (local) Community Cs, then when it recieves all of the warrants in a message, the service should be able to just bung the whole lot at the local Community service Cs and ask it 'is this lot valid ?'. The Community service can then work out the details, checking the group memberships are signed correctly etc. It means that if an institute provides multiple services, they only need to assign the trust relationships in one place. All of the local services trust Cs, and the administrator of Cs decides if they trust other Communities, Cx and Cy. Note, (local) is in brackets because it would normally be local to an Institute, but it could be a remote Community managed by someone else. Dave From owner-grid@eso.org Tue Jul 6 18:18:09 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66GHoRS021987 for ; Tue, 6 Jul 2004 18:17:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66GHofg021986 for grid-outgoing; Tue, 6 Jul 2004 18:17:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66GHkRS021978 for ; Tue, 6 Jul 2004 18:17:46 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66GHiDP018548 for ; Tue, 6 Jul 2004 18:17:45 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id JAA27622; Tue, 6 Jul 2004 09:16:26 -0700 (PDT) Date: Tue, 6 Jul 2004 09:16:26 -0700 (PDT) From: Matthew Graham To: Tony Linde cc: "'Grid and WebServices'" Subject: RE: MSO and multiple communities In-Reply-To: <200407061457.i66EvkDP014733@apollo.hq.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.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, > If a user has to hunt around finding different communities to register > accounts with before they can achieve anything useful with the the IVO then > the IVO will have failed. > > We must find a way that a user can simply construct a workflow consisting of > several jobs, having first made sure that they have the relevant > authorisations through group membership (1), and then expect that workflow > to run through to completion. That is the requirement. Consider the situation when the actual services used in the workflow are dynamically chosen; for example, if they are selected by discovery, i.e. querying a registry for the optimum service matching the requirements of the user. The model I have in mind is that the user creates an abstract representation of their workflow using a GUI, say, and the workflow engine then queries a registry to determine what is the optimal execution plan for the proposed workflow given that it is this user. The onus here is then not on the user to have selected which services to use but on the registry so that it can be queried on authorisation information - can this user use this service? Part of the instantiation process for the workflow would then be signing on to the various services - the user is at this stage making their cup of coffee so is not around to physically sign on themselves. Another scenario is what if the workflow engine is load balancing services so that it needs to change which particular implementation of a service it is using in mid-flow? The user will again not be around to issue a new sign-on. Cheers, Matthew From owner-grid@eso.org Tue Jul 6 18:31:07 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66GUlRS023200 for ; Tue, 6 Jul 2004 18:30:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66GUlEN023198 for grid-outgoing; Tue, 6 Jul 2004 18:30:47 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66GUhRS023178 for ; Tue, 6 Jul 2004 18:30:43 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66GUfDP018920 for ; Tue, 6 Jul 2004 18:30:42 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:41384) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1Bhsq7-00056r-GQ for grid@ivoa.net; Tue, 06 Jul 2004 17:30:39 +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 i66GUdmm026367 for ; Tue, 6 Jul 2004 17:30:39 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i66GUcM1010650 for ; Tue, 6 Jul 2004 17:30:38 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i66GUcBQ010647 for ; Tue, 6 Jul 2004 17:30:38 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 6 Jul 2004 17:30:38 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Re: MSO and multiple communities In-Reply-To: <40EACD0D.3010508@ast.cam.ac.uk> Message-ID: References: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> <40EABF29.5060406@ast.cam.ac.uk> <40EACD0D.3010508@ast.cam.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I have uploaded a new version of the SSO introduction at http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-introduction.htm This now has a glossary at the end giving detailed definitions of account, identity, community, warrant etc. The definitions take account of today's email discussions but clearly won't match evrybody's private glossary (otherwise there would have been no need for me to write them down). 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-grid@eso.org Tue Jul 6 19:51:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66HocRS029616 for ; Tue, 6 Jul 2004 19:50:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66Hochp029615 for grid-outgoing; Tue, 6 Jul 2004 19:50:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66HoYRS029610 for ; Tue, 6 Jul 2004 19:50:34 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66HoWEQ026984 for ; Tue, 6 Jul 2004 19:50:32 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i66HoTY25351; Tue, 6 Jul 2004 13:50:29 -0400 Date: Tue, 6 Jul 2004 13:50:29 -0400 From: "Wil O'Mullane" To: Guy Rixon Cc: Grid and WebServices Subject: Re: MSO and multiple communities Message-ID: <20040706135029.B18961@skysrv.pha.jhu.edu> References: <40EAA192.2080201@ast.cam.ac.uk> <40EAAB85.1030908@ast.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gtr@ast.cam.ac.uk on Tue, Jul 06, 2004 at 03:28:07PM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > Hands up all those who think that service providers to the IVO are required to > accept identity warrants from any community CA inside the IVO. Hands up those > who think that providers will actually do this. Two hand up. From owner-grid@eso.org Tue Jul 6 20:21:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66IKZRS002201 for ; Tue, 6 Jul 2004 20:20:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66IKZo9002200 for grid-outgoing; Tue, 6 Jul 2004 20:20:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66IKWRS002195 for ; Tue, 6 Jul 2004 20:20:32 +0200 (MEST) 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 i66IKTDP021911 for ; Tue, 6 Jul 2004 20:20:30 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i66IKTA26062 for grid@ivoa.net; Tue, 6 Jul 2004 14:20:29 -0400 Date: Tue, 6 Jul 2004 14:20:29 -0400 From: "Wil O'Mullane" Cc: "'Grid and WebServices'" Subject: Re: MSO and multiple communities Message-ID: <20040706142029.E18961@skysrv.pha.jhu.edu> References: <200407061457.i66EvkDP014733@apollo.hq.eso.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200407061457.i66EvkDP014733@apollo.hq.eso.org>; from ael@star.le.ac.uk on Tue, Jul 06, 2004 at 03:57:46PM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > > Making every user set up an account with every community which manages > groups they are joined to (and groups that those groups are joined to? and > ...) will simply not work. That was never implied - in the discussiosn we had in boston the agreement was that this would prbably be done behind the scenes. I will have an accoutn for each user on my system but I will create it the first time I see their identity > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > Behalf Of Guy Rixon > > Sent: 06 July 2004 15:28 > > To: Grid and WebServices > > Subject: Re: MSO and multiple communities > > > > Let's clear something up. > > > > Hands up all those who think that service providers to the > > IVO are required to accept identity warrants from any > > community CA inside the IVO. Hands up those who think that > > providers will actually do this. > > > > If we get this kind of universal trust, then we can have true > > SSO while still having multiple communities. If not, then we > > automatically some form of MSO and _nothing_ we can do > > changes that without breaking the integrity of the system. > > > > I reiterate: if user U is registered at communities C1 and > > C2, and if service S trusts C1 and distrusts C2, then C1 > > _cannot_ rightfully act as a sign-on proxy for groups in C2 > > when talking to S. U _must_, somehow, sign on separately to > > C1 and C2. > > > > On Tue, 6 Jul 2004, Guy Rixon wrote: > > > > > On Tue, 6 Jul 2004, Dave Morris wrote: > > > > > > > Guy Rixon wrote: > > > > > > > > >>Would it work if a Community issued a warrant > > (certificate) when > > > > >>an Account joined a Group at that Community ? > > > > >>An Account would then have a primary identity > > certificate signed > > > > >>by their 'home' Community, to prove who they are, plus a set of > > > > >>membership certificates signed by other Communities to > > prove that > > > > >>they belong to Groups on those Communities. > > > > > > > > > >Nearly. The warants are supposed to be short-lived, so > > the group > > > > >warrants have to be collected at time of sign-on (start of each > > > > >session). Therefore, one has to be able to find all the > > > > >group-granting communities from the primary community. > > That's doable. > > > > > > > > > > > > > > Yep, if a Community for an Account keeps a list of Groups > > that that > > > > Account is a member of, then it can use this to get the > > membership warrants. > > > > Could even be delayed, and only done when a warrant is required. > > > > Client service could keep a cache of membership warrants for this > > > > session, and only call the remote Communitites when it needs to > > > > prove group membership. > > > > This avoids a message storm of warrant requests when a > > user logs in > > > > to check the news pages. > > > > > > > > However, there is a useability problem with this model. > > > > a) The user needs to be aware of what membership warrants are > > > > required for which actions and selects them when > > designing a workflow. > > > > > > This would be a policy look-up on the registry. > > > > > > > b) All the membership warrants are sent with every > > message (message > > > > bloat - a 2 line status request may end up with 50+ > > warrants in the header). > > > > > > A good reason for using X.509 instead of SAML - much more compact. > > > > > > > c) The system works it all out - a complex problem that we havn't > > > > solved yet (particularly if workflow execution can > > dynamically swap > > > > between equivalent services based on availability etc.) > > > > > > > > > (d) Back to the pull model: service knows which groups are relevant > > > (because service has internal authorization tables mapping > > groups to > > > privileges) and which communities host which groups > > (because it looked > > > them up when setting up its authZ tables); so service pulls the > > > warrants required from the community services. > > > > > > Pro: minimized warrants sent to service. > > > > > > Con: service has to interact with many communities at time of call; > > > all must be up and there are more (but smaller) messages. > > > > > > Con: user agent has to associate the same key pair with all the > > > communities => user agent has to log in to each community > > at the start > > > of the session => use ragent has to know which communities > > are relevant. > > > > > > > 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-grid@eso.org Tue Jul 6 20:36:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66IZcRS005951 for ; Tue, 6 Jul 2004 20:35:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66IZcUU005950 for grid-outgoing; Tue, 6 Jul 2004 20:35:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66IZYRS005945 for ; Tue, 6 Jul 2004 20:35:34 +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 i66IZWEQ028081 for ; Tue, 6 Jul 2004 20:35:33 +0200 (CEST) Received: from SARA (roy-nat.cacr.caltech.edu [131.215.144.149]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i66IZSlk008073 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 6 Jul 2004 11:35:29 -0700 Message-ID: <055001c46388$46b38a10$0c0ba8c0@cacr.caltech.edu> From: "Roy Williams" To: "Wil O'Mullane" , "Guy Rixon" Cc: "Grid and WebServices" References: <40EAA192.2080201@ast.cam.ac.uk> <40EAAB85.1030908@ast.cam.ac.uk> <20040706135029.B18961@skysrv.pha.jhu.edu> Subject: Re: MSO and multiple communities Date: Tue, 6 Jul 2004 11:37:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > > Hands up all those who think that service providers to the IVO are required to > > accept identity warrants from any community CA inside the IVO. Hands up those > > who think that providers will actually do this. > Two hands up. For reading data, two hands up. For writing/deleting data, no hands up. From owner-grid@eso.org Tue Jul 6 23:12:23 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66LBpRS022126 for ; Tue, 6 Jul 2004 23:11:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66LBoKX022125 for grid-outgoing; Tue, 6 Jul 2004 23:11:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66LBlRS022116 for ; Tue, 6 Jul 2004 23:11:47 +0200 (MEST) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66LBjEQ003686 for ; Tue, 6 Jul 2004 23:11:46 +0200 (CEST) Message-Id: <200407062111.i66LBjEQ003686@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhxE8-0000Gj-UF for grid@ivoa.net; Tue, 06 Jul 2004 22:11:44 +0100 Received: (qmail 10643 invoked from network); 6 Jul 2004 21:12:06 -0000 Received: from agforum.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 21:12:06 -0000 From: "Tony Linde" To: Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 22:11:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRjeQk2Vcv7hSVMRfey9CjG/xlfgQAI8xRQ X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I've not had a chance to read the document but the descriptions in the glosary are complete and very useful. I certainly agree with the definitions but I would tend to conflate identity and account, assuming only one account per identity. I cannot think identity (as a single unique thing) has any meaning otherwise. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 06 July 2004 17:31 > To: grid@ivoa.net > Subject: Re: MSO and multiple communities > > I have uploaded a new version of the SSO introduction at > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-i ntroduction.htm > > This now has a glossary at the end giving detailed > definitions of account, identity, community, warrant etc. The > definitions take account of today's email discussions but > clearly won't match evrybody's private glossary (otherwise > there would have been no need for me to write them down). > > 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-grid@eso.org Tue Jul 6 23:21:06 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66LKkRS022771 for ; Tue, 6 Jul 2004 23:20:47 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66LKkAl022770 for grid-outgoing; Tue, 6 Jul 2004 23:20:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66LKgRS022763 for ; Tue, 6 Jul 2004 23:20:43 +0200 (MEST) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66LKfEQ003842 for ; Tue, 6 Jul 2004 23:20:41 +0200 (CEST) Message-Id: <200407062120.i66LKfEQ003842@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhxMm-0000Y6-2t for grid@ivoa.net; Tue, 06 Jul 2004 22:20:40 +0100 Received: (qmail 11477 invoked from network); 6 Jul 2004 21:21:01 -0000 Received: from agforum.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 21:21:01 -0000 From: "Tony Linde" To: "'Grid and WebServices'" Subject: RE: MSO and multiple communities Date: Tue, 6 Jul 2004 22:20:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <20040706142029.E18961@skysrv.pha.jhu.edu> Thread-Index: AcRjipuTm9pIepulR1+5pReTK6TzdAAE2IEA X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > I will have an accoutn for each user on my system but I will > create it the first time I see their identity So anyone who ever uses any data or software on your machine will get an account created - possibly 10000 plus of them. Why? If all you're going to do is create the accounts when you see the identity, why go to the bother? Why not just run the job anyway? Or are you going to add them to all the groups that your apps and data use to encompass privileges? And how are you going to recognise when people are added to and removed from groups? It isn't going to work. We've sold the IVO on the idea that anyone can get at any data anywhere. If you're going to manage that on the basis of every user who ever signs up to the IVO having an account on every system attached to the IVO, it simply wont work. It is like saying that I have to have an account on every http server in the world before I can browse the web. All the mechanics has to be transparent to the user and relatively simple to implement or it won't scale. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Wil O'Mullane > Sent: 06 July 2004 19:20 > Cc: 'Grid and WebServices' > Subject: Re: MSO and multiple communities > > > > > Making every user set up an account with every community > which manages > > groups they are joined to (and groups that those groups are > joined to? > > and > > ...) will simply not work. > That was never implied - in the discussiosn we had in boston > the agreement was that this would prbably be done behind the scenes. > I will have an accoutn for each user on my system but I will > create it the first time I see their identity > > > > > Cheers, > > Tony. > > > > > -----Original Message----- > > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On Behalf Of > > > Guy Rixon > > > Sent: 06 July 2004 15:28 > > > To: Grid and WebServices > > > Subject: Re: MSO and multiple communities > > > > > > Let's clear something up. > > > > > > Hands up all those who think that service providers to > the IVO are > > > required to accept identity warrants from any community CA inside > > > the IVO. Hands up those who think that providers will > actually do > > > this. > > > > > > If we get this kind of universal trust, then we can have true SSO > > > while still having multiple communities. If not, then we > > > automatically some form of MSO and _nothing_ we can do > changes that > > > without breaking the integrity of the system. > > > > > > I reiterate: if user U is registered at communities C1 > and C2, and > > > if service S trusts C1 and distrusts C2, then C1 _cannot_ > rightfully > > > act as a sign-on proxy for groups in C2 when talking to S. U > > > _must_, somehow, sign on separately to > > > C1 and C2. > > > > > > On Tue, 6 Jul 2004, Guy Rixon wrote: > > > > > > > On Tue, 6 Jul 2004, Dave Morris wrote: > > > > > > > > > Guy Rixon wrote: > > > > > > > > > > >>Would it work if a Community issued a warrant > > > (certificate) when > > > > > >>an Account joined a Group at that Community ? > > > > > >>An Account would then have a primary identity > > > certificate signed > > > > > >>by their 'home' Community, to prove who they are, > plus a set > > > > > >>of membership certificates signed by other Communities to > > > prove that > > > > > >>they belong to Groups on those Communities. > > > > > > > > > > > >Nearly. The warants are supposed to be short-lived, so > > > the group > > > > > >warrants have to be collected at time of sign-on > (start of each > > > > > >session). Therefore, one has to be able to find all the > > > > > >group-granting communities from the primary community. > > > That's doable. > > > > > > > > > > > > > > > > > Yep, if a Community for an Account keeps a list of Groups > > > that that > > > > > Account is a member of, then it can use this to get the > > > membership warrants. > > > > > Could even be delayed, and only done when a warrant > is required. > > > > > Client service could keep a cache of membership warrants for > > > > > this session, and only call the remote Communitites when it > > > > > needs to prove group membership. > > > > > This avoids a message storm of warrant requests when a > > > user logs in > > > > > to check the news pages. > > > > > > > > > > However, there is a useability problem with this model. > > > > > a) The user needs to be aware of what membership warrants are > > > > > required for which actions and selects them when > > > designing a workflow. > > > > > > > > This would be a policy look-up on the registry. > > > > > > > > > b) All the membership warrants are sent with every > > > message (message > > > > > bloat - a 2 line status request may end up with 50+ > > > warrants in the header). > > > > > > > > A good reason for using X.509 instead of SAML - much > more compact. > > > > > > > > > c) The system works it all out - a complex problem that we > > > > > havn't solved yet (particularly if workflow execution can > > > dynamically swap > > > > > between equivalent services based on availability etc.) > > > > > > > > > > > > (d) Back to the pull model: service knows which groups are > > > > relevant (because service has internal authorization tables > > > > mapping > > > groups to > > > > privileges) and which communities host which groups > > > (because it looked > > > > them up when setting up its authZ tables); so service pulls the > > > > warrants required from the community services. > > > > > > > > Pro: minimized warrants sent to service. > > > > > > > > Con: service has to interact with many communities at time of > > > > call; all must be up and there are more (but smaller) messages. > > > > > > > > Con: user agent has to associate the same key pair with all the > > > > communities => user agent has to log in to each community > > > at the start > > > > of the session => use ragent has to know which communities > > > are relevant. > > > > > > > > > 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-grid@eso.org Wed Jul 7 00:28:42 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66MSKm8028420 for ; Wed, 7 Jul 2004 00:28:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66MSKVY028419 for grid-outgoing; Wed, 7 Jul 2004 00:28:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66MSHm8028413 for ; Wed, 7 Jul 2004 00:28:17 +0200 (MEST) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i66MSEEQ005196 for ; Wed, 7 Jul 2004 00:28:14 +0200 (CEST) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1BhyQ5-0002PB-TG for grid@ivoa.net; Tue, 06 Jul 2004 23:28:09 +0100 Received: (qmail 16156 invoked from network); 6 Jul 2004 22:28:31 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 6 Jul 2004 22:28:31 -0000 Date: Tue, 6 Jul 2004 23:28:08 +0100 (BST) From: Clive Page To: Roy Williams cc: grid@ivoa.net Subject: Re: MSO and multiple communities In-Reply-To: <047201c46372$757526d0$0c0ba8c0@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: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 6 Jul 2004, Roy Williams wrote: > What is there in the real world? There are credit cards! Roy et al I was thinking of posting something on the banking analogy too. Only I thought of two slightly different aspects: (1) You need an account to do most things at a bank branch, and to get an account you need to authenticate yourself quite carefully the first time (needs passport and utility bills in the UK now, typically). The main exceptions are things like changing one currency for another: here banks don't care who you are, as they take a percentage of each transaction. In a similar way we need to ensure that some VO services remain account-free, e.g. reading non-proprietary data. (2) Cashcards and ATMs are almost universal - it is rare to visit a country where your plastic card can't get money from a hole in the wall machine. How: there is a world-wide cryptographic algorithm embedded in a chip in the machine, with a self-destruct mechanism if anyone tampers with it. The encoding algorithm is known to many banks and allows them to issue PINs. So a combination of your digital certificate (= the magnetic stripe of the card) and your password (=PIN entered on the keypad) are a reasonable guarantee of your right to withdraw cash. Not 100% foolproof, but losses are a tiny fraction of the amounts transferred. Note also that cash machines are designed to work off-line (though mostly now they are permanently on-line) - similarly it would be nice if our authentication mechanisms didn't all fail of some network links were faulty. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-grid@eso.org Wed Jul 7 01:22:58 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i66NMbm8001637 for ; Wed, 7 Jul 2004 01:22:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i66NMbkJ001636 for grid-outgoing; Wed, 7 Jul 2004 01:22:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i66NMWm8001631 for ; Wed, 7 Jul 2004 01:22:33 +0200 (MEST) 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 i66NMUDP000170 for ; Wed, 7 Jul 2004 01:22:31 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i66NLpX31462; Tue, 6 Jul 2004 19:21:51 -0400 Date: Tue, 6 Jul 2004 19:21:51 -0400 From: "Wil O'Mullane" To: Tony Linde Cc: "'Grid and WebServices'" Subject: Re: MSO and multiple communities Message-ID: <20040706192151.M18961@skysrv.pha.jhu.edu> References: <20040706142029.E18961@skysrv.pha.jhu.edu> <200407062120.i66LKfEQ003842@rocky.hq.eso.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200407062120.i66LKfEQ003842@rocky.hq.eso.org>; from ael@star.le.ac.uk on Tue, Jul 06, 2004 at 10:20:39PM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: we do not need accounts or certificates for the simple jobs so no not necessarily for all 10k users but for the perhaps1k who want a more sophisticated service yes If i really do not need to identify users then why are we doing this at all we do not need security or certificates On Tue, Jul 06, 2004 at 10:20:39PM +0100, Tony Linde wrote: > > I will have an accoutn for each user on my system but I will > > create it the first time I see their identity > > So anyone who ever uses any data or software on your machine will get an > account created - possibly 10000 plus of them. Why? If all you're going to > do is create the accounts when you see the identity, why go to the bother? > Why not just run the job anyway? Or are you going to add them to all the > groups that your apps and data use to encompass privileges? And how are you > going to recognise when people are added to and removed from groups? It > isn't going to work. > > We've sold the IVO on the idea that anyone can get at any data anywhere. If > you're going to manage that on the basis of every user who ever signs up to > the IVO having an account on every system attached to the IVO, it simply > wont work. It is like saying that I have to have an account on every http > server in the world before I can browse the web. > > All the mechanics has to be transparent to the user and relatively simple to > implement or it won't scale. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > Behalf Of Wil O'Mullane > > Sent: 06 July 2004 19:20 > > Cc: 'Grid and WebServices' > > Subject: Re: MSO and multiple communities > > > > > > > > Making every user set up an account with every community > > which manages > > > groups they are joined to (and groups that those groups are > > joined to? > > > and > > > ...) will simply not work. > > That was never implied - in the discussiosn we had in boston > > the agreement was that this would prbably be done behind the scenes. > > I will have an accoutn for each user on my system but I will > > create it the first time I see their identity > > > > > > > > Cheers, > > > Tony. > > > > > > > -----Original Message----- > > > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On Behalf Of > > > > Guy Rixon > > > > Sent: 06 July 2004 15:28 > > > > To: Grid and WebServices > > > > Subject: Re: MSO and multiple communities > > > > > > > > Let's clear something up. > > > > > > > > Hands up all those who think that service providers to > > the IVO are > > > > required to accept identity warrants from any community CA inside > > > > the IVO. Hands up those who think that providers will > > actually do > > > > this. > > > > > > > > If we get this kind of universal trust, then we can have true SSO > > > > while still having multiple communities. If not, then we > > > > automatically some form of MSO and _nothing_ we can do > > changes that > > > > without breaking the integrity of the system. > > > > > > > > I reiterate: if user U is registered at communities C1 > > and C2, and > > > > if service S trusts C1 and distrusts C2, then C1 _cannot_ > > rightfully > > > > act as a sign-on proxy for groups in C2 when talking to S. U > > > > _must_, somehow, sign on separately to > > > > C1 and C2. > > > > > > > > On Tue, 6 Jul 2004, Guy Rixon wrote: > > > > > > > > > On Tue, 6 Jul 2004, Dave Morris wrote: > > > > > > > > > > > Guy Rixon wrote: > > > > > > > > > > > > >>Would it work if a Community issued a warrant > > > > (certificate) when > > > > > > >>an Account joined a Group at that Community ? > > > > > > >>An Account would then have a primary identity > > > > certificate signed > > > > > > >>by their 'home' Community, to prove who they are, > > plus a set > > > > > > >>of membership certificates signed by other Communities to > > > > prove that > > > > > > >>they belong to Groups on those Communities. > > > > > > > > > > > > > >Nearly. The warants are supposed to be short-lived, so > > > > the group > > > > > > >warrants have to be collected at time of sign-on > > (start of each > > > > > > >session). Therefore, one has to be able to find all the > > > > > > >group-granting communities from the primary community. > > > > That's doable. > > > > > > > > > > > > > > > > > > > > Yep, if a Community for an Account keeps a list of Groups > > > > that that > > > > > > Account is a member of, then it can use this to get the > > > > membership warrants. > > > > > > Could even be delayed, and only done when a warrant > > is required. > > > > > > Client service could keep a cache of membership warrants for > > > > > > this session, and only call the remote Communitites when it > > > > > > needs to prove group membership. > > > > > > This avoids a message storm of warrant requests when a > > > > user logs in > > > > > > to check the news pages. > > > > > > > > > > > > However, there is a useability problem with this model. > > > > > > a) The user needs to be aware of what membership warrants are > > > > > > required for which actions and selects them when > > > > designing a workflow. > > > > > > > > > > This would be a policy look-up on the registry. > > > > > > > > > > > b) All the membership warrants are sent with every > > > > message (message > > > > > > bloat - a 2 line status request may end up with 50+ > > > > warrants in the header). > > > > > > > > > > A good reason for using X.509 instead of SAML - much > > more compact. > > > > > > > > > > > c) The system works it all out - a complex problem that we > > > > > > havn't solved yet (particularly if workflow execution can > > > > dynamically swap > > > > > > between equivalent services based on availability etc.) > > > > > > > > > > > > > > > (d) Back to the pull model: service knows which groups are > > > > > relevant (because service has internal authorization tables > > > > > mapping > > > > groups to > > > > > privileges) and which communities host which groups > > > > (because it looked > > > > > them up when setting up its authZ tables); so service pulls the > > > > > warrants required from the community services. > > > > > > > > > > Pro: minimized warrants sent to service. > > > > > > > > > > Con: service has to interact with many communities at time of > > > > > call; all must be up and there are more (but smaller) messages. > > > > > > > > > > Con: user agent has to associate the same key pair with all the > > > > > communities => user agent has to log in to each community > > > > at the start > > > > > of the session => use ragent has to know which communities > > > > are relevant. > > > > > > > > > > > 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-grid@eso.org Wed Jul 7 02:23:38 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i670N6m8005793 for ; Wed, 7 Jul 2004 02:23:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i670N6CP005792 for grid-outgoing; Wed, 7 Jul 2004 02:23:06 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i670N2m8005786 for ; Wed, 7 Jul 2004 02:23:03 +0200 (MEST) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i670N0DP001133 for ; Wed, 7 Jul 2004 02:23:01 +0200 (CEST) Received: from dial.pipex.com (unknown [81.86.72.119]) by shockwave.systems.pipex.net (Postfix) with ESMTP id D6AA71C0018D; Wed, 7 Jul 2004 01:22:59 +0100 (BST) Message-ID: <40EB4250.2010508@dial.pipex.com> Date: Wed, 07 Jul 2004 01:22:40 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Grid and WebServices'" Subject: Re: MSO and multiple communities References: <20040706142029.E18961@skysrv.pha.jhu.edu> <200407062120.i66LKfEQ003842@rocky.hq.eso.org> <20040706192151.M18961@skysrv.pha.jhu.edu> In-Reply-To: <20040706192151.M18961@skysrv.pha.jhu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil O'Mullane wrote: > we do not need accounts or certificates for the simple jobs > so no not necessarily for all 10k users > but for the perhaps1k who want a more sophisticated service yes I got the impression that groups allow a coarse-grained approach to assigning privileges and avoid having to track huge numbers of individuals. Groups can span communities and so separate assigning privilege from trust. That way we don't need to ask data providers to assign vast numbers of individual privileges. I'm a bit out of touch though :-( > If i really do not need to identify users then why are we doing this at all > we do not need security or certificates On that subject; is there any formal security analysis on the VO? ie, what are we 'defending' against amongst the various services? I get the impression that the majority of services do not need any security, but the fact that some do requires a way of passing security tokens between all services so that 'fully public' services can pass results or make calls to 'secure' services. > > On Tue, Jul 06, 2004 at 10:20:39PM +0100, Tony Linde wrote: > >>>I will have an accoutn for each user on my system but I will >>>create it the first time I see their identity >> >>So anyone who ever uses any data or software on your machine will get an >>account created - possibly 10000 plus of them. Why? If all you're going to >>do is create the accounts when you see the identity, why go to the bother? >>Why not just run the job anyway? Or are you going to add them to all the >>groups that your apps and data use to encompass privileges? And how are you >>going to recognise when people are added to and removed from groups? It >>isn't going to work. >> >>We've sold the IVO on the idea that anyone can get at any data anywhere. If >>you're going to manage that on the basis of every user who ever signs up to >>the IVO having an account on every system attached to the IVO, it simply >>wont work. It is like saying that I have to have an account on every http >>server in the world before I can browse the web. >> >>All the mechanics has to be transparent to the user and relatively simple to >>implement or it won't scale. >> >>Cheers, >>Tony. >> >> >>>-----Original Message----- >>>From: owner-grid@eso.org [mailto:owner-grid@eso.org] On >>>Behalf Of Wil O'Mullane >>>Sent: 06 July 2004 19:20 >>>Cc: 'Grid and WebServices' >>>Subject: Re: MSO and multiple communities >>> >>> >>>>Making every user set up an account with every community >>> >>>which manages >>> >>>>groups they are joined to (and groups that those groups are >>> >>>joined to? >>> >>>>and >>>>...) will simply not work. >>> >>>That was never implied - in the discussiosn we had in boston >>>the agreement was that this would prbably be done behind the scenes. >>>I will have an accoutn for each user on my system but I will >>>create it the first time I see their identity >>> >>> >>>>Cheers, >>>>Tony. >>>> >>>> >>>>>-----Original Message----- >>>>>From: owner-grid@eso.org [mailto:owner-grid@eso.org] On Behalf Of >>>>>Guy Rixon >>>>>Sent: 06 July 2004 15:28 >>>>>To: Grid and WebServices >>>>>Subject: Re: MSO and multiple communities >>>>> >>>>>Let's clear something up. >>>>> >>>>>Hands up all those who think that service providers to >>> >>>the IVO are >>> >>>>>required to accept identity warrants from any community CA inside >>>>>the IVO. Hands up those who think that providers will >>> >>>actually do >>> >>>>>this. >>>>> >>>>>If we get this kind of universal trust, then we can have true SSO >>>>>while still having multiple communities. If not, then we >>>>>automatically some form of MSO and _nothing_ we can do >>> >>>changes that >>> >>>>>without breaking the integrity of the system. >>>>> >>>>>I reiterate: if user U is registered at communities C1 >>> >>>and C2, and >>> >>>>>if service S trusts C1 and distrusts C2, then C1 _cannot_ >>> >>>rightfully >>> >>>>>act as a sign-on proxy for groups in C2 when talking to S. U >>>>>_must_, somehow, sign on separately to >>>>>C1 and C2. >>>>> >>>>>On Tue, 6 Jul 2004, Guy Rixon wrote: >>>>> >>>>> >>>>>>On Tue, 6 Jul 2004, Dave Morris wrote: >>>>>> >>>>>> >>>>>>>Guy Rixon wrote: >>>>>>> >>>>>>> >>>>>>>>>Would it work if a Community issued a warrant >>>>> >>>>>(certificate) when >>>>> >>>>>>>>>an Account joined a Group at that Community ? >>>>>>>>>An Account would then have a primary identity >>>>> >>>>>certificate signed >>>>> >>>>>>>>>by their 'home' Community, to prove who they are, >>> >>>plus a set >>> >>>>>>>>>of membership certificates signed by other Communities to >>>>> >>>>>prove that >>>>> >>>>>>>>>they belong to Groups on those Communities. >>>>>>>> >>>>>>>>Nearly. The warants are supposed to be short-lived, so >>>>> >>>>>the group >>>>> >>>>>>>>warrants have to be collected at time of sign-on >>> >>>(start of each >>> >>>>>>>>session). Therefore, one has to be able to find all the >>>>>>>>group-granting communities from the primary community. >>>>> >>>>>That's doable. >>>>> >>>>>>>> >>>>>>>Yep, if a Community for an Account keeps a list of Groups >>>>> >>>>>that that >>>>> >>>>>>>Account is a member of, then it can use this to get the >>>>> >>>>>membership warrants. >>>>> >>>>>>>Could even be delayed, and only done when a warrant >>> >>>is required. >>> >>>>>>>Client service could keep a cache of membership warrants for >>>>>>>this session, and only call the remote Communitites when it >>>>>>>needs to prove group membership. >>>>>>>This avoids a message storm of warrant requests when a >>>>> >>>>>user logs in >>>>> >>>>>>>to check the news pages. >>>>>>> >>>>>>>However, there is a useability problem with this model. >>>>>>>a) The user needs to be aware of what membership warrants are >>>>>>>required for which actions and selects them when >>>>> >>>>>designing a workflow. >>>>> >>>>>>This would be a policy look-up on the registry. >>>>>> >>>>>> >>>>>>>b) All the membership warrants are sent with every >>>>> >>>>>message (message >>>>> >>>>>>>bloat - a 2 line status request may end up with 50+ >>>>> >>>>>warrants in the header). >>>>> >>>>>>A good reason for using X.509 instead of SAML - much >>> >>>more compact. >>> >>>>>>>c) The system works it all out - a complex problem that we >>>>>>>havn't solved yet (particularly if workflow execution can >>>>> >>>>>dynamically swap >>>>> >>>>>>>between equivalent services based on availability etc.) >>>>>> >>>>>> >>>>>>(d) Back to the pull model: service knows which groups are >>>>>>relevant (because service has internal authorization tables >>>>>>mapping >>>>> >>>>>groups to >>>>> >>>>>>privileges) and which communities host which groups >>>>> >>>>>(because it looked >>>>> >>>>>>them up when setting up its authZ tables); so service pulls the >>>>>>warrants required from the community services. >>>>>> >>>>>>Pro: minimized warrants sent to service. >>>>>> >>>>>>Con: service has to interact with many communities at time of >>>>>>call; all must be up and there are more (but smaller) messages. >>>>>> >>>>>>Con: user agent has to associate the same key pair with all the >>>>>>communities => user agent has to log in to each community >>>>> >>>>>at the start >>>>> >>>>>>of the session => use ragent has to know which communities >>>>> >>>>>are relevant. >>>>> >>>>>>>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 >>>>> >>> > -- Martin Hill www.mchill.net 07901 55 24 66 0131 668 8100 (ROE) From owner-grid@eso.org Wed Jul 7 03:34:13 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i671Xlm8009770 for ; Wed, 7 Jul 2004 03:33:47 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i671Xluq009769 for grid-outgoing; Wed, 7 Jul 2004 03:33:47 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i671Xhm8009763 for ; Wed, 7 Jul 2004 03:33:44 +0200 (MEST) Received: from billthecat.sdsc.edu (billthecat.sdsc.edu [132.249.20.60]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i671XeEQ008877 for ; Wed, 7 Jul 2004 03:33:41 +0200 (CEST) Received: from [132.249.200.198] (moore-pb.sdsc.edu [132.249.200.198]) by billthecat.sdsc.edu (8.11.7/8.11.7/mx/49) with ESMTP id i671Xdb25264 for ; Tue, 6 Jul 2004 18:33:39 -0700 (PDT) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu Message-Id: In-Reply-To: <20040706192151.M18961@skysrv.pha.jhu.edu> References: <20040706142029.E18961@skysrv.pha.jhu.edu> <200407062120.i66LKfEQ003842@rocky.hq.eso.org> <20040706192151.M18961@skysrv.pha.jhu.edu> Date: Tue, 6 Jul 2004 18:32:33 -0700 To: "'Grid and WebServices'" From: Reagan Moore Subject: Re: MSO and multiple communities Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The need for authentication is for access to controlled resources whose usage is allocated. The approach we take with data grids is: - public read access to collections - writes restricted to individuals who own the collection, or have been assigned write permission by the owner. - addition of metadata restricted to the curator of the collection The authentication is done to the data grid. The data grid then authenticates itself to the remote resource on which the data is located. The only account needed at the remote resources is the ID under which the data grid runs. This approach provides a single sign on environment for access to data stored within a particular collection that is distributed across multiple sites. Since we use GSI authentication, the system interoperates with grid environments. For the case of access to compute resources, we rely upon GSI. Use of a compute resource is only possible if the individual has been assigned an account. The Particle Physics Data Grid and high energy physics community have established compute grids that span Europe, the UK, the US, and Japan. The IVOA can choose to do the same. The approach required establishing the set of certificate authorities whose certificates would be honored within the compute grid. Both data grids and compute grids are running today that enable single sign-on. Reagan Moore >we do not need accounts or certificates for the simple jobs >so no not necessarily for all 10k users >but for the perhaps1k who want a more sophisticated service yes > >If i really do not need to identify users then why are we doing this at all >we do not need security or certificates > >On Tue, Jul 06, 2004 at 10:20:39PM +0100, Tony Linde wrote: >> > I will have an accoutn for each user on my system but I will >> > create it the first time I see their identity >> >> So anyone who ever uses any data or software on your machine will get an >> account created - possibly 10000 plus of them. Why? If all you're going to >> do is create the accounts when you see the identity, why go to the bother? >> Why not just run the job anyway? Or are you going to add them to all the >> groups that your apps and data use to encompass privileges? And how are you >> going to recognise when people are added to and removed from groups? It >> isn't going to work. >> >> We've sold the IVO on the idea that anyone can get at any data anywhere. If >> you're going to manage that on the basis of every user who ever signs up to >> the IVO having an account on every system attached to the IVO, it simply >> wont work. It is like saying that I have to have an account on every http >> server in the world before I can browse the web. >> >> All the mechanics has to be transparent to the user and relatively simple to >> implement or it won't scale. >> >> Cheers, >> Tony. >> >> > -----Original Message----- >> > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On >> > Behalf Of Wil O'Mullane >> > Sent: 06 July 2004 19:20 >> > Cc: 'Grid and WebServices' >> > Subject: Re: MSO and multiple communities >> > >> > > >> > > Making every user set up an account with every community >> > which manages >> > > groups they are joined to (and groups that those groups are >> > joined to? >> > > and >> > > ...) will simply not work. >> > That was never implied - in the discussiosn we had in boston >> > the agreement was that this would prbably be done behind the scenes. >> > I will have an accoutn for each user on my system but I will >> > create it the first time I see their identity >> > >> > > >> > > Cheers, >> > > Tony. >> > > >> > > > -----Original Message----- >> > > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On Behalf Of >> > > > Guy Rixon >> > > > Sent: 06 July 2004 15:28 >> > > > To: Grid and WebServices >> > > > Subject: Re: MSO and multiple communities >> > > > >> > > > Let's clear something up. >> > > > >> > > > Hands up all those who think that service providers to >> > the IVO are >> > > > required to accept identity warrants from any community CA inside > > > > > the IVO. Hands up those who think that providers will >> > actually do >> > > > this. >> > > > >> > > > If we get this kind of universal trust, then we can have true SSO >> > > > while still having multiple communities. If not, then we >> > > > automatically some form of MSO and _nothing_ we can do >> > changes that >> > > > without breaking the integrity of the system. >> > > > >> > > > I reiterate: if user U is registered at communities C1 >> > and C2, and >> > > > if service S trusts C1 and distrusts C2, then C1 _cannot_ >> > rightfully >> > > > act as a sign-on proxy for groups in C2 when talking to S. U >> > > > _must_, somehow, sign on separately to >> > > > C1 and C2. >> > > > >> > > > On Tue, 6 Jul 2004, Guy Rixon wrote: >> > > > >> > > > > On Tue, 6 Jul 2004, Dave Morris wrote: >> > > > > >> > > > > > Guy Rixon wrote: >> > > > > > >> > > > > > >>Would it work if a Community issued a warrant >> > > > (certificate) when >> > > > > > >>an Account joined a Group at that Community ? >> > > > > > >>An Account would then have a primary identity >> > > > certificate signed >> > > > > > >>by their 'home' Community, to prove who they are, >> > plus a set >> > > > > > >>of membership certificates signed by other Communities to >> > > > prove that >> > > > > > >>they belong to Groups on those Communities. >> > > > > > > >> > > > > > >Nearly. The warants are supposed to be short-lived, so >> > > > the group >> > > > > > >warrants have to be collected at time of sign-on >> > (start of each >> > > > > > >session). Therefore, one has to be able to find all the >> > > > > > >group-granting communities from the primary community. >> > > > That's doable. >> > > > > > > >> > > > > > > >> > > > > > Yep, if a Community for an Account keeps a list of Groups >> > > > that that >> > > > > > Account is a member of, then it can use this to get the >> > > > membership warrants. >> > > > > > Could even be delayed, and only done when a warrant >> > is required. >> > > > > > Client service could keep a cache of membership warrants for >> > > > > > this session, and only call the remote Communitites when it >> > > > > > needs to prove group membership. >> > > > > > This avoids a message storm of warrant requests when a >> > > > user logs in >> > > > > > to check the news pages. >> > > > > > >> > > > > > However, there is a useability problem with this model. >> > > > > > a) The user needs to be aware of what membership warrants are >> > > > > > required for which actions and selects them when >> > > > designing a workflow. >> > > > > >> > > > > This would be a policy look-up on the registry. >> > > > > >> > > > > > b) All the membership warrants are sent with every >> > > > message (message >> > > > > > bloat - a 2 line status request may end up with 50+ >> > > > warrants in the header). >> > > > > >> > > > > A good reason for using X.509 instead of SAML - much >> > more compact. >> > > > > >> > > > > > c) The system works it all out - a complex problem that we >> > > > > > havn't solved yet (particularly if workflow execution can >> > > > dynamically swap >> > > > > > between equivalent services based on availability etc.) >> > > > > >> > > > > >> > > > > (d) Back to the pull model: service knows which groups are >> > > > > relevant (because service has internal authorization tables >> > > > > mapping >> > > > groups to >> > > > > privileges) and which communities host which groups >> > > > (because it looked >> > > > > them up when setting up its authZ tables); so service pulls the >> > > > > warrants required from the community services. >> > > > > >> > > > > Pro: minimized warrants sent to service. >> > > > > >> > > > > Con: service has to interact with many communities at time of >> > > > > call; all must be up and there are more (but smaller) messages. >> > > > > >> > > > > Con: user agent has to associate the same key pair with all the >> > > > > communities => user agent has to log in to each community >> > > > at the start >> > > > > of the session => use ragent has to know which communities >> > > > are relevant. >> > > > > >> > > > > > 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-grid@eso.org Wed Jul 7 11:43:00 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i679gOFL019735 for ; Wed, 7 Jul 2004 11:42:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i679gOpA019734 for grid-outgoing; Wed, 7 Jul 2004 11:42:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i679gJFL019723 for ; Wed, 7 Jul 2004 11:42:20 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i679gIDP011845 for ; Wed, 7 Jul 2004 11:42:18 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:62629) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1Bi8wQ-0000hs-Rl; Wed, 07 Jul 2004 10:42:14 +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 i679gEmm021981; Wed, 7 Jul 2004 10:42:14 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i679gDM1012097; Wed, 7 Jul 2004 10:42:14 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i679gDd9012094; Wed, 7 Jul 2004 10:42:13 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 7 Jul 2004 10:42:13 +0100 (BST) From: Guy Rixon To: Tony Linde cc: grid@ivoa.net Subject: RE: MSO and multiple communities In-Reply-To: <200407062111.i66LBjEQ003686@rocky.hq.eso.org> Message-ID: References: <200407062111.i66LBjEQ003686@rocky.hq.eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: We can choose to equate identity an account in the spec but I've left them separate in the intro to make it clear what we are doing. For an example of identity indepdent of an account, see my discussion of registering identities in the resource registry. http://wiki.astrogrid.org/bin/view/AG2/MaxRegistryUsage On Tue, 6 Jul 2004, Tony Linde wrote: > I've not had a chance to read the document but the descriptions in the > glosary are complete and very useful. > > I certainly agree with the definitions but I would tend to conflate identity > and account, assuming only one account per identity. I cannot think > identity (as a single unique thing) has any meaning otherwise. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > > Behalf Of Guy Rixon > > Sent: 06 July 2004 17:31 > > To: grid@ivoa.net > > Subject: Re: MSO and multiple communities > > > > I have uploaded a new version of the SSO introduction at > > > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-i > ntroduction.htm > > > > This now has a glossary at the end giving detailed > > definitions of account, identity, community, warrant etc. The > > definitions take account of today's email discussions but > > clearly won't match evrybody's private glossary (otherwise > > there would have been no need for me to write them down). > > > > 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-grid@eso.org Wed Jul 7 11:57:04 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i679ucFL021370 for ; Wed, 7 Jul 2004 11:56:39 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i679ucW7021369 for grid-outgoing; Wed, 7 Jul 2004 11:56:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i679uYFL021355 for ; Wed, 7 Jul 2004 11:56:34 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i679uWDP012183 for ; Wed, 7 Jul 2004 11:56:32 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:63624) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1Bi9AD-0003xr-CN; Wed, 07 Jul 2004 10:56:29 +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 i679uTmm022458; Wed, 7 Jul 2004 10:56:29 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i679uSM1012121; Wed, 7 Jul 2004 10:56:28 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i679uStm012118; Wed, 7 Jul 2004 10:56:28 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 7 Jul 2004 10:56:28 +0100 (BST) From: Guy Rixon To: Martin Hill cc: "'Grid and WebServices'" Subject: Re: MSO and multiple communities In-Reply-To: <40EB4250.2010508@dial.pipex.com> Message-ID: References: <20040706142029.E18961@skysrv.pha.jhu.edu> <200407062120.i66LKfEQ003842@rocky.hq.eso.org> <20040706192151.M18961@skysrv.pha.jhu.edu> <40EB4250.2010508@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 7 Jul 2004, Martin Hill wrote: > Wil O'Mullane wrote: > > > we do not need accounts or certificates for the simple jobs > > so no not necessarily for all 10k users > > but for the perhaps1k who want a more sophisticated service yes > > I got the impression that groups allow a coarse-grained approach to > assigning privileges and avoid having to track huge numbers of > individuals. Groups can span communities and so separate assigning > privilege from trust. That way we don't need to ask data providers to > assign vast numbers of individual privileges. I'm a bit out of touch > though :-( Yes, this is the purpose of groups. However, when controlling access to files owned by individuals - think of VOSpace - groups don't avoid the need to authorize at the individual level. > > If i really do not need to identify users then why are we doing this at all > > we do not need security or certificates > > On that subject; is there any formal security analysis on the VO? ie, > what are we 'defending' against amongst the various services? I get the > impression that the majority of services do not need any security, but > the fact that some do requires a way of passing security tokens between > all services so that 'fully public' services can pass results or make > calls to 'secure' services. There is no formal analysis yet, although we might commission one when we have an agreed scheme to analysis. Earlier discussions in AstroGrid identified these threats: - Improper access to restricted ("proprietary" archive-data). - Improper access to users' own files (MySpace et al.). - Accidental damage to ephemeral state (e.g. user A trashes B's query). - Accidental damage to permanent state (e.g. user A drops service B's DB). - Malicious damage to ephemeral or permanent state. - Malicious denial of service attacks (e.g. repeated large queries). - Accidental denial of service attacks ("slashdotting" by general public when an astronomical even is mentioned in the media). >From this list one could then subdivide into types of attack or accident. Note that there's a mixed bag of impropriety, damage and inconvenience in the categories above. We're trying to exclude all of these with one access-control system because it seems too horrible to build several systems. But, following Roy's 2-hands/no-hands message, I wonder if this is the easiest approach. > > > > On Tue, Jul 06, 2004 at 10:20:39PM +0100, Tony Linde wrote: > > > >>>I will have an accoutn for each user on my system but I will > >>>create it the first time I see their identity > >> > >>So anyone who ever uses any data or software on your machine will get an > >>account created - possibly 10000 plus of them. Why? If all you're going to > >>do is create the accounts when you see the identity, why go to the bother? > >>Why not just run the job anyway? Or are you going to add them to all the > >>groups that your apps and data use to encompass privileges? And how are you > >>going to recognise when people are added to and removed from groups? It > >>isn't going to work. > >> > >>We've sold the IVO on the idea that anyone can get at any data anywhere. If > >>you're going to manage that on the basis of every user who ever signs up to > >>the IVO having an account on every system attached to the IVO, it simply > >>wont work. It is like saying that I have to have an account on every http > >>server in the world before I can browse the web. > >> > >>All the mechanics has to be transparent to the user and relatively simple to > >>implement or it won't scale. > >> > >>Cheers, > >>Tony. > >> > >> > >>>-----Original Message----- > >>>From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > >>>Behalf Of Wil O'Mullane > >>>Sent: 06 July 2004 19:20 > >>>Cc: 'Grid and WebServices' > >>>Subject: Re: MSO and multiple communities > >>> > >>> > >>>>Making every user set up an account with every community > >>> > >>>which manages > >>> > >>>>groups they are joined to (and groups that those groups are > >>> > >>>joined to? > >>> > >>>>and > >>>>...) will simply not work. > >>> > >>>That was never implied - in the discussiosn we had in boston > >>>the agreement was that this would prbably be done behind the scenes. > >>>I will have an accoutn for each user on my system but I will > >>>create it the first time I see their identity > >>> > >>> > >>>>Cheers, > >>>>Tony. > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: owner-grid@eso.org [mailto:owner-grid@eso.org] On Behalf Of > >>>>>Guy Rixon > >>>>>Sent: 06 July 2004 15:28 > >>>>>To: Grid and WebServices > >>>>>Subject: Re: MSO and multiple communities > >>>>> > >>>>>Let's clear something up. > >>>>> > >>>>>Hands up all those who think that service providers to > >>> > >>>the IVO are > >>> > >>>>>required to accept identity warrants from any community CA inside > >>>>>the IVO. Hands up those who think that providers will > >>> > >>>actually do > >>> > >>>>>this. > >>>>> > >>>>>If we get this kind of universal trust, then we can have true SSO > >>>>>while still having multiple communities. If not, then we > >>>>>automatically some form of MSO and _nothing_ we can do > >>> > >>>changes that > >>> > >>>>>without breaking the integrity of the system. > >>>>> > >>>>>I reiterate: if user U is registered at communities C1 > >>> > >>>and C2, and > >>> > >>>>>if service S trusts C1 and distrusts C2, then C1 _cannot_ > >>> > >>>rightfully > >>> > >>>>>act as a sign-on proxy for groups in C2 when talking to S. U > >>>>>_must_, somehow, sign on separately to > >>>>>C1 and C2. > >>>>> > >>>>>On Tue, 6 Jul 2004, Guy Rixon wrote: > >>>>> > >>>>> > >>>>>>On Tue, 6 Jul 2004, Dave Morris wrote: > >>>>>> > >>>>>> > >>>>>>>Guy Rixon wrote: > >>>>>>> > >>>>>>> > >>>>>>>>>Would it work if a Community issued a warrant > >>>>> > >>>>>(certificate) when > >>>>> > >>>>>>>>>an Account joined a Group at that Community ? > >>>>>>>>>An Account would then have a primary identity > >>>>> > >>>>>certificate signed > >>>>> > >>>>>>>>>by their 'home' Community, to prove who they are, > >>> > >>>plus a set > >>> > >>>>>>>>>of membership certificates signed by other Communities to > >>>>> > >>>>>prove that > >>>>> > >>>>>>>>>they belong to Groups on those Communities. > >>>>>>>> > >>>>>>>>Nearly. The warants are supposed to be short-lived, so > >>>>> > >>>>>the group > >>>>> > >>>>>>>>warrants have to be collected at time of sign-on > >>> > >>>(start of each > >>> > >>>>>>>>session). Therefore, one has to be able to find all the > >>>>>>>>group-granting communities from the primary community. > >>>>> > >>>>>That's doable. > >>>>> > >>>>>>>> > >>>>>>>Yep, if a Community for an Account keeps a list of Groups > >>>>> > >>>>>that that > >>>>> > >>>>>>>Account is a member of, then it can use this to get the > >>>>> > >>>>>membership warrants. > >>>>> > >>>>>>>Could even be delayed, and only done when a warrant > >>> > >>>is required. > >>> > >>>>>>>Client service could keep a cache of membership warrants for > >>>>>>>this session, and only call the remote Communitites when it > >>>>>>>needs to prove group membership. > >>>>>>>This avoids a message storm of warrant requests when a > >>>>> > >>>>>user logs in > >>>>> > >>>>>>>to check the news pages. > >>>>>>> > >>>>>>>However, there is a useability problem with this model. > >>>>>>>a) The user needs to be aware of what membership warrants are > >>>>>>>required for which actions and selects them when > >>>>> > >>>>>designing a workflow. > >>>>> > >>>>>>This would be a policy look-up on the registry. > >>>>>> > >>>>>> > >>>>>>>b) All the membership warrants are sent with every > >>>>> > >>>>>message (message > >>>>> > >>>>>>>bloat - a 2 line status request may end up with 50+ > >>>>> > >>>>>warrants in the header). > >>>>> > >>>>>>A good reason for using X.509 instead of SAML - much > >>> > >>>more compact. > >>> > >>>>>>>c) The system works it all out - a complex problem that we > >>>>>>>havn't solved yet (particularly if workflow execution can > >>>>> > >>>>>dynamically swap > >>>>> > >>>>>>>between equivalent services based on availability etc.) > >>>>>> > >>>>>> > >>>>>>(d) Back to the pull model: service knows which groups are > >>>>>>relevant (because service has internal authorization tables > >>>>>>mapping > >>>>> > >>>>>groups to > >>>>> > >>>>>>privileges) and which communities host which groups > >>>>> > >>>>>(because it looked > >>>>> > >>>>>>them up when setting up its authZ tables); so service pulls the > >>>>>>warrants required from the community services. > >>>>>> > >>>>>>Pro: minimized warrants sent to service. > >>>>>> > >>>>>>Con: service has to interact with many communities at time of > >>>>>>call; all must be up and there are more (but smaller) messages. > >>>>>> > >>>>>>Con: user agent has to associate the same key pair with all the > >>>>>>communities => user agent has to log in to each community > >>>>> > >>>>>at the start > >>>>> > >>>>>>of the session => use ragent has to know which communities > >>>>> > >>>>>are relevant. > >>>>> > >>>>>>>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 > >>>>> > >>> > > > > > -- > Martin Hill > www.mchill.net > 07901 55 24 66 > 0131 668 8100 (ROE) > 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-grid@eso.org Wed Jul 7 12:12:00 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67ABbFL023824 for ; Wed, 7 Jul 2004 12:11:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67ABbaZ023823 for grid-outgoing; Wed, 7 Jul 2004 12:11:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67ABWFL023810 for ; Wed, 7 Jul 2004 12:11:33 +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 i67ABVDP012797 for ; Wed, 7 Jul 2004 12:11:31 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id D989744013; Wed, 7 Jul 2004 11:11:30 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 3986; Wed, 07 Jul 2004 11:11:29 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 87FBF44011; Wed, 7 Jul 2004 11:11:29 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 7 Jul 2004 11:11:29 +0100 (BST) Received: from dial.pipex.com (IFA19P.roe.ac.uk [195.194.122.26]) by katrine.roe.ac.uk (Postfix) with ESMTP id 4FB7A44011; Wed, 7 Jul 2004 11:11:29 +0100 (BST) Message-ID: <40EBCC61.6080407@dial.pipex.com> Date: Wed, 07 Jul 2004 11:11:45 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon Cc: "'Grid and WebServices'" Subject: Re: MSO and multiple communities References: <20040706142029.E18961@skysrv.pha.jhu.edu> <200407062120.i66LKfEQ003842@rocky.hq.eso.org> <20040706192151.M18961@skysrv.pha.jhu.edu> <40EB4250.2010508@dial.pipex.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: > On Wed, 7 Jul 2004, Martin Hill wrote: >> >>I got the impression that groups allow a coarse-grained approach to >>assigning privileges and avoid having to track huge numbers of >>individuals. Groups can span communities and so separate assigning >>privilege from trust. That way we don't need to ask data providers to >>assign vast numbers of individual privileges. I'm a bit out of touch >>though :-( > > > Yes, this is the purpose of groups. However, when controlling access to files > owned by individuals - think of VOSpace - groups don't avoid the need to > authorize at the individual level. I can see that we will want to allow fine-grained privileges too. In the case of store space, this is automatic, and individuals look after their own files (and who they publish too). I was more concerned that Wil seems to be saying that we would be asking data providers to assign privileges on an individual basis for restricted data? -- Martin Hill www.mchill.net +44 7901 55 24 66 From owner-grid@eso.org Wed Jul 7 12:32:13 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67AVrFL026057 for ; Wed, 7 Jul 2004 12:31:53 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67AVqFJ026056 for grid-outgoing; Wed, 7 Jul 2004 12:31:52 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67AVlFL026044 for ; Wed, 7 Jul 2004 12:31:47 +0200 (MEST) 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 i67AVjEQ020139 for ; Wed, 7 Jul 2004 12:31:46 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:33094) by ppsw-3.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.143]:25) with esmtp (Exim 4.34) id 1Bi9iK-0002hh-3r; Wed, 07 Jul 2004 11:31:44 +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 i67AVhmm023540; Wed, 7 Jul 2004 11:31:43 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i67AVhM1012196; Wed, 7 Jul 2004 11:31:43 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i67AVh7I012193; Wed, 7 Jul 2004 11:31:43 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 7 Jul 2004 11:31:43 +0100 (BST) From: Guy Rixon To: Martin Hill cc: "'Grid and WebServices'" Subject: Re: MSO and multiple communities In-Reply-To: <40EBCC61.6080407@dial.pipex.com> Message-ID: References: <20040706142029.E18961@skysrv.pha.jhu.edu> <200407062120.i66LKfEQ003842@rocky.hq.eso.org> <20040706192151.M18961@skysrv.pha.jhu.edu> <40EB4250.2010508@dial.pipex.com> <40EBCC61.6080407@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 7 Jul 2004, Martin Hill wrote: > Guy Rixon wrote: > > On Wed, 7 Jul 2004, Martin Hill wrote: > >> > >>I got the impression that groups allow a coarse-grained approach to > >>assigning privileges and avoid having to track huge numbers of > >>individuals. Groups can span communities and so separate assigning > >>privilege from trust. That way we don't need to ask data providers to > >>assign vast numbers of individual privileges. I'm a bit out of touch > >>though :-( > > > > > > Yes, this is the purpose of groups. However, when controlling access to files > > owned by individuals - think of VOSpace - groups don't avoid the need to > > authorize at the individual level. > > I can see that we will want to allow fine-grained privileges too. In the case of > store space, this is automatic, and individuals look after their own files (and > who they publish too). I was more concerned that Wil seems to be saying that we > would be asking data providers to assign privileges on an individual basis for > restricted data? I don't think that IVOA is requiring this. The current position seems to be that you need to prove an individual identity in order to prove a group membership in order to prove authorization. Services will also need individual identities for logging. In Wil's MyDB system, data are owned by individuals, so authorization has to be at the individual level. This is because it's a read-write system. In a read-only archive, authorization at group level is still OK in most cases. In the cases where it isn't, the operator of the archive will want the finer-grained authorization to achive their own ends. 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-grid@eso.org Wed Jul 7 13:19:57 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67BJLFL000771 for ; Wed, 7 Jul 2004 13:19:22 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67BJL5a000770 for grid-outgoing; Wed, 7 Jul 2004 13:19:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67BJHFL000762 for ; Wed, 7 Jul 2004 13:19:17 +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 i67BJFEQ021286 for ; Wed, 7 Jul 2004 13:19:15 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 3DBDA44011; Wed, 7 Jul 2004 12:19:15 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 10877; Wed, 07 Jul 2004 12:19:14 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E53C34400D; Wed, 7 Jul 2004 12:19:13 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 7 Jul 2004 12:19:13 +0100 (BST) Received: from JDTAstrogrid (katrine.roe.ac.uk [195.194.120.81]) by katrine.roe.ac.uk (Postfix) with ESMTP id 9137D4400D; Wed, 7 Jul 2004 12:19:13 +0100 (BST) Message-ID: <00c201c46414$3e2b38c0$b4786cc0@JDTAstrogrid> From: "John Taylor" To: "Reagan Moore" , "'Grid and WebServices'" References: <20040706142029.E18961@skysrv.pha.jhu.edu> <200407062120.i66LKfEQ003842@rocky.hq.eso.org> <20040706192151.M18961@skysrv.pha.jhu.edu> Subject: Re: MSO and multiple communities Date: Wed, 7 Jul 2004 12:19:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "John Taylor" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > The authentication is done to the data grid. The data grid then > authenticates itself to the remote resource on which the data is > located. The only account needed at the remote resources is the ID > under which the data grid runs. I think the reason this doesn't work for us is that instead of signing on to a single "data grid", we're allowing sign-on to one of a number of different communities, not all of which may be universally trusted. From owner-grid@eso.org Wed Jul 7 13:39:08 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67BcgFL002682 for ; Wed, 7 Jul 2004 13:38:43 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67BcgRn002678 for grid-outgoing; Wed, 7 Jul 2004 13:38:42 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67BcYFL002667 for ; Wed, 7 Jul 2004 13:38:34 +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 i67BcWEQ021802 for ; Wed, 7 Jul 2004 13:38:32 +0200 (CEST) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 8473C4400C; Wed, 7 Jul 2004 12:38:32 +0100 (BST) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 13094; Wed, 07 Jul 2004 12:38:31 +0100 (BST) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 32EDB4400B; Wed, 7 Jul 2004 12:38:31 +0100 (BST) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Wed, 7 Jul 2004 12:38:31 +0100 (BST) Received: from JDTAstrogrid (katrine.roe.ac.uk [195.194.120.81]) by katrine.roe.ac.uk (Postfix) with ESMTP id 082984400B; Wed, 7 Jul 2004 12:38:31 +0100 (BST) Message-ID: <00e901c46416$f00da260$b4786cc0@JDTAstrogrid> From: "John Taylor" To: "Guy Rixon" , "Dave Morris" Cc: References: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> <40EABF29.5060406@ast.cam.ac.uk> Subject: Re: MSO and multiple communities Date: Wed, 7 Jul 2004 12:38:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "John Taylor" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > > >Suppose my identity is in community C1 and my group is in C2. My target > > >service trusts C2 but not C1. > > > > > If the service S does not trust your originating community C1, then you > > can't access the service. > > End of story. > > OK...in that case S only trusts a group warrant from C2 if the warrant is > names an indivdual account, at some Ci and S also trusts Ci. I.e., the group > warrant can't say 'the bearer of the public key xyz is a member of group G'; > it has to say that 'the caller X is a member of group G provided that you > can authenticate X as individual user I'. Possible, but we'd better be aware > of the distinction. Doesn't C2 just need to say to S 'the caller X is a member of group G and Ci has authenticated X as user I'? Then S can say "all very well, but I don't trust Ci. Service denied". Since S trusts C2, it can surely trust C2 not to spoof X's authenticating community. ===================================== John Taylor +44 (0) 131 668 8328 Astrogrid Java Developer Royal Observatory of Edinburgh http://www.roe.ac.uk/ifa/about/directory.html ===================================== From owner-grid@eso.org Wed Jul 7 13:46:48 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67BkUFL003664 for ; Wed, 7 Jul 2004 13:46:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67BkU6J003663 for grid-outgoing; Wed, 7 Jul 2004 13:46:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67BkPFL003654 for ; Wed, 7 Jul 2004 13:46:25 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67BkOEQ021963 for ; Wed, 7 Jul 2004 13:46:24 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:38789) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1BiAsX-0004hr-4q; Wed, 07 Jul 2004 12:46:21 +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 i67BkEmm026370; Wed, 7 Jul 2004 12:46:14 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i67BkDM1012877; Wed, 7 Jul 2004 12:46:13 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i67BkDBE012874; Wed, 7 Jul 2004 12:46:13 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 7 Jul 2004 12:46:12 +0100 (BST) From: Guy Rixon To: John Taylor cc: Dave Morris , grid@ivoa.net Subject: Re: MSO and multiple communities In-Reply-To: <00e901c46416$f00da260$b4786cc0@JDTAstrogrid> Message-ID: References: <200407061316.i66DGJEQ016132@rocky.hq.eso.org> <40EABF29.5060406@ast.cam.ac.uk> <00e901c46416$f00da260$b4786cc0@JDTAstrogrid> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 7 Jul 2004, John Taylor wrote: > > > >Suppose my identity is in community C1 and my group is in C2. My > target > > > >service trusts C2 but not C1. > > > > > > > If the service S does not trust your originating community C1, then you > > > can't access the service. > > > End of story. > > > > OK...in that case S only trusts a group warrant from C2 if the warrant is > > names an indivdual account, at some Ci and S also trusts Ci. I.e., the > group > > warrant can't say 'the bearer of the public key xyz is a member of group > G'; > > it has to say that 'the caller X is a member of group G provided that you > > can authenticate X as individual user I'. Possible, but we'd better be > aware > > of the distinction. > > Doesn't C2 just need to say to S 'the caller X is a member of group G and Ci > has authenticated X as user I'? Then S can say "all very well, but I don't > trust Ci. Service denied". Since S trusts C2, it can surely trust C2 not > to spoof X's authenticating community. C2 can only say this if it was involved in the logging-in process. Otherwise, it doesn't have all the information. 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-grid@eso.org Wed Jul 7 14:03:03 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67C2UFL005550 for ; Wed, 7 Jul 2004 14:02:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67C2T0g005547 for grid-outgoing; Wed, 7 Jul 2004 14:02:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67C2MFL005528 for ; Wed, 7 Jul 2004 14:02:22 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67C2KEQ022382 for ; Wed, 7 Jul 2004 14:02:20 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i67C2EP07338; Wed, 7 Jul 2004 08:02:14 -0400 Date: Wed, 7 Jul 2004 08:02:14 -0400 From: "Wil O'Mullane" To: Guy Rixon Cc: Martin Hill , "'Grid and WebServices'" Subject: Re: MSO and multiple communities Message-ID: <20040707080214.N18961@skysrv.pha.jhu.edu> References: <20040706142029.E18961@skysrv.pha.jhu.edu> <200407062120.i66LKfEQ003842@rocky.hq.eso.org> <20040706192151.M18961@skysrv.pha.jhu.edu> <40EB4250.2010508@dial.pipex.com> <40EBCC61.6080407@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gtr@ast.cam.ac.uk on Wed, Jul 07, 2004 at 11:31:43AM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I agree. > > I don't think that IVOA is requiring this. > > The current position seems to be that you need to prove an individual identity > in order to prove a group membership in order to prove authorization. > > Services will also need individual identities for logging. > > In Wil's MyDB system, data are owned by individuals, so authorization has to > be at the individual level. This is because it's a read-write system. In a > read-only archive, authorization at group level is still OK in most cases. In > the cases where it isn't, the operator of the archive will want the > finer-grained authorization to achive their own ends. > > 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-grid@eso.org Wed Jul 7 14:27:11 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67CQodT008190 for ; Wed, 7 Jul 2004 14:26:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67CQnV2008188 for grid-outgoing; Wed, 7 Jul 2004 14:26:49 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67CQidT008171 for ; Wed, 7 Jul 2004 14:26:44 +0200 (MEST) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67CQgDP016398 for ; Wed, 7 Jul 2004 14:26:43 +0200 (CEST) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.34) id 1BiBVa-01jusr-Lz; Wed, 07 Jul 2004 13:26:42 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Wed, 7 Jul 2004 13:26:42 +0100 Date: Wed, 7 Jul 2004 13:26:42 +0100 (BST) From: Alasdair Allan To: "Wil O'Mullane" cc: Guy Rixon , Martin Hill , "'Grid and WebServices'" Subject: Re: MSO and multiple communities In-Reply-To: <20040707080214.N18961@skysrv.pha.jhu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil O'Mullane wrote: > Guy Rixon wrote: > > I don't think that IVOA is requiring this. > > > > The current position seems to be that you need to prove an individual > > identity in order to prove a group membership in order to prove > > authorization. > > > > Services will also need individual identities for logging. > > > > In Wil's MyDB system, data are owned by individuals, so authorization > > has to be at the individual level. This is because it's a read-write > > system. In a read-only archive, authorization at group level is still > > OK in most cases. In the cases where it isn't, the operator of the > > archive will want the finer-grained authorization to achive their own > > ends. > > I agree. Ditto. Al. -- Dr. A. Allan, School of Physics, University of Exeter From owner-grid@eso.org Wed Jul 7 14:54:55 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67CsEdT012097 for ; Wed, 7 Jul 2004 14:54:14 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67CsDlF012096 for grid-outgoing; Wed, 7 Jul 2004 14:54:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67Cs4dT012073 for ; Wed, 7 Jul 2004 14:54:04 +0200 (MEST) Received: from artemis.le.ac.uk (ntp2c.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67Cs2EQ023970 for ; Wed, 7 Jul 2004 14:54:02 +0200 (CEST) Message-Id: <200407071254.i67Cs2EQ023970@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1BiBw1-0000l8-TF for grid@ivoa.net; Wed, 07 Jul 2004 13:54:01 +0100 Received: (qmail 10143 invoked from network); 7 Jul 2004 12:54:19 -0000 Received: from agforum.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 7 Jul 2004 12:54:19 -0000 From: "Tony Linde" To: "'Grid and WebServices'" Subject: RE: MSO and multiple communities Date: Wed, 7 Jul 2004 13:53:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Thread-Index: AcRkDeVxz0waepXnTa2wRz3Qkp8ImgAEvsDA X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > In Wil's MyDB system, data are owned by individuals, so > authorization has to be at the individual level. This is > because it's a read-write system. In a read-only archive, > authorization at group level is still OK in most cases. In > the cases where it isn't, the operator of the archive will > want the finer-grained authorization to achive their own ends. Just to be clear though, this does not mean that individuals or groups or indeed anyone but the VOSpace management system needs any level of access to the data in the MyDB database. On the physical system, no accounts at all are necessary since no-one has _direct_ access to any data, whether file- or dbms-based: all access is mediated through some management system. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 07 July 2004 11:32 > To: Martin Hill > Cc: 'Grid and WebServices' > Subject: Re: MSO and multiple communities > > On Wed, 7 Jul 2004, Martin Hill wrote: > > > Guy Rixon wrote: > > > On Wed, 7 Jul 2004, Martin Hill wrote: > > >> > > >>I got the impression that groups allow a coarse-grained > approach to > > >>assigning privileges and avoid having to track huge numbers of > > >>individuals. Groups can span communities and so separate > assigning > > >>privilege from trust. That way we don't need to ask data > providers > > >>to assign vast numbers of individual privileges. I'm a > bit out of > > >>touch though :-( > > > > > > > > > Yes, this is the purpose of groups. However, when controlling > > > access to files owned by individuals - think of VOSpace - groups > > > don't avoid the need to authorize at the individual level. > > > > I can see that we will want to allow fine-grained > privileges too. In > > the case of store space, this is automatic, and individuals > look after > > their own files (and who they publish too). I was more > concerned that > > Wil seems to be saying that we would be asking data providers to > > assign privileges on an individual basis for restricted data? > > I don't think that IVOA is requiring this. > > The current position seems to be that you need to prove an > individual identity in order to prove a group membership in > order to prove authorization. > > Services will also need individual identities for logging. > > In Wil's MyDB system, data are owned by individuals, so > authorization has to be at the individual level. This is > because it's a read-write system. In a read-only archive, > authorization at group level is still OK in most cases. In > the cases where it isn't, the operator of the archive will > want the finer-grained authorization to achive their own ends. > > 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-registry@eso.org Wed Jul 7 19:26:14 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67HPudT015393 for ; Wed, 7 Jul 2004 19:25:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67HPtGa015392 for registry-outgoing; Wed, 7 Jul 2004 19:25:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@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.6/8.12.6) with ESMTP id i67HPkdT015359; Wed, 7 Jul 2004 19:25:46 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67HPiDP027509; Wed, 7 Jul 2004 19:25:44 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id KAA20199; Wed, 7 Jul 2004 10:25:43 -0700 (PDT) Date: Wed, 7 Jul 2004 10:25:43 -0700 (PDT) From: Matthew Graham To: grid@ivoa.net cc: registry@ivoa.net Subject: Are registries services? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-registry@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I cannot remember if this has been discussed or decided upon elsewhere but are registries to be considered as VO Services, in which case should they also implement the getRegistration, RegistrationChangedOn, getAvailability and HarvestLog interfaces? Cheers, Matthew From owner-grid@eso.org Wed Jul 7 19:34:24 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67HY0dT017061 for ; Wed, 7 Jul 2004 19:34:00 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67HY0xQ017059 for grid-outgoing; Wed, 7 Jul 2004 19:34:00 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i67HXudT017046; Wed, 7 Jul 2004 19:33:57 +0200 (MEST) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67HXsEQ004857; Wed, 7 Jul 2004 19:33:55 +0200 (CEST) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id i67HXqV02200; Wed, 7 Jul 2004 12:33:52 -0500 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id i67HXqWh026802; Wed, 7 Jul 2004 12:33:52 -0500 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id i67HXqZh026798; Wed, 7 Jul 2004 12:33:52 -0500 Date: Wed, 7 Jul 2004 12:33:52 -0500 (CDT) From: Ray Plante To: Matthew Graham cc: grid@ivoa.net, Subject: Re: Are registries services? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 7 Jul 2004, Matthew Graham wrote: > I cannot remember if this has been discussed or decided upon elsewhere but > are registries to be considered as VO Services, in which case should they > also implement the getRegistration, RegistrationChangedOn, getAvailability > and HarvestLog interfaces? Yes. From owner-registry@eso.org Wed Jul 7 19:34:24 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67HY5dT017097 for ; Wed, 7 Jul 2004 19:34:05 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67HY5bg017093 for registry-outgoing; Wed, 7 Jul 2004 19:34:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@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.6/8.12.6) with ESMTP id i67HXudT017046; Wed, 7 Jul 2004 19:33:57 +0200 (MEST) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67HXsEQ004857; Wed, 7 Jul 2004 19:33:55 +0200 (CEST) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id i67HXqV02200; Wed, 7 Jul 2004 12:33:52 -0500 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id i67HXqWh026802; Wed, 7 Jul 2004 12:33:52 -0500 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id i67HXqZh026798; Wed, 7 Jul 2004 12:33:52 -0500 Date: Wed, 7 Jul 2004 12:33:52 -0500 (CDT) From: Ray Plante To: Matthew Graham cc: grid@ivoa.net, Subject: Re: Are registries services? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-new Sender: owner-registry@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 7 Jul 2004, Matthew Graham wrote: > I cannot remember if this has been discussed or decided upon elsewhere but > are registries to be considered as VO Services, in which case should they > also implement the getRegistration, RegistrationChangedOn, getAvailability > and HarvestLog interfaces? Yes. From owner-grid@eso.org Fri Jul 16 20:39:17 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i6GIcfoS021474 for ; Fri, 16 Jul 2004 20:38:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i6GIcfn4021473 for grid-outgoing; Fri, 16 Jul 2004 20:38:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i6GIcboS021464 for ; Fri, 16 Jul 2004 20:38:37 +0200 (MEST) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i6GIcZFA012690 for ; Fri, 16 Jul 2004 20:38:36 +0200 (CEST) Received: from lugh.cacr.caltech.edu (lugh.cacr.caltech.edu [131.215.145.183]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id LAA01989 for ; Fri, 16 Jul 2004 11:38:34 -0700 (PDT) Date: Fri, 16 Jul 2004 11:38:34 -0700 (PDT) From: Matthew Graham To: grid@ivoa.net Subject: Mono 1.0 experiences Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.16.107695 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Matthew Graham X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I just thought that I would make a few comments on the playing around with Mono 1.0 (on Mac OS X 10.3.4) that I have been doing this week. Why Mono? Mono is the open source version of .Net with apparent support for ASP.NET and database support (SQL Server, etc). Mono v1.0 was officially released June 30 (http://www.go-mono.com) and there are rpms for Linux, Windows installer (why) and a dmg for Macos X (Panther). Tamas and I tested it with a toy client loading the WSDL from his name resolver web service and it gave exactly the same answers as Windows .Net based client. There is a utility for auto-generating the client stubs, unimaginatively called wsdl.exe. GUI support: On MacOS, it uses gtk+, which you have to setup with Fink - this is a bit of a slog but instructions are included on the web site, although contact me if you are going to do this on MacOS because they are slightly wrong. I have just run the test programs (under X11) and the test GUIs look fine. ASP.NET support is *not* there for MacOS X: you need to build xsp (the Mono ASP.NET container) and mod_mono (the Apache module to use this) and both have killer bugs on MacOS - they will build/install OK but don't work. There is a Bugzilla actively tracking this but anything which says "load the latest version from CVS" should not be a 1.0 release. Cheers, Matthew From owner-apps@eso.org Fri Jul 16 21:37:44 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i6GJbQoS026986 for ; Fri, 16 Jul 2004 21:37:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i6GJbQs3026985 for apps-outgoing; Fri, 16 Jul 2004 21:37:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@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.6/8.12.6) with ESMTP id i6GJbJoS026973; Fri, 16 Jul 2004 21:37:19 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i6GJbHGd019988; Fri, 16 Jul 2004 21:37:17 +0200 (CEST) Received: from localhost (budavari@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id i6GJbFi05025; Fri, 16 Jul 2004 15:37:15 -0400 X-Authentication-Warning: skysrv.pha.jhu.edu: budavari owned process doing -bs Date: Fri, 16 Jul 2004 15:37:15 -0400 (EDT) From: Tamas Budavari To: Matthew Graham cc: grid@ivoa.net, Subject: Re: Mono 1.0 experiences 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.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.16.107695 X-Virus-Scanned: by amavisd-new Sender: owner-apps@eso.org Precedence: bulk Reply-To: Tamas Budavari X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Let me just add that... ...the same web services client (C# code) .exe file I compiled and ran on Linux works also on WinXP and does the same thing as the one compiled on windows. It is true the other way around as well; the .exe compiled on windows runs with Mono. The two files have the same lengths (7680 bytes) but they differ, which must be due to the metadata describing the compiler/version that were different (csc vs msc). I knew it should work like that eventually but it is working *now* with the first release of Mono (v1.0) Very impressive, isn't it? :-) Cheers, T. PS> I compiled msc on RH 7.3 linux myself w/o any problems (./configure, make install) On Fri, 16 Jul 2004, Matthew Graham wrote: > > Hi, > > I just thought that I would make a few comments on the playing around with > Mono 1.0 (on Mac OS X 10.3.4) that I have been doing this week. > > Why Mono? Mono is the open source version of .Net with apparent support > for ASP.NET and database support (SQL Server, etc). > > Mono v1.0 was officially released June 30 (http://www.go-mono.com) and > there are rpms for Linux, Windows installer (why) and a dmg for Macos X > (Panther). > > Tamas and I tested it with a toy client loading the WSDL from his name > resolver web service and it gave exactly the same answers as Windows .Net > based client. There is a utility for auto-generating the client stubs, > unimaginatively called wsdl.exe. > > GUI support: On MacOS, it uses gtk+, which you have to setup with Fink - > this is a bit of a slog but instructions are included on the web site, > although contact me if you are going to do this on MacOS because they are > slightly wrong. I have just run the test programs (under X11) and the test > GUIs look fine. > > ASP.NET support is *not* there for MacOS X: you need to build xsp (the > Mono ASP.NET container) and mod_mono (the Apache module to use this) and > both have killer bugs on MacOS - they will build/install OK but don't > work. There is a Bugzilla actively tracking this but anything which says > "load the latest version from CVS" should not be a 1.0 release. > > Cheers, > > Matthew > From owner-grid@eso.org Fri Jul 16 21:37:44 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i6GJbNoS026979 for ; Fri, 16 Jul 2004 21:37:23 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i6GJbM1V026978 for grid-outgoing; Fri, 16 Jul 2004 21:37:22 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i6GJbJoS026973; Fri, 16 Jul 2004 21:37:19 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i6GJbHGd019988; Fri, 16 Jul 2004 21:37:17 +0200 (CEST) Received: from localhost (budavari@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id i6GJbFi05025; Fri, 16 Jul 2004 15:37:15 -0400 X-Authentication-Warning: skysrv.pha.jhu.edu: budavari owned process doing -bs Date: Fri, 16 Jul 2004 15:37:15 -0400 (EDT) From: Tamas Budavari To: Matthew Graham cc: grid@ivoa.net, Subject: Re: Mono 1.0 experiences 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.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.7.16.107695 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Tamas Budavari X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Let me just add that... ...the same web services client (C# code) .exe file I compiled and ran on Linux works also on WinXP and does the same thing as the one compiled on windows. It is true the other way around as well; the .exe compiled on windows runs with Mono. The two files have the same lengths (7680 bytes) but they differ, which must be due to the metadata describing the compiler/version that were different (csc vs msc). I knew it should work like that eventually but it is working *now* with the first release of Mono (v1.0) Very impressive, isn't it? :-) Cheers, T. PS> I compiled msc on RH 7.3 linux myself w/o any problems (./configure, make install) On Fri, 16 Jul 2004, Matthew Graham wrote: > > Hi, > > I just thought that I would make a few comments on the playing around with > Mono 1.0 (on Mac OS X 10.3.4) that I have been doing this week. > > Why Mono? Mono is the open source version of .Net with apparent support > for ASP.NET and database support (SQL Server, etc). > > Mono v1.0 was officially released June 30 (http://www.go-mono.com) and > there are rpms for Linux, Windows installer (why) and a dmg for Macos X > (Panther). > > Tamas and I tested it with a toy client loading the WSDL from his name > resolver web service and it gave exactly the same answers as Windows .Net > based client. There is a utility for auto-generating the client stubs, > unimaginatively called wsdl.exe. > > GUI support: On MacOS, it uses gtk+, which you have to setup with Fink - > this is a bit of a slog but instructions are included on the web site, > although contact me if you are going to do this on MacOS because they are > slightly wrong. I have just run the test programs (under X11) and the test > GUIs look fine. > > ASP.NET support is *not* there for MacOS X: you need to build xsp (the > Mono ASP.NET container) and mod_mono (the Apache module to use this) and > both have killer bugs on MacOS - they will build/install OK but don't > work. There is a Bugzilla actively tracking this but anything which says > "load the latest version from CVS" should not be a 1.0 release. > > Cheers, > > Matthew > From owner-grid@eso.org Wed Aug 4 15:29:28 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i74DSYrF009378 for ; Wed, 4 Aug 2004 15:28:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i74DSXR6009377 for grid-outgoing; Wed, 4 Aug 2004 15:28:33 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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.6/8.12.6) with ESMTP id i74DSTrF009367 for ; Wed, 4 Aug 2004 15:28:29 +0200 (MEST) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i74DSRGd005815 for ; Wed, 4 Aug 2004 15:28:28 +0200 (CEST) Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.41) id 1BsLoh-01s7l5-Kd for grid@ivoa.net; Wed, 04 Aug 2004 14:28:27 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Wed, 4 Aug 2004 14:28:27 +0100 Date: Wed, 4 Aug 2004 14:28:27 +0100 (BST) From: Alasdair Allan To: grid@ivoa.net Subject: WSRF::Lite 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.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.8.3.109413 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alasdair Allan X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: For those of you who don't read the OGSI::Lite/WSRF::Lite mailing list I thought I should point anyone thinknig about using these Perl modules to http://kato.mvc.mcc.ac.uk/sve-wiki/eViz where there is some basic (and unfortunately still quite brief) material about how to use them... There is also a (canonical?) listing of WSRF implementations, which isn't very long at all... Cheers, Al. -- Dr. A. Allan, School of Physics, University of Exeter From owner-grid@eso.org Wed Sep 22 12:17:49 2004 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 i8MAHbc8007473 for ; Wed, 22 Sep 2004 12:17:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8MAHbMv007472 for grid-outgoing; Wed, 22 Sep 2004 12:17:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 i8MAHbc8007468 for ; Wed, 22 Sep 2004 12:17:37 +0200 (MEST) 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 i8MAHZqH007630 for ; Wed, 22 Sep 2004 12:17:36 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:46013) by ppsw-3.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.143]:25) with esmtp (Exim 4.34) id 1CA4Bi-0003N9-C0 (return-path gtr@ast.cam.ac.uk) for grid@ivoa.net; Wed, 22 Sep 2004 11:17:26 +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 i8MAHPse008932 for ; Wed, 22 Sep 2004 11:17:25 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i8MAHPfZ003721 for ; Wed, 22 Sep 2004 11:17:25 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i8MAHPw0003718 for ; Wed, 22 Sep 2004 11:17:25 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 22 Sep 2004 11:17:25 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Agenda for Pune Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.21.8 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, an outline agenda for the GWS meeting at Pune: - Report on WS-I interop profile (Andre) - Report on VOSpace/VOStore definition (Wil) - Progress and open issues in the single-sign-on profile (Guy) - Interaction with Astro-RG in GGF (Guy/Nic Walton) If anyone wants to speak on another subject, then please let me know. 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-grid@eso.org Fri Sep 24 09:52:37 2004 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 i8O7oTsE025032 for ; Fri, 24 Sep 2004 09:50:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8O7oTRW025031 for grid-outgoing; Fri, 24 Sep 2004 09:50:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 i8O7oSsE025021; Fri, 24 Sep 2004 09:50:28 +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 i8O7oQ0o028871; Fri, 24 Sep 2004 09:50:26 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:64663) by ppsw-5.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.145]:25) with esmtp (Exim 4.34) id 1CAkqV-000884-LG (return-path ); Fri, 24 Sep 2004 08:50:23 +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 i8O7oMse021893; Fri, 24 Sep 2004 08:50:23 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i8O7oMfZ005977; Fri, 24 Sep 2004 08:50:22 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i8O7oM5k005974; Fri, 24 Sep 2004 08:50:22 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 24 Sep 2004 08:50:22 +0100 (BST) From: Guy Rixon To: "Wil O'Mullane" cc: interop@ivoa.net, grid@ivoa.net Subject: Re: RunID - cross service tracking In-Reply-To: <20040923113742.K6830@skysrv.pha.jhu.edu> Message-ID: References: <20040923113742.K6830@skysrv.pha.jhu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.23.6 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil, this probably _should_ be part of the support interfaces, since (presumably) we want it supported eventually on all services. If we make it a SOAP header, then its mustUnderstand attribute should be set false. If we make it an extra agument on CGIs, then presumably it's ignred by default. We should probably put a stipulation in the support-interfaces spec that all IVO services must allow this argument even if they ignore it. What exactly is the servename part? It seems useful to have one ID associated with many related calls to services: i.e. with a job rather than a job-step. Was this what you intended? Cheers, Guy On Thu, 23 Sep 2004, Wil O'Mullane wrote: > Hi All, > Not sure where to go with this idea. I have added it to a new draft of Support Interfaces but that is not the proper place to do this. > In a meeting we had yesterday to discuss logging > Tim Kimball had an interesting idea. We should have a RunID associated with > a particular service run. > So a portal creates a run id in the form servename:sequentialNum. This id should be passed to all services called such that it is logged for each service call. Any service calling another service should pass this number on. Hence if DataScope calls 300 services from one user request they should all have the same RunID. For a web Service the run id could be in the header i.e. no change to the interface. For the Simple GET services it can simply be appended as &RunID=server:990990 which will automatically put it in the log. > > Hence the tie to the logging interface. > > > > wil > 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-grid@eso.org Fri Sep 24 12:37:34 2004 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 i8OAbQsE017023 for ; Fri, 24 Sep 2004 12:37:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8OAbQ1L017022 for grid-outgoing; Fri, 24 Sep 2004 12:37:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 i8OAbPsE017018 for ; Fri, 24 Sep 2004 12:37:25 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8OAbO0o006403 for ; Fri, 24 Sep 2004 12:37:24 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:45380) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1CAnS1-0006GW-UL (return-path ) for grid@ivoa.net; Fri, 24 Sep 2004 11:37: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 i8OAbGse028258 for ; Fri, 24 Sep 2004 11:37:16 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i8OAbGfZ006265 for ; Fri, 24 Sep 2004 11:37:16 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i8OAbGg4006262 for ; Fri, 24 Sep 2004 11:37:16 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 24 Sep 2004 11:37:16 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.23.6 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, A while back, I was asked to prepare examples of asynchrnous activities in web services done with WS-RF and also with WS-CAF etc. I've found a document http://forge.gridforum.org/projects/dais-wg/document/Scenarios_for_Mapping_DAIS_Concepts/en/3 that does this for the DAIS specification of GGF (DAIS services are similar to our SkyNodes). 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-grid@eso.org Fri Sep 24 12:55:25 2004 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 i8OAtLsE018952 for ; Fri, 24 Sep 2004 12:55:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8OAtLjE018951 for grid-outgoing; Fri, 24 Sep 2004 12:55:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 i8OAtKsE018946 for ; Fri, 24 Sep 2004 12:55:20 +0200 (MEST) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8OAtJSV001843 for ; Fri, 24 Sep 2004 12:55:19 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:46943) by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25) with esmtp (Exim 4.34) id 1CAnjR-00038L-07 (return-path ) for grid@ivoa.net; Fri, 24 Sep 2004 11:55: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 i8OAtGse029007 for ; Fri, 24 Sep 2004 11:55:16 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i8OAtGfZ006294 for ; Fri, 24 Sep 2004 11:55:16 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i8OAtG8a006291 for ; Fri, 24 Sep 2004 11:55:16 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 24 Sep 2004 11:55:16 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: GGF directory-service spec Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.23.6 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, in respect of VOSpace, we should be aware what GGF are doing. We may need to interoperate with GGF-style grids (which might mean that we have to provide interfaces to their specs), and we might want to steal their ideas. The Grid File System group (GFS-WG) of GGF has an architecture and a mature spec for a directory service. Please see http://forge.gridforum.org/docman2/ViewCategory.php?group_id=115&category_id=369 for their documents. 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-grid@eso.org Fri Sep 24 15:10:45 2004 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 i8ODAcsE006898 for ; Fri, 24 Sep 2004 15:10:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8ODAcsR006897 for grid-outgoing; Fri, 24 Sep 2004 15:10:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 i8ODAcsE006888; Fri, 24 Sep 2004 15:10:38 +0200 (MEST) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8ODAZ0o013069; Fri, 24 Sep 2004 15:10:36 +0200 (CEST) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i8ODAVG10407; Fri, 24 Sep 2004 09:10:31 -0400 Date: Fri, 24 Sep 2004 09:10:31 -0400 From: "Wil O'Mullane" To: Guy Rixon Cc: interop@ivoa.net, grid@ivoa.net Subject: Re: RunID - cross service tracking Message-ID: <20040924091031.K12837@skysrv.pha.jhu.edu> References: <20040923113742.K6830@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gtr@ast.cam.ac.uk on Fri, Sep 24, 2004 at 08:50:22AM +0100 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.23.6 Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ok it is in the suport interfaces. Yes JOB number rather than job step indeed. ServerName was inteded to give a little uniquness to the string and also make it traceable to the orignating portal of the JOB. > Wil, > > this probably _should_ be part of the support interfaces, since (presumably) > we want it supported eventually on all services. > > If we make it a SOAP header, then its mustUnderstand attribute should be set > false. > > If we make it an extra agument on CGIs, then presumably it's ignred by > default. We should probably put a stipulation in the support-interfaces spec > that all IVO services must allow this argument even if they ignore it. > > What exactly is the servename part? > > It seems useful to have one ID associated with many related calls to services: > i.e. with a job rather than a job-step. Was this what you intended? > > Cheers, > Guy > > On Thu, 23 Sep 2004, Wil O'Mullane wrote: > > > Hi All, > > Not sure where to go with this idea. I have added it to a new draft of Support Interfaces but that is not the proper place to do this. > > In a meeting we had yesterday to discuss logging > > Tim Kimball had an interesting idea. We should have a RunID associated with > > a particular service run. > > So a portal creates a run id in the form servename:sequentialNum. This id should be passed to all services called such that it is logged for each service call. Any service calling another service should pass this number on. Hence if DataScope calls 300 services from one user request they should all have the same RunID. For a web Service the run id could be in the header i.e. no change to the interface. For the Simple GET services it can simply be appended as &RunID=server:990990 which will automatically put it in the log. > > > > Hence the tie to the logging interface. > > > > > > > > wil > > > > 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-grid@eso.org Fri Sep 24 17:29:24 2004 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 i8OFTEsE025699 for ; Fri, 24 Sep 2004 17:29:14 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8OFTEK7025698 for grid-outgoing; Fri, 24 Sep 2004 17:29:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 i8OFTEsE025694 for ; Fri, 24 Sep 2004 17:29:14 +0200 (MEST) Received: from smtp2.linkline.com (smtp2.linkline.com [64.30.215.131]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8OFTC0o019399 for ; Fri, 24 Sep 2004 17:29:12 +0200 (CEST) Received: from Ropy (dsl-64-30-223-60.lcinet.net [64.30.223.60]) by smtp2.linkline.com (Postfix) with ESMTP id 15642F2; Fri, 24 Sep 2004 08:29:09 -0700 (PDT) Message-ID: <014c01c4a24b$3d17e6c0$6501a8c0@Ropy> From: "Roy Williams" To: "Guy Rixon" Cc: References: Subject: web services for remote execution Date: Fri, 24 Sep 2004 08:29:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.23.6 Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy I have been watching some the emails, wondering if any of them fit what I want to do. O'Mullane and his RunID seems relevant, The GGF document on "Scenarios for mapping DAIS concepts" seems relevant. I am building an infrastructure for Science Gateways on the grid. This is a set of secure web services that allow execution and monitoring of batch jobs. It is intended to be used with a set of web pages to expose particular functionality (eg astronomical mosaicking, seismic simulations, etc). The web services would allow: 1. Creation of a session on the server, including creation of file space, and return of sessionID 2. Put and Get to the file space of a session 3. Execution of an arbitrary Unix command on the server, which includes: -- Queuing jobs on the server as part of session -- Monitoring status of remote jobs using sessionID 4. Removing and deleting a session and its files I am close to defining my own service interface (WSDL) for these actions. Before I do so, can you (or anyone else) tell me if anyone else has already done this (CEA? CondorSOAP? GGF?) Thank You Roy -------- California Institute of Technology roy@caltech.edu 626 395 3670 From owner-grid@eso.org Fri Sep 24 21:03:15 2004 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 i8OJ2msE018747 for ; Fri, 24 Sep 2004 21:02:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8OJ2m4d018746 for grid-outgoing; Fri, 24 Sep 2004 21:02:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 i8OJ2msE018742 for ; Fri, 24 Sep 2004 21:02:48 +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 i8OJ2k0o025896 for ; Fri, 24 Sep 2004 21:02:46 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:52005) by ppsw-5.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.145]:25) with esmtp (Exim 4.34) id 1CAvLA-0006p6-Qk (return-path ); Fri, 24 Sep 2004 20:02:44 +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 i8OJ2ise016181; Fri, 24 Sep 2004 20:02:44 +0100 (BST) Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i8OJ2ifZ006818; Fri, 24 Sep 2004 20:02:44 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i8OJ2h98006815; Fri, 24 Sep 2004 20:02:44 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 24 Sep 2004 20:02:43 +0100 (BST) From: Guy Rixon To: Roy Williams cc: grid@ivoa.net Subject: Re: web services for remote execution In-Reply-To: <014c01c4a24b$3d17e6c0$6501a8c0@Ropy> Message-ID: References: <014c01c4a24b$3d17e6c0$6501a8c0@Ropy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.24.0 Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Roy, it's all been done before, somewhere. What you're describing is a classical compute-grid. Loadsa prior art. The particular form you suggest - execution of a restricted set of pre-installed apps - is CEA's speciality (CEA is a grid job-manager, in case you were wondering. CEA does the session-cretaion bit (will send architectural links next week). It imports and exports files but does not otherwise do the file space. Globus WS-GRAM also does this. IVOA async-activities specifies the session-creation interface. OGSA will also specify this (no details available yet). This also handles cleaning up the files afterwards. IVOA async activities are based on WS-RF; WSRF.NET is out (U of Virginia) and seems rather good - I have a detailed tutorial example for using it if you wish. MySpace does file management. GGF's GFS also does so (no implementations yet). VOSpace and VOStore will also handle this. Condor and Grid Engine are good systems for sessions on local clusters. DRMAA is GGF's standard API for talking to these from an application - and it's implemented for both. CEA may get a link into GridEngine via DRMAA quite soon. CEA does execution of Unix apps. If I have my way, it will be made cluster-aware (the DRMAA thing, above) for these same apps. Let me know if you want more details. I'm off to Pune, so will be off-line until Monday. Cheers, Guy On Fri, 24 Sep 2004, Roy Williams wrote: > Guy > > I have been watching some the emails, wondering if any of them fit what I want to do. > O'Mullane and his RunID seems relevant, The GGF document on "Scenarios for mapping DAIS > concepts" seems relevant. > > I am building an infrastructure for Science Gateways on the grid. This is a set of secure > web services that allow execution and monitoring of batch jobs. It is intended to be used > with a set of web pages to expose particular functionality (eg astronomical mosaicking, > seismic simulations, etc). > > The web services would allow: > > 1. Creation of a session on the server, including creation of file space, and return of > sessionID > > 2. Put and Get to the file space of a session > > 3. Execution of an arbitrary Unix command on the server, which includes: > -- Queuing jobs on the server as part of session > -- Monitoring status of remote jobs using sessionID > > 4. Removing and deleting a session and its files > > I am close to defining my own service interface (WSDL) for these actions. Before I do so, > can you (or anyone else) tell me if anyone else has already done this (CEA? CondorSOAP? > GGF?) > > Thank You > Roy > > > -------- > California Institute of Technology > roy@caltech.edu > 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-apps@eso.org Thu Sep 30 13:46:00 2004 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 i8UBjkQc009352 for ; Thu, 30 Sep 2004 13:45:46 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8UBjkni009350 for apps-outgoing; Thu, 30 Sep 2004 13:45:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@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 i8UBjfQc009336; Thu, 30 Sep 2004 13:45:41 +0200 (MEST) Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8UBjdSV005139; Thu, 30 Sep 2004 13:45:40 +0200 (CEST) Received: from star1.jb.man.ac.uk ([130.88.24.176]) by curlew.cs.man.ac.uk with esmtp (Exim 4.20) id 1CCzNT-0005XF-Lr; Thu, 30 Sep 2004 12:45:39 +0100 Received: from [130.88.9.114] (helo=[130.88.9.114]) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1CCzNT-0006zE-00; Thu, 30 Sep 2004 12:45:39 +0100 Message-ID: <415BF1E7.3080900@jb.man.ac.uk> Date: Thu, 30 Sep 2004 12:45:43 +0100 From: Paul Harrison Organization: JBO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en, en-us MIME-Version: 1.0 To: grid@ivoa.net, apps@ivoa.net Subject: new draft of CEA note Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1CCzNT-0005XF-Lr*1/JxwabOhME* X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.29.6 X-Virus-Scanned: by amavisd-new Sender: owner-apps@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: There is a new (internal) draft of the CEA architecture note at http://www.astrogrid.org/maven/docs/snapshot/applications/design/CEADesignIVOANote.html Note that Astrogrid does have working a implementation of this architecture (http://www.astrogrid.org/maven/docs/snapshot/applications/) and a scriptable workflow engine (http://www.astrogrid.org/maven/docs/snapshot/jes/) for running complex jobs including calls to CEA compilant web services. I would be interested to discuss with anyone at ADASS 2004 whether this architecture meets their needs, and where extensions would be appropriate. This workflow capability will form a central part of the Jan 2005 AVO DEMO (http://www.euro-vo.org/twiki/bin/view/Avo/AvoDemo2005). Paul. -- -- Dr. Paul Harrison, Astrogrid Developer MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572681 (direct), 571321 (switch) - 07904025192 (mobile). From owner-grid@eso.org Sun Oct 3 22:08:48 2004 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 i93K8AGO015827 for ; Sun, 3 Oct 2004 22:08:10 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i93K89vf015826 for grid-outgoing; Sun, 3 Oct 2004 22:08:09 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 i93K86GO015820 for ; Sun, 3 Oct 2004 22:08:07 +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 i93K84SV029815 for ; Sun, 3 Oct 2004 22:08:05 +0200 (CEST) Received: (from moore@localhost) by postal.sdsc.edu (8.11.7/8.11.7/server/68) id i93K82d14531; Sun, 3 Oct 2004 13:08:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu Message-Id: In-Reply-To: <014c01c4a24b$3d17e6c0$6501a8c0@Ropy> References: <014c01c4a24b$3d17e6c0$6501a8c0@Ropy> Date: Sun, 3 Oct 2004 11:34:40 -0700 To: "Roy Williams" From: Reagan Moore Subject: Re: web services for remote execution Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.10.2.1 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Reagan Moore X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Roy: Various grid portals also provide many of the features you are seeking. The NMI portal provides a way to interact with grid resources, list files, execute commands, and some of them interact with SRB collections. The portal environments are converging on JSR170 as a common interoperability specification for importing portlets from other communities. Reagan >Guy > >I have been watching some the emails, wondering if any of them fit >what I want to do. >O'Mullane and his RunID seems relevant, The GGF document on >"Scenarios for mapping DAIS >concepts" seems relevant. > >I am building an infrastructure for Science Gateways on the grid. >This is a set of secure >web services that allow execution and monitoring of batch jobs. It >is intended to be used >with a set of web pages to expose particular functionality (eg >astronomical mosaicking, >seismic simulations, etc). > >The web services would allow: > >1. Creation of a session on the server, including creation of file >space, and return of >sessionID > >2. Put and Get to the file space of a session > >3. Execution of an arbitrary Unix command on the server, which includes: >-- Queuing jobs on the server as part of session >-- Monitoring status of remote jobs using sessionID > >4. Removing and deleting a session and its files > >I am close to defining my own service interface (WSDL) for these >actions. Before I do so, >can you (or anyone else) tell me if anyone else has already done >this (CEA? CondorSOAP? >GGF?) > >Thank You >Roy > > >-------- >California Institute of Technology >roy@caltech.edu >626 395 3670 From owner-grid@eso.org Thu Nov 4 19:56:04 2004 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 iA4IqLf7007171 for ; Thu, 4 Nov 2004 19:52:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iA4IqLhu007170 for grid-outgoing; Thu, 4 Nov 2004 19:52:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 iA4IqHf7007155 for ; Thu, 4 Nov 2004 19:52:18 +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 iA4IqFG6005547 for ; Thu, 4 Nov 2004 19:52:16 +0100 (CET) Received: from Ropy (dsl-64-30-223-60.lcinet.net [64.30.223.60]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id iA4IqE4I028500 for ; Thu, 4 Nov 2004 10:52:14 -0800 Message-ID: <01b701c4c29f$65c4a030$6501a8c0@Ropy> From: "Roy Williams" To: Subject: HotGrid paper Date: Thu, 4 Nov 2004 10:52:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.4.0 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is to direct you to: "HotGrid: Graduated Access to Grid-based Science Gateways", by Roy Williams, Conrad Steenberg, and Julian Bunn, which we have submitted to a conference. The objective is to greatly simplify the use of the Grid and thereby bring it to a much wider community. Your comments welcome. Full text version is available at http://us-vo.org/pubs/files/hotgrid.pdf Abstract. We describe the idea of a Science Gateway, an application specific task wrapped as a web service, and some examples of these that are being implemented on the US TeraGrid cyberinfrastructure. We also describe HotGrid, a means of providing simple, immediate access to the Grid through one of these gateways, which we hope will broaden the use of the Grid, drawing in a wide community of users. The secondary purpose of HotGrid is to acclimate a science community to the concepts of certificate use. Our system provides these weakly authenticated users with immediate power to use the Grid resources for science, but without the dangerous power of running arbitrary code. We describe the implementation of these Science Gateways with the Clarens secure web server. -------- California Institute of Technology roy@caltech.edu 626 395 3670 From owner-grid@eso.org Tue Nov 9 19:40:55 2004 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 iA9IeVU4017253 for ; Tue, 9 Nov 2004 19:40:31 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iA9IeV8b017252 for grid-outgoing; Tue, 9 Nov 2004 19:40:31 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 iA9IeRU4017245 for ; Tue, 9 Nov 2004 19:40:28 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iA9IeP2i021863 for ; Tue, 9 Nov 2004 19:40:26 +0100 (CET) Received: from localhost (nieto@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id iA9IeNx24393 for ; Tue, 9 Nov 2004 13:40:24 -0500 Date: Tue, 9 Nov 2004 13:40:23 -0500 (EST) From: "Maria A. Nieto-Santisteban" To: grid@ivoa.net Subject: The Grid and Database Management Systems 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.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.9.1 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Maria A. Nieto-Santisteban" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dear all, I'm doing some (re)search about how database management systems are being used on the Grid to do data analysis or data mining (whatever is your preferred term). >From what I have been reading, it seems that the Grid middleware that allows interaction to different DBMS is OGSA-DAI http://www.ogsadai.org.uk/docs/docs.php#current As a member of the IVOA, I'm specially interested in astronomy applications, but not restricted to them. So if any body knows about real applications in other disciplines, I am eager to hear about them! I would like to know HOW and WHAT specific astronomy applications and catalogs are using the OGSA-DAI software. What DBMS are being used: DB2, MySQL, SQL Server, Oracle, PostgreSQL, Xindice, eXist? According to OGSA-DAI, Astrogrid is one of the projects using their software. Is Astrogrid using any of these DBMS or only the flat files capabilities? Any known application from NVO? A more general question about the infrastructure of the Grid: Can anybody tell me what Grid nodes (if any) support database management systems? Are they tide to specific disciplines projects like Biology, Astronomy, Chemistry, etc or are they available for general use (providing the user has a proper certificate)? I am mostly interested in something similar to what CasJobs offers http://casjobs.sdss.org/CasJobs/ A place where I can create my own relational database, and I have full power to create tables, indexes, functions, stored procedures, etc. CasJobs is related to the SDSS project but nothing obligates the user to work with SDSS data. In principle, MyDB can be used with any data the user is willing to load. That's the type of capabilities I am looking for on Grid nodes. Do they currently exist? If not, is there any plan to provide them? I really would appreciate any information you can provide me. Feel free to redirect this e-mail to anybody you might think can give an answer :) Thanks, Maria From owner-grid@eso.org Thu Dec 2 18:01:29 2004 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 iB2H14MV016157 for ; Thu, 2 Dec 2004 18:01:04 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iB2H148a016156 for grid-outgoing; Thu, 2 Dec 2004 18:01:04 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 iB2H0wMV016146 for ; Thu, 2 Dec 2004 18:00:59 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iB2H0u2i013945 for ; Thu, 2 Dec 2004 18:00:57 +0100 (CET) Received: from localhost (budavari@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id iB2GhMF19585 for ; Thu, 2 Dec 2004 11:43:23 -0500 X-Authentication-Warning: skysrv.pha.jhu.edu: budavari owned process doing -bs Date: Thu, 2 Dec 2004 11:43:22 -0500 (EST) From: Tamas Budavari To: grid@ivoa.net Subject: XML-binary Optimized Packaging Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.12.1.36 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Tamas Budavari X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: For those you who haven't seen it, yet: MTOM and XOP are now W3C Proposed Recommendations (16 November 2004), so the final may be only few weeks away? SOAP Message Transmission Optimization Mechanism http://www.w3.org/TR/soap12-mtom/ XML-binary Optimized Packaging http://www.w3.org/TR/xop10/ Cheers, T. From owner-registry@eso.org Tue Dec 14 08:51:20 2004 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 iBE7p1KW026304 for ; Tue, 14 Dec 2004 08:51:01 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iBE7p143026303 for registry-outgoing; Tue, 14 Dec 2004 08:51:01 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@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 iBE7ouKW026294; Tue, 14 Dec 2004 08:50:57 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iBE7osRQ027702; Tue, 14 Dec 2004 08:50:54 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id iBE7ok201922; Tue, 14 Dec 2004 01:50:46 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id iBE7omWh022915; Tue, 14 Dec 2004 01:50:48 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id iBE7omPS022911; Tue, 14 Dec 2004 01:50:48 -0600 Date: Tue, 14 Dec 2004 01:50:48 -0600 (CST) From: Ray Plante To: "Matthew J. Graham" cc: Registry List , Subject: Re: Registry Interface and SOAP versions In-Reply-To: <3A31AB3B-47C9-11D9-9521-000D93AE2542@cacr.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.12.13.48 X-Virus-Scanned: by amavisd-new Sender: owner-registry@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 6 Dec 2004, Matthew J. Graham wrote: > What version of SOAP is the Registry Interface WSDL supposed to be > supporting? This certainly needs to be stated explicitly in the RI spec. When I looked into this issue earlier this year, it appeared we were supporting 1.1. Our leading toolkits supported SOAP 1.1 by default. Furthermore, we were using WSDL 1.0 which defines binding only for SOAP 1.1. Given this, it seemed sensible to go with 1.1. I'm not sure it's prudent to go to SOAP 1.2 while WSDL 2.0 is still in WD, unless someone can spell out clearly how 1.2 can be used with WSDL 1.0 (using the usual toolkits). > Does this mean that we are only supporting SOAP 1.1? If so, what is the > timeline for moving to SOAP 1.2 support, which, after all, has been a > W3C Recommendation for over a year and a half? It would be good to get a statement from the Grid&WS WG on this issue. cheers, Ray From owner-registry@eso.org Tue Dec 14 09:41:48 2004 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 iBE8fZqr002701 for ; Tue, 14 Dec 2004 09:41:36 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iBE8fZKk002700 for registry-outgoing; Tue, 14 Dec 2004 09:41:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@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 iBE8fUqr002650; Tue, 14 Dec 2004 09:41:30 +0100 (MET) 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 iBE8fS2i002398; Tue, 14 Dec 2004 09:41:28 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:59200) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp id 1Ce8FF-0008NX-I2 (Exim 4.44) (return-path ); Tue, 14 Dec 2004 08:41:21 +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.12.10+Sun/8.12.10) with ESMTP id iBE8fLGn009459; Tue, 14 Dec 2004 08:41:21 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id iBE8fLIM028865; Tue, 14 Dec 2004 08:41:21 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id iBE8fKjq028862; Tue, 14 Dec 2004 08:41:20 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 14 Dec 2004 08:41:20 +0000 (GMT) From: Guy Rixon To: Ray Plante cc: "Matthew J. Graham" , Registry List , grid@ivoa.net Subject: Re: Registry Interface and SOAP versions In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.12.13.48 X-Virus-Scanned: by amavisd-new Sender: owner-registry@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The intention is to follow the WS-I profile for interoperability. Their current "basic profile" is v1.1, available at http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html It says: "This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them: * Simple Object Access Protocol (SOAP) 1.1 [...]" So yes, SOAP 1.1 please. The timing of a move to SOAP 1.2 would depend on WS-I. I'll investigate. Cheers, Guy On Tue, 14 Dec 2004, Ray Plante wrote: > On Mon, 6 Dec 2004, Matthew J. Graham wrote: > > What version of SOAP is the Registry Interface WSDL supposed to be > > supporting? > > This certainly needs to be stated explicitly in the RI spec. When I > looked into this issue earlier this year, it appeared we were supporting > 1.1. Our leading toolkits supported SOAP 1.1 by default. Furthermore, we > were using WSDL 1.0 which defines binding only for SOAP 1.1. Given this, > it seemed sensible to go with 1.1. > > I'm not sure it's prudent to go to SOAP 1.2 while WSDL 2.0 is still in WD, > unless someone can spell out clearly how 1.2 can be used with WSDL 1.0 > (using the usual toolkits). > > > Does this mean that we are only supporting SOAP 1.1? If so, what is the > > timeline for moving to SOAP 1.2 support, which, after all, has been a > > W3C Recommendation for over a year and a half? > > It would be good to get a statement from the Grid&WS WG on this issue. > > cheers, > Ray > > 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-registry@eso.org Tue Dec 14 10:13:40 2004 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 iBE9DE02006576 for ; Tue, 14 Dec 2004 10:13:14 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iBE9DEwA006575 for registry-outgoing; Tue, 14 Dec 2004 10:13:14 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@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 iBE9DA02006570; Tue, 14 Dec 2004 10:13:10 +0100 (MET) Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iBE9D8RQ000024; Tue, 14 Dec 2004 10:13:08 +0100 (CET) Received: (from nobody@localhost) by newb6.u-strasbg.fr (8.9.3/8.9.3) id KAA16593; Tue, 14 Dec 2004 10:11:28 +0100 (MET) X-Authentication-Warning: newb6.u-strasbg.fr: nobody set sender to schaaff@astro.u-strasbg.fr using -f To: Guy Rixon Subject: Re: Registry Interface and SOAP versions Message-ID: <1103015487.41beae3fef16d@astro.u-strasbg.fr> Date: Tue, 14 Dec 2004 10:11:27 +0100 (MET) From: Andre Schaaff Cc: Ray Plante , "Matthew J. Graham" , Registry List , grid@ivoa.net References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.12.13.53 X-Virus-Scanned: by amavisd-new Sender: owner-registry@eso.org Precedence: bulk Reply-To: Andre Schaaff X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: ... and concerning the WS-I profiles, the SOAP 1.2 integration seems not to be clearly defined ... probably nothing to expect before a few (or more !) months André Quoting Guy Rixon : > The intention is to follow the WS-I profile for interoperability. Their > current "basic profile" is v1.1, available at > > http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html > > It says: > > "This section of the Profile incorporates the following specifications > by > reference, and defines extensibility points within them: > > * Simple Object Access Protocol (SOAP) 1.1 [...]" > > So yes, SOAP 1.1 please. The timing of a move to SOAP 1.2 would depend > on > WS-I. I'll investigate. > > Cheers, > Guy > > On Tue, 14 Dec 2004, Ray Plante wrote: > > > On Mon, 6 Dec 2004, Matthew J. Graham wrote: > > > What version of SOAP is the Registry Interface WSDL supposed to be > > > supporting? > > > > This certainly needs to be stated explicitly in the RI spec. When I > > looked into this issue earlier this year, it appeared we were > supporting > > 1.1. Our leading toolkits supported SOAP 1.1 by default. > Furthermore, we > > were using WSDL 1.0 which defines binding only for SOAP 1.1. Given > this, > > it seemed sensible to go with 1.1. > > > > I'm not sure it's prudent to go to SOAP 1.2 while WSDL 2.0 is still in > WD, > > unless someone can spell out clearly how 1.2 can be used with WSDL > 1.0 > > (using the usual toolkits). > > > > > Does this mean that we are only supporting SOAP 1.1? If so, what is > the > > > timeline for moving to SOAP 1.2 support, which, after all, has been > a > > > W3C Recommendation for over a year and a half? > > > > It would be good to get a statement from the Grid&WS WG on this > issue. > > > > cheers, > > Ray > > > > > > Guy Rixon gtr@ast.cam.ac.uk > Institute of Astronomy Tel: +44-1223-337542 > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523 > -- André Schaaff Observatoire Astronomique 11, rue de l'Université F-67000 Strasbourg From owner-grid@eso.org Wed Jan 19 12:52: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 j0JBpXMF010930 for ; Wed, 19 Jan 2005 12:51:34 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j0JBpXSX010929 for grid-outgoing; Wed, 19 Jan 2005 12:51:33 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j0JBpTMF010921 for ; Wed, 19 Jan 2005 12:51:29 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j0JBpR57001374 for ; Wed, 19 Jan 2005 12:51:27 +0100 (CET) Message-Id: <200501191151.j0JBpR57001374@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by apollo.le.ac.uk with smtp (Exim 4.43) id 1CrEMs-0003he-A2 for grid@ivoa.net; Wed, 19 Jan 2005 11:51:22 +0000 Received: (qmail 4116 invoked from network); 19 Jan 2005 11:51:08 -0000 Received: from agforum.star.le.ac.uk (HELO gnowee) (143.210.36.14) by mail.star.le.ac.uk with SMTP; 19 Jan 2005 11:51:08 -0000 From: "Tony Linde" To: "Grid_Ivoa_List" Subject: FW: Emerging Technologies for Next generation GRID (ETNGRID-2005) Date: Wed, 19 Jan 2005 11:50:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT32v1usW7bH1rASn2EGmAg6e+SpwGQeTZA X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.1.19.1 X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id j0JBpXMF010926 Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: fyi... -----Original Message----- From: Carole Goble Sent: 11 January 2005 12:40 To: ... Subject: Emerging Technologies for Next generation GRID (ETNGRID-2005) Apologies for multiple postings Carole =========================================================================== Second Workshop on Emerging Technologies for Next generation GRID (ETNGRID-2005) 14th IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises (WETICE-2005) http://www.diit.unict.it/users/csanto/etngrid05/ Linkoping University, Sweden, June 13-15, 2005 ***** SUBMISSION DEADLINE: Feb. 11, 2005 ***** =========================================================================== The Grid was originally designed as a large network of computer systems able to offer an environment where computing and storage resources are shared on-demand. To date, the development of standards, such as the Open Grid Service Architecture (OGSA), along with the introduction of new paradigms, such as the Semantic Grid, is leading the Grid toward an environment that is not only suited for computational-intensive applications, but also for computing scenarios typical of distributed systems, like service and information providing, multimedia environments, ubiquitous computing, etc. For these and other reasons, the Grid is becoming an interesting and challenging environment supporting both old and new services for cooperative applications. A relevant research effort is thus needed not only to investigate innovative Grid infrastructures but also to make the current Grid model suitable for these emerging usage scenarios. The objective of this workshop is to gather researchers working on different emerging Grid computing aspects relevant to enterprise collaboration, covering issues ranging from the middleware layer to application development and user interaction. The goals of the workshop include (but are not limited to) discovering new application scenarios, proposing new programming abstractions and tools, identifying the challenging problem that still need to be solved, and reporting results and experiences gained by researchers in building Grid-based middleware, applications and alike. Submission Requirements ----------------------- Participants are expected to submit an original research paper or a position paper, not submitted or published elsewhere, by email to Corrado Santoro, corrado.santoro@diit.unict.it (make sure that the subject of the email says "ETNGRID'05 Submission"). Submission should include the title of the paper, the names and affiliations of the authors, a 150-word abstract and at most eight keywords. Submission should follow the IEEE format (single spaced, two columns, 10pt, Times font) and not exceed six pages, including figures. Accepted papers will be published along with the WETICE 2005 post-proceedings. The paper should be in either PS or PDF format. Papers must focus on collaborative aspects of the Grid, including, but not limiting to, the following topics: * Middlewares for the Grid * Multimedia applications with the Grid * Reflective and Aspect-Oriented Grid systems * Reliability and Quality-of-Service aspects * Wireless and ubiquitous access to the Grid * Cooperative Agents and the Grid * Grids and Peer-to-peer systems * Web integration with the Grid * Abstractions and tools for collaborative application development in Grid environments * Semantic Grid * Experience reports on collaborative application development in Grid * Scalability and Performance issues in the Grid * Analysis of stability and bottlenecks for Grid applications * Resource-aware applications in the Grid * Architectures for Grid-oriented applications * Security and Verification Issues in Large Distributed Systems Important Dates --------------- * Paper Submission: February 11, 2005 * Notification of Acceptance: March 18, 2005 * Camera Ready Paper Due: May 9, 2005 Program Co-Chairs ----------------- Angelo Corsaro (acorsaro@amsjv.it), Alenia Marconi Systems, ITALY Antonella Di Stefano (adistefa@diit.unict.it), Dept. of Computer and Telecommunication Engineering, Engineering Faculty, University of Catania, ITALY Giuseppe Pappalardo (pappalardo@dmi.unict.it), Dept. of Computer Science and Mathematics, Computer Science Faculty, University of Catania, ITALY Corrado Santoro (csanto@diit.unict.it), Dept. of Computer and Telecommunication Engineering, Engineering Faculty, University of Catania, ITALY Emiliano Tramontana (tramontana@dmi.unict.it), Dept. of Computer Science and Mathematics, Computer Science Faculty, University of Catania, ITALY Program Committee Members ------------------------- M.Nedim Alpdemir ........ University of Manchester, UK Cosimo Anglano .......... University of Piemonte Orientale, Italy Roberto Barbera ......... University of Catania, Italy Walter Cazzola .......... University of Milano, Italy Giovanni Chiola ......... University of Genova, Italy Paolo Ciancarini ........ University of Bologna, Italy Michele Colajanni ....... University of Modena and Reggio Emilia, Italy Geoffrey Coulson ........ Lancaster Universtity, UK Marco Fargetta .......... University of Catania, Italy Geoffrey Fox ............ Indiana University, USA Carol Goble ............. University of Manchester, UK Aniruddha Gokhale ....... Vanderbilt University, USA Pilar Herrero ........... Universidad Politécnica de Madrid, Spain Giulio Iannello ......... University of Naples Federico II, Italy Ryszard Janicki ......... McMaster University, Canada Maciej Koutny ........... University of Newcastle upon Tyne, UK Luigi Mancini ........... University of Roma "La Sapienza", Italy Sara Tucci Piergiovanni.. University of Roma "La Sapienza", Italy Agostino Poggi .......... University of Parma, Italy Svetlana Shasharina ..... Tech-X Corporation, USA Santosh Shrivastava ..... University of Newcastle upon Tyne, UK Giorgio Ventre .......... University of Naples Federico II, Italy Stephen Vinoski ......... IONA Technologies, USA Luca Vollero ............ CINI ITeM, Italy Ian Welch ............... Victoria University of Wellington, New Zealand Steven Willmott ......... Universitat Politècnica de Catalunya, Spain Nanbor Wang ............. Tech-X Corporation, USA From owner-grid@eso.org Fri Jan 28 17:23:26 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 j0SGN4BV018713 for ; Fri, 28 Jan 2005 17:23:04 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j0SGN4oo018712 for grid-outgoing; Fri, 28 Jan 2005 17:23:04 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j0SGMwBV018694 for ; Fri, 28 Jan 2005 17:22:58 +0100 (MET) Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j0SGMvhA006707 for ; Fri, 28 Jan 2005 17:22:57 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:47798) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp id 1CuYtN-0006je-JB (Exim 4.44) for grid@ivoa.net (return-path ); Fri, 28 Jan 2005 16:22:41 +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.12.10+Sun/8.12.10) with ESMTP id j0SGMfoL021214 for ; Fri, 28 Jan 2005 16:22:41 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j0SGMfoi003124 for ; Fri, 28 Jan 2005 16:22:41 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j0SGMfZg003121 for ; Fri, 28 Jan 2005 16:22:41 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 28 Jan 2005 16:22:41 +0000 (GMT) From: Guy Rixon To: grid@ivoa.net Subject: Universal Worker Service Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.1.28.3 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I have just attched to the GWS-WG wiki-page a draft of an IVOA recommendation for a "univeral worker service". This is a formalization of the Asynchronous activities proposal, with more detail added. The proposed interface unifies the AstroGrid CEA ideas with the emerging grid infrastructure (WS-RF). Your comments are invited. 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-grid@eso.org Fri Mar 4 02:28: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 j241S3EZ023788 for ; Fri, 4 Mar 2005 02:28:03 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j241S3kp023787 for grid-outgoing; Fri, 4 Mar 2005 02:28:03 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j241RxEZ023768 for ; Fri, 4 Mar 2005 02:27:59 +0100 (MET) Received: from mailhost.cacr.caltech.edu (mailhost.cacr.caltech.edu [131.215.145.180]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j241RuHG023539 for ; Fri, 4 Mar 2005 02:27:57 +0100 (CET) Received: from [131.215.146.187] ([131.215.146.187]) by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with ESMTP id RAA04309 for ; Thu, 3 Mar 2005 17:27:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: grid@ivoa.net From: "Matthew J. Graham" Subject: PKCS12 KeyStore and trusted certificates Date: Thu, 3 Mar 2005 17:27:20 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.3.17 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Matthew J. Graham" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I am using Java 1.4.2_05, creating a PKCS12 KeyStore and trying to load the certificate of my CA; however, I get a nice error message that "TrustedCertEntry not supported". Does anyone have any experience with this? I think it is a problem with the standard KeyStore implementation - does BouncyCastle support this? Cheers, Matthew From owner-grid@eso.org Wed Mar 9 18:10:56 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 j29HAZC1017126 for ; Wed, 9 Mar 2005 18:10:35 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j29HAZqg017125 for grid-outgoing; Wed, 9 Mar 2005 18:10:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j29HATC1017112 for ; Wed, 9 Mar 2005 18:10:29 +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 j29HARhA016411 for ; Wed, 9 Mar 2005 18:10:27 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:61494) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1D94hM-0004mI-D9 (Exim 4.44) for grid@ivoa.net (return-path ); Wed, 09 Mar 2005 17:10:16 +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.12.10+Sun/8.12.10) with ESMTP id j29HAEoL021416 for ; Wed, 9 Mar 2005 17:10:14 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j29HAERN020508 for ; Wed, 9 Mar 2005 17:10:14 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j29HAEcu020505 for ; Wed, 9 Mar 2005 17:10:14 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 9 Mar 2005 17:10:14 +0000 (GMT) From: Guy Rixon To: grid@ivoa.net Subject: SSO authentication: a new approach Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.9.7 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi everybody! The 2004 discussions of single-sign-on authentication stalled due to disagreements and misunderstanding about the trust model. Since then, there have been other discussions about this (in AstroGrid and in EuroVO-VOTech and among the GWS members discussing VOStore). From this, I've synthesized a trust model that seems to work and which defines the architecture of an SSO system that we could use. Here's the initial document: http://wiki.astrogrid.org/bin/view/Astrogrid/TrustModelForVO (VOTech and AG people: it's compatible with what I said at the DS-3 meeting.) (VOStore people: it's a poshed-up version of what we discussed earlier this week.) If this finds favour, then I'll write it up as an IVOA document. It would be good if we could get some consensus on this trust model and excellent if it could be agreed by or during the Kyoto interop. Please note that the trust model sets the requirements for the SSO protocols. Until we sort out the trust model we can't sort out SSO. 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-grid@eso.org Thu Mar 10 11:43: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 j2AAhKR5019900 for ; Thu, 10 Mar 2005 11:43:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2AAhKo3019898 for grid-outgoing; Thu, 10 Mar 2005 11:43:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2AAhGR5019870 for ; Thu, 10 Mar 2005 11:43:16 +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 j2AAhFkW010467 for ; Thu, 10 Mar 2005 11:43:15 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:33266) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1D9L8C-00062f-EW (Exim 4.44) for grid@ivoa.net (return-path ); Thu, 10 Mar 2005 10:43:04 +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.12.10+Sun/8.12.10) with ESMTP id j2AAh4oL011507 for ; Thu, 10 Mar 2005 10:43:04 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2AAh4RN021436 for ; Thu, 10 Mar 2005 10:43:04 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2AAh3PR021433 for ; Thu, 10 Mar 2005 10:43:04 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 10 Mar 2005 10:43:03 +0000 (GMT) From: Guy Rixon To: grid@ivoa.net Subject: VOSpace discussion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.10.0 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Two meetings were held on 2005-03-07 in which VOStore and VOSpace were discussed. The minutes are at http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceBrainstormMeeting These were not official IVOA meetings, but should inform the discussion on this list. The people protoyping VOStore were present. 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-grid@eso.org Thu Mar 10 12:26: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 j2ABQKR5026285 for ; Thu, 10 Mar 2005 12:26:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2ABQKwH026284 for grid-outgoing; Thu, 10 Mar 2005 12:26:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2ABQGR5026276 for ; Thu, 10 Mar 2005 12:26:17 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.4.129]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2ABQDpB000210 for ; Thu, 10 Mar 2005 12:26:13 +0100 (CET) Message-Id: <200503101126.j2ABQDpB000210@rocky.hq.eso.org> Received: from [143.210.36.14] (helo=gnowee) by artemis.le.ac.uk with esmtp (Exim 4.44) id 1D9Lnr-0005Zb-LK for grid@ivoa.net; Thu, 10 Mar 2005 11:26:07 +0000 From: "Tony Linde" To: Subject: RE: VOSpace discussion Date: Thu, 10 Mar 2005 11:26:05 -0000 Organization: University of Leicester MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUlYr25h+7Sav97S+q2CwoLacyrLQAAOcIQ X-UoL-Id: 975e1f30b9281700c3b86d2dc2e25ecb@1D9Lnr-0005Zb-LK@artemis.le.ac.uk X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.10.2 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I've asked the organisers of the Kyoto Interop meeting for a BOF at which VOSpace can be discussed prior to a new workgroup being established (did this before I knew it had been raised in this forum). I still think VOSpace needs its own workgroup but will open the discussion here. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 10 March 2005 10:43 > To: grid@ivoa.net > Subject: VOSpace discussion > > Two meetings were held on 2005-03-07 in which VOStore and > VOSpace were discussed. The minutes are at > > http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceBrainstormMeeting > > These were not official IVOA meetings, but should inform the > discussion on this list. The people protoyping VOStore were present. > > 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-grid@eso.org Thu Mar 10 13:19:26 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 j2ACJ7R5003155 for ; Thu, 10 Mar 2005 13:19:07 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2ACJ7ud003154 for grid-outgoing; Thu, 10 Mar 2005 13:19:07 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2ACJ1R5003133 for ; Thu, 10 Mar 2005 13:19:01 +0100 (MET) Received: from apollo.le.ac.uk (apollo.le.ac.uk [143.210.16.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2ACIxkW013479 for ; Thu, 10 Mar 2005 13:19:00 +0100 (CET) Message-Id: <200503101219.j2ACIxkW013479@apollo.hq.eso.org> Received: from [143.210.36.14] (helo=gnowee) by apollo.le.ac.uk with esmtp (Exim 4.44) id 1D9Mcw-0002fP-MY for grid@ivoa.net; Thu, 10 Mar 2005 12:18:54 +0000 From: "Tony Linde" To: Subject: RE: VOSpace discussion Date: Thu, 10 Mar 2005 12:18:51 -0000 Organization: University of Leicester MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200503101126.j2ABQDpB000210@rocky.hq.eso.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUlYr25h+7Sav97S+q2CwoLacyrLQAAOcIQAAHj9WA= X-UoL-Id: 9f18aa4e0a502ed64d41796ca6a554b8@1D9Mcw-0002fP-MY@apollo.le.ac.uk X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.10.3 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Scratch that - Guy is going for three GWS sessions, one of which will target VOSpace - so BOF will not happen. T. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Tony Linde > Sent: 10 March 2005 11:26 > To: grid@ivoa.net > Subject: RE: VOSpace discussion > > I've asked the organisers of the Kyoto Interop meeting for a > BOF at which VOSpace can be discussed prior to a new > workgroup being established (did this before I knew it had > been raised in this forum). I still think VOSpace needs its > own workgroup but will open the discussion here. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy > > Rixon > > Sent: 10 March 2005 10:43 > > To: grid@ivoa.net > > Subject: VOSpace discussion > > > > Two meetings were held on 2005-03-07 in which VOStore and > VOSpace were > > discussed. The minutes are at > > > > http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceBrainstormMeeting > > > > These were not official IVOA meetings, but should inform the > > discussion on this list. The people protoyping VOStore were present. > > > > 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-grid@eso.org Thu Mar 10 13:35:15 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 j2ACYuR5005560 for ; Thu, 10 Mar 2005 13:34:56 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2ACYuJP005556 for grid-outgoing; Thu, 10 Mar 2005 13:34:56 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2ACYrR5005547 for ; Thu, 10 Mar 2005 13:34:53 +0100 (MET) 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 j2ACYq213262 for ; Thu, 10 Mar 2005 13:34:52 +0100 (MET) Message-ID: <42303EEC.9010804@jb.man.ac.uk> Date: Thu, 10 Mar 2005 13:34:52 +0100 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: grid@ivoa.net Subject: Re: SSO authentication: a new approach 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-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I agree that this is the best starting point to create an architecture - in addition to the text, a diagram would be useful to illustrate the trust domains (with their contents) and the trust relationships between them. I think that this is a pretty good starting point. I have a couple of issues though * In the document you talk about "less-trusted" entities - surely in a trust model something should either be trusted or not-trusted, there can be no degrees of trust. * I think that there should be some discussion of what should be done in the case where there needs to be a trust relationship set up between the an existing authentication system (e.g. the existing particle physics Grids) and the IVOA one. Guy Rixon wrote: >Hi everybody! > >The 2004 discussions of single-sign-on authentication stalled due to >disagreements and misunderstanding about the trust model. Since then, there >have been other discussions about this (in AstroGrid and in EuroVO-VOTech and >among the GWS members discussing VOStore). From this, I've synthesized a trust >model that seems to work and which defines the architecture of an SSO system >that we could use. Here's the initial document: > > http://wiki.astrogrid.org/bin/view/Astrogrid/TrustModelForVO > >(VOTech and AG people: it's compatible with what I said at the DS-3 meeting.) > >(VOStore people: it's a poshed-up version of what we discussed earlier this >week.) > >If this finds favour, then I'll write it up as an IVOA document. > >It would be good if we could get some consensus on this trust model and >excellent if it could be agreed by or during the Kyoto interop. > >Please note that the trust model sets the requirements for the SSO protocols. >Until we sort out the trust model we can't sort out SSO. > >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-grid@eso.org Thu Mar 10 14:10:29 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 j2ADA6R5011008 for ; Thu, 10 Mar 2005 14:10:06 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2ADA6AU011007 for grid-outgoing; Thu, 10 Mar 2005 14:10:06 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2AD9wR5010981 for ; Thu, 10 Mar 2005 14:09:58 +0100 (MET) Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2AD9ukW015242 for ; Thu, 10 Mar 2005 14:09:56 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:42635) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp id 1D9NQC-000111-Lx (Exim 4.44) (return-path ); Thu, 10 Mar 2005 13:09:48 +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.12.10+Sun/8.12.10) with ESMTP id j2AD9moL016519; Thu, 10 Mar 2005 13:09:48 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2AD9mRN021707; Thu, 10 Mar 2005 13:09:48 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2AD9lwV021704; Thu, 10 Mar 2005 13:09:48 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 10 Mar 2005 13:09:47 +0000 (GMT) From: Guy Rixon To: Paul Harrison cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <42303EEC.9010804@jb.man.ac.uk> Message-ID: References: <42303EEC.9010804@jb.man.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.10.3 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Paul, thanks for the comments. The "less-trusted" entities are the case where I trust some service to perform a specific action, which I state via authorization tickets, but not to use my other privileges. I think this _is_ a form of partial trust; maybe it bneeds better explanation. Diagrams will come in due course. I have one suitable one that I need to get out of power point and I may draw others. You're right: the interactions with other trust systems need discussion. I'll add material about this later. Guy On Thu, 10 Mar 2005, Paul Harrison wrote: > I agree that this is the best starting point to create an architecture - > in addition to the text, a diagram would be useful to illustrate the > trust domains (with their contents) and the trust relationships between > them. I think that this is a pretty good starting point. I have a couple > of issues though > > * In the document you talk about "less-trusted" entities - surely in a > trust model something should either be trusted or not-trusted, there can > be no degrees of trust. > > * I think that there should be some discussion of what should be done in > the case where there needs to be a trust relationship set up between the > an existing authentication system (e.g. the existing particle physics > Grids) and the IVOA one. > > Guy Rixon wrote: > > >Hi everybody! > > > >The 2004 discussions of single-sign-on authentication stalled due to > >disagreements and misunderstanding about the trust model. Since then, there > >have been other discussions about this (in AstroGrid and in EuroVO-VOTech and > >among the GWS members discussing VOStore). From this, I've synthesized a trust > >model that seems to work and which defines the architecture of an SSO system > >that we could use. Here's the initial document: > > > > http://wiki.astrogrid.org/bin/view/Astrogrid/TrustModelForVO > > > >(VOTech and AG people: it's compatible with what I said at the DS-3 meeting.) > > > >(VOStore people: it's a poshed-up version of what we discussed earlier this > >week.) > > > >If this finds favour, then I'll write it up as an IVOA document. > > > >It would be good if we could get some consensus on this trust model and > >excellent if it could be agreed by or during the Kyoto interop. > > > >Please note that the trust model sets the requirements for the SSO protocols. > >Until we sort out the trust model we can't sort out SSO. > > > >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 > > > > > 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-grid@eso.org Thu Mar 10 16:33: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 j2AFXLR5003125 for ; Thu, 10 Mar 2005 16:33:22 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2AFXL1m003122 for grid-outgoing; Thu, 10 Mar 2005 16:33:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2AFXFR5003102 for ; Thu, 10 Mar 2005 16:33:15 +0100 (MET) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2AFXDpB008134 for ; Thu, 10 Mar 2005 16:33:13 +0100 (CET) Received: from [144.173.229.5] (helo=butch.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.41) id 1D9Peu-01BU59-2m; Thu, 10 Mar 2005 15:33:08 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=localhost) by butch.astro.ex.ac.uk with esmtp (Exim 4.24) id 1D9Pep-0000Dp-IX; Thu, 10 Mar 2005 15:33:03 +0000 Date: Thu, 10 Mar 2005 15:33:03 +0000 (GMT) From: Eric Saunders To: Guy Rixon cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach 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.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.10.6 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Eric Saunders X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy, I have a couple of issues with the trust model as it's been defined here. Firstly, what is the benefit of allowing fully trusted agents other than your personal user agent to assume your identity? If each step of a workflow is authorised, then it follows that the whole workflow must be valid. Consider the following simple example. I want to run a set of simulations on some remote facility, and have the final output returned to my VOSpace for further processing. The delegation proceeds as follows. 1. I instruct my user agent. 2. My user agent contacts the portal agent for the facility and makes the request. My user agent provides the portal with a single use 'ticket' which allows the portal access to a single directory of my VOSpace, for writing only, with a short but reasonable expiry date. 3. The portal agent verifies my community and decides to trust me. 4. The portal agent authorises cpu time and temporary scratch disk allocation from separate services at the remote facility, *using its own identity*. These facilities are completely abstracted from everybody beyond the portal. 5. The job runs. The portal agent uses the ticket to dump the data from the internal data store to my VOSpace location. The ticket is now invalidated. The portal returns a status message to my user agent. In this example, we only had to export our user privileges to access the final data write back. When we did so, we minimised the extent of these privileges. If we needed other services requiring user privileges, the same temporary ticket model still works. This is just an example of the Gang of Four 'Facade' pattern: allow encapsulation of a subsystem using a high-level interface, simplifying subsystem usage and hiding structural details. In this case, our high-level interface is simply the set of allowed personal actions which we make available to the other components of the workflow. We could even make this explicitly OO by passing the interface API of our agent to the other workflow components. Now, when the portal wants to give us our data back, it calls a 'dumpDataToVOSpace' method on our user agent, which verifies the portal is allowed to do this, then goes ahead and unlocks the storage location, passing back a suitable URI or whatever to the portal. The advantages of this approach are the same as those of encapsulation in any other piece of software. The less each component knows about each other component, the less can go wrong, whether maliciously, because of bugs, erroneous assumptions or simply poor security. Each component is now effectively sandboxed. The other big advantage is that we are not giving away our private identity to arbitrary software entities, and simply trusting that they will do the right thing, now and forever. This is inherently risky, because if a single point in the trust model ever fails, we lose our identity integrity permanently. My other point is to do with acquiring trust. While the system is small scale, it will be possible to individually validate communities and thus establish a trust network. However, as the system scales, this becomes more and more difficult. The problem has already arisen in the real world in the form of public-key verification between private individuals. The weakness of all public-key systems (of which digital certificate schemes are a subset) lies in the validity of the public keys - i.e. that a public key can be trusted to truly belong to the identity it represents. Once we can no longer personally validate keys, this is a problem. I recommend a web of trust model like that used for public key email encryption. See http://www.gnupg.org/gph/en/manual.html#AEN385 for a good discussion of how this works. The only assumption is that users in the web of trust will, for the most part, authorise keys responsibly. This seems reasonable for a specialised environment like the VO. The model is also very flexible - individual key holders can specify their trust level based on their security needs and/or paranoia - a key issue when trying to federate resources run under distinct local security policies. Note that this also allows 'degrees of trust'. Cheers Eric --------------------------------------- Eric Saunders eSTAR Project (http://www.estar.org.uk) Astrophysics Group University of Exeter --------------------------------------- On Thu, 10 Mar 2005, Guy Rixon wrote: > Paul, > > thanks for the comments. > > The "less-trusted" entities are the case where I trust some service to perform > a specific action, which I state via authorization tickets, but not to use my > other privileges. I think this _is_ a form of partial trust; maybe it bneeds > better explanation. > > Diagrams will come in due course. I have one suitable one that I need to get > out of power point and I may draw others. > > You're right: the interactions with other trust systems need discussion. I'll > add material about this later. > > Guy > > On Thu, 10 Mar 2005, Paul Harrison wrote: > > > I agree that this is the best starting point to create an architecture - > > in addition to the text, a diagram would be useful to illustrate the > > trust domains (with their contents) and the trust relationships between > > them. I think that this is a pretty good starting point. I have a couple > > of issues though > > > > * In the document you talk about "less-trusted" entities - surely in a > > trust model something should either be trusted or not-trusted, there can > > be no degrees of trust. > > > > * I think that there should be some discussion of what should be done in > > the case where there needs to be a trust relationship set up between the > > an existing authentication system (e.g. the existing particle physics > > Grids) and the IVOA one. > > > > Guy Rixon wrote: > > > > >Hi everybody! > > > > > >The 2004 discussions of single-sign-on authentication stalled due to > > >disagreements and misunderstanding about the trust model. Since then, there > > >have been other discussions about this (in AstroGrid and in EuroVO-VOTech and > > >among the GWS members discussing VOStore). From this, I've synthesized a trust > > >model that seems to work and which defines the architecture of an SSO system > > >that we could use. Here's the initial document: > > > > > > http://wiki.astrogrid.org/bin/view/Astrogrid/TrustModelForVO > > > > > >(VOTech and AG people: it's compatible with what I said at the DS-3 meeting.) > > > > > >(VOStore people: it's a poshed-up version of what we discussed earlier this > > >week.) > > > > > >If this finds favour, then I'll write it up as an IVOA document. > > > > > >It would be good if we could get some consensus on this trust model and > > >excellent if it could be agreed by or during the Kyoto interop. > > > > > >Please note that the trust model sets the requirements for the SSO protocols. > > >Until we sort out the trust model we can't sort out SSO. > > > > > >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 > > > > > > > > > > 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-grid@eso.org Thu Mar 10 17:40: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 j2AGe5Om012697 for ; Thu, 10 Mar 2005 17:40:06 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2AGe5N7012696 for grid-outgoing; Thu, 10 Mar 2005 17:40:05 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2AGe0Om012671 for ; Thu, 10 Mar 2005 17:40:00 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2AGdtkW022194 for ; Thu, 10 Mar 2005 17:39:56 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu X-Envelope-To: Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2AGdce12580 for ; Thu, 10 Mar 2005 10:39:39 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2AGddWh006209 for ; Thu, 10 Mar 2005 10:39:39 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2AGddiG006205 for ; Thu, 10 Mar 2005 10:39:39 -0600 Date: Thu, 10 Mar 2005 10:39:38 -0600 (CST) From: Ray Plante To: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <42303EEC.9010804@jb.man.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1903330751-914646686-1110471466=:30645" Content-ID: X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.10.7 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1903330751-914646686-1110471466=:30645 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi Guys, (no pun intended.) I think the time is right to try to tackle this on in the VO. I pretty much agree with Guy's write up. I just want to share my current take on some of the issues he brings up. I also want to share part 1 of a 3-part white paper (attached) I'm working on addressing authorization issues (but which also talks about authentication). I think it's largely consistant with Guy's vision. One caveat about the white paper: it is meant to layout how we could manage authorization using a particular grid tool (Globus Community Authorization Service); however, the model need not be dependent on this. I think an equivalent system could be assembled using, say, Shibboleth. > single sign-on Yes! > single registration system As Guy points out, if we want trust to transfer across administration domains, we need to minimize the number of roots of trust (i.e. CAs). A single registration system for the global VO would do it; however, administratively, I'm not sure how practical this is (because services need to be maintained...$$$...and the whole thing). So, I was thinking perhaps this might be handled on a per-project basis--e.g. NVO, AstroGrid/EVO, JVO, etc.--and then these projects would agree to trust each other's CAs. At least a per-project approach might be a good first step to ultimately a global CA. > where to register (home institutions) I'm not sure how doable this is in the near-term for a few reasons: o I'm not sure I could convince anyone at my home astronomy department (let alone someone higher up in the University food chain) to take this responsibility. Perhaps after VO gets more community traction, this would be more practical. Shibboleth operates this way, but typically it leverages the university's library, which already manages users on a university level. I guess if we use Shibboleth, perhaps we can leverage this infrastructure. o Many legitimate users may not be part of an institution that can readily manage approval. In addition to amateurs and astronomers working in industry, I think we might include the lone astronomer at a small teaching college. Nevertheless, strong trust starts with trusted humans, so this may be the only practical way to do it on the large scale. I'll note that observatories have an operational trust model when the dole out telescope time. Perhaps we can leverage this. On Thu, 10 Mar 2005, Paul Harrison wrote: > * In the document you talk about "less-trusted" entities - surely in a > trust model something should either be trusted or not-trusted, there can > be no degrees of trust. Actually, I think we do need to support "less-trusted" entities, as the attached document argues. Many services we'll want to provide, including VOStore, do not actually require that the user connecting is actually who they say they are; they only need to guarantee that the person connecting is the person who originally, say, created the space. This is the model for the hundreds of portals we already have logins for today to which we could have registered a fake name. I have proposed the concept of a "weak" certificate. These are less trusted certificates that are granted without a human in the loop as is done with a traditional "strong" certificate. cheers, Ray ---1903330751-914646686-1110471466=:30645 Content-Type: APPLICATION/PDF; NAME="CommunityAuthorizationP1.pdf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="CommunityAuthorizationP1.pdf" JVBERi0xLjMNJeLjz9MNCjMzIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0v TyAzNSANL0ggWyA4MjAgMzMzIF0gDS9MIDEyNzcyMSANL0UgODM0MzMgDS9O IDYgDS9UIDEyNjk0MyANPj4gDWVuZG9iag0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4cmVmDTMz IDE5IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA3MjcgMDAwMDAgbg0K MDAwMDAwMTE1MyAwMDAwMCBuDQowMDAwMDAxMzA3IDAwMDAwIG4NCjAwMDAw MDE0NjYgMDAwMDAgbg0KMDAwMDAwMTY5NCAwMDAwMCBuDQowMDAwMDAxOTE2 IDAwMDAwIG4NCjAwMDAwMDIxMzAgMDAwMDAgbg0KMDAwMDAwMjY1NSAwMDAw MCBuDQowMDAwMDAzMTAyIDAwMDAwIG4NCjAwMDAwMDM2NjkgMDAwMDAgbg0K MDAwMDAwMzcwOCAwMDAwMCBuDQowMDAwMDA2MzU5IDAwMDAwIG4NCjAwMDAw MDY0MzcgMDAwMDAgbg0KMDAwMDAyNjYwOCAwMDAwMCBuDQowMDAwMDQ0Njc3 IDAwMDAwIG4NCjAwMDAwODA2MDUgMDAwMDAgbg0KMDAwMDAwMDgyMCAwMDAw MCBuDQowMDAwMDAxMTMyIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgNTIN L0luZm8gMzEgMCBSIA0vUm9vdCAzNCAwIFIgDS9QcmV2IDEyNjkzMyANL0lE Wzw3ZDkyMWJhZmQ4NTYxNzY2MTAwZGIxY2QxZDY3YTI0YT48ODk2YzE1Mzdj Y2QxMWY3YjgzYzExOWRhOWQxNzYwNmQ+XQ0+Pg1zdGFydHhyZWYNMA0lJUVP Rg0gICAgDTM0IDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDMw IDAgUiANL01ldGFkYXRhIDMyIDAgUiANL1BhZ2VMYWJlbHMgMjkgMCBSIA0+ PiANZW5kb2JqDTUwIDAgb2JqDTw8IC9TIDE1OSAvTCAyNDEgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCA1MSAwIFIgPj4gDXN0cmVhbQ0KSIliYGBg BiITBhYGBqbLDIIMCCDIwAqELAwcBxgY5v1nmnLQJaFFwN+AgSEp4pYFVA1z J6vSreUcS6zUvm49tfic5iIW7XB3LSW39co9R5UjtqaLli4ulA9ynXPrYSRQ NUdHBwOTRkcDA4NLB4gU0gAKMDAwClt0dIBZQAUdKFYBgQADY8VBIM0PxNJg EXWgWDFDBcNehu0M6xmfMc5gEmBg4DJhUPdb4pbXY8jlx5jGYM9QxNDLsNWo jGGZ5D2GZVL3GTYy/IE6WoaB8YUUkGYCYm+AAAMAcr87cQ1lbmRzdHJlYW0N ZW5kb2JqDTUxIDAgb2JqDTIyMCANZW5kb2JqDTM1IDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgMzYgMCBSIA0v Q29udGVudHMgNDQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0v Q3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9i ag0zNiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250 IDw8IC9UVDIgNDAgMCBSIC9UVDQgNDEgMCBSIC9UVDYgNDIgMCBSID4+IA0v RXh0R1N0YXRlIDw8IC9HUzEgNDUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAv Q3M2IDQzIDAgUiA+PiANPj4gDWVuZG9iag0zNyAwIG9iag08PCANL1R5cGUg L0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCA2NTYg DS9EZXNjZW50IC0yMTYgDS9GbGFncyAzNCANL0ZvbnRCQm94IFsgLTU2OCAt MzA3IDIwMjggMTAwNyBdIA0vRm9udE5hbWUgL05KR0RCQytUaW1lc05ld1Jv bWFuIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDk0IA0vWEhlaWdodCAwIA0v Rm9udEZpbGUyIDQ4IDAgUiANPj4gDWVuZG9iag0zOCAwIG9iag08PCANL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCAw IA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgOTggDS9Gb250QkJveCBbIC00OTgg LTMwNyAxMTIwIDEwMjMgXSANL0ZvbnROYW1lIC9OSkdEQUErVGltZXNOZXdS b21hbixJdGFsaWMgDS9JdGFsaWNBbmdsZSAtMTUgDS9TdGVtViAwIA0vRm9u dEZpbGUyIDQ3IDAgUiANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL1R5cGUg L0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdodCA3MTgg DS9EZXNjZW50IC0yMTEgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTYyOCAt Mzc2IDIwMzQgMTAxMCBdIA0vRm9udE5hbWUgL05KR0NNUCtBcmlhbCxCb2xk IA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDE0NCANL0ZvbnRGaWxlMiA0NiAw IFIgDT4+IA1lbmRvYmoNNDAgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3Vi dHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxNDYg DS9XaWR0aHMgWyAyNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAyNzgg MzMzIDI3OCAyNzggMCA1NTYgNTU2IDU1NiA1NTYgMCANMCAwIDAgMCAzMzMg MCAwIDAgMCAwIDAgNzIyIDAgNzIyIDcyMiAwIDYxMSA3NzggMCAyNzggMCAw IDYxMSA4MzMgDTcyMiA3NzggNjY3IDAgNzIyIDY2NyA2MTEgNzIyIDY2NyA5 NDQgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDYxMSANNTU2IDYxMSA1NTYgMzMz IDYxMSA2MTEgMjc4IDAgNTU2IDI3OCA4ODkgNjExIDYxMSA2MTEgNjExIDM4 OSA1NTYgDTMzMyA2MTEgNTU2IDc3OCAwIDU1NiA1MDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAyNzggXSANL0Vu Y29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvTkpHQ01QK0Fy aWFsLEJvbGQgDS9Gb250RGVzY3JpcHRvciAzOSAwIFIgDT4+IA1lbmRvYmoN NDEgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUg DS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAyNTAg MCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAyNTAgMCAyNTAgMCA1MDAgNTAw IDUwMCAwIDAgNTAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgNjExIDYxMSA2 NjcgMCAwIDYxMSAwIDAgMCAwIDAgNTU2IDAgNjY3IDAgNjExIA0wIDYxMSA1 MDAgMCAwIDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1MDAgNDQ0IDUw MCA0NDQgMjc4IDAgDTAgMjc4IDAgNDQ0IDI3OCAwIDUwMCA1MDAgMCAwIDM4 OSAzODkgMjc4IDUwMCAwIDY2NyAwIDQ0NCBdIA0vRW5jb2RpbmcgL1dpbkFu c2lFbmNvZGluZyANL0Jhc2VGb250IC9OSkdEQUErVGltZXNOZXdSb21hbixJ dGFsaWMgDS9Gb250RGVzY3JpcHRvciAzOCAwIFIgDT4+IA1lbmRvYmoNNDIg MCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9G aXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxNTEgDS9XaWR0aHMgWyAyNTAgMCA0 MDggMCAwIDAgMCAxODAgMzMzIDMzMyAwIDAgMjUwIDMzMyAyNTAgMjc4IDAg NTAwIDUwMCA1MDAgMCANNTAwIDAgMCA1MDAgMCAyNzggMjc4IDAgMCAwIDAg MCA3MjIgNjY3IDY2NyA3MjIgMCA1NTYgNzIyIDAgMzMzIA0wIDAgNjExIDg4 OSA3MjIgNzIyIDU1NiAwIDY2NyA1NTYgNjExIDcyMiA3MjIgOTQ0IDcyMiA3 MjIgMCAzMzMgDTAgMzMzIDAgMCAwIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMz IDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCANNTAwIDUwMCA1MDAgNTAw IDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDAgMCAwIDAg MCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDQ0 NCA0NDQgMCAwIDEwMDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rpbmcg DS9CYXNlRm9udCAvTkpHREJDK1RpbWVzTmV3Um9tYW4gDS9Gb250RGVzY3Jp cHRvciAzNyAwIFIgDT4+IA1lbmRvYmoNNDMgMCBvYmoNWyANL0lDQ0Jhc2Vk IDQ5IDAgUiANXQ1lbmRvYmoNNDQgMCBvYmoNPDwgL0xlbmd0aCAyNTc2IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJhFddc9vIEXzXr9hH IGXiiC8SSJ5kJ3flVOrkOvGcBzkPS2ApbgwBDBaQrPsj+bvpmVkQIGVXSlUS BQKDmZ6ent73u5ufdrtExWp3uIkLtcYP/sSbTbRO1HYdR3mhdk83P31wG1U5 /n6tXNXe/PTLfawe3c1qHa3XuHdXyUdEerl5CG7DNI/SQH2+Wx16a9q6eQ23 SbQJ3oVxoD50T09ja4fX1V47U6vwX7u/38TRNtts1SqONgX+7v56cx06o9jB 7Tgcu97+oQfbternXj+Zl67/qsLdv29izpur4E9xkkRlpjbZOkq5EEm3oJj8 yaf7SfeDiv+sfndGfUBK7p36zfxntL15Mu0QJnkUB7imW+SabqMsuD2d+k5X R0kdGGYeQ//2RCW4r9yoTVxG/GZ+3WYupuBiftOv6lOj28Fw8Pf9WBn1j+4w WMcFZVGWMyQ5ASJPxpw9P/7rh/tbvm8FtNeLO/lt2fy2jdT52fSOUFtHsfoS /Gz2/aj7VxXH71SyXudfwrBAceeiNlLUKo6jbCvRMwk/p8CvX5AojUrPI/5U rlWeFtEmIagFBSkguN27odfVMAXYXCNIj8aFZ+AVfGtf0O5olOm16g7qiXPX Ib7fBM7ZZ6Pc2D+bV6ca+zXMcRXQ3t/vlO6FcJsoyfGqCa54js60wO11b59t +6gGvMa2VW+0o39bUxm8YXhVh64X/CUYEIrzH1L3IdAouWs7pBrYSjeqN87o HjQajnpQ6HlrBiLzxVxso2KR5dzUxMcEbw5GDyOCIeBTBy7VetBKV5Ql8wqX gU4SdOEaGOEGjrzi0Jc5b2cQthJfYrW6eXXWRUr9MyyjPLDDkVGpzbNpuhOF zwPMCnWCrk+p58vc0zl46glp+2EEEHd7Z/pnPXRg45fg892XUFUEE+bOUEfL gKMOXdc4/J7zzxcFPARSJXOgCL4a1B1iMorgovpwtcElIzdBzCBPGDpqrelR H1Hqc7gFXe5CUixKRJ4fW6mqiLbxoqq5zdKSgIiBXja6fzT/hViNDj1whMwJ zWkHi4JH1AtFEe5wwMs+FHPQYu4zBqYOqSBL4sefuNgsaJQmXeRLfYhYSWD/ CDPkLzpJFWyCrjbA75JcSfZmCB4CPGHbGuSv0R2nXmzTKGefAEsZnABjHDSv qu0GwKcbA9Q+tnNPkuxqEubJSvzcciEbX8ZGikhQxBNn+I6LwXXWeVRRBFzE qcO1xqJjfM2F9JCahnmTLguZAUw913SPLreHMMWjRAUAVQEH1zUGxYw82SfT C1LWkVC6qSiJftmihbxOo+hcV1k9IOoLM4impOkebUvD2I3t4P4CHo9UIDPg 3IM3LeBPuYRVEJnHvhtPShowcgPcoMw3i9+kQZhCTI4zPH9zI5YpnyUbeS5X qGPOg6/DsTdmdaJVWHfVSO/CmLRnrcy+q0JSezAoLMRTh9UJrVD6dEKbhHle EH5puv3oZrHMfig8sRees0tQ55WPtudEBdB8G7TqHpphMbtfgg+395AMCEOF +fKwllG5XeJaziNVehwanpEtlH6anlKmJw4mg3GSqyiHOWcNAaX5qYHuhMkh xmy5KyV1ZX+WV8lgoU9Cv5LpVwr99q/gQjtKjL3pgRffQruhG/tK8qP5SMmC PNnWyr1W3v6H7CdO0pfRc4Dz5Mh9lkd6MByvaeyjPNHyH2DYGlNTOvz/K+cn Zez+9Ebmcmn50UxJGiZRRyJquNv7sa8Net9OQvdCCxTLryaDQ3dUHVT3JHwV A+AtVFJEZfldqq3FAL4Y/RV97gd7II4Zd2kgNtE2n9p+ZVNWMKXba3Giai70 G+pE25ihyQO9bwArrMThQMKDDdfQyqO8ZcEyoFQOquMnGt4YDDdTIxV5A2Ff ZWKpYy9mv9RhD/JboZRJ4kZqL5Ze9oauhnncjwO0hrbTEc7awkpgkmV1FlDq VUaP7Uk2DVR88IYVzMzi5WzMGHixdDPDt0Fvq8GQBlnIpRCyGnuaTI6GEiXU 4jCwWIcncnlWOII1wQIT+9WXbLH6rhuycMk+mxcyGq7q7V58nJg8USz1uLzW wg3ydlWVdgybDCxQMpPapteFQ2K1lVaRhui6Bq9B2obktfcHAf4a/Z/OAZPI plfZzyYnZpkJ3Pj0pKFeRmFUSBrl5CALZyGN0LCIDzFllOb5dw2G4BHMOCY8 WR4bo47dC0dEqJUorcT6UYZTt4WJ4rdoAwO8lnSM2YdvCBRF+YJF3dk9Z6XP 8iF41O0kmAy2hNJi3Vr9iCZcXnpVNcBF0uNg6nnLUsjLZN+qthPVZ2fLaiUa w/Tm/62I2pyylvsudLOl1+uzw15yYl5F6SQIVFjdicvlEuCA2wWf/RxkF17q WrkegpTbZb7BBdbcKG9MCXLBIMFq3F5jMHuZ2FuCCxfDdIfYfL6bFi8bP9mT RdD6AXAnMYxkRvrOubMDTMvvKsFkP3Qt3LciBgLcApGzvtkW9sYSA6zzykeV vaPE5nEpf9jgxDdY2kkUNG6A/lp39L2UVWzgqST3OCripfTEV0AFj9YT0hN6 JJ6zDmoeNUjG5tJ64SGQEwoKIDXU/tT1AxQFHsvzLvr/J94kQ+2ZP/Fe7aC/ 7fCqYosnFr9d1d4U4JZK0hRPqozNJviUQH5uDjfvdzRvEAJ+DX+i19Ad6+k1 9ENxzgdOEuE83vpFEqvfwZIwx9Nl8EGTURMM36YfF2VUTOmfB2LJYzRQhau0 JMX99HFV9/YZ235xiIN3zAMAPb2iyLPFkSnevCEZdUR9goXsrRk0AsQJrdVb OcN+6sDq6ZqnErhYehNJCrncHQL3l+DXu1s6SV76g9ijyBDGeRptk3Ohb8lP p0EKo+79OfG2r46o9mqzs8KJH4BYTjs2Xh4T0ze2fvJ9cbAPyd6x+WOn39Yr keTuhM0J+mmStDSoZ2cZL06MF9Jg20OPow70xTTYC91JzNnRoP0HXfmWJLMB eIC5HcjX0gGJD604DnX8vpPPi480yOo8dRfGerGv/VkVlWgcCCzIQMr0jDm2 sqaJHfDrnz5SX0Txsii51oS5D3EsET3FZlXhmjDYlg9TcjwiTwZx6lqvS0a6 0zvJGwP25py1Wsw9nJ3340i9rewJwE/Jc96yDh2fuGS9csgfHQunhTVYkXlD fljPfeHzStc0psKJSw+a4+LlelqwxQ9sQC7GCg64GtEwjD0ZU7LDnNY2Wl88 OO/7hPsTzEVBxYUc3o5BAuKreubXpqKp3TzmwB0a6XiVcVAW1fjyPPt2DXo8 nXKdR4YaVQR+HhKeh8zPQ2sfj8NE2vUy8LwW1553TrEBAbKGV6AAzWsPuq3u Wn/48MxLL8zbrBy9fpGG0EQM+qtp3/FjU+VcZYLVkS+WTyxNuUJFiGm+VQ38 3rOH52LnzPDEHh4zKUmP0pF8Fgxu4obpeatnQc0QSSXYKf8bAP/JSwQKZW5k c3RyZWFtDWVuZG9iag00NSAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSAN L1NBIGZhbHNlIA0vU00gMC4wMiANL1RSMiAvRGVmYXVsdCANPj4gDWVuZG9i ag00NiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDIw MDgwIC9MZW5ndGgxIDM0OTM2ID4+IA1zdHJlYW0NCkiJfFULdI1XFv72Oee/ NyKJIORJ/5tLavKgSb0FkdyEjIoQJfHo3Cs3miCSVmowbeMR0rl0SqnpDDWk lHp0/pAppYh26VL1yqKqRtsspR6VNRnGMCr3n30vY5i1puesP9lnn332/vbz ggAEYx4kckfm9UiZfC5/BVDdzNycwlJX+YqKw08AVUcBqiucVaH/betKpnEe sPafUv58acCVPd2AgAhA++r56XOm1JT11ICnuwADVXGRy/1FdHt+/1oav+ld zIx2n7Y9zAZ9+rsUl1bMLp037jgQEgaErZteVuiihPPxQDnrDNtQ6ppdHmSj asZzkuX1Ga7SooWHjuUAi9cxnh7lZTMrGDevxfN89+UvFpUPsbmZE1sHhJZp exDj/zYhRsUhBjAv/ufzlpgXfXe+/+Iaa+t0/3uwdmAbvqJupGMn3UU47lAk JSMbCrfZ4p/RgrcQhjFYRe3QBR3xLLJJsUwCltJqc5Z5FQPxJmrMXbTA3ML3 b+Az3GEE3ypCH+Sw/LMowlV5CQXmHxGAarTGAIymjnDhDO9bjGEFVmI/vWze YathWMD6UjEEQ8yD5j3EY6lapp1t9Rcsx16ymIVmCTojFh6RYJ4xv0McCvAu tjGmBKpXw2DDNCzC2xQpP2PqLWyAl4LEJJmhHWBL2RiLGfg1PNiCI9SOcrWz WrP5G/MyLGiPboypBFepF40QG1WQOcg8hwn4CIfZX9+uVxPUJm2Cd7D5jvkJ OmAXBdLHdFBL0X7XMt9cb36AIMaTzBHJYTuTsRAH8Tn+jhui0qzEMOSx5UPU iXSK44ifEZHiVfGqPIXu7O0kRvsS/gSDM7IHe7GPY/NXNOIShVE0/ZIm03K6 IYKEW5yQq2WdPK1Ivc/xtqMrx6gCG/EhjuIYTpDG+p+iXJpKZfR7eocahSGu i9sqQC1UP6kWLc7b6P3JzDFvIQJReAZzUcmxfRc7UYfj+BI3cBP/pFDqS8W0 ngxqpOuilYgVI0W5WCU2iu0yRy6XB1Uvla6mqWPqnLZYW2J1Wb333vOu8G73 Npi7zAaunRDWH4csjuh8roqNOIBTrP1rfIMLvvph/QNoPD3HVmbSa7SSttMh aqBr7CX8O1YMEA62WiZe5DgtECvESrZ+gvdJcU58I34Ut6QmY2Vv+YJcLw25 W56UP6hQFae6q2Q1Uo1XJmcmRRuq5Wmbta3aJ1qzJdXitpRbrlgXWKsCjrbE t3zrhbfYa3h3cu0GcCXN5UisRQ3XfR3n4AhH9DgjbsQ/OAtRZKMnGXc/yqLh NILG0UQqogVUTW/S27SaaugD9oB9EFbGniCGiDzhEkWiSlSL10Ud7z3ic3FG nBVNjDxc2mWCTJbZcrycIGewDxXyVVnFkV0ut8gT8pS8LK/IJs5auOqsXlJz 1R/UJlWnGrRntFLeNdoBrV5r0O5p9yzCEmWJsfSwTLVstlywWqy9rbnW31pP W28GlFMMxTNyHY8sEck92FlsEWGqkpqY0YkU2rDnCZyHPO6KmxgsvZyXEN89 Y+sgIlV730tLmjL4fQXtRS86hEqLkDxVVSN20HnRqD4VA/ElOSlSbZIztCPC hq08jZaJj8VeSkedSBVjxRoJukSbcYnrfTZW0jSaia3URP3pFepDlTgtOso8 qkKqWSMUtaJsagYjwHzlxnP42UX9eFpf9a5Vweplnk+7sYozug3f0fu4S5p5 naeb5Gnk4imzlOt9EXxTbxL3WSX3YyRPkOmWE6gjC0/8PpZBai6a8S9c1fZw RaXzJL3sLVFr1fdmHzOJO4y7DJu574oxlDvmElfJPj77ThO50wN5lqRwV+di PNx4hafectMw15gLzTlmGb7gt3cpke7SOu6I3fwiFYd5v4GvaQn34dCf9/P/ La8b9bhGEdSVUrgfmrRZ2jJti1an7deOWZI52lVYzRV9gas5kD0oRAOu4TYF cG4ikYiejLcvY8/HdFEg9yGDolDOPduN53j6A09mspYFHL013M/7uDeaeU5M xH6cJUHh7FEh2w9gPcM5zr9i6fc4gwtpJ3PcPLXj8SP7HUJ9RQXbS2NNq3hq 1TOm8/iBo236cSXyXHDQWNZ1G+PgZgu9kUu1yDI/5EmVA4c8yvHuQqFIp1ja wO+c3KEh6IR+2vckkOjNMfuKErmPf2NM5q/jX69oDKQXGEUb9qMFHWgkenlH M4ZTQNqQMWmDBw1MHdC/X98+vXo+nZL8VI/uSYkJ8b/o9mRc1y72WJv+ROdO MdFRkRHhHTuEtW/XNrRNSHBQ68BWAVaLpqQgJGbas5y6Eec0VJx92LAk39nu YobrEYbT0JmV9biMoTv9YvrjkmksOeV/JNPuS6Y9lKRQPRWpSYl6pl03jjns +m4aPyqf6dcd9gLdaPLTI/z0Mj8dzLTNxg/0zIhih26QU880smYVezKdDlZX 2zoww55RFJiUiNrA1ky2ZsoIt5fXUvgg8hMiPLN/rUBAMIMyouyOTCPS7vAh MGTXTJfbyB2Vn+mIttkKkhINyii0TzZgTzfaJPhFkOE3Y1gyDKvfjF7i8wZL 9NrEes/S3aGY7EwIctvdron5hnQV+Gy0TWC7DiN87sWI/x5ZebuM/OpHb6Ol JzOiRPcdPZ5q3agflf/orc33t6CAdfBb0TXL6cli00s5iMPzdLYmFhXkG7SI Teo+T3xe3fevyJ7p4zin6kYre7q92DPVyamJ8hgYPce2Iyoq7SOzEVGZumdM vt1mDI62F7gcMbVh8IyeszMyTY98/CYpsTa07f3A1oa0eUAEBT9KFD2881N+ cR81fPTDyJIPkT2bC8LQC3VG8m/uqz44quqKn/fefe8tkeq2NCkkIyzdJg0k NIB8BisLmURsakwgCZvA6BI+FKiFmiEjnSGkjJW4IS3fBBIo1SqaYN0gfyyG tkvtFMGmOqOxDnUcC6UFAp06QrUJ5PV37ntv2axQqp3+0538cu499557zz33 d8+9L+jHmqbxv6XTKLx4GrrhV6XAKrIEO7I8MqQgFPbms57tI3qm1+8LXyEw wH/p4mDNIkdjZHqvEBeZJ3Gqod0tR3JyImPHMkXMAuwpfLxH1iePy62LqlP8 q70+CISPShHbRVX5eQj/6NG8wU3RANWgEmkoC9p1H9VkHKJAXk5VRA1xS8xt Sa3glga3JW4e8oPJh4kf9akRT1b87w5v2rDCR/IjStq/aV5qtxfP8xeXVQd9 heGQE9vi8kE1u31avM0pRYYVBLUM1SmpGZpsBSkXxjtzJTg0IjLxZ0hSL4lo IKVUKL6iiDc0x/5flTJ69E1toqYnwShq/Z2tpLhu5ngZyc8ZXJ8xqD7Iu6Fh Df6KLLW4vDocThnUVoQEFA4X+X1F4VB4UdRqqPH7vP7wEfWAeiC8ujDkbmjU eqUpI1K0qQqLeETJB1lVmt3pVxrLOgNK47zq4BEvvlQay4OHVEUtCM2u6vwa 2oJH8BQJSK0a13LNxzUqVkD0Q6pHNmUcwcdUg2wVUiHri6MKSZ3H1Sm0OKra Oq/U4TeOeO/NewZKqMBLfX0DZd5CyYaEn55tOCp1uoN2imqv02pRS18Cisw7 qUo/TtXKX2kh2lYCBdqd+MY6SBXovwb1Wsht6nTrGvpXAk8DdwH3A1nAAmC+ g3nALNicANoxxkM8jpRnaIXZTd/EXATsBBYB2/VK2oG2XcZ0qmE95tqEMfwo 74Z+r9FOW1BuQXsV95WS7SvpW2jPRXmbXmlZZjOZ0BHK16BPw/xb2WfILMxf K2qtSyiPxdj3oX0jZAVkuePvcFk+wzZyrbzGp7iM+NRDvwWYCzQBCxAfth8P u1GoN6N8G/waAjkUuF3goxV97sZbMQI5DvMXOOsmuW6sI74m+C99ujE4prMS AZ94XeeBbuDNBN+S0TwItXhV3CX3j9f8BWCG2k2zEZcBXpd+1vqY4SF6F+vq AnS8Ryd4yGqHnzP1w9SC+kTgbolaUkQbrdIuYw8O0/eNnfRT6EmdAPyDMtWL lG5k0lTEL4jx5wNLMearkg9L2AfrIuQocZbSMVYIWIG5T7hx4tigPgf7GkTf qyjjUUtPAMsRgxbgMfYP8+dxzLHvHyuVAy+g7weYp5iBOUdJYO32vtIa2H8P YylyHnsfbAmgfQVi+nPgV8Ax9sGF5JkDOVY7aWq79RHkMCAd6Aa2MN+AELCf +2D+FPRPkXwFZ5ibzA/mhn5ccnUe+26vQZ6FJufMPAr7BcAIINs4SAsdZKMv x6eGOcvnxR2bucW8dqXk9ErmvXKB18mcSpDb9RiVsQ9yXnDLlXzuMO5alvgu YZ/2aD20mTnLfHMlx4W5xueRz4QjSxPWmuuckVzYj5RcBxdd6cYiLt+gPRiz 0tgCnvZSiThFJXgJl+hrIbdifUegw3oEvii0HHrAE6Mx2MsHYLs7SbYwzB5l Beb6sehALHpor4xrj/pV0aPoeod1XiflhN6h1svyp2QylJjdxpKR2PZZ9Z8H 6jt6By1D+YLeY1lYz1Y+E2avMh7wuRL6Q0ADMNaTo7R4VipRs4K8+OS7DKwS AcrXAzRVxGimSKUA4pQJfYVxr8y7mzH+caWXmrFfT5qp5NfOIzdiLvUd3A8A jw95fwKPBnEumUuudPmaLJkznHchdcgROHevAF3AKQd/Ak6Dj9+V5xd3A+dn eT8gRwPNNl+tS3F+nqA2yB+5/Ezi6dgkfprJvEyWfLdwfpd3C84p/Gh218/5 kXMc50jOc3z3uf2TZYL9DuSOP8g83E3VzrkeA4wH8jDGUSePdGlR6zLO6Dnj LavLnGl1aSetLmO39Zy50nrNOGy1Yd1j4ndqzM5lfJ7cu5TjxPeie4/qWbTM yWd7ZF/ML+/RSpkHyFiL87eCajDu7/he5XOoteHcIZ4Yb4N4nr4jTtNm+H6H 9pKtF/OohHOiqEMZeuR0br9N2yzb54qPqE6MQfl5yFb6omFSnfFrtrG6pe6M 3cY6vZp2gXd54in6md5JQd4rXoc62TrJe48zn+5poL0mgcOnaY/ow5pjWONx KVsln9j2ZauP12fOoK/oGtbHfQC20feSz4nHThmLmIzRDslhxILHNN6W7w3S 30X/n9A6Twrt8Xwd+ekKpZvIJXKuTprvCci4C3lff4jz0QuOVVCj/mXrn5L/ By1L68MZ6sX5YuBpp6fSCL2XWnGWGmV8bNnE50frpVTmCNZXLt8TveD4s/SY 0UGbjBh414O7oAf71ou1rKRpKG8RHVY/+hZiDOK5oS+T7xO+pwLWm3xezBgN NwOYH33YB/n+w7zaWfi7jRqRS2Z5eukZw8fvGkUB90YCE2zI+nqgHthkQ+q8 tlRGY4x1Ur+UXlPbNRX85vYT4gWcvVaapR2gFLEM74cLtEHNo41aCXh3CXeG BjvURS5la5eoWPtE3j8b9RSaKvul4R4/R6WiCvYxWiIO0RLNQnk4sAN8hJ0e pWp9Md5ZD2IcB+oU2AyhUqMJ5TzrIPeTc3xipTHEWpoo7RIgfXXBPj+d4PMO xPYH4AP7i3Kiv+xr3E/Hxxv5J9fJ48JO9vkjzSKy3gMybTlQpjZTB7BfPYV3 eIzqlZ14rLRRkXIWaHPwIs2RshMooyJRrzQCpYAQ9bQPchzkBaAHaAOOAn8T k+mHGPsY5Mv8XcBQf4ncBYn2Z4FfAO+7bYnguW6kT4T4Cw2q6xNpPUPNxZsw lz7dfx9NEo8jD49HPAGtjkoZxu20yvTQKvU09JyTkup6Nu0Sq2jkrfy5FZQ3 aLyMoY1A4hrd/YBM+w/wXoL0scT5Gsf383/r42cF9nc98LCM/376huTQOcTf pCHKUXpQ+QD8a6NvM5x6SMZzH869s0/QN0p90v6BK1O0uRRI1qO8geHWk/f1 VnWM+1IiXB64MCfiLQKI99EfSK7jPniSYTDHcmV9HcOtx+e9GcppEuJUBEmS Y0l1w0trGOpq1FuIef4oI14vx7uq3OYnA7FdzkAMiQHdwwzEjhjo+wQjIa5B jivmZFty98flefL+sF/iN+j3Z7yZyyk9Wcb57eSLQZwvs/ker3MuOZvU5/qZ uH42cFZuNub/E3B2TgLHgd/+r+fiLMM5wst54i28NyJ4qz6Db8zXqZnoWiNR /zGiqw8hD02AfBG6CpSzID8EhkO3HBK3UT9YdhVsHHgb6Ab2iwx63HlXjkC9 0La99pwzXqZtz3Z9eO30T7Ht+zcCrSj/HgDL+l+F3A55Bf0jsKuCrIduA+Qk 1EuBf7FevrFNHnccvz+OHyeNYxNCcAnhHgi2E6dujBtmGFLyOE2oVm+KCyly RlFdaKRqk4olEtigTQJTJBJEmm3qtK5T401aVI21eXIe1F7CcMcqVZ06vE3V 0knT/IK9mEZFX1STJrXKvnc2BXVsbbUFfe97z/P8Pne/5+54fLcX17/DdQ/E UP8i9DcIeX6IbcyHXeBfgo6r/chdzqH/X/8P54/P6sjxa9AhvedEvp88Q3xm vzWfn+KfPGvcmv9P81tniX/z6jhgz/eW0h1nn/96xrnlmM9/VvUBdNMxvfYR 9pSG3kdjL6v33Gr/WHW9335H7yep3lNWHeOp8qhXe2e1f4X/ED5Vcw35HCNf Rl4HVF6/JEP8B8RDKRFrRf79nLcpauX5CznP+qgV9/Ln8QvwPGHE5l8hRYiR o/zbZAJiCE/I8I5oQVVydQ1RL+LPEROahDjJoqT62oJU/Lnc+mbV/LekZ53m TslId6WS8/qiyXgT/wahfIQ/TdqI4OPwLfAj8Fb4Yf4kces8rZzHG51Ef70I 7+UbSAcex7EHjML7+SbSosPGZEOlnzHZHorG6/iD3KdDPNxNuuEubsioMJe5 hUwtfjZXe4/K76z0bohe5lPcIE2ImkTURuG5zOtIF6TeZChX647Oxev5EF5z CMMikCMl87q0+NMSDaG/Ab6ZNOPZ13Hs3QDfy7fIDaK4jN26CvuOagX99UjX A8py7oZoMV7Le/DU5rMY8Vnd21wusCtK4gHeTiIQw6BOoDaBmpfPoDaDaZrB 1MxgamaQxQy+b4RP48k0Yrr4SZLhJ8gcNI+6A01ukBjBgq5sb48W+L3ch5Hw LmPsKO5uytU2qMx8snG9DvPl6huivZf5MTIIMSQ/mtvoix5d5iH9KvflfC0K yMjaegzdxspcAGxWc3CZb+Zb9Ei06hGw4wLXFEdYQSh7i5XU6LA/sHfU/LJr uFb+m6q/XfXfVnytyEo59GLl2e+Vl+Ob2V/R2OPsz2QeNcaW2VUSAfAnlldZ sHdZgfTCV3H9JLwAfwD+C7n1TZFn+RwMub8o3c3qZdlV2dlVrQh/tbKxpVpp bI7G/exX7HWyGU38Eb4d/jorkm3wK3AfvMhGyZvwi2wn2QP/edV/zVbUmmav sUtkFzwnG1QKtjSULUqnslclqVwlu8QKe5VdIJsQ+ooMbMLdl3OB7cKzjPYo +wkbla2iMV7HfkRT9AMEZcmqctLIfixjqpE5uWKKAptjc5YvZvmtsLXAI/5I OLLATb8ZNmPmghn3sllSg8HDf1h2DmWMmAyrB7KgOTYtHTE7/hHeSb0XI5Mo s7qWRpnRNYLS+/HT93Wtl02RQYihjXFoApqEThMHypPQKegZ6Fl9ZxQag07g 85EBkQGRAZHRRAZEBkQGREYTGd37GKSINIg0iDSItCbSINIg0iDSmlD5pkGk NZEEkQSRBJHURBJEEkQSRFITSRBJEElNWCAsEBYISxMWCAuEBcLShAXCAmFp IgIiAiICIqKJCIgIiAiIiCYiICIgIpowQZggTBCmJkwQJggThKkJE4QJwtSE F4QXhBeEVxNeEF4QXhBeTXj1/IxBiiiDKIMogyhrogyiDKIMoqyJMogyiDI7 scRL8TeAlICUgJQ0UgJSAlICUtJICUgJSKn66qN6MBiWzTg0AU1Cii2CLYIt gi1qtqiX1xikWBuEDcIGYWvCBmGDsEHYmrBB2CBsTWRBZEFkQWQ1kQWRBZEF kdVEVi/cMUgRn39Rfu6pYadpyoUfVzZJO7RPkBvax8mq9mfJkvZnyIL2U+SM 9pMkpv0ECWhHe9pHiXBRKWKeeDM+AYPQ49BRaB5ahK5Ahq5dg/4CrbGd1jaH xxg05o1F44pRs2iUDeZxDjrnnYvOK86aRWfZycx4C3Pr7yg+LeQ5XU6gvAnh RwRlr671sm70243v7E7862bd1rr3zJshei1Er4ToYog+F6LxWvYQdegvnUli DInTlFUf6BGrUCwQ7MGXafbSjY1CBr4g8nSlYh1WJ/wGtAQtQGegGBSFwpAf EvpeCPEpa1u1yRUoCG2FTNUFaW7Grr5xncsqMDddyL3hJrWqn2A7uGUZjMDy MjgIe00GD4t4Lb1EgmobRC9i5i7AF6W4jsevVOxnUizDXpaiG3ZIBu+HHZTB t0XcTR8lwqHQoarvx3sr3yfFAYQ9IkUHrFMGAyo6hI78eNpBU+Q63F+ltld6 apNiD2ybFLtVtIsE1cRTJwnr9Gog5TyHhG4WaMpBrXvEe+K74gbwv2NgsTze NfMO2DV/nh6w6sRK+CUEx4WM16l4/D4sVd1WflEs+KfFi2iL+i+JF8T9Yjac d+H2eeQ9rbuQ4oyZZxes9WJSRMRo+Lo4Jh4WT4h94pAf96V4TKyoNMkwTbEL l0QSDX4Jb+GX4iF/Xqe4V3xTWCIodpsranzJrkq7sfCKGgESrfR+H8Y35M+r Nf5oLE/XWSHjfWPOOGj0GXuMNmObscVoNZpcjS6vq8FV76pzuVxOl8PFXMTV lF8rW50Ey7bJ6VXmdKjSoetepkoU6tjHqIuRh4m9nidYYn8fTdjFIyRx2LT/ sb8tT+se+apd09ZH7cYESQz12bs6E3ljbZ8d60zYRvJgaonS2WHctdnZPCVD qTxdU7emWuzGB/GQTJ1vKRBK7506PzxMfM3He329jT3rdu/tv0uRrpadt/98 d1Zb7e8l9qfsn7YO21FVWWsdTtin95uPpQrMw9wD/QXWoGw4VXBkmGdgn7rv yPQPI+y6DsNqbkAYCSpDmKuPmCoM35M+FYY5qsQFgCNuqzLE1blJQMcF6tw6 zkFV3NKqOdC/ZJo6BsfYVR2z6id3xGDFgO1fCgR0VJtJUyqKptpMnViHbkgI hISFDqHY1+mGBNWd2V23Q/zVkJ0fh+zUfXF6O0ZUYprab8U0tSOm83/8G+nr pLkdY+NXB0baBtJtAyNQ2j53/CmfPXnYNJfGx9QD0+aB9OEjTyl/YsQeaxvp t8fb+s2lHVfv8vhfbFd7cBPHGd/d27vTne+sk2QLPSwkIfkRVOOHbMsKCjq/ EoirgEsAO6kISQrmkaYY26EtCfwDBSZloEMapoUZnLbYhGaCH+AYB4IpnWTI TKZQZlrTTiZMxgm0QWmmuJQJ1rnfSjaTTLnH7t5+t/v97vd9+323F5m4ItA4 gC42Pdk6cFFf2zhYoVc0BZ5tbBuKx1rrvqVr731drbEHTBZjk7UyXfG6B4jr mDjOdNUxXXVMV1yPZ3Q1bWB+v6x1wITq2xq+n62HSI4MPrzG7W+rt2ubFzGH PrPQ79juHqUIH0c5obZ+JVDfr8LNRKV1pXVMBOuMiXKh2zwjcmxf6HeP4uMz Ig26LYF6NEstYi8191e3NPf7lz/VylylX3/2wTbrZEdG7EBNGxrhgueuzA3n N99EnQ88uh50dHd3d7KiO9SJUHP//OXN/TUtgEQUQdWaxjboWzDbx3GZvgFJ ahqZHgNhCEDgLqaOtUI4BAzqMuy6RNIj9IiEbRW6hlyeyh+dgwy+A27Yx5Gt g2UVmV3E1qF5hWz/0jVUVp2tYX/K6kGXvxI0DEVgKKsLs7VuKYXGgcIDpQci PYU9pT0RAXqHe6HT28tS6WBZL4e6Qp2zRECzqw3IBlhM3xuDBZ6M4h7WCIXa Qp04w9f/k41nSb9PbOfMrJ2Z6btmDZLt70TZl7PCUPfsoO6ZIRlhd2ZIRiGE XgjBPJzwNyWi+lMEG4I4QuK6DfHU4JAsUgMjp0ngDcKdxUVIwv3YgRwh7U4s HXtCm4wl0jEUh7Y2BUVFud/itxRCAYEeTfm4sSmdR/eQj46xSL/JaCHr+atI Q4/quSXmPo6YJIwkDVlN5/A8JEGYngeYXtNl6bZy2EfLKaEj5PUhy7FNTGMy lZ5MaSkUj2sxDXThJA4UkWrNVhMJE5KfZ51jJ2sv/Krn+ZU7x/a2P1IdMFpu 4H//A/sxuX7OuGKs+vJ3xvHD6xiSBkCiZ5As0R3FpFhuJ+3yIdJHjueKkklD cFk1hgnBF2cwnTLd5g8rDI11YwNDk0pPfBuMbRFXXUW4sN2anycSrml548MF 6/aeP9RX3/yW0TL43t1Pur/Eb+Kyvxpz7175lzFp3GNIuo0z+Bh2ohwUPy2Z cgRZHMFzdbdwBNfmyPIWXCQGzZCPfagcGHUq7S85QkB7MjGRBt2J1GQaW6LI Eo1WlNv8+XmCIBbX1EQCP8fO+d1PRVYsJnuw89JP9232dRU8t4Lpq8O7yQbY mHKoUveXYx0THAHra5yPK+co18hrGV0cctJjLzBdE8mE9nkSlaWSoAKsW0dK 8G7sNG6w2Q5C8Rag51BQzye1SCZF30BL76NNM6wV5WEYfxA7Z0ZPp6dvkIVg BQ7V6h4w/hLC5RHCgVOC5+EviIvnvoBZDmZwTCZST2h3EvDVsXhsN78g9Ir2 x4pyEYcxhzddNX7h5G99nccw/QY+p4gfA3daqUubyDbyKkxJ4X926Bke8yNk 9TsmicdIkdC7kBkJwiSpqzyiXuqj/ZRSpzyK+3APykKPJZinZ5ROJlNAM0r6 /RZBrK4JRsJckXHj11dexKR8ggYONE0HL/2MIQgjRBVA4MFx/ZnTjmHXGfeH 9APHZcdl52WXqcHdUNDgWek8TH/pOEF7C0yCy4dKhIhrMW1wNDgbXKagI+gM ujh7EV1J9ziOuI8UHPGcKDjhMVmRR/P4PBWelzw7PQc8f/GYPCwe2fPyqzxE U8weZjzC2NeBQhayrPYqNELeGCJYMbO/z4BXKVOIokO/0mvjpXG7HS8FyC6v eVzbSpxzr/4hS/YkY7sjFkswH0+HOiZgkYeSHTGLNYot4VCSxTLkmR4btEQZ hkFzptJztSg1aVHeZIHaEs2Gn7YBgTQ82arnSG6nm7htmNoQgongSraxpdPc 0noOuaevowK4PdPXa2tr23BHMpnEFn+NNVITqamuKgrME8TCmmC40g5+LgpU EKkyVaz13Hov9PDattb1JuOmE5vev3b3sUTYuPOYHfPGvdew9PeB+KoVq9du 3FZw88N/vv380HN1k8uKmJUS0zeoG6z0ELqmV+7Ov5RPthW8WkB6uTf5vrxh bpQfzvub42OnyZ6H99n3zSF++AejeI7N7veqmiKP4KCuLFWxru5Xiapi+wgm utlrK7MRG6PX1uvmMVB+WgO/Av8Dciqhm/YWq/3KGNhAsWvjO7z7vUe9J73n vbz3uji+NIiDrpB9fM5WPI6c82dtkcoaA+pkyhItS84YhBXssSOFGZnRGUoZ q0Aq0IeStkK7PVyZZU+M2O/TuIiEK+cAj6IdChSYF0xgTd3Ssmrrlu/VNHu3 /Lh1yeJ1OUba/cOLP/nTK+1Xtx8yPv/zB8bXeJd//Ys7N298Of8zbsOqx1t/ sOY7u44+vfOFPRc63Wd3XTC++gzWE5BLG4FXGanoEz2q+NSopDiVkLJc2aR8 qggpFQvUTgtpibpYfVrtU99R31clDHsGRVBFXs5RRaQoqjqC39ZdHM3jICwR haqcSqiMRF0dUy/Dw7u4BJkggZ0aRpTCAAQ70FP8fhnLzBBWTTwqnhc50WWO kx2EEGfuKP4uXpxZ1RMdkEwSsLbZwo5DEksnY4xCazTDoTXKwguF+GI2m2dd t1R5REkoHykfKzzKOi3QG4JMV43DlnB+wIItmGxPHycv3xoeNr4yTuLiO9xv p1b/17hG5uL/GDnAzCVwu09pUSbXLtDdXC0WhFoqSyc5QoQi7OPLecKfNH30 +0y2Y0k1dgfFU/FUNvLCYrBcYrETOzmV1VO3s5GU7aMQf54fhXllXHcGidPj uhSJVgklUIjM9aSS6ipBhwKexvVl/mKQQfEQmk/n8yVymVKLInxc2Yg2krXc On69qV2+yZkfFzBL0ZwsSVSUMPYhEUKsKEiU+nghj+cFk6y7PItkpiLH5amS CwnHCVQawWf1XEEk/6O6WmCjOM7wzmN3ZnbP5/X5ceezze3h2D5sjM/HGgN2 4lUhLtTioZgSHjWPBAJCEeFQeSRtjFueblyVVElwoiBbLUgVScPDAWwHCqWE NImaVAWFkJbWEgFThBtUUUKAW/efPTsit9qZ3dFobv9/vvm+71cp1LXcFwyG gYWWQ9kJa6A4agPO7sWPOCIiUFy0CSz68SMKhRnCAo7ON5Y8PSoc+Xdakrdb kqHU7MdXTr8GPAxJaaifNQT7VAWMVOFJwc4Xz+6cEJIdM+vrd549m961d4Ut MmylQm5X0yED/OMY8I99Chl2j3Cq9w+7kKkHhzU6efII46T5KholcKFoNiHq KfcPbaljz7vncB2aUv7ROTTL7VH7H/wCW6kBySLLhwfVJaBhYeUzZ/YO0Z7T nteldGofiAvkgvE/IkpEzBfLGJczLm+DukHsUDnLZsFgdjA4DpeTEpXF1NfV PeJD8r6hNqA5oMZPmAoaUG7Bpkr+zgrZXq9DHL1okRMMVVLud/wB29+0NBPN yUSZTm7IBm6POWMDlTrJ/Mo/X/lK8ZYKxwtRYW5ZN0OZLMLicBp6cUdPQWtz OrlJqagtcBKAX4BSbgO9f1khe/nQIpUOSQpWNVpsKVmmErWCeUG1VDJIlilp hTagyPfcv9x0/+HuQi8gG2X8bkXC/Xt4/8bffvzn7o0HcMHiW/9Gv0KL0Fr0 ateSQ43rt91w77k3br4mMfsKYHY5YNYEw7DFmRgDGH4/uJKu9KnlwSnBGXkL 81bnqVOCkwp2FryuvmaokawSpODsQEmmyfPLDjIkgd0jDFtG5WS3RZEVjUdx NCtgKZYZN7HZi1/qsaqbR4U8BWLWkrxTkfRMRKq+wXOsSksSvFsU6NAzbpq8 iqOgcYnaxzDwZWlZafEruOj4sp/1LqusfWbW1qf2pc6j2OWf1s5YWl//bPNj R9X+wtIz7uAnR7d2P91UHqFnHtT4A/PfP3Dg2DMBv8TIHmDEbRCpUNY7DVyl mlrCLB7np/i/OK3iuznmXCG0BCMsFM4atDka1p4gQG44bBlxAxtUWEjKOoAC YtIfjsnbwnrJZp5JSdUHpCRAT1Q4C57nyo169x4ylKrDK1Jvqv133f13Uy/L b3sK8HsS8GspnzuNk8c0jZnPNvKNvu18m297cFuB0IJaQSAYKIhlxUKxcGwM n2EspvPEImMN/Ql9IfTj8DH/MfODjHPmRXPQ9JNCzZJ4dSLhKRFYHUJCeYWV mghIyAaa5mSjbInXbInX8rzKTAK2z8pfCsNlgfk4YlkEQh4bH4vH5pd16yhT j+hxnegSt9HWru/gVgZv3h5KekyQxi/AVwpkfSpZIY3KCIRRDRg2CiIH2wlm YqJFR1CcawYAxbU1pAG3trhdR6+5B94+3ffLvwGVTxzvfhF5q+3M1esnWt6b hgu+TvUuav8jWnX+KlqxdObVj2qfffHOf9377v2Zdj/E2QGpfBd2mCjP9Skq wDJh26qEZ3GJ1zsNOUFbUR11rtqmDqhqRF2mrlNvqbRNhXOKicIxuQS12CFl QCGn5emXu/1XeKPKWlo9Gvj6kXKrwSs4kuuBq6Sl7kAxtf9eI3zHXkDafvUd KOgedcJzmVybAssonKphqEkeBpFW3fcwiFy57qzUyNJy1WjuXhTDA+o792d+ LZECcNHyIUYfDjmGQUp5qQHKjEjvcJsjCqfaujW1zha9wwM9I72zr3ACjEKj Ca5fETd1SoWuZ+NCaoqIXozHU0tUQem1mq4Ua/RNeDPdJw7oR0W/fkfc0/O6 6G7RpZ8TH+oX8ef0M3FJH8TX6VVxQ8/YJDbrW3EH3So69N2YLTBW4jV0lVit b8TPUzYdN9Hpokl/kj8pFugspFf5bTyV2qJOb/AzaSY0IfRcHKZBwUYEPgKJ 0oXqYyyh+X0JryTCfC7PsA3ZeFH6jQybO/4y25ANDL3pmPLB4ATqXYSZDo4E FKoBwBcc8b4tqGrIvDAkBwp6h+ucSvgXi3IhEmlrg6HKSxAMjxiWIT6KsU8H vWU84kf+XpTRwzSV9kNtJWG1uCUNp2DzPFtNMIdt4Yif3AK7cNKwDB/uxZOd AODIgYmKA5OURMSHfHKZjOoNYCtuJ4cqKsz6/5j14XwzlUwl68MhE2QUBsAW wcebnr7C135XV0c0NLsZ5JMPDxw2LCmYLd7Pw2GFUpGUsEEoKq0KEOjL6D2k I4ZOuEPuZfeK+0+QzRC5fq+R/vx+q7wBU52gAcWSGdEnjl8QjeeTIKcBOA2Q XaUnYDSQ3nTYsnfKISKSYDyHMU44xowIyBfkilAZMZUR04T2qVfnveTkO8Zc Y5lB1hltBu42Ths4zaZcjCwqvJKludkWCe9knJZVk0ewG749G2AxQDYgyDsj b975k3ZxigL3zgkyeMhQGkfSXAw4AlDBrTRGTh8XEjWeEZG1UHV8mjer7ZhR w9uMGi+wR8MTbN4MjUrySII4hDaS7SAM3fwI/5JoZ8mn/AtOLFLFbVLH5/Bf ky7eTQ7yQ+QUN9IGb2KNjZ2JnsEbcDKqEja2ZMNyamBkjyOiE2w8DxpvduMY C96g4ZixECZBNh6XsTo8kc3GDvsRns9EDi5gs/Dj7A32FvsYX8LX8SD7Bhtl OMZ+wDazXextrEkOWl8x+lNGobBQ8ZAgOQRldSILL0DZ7sXUYQBAJTl/r5Gc eDBdOoCFoD2DoD2ZSoHyG+eHe9Q9vNPX6accMT/PZKGy0GaxKcA2ZW3O3UHb ebtvh397oD1nV+6u4K7QjrCPBQAJ4dxAOCccyg2z7MoMkV/JSF7ZQR0puqlb aeVwrHiRU7SsaF1RW1F3kWYV3SrCRWZZt4IywXrEvT3v6Cls/dO38uL5hBbP J3juG4CehGLKrp00SepH2gwpKCcwWltpC6clfr+qvQdNR9vdVvek2+e2oupr hw9fuXz8+AC+MNC57kjFVHet+4a7130OLNHqb9zh4eEHd+/LPLwKrH0XToHM wyanRFP7cvr+T3a5B0dV3XH8nvt+791kX3dvVnbv3TxgQ7LAJhAEvRQICYEQ anisdTGgIZCOE0JBoFMgOBbwVVE02MKUjA+o0kEkoCHKGHAK4j8wVAOIDGIR LJ3IjGUQB7Lp79xdSJhms+fsuXtn9p7f+f2+v883QE1jUBPTy5A57nxFVQlD w3zgInjf/7GPb1gont0fE9JcQ1U+7378uUc/WVAYJCA4MMA7cIMs5h9LB4NY jvcG9PM6Oo/UX697b9G22uYTR958/+nJC6rKOphuX+TC+5u6lrq9/Wfoo+mG kkWT6pYoIvww4B3zCezHS0SIW/YzFa5q1zyuWWqW3xN2qx3Wh+pZQWR5VvTz PrFcrVQrXRyvCW6P6nF5tHK13DXNtVJdo/1TlFYLq/WnQ5uFzfrGECv4PILs Uh9RV6rPqq+pb6mMGlZkj6LILtmr+H35uZoHNXg6PKTHQ4QjOFwQOC/Bq9iO FBKKppDKl0ZhB7uP7WFPsTS7aZmFwlbcIq2Id2jUzFFPDEbNyYW+G6m+u+Zj ELEcFQAFSKlgFpHbcY8OdLSmcEBHO/HkfD5/boQqIS3L7R6MqtVOtvznq7aj RxrWNnem/9q7vH7B4gnnv2qeMKsqeuAq0z3ri2feOZM3buOe9Hfo4T3JSP8O qjY6/1fTfwMGFJRz+sAV+ieonWJ0yp54yN0V+rDoWDEN5sIL5sIbiDUyjUUr 2NXKiqJzcq8lJ8U56hwzaS2RF+c0RZYWNRWvCm0MtUfkHAt37AeGJfBsN+rB xGxztnXEPGLRrWartcHcYF0yL1lsTByhRM2oVaEkrBqxRpliTraalUZrjfJ7 8znleXOXuFv5m5kriILCmqyli7riMznTEhUa+ecGbD2caAmglsDOABnoJhsJ A1RIBkg0kDHSQxFVCMtSdTCciCMb1aEGtAV1oH2oB/HoR9oOVmg0okeOEALX B/zIb+f6E/4arrAgWDKssEPbB6xfg667MweojzydzfmaR+Z/QNjjkjPx6dVq N2GOLcdWpzV2IxW7nJmXxy5Dt8tI1+THQJpNiIcRegjicSo7/2t/boUJ4YEJ Vif25+DVKduVU6GEcypE5+3C136wVRmuKRViAL9zK2JD/5JZ1PCOF8crZWYZ xLFamWxWWrvEd02RSCXvmpF8ny8jLIXOqyxRPgitHOv1+H20k1nYl01H4eDO TS+/MnFG4tCPDZvWX38XeZCfS5/NXbt2Q3Vp8Ti07+TKFweIT9PX0r3oQt4r m9fMTlQbOSUPzl2zd9lni3/6Qml9osysSOSXLn7q8AvrvvktQji/ikGTDkEN c+BZrFIhTseZOmGZ0CZsETgWMWQ+TZEcwQt+f5Bej/stGmmLLBdGcWI9riJY uim1jlxGtpFbSJrU+f6/Z09l9vwPSDgVx7P0T4BhauOUy1lNmuDgJzSOMuxY 0MX0TPqldC199Nat2w/BU22FjhGFp9KJ5+1xHM8JnAYiIkzjpwncPGGu1q5t c7/h3e7brX3kO+P9nr3JSoosg23k8nMFWQorJzFUARqYtlFnNBjUMqPNIMNG 3OgwegzaQMDdYT2u9+iUjoUgOAQEHPeYoYAJuC9gMXAwPDfihiPxOaUNPU9T ScvEtrFsKyqScl/+w7q2ICqKbzi79/S5dZ4QNMErh8c9+lRT+14qdiedvvV1 e3Lh9jnrbkLUBwZAOethfyxSOwkK8UCdkG0OfNYHxyd6+F7US56jzzEMBt3V zDbUTv6ZfoPZyfMUIbGlPIbpBn4V4nTCxw4nCthqYho7D06RIskwIjxwuCxF 02GG9TAMS3WRi2yJJcCTAkchkukmFxI0FCKktkSj9XQbfZH+lqbpLiTZ4nqq jbpIfQvQD7V6EO4A7OxGEkGSC20hjhDSuQVZ3ZzZr0OFpW6kUrFA3z2q7Luf KQeJqadTy7DSQcCkeoDplANKWEZTRAwBWUQQJktESv030CT0O9SExvf/l+m+ /Rk9EYwPZAZHENwL2J2gATsnRsXYsDRGoiGQkg2BYyGCnTBTQ+b9ehnw31Vb CIYSog6DfHdF4BWD9TDpCyXoMAwcGAZWDhJeYTiRL3D/Fq/KPwu/iD/LzHHm hHhc/pr4EvxJr3yN+F4Q9tBvMXvEd+SP6U7mY/Gg/DktlNAmUyqG5e30Vma7 +LrMZzZ/gEeqwuJerkYyiCvAB7AXEfzIOzozzmOH7cU+5Em8kliKQByYDcHx GpCFg17DaUfGgaMSzYS7BuKdLFiNroHR9mMUIYeHZIDIMsxoSfRIkiiwHBfm BQ/PC7Qky1lTAj9CyQSJaJliRIkTeJbnOCabJI49gaYKlV8K7qMLxW0xzB6W Dtul2A3CUg6DDID31JW7+RDUZ/angoH+/qDenwrUQsFfuZcVWvblPD38u52R cGMLMnNovtw/ZVjasSCtWf7EQytOlVxIlVwnZVBj+k1UegHJ0FHQJTQivSN9 LP1N+gJUoZu6foegCfAjVbe7QLKqB36gS+iHCIsYjVrtJVyQz2NCvuB0oyqv Ov+8dtEtlOuV+ryCxXpTwcaCV/WtwV3BQ8bx4OeGzLKK18fqvkJ2uDepryI3 krvYg+wxVv40cU4jQ9HRo9zFStSOlSSitlkEgx5KtETvRMloZQgfelx1JSaG EBHSQvtCv4ToUKgYjSFsuIoJlSTmROw898MR29BgCAQTkS5yxUGakxWxGOcO fOfM8LUzwx3FcIdte6QHRhXww4UiJTlM3imT4AUHwA7aqi8hB2clUKIBKudP uHTHDI887kcX/WiW/3F/i5/y62OWTsry8HLom619qVotdTOWWV12FBCiDQkI lsjppg4TxTJpvb80hFqTfXcLPAomyAgl6qNPRslULAnFHYOzplQtI/etKdz2 CqHJYWCiPD5/BPc9lgUZxb1vbPnYDGQjzKZeDygtXCovQ40DsdMnP+mqoYz8 9DVJ46iqt1NvH567/dV/zKhrqalHC8qvRcfOnzJj6hhNIr8r+ctryec+Sne9 +McZeWN1vrJy/+ZHX6rJyw/nzZ76YPp0zv/IrhbYKK4r+t78Pzszu7M7szP+ rL2xWWNvkGN2jTF2sgMY83H5ldRloRtDWgzbtMQmaoC0DhYQDGrLpyFNIKYY tQiaUEGMMDaUglCaIFVVaarSCon+RIIQsbBah5DgHXrfrA2Vamv3zc6+2ffe veeee85Uq6KxoXVqrK58DYS8B9Cw39PkRejQENIf3ndq5Pq6wrmFlN7KtUqt ZquVLvqc52qZBqUhWFs4h2lRWoJzCvfzB0TJpwL8UQEkoZ/lQyQXQVnWkBSO CgUdERzxV1J0TBvElY4Pd6BuolqKU/l4dzYuHM41frIItHpeqQ+TXgPSoDOD M7OXO3I71y61m+1WtojNgNOKg9AMQOh0MCUQsAojCM3okS/pwfbW/suumxta +Z6jJ+dvzmzbvnbNDvZcbmS/e8v9wh1xr69M91JVRxd3HH534MghwqVfg7On oBJs9E9n6XItrafNdVpWz5pd1mb7TepN3wf+D6y/+K9Zt7nbwu3gbeM+F5we nG4s0BeYzVbal/XxM/Q6s86iN7IbtR52h7bLPq4fM4f0AVNUPYQWJlWviYSS akIhd+xI0hu1QFI5hxkkQcz0gIwcmIocmIcSewGn54C+GPiqNMxjchdHUbVC LpToYmjtBYV8NGQXLM+HciERfZmFw/HR4TiovtHMTUBsbjQehzGvtSCmnqrK o2paHUtAR+wdQJGpce+o31yc7drywpJ2A4fio7+/7d7B5vDlj6lPpy57dt87 F3pXvlj9m8s4hhnM40nHiJd7FmK3ehw3e50peppLS2k9j5a3ABr3RbEj0h2h ZtBJ3wwjaS+gm3wLjCb7gCiGPLjIBDWOKvOqBqmQwpWqEsMEKZqGCvYQ7EQF u3h546MTdt7LI8brBnm/6jkQwIqS5bJSVs+jhcuko9Ha8QOCcw0Hovh/ocKs dh/MfG/FWfeBe7l/K7ZzenXTK6t3bl/7rZ7elWlcAUpcxfZ+yj/W8c5X1h/9 xdkjh+G8M+G8FYCVECrCPx9CfqiTZrn+gHhQ+an/OHtMOi+eVwYLBCGE51Fz uWZpceS4MsANFHwoXfFdk/7qu89/rihFWpHhAEMYjhpIasZF4w8GbXhoiKS8 UQ3DSP3YAfunL1FXqZRq6cQxDNiFSZzQEZlTXJr0xicq82N8Sn60irzR0YBO +yCkyA/bbtN1CPNpRtYtEu5ymUdRXG3kQVQdaYu8GDkcYSJaVHAULQkBH2fD OIl4hoBqFIpzGAyDE7KcyaGU5UQ0eAMKtghXe3o/lfMMhQ6bgBk62QxM0sep moz9E1NHx5uY9wCCL/R6sun+MBlOnRalZ7yPM6Mpr82lbxIGzXjLqw5ESSWL qmR51YFgea0wXd0I5Ay2BlprwlOqwBaYQLwUxCnBOKKjnm4N5p1FmPoSW9Nu n3TvvJbFoT8NY53LOfTW1bNWVNCbWr/R2IjxV6sPHjmz7wZgIe5+6F7o+uE8 /J1Xtsye/RLhDQsK4BPwpCYadKZOY3AVU+ovDaSZbosVmIsWZZgBKqSbATWo Ib8axMhPhURBk3Gb/FCmZJIIicMBzcQPTWySjxE//O4I/DQXDEliIiUsFpYI tDDZXx1oC1CBQcw4ihqMUaE21GdeMimTYEL0JU07vGmIyqJ8zoBSx8BbjGXA bNg3kQVlkulszMErBW/1UzX4G+9DwYTntqaGeY8VjIRRBvRaZvXWH/jeppdi s595uvajj9xbvUxsyY7ty8rf99cvbbkxdpae79W+u5RZ5SmIarzIeX5jcU8x pfuUjpodSncNU4rLqDL6KZygErSDZ1Oz6ZVaOpSe1FrZCql6QbsfuB/UG5SE 2TA58WSL0mS2TG56csSXC0u7oWfLPkWu8ikVqhk2pig+sIBWOamAM14FeEBX Ax5ITsu+/Di5Kl8AZZPyY00yXwiiUeg1/jaWEE6JVkEGVZpCAi4bvGVzVZVy rMAipCPadkHBnhpcAxQ06EgoUR7V7acesc/oOP/4h/25mxPNKje6IS/IJvo/ 8jbnLd4PyfHgi4lsRUTykRcv+CdaXKfHW1o2lJ20trI9nq3mSJcLs2Z4ou/X AoWNAzhcC94L/FYpCIVg6DGXbcYzheLJrevrJgWVVy9d63oe44u/7cb8Mx3n 97j//tfYtlVrd+9ct2Zbc8V0IxI1a8qee/vEmT1/xjIu+NUbY3N/fe7bjUO7 VWrbLw8d+dnRvkMQrJ8gxKSB103U78Q1XILrSSL9s/CswN/wF1jkWZMtp5YH 1gVYjKlgKKAH6RCFNRLUYpoXJSlkSCZCshQTRKe0PHlSxA9FLEKYISXmE+XJ vVafRXVYIxZ118IWCsVMw6MtmNtn4BEDG3Y4lQ9854Y4caGLiCGN3xv/lHcD oKiHIaZhT14JnkGFbkAEQoQyAMpJr91x5BK/u/PC6t7Fxe6t0qVPN69PuLdA Fnx8eF7Hzj25fVTNsRW1Tbt25D6FQwO2X4dCPAGXNDitjUNIhJ2lAlLKEZeI VLd4SrwkXhXvimyJuErcIvbBDZbmeMQyNHQxB11F/4AnM6CJOJbjGYnioWd6 WIyWJxlbGD/X43OkvPKkWT85UV4kbogHyabh9Tq23VvYZgYw4449WMDEHlyH DO2CDLXBDmX0H+Ipb5xWAinPUnXZU5I87aeDXIXYzp2ULkpXxN9J1yVpGb2K phTeEpu5rwsvc+yA+HdmmBljPuPYRfwioZ3rYn7EvM30sge5g/xBQSphdC7O xNkqroqvEqqVFqaFlUCTipIoSKwk0hwjswwHp0SyLPASLUkyM0h91ylgq4X6 Eh7zaxRKjuFuhEtgw7Yv9f1xiU3ObfvvdVpQUcQLoXwm4R+qpEfo8r8vNE5U E/3wSr8YTaIJ+9OJNoCiJiqQGJ4o5gO7sI3n4xXuG/g194/uZ9vA7NzDL7s/ yD2Hb+xyT8DSj7O5bAixEKNKkkt2CUt1s6fYS+xV9i7LlrCr2C1sH9xg4Ug0 SDI6htFE1pDN/F/WxvOUyOeIPfdlM6z1KkLcW8CKFbhhCFXC0xlYC7qQz+BM X5JOCkkrWdZEzRHmWE1l/+W7amCbuO74vbvznc++s3322eev4PiS3NlxitPG TgikzVFSF5IywkcAB7KkFAIpHZBu2Vg3tWmb8ZWuDLR88NVEDEHKqpISmBJt 07J1Gqq6qWhtpZVNI9KoQqeiBikL7USc/d854avqLN979+6en/z/v/f/ffC5 VDy6mmuKtkf7oqeYM+xp/iJzkR+MXo6ORW1ENB6thRe/i16NMlHdH0xUwrjd eGliwzTrz8G0cd7Chg32oFmHKGqBYFDVLHD07A7VKer1ySYR7YSDNEymdLs/ oOYE4dnOIGoKoiA8u1CgqhpWXOcJQjNECFeJe70U/rcGUzV9MVwVcOVrCU1f +Ggirn2gXdUouxbS2jWK0HK1Ym1GozVf5F8VcyYqC4mxLFZWTAHfAyVNtTbg bq50HUb5Vt4AcDSwEfL5fAzTEoq5wm7sj2TDJckeo5S1O6V8t6pfRFTnaHN3 cerkxraTEajtHG3lom3zM+PzKksXb3soM06rh95cU1e3pnFjVe90mmx8Y37F 0s7uDEmmjtUXpTqOTN+GPTuE0Q72zEP06V7WJbvqzdvM9DCNYLccVeYq+2cO E2NAm8jaBIa3WkGqkkj1EAa0EWgGFvkmaLNYVd6G8ysI/B2E49EEsNz9CGdk 6msgly2MOZUbvg/SjCQB0NHpzHj+yvJl34sBUJg6P2w4uiJEzntry4LajvOZ EK0ev7BkW8ePMK6tAv16FCIVwO306Euvo3HzLdctN32JvG4inT6TjyPTjrWu tZ60t4fsZXrNPfww9zH5d9M/uI/5cdM4c11wnDG/T/6Zedf8J97UZt7PdJgp 0TiFVhmnSKJZqZz1NwV2BciALUzcZ0+yJi8r2ufYj2txNINmb/HSCFMfanAl nBAW4ZbA4OWrBffw3KoD08dvokTmvc8PZ24dQLndO3Z0de3Y0U0qryHmQObS Fzcz73bMDLwxMNB/fGAAx9uZeY7ugXgd4E+O6vMXuJa6SGeCKhfKXYlAFbVM WOaqCnwV4LDHnfMtU+xXATPUz71+1mO1Ouy2OT8rRm02u+pwGEbF+qCjXX6j AjbSce1rntbgJsz32NPe41NAh8FO4phnTS22Knej7kRMydvPjiAyc3tk/cEV sMWe15s3vbLnma37YGtrN2f+mZnOTGU+SdVNf0aNDP3yxNCZk9irbIDYN0Hs IpFDnNDLnBVkQkhIFcFqskqokqqD5l0hlGN2y4m0KW1ZJ6x1peW0f23Oacvp 4JfclHBL4kXCFsBJoK1unASXlbU7GC8YsnnOKDhTVRTthmo66EAOfygrk6bu iX/ygfBjrbMJaDG1WJpdLXKLrzkHEoBExhA5WSeKVQ5K3LWp1LKyU40X2w4g avTZYxWIykz8ZHPz/o6nnz6ceY70PLl6Xx9yIOCY+g0n/puiLvyi7+TguWNv Y4W+lyCoMmP3B/RIjwlxNrTa1GxqM1Fx53rbNtsuJ23h7HyIJw/yMzxZya/g SX6Y/IEeZVmocIpkLBGCc3DF3C6O5vwvOfucZKPzJec552Un7XQQKqKME0CS 7agfkcgnVo6gYFaGt95T0FMNvuVZIQ7JgPoufyR7GFqJmkF5dc1gcmX9+ncs jyyAkxA2qvqOJGdE1I9resn2qqb0uicfXbQqTqs926uS/5m/+GzmJsRYDBXt gBgLyT/oo4zI5Jk1WZTzep29Uo/WVcixUkoinb8WRmyXwp/mfSlMKUxUqBO2 CF3WHucZZYRnF+fp+VXqVmWzute5V9qjvJrPlalPMClrtbDCngo/rrBKvqaW 8clwUknmJfNZxmISubBX0HhFUfLYfEUv+i6/W/qh+/vRtsJ97o7Co+6uwgvK hTyhHR2UX/MeKXyzcLCIkcMePZyX8OjBUCLkQVfB9JSYw7UFBwvIAt2bkyjw F2F8lIF3aotQcRGKF6GieeFiOFwlKEzMcpPRw5QsM3MCMHNs9zBO+W3gG9Do rTdmMTTWikfARDeIrJjQkwxCDPIgVSkNp8JrUFrejFrkKWRBMkn7wwoZcQk8 GfE30ohORay1fuRPuVhwTfDFAn7uamgNjBDKzPvYc4SHs70yPDM2NC8fj8eG QvnZsc9vjPUA3GwXUKmSUnqFnyt/VD5SmLDCCzTtJ2ZdDVGC/c2Q/FAl9IND nOUxY6wUJHCv5wD7E6gY6agW0U2oHU0gioBzX4uaEG3MdHlgJkL6coJGjfQE TeIQPDos7SmRdVhX1mFRWU+WJWQ9Nh+agig0sK5dDsmN8k6Zluv8OvCX3Y9q /TN+cjb41thkQ5bNr8XwcDI2y+/XYtlkZF+ms56yFT4NDUs2gnTLn3lP56zO SnsEGsjD578SynmJL8e35/lyyNC/37GWE/jHCH4PjOAq8Bi2Jwlkr8GhA3eK AcGEKY8FOAAfCGJAArBQi5HfueOZ75QVSO5lmbc2vHjl0ysfRTK3xMb1O4tz gyr6fXr95BefTKN4bFVdJBjPdUtizWNrjxz4zeudDz/2eMiTN88dbK6u2XP4 r4NQRaGZ6+Qh0wlgxb/o0VwCzKslal9oq7al7azPTXgpj5uQnS4JyU5SQl6K Yy0s78XpthNyvzwoU03QjcqUPIzo826ESWOIcDMsxk0bb+XiljhBxFEjoATM 0CNeSpWdde5KqU86J1FNUrv0M+myNCGZCMkh5UrFEi35/Lv75+RUzWAZ4MQi wIkRQpoZXZCuWH4blNRkQ4Vj0oehBRAWMBemXgMhJZbY4YMxBrnzRMnIqYyT pkJKxbxkSbJAJF8YtWpBrdq76cdPvVBu5V5+GflpdSyz5pVYMHClsGTlEw93 oQ/GPjyV2Q/5+SmgzGpaBYV0XJfXiVvFbhPFMT6mgqwQa8gacZxkDe8n0lYP YXFLkoVjXJLqdhMYIG0eQyd50AzU/P/RSZz5jkAyowkzMn+zBcySzAP6qCGc ZIwwkyCOjLBLS/Et9a2Fv23ZfvYp5Autqlz6fCHy9dVt+vbZbrI/4x3bsmhF 2zU0CqYK4rSCEqyHOK0ooLtNEX88weKGwY0ZN2Cx/jYEvWHncv0LE0dpxFBW s9nCW8Gzkv9jv/pi4zjK+G9mZ3dvZ/fu9u589t3l39n5Yydn13Z9tnPGrTdx Ejtp7DjBaWKEoQlpqoChxDSKKYjkAZSUh7bqUyVUQSsVHvpA67iNE14qFJGm IFSBgpSAREStCCICVpS6Tujd8c3upSBEZJDKA9LN3W9mvt3Z2Z3f92e+iWsZ KyMb0GJftB3y7XmvdkU2L6HbNUjba7HBzqPHPgUrCEkzkoUdfy7bqssLBosZ kOjr6yU15lRiXFjmxW1IYUvL4pwZ1LcKYfVEanlT3g6vCreFvbAI19VlXNkn d9ExbJa3ebbgBVv0iV1CE+d5G6WoJ72o0wmWpRCisbRzgWwrrYwrlxq6OU47 1Xh6eOvjW677sp+hq/Q8XmD0Cb5r52jDUn5KpZ7VJ+q6uru6E3QEO1saZY3v 9NQZEfddVl8i9op/eHNrbUsLXxlwatGJaCNx6vBGr52YlTC4NHVrGWr5ShHT M2aNtVLGHCee03LGarugFYxBbdB4UXvRsCJqpVPNA0ShLYQuLFsKZxkyolav sdIy6Tir0SQa9RarSTY67ejWH7a2YYAP6IPmdus4psRxfcqaksedUzgtTumn rdPylHMFV8Rl/bJ1RV52buCGmNPnrBtyzrmDO2JBXzQXrDtywWnRZ8u/9qxl PXmxjiprtnzVl6SSnHv3oCRDReB0jzKPt89Sa3tUVVQcYnRmUPfpGKvue0nq 2J6SbIOCuEkWZCmlq1ORiqgqHvqan/mpLfTsbHnojCEtand6D2pwsvSU5oAz 4Wi6tE0rZIRMU9eFUPbhSDIUyNZIX4RHyChCmywWQZY4/zJsggeNRWayLB2+ cI5lglwlkx4qZlLFYiZdTAVGgED9fZVTmtvrfxD9Y36NmP+VZBcIgrcfw2kn gIr8M7YXLtCKF6fDBVrwIoV923PUlXkK+1rQkHRt2lbStXubgL+LqLxI2VdC /Vm9prGx0ussdvEsi77xc5YsvVa6dXaGbGyQzyr87Sp/rbiXrCxS2i32kJUl WH4m3qSzhNp3U040H6oNR/OmqgxV6bV0jSs1rCLv1Q1DhO2I4XIkDJHggt5H qX/iMUo6ZtmPyfWi4dZIE7LJtuRjSW2eXNzfldflVevFl6/MJ4lkUdC8VDp/ QlMJYaNncV/ijCspzgrwlnfls2hT54SaC5WonhsqpqlWHlj0Wc/ljk4Oubfn 6IQ03hpQT94XI7bjAfVmxO1VlAeEjz/yukubQg9tCtPCxfnyPHn5/BuayzZS GfO3YL38Ry8SjvUl3ESaqniqj2x6/gwJqp0mOZhrLKDbjGiUhzeqwNkdYbnS IltdeqZ/bf++EyO7h9ObOw9+Lk3UR/itj/i58YMPNcR+F/7amPLxBsq0f0Ps u2xoJn5JMMpIyl67G8tLRpXJQpJ/yBYl77YH5ICzn+3nR9gRfiIe+r14z/mr uOYI2SpeNn/Cn0IIko1SZkdmzVqdl/1tJeq6kM+J71NSk133AAVflpuxZIcb rSSFqvXWqqww6kaz0baoFz0RNaIZ4v5tytV53Ax14KTzvErvySwsmsN06pTE ctOk8H+fWzqUW8amvnEvt1QJ/Xhu0r1N29DRyYVxdeV2783cpHKW4gdzVN9U LTsaOP45Usd7XsRK5VkUso1aaYaULnMKY5UjAPnNUV9VnPYKaRds1yGEfY8Y Q0cn6+o2TL2zPsnMro76ZAN79mBr+0jpGe0rpS8+d2w5O/NbdumrrRrjf7pY av6e+SHKZRzTHmWv6m9pJqK0n70Ea4ZUhPVkOKiUif8CC6Tgk/+EeYA/TPgm 4VcBtFF6z12K83sAc+I++Nn9YXkB5NOAfSiAQ68Ob6vgl/9AZAPgfguI0/sT 3wZqRgMkZ4FUikBHv/SzQOYdYIX8z7CKnsvWAPUjQAN9x5qdwFpCYxPQpPBu gPXExYaDQHMt0ELf10JcPPBnSuz+ArQRD3map3Mj0JUFup8CClcDfGo/0Hu9 iv81HhJVVFFFFVVUUUUVVVRRRRVVVFFFFVX8PwAcDKrUQFM9liEYWLJoldZ2 gKgbi6MmWVvnX1kR3FiDdY1YvwHNQGtb+4Md6Ozq3ljo+XiCLVu3DQxu3/HI TgzvGtm959Ojex/dt3/sM/js+H3e+NbSH/VJFoEfUN2ALPU41evRijx6sAlb MIDtGME+HMFxPI0XsulymcZm0USrbffH9GMbjdmJPTiAL+HrwZjy+/f/Yc21 lyqaWKpoS44I4XBlLg0xqlllRTH6BX2Deg1K48KiKw3oqPQ5Ithb6Wt0/QuV vqD+dyp9g/o/Gt4x0D80kts0eeTARPPmJycOLX0Bw9hB1PVjiMjLEUmTROAB TBBpm/EktYeIrsfxBI5R/wDdXXr8JzFCMaI34RZ6abU6MeCSpvcSRcOkVY1k Wjx7nu6EBIRP470Wh3mcHv+4/Ksa+qjAI7t4IaSm+UUoKXhFG/z6E7WHj57/ fLT3g1A65I9+5f1e33XevPTD7969+1HR3RpKkqj048/89wEAefPRigplbmRz dHJlYW0NZW5kb2JqDTQ3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMTc5NzggL0xlbmd0aDEgMjkyNjQgPj4gDXN0cmVhbQ0KSIlc Vgt0jVcW/vY+/39vmhDRkHg2N24eROIRKp4RciOpNASxmqjRXJFHQ0g0NLGk pWYQUVSJV7VDp6WC3CBefch4DKWWpYowljIzlCpFqzIi98zO7axZ7dy9zlr7 nH+fc76997f3uSAALTEPCqmjx/WMnpycvhooOiGro7IKnIWjTi5eBExvA9A3 WbOLbdqxeY18uwJYS3IKcwtowqcrAa80wDydO600599f3N8JhH8GxGzOy3ZO OdZmlRcws53s6ZcnCy3KrDMB3xCZh+QVFJe0XpM5S+ZJMlzTZmQ5cahVCfBK psz3FDhLCr0u01LBs1XsbdOdBdk5XU5vBwrlTNpYOOO1Yv2zfMGMW83fC2dm F5Z2SDwCdGoAvI+YywTViwiS0UkVQTDo6zJuNQ/3SP3UnAq7O0//Q8XK7tX/ Hb/+QrEVy8gHZXgLCYjGX3ASU1GIMajGYNyni0iEIVavoxvi0IQAcmIExchs GQL1Sfnysr7NN8FYh/l4iFm4gCz8DRaspz4IQX98hSE6F/5mPfphIVbrv8Nq 9MVHqNdXtBtJ2Ix6Gkzj1DwzFi9hDuZiKQVSBPWnuQgTDCX4HHXs90wtWiAF o5CGdORij0Fyp4lUVNN5FS83paOCnqc6vR02QRWGKAyjftxdH8RziEBfDMJQ /AmrsBYXqQcNUb2NAwgUn5w4QL4UQF3okH4PQSIpmChIl6IS23AKpyiI0rin yjQ/cd+CL2YIwjJU4DwekDe9RCW8X+1wD9X5erc+Krtj5B4HRgruMqwR77Zg L+rwV4lJPXWmVFpD94xiM7ppvvus+5oO0A/QSrCORx6m402US27ex2Fcxr/Q QAZ5UWs6zL34svI13jcDNfSiZgagJ4ZJtEqwCItFDsiOY2SjrtSHiukC+3Ir nsZvcBX/oMpVjfqn8Z2O11v1EYn5bVhhFwnDWMlqmWRtueRuO3aiFvtxAt/j Pn6WSOZTBdVQLT3mNryDzxtPzXrzvt6on8JHoh2KSPQS6SMRTMQLgmU61kum vsRpqZkneEIdaQC9QYtoCS2j1VRJ39IvvJDP8FVVqT5RLnXCICPayDcrzGuW MVanu9K9XieLd/5ydl/hTazEMFu4+Jpw4j2J4y7swyHB9hiNEhd/8TaEBtFY KqG5NJ+W05/pEidxPs/gQkWqs7KrcLXYCDKqjLPGZXOOWeEOc2foHmjmjbew YZDgThd5BTlyyxyRColDNT6TbB0X1t4WNj9Co9zGkmcfakvBFE4JIuMl6+k0 iZyUR2X0IVXRZbrHftyOu/ByXsUf8tf8nSpS76oNarc6p9yGNn3MaJFkM0P8 rTIfWsZbyq3DrZOtW7y+aopoOtF01d3C3dYd7h7n/qP7U52uZ+vX9Sa9Re/Q 1brOU6lKuNtZ+GUTCUcPqZxkvIhJgn8qioSTS7AC74hsER92Yw+OCuPO4mtc xbciN3FLMnvH49MjPBWf2pGdegtfYmgiTaYcKqQ5HnmL1tI62kAuOkR1dJLO 0UWqp2siv9BjauBn2Z97cgw7OJFH81jO4mwu5Dd5LW/gj3kfH+RjkuULfJFv sFt1kkwkqCT1BzVJIlKq5qtNap/6Rp1X9eq6apDYGJKjYMNuhBoDjVxjgXHN 7CpxmmLmmx+IHLb4WPIt1ZbdllOWW1aLtas1yZpq/di6y6qlUqqxUqr0Nz9h 3Fbqxi8LSkVHeA+9S6d5l3GXfSmD5ihwlBEpHE/BTS5XoRSrSqij1PHbeIGV xNCXN3IiQjxHjZUq7iM8TDPPGW1pC8ALKU/6zRnhT7LYLMZBhOp6tMY7eipq KVAqKluvk1qYR8lUJzWUy0X8vfFU+QlDr6tLwpubUvt9qdJyChO5u7BtCD5A AAZIPq+ilGzcAxOwTi2WTAejPSKMaab0cHqodmEbV3I579FfMvCD9L0JRiLB uCZ9PwJBdAc7BdtJPsflVGtYaBONFgydlJfw4zhCeCOy1SwyeB7/ZNTjEg/g CSqSHhq9lbyGkqcFyKA75IXtVMkNFIzVNE+8v0F3+AaK8RNpblLLOY9O0HEK 4O40XPWCm6/TZEETgntmIHlxjNSRRXh1k7epHNqAc+ZhdcVIUXth0BcUw0+V jR2Uovrruwi1NKiW7vM6Hg7WeqXh0/SjRKcIl/RRFWU4jZGNtY1nOJBWqgIz XT90l5kLOBY55m3rEJRyvHSIM/IWVSOCfuQOEvcgWRkokQo0VjQ28hh05vv0 CCW0XKojRDxJk85RjVzaKramvE1D5RV4wlXSNVPULOkze3FU2D5Xers/Z8k7 k0djwfJKGJ73YL2w4YHxKkrl30MqPpfXtEq058yP4oalxQ2NHTJ40MAB/WOe 79snunevnj2iIrtHdOsaHhYaYu8SbAt6rnOnjh3atwsMaNvG/9nWfq18W7bw 8X7Gy2oxDcWEyAT7iEybKyzTZYTZk5Kimud2pyw4f7OQ6bLJ0ojf27hsmR4z 2+8t48Qy5/8s4361jPufJfnZBmNwVKQtwW5znXbYbftpwph00d922DNsrrse PcWjr/DoLUUPDpYNtoR2eQ6bizJtCa4Rs/OWJGQ65LgaH+94e3y2d1Qkarx9 RPURzRVoL6yhwFjyKByYMLCG4dVSQLk62B0JrvZ2RzMClwpNcE5xpY5JT3B0 DA7OiIp0UXyWfbIL9uGuVt09Joj3XOOyxLusnmtsrzZ7gwpbTWTdkqX7/f5D e9UARXVd4fPefW93Y1Cx/oM/SzZgI1KkVEWidf2BqiQxKpCFErsgWiMmmNjG aKuhNVZn/TeaatSMSU3agaSzECcuphLUCNoWrabEGVOddrSTWItaR21MCbff ufveuotpYzpTho9z7zn33Hvufd8950Jl/tS4ck95aYkvKEqLeI0eqVh3UrDv 0gv9bncx+dcm+lZFWxNFIKffE27uBgKr3MHd033R1iT+W1SEOeCrJ+f6A7lY ei0fYr90BMLh81bCm5rjyWGNf747eI9ngmdeYL4f3yMhEKQZS5LqEhK89fLP lJDjDuT7PEnBcYmeotJJA2p7UWDGkrf7e939Yy1pw2rje4RPs7Zbd6sR1zW6 MSdiUy01nFt5MyLHqXFEnilgQdA9241IfB5sJIv/zMmiwOwsDMNPkQavYDk+ wxPBeyb6A/HZrGf/oJkc73EHbhA+u6ft77GaUkvjSI6/QdxkckT4BbvdDqam BocOZV44J+JDIsZvq/6ItGHPhvTLnoXxbggcHz3qg1tRdjrOPCmJv+qakJfK 0AlWTfeF+24qS6wjb3pqUVD3s6XRtvQuYEuVbYm4+z2g717i/wJ6B10pkd/u 8X165szLDmp9/ot5TtieN9OTN73Y584J+K2zzcuP6YXtWRGb1Qr2nOgTibrV 0hOFsoKJJZHB3PHFBY1k/DoUk8tDTheoqDSaOzcY758c/lvUJSnpLp1C8ip7 KXHbzQozmJ0a238wph8TXlxAIGAjRc/LLw4EusTYcpF2AoFcjzs34A+UhmRV mccd7wnU440XDCzM8dtfNCT3r0kM5q4twibmadlgq04Taj3a6um1Xm31zGJf fTxetqvzfXW6pk/0TyiqvR82X72byKu0ekTLPTf3KE8D0+t0lzIl1nuJqpTV UArVnx3SSOlctk6j2SE9rItXOvykqecD/ttL6sihx1wV7WZ7h+sm/pdyRr8v xJuO0doAbuk2qullUaKlGEQvAoWOatroGE1l2jtaV9jW6tUyySDtPnMuNegk L0E3En45+mj5LsYvBZYBbmAS4AWmAD8BPgEeAR6Ez1LgfszxEnCUJfRNzhIq Nc7LncBJs5ACZrM8jPYp4LjZTOvR/y3WbxTr5H6zUB4zFskGR7U8gHYz7Esx 7gQkz3ES83UzFtEG9M8Y5zXCPm5Bvxi6EPzaxUDqqo+mM2KgzBR+yjJIXtGr tXnwGw6MFOtYR0Mgvfrojh2wH0P/Afj40N8NfS+0p2F+D48DxmDMIMg0zD0U 87bBns96jB2G/XgQdwgoga1ZZNI6PZPaRKb8vpFPvax9v8L75j3be1Lxh2O6 A5iX5/ZGIxzfbdyO7UtxFjH9EfIZIAN7addb6C0jnRYY1LHP0YvWMJyn8d2r te1AnFFO/Z0D5RbEONncSyPQZ8wCiuF/zdgpT4nr5IUt1fESbYZ+sp4Bjo2g Ov1HdMGRTN/FftOwnsk8wbltVFwoV+emQw4y/irfR5v7yc6BWhfrnHby2TjX URr8R2Kty4ijzVikBYAfIrY6YBPHg/XTceZ+fPd9WmFHDebpAe79APgG9rUs DHkeHN4E3XiMG+Qiet5a51SUPMXci4b1fWycsaHOvhovympqAm4ilhTgILAM fh9BpkP/COQMcLEJ4zOZr+DF1TA35VvMDfD9D9CP4tjVHsBv5lj43mhL9bn0 C6ASeMFB9KqFn2KMui/MWY7TmruNucWcsaXFjSN6Dd7xvE/mlSXV3TtHQ1QM 2DtzKyJx75j7Sl7EnWa5laYwZ3nOiGxW+WAM30d825SItOLh+4m8cVbJi1Ro cX2MLa2zOByR6+Q7sC1z9KVdRia4H8IdGEJ9xDXkoLM4wydpKt9jYyu9rK+k Xs5LlI5vOQ1zbe8ktzGcrdp8zNeI82wyWmg75DajVb/PaNVMs0ZeNNq0RrNG X87tO2Vn2GNZMqJtX1X/v0D/0KzB/xQ18m9mq5RGK23GXsl5SRsOuG0JfR1Q BQx1pWrbXBVayFlA8eDNdaDS8FK26QXnGmmc0Vvl72ToCxyE89coz3iFFmmN WldRoKU4amiBKMAdxVr6h7SCwfNDLozwKMy1bFvewSVL2nztJI9yzue8a0t1 95BXLemL6WfTt7g2cH7m+sA5mhHmq3wtwsvNqCEf3eZnLE/lrSh+vog5Mzrz MkqeY8m1hfM71xasPwvr78Jcr/P+VX5EjuMcyXkOd/5he3xnGfGv1g4gP+xT ebiFiu17DfA9/wS2h6w8gjxMe1U+rKTHHYVUJEbRwyofTaZZ5glyqxpk1VSj Tv5S5TLcJ7uWqjraKjdE6uhAeS2cz+QRlW8Oynq+n6puon6au7We5jFKVHll Ef1G3UO+g59SNtYqEG8i57bLxdBliLHIvdCLy1SsbKdpsFgMP0Nu4ZoonqRk VR9Py0oxjsYp35XSa3yKuv0GaoU1nxoDaW4FJ/EWcPjpoMoFxcwR6mbnY/72 zgr5rnOWPOQopybzUeynjP6CvbSoMwjJJnUO7NtXpvFZOPPlRnFTdmDM7xXY p0LWq/PAGUWfharN/KbAnI5K2qrOg31W0Mcun7zAMOfRs47PsA7WMseilkyQ DeYEuUnlVgdq3BLsczBqWxyNZd47n5ZSDJbH7TosGihZLJOvm4lyD87uAUs/ hPM+v0n4vcFvCPPXXPtlSPmcxDutC3kZxhDwsoLmij3AKupu7sFbJCRfUG+F Vvq6MGS1WIb3Tfh9wm+EAnVfKuUbZh0N5TumYsAafPfxPQ4jlxYil4x3rpG/ MnT6Jjg3Auc9DZgD5Fj9QxYOh6GdCI/RdNjz9X9SG9olaH9PbxA/1htoFL8D xQeyVTwvj+ib5HLxGB0Qx+VJfQC9p7sQx/vyM/EBFWlXqElU0UExBe+mhdQs jsoL4rA8p99LU/UxcpeopQqxQraIZ2iaeArzbaQj4ufyqlgvN4it4OgNOiR+ J1caWfSecS/mOkdN2s9oh/4P2uF4iOKx3ng1fxVtwPx9FFaAJ/CLhorVxp0x l+nJFGfFWxwTL8dqx2nHaMe3HrXMio/3zfMqP4wxJtNUIvknIDksO6bjmxRz Xlc5Kwe5x4Vc9DiNgT2B6PNrwF60N2HsTeAC2s8BAbRXA/8CXgOewrjrmGYE MBj97xgJ9JyVZyoxPhW6BQD8Pj+F/iC0s9BuAfoTtX8M+TQwDu1bAPTtpoUC oDt8ME7yWhmW7grG7wTOoP0q5Mywrv1ttLtacj+wBVgODFfv107vkv+D/MJ6 dLeyUx3K6FxTvpLMuSsZU4Ps7/9l0qotJXdI6xzsfUTF859qXowEfxqiwbmV 8xvnVc5tnE//zXrVBzdxXPHdPUkn2T5bkm0s26CVJd/5Q2Bbd8J2jI1OsmVa VD5NMhZfpm1CQkkbGuOkGSDCSZgJnhJmmqYftIU203ZcTPH5hPH5I8BMZ9rp HwydTv5oZzKFIZRm2iGknZRxG2z17cqFNs20//RO7/129/3ee7t7q907tp88 QNhT+b7GzhP4AM1j7jrbS9l+xvZStp/ZX+bnfZ39JOwRJ1D1P/s1g7bBRj+b TSZV3QIMN3E06xvUaW6oUtSj8VJhFp0BGQe5BsIyzcLhM4uIMEvGUR2iQJ42 l1VzL8tMJJYKre35QrZxlXo9XgCvmHdBiGAJ06g+75Wtb1I/iBdCA4awUwiD CPCfpMJFYdjsoCXxCiGL3IKJAiCbQQ6A3ABxQGey6DrIXZAciA15hVHz5nF6 STiD9+NTEORb6HUn1otoxpaxkwzJCGRglhgI567gCrNyr2rlrmSfqNoL3TyK B1nDW8IruILlhyc4bkY03QJo4pCFaeGo1OWxRs7j8gBHM5RnV2rfn4NpMUBu kPFJQRdqGiDRX7IdSpc6J7zEbtThRJNUl3dqfgvGufNxILyflZu0Mqiy57Dv kjAMUzLCdTFra1bdzLZlh1rEcOMWNchw3Qa1mIXo1QoAdJeyTvXK3f2cZKoa 8zEbNS+jtnWp3lkI2IW03Id6udyl+eTVO1S3rERVh9yoFUF+K7eo18qrtKKO Zk39tnxWnpF/KdvscitY1Xa1sqOho71D8MkVEPBCvdwu2+aEYXYj2Yl0Ny2h rPP0K5QU0hYNRvXnLOXDPspuRIFUTtsGxHGRDDjGHSR4Dviuc82Q+B294BwN qsFQeCsbUsZs0DgE2aRkTH8Aov1hyh/WVD9MBltYmYuf2aSqykotXpB7X8gg +PTLzQOGAf8ILh1aADyzsV7Vz7C5Q/WySE0ar8Ki5PEVzcaqn14fZQgTyaFG 8wHoRSu0oNKiqkFFa4f883qBAsldSnWNOnIJUmEhw26kwMCaaBt1NDtiDuEM GSeXyTViOyOMC5eFa4LtGWCdFAQqNAsxYZMwINhL4qvJHXi4A6DPgFwHEVAz 6BjIM7w2DmsIo02gISIiYB0HKyvF2CrmloGPWdj/AwumYJI7cBtwQxS9qg2j FqxjgjFyYYKcqKICthivx6nHC8khEkJRJOEurtu4rtarotLJqPRKVHoqKqWj 0rao9KmotDIq1UeluJusRgEkkWqm8X2uf8b1Zq5X6lUB6YOAdCkgfT0gvRCQ vhCQPhuQBgJST0CKS3gtbkcS6uK6hesVTOOFCyUbSpDrMl5AG5AkTMDUliNK yk0lSi1SZioxAKfpn6XxSuKAV0IMVjvIGIhtCQVEbawdowjbBfBHKIQfAzxv Ko3Uwj/NwxiLGS/Ho0hhXvhHyI9lwB+iMV5/E0U4/mAJv2eGnga37zKIu/B3 4BsDkkACjSd5zlSawPy0GXmWxj14P+RkzU+hWk5LwhJhGFtyC5n+03QO1yA/ YVV0QXmBLoC/bNK/a5YTm/RvtRYZM+l7ioWh9nuwnTLprQjU9EL6buQWvRk5 Tn+tWARfpL9SrtKrsmUD4lSEE88rPMg5PzQC/3RkN/2mcpq+no89UstJL8Nk juml9CUY0lDoFj0AYR4PPUt350PtCvEePHqb1/qgPwCbNN64UWGBS+m6yJO0 Vxmj3ZGrdG1oN+2g0H6RPlJ7i7aFeK6mEHdv9MPgoCcNoTFaFxmjj7bN4Z8j EY+AhPUmMSN+Wdwn7hVToi62i63iKjEo1ohlTq/T7Sx2FjkLnE6nw2lzwsus s8zK3dDhtQqjMoebgcPGtI2X3YRpUOxIIdhJ4MXPKBVSJNWXMNrCKUvMbTXa wynDtXlH/wTGr6VxyrjyeZT6XMC41xeycMGW7YY9lMCGN4VS2xI+IBvkVQuj bf0WzjGPY9WGt7sfziysHztRzTB97EQ6jZY9F/PFvGs9j/T2fILas6TDDy9f +N8v3wrjG6m+fuPsirShskJuRTplrOsL7OyfJkfIoWTPNDnMIN0/jXvJkeRW 1o57e9IPaLCgDgMNFvXhPC2D/IwGqzvDabvzNAreQJMZMNooopxG8SijwTJj vIkxmuyZoJRzbAfQGOeM2Q7kOTLn3P4Xjt2NbnPObbubp6vglNpaoERqGWUi WAuEidogN295aA7lzUfy5iPc/KWHZi1vPps3nwVz+P90PZH4X4zkvr4ETm3u n3CiRLp7Zx6XuQ+s5evAM9l1tHoGLxd+iwrDaaMglDAKQwkUi/nC7k7cvMtR ZDigTQRh9DU1vherZ2wIppzRi6BZWjKtiq+KMxMsZ2YqhuaSJZPvxTU1kGR0 yeSGZg8kgXXc1Afrcn/SaNwDEOpJI19yXw/8lmAQrqGhocHBg0PsAgelL2V0 bdneP6EoSaNyT086nPTt6zn4X8aPUkYjOMWYkygmDR2cBgfD3C8cHsoXIDYr fvw6mG/jVBQefNCOWdxBFiWMYUqt3O+y/uX81J0Maz4lrE3DV93whFdj5DQe PMi8IVY+wmA+KvuHsy84uOG8FFHsAsHzDtEie/VSZLfNC6hAtM1jVOl02Ofh zROvz7refAeey73Ohc6N7g87Nyx0ohiU3fdBRVpqPDUeGRRsJuh+QLhyX7ej j1DAdgU2k68urhdG7K8hN+qcEp0Yl7o8XgsPZ0vQj7GFk1l7wRqXhR+bLOm2 V3oS08SNfGFIseHOwi33wh33bVgQkRa8C4tKnbLa3ebFFQ7RQcrL8HDw+Wj9 G1P4lG966Gszi9vd755/dQQncrgd14eOn317YfTeHLyz1iyuJ5Tn755yQX6P q9TzCfn1gpLuEju1E3sVdO+9ic2sF/d2/Uc32pZVLCt3iwTXtba1eldHcWPw ea3hDWvxSd4N+6HSm9CNxbcWF3+x+Bs68pO3SRq6Af3402IOu9EFVIaa9SJU VnY3VowzxbjYM4MPIhuZnEJrCyvLv/jXf1BdrcFNXFf43n3qZWm1eq8e1u7q hdeWhC1blq2gBcI0YIxTBhLAEWlTwCakIa6NPRMC5VGCB0gZd4aUaWkJkJK2 zgRiYxAGYjp1M007wySdhvxryuDySNEwnRh3Wiq5Z2VI07naxz0j7b36vnO+ 8+3cv783VUSJfE+R+2h+koWVGlPRiAZAqqmh3umwM6yjLRFiqCTJtsbm5Q7t uyGlYmHeokvqrU5lwaL6tefrAfsls3dhzVFkRIGLwPTQCGMEMvvG9B7T44XA OJXmJ9OVh8qStsCvldZsTU1r62irdoYDsgW9OnuH/JLuRjwKoUPqikZna/Ap Zhm7NNBRvTy4yrUuuMG5wfVy4OXqLcF+S6+zz7Wzentwj3Of643gEeeQ6+fB U463nSdcw4EzwYvEOceI85zrSmAiGLL9C9G+Au5SBUOVZ3hXFa7yhKXhXWD+ Pifvk7MkTQqRcezHTvSYD9h0Xtt1MVesEKLtnGAhJyq7T/PpJpfEECxkiLOh Pt1k462pCDG568ye/vVd2Y49Z9Z0vbV5b8vA91va1qlPKL0r962ju6/f/rC8 4ccDjYHrd/52G5sPPZfqLP/1ZvmzT7q7Yi9hGg9j49bNgOcOAPFZQMGL/qAK rICfIbqIfqKPvFJFQ3/lXNhloXQWSKfmUR2LmYVGcGcsEvApaK9meHnzwFzA JSgyzoJJpItxFsstaMdgLz3jeBoJZJWq93oRrWNNCF8iY5C1AmEcrbZgS4GM qkYO+yCGXdhnGCdi+CagAmKpKFmFu4qVmfxU9oFWmLksN13cb44rO7hJxcq7 Mm7EPSgq/8EPEFfE3NW5swZfHvVgzABWLlZMN1WGrZJuEVlio2Hy2fIHvob1 hlLJvFKocYjSHQdBRkQhXYW/SXc/PP6d2nCUDYcJIx+ID5DhpUa7TY6ZQusB qyBgdRWw8qMxVTyse914TPem4V3dsGlCN266prvmNtwnv6D+7rzvoowm/xXA yAP4DCAfblYdftLlppw0kGgjeYZ0UU4KGwsEoZr0wxba474FFWUyTRAuELJ/ ogBiwBL6CWKEF6rH8Qy+P5ct7VNFbmYK8OBK2VxpCnDAGhjwiRfvIa6EuY/e Z4jFq9aoegtppKpJL0Wh/Nr5SZTHeVFsRLbHQDTNlZ2WZlisb0o3EL8t5Qnq dPuuTW90yg2T39t9tjq5e7J8Ea9a+aIrFsaTGA/s7d67n9t9+P2da9q2Df2l /PmTGc1cLYVK+pRejiT0G3UrI/EZCg6RVYJJNht8ml7JPM1+m36BeYHtoXqY XnYPtYf5ATtEDTFvUaeYMepi0LmTwjqf2/cke5J5wNCi20kGeEyEdG6vKDlI ivq3hOyShCSKRFSAp0hJMhMkpBnlBaN9wVzFe+TAsO4yoYda/n2lsrgZKCsA qr2oiTqfSfBzSGkpREMOISufqYQyGS2sJU4PykMHEsFsaoJoZyoF+EigXBBq qNewi0QJDv8uXt7cdnLdwa4jq/v6N7bGUpHGhTHB4e/5YOOxPfTyX7wjtG37 08EbR2uztYF4qKFRNOpvnNtx9ikzImaPIUR9i94CaIXxkLqbdCAn5SZFnWSQ mRBrknFCzskd8vPyVnmn/EP5J/Il+XZwJmikRVqmQ0mxQUqGlviXSKul7/o3 SJtC/fZt0i+lPzs+FT+Tr4dsESlpTzrm+6l5qNab8CX8VFT1tKQiqq0lZQvL vD0ky5D1UtDAG/0GvygWCK+6TBIDfr8e6/x6n8Pr98kOhyxKdlGUZF528IG5 gg6F7WHZZtNLiPT7fAaDXkdKVomQkCw67CGKjyQd2FGYvTpqbEk5CuSiC/JO SfV4U9KjmFQgF4whLYIeRVABL1KrsMq1pCw4gTswiQvkirHIQVlCwXFyHdlZ kYPpvDKtKDOKMn1LyWt0AW15rQhg5DRyi3CjMasDZuHqVii4cX9dGeCsu/fV jDVzWZbmslk2C70eDEgeZEMTjh5MgnS4nM4GEA9NbGGkRZb5Sk+a0rBHkaru 0llsC9uNpS+MroXz/JzRwJVfO5Bwp7LG8lbjsp5XyJpT5QG8mt7y8GiHJ+bw +8Jhn622uvfdS7m0OxgnwmEyf5RaUR4t3UXk7CeQExehgkRUi9L4p2o/C/JA 8LXJXDiX7Eh2pl5s2N7wSuZQ8ojhZ7HjybcN780bTo5SY4bL4Ymk7ZnaSYqQ 0nV1tTbB7rdhL/Lj2rq6gOC1C4JX3xhKxG01cZyOS5CK8YR0GDiTbJiw6aR0 bZ3QHPMKnF4frasHyzWaM2HTOF6EomC/GNXKpxiNK84NV+way9ReqbvpLZBL VDMvaEyeFa4KHwukAF8aszYmBSwUcO/5Zr3gEpoN47gXOx4LutbllLyyWHvn EOCRPmtO+9VoxKVdd43G3JX5+TqYq9aMMuf22qdKU6B7itJ+d7rnrgeIT2hP g96glS5y53IQyYOdqQyI7acrPeL/yGe5Cs35trMxMK/bwLyOpDzhwuzt5ua1 4GgVCC6A4FgoJsekWDNEcR72qZqSkiNTL4mZKByV7YBbEuudFbvifKwR/+sy FWm1PRIKEFn8tduEGU+9OvH8rya293Wf6l35XtlStcIXs7pjX1an262XF/o/ /uNrg6Hm8smXnjj2jyOng3E6Gl4+uHzblbr40c6NhU1ua5iosvoig2Rjd01Y KV0jxga7ek0PO82XT2w/QGo6fGD2Bn0ClCWKDquhELfYuJh7juky9hn6jQOB 17k3uXfQeXTOVHWa/5AnGAsmCrhd1etCP9I1RIOko0DYLlg3uPVIq2IyMEIM gptcNBId1Kr1nD2Dps2QICrvU7/RlvKp9sxxH/ZtjG3c4Z7jFigqKcXp4hSU Zmkqly3e46a0xtMDqJFyNE4CDIBXxcVAv2Eo+b98l3lwE9cdx9/b1bHSSivt oZUs68laSbtayZbkQ7YRGHvTcBhiUhNICknsxNyFcnY4XHAwMeGoB5ikR6aE TCABGgqpJ/iAEI7SoUc6TNOD/sF0hsKUtulkXNopnXYmWPS9lQwOzVSa0W+P N7Oj/b7v9/f5ReM4XYU4iVdyyXpkadxijbeueXxw18mu9j+f7b/ekV1TuPvh 8ftg19/gW79dvLUhEIinrKsKs9Y0dU5PLOq5ff7yTz7dtmPgWP+9V2/Ao3/P SlIWk+kv8SSwEPspC1uHfVEP31yD/4LRh3PQyvm417Xvaxcsw/wZzQ45DkDO 4wH2Krf7BQbZZeRHcmJFNtulo4StlaK6rMjm80jIZ1GhGo4jFXg8YRSWEApn MyqVcXOcT6VkH4Oq9TDy2k4Au2GnPrb/wU7ZE68BrVoztHZtnWbVgjXgmucc DUEY28cleFAFyiK6F0FELFPtwE+uduLD9+9NcMx60y8I+wP7BJV8QqrBYqMg I5BH/2OW9XNuY9C+XfQJYSdskSbsjvHeV/JGR7GY4PAvWCwTruzG+dhzBVuH OAc3RtpUjY6ZGzpGP0pYpDXGGpXi/YQWow4ePr1lc4u2T/fMXTu0KdK4yjX2 ifvJoC6Wq3dQsK7NZQkt0dhZeb3fahn7y+zugtCUmPp4YfnquKoTAHPxKNlL 1yyeFFQFtXCiWf/SHK8Ta3sRZ2UWa6tDh1HnEAM6JTwtH9D6E/36UXAGjJTb EzpkKASFgIgE3uFFfKCsLMw4JIZxxCL6WWgzlEgGCjwFGT0RA5YUk9QdjBec ALpXj+i0fiVVdgHr5KCn4+mAweIkHYyfSZriXHkojikNU5SGIVGGpcG1l0QY 0xvIj4syWtSklFu4feHJq8k7OsqbNMJ9QavCv2RMMlNoOG7wUnPZ2fufnObz uL3eGPSIzTKup3EtPgKT3eczKIF7VhR7zV7sZnXjnayOPnlP5NrLU1JF7E64 sY13uqgk0/FkUEh+Wl7ON/UdmN+cC80MmvyLMlvo/LJqLQVVNZ4s33fvd8/H A7InXt4Q3pwm89/P7t+yBbASSbjI2GgX/YIuNQiTtRlgujDTt4Lqpo4G2Pni psBQgO6DkBVciEVxzBlJVUdJJ+VAzpCMYQNAGJZ8kgQpyUdBGBMFSYRAFNR4 PIYzFudskmWdTkChECOJDllM6YLok70wK2KgMCTJaAy1SEZtWYshrZN6pcOS RTpLpwcd4HtxrJjBymSBTBbg1/aj02KelMFkOmdWFDerURasb5G/LG+XD8gD slV+KeUQMfWJcmqC7Fh3k0bMDxy9jecTXAtEWlNc021NRTAZ13Y3g3nkwYH1 i9We+FsE+CEYcXA5UFli9w4IJ2irkSC1wxh8xIYQ42kj9QR854+h3EyXm4VD rmlK1h9RCpfjhan/KK953ll4BuuflFAcuhMLO1lr22fX6eCiBpWoDD0+Jbvx s7ctW+4NvlinmXOQS0BVL9EDTWlaBZheP8bu+w/WPIT9lzPKbJRMzVT2qN9W 3lCP2Y9HRuzDitPmhCnyRl/AecsEksoUZYb1K/pW9R3qpDLiPqdcVFk56s3z UY+3GelOJ9J1VpCxWYE/hADPYsfqLBuW/Vh7v5NBFVoGMHUVFTygBJ5xopic 1P2yN3aO3g4s0D+Y0q+xJFf9lDgk9MpQPmtaFiN70bI7JuSp6Vm56Fm55Flc e89gz8o4Tcm1YSEvj4fqw1Sd89dxA2PuKIYqIQ48RTySq58jD45AJleCzEqw vgMPWwQccPNLPBCvtmTchMkO48RgUPJvfrWzcO/1zle/pjUsc479iV05r/qm nu/66frpqweXbntpWpe1bfjl5T/ujhb270xFUjZVnXWMtvRnYxnr2Hvo2aGu pZt4ohrhy7exahqogd80ehjZkWhKtYK21OzKZ8FKsBVsruhOf9d2MP2D1Af+ S6lLGf64bchO2UJyaG+aphM1NRaX6EYu1uJEbFAqQ0EtqiKtxmIJi5IkihIe KMIASjgVFJjMZoLJDJ4XgpTmcrEsYKIKHtWqxFpdEr1VRLUwefHpXJgIEAoX qxjAFfpH1tXBupprFiKoRInDoiGwLeLZomKkGg4smWh4yppFc4oQSDX1Ex8L 5Mm1ESEvYv3M2/gpYukp5i38lF4RimSH1GKDi7WPhnrJ3CWLF7XvwPxZ+VB/ EuDF2aO0B4QHQW4OH//X47tJVy15WqFtiWJCP9JJ7Y3FXWIXsQMmYiQ973pb +0aMKIscY/9kZweTYiQ2Gnhihgueu3Hlo4Gd1S+uYscWGLWnft7TE6mivgW9 hWXtjamAwOCBA3fU7Ga67ql0xoDqu3v7rqPC119bYFOp3zsu7V+7iSEMyd2/ ZXkGM+QU+LTxyitVO7JUp7uT6/SsdK/l1nrWenvc27ntnq3e3nRv5pD7Te6Q x6uDlDuXnp9erixJb2O2chsye5ldqV3pN1wHuYPe79S9C95zDXADnlPeY5kT 2Q/gRdd57pJ3MDOSvZsJy5m5bLtrnvu59PyszSb5pdmuVm62d2fG5km7Mxa7 jjCKGk59iS92R1F8NPUhzAAA8vgib6/L5YDDWyk4T0Wqq6uparx0OLYnGtkT xeA6XKHcVCilmPikDOJxhVSjPJrIZZUWpVehleDUylOCkakXrmLcnWIS7/Bb 4CagCPSewQuB4a8H52ADaIIN7xdRFzsZN3Xv6N1K0tnJhimdd5CtQPYGRt9R UvABGVeJ3BugOV/6xboSAdfnEhr51ucaCACT70TCipJlwJwxYlECVFE7ty5q H9jXt6cie3VxKHPt+KTaiqcm2zgepULaiqjlcN+Kl+fBygWrr3Y3rdiQCE5R KuC/Z1XvPXXkq9Mmzfv1kpq5C/f/grVF/RQdrik0N6ndB7/RPmN74daR55Zf XilXetpxJwZ4hviITKKwwzCAAzidPCMx5TbF5uMNLyVM4qf6ppTlI3ml1dvG 9/DbxP38Ad+b0iHfBR+3tGJJhDrE/5A/z9ORGIyRlx6J5kg9jerN02C5eTqY mWxWo+q/dFd7bBP3Hf/97s4++85nnx/nZ2zHr/MlDnEePgeTh4+EVAkQwitQ SDMYpSlk0BLaUjEKC2tRRKjoBs1KWUVKxbpNrCokhZl2tLz6B39Mq6ZqFVW1 h5RJoZPFtNJqW5tk39/Z2dZKtXz3vdfP9/Pv+/08vtWq2cYFzf7KQNBvwmzQ 5LN7gz6bKOp8ItoRtotiLFLpikQqC/P7NIeIIpV+n89sNlERZE7bsb1AjU2K hyJv023wB9ovIQ0IgqRPE0GAbMiH6tAIYpAvai7Qay7e8C7gHND9xX3SrZQV OzXKfEOyvxXFJY3WzA/bf2h/zT5pZ9DAJp3jSTHAR5eZMHg0WKqCHgjHXXTp XSTBvqGk5uCYWaNu1DCAn0gAuUAuYdy0x9TRFecoD79xqZPjV1P2DW5bbd6C T3H1wabd+2aZMLNzQ2hRCwh3tMr96FcfUb9/qjbsCShMIsHY/ENnv/wH1HHd /Ax9nT4K3K/iO5rXXGmKqPg5/Fz1OD4VOFl9qvZXjZdTfB3MUvNYXPlz7nP1 VLZ6eSVlifpUizWqZKzkXg4O8p5ezxYP3VqHLRqcWjSfesV9R56RaUwxDAKu SsiyZBHcyXSDnHAz9VJNY1Au0OOaEyXj0ShiFcQwYUl2SZKcLsx/MhVy5NMF ulYT/H6Rl7KKLInCmOUq7kAMRSMJtIv+tfyGpMFzEsmoNZbIIEmU6iT6R6RN nR+ZXKdKV6lxVEMfBrMeJKWVyQTJsx45mQmOrFMngveCVLAhK3mkLNdws0T1 ZaYvd1fXplYrpKu6NgUmUY/e8rkUK0Vb+TpMRI/O0vlFT25BKzb13L2fGhhO pe4Xxdkviv/tvsRiakEdUlCXhBWmsT0HTGHPwRfBARZvj5L7JjCN4q1bxPgj qKO9pJ4G0IoL1etWXFiyZvOD7yF1/kOUgU2Zn0HJ+ZnF8IFySuEBTLMlq0+c vkfnDDXT1ASlpB85moBk3J4mNsoaKZ1/9Gqjr99005zJIkjJpdHOE9BOuKVn H+td2T303sknBlvXSPH3ta7BiWU1u0fOt9NHZzf3C2bRAi1Vv3fH7lRV/eoV 55fV7x+awN8dWq8t31vR0jc3Obqs9+wf/tK3EnKHsqT2DMeRB8WxQRP7A9jE Yda8Bm00vFPByGVhJlED/52xG8D+x71e5Om0fqq46zw9XgFH/NiKkILgqjcs WF2CYI3EQ7lIkmGFaX+c54WEYhXEUIE+rNlYyPcL7O9YKsxidpv3N1BEHhxH Aryoui4jECJSVD3IeiCvJ1Hj4fXXhA+Evwu0UMDNlxKCR0hwBSp8sVwwJaJP paaLswMDqbsL6S0W86X8mkr5BXdIMurIfV5MfYU/HyX+j+g9HiaphJTSWZIJ yUURB4h1FQBqV2lC/o4S8bNU7/tbX1j12POFuU9HX5rAdTHRs0hKVW1f+eDV Y/1tA5Oy4fhsz/blJw6enbs+Ocx49kt+wcHK//5n02Hc8MpDO8aPgJK3wNrv AtwrWNAeABWz5hWyq0U1OJWsVdpQG15iaEu2Kc9TxyJHk+epc/FL4am4GAbf 5md8Bn8yrBiPyPj7ybHk6xHabdBN/aRd1YNbD4BHdUJ5U6EUyJDgsxcw81Yw zrEJ0qYGxDzET7RoKJdI0jy67drjSwqQoLSQF3qFLQJjE8ICJfiroyR3ISPc yht7jVuMjxuZEeOrxgvGa8YPjAajryq1QRdeQFfP3VXiHInF4jSsfioFGcCw 4Dnx9kCJgIcJYiKAmFpAzDtAwjNgN2cITkB+IYeJMjgccT0PZYC0UaVMGNmy PDfRgR0f7js+cR5Hju3eJVdUhatsac4ZVLddW7b2ye09L33n44NPvTr6Mlau 9Le31USVkLNykYuXrK6xH5w+Pfh0zyNQ/wBRZj3Ufxr81A3tDBvCrqjPlueB ODnYeC3bkuHIjvdm1AyvNTTCaYOaCXB+fie3k/8T90femJd6pS1SXyPzv2HR JZms2h3qbu6rHVV/gn/qOi29ji7jAncp+FZmSrWuR1jG+DMVW7zwKEee1we1 agm1VYvF4aBCdbmkWFyWnbs4zPHpObmAP9NkpbYu3RNzNebq5MCSbMxFOwn2 aJSmw04ZnL7cGK9kc4X5jydDuRxhbt7rtfLOFkV2iqhA01Pym06eVAaXhXk2 nMnwYxxxUlmYeceZDLjtDo2jp9PjyCk6KWeJwJ1vA4FnoQasAaiBAEwyoAXj mUAJriRodmD1ewEc8LWAaW/hGn7+dVQC9Q5Pz4JNh4oQ73+NfPPF/4cnKRUH IV+C0jJIoXR0nJp0oJbYfBhEHDg4tRfvXSB4kG1sLHPnt1OsU9fxMqgJnJE+ BDHr535RYTcLjujqaNdJLVoTSv746bUrVg6/+8qBR7Or5G08a7FJEY8aWJ47 NHevvXYHwPP4l9u3hjiH4N0qbX+mria39Zk/b2gefXIcrx3qq2nEDyXcil+y 2tnE7BPaqrmt767oxTcI72qA/WHAvh8l0JyWtYl8wit6EwwyiSbKsc60xkwp 5urEYnNzqIvtNnWbu7h+00axL3GSeY35mXOSuZwQk2TZW2XVHK2w501R6MJM ZpPZEEAms1SJxgKaiWsTAsFAOkAHAnws7mANSZ6vXGKTwhIl+ZOomyKw9lgh pdYRZXXeqsEPTVix1SenbnoXFLjnX9PERPcUAc35IjRUA6liOUvITmBdSglw p67VZiAWmIqZEIydy5vKkSXRbGkj55MQS4pMjJZzAc+eb8CeNSYhVWWvfZ89 tLnryLNS8aMTLxaw++TQYPvGX+659eLAgQNq/eBf8f6GyKaDzY8E/1Z4fBwv fmND87qVD7dW+e1VTS93VmfuQOc0NzH3AH0bsN6BB68gGqazeVGeJmvo7Evl jZpnqac9hxhHp6ZUlayv3xeD7gJ2nQD5Ts0Nmxc2q5jpJM5CUMsm0xJhmM5l OKbB78QK+HuaGI8jY+N4a3wREscDcbMN5WenybdFnE21kMVL/zagpSLRZDJM Ux3tTCzOhKmOZDt4r3DSBRsMK43/D99VH9vEeYff987xxb6zfb47+/yR3J2/ 7sMfxDi+BDtpc4SkfIS0hEC6hKSUdYixASq0HWNVp24q0LB1TK1AQqKFqaXS GNA2LDSFqa20aBP7Z0iT9scmrf9YbP2I+Ie1qjTMfne2Sbo/Zunu9b13fn16 f8/z/J5nxaq8vaq9mjykazLbU4XYskDU58TVvgWCtNgibwFhLw/JojzkLf29 yb+7M/eW7i09INxS4x3gZdhay/Vg2+dAQY8vLvoXj7exi/7+B165ZcFcsF/w IoTtNOPwxZXslwYIq18YSCYLUwMJ+zRs8S2zNYlt+06lSIJy6NdMUU5dGy6o B2rby6d6G1+aPbeBgBY9bdtNPMW9emDjpr1Hpqf7s3J3Jp4JsZSHz+3clPA/ dOWKf3ywN9/Xs+nNDZunV6VlLebxRQdK68z4BvLgYH2k/skbn2xfm47qSlcy HOb9lKeN6vn+7uznxIVBce3kDwcnJ0cLqWI6yna1+ymvbh7s+wzY+a37/yJW tYURjQyctjTxQNUM/6BqcjmLM3MWpNRJBkdTOCwaw4kpXS8aowx62r1AnrVi DKUzAcYIyFJCkKREnJayekJixRNhENbfBjxPk8wCXj9HPhlYwKn3jX2cZMVN O3pcrfaVnTFbdkbLA11AsmSlccXz4XJROikRUjQriVLWe/jYN3xyo04WLdkc liwfnOzFwj5nbLrgydHavdpt8LfL7neF9KIvl9iW3tp+aMZZcl60IHSABfvH Nb4iJvmK/XU+UBGtQKVZaqj0iuLx5AoNbkpvbyNMgeLiP2WrfYbRV+39g8D7 AqFKNTU0PfSwUY7+VJHj4eG2cDVr9PUZ2Wr9mXvr1vtZgS2Mi99db67OZCbw xwc6wh20BmxGEVDQz4HN3XjeKjJJoWJavkDZtEKmabGml/YyETrKbEVHgxdY qlccMB8RJ0RXPBNVYwWySVwZa9A7dRmsA0AOq4JLZ0rF7lGEGLfuTdJoAD7/ XgpyYsVRvK4vuu0hbmkkxCnMC0JE1dS0FsTYpelaUEeS7Av6iz7GRReZ7npu AXdYId1ZUohE5LQqpNMqdmHksgldCmpCMKhhDf6Y0TBYNHibbnidnGAYOR/j NnSvdCqmJemcwfpipnRCXsAfXIvU0gtCTf2Q7IJO8grSwULn8I250l8Mu+KA Tnuc6zCdS9Ayo4kqw+n6VdOIlg3R6c+AHaeEo7XavdtfLt0FoXiUvQ3QQAOj tloN9B9va8ADOcYZBF+stBADY8SRjwhqwgaxSxgw5ZzZm1Q72w95yT6/YOuK HZwmHVw5eMW412nEqppK9SYot012KiyGVyYkTSUpMoV7W+AhHq3XDt1YwzGp fIrG896R/d27lYmw0sPzQlAs96X2P1vMivrM7J6zeHNHWyYlltp+8R9j1xub oxCLvKrq0tSRzs0bfvJXXQ+q49HZxxN9+PTh+uuu53ZF+YjiTdnIegzYvwuQ 1YkNa5MHYQ7JWLZi5ja0reOO/LXo8ip0kbboLbSL7hwOTekdxU6ADHiwTlLm QgLHhQI0J+khjl1+cJ/3Or4BS6YthsxwiMMfc7c4goMkY3klDydykvfw5gaj bc900BFdDgoHiYBz5ACCL2fpgnN1NRNuzPKpEMwmYNaODpzFxhv3A9Hmr/wi zPoaT89HKpwVbkl0S6iXane/mPlfOYB6t2o6Y4sBJNiDjr7Q9v947RMGHXgv VWmI/TeMV4v0+EHddtUvRnk/SFhF2rmlz1S7FRxIqLrYBQZqalIICEFjQj5m quVk+mny4jPBiExloBLgzsnL4JJ68EnLgyNMpQCH125BZ3nhYQHEqL0rjOJE vMs1Rm31bJXGlCP4+cKs9Lb2ln6duK7S03ha/wiTU54paUoh97r3er4nHfEc kZ5X3RPZMXOfSm5FtuU3eTgwJrLgInmhZ7gwpZvFnlFov3mMCudSOLXa5UIU xTByXBHicQXlUE9OzheEfL6Qz3kjdLxXV+KFPCuc4EHprzJURlnA6Tkm45jk aTDJxKk582bhd5B2c0DZPMyKlXzjpjNUncFmqjOC/OcbRM47lY7GynfyOB/t jYt5Md7rLTUbwIoOAKGrVrubAyI3FL5Z1GUaO5xtlBec9yHctNkPZP84639h sb3faf7gr0feLUFM64GY9p6SXANltv3aQYe9JNds5/9P7RukTrUuKQ0vHr3x x+nS2s4fhVgPEzQH5Jnx6qpMPvlsOMZ3aJvOT3bJpdPXlFSMkVQ3OVuvYPHd QbP/O/UdG1k/78tO8EcrWkEtPodfHckK0Ujhz7/avvsCceigGE643Gno3f2A mauAGR+KosvW2nbCQ7q95Fv8lcj5+Bw3F/4w4t4RmYwe5X8eOcW/HrnAUT18 Nbqe3xh9vH2C28ZTXoYJpmmKbGsT0y5asC0yR704Ml6mXlxnnqTOUQQVjfnt aQ3ZPEAW3EPWOhOBS0SWZCKkoCKy0HnUhn4fbzjpZgoa/bRRrNFPwYlBeZyT Ta8Ze2sFwrXsgCl7ywhnbzny6rl67djs5V/j+Esv/ebtHRte++rJja98RWw5 Xf/bpXd+9hrWL115ZOap+o5bO/fgN20NU0GOKrALBvraWksAaxJwjOHt5BOe J7xbjYvkpcDFyIWY52jsVOx+jpx1nXERkixjNJz4TDeKaBQTgkLIBE50+bBv AZ+zkkLG7caUjuEhWVYSgqIkFNmrJxS26LE8Wzyk5zphIZkg54ybio3YVWJF scoPlRUrbypWGo4kHGBoFKujs4wUjJRzykfKLeWOcl9xA1tens8pYslRwbsN mMEHHIujTssgtq0KmNjajA3f4EoAH7fb0eqijVLYZD5DNiKfbTphYzX1gatc xqUztQdP/vKdk2PdCTUZKYgJF0G108FAzBzflZWybuXMB0pASITWkGNr6jGc OzykZQb7C5LMu9vb/da3zw6OHxJ/TOzft4pjWA/s/v0l6CD/hN0vovetdAlj MRlnB9ppVyBChwJVrU2nU4EzJNmFB/BjeOd/2a/62CbOM/68dz5/xIkd++I7 n8+xnfgzsWP7iD/icEkubQqEpCRAgEFJE0oDSRZIC1SMausHULpmW4voEJVo tWzdaFVoN76kDKka0lgmWib1j/4zTaq6NXRFWtRuAlZtS9hzd4bAVK20f/Qv n/W75733Xt/Zz+95n+f3oB6YIgalLDkNaRMTqjMJU6hpMq5pN2+tDjms1ARM EwV7ql5CyEVb83uBDwOfBegnAy+g/84HDIFJc3PksGdCmHZriSKTdStpRE1t ZtJ93k25vyudIx3kYXDHK6+pcXgVE8TV/v45jMQZrauTZ2b1c78Wi3F0IB2M qG0Xxh/P6dpO81SQbeRU8Y6OS1KapOfV6zz115YwM3x/a2e1tLf7zf3LHqxx NvDhlrBxx+bu9ZXe040/Gg94bFsd8Wrc1H848HhHukbOPX9QGf5pbXmSdLz0 xJrWWK38/mh20wGGjqYwgtehD7cYngYfMf4aGEz5j9oLdtScP2c+pf5to9eI E3Cd0KHqZnjARtsD1QHqSQwkygc2OzEwJhNUe30i8XirfW5GMBAzcB5BMBjo F2GSIkbWisnczwlVHCdw/pjAVVKddhqbsRs0occC8EuTfcJ2jhAwYWdV7uSU XCFznnuPozitYvst6Bb/HRVbk992Tq3QnKrBOcXnbNOK4xzq6hk1omf0KqvW WEZPwujzOVnN00TVmKDFc0GLYkaWSeVFTYj3o2JSuym6EfupL8q2QWyf8hS/ 4hXHyye8lVahzr26ZuOqpkKiKfDakbLthzYYnp7/rG3u1IDX4QxWbRUO5CP5 eG4cG07f7hfVbKHmzAsYrzI5ouw3NwvNlDMrLZX65FFuj+tx7oTrd/Avl2VN sm/xqIXucvXBBhedA9lF1cTqCtRxCylE2mI9sYHYNdd17lrBVLVYlllLWSTa VGjmeKbRJbORqNiSbGwsVs+4SQYj0LSflatYVnbbrCLbgvVTZivLJiyDtNrP ivKbLGZVVnELGRZlvZ/tYQfYF9ifsAw7RWWUcmwGlSRJhgOHnaJeP1VzGpdr tsql20RGs4oQjGXSoiJOirQotFhEnuXxpWW7f6txiCQuFFK17RGVoLNNewDu PNWe5HStc//V2f7KWW3lDG6km2UW66x8G7OyJqVUJrXOAYEEq4SiDpb1HKXS 2t+vho3b5bYWXJihoba8sBiRRvgQNzUa7ked+Nt5R87vrLdGUzSXv7Mst1L5 PH3hrWiF1VG32tezOt8YTVRUdr1x+aGkklgXcJS56pf7u/qUXDgVezAquGpG T+5s5+hH5048E3Q6/GP89xZHEsHapuWfz195X5G6jpLsuFju8A1yu/LxVDj3 g/m39wdZ/p6Pfv/HbjWSgjc+YbowkuJkXLG6XYJImV0WkapXNVu0vKJ1nWd1 /ZBnsP5DD1PvSokyt0wcEDfWbxfH/CPxX0TPxK3OBtXn6eaMak8ls5qp141f M6d9+k0lzXsznvqLhLihdiI8HY9EbDYweUVRENxWijYwRsYhiHGP129NWdus tBXr2Flmr91BHFN0Xiknl4UJ915PfAIue6ao55UyccIb7gkNhKjQFJ06VX/Z q3VQVW2qPRXPqkaxJ3MZr1KTTXsVb6+X9p6jg5Cgm05+4I4Xq/zs9X4UV3Nz s5WIuX4sVHoE4AZv0za7fr46K+B8asadKnaj1nLiJQkSERP1DPSv10RYMRrP iBgMPDrxlKOASf6Ds46Cp9auhcd6VA5xTNqE1dqpm2lZK3omI4UpgwSpYunL hjmW41EO3/fWcEuZIc8lQ3UFu2/d6J/z4fb5zQlTyB4UGqsbiF92Gg3kKP3c nPPS6ZEU57AEwy5/vKUx07D2+6/OX2mizsx1k+P/3BrgjaF7X5s/tq+WOqZW vsH5JfQB5L+JsMoDRyUiuZuzFsEj1AktwjHqDHXOcyY2tWianja8I7zjqegU 14sjIm2Q0qkUUx33eSSPw5BOJRviMa9orpEYo8lsKbOWm3lDdqJpugpMoYvx qM9eM0XOK3nJoVidGbvD76AcsfLHeFWNHeQneaqXf4r/FU8H+DTO0Xxnc1Pn b/KkLd+TH8jT+Sk6qFQYLktqlpbULC2pvPLhusxBaVL6VKJ7packKiClJUWi pSnKe7qwSGdX61yR3n41neOFJk1moG3ub21Ip5bDdRTAqZ61TG64oCu8ONlB OI5XacprVC0wZQSTUd/KekHl9RSfy9NqEUbZ3FXrqUjIO/IrJavRtjiaDiVa x+Yv/enIoYw/1R6pqjCzZsZktOc7B5NNtqZ7XDkL/Vzz0I/nq5a93L2vN1Dp sNrYxpq6RZ1Kz7vzGz8/jjI7qliYlJkpq13+UCv1+CsdxjDcOoa/Aj5B2h+5 DTM6qKQOOgNgGARgvrMA47GvBvM5ACu+qrxsARUffzHsj+hwPKyD9ehwdQDw t0Hg7h7iIYBqG4APbQ2+u/YJgNDrC4h064jhb61P60jguxtGF5BEP6UTANJL AI1/0ZEtIv+zEkoooYQSSiihhBJKKKGEEu4GQAHR+tYqoNURwX6PGOFLD7po reXYM4ID2CoXgPu2BaFwBKBOG6ZAgkbI5gAKC/c77luydFknQDes6IGVqwDW rF33LdgAG7/83d/IYYDzeK6HAI7K8FwHCUjCIsjCvbBE/dXQC6thLWyBERiD cXgMdsOeGzfwOwGIaWvTuLb91tpVuHYTrv02bIcd+tobH93dp8jQ3R5IzY2/ /98VZvzVpLhWxDMp/mMRP/rYiKOcGhEGC87kYGVxTIENni2OaZw/XBwbcPxu cWyEHCErli/taG+P941sG9q5Ymj3qvFtm7YnOndtGhvZ/PVuoROXw1LoQJe2 Qxz60JXbYAh24vwQunMVUrANHbwdXd8Ju3A0his24/wQbEVyxnBmx9d8xjf5 LZ0N+gT8A2QYBgY9XokbaA3Ssw+ji8ZrdDY5iHfMBhypVzctbKGc+PVbx//S 3oYHKBife8zqYy6Z0/TOIvvUx1ufGb7y+oBdvmYWzNrqV/1Tb6v27MU36v7D zP3QfN2cxks1HrQn/3cAhc6E/wplbmRzdHJlYW0NZW5kb2JqDTQ4IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzU4MzcgL0xlbmd0 aDEgNTYxNDQgPj4gDXN0cmVhbQ0KSIlcVQlQlEcW/l53/zMI8UQcPBkYLhXk CF5olAiDKB54gOAmkUHlEmTEI+qaaEIUCjyiS1SqlOgaAglZM5jVqHE36EY3 xnjFE2I8Kt4bXdeYlFvC9D7Yo5Kdr/6p192vu7/3+vXXIAAdsQoSKZOnRURn JadvBJq/5N5JswsdzvmLezYDlyYA9MPsJYusPxY3v8FjVwDzsWxnTuFf3u/L K3i8B5iicgqWZXcuK80Bol3Ahqe5cx1zTqXJvsC3vjxnSC53ePfv2gh0uszt wNzCRUsLS6Jbud0CdN9RUDTbIRpLbwNH6rj9XqFjqdOrmn7HfLgN63xH4dzA qglpQFM680lxFi1cxLz51zSsbdxZPNd5c1glc7FtAzp7G+sBYwL8+OsjK9Eb 0Df4u8nfXfd43WLMg82dr69Lb579h/98QBA2410E4hFF4QgaMR7v40WkoBJj cRofoxOW0Qko2JCAOgSRHwQSYSEDVWjCSyjGLVxHKJJxlbrxOnY40QPD9T3+ T0aZPsBenojHbhykApqGCLaTRBgN5J036EZYEKpP6svc2o5bFKgbkMTWbXRF CFZiI7ohH1/plrYMIgu1tILuwR+ZqFAxqlzPwwjsxQVKZmsilhmXO+xFAc/a RRZq1Nf0HfxZEebySm+ijBnvQaMYJOONHbAiGC9gEhw8+ls0kTdFyTgdosfo Ku6txWMxUByTZuYxEOMwC+uwk7NxETfxE3nRYNpO9Yyz9NBoO91kLMZyrqvt nL1afIQDFEVRwiIsnC0L+iOVxzaghvf/BGcomTKokQ7LGiPSPVp31z76jtYY gHRm+C4O8x5PKJJ9eAcZIBepfmqREd36Bkc4B9twBmeZx1XO+094SgMYN8Tr YqWeoev0LebiAT8MwxTMRBGW4FX8nk/1CL7AP+iZ6MCep9VRY7nxSG/i3AZj DHOfzN7TeO0KPqU92M+4yFF2JStHMYwm0VTKoQ20mfZTEzUJk/AXC8R96ZIn 5BU1xDB0LK/UA/14XxtmIJdP4HXO9iaOtw5HcZx8KJjCOaKLPP9nMUIkMHaJ 0+KqXC03qBZjjfu6+2/uZ7ocZq6ysZyHxfiQs/B36sEc+lM+LaTvmfnb4o+y k+wibXKwfFFOlxmyTFbKL+UpVazqVbMxznAY9WaHe777rE7Wb3EuCCbmFYIw xGAo1082V9M85udkFGMF3kA51nO9bMIO1HPcn+M4LuA7/MAnAPJnznm8eyFX 3Wpaz6iij+gwHaXjdIN+boMIYISKIWK0iBeJIkesZlSKM+KiuCv7yNlypVzF qJb7ZJOCUkob0Ywko8KoNZ0wh5qTzFkeX7c8aB3QmtF61Q13L/dv3Jvdh913 dJpexvyDEI5BzLSUWVZxDdYwPuRK3Idj+BqX2rk+JkEGV7wv2bgawvjURtNY GseYSFMYqYwZNJPhoCzKZaykVfQmldBbtI7eacdWjq2GPqB9jE/pIOMCXaPb dJ8eCy5iIbmag0SIiBDDOdJ4MVZMFlMZOaKI4RTFYgmfUK34RBwQF6W3DJLh 0iEXyCq5Wx6R5+U/lVBhKkKNVGkqR5Wo0+qsuqyeGX6G3cg1qo0jpt6mGFOq Kd+01fSx6a6pxWwyp5izzCvM583aI4jV6q8c91788hdhOk0Lje5qqbjG98JX Oo1SSuWMmcR0WSDXy2+MbHokrdRM5TJPztO7ZKJ4KosoTXxOAdLPiJXZWAtN 9eKGeCLuKB+aLu5RqNpIn4oiGS9MbZsY55SPKjHuAuISYsVr1CiOyhJZov+E WKOarhnV4iys6rrwxjW+1aViC086JfJEBdJVjPEMeZz3D4ylnO9RoowGyPOq GrekTfxIj2gzq8ZJGq8CxStiONWz4rZSPzygBXDSO4ijz+g72g+iOllLE8Rz fFou0ZGG8iN0UvrTeemJjDaOFCx8KEU8EqnykOmMHEzEKvENlpOkSK6d//7c mM83oFKEsKbZWU3OUTR8sYX1/on7UJtiG5eNCq6znTIMUxGJl8UJxPLduMVI xxpE4yDXYBkixVas0KtoDuv+RNZPgf2UjwjyYrW0MLeV/F70EAGshbN416es /1+x6ifTQ7xKVr5ZjQhVbSNrlZ2VKZP1t4IxBy9zaxs2mfYa5zCZLICyuqu5 yq/gFX5zvuf9e2Ek85uJnSqMWVtZmRfwjG3uJMQx1uAECbzGnEfxPU9RSay8 m3U+R5jHb9QEfhOPI09vQTyf3VRdoiswS+/ULyEH03Qd6+8SvQdDUGpkiDRj oIphjT1OX/B79C1VsG4noZn1KIh8cZ+xmxmNMj5DubrE2jlar9UX4MP5COAM ZfErehOFeMh5S5KNeN49STToROnkF+oapuha7UeeyNUFrLyHUGM2WHtWoZ9R w7WLuDGp0+NGj3ph5IjY4cOGDhkc83x0VGTEoPCwgQP6h4YEBwXaAvytfv36 9undq6evpUd3725du3Tu1PE5L88OHmaToaQghNltiZlWV3CmSwXbkpLC29o2 B3c4ftGR6bJyV+KvfVzWzHY3668949gz+/884/7tGfc/T+piHYmR4WFWu83q Oplgs+6nmVPS2V6XYMuwuh602xPb7bfb7Y5s+/vzBKvdNzfB6qJMq92VuCS3 3J6ZwMs1eHnG2+LneoaHocHTi00vtlwWm7OBLKOo3RAWe2yDgEdHJuXqZUuw u3raEtoYuGSQ3THHlTIl3Z7Q298/IzzMRfGzbVku2Ma4Ov+L9WoBjuoqw/89 5+6jNCGb8E4C3c1lg8kmhIc8EoSubHYbCLbNg7AbU91A6ADRFodHRTslnZZH F9BStUMZyjCMdhii5Sa0mugME8bpMOpgdZzA9KFWWlS0hQ4DzkDHXL//3L3L ZouCjpl8+5/z/+fxn/985/znhlQTiqhpTHfE9Khp/Ot5NbTH31c1lNo74KPV yVBel9HV2RE3ZWeC5ygMYd56c9I3Pph8q4rBiyLxXdnWEpmKTl7v52oqtctv HmmKZ1sD/JtIYAxTBGPJVAwT70UIG1v8mEvsSMRNbQcm9PM6eE326tYaUdYk N/jNe4ylxrrUhiQ2pjhlUvO2QH9xcXjQeo+Ko/5Ua9wImPeXGInO+tK+8ZRq 3nZyStg/ZbSluqrPV2iHtW9sQbqQl59dWJuxqZJqzqXG5kxcNfbIWAY6mP41 fngSN7CmhfyzdiGl1ixEM/wlNPQyu7Af6817IsmUrw56H/c3XUGf4U9dJ+y/ 8dGHozWdaY076LtOXGSWZIgGu1M2QyGzspIJ4olgR+HjElWfV121dUCYxkaf HwLho4cR285EXQ2CHwjw9u4ZCNNqVMyeprhd99Pqkn4K14QSpkiyZcixTFjJ lh7HkumeNMDj14i/LyaY3vLMf4Fv4rjoujpTm/gfzGtte2OL0djUHvdHU8l0 bBtbR9Vs+8KMLV3SbAMCbupBRGqZAeo1t8dZgX9XMGZE1ycbcNTgozkuEpcl ImGXRIlUQ4G/HZmRuRLP47H0oFvxv2vA4wWBlUbzx0xfssH+TYwJBO6y04D1 MfdS4la39JrMutDo+qJR9VHu5aUkHNbLRWNreyo1ZpQthssqlYoZ/lgqmeoc sHpWG36fkRqUcRlPbYwmne0fsH66p8SM7U1gEeu0OlBb0NI+Q9vd1BfWdre0 xwd9+MTa3RrvF5qIJJcm+qbDFh/0435WWsFaVnLFzxXkN5yKfuFV7UsGw0Q9 yqorhaqvGdBI6byOTqM1A8LW+RydgE63dWGl4z++KSKt8WwOqIOVqFYPAHyh BkaitMpHn2weafbVKapl/bk+467VSrkkHOCFLetph45vQOAr7uPU4K7FKr5G TbC1AjOh368/Q0G0fwz1Fsj9opYk9MuBj4EqoAXwA6uBOLACeBJoQlsT+BaP 4UDuow7Pl6jTdYZ8rjYqA5ajbOjvU6W+iQIoN3Ad882VU6kS5TLYKjxT0faM dZHtaFem2rWh3ybqgX0J6vcCRZ59VAJZAIyDvhjjHGOfIRvlaV6rdQXlrfBj GcqfQMbgaz3kCugfQnkxkI8+nxO11hqUC1FejNgUopwHRNHvBvdB+3z42AX7 eNQFt8W8+ZAl3BZjVsjzWol2EG+q89Snt9J42McqYN28ZmdN7D/79G8QY/+y YfunwL6KW759CiIHa+VctVdPp9d6SJyljfKIdRVlwz2eogzPeZqG9X0I1Opd NMUz1forfFzmeo3moe4FJivwmIdop7xGYdhC7hfBmy5aImbDMM+6Kb5JU91B egDrRbxpBnxPMPfAhelo16L6d9E0/SIVoxxmeIn+nIkTYoO9b4SMIO6XvWR9 hDEiDIwzCJxG/0mYv4ZjwPuutY30ou0l2J4ANoEjU4BJsO9RHEYf7o95Ps9z 2PtAPsVBgLkHzHGQ3h8H9zpQ8T+uMBGYBCwAeN4XgZ8BDwLf5TYYdyLaT4Mf TzFnmJvMD+aG4j/4pDjL+7gJsWGO2WfmB+JR2g2MB6rwUbIzjUq0VeeF95F9 5rPAYzO3mDOOhL3c5r12hdfJnMqShqtKza3OIHMrS1Yw91nKsFpDhRii+cxZ O9aOVD5E+TzymXCk4w+fT3VGIGU3jePY8b470olFRh6hIGwrXG/RA/psWiXf AP87UH4YcgHic1idwSv69+gDsYOEZ4iqsJd8dl/KkQcYnmFtA8YbQizL9bP0 kpLDokwf1lyuXuuSq1c8ZcMpZ8tcaEO2jSUj2/bf6v8XiHOuXnoU5b+5hi1L H6YXsFby/F2bBfgdCX0/0ANUekPaAW+3NuBZST7w5hrwuB7G92uYFuhDdL8+ QZ27IPQrMXaN3k2L0E/iS+05uZKOunvps3IY+4i5xDl6hsHjQ27M8CiXc5/m kpIOX28j+QzkO1KdqVrrD+pc1Vp/VGey1hqxJdVybuD7WeUHUndzocPXDC9f pnJ5PYufOTzN4uci9PPl8jJLjmWZzi35zjlFn4mca3j96n5sU+dJ3XOw9Tvt c2Wm/3EaEMetd9Q9fJbanXMNzAaCsP88fY/gHsZ+c87cZ3W4n7A65HKrA+v8 sXsX5FXrpJhh9WVyapDmpO+yYieXcpxcZ6k0k0eD9FD6PgtyPtWPIYfbeXSc yp9/ocmuq+pum6P85XPIZ7AG994M5PF/WDf1InpMPkckcS5ZD440sU330gT5 J9y5y2mzPGz9Tu5Xd1BUjlBChnCG0Rcxm+wSVOqqp0b0ITUet4FkHfvv1sFP vgsaUMdeOfcy7737JuUDM1yXcR+1oc1xtdaguscP0HSOg+q7BXkFY3lCVKQL CqXbBFWfr+K9oOKBOzArFuncvITHdDcrzhaoPnOtm94iqmW4XqH5mD+o5mqg Om8tlbvarMvqXVFED8ozNEs20H0oFyve70KOqkC+bEB+BOT7wAi46bPrKlcr ad1Q+X67yud5rhpapd4TbHPTNHcFzWToBmxJqpavYJzHwaubKL9qWep98Hsq 5Lmhj6XfJ/xOEOq8/Bb9fkHVfMbYB5Vv2J+D4NubdB/nRM9RxHAMn0FNQ7xL 03mwCHUB+e0sPJ/WldpSC4i3qE3ZWuk9cUqcEKesbn4Hyrfpy/L72L8TFJDt yN9vIDcuQg5fjlj9huLy1yiXQX8Y2Iq332Yq0AuoS15AuzmwbUS/sxjjKOyM nejzLuSrtFj+ktbLIbwPLvAbgQL6FshHgHqKaD+kbnGDut3zkZMXWS+r8Rmb rS8qHEXevJDum4by1cHtfN6Gt91t/FW+ZvvJPt7GPx6Dx1X90EbXqYDIehcI 2nKkSeyjXuCIeBttv0DbtGN45h+imHYROJTGj6hByT6gCWdsnvYkMFOfRz8B nka5CvIUcMKu00HgHWAHxj4NedKNTwWGWAo+Q0J3GDgA/MqxZYPnup0+G64S Gl1/nXoY2jXrn4zc9vrTNB/zzdcXEzHkJXqe4d5O7Z6t1C5xP+jTMGZOHfPM 0V+nDXfy507Q3qRZKoY2wnezxrsFn13Oz/+v8e4W2N/twCPKh8u4j20OjdXO URlkG2Sb3EJfZ6BejXrCiad2DVxjHKPvKH1m/2w9uEKSc3aOPreeu693qouT eOtmweFBhg8v0LMM/V/cV21QVNcZPueeu3d3XS+7IhoF4QC7V0HWgGsNfmyz dwlo+JiA0SrQTpZqjVOjA1abTFMoOo2pNlpoNGq0EZKGphOgLHfVLGork47J mMkonelMO/2h2Npf/VGStHbSovQ5Z3cRjU7SmfZPd+d5n/N+nPece+65974n hHjgXt1xibwgoF2E7+JndfWtz0EjapTjck5E7rF7dK2WbBdQfJhrpuxzQGBS v4KzBiBiZX+dHBSQzy6gnCLfFJj0LyUvCUxZ10fEumJM6U/dn9R9uff+YH6m ehloRD17mZSA14LDKZ7c38n3xV17fk1iv0/q4l3y53ti7jwTd54NPCsPyvn/ BDw7HwDvA+/9r8eieD+Id4QHkDXqSlKhLUXtuZ7guHrrQ0LGM8Az8V3Akzc+ ivZv0d4IFKH9DmzHwPvASDN+G/YJfEewlW6fVDNRvxOyD0CO2y2JvrduAs8l ctw6R8i/fp/ErkT/8QPAKviwC8dPAdi9478AytEnlefH0HeAfw19dSLXONq3 rgM/AKqBowke/yEg/E6M8TtRj9znHPpf5QedP74oJ88ZwRR/5gzxn/DKL8R3 nTlS9//zOHWWuA/LdUjOX5synwedce5i7B/nVKCW9oqaUtTRopa1oX4W9eMk i3Pb45JnJvOk2C2+gaJ2FvWrbQlqZk3Oo2jKebDiLFk3McyuxyoqAmYcXPSw ZKugMDAkHFbmvMAv2XWljywgHIZr1uws6blqlZUlG48sSzRiCxcFroWnsavk r4DCrrJrpCDRK1bwcGAsrMNA2feIm1LCSTfq5SigEJP9IeabH+i6wD6E/wN2 iXxDdrtk6TMCSPg+e4eko64+w04nPadjaTMCJLwTl0LJMOQIMAqMASppZm+R dqADGABQ6EFyoBioFRbWy3oxzx70d0MWA81AB6CSdext2J8Rkv2cbSX56HuA HSazwC+xQ5LfBGeC34A9B/w6dMFdSf0EWPiPJ+2vQp8NPpbko7BngY9AF/xK Un8Wnx7Rb1eSu9lOK4d7wjnw5wIlAEPrMFqHsXSHRU0ASdn32TY50iA4AN6e YCxXm5XnlfeoLfbQ3EA3lrQNS9+GlWvDyrURFa7WVExrImYRa0VMK2JaEdOK VSlhOzHeTrFJIT1ALsCw7jux7sIehRwGRqT9BchOoFto7DmsYyFmtZ9ttQo4 NtmW2HIzEDrHnsZSm+zp2NzsQMcdzTlNbERwWpLdInaz9G6OOacL6+ZYZnaC EfVMOI1tIt8FFJIB6QO+BJQDKttk+Yr5WfYE2e4gZhpvV9pZu9puU0vKafoF FiB1eINzks4WkSACCnkkSEubnC3O3U7mceY6S5yms85pa2btrIMxzopZiNWy CLPFJ4Yt+4olIHO1tmJJp6vbFXUNu0Zctqg2rI1oo9qYZsvVSjRTq9OatBZt t9apdWvOTq3TrjS5Wly7XczjynWVuExXncvG7bQ7vJdtFN8mSA/QAnQCKtY4 AnsuewqI4G5EsBRPiUoXkkDzACNoj4Jt0NyIcyPODasbVjesBFJ46oAmoCXp 1SY9qT4ifkx4AFEUpcGahrUdhRwTLaAKmg5Nh6YjakQZxww9kLlAHcCkbRTA roFM+UqS/iZAk/4xGZPymaKvMm5+fcFwIY0W0u5C2llIzWAoHDDzIdLT0yPe iBEpiPSozd5mo7mguUet9dYatQW1PWrIGzJCBaEetdhbbBQXFPeo3MsNXsB7 1I6agZoLNVdq1EhNc017DSvFrYtZRSUByfmG4NPW3MxAqTu8EidQSiKQXcA1 gBEOWQyEgGZAVQYgudIPaz+s/aQWiAA29OgXrxdInvQJe5f0iZbwK3f5GS68 z1qxpDZchVduBOgCGHL3wd8noxOtAWmPQo5Ke20yvlvaOWSqD8MLrlG+5hrx +DWSEBABWgAbucI2kGsAMkNyoAUYAFTWiP8GtkHpx79P6WN+U188i5PZs1Ew pc9weMIeZTr2gI4iW8hjUu6XMiSlz0yr0m9W6b+q0l+s0hegoRSQMByHpcwz XWH9VFivDeuFYR3ZHiJ5RFdmSakJSf8i5RNS+s2MPP3TPP2TPP2jPP21PH1H nv7lPNFvHp5dXcmQ0iUkPSJllZTzTRfX3+P6Bq6Xcj2s05MUo5MyKXOkzBKS fnzKXe4mznP0Y1KOTNQKFvK4QiTRCSsYBt22gqtBt6zgSdA/reAhfp5+SuUn jd60fDd4eBb9G61Uhf5Jkj+ilaQXPAbeAv4ZCVID/KYV3CPif4r+x6G/QfId Iv51Uif7ddFKaX8t2e8nln8jRj1h+b+DUY8Tvxz1qOW/Aeshy78f9LLl3wbq sAwxwa1WcCEPz6BbiE8RsZuIoYiZ1CRHfByZt4FXJzpXWH7Rq1wMEKePWd7F oAViluepl9TJ4bjllReZTbwyxTzilZPOIobkNOqWk9dJvmSH5d2DLNop4wb/ R/CcuHDyd+q2TvI/ncf1rYf6R1pp9fLfDInlsvgVf5waZ/hl7zl+0Ren6y0+ 7I874Ljgjyv0NB/EIkcRq9AzfMC/hfd7pbfHCy9udVdwET/hbeSvGtAtvsd/ XkyDbMcVr4e7wf8orwn28lVGnMJtBjGYOY2v8H6LL4d5WZxWxnr5Yl9cTKUE OXrP8IUYcb5XTuUrpWeVpcROv2367bvsG+3r7WvsK+1L7IvsufZs+zx7hiPd 4XGkOaY7pjkcDs2hOhQHcWTEJ0ZNHBooydA8gjRVSFW2PYqQEOKtr1CHgmcn OpNVK9Vry2g0vZpUryuLlhZVx+0TT0aXFVVHHXVfrR+k9EcN0KLKvjgl6+qx QYVpb1Y0/bH6IUJp8d6DWYJb9x5saKDV0eFNpHpjbvTmWlzHtDWNUZu3bA6Z /WxoTij90RnLV5XfRzQlZdGd35yiqb852dEj1Wvro29nN0QDojGR3VAdXb02 92v1Q8oOpbmifEhpEdRQP0SfV3ZUPCns9Pnyhskwkq+0IAwVf0siLEbyRRjJ pzEZViPDsE3zK8oH8/MTQe/SShGE7fOuDNqSyOXDEMhVJwhhSg7xyVw+JUeE YT8kkrmnJptOqFsmc08nMtk8ETRoGAjxGyJksNRAwKBRKt29d9xeIzGdBmLI cQz6b9arPriJ64i/D53kk2R9S3cng9EHsrEPG39JWOaKzx+iDYopxC61CIpt bGMoBcfYSqcQYrcdwkAHDG0m0JZit02dpKSDjCEophMzCWlJ8ocz06RTWjph Wk+HaeoJ0yYQApa7T/KQZMo/nemNdvfp7bvb377dt7cXy9jB+LM1y7JrIAsW 1pAcWCP/P6/u+v9hMZ7ouNbVGen2R9r9kW6g9uT3n9gmJoe2eDzjXdeYwpOk Be1bOrcx2dGdvObvbkx2+Rs94x2dD1B3MnWHv3EcdUZaWsc71e7Gsx1qR8Tf 0RibGBtsiH7B1sH7thoGH/CwQfawBmZrLPoAdZSpx5itKLMVZbbG1LGMregj 9Ti6vnU8B9XHGjZn5QQx6OE8tOd5Y/Uuy+OrM4djlVd8Km9Sg+C1ZZBjSaO/ PpkLxFQldSV1TAWnk6lMMG1eUIlPrfLmTeIXFlQWmLb665GMxMj2xvu//v7+ AUaJhAx8ICFm5gbg0Hqbo8k1Gza1JpWkEkmq7Y0xzMKRWLgaWlXLlDKtkF5l UBlWRpQzCpdIxGDaNuWb9pE2X69v0DfsG/Gd8WmZYnPry6oy4vvQRxOQTXgA rkhjxmYCJPzY34FEP7sQGOgHypqTE3JDa50PdUK3i6EzL0F2ID9QJVAzEIde B/57oL8B/RtIg74H/IdAvwCaYDO0hJZExO2NzGJMZkVHpBUTZcGK6hTIjq1Z 2bwpKyPrslKpqxBBnq2t1NeZofHGaBL4W0B/AvoH0KdAHK2gFZmHJ7JZG+tH /TIG+Aj+DDDWLw9gGQaYbfdAvywjRizBIQKwVMZfzHuE+xMItgICAgIWZWb7 2W0JJj9bCDUYajGX6ZaRDjWNE3yRvAptqo5MnUWcJkVePUeRXscG5zGScrTc FOgJorgI8XgHfgyJsuWWMqess3ykNM0pqBbGlnvAysu8Vq81AAyKP7rnoZfu qRy6izyaS3D/fuonv+F2QD/iRicvpKQr0m0jNabmP5nwB6oysqSsCqfmb0wU B6tQav6KuhgGkgjMXQ3sthHrjIKR6BftN/WEclEKt0zoqNsE8qyDohQNnsvN 1WtMMFBdbrdg1e/UvC7sRFZs3Z+36BnvN/ZAeb8Vn7s1a7WFV2QZqp1Tahlw GffFFyrIbkwLC4JVocoKl9Oho176uT9EDblIdakctofTW1a6giXLa9wh6sdL vy1JtTU15V/rTP8ZL9uzXK1ZVV54JH2VvfQ2gN4NfhvRBjVPbxrK7wkZmFNG 5lTKcMXwR8MNg8bI/LmgpSZBcPPMGVVvNPI76VBuy3Nsv2cB7TpLpLvx76i2 iSHGuwGs/fPgToWEqpKSVRlAy/bKgKEscCyLoSW9ljzJHUF2VKP6n7U+byVP Gw9aif4Eb0UnsB0yQs+/YPKt12LtkKPlMWYwPjunKBaI7mztbHkZiuM4dhYU FpCgBa10arXE6RDyCXnyePfRk7ji1t5T67zutfvSvYGHtx7Dh97FITy/q7jx n+ln3/jDmUPP/xgwlAKGjRkMYXVpkaY45yscBeNWAGGHNzmvBwDZb0mqHXK2 PvffIHDcHnQJLpvTgnTBUMgWrCosJaUnuodPpqdv7x1p8krRJ7mu4ujWH6S/ 9V76rTTeFYh8gHe88V7y0BhDsCt9Gtr4K0hAzWphjMSEyy7KC+3SOxLlMdJp NOYcG3rZphoNmhqzc4lzyEmdKVwMbZW5zUzMkngSQEHWx5vm4pA6szO2MLba hDBDhvvsAAkQFfh9Oq3fdz8u2l09fbxOZwjYHOU10VB9z3D69HLf8Hp7Lu/g ayrL1/S39YyzGDXjIdIKHwkU1aoewg0t7goNcpi1TklKEbHg9bgdH8Wj+B2s xSlcdR4NaVo2sV2ai7M9WjELnEGR7V6nt5lwc3eJcJw9+dj8DO5FryEDktVF SNUaqMqrNUFerQ228XiEP8MTfr+RnQ/LrT5IK+ZbeVkggz7rCUYr1LrS0rq6 1zK8dIXKnkvnZ8hqiChFj6g84t5e0hOCQKZooZpLqIMQgA3VxgCZvUR1eGgZ baeP01F6nWrpRfxr8rYmhXvH389k90dsQ5Va5QBXKu+zXGYHEvsxWZ12rscf cEc+3cj9ilm8CUVLy21DLnRcdahiuzgqXhc1SFRF8gR6GhFTnR1vh68dHo8i H1QsNs6BsR9u/gSZ8XbkghmE/6VCH28mPMEcn2MkFE3i27D8IdVmMplVa7DM PGg+ah41a8ySMEmW4hmUDbysNFlmZ1hCAlYrC38YfTx7D38sy5kz0he3Byqt DpdLcHqDq0nQCvnAEuImXuu1K5vTpL3apdcF3IF6ze9+dvfA7up8EgiQxeV7 yLVnij35S5iPy8HH0+BjPt6mflcnGsKCuOhLVaIKTGLMnO9yFekU3UO6F3Va 1fOoZlPOo8ImcUfOgHXAdtLwU9OPrC8ZXjK9yb0pXBGvClfF6547mjuCE75p NBKX55RckrBY1PGCQTQsrpK+LB0Uhj06USJEcEtGSZtLJcJpRYHVFLsmNwUw eF51GGuHeMynaKVqtHDuYQmPSGckIk3SSti4wxOYGPNT+LCai7R//aq9zd5r H7Rr7CmsU+0qOOVGHtUz5KHtnlEP8UgX8R3Imlysqo420ksGyTCZItPkffIh ySHSkkl8BBJ/4azNKFD44n234k2QJBaWJrNz8T4o233jWtLQ0nphmMdT/DRP ULwvJs+wA5mJjC0cJpbsknP7pMMS6GMm5YCF23fZBAmG+3bHIWLslShj6g0i FKyCUGl1/tBCQdXqiM5bEQqtpKfb7l3HHdhzalfXSEFAmv7JL/9Stnbszmq8 5ZtfX+PGXPpuANfjEy9+ZyzR98pv3z3a0/Pz8+mb1ZZy1oI0z9+gGyGeFfjh V5B+/vpZY5hPzV9SFWO4jo/o1xiiPs00j4uKqovUqvb/0F0+sE1cdxx/793Z Zzu27zmO/53ts8//zsGJbXJ2IC6CS8raQigJQmlIRkoWJhICHSFsGQmgmCxt /pQu0dbS0miQqaUttJUSUlKTsrWVaEXpqlWTxijdVETTQoBUk8a0wRS0d+ds Y6t2vvd+d8+y9ezv7/v7fS7129SV1N8MDEjBSn1vsCd+MnQmNBP/KP5F8Ivw 5/EbgbmwcY2uOAcPTUWjGOTQ7NSnSZjMUanTlAbboT0Hj532yrFEyksecaew qTj6DmwDRUCPvpQLaokGaFTVgCg5NWGExhwcJeul2VI0WjpeikrJ+uktTC/5 7Tn0lWyQU3A89V4KkY4MV74tW9+1IqtLmoE8vP5vgVR15pt231amWUIFpH7E 5jtXzTfNK012afLBbrk8nuAjBpbWBoSgEBLCAq3VhM2RiMHfAhN0aQvkWXIl FIgt0KCPa5Mt0GfythDiwSsWWWfJQXKoHusEu0nrU2RSk9SuiiUsllwHMZ9d KlNLsWK+oOJDRVmmLTPZ/1J91cyBbMfP7t0c2poQXJxlryO8ZNvzQc4XO7ze X3PskYPNY2302qHn2msanz26dHrfxMHXVoveEp1mlbbg6M6a6uXeaCVveLy/ prX3FcWtLUTdbs06IEBefvBlGhY28Nv5Xk2vttd7iH7Gy6RRWqij6vz1wg5P l6bbM4CGuWHPS9Rr+vHglSALgpDFlkKrze7QFZGqSeWgR7b4BVIuab/AuT0U 46Q1ZPXYlN8vWGeIb5yUVTaaTPAqQFcFgYDWDFwJ3PDh01lmXFEN/pWoFoRy sDmIgiQd7kxjNC5AQfkSWe+X8ThG2BWYgc/BOVXC2SZS1DDpIfN5IWeJxcg1 abmqfKTGKZ4a0MVjGlKagXKTt5Vs6oSdqNPfB/tQn19L/KXYiriK4LtcsIPe Vfh9vkPT4dU0NZAGyQgMreil1d7XHxelIkqJkOpef6+tAerHnqzv37Cnu2dX PMiJiepHfzR59OknzkJas+7ktHh0MLdjOisu21jmiWEhNdm77/eZUgaxCs3u J1oME6e5QARIsEeeaSBYIfmkJeIuqSeQLcgas1zW3RfORoalE87j3KvhKeNb 3NuRd8QPDB8U/MFkZ4ABak2I04t2k4MLm8LmangI/sT0pPkEMD8AMrAaVMM1 0S3wu+JmqR20w+2oNdIutkn74H6xq2S/NEKPaLJMVtdn6SscKRqxv0Af1j1r OVw4Zn8l8qb4ppSjp3VzBTeMc+Y5ca6smDHpxQyogMvLNKt1wMiJtDphhz8H tae0mlIlWE3eSj1kSU+T1ZEk1xhukzFIy2kkp5vT4+kraTodPEveoEguLIGs bEg6ZMeog3K4UjPwm0WhiVfnb6siz8/enlehShETKgRDLFoWS/ABi53W2cKC JtgCfIy3BZYULWkB8ULixwBNDMrryBSzl7aAhIVMQCVm1Z6KOxXxydkJI//B H8buyHOECtVhhZGUMmsrsjusWiUsehUO/bLpNydePr/z9YmKdZcn39/5WDdc ulfu2rYtm15avrH2mSd29kUeRq/3jz/W/+6pznVHdwyu37Z75OPu7+1pnLy4 80DN9h931aTaEveuPXS8+eBYT/0jFe0KOxH2GaUmCPs4QNUk5crBsOw1tZaP usZdSCsDxigXFrCyjSBRatQ2bkO2szAMnOB3hIlVAr2t9pxF/ozB+6DIej8g CQoWkVGSqKxSIjWRJ6V45YK1Kn9VRWgI/JQwaI6aJPsJgq2yWwi/b2kt/5A9 F0BGk9tqw3rjtNOo7KsoR62XfbzsJLTG6n0E0crdOMMKPiErUMJ5tyukABsR VYFRrPLTAtllAs+qrY+cihn/a8PU/yFUyC1u/vH/RVVqUs7vXb5799vQigAm T5IT5NnGA3zIOYnUolAIfTzivcDDe4DXB3kPKvo1dRU4yGDIMFBXZYcOeXiK 1XnsXuDrgFmIINSxSAcSq0jFafrk008SCSUz8fz8N7dgIn/gAwPnzmEylibd sltnZlkTNvB6X62gtbFWzFk4t9vj9GoF0lxPhdNKmEpuSqkxFlfjqeL8sj+S X+b4/LJDXT5lU4P8PLamTGwB+fIKdi37EF7D1wgNbD2uK9rEt7OtuI3vwll6 wDzMDuCBwiF+0DfGjuEjljH+DHsG/4o7w3/MXsDnvRf4z9lL+CZ7HV/n77B/ x3e8d/gSPVvtRj4eKn8S8PK8R282uPV2j8Nt1yHGrbNZity2vTyL/Zj3eAIW XGTpIE+wmDWbc+gj2YJ4Ata8z3scgPwfl4OnZaMOs5TNbtfp9DpPDt6V9Sz5 DDpuli05lJyq4SGfQ7dks18215r/bKbMr/p3DKvZ7eJI9jg5pfQrZIXJi8y3 STNYWDFgzlf8gSZz3BkbINwUcwI8D/F7354H8IFzK5gV5FRbQOxfB+wktV9g VLsTJC5fVr4MSjDPx2oyFiDqxMJfNgceaLlXV+eSVsI/BeGliqaNC3MbKqI/ +PoW/PBijehLMOEw60z+nN78jxcGN2jCYToulGyBJhRa+KNS+QMA0F+TLsyD GFiODsjJRtDID4FBfkg6wv1CfIN7Q5zjbojXEsbloEfsll4sOyIdD52ULnGX xEtRA53JoWtTbGt5RskKTyClRPlLmyMlyUIJmVx8qkwORsnk9qZWh1aHh7jP 4MXQZemrMEOHYNhUhimb1s0V8faQPWpLxsu+E1qbqoebXI3iYWTBAGfqYGOo OdORyWbGMzouyZXVAgozXIiPuhK0FlG8g6+RBkMvhj6TGH9GztRmtqKtVLOm WdvMNCe7tHu4Pe4O/oehPWJPtF/7lPspfkTKZi4kLiduhu6GXA061ufWCwHs c9uFoBQCFF0C0jFfiAoULy+RqHggmk7r7cVRh8OO4lElU0YjMKKkfSathiol ZKdWVaaU26l/sl01sE1cd/zeu/P57PjjfIntsy/23fly/oiT+GInDtBAjlIY H4NkaxLK1AgyUspWKpLwlbRrQdtaStSOqB0U0MaoqCY6pWpWvgysDNg0idFt INikdtXIJMqgbTbWRlAVYvZ/59Cu66T43fmdnUT/3/t9zZlnXc0K2P/68krk jBqVuLKDScvTaurJA35uo2Ay+xhMwTLG0AzZdLp9DRSDFAZBubtg6jVseTnu qHFB2YLV7YY1BmfZy+MOr0LeevdOn/ErdIFSqW4kguKml0ykoWWNw9mBlJ/u 6pvz0DGqnq69LlmX8WUQCJvJCe0ftw5YvxVWyMtHwooV/uFF8n9wOmllYGyz Mw1aUowie1gKSZhl41U61nPxpBjPoYy9Poe0aDxHN6D6HJ2QUjlk2OpylB6J 5aholm7MQRWBENr8udPdy6Koqw/19/dT/X2f2yBFKkXJ8FhNbcxlm/JWB4QU qpJkCvt6gDheyQXtvqn4YxUP+s0X5nVvufz+5JZchx6MJBbn8MJXV+7c+73J J/Xl0198acmZ4z1t6/sOn+w8s33WQxI+FL3/4WceOdah57V+es3Tao0uVh3d tOoVr93e8v3Fmw4Ebq+V9g+0vtjO2EhSXXj37zYvaHUVwub9jmgGZXCGzsg7 vbuj+737hSPeo0IZF4X/Hj1FP+kfCLxADwV+Su8Mj9AnaIeL9jA4Mp9eRtsy HO+rkqAO2A5jCaHjVIFedETZY0tW0qiALx/2pUd5xBfo2Ye3u3/mxu4CnTEz FQ48QiGEsvzIGz4k+1p82Bc24QA6mhUReUVZxKJ1PMQFes9Ky9fSXf2LSfO7 2d8HsaWP+Bs0jImrLeMfTYDkkCRz1oJX8Uusy66H42XxgM5KjlrK5YeFC9lq kTPoriUpZQq5UkTp7+tC5Zo1dOyvEAgGTUGW0RQSUYQq0iEIck3MBVmedfWV re8+tXF81w9/PyivKt44UXzj2NAR1PLWS9urBakiXGZ7rJj705FtxUuXC8WP h/sOVBw+8NnxO+dQ+4n5gXLJIJ6vgUuSjhCAlkCby8qkssiz/A7+z7xtI7+x Yiu/q3y3/6x0NnKJ50SfUBGJ0nY/2hp+LoqTHCtLlBqzy5Jb1YJqSE56PG4c SgYCFFfZ3CogSuAFRTAEU7AJhbt/O0JmKCzQCBdntTRCD1A01KuRrkFratBi Y9BiY9AadxCigIsHNrLWJhsmm+zeWPcUBoSLk9YKsbE/fdMC5QvKTb9Hscpw 1Ovn9Yp41FvZicJ+WCI+uRNJ5aHOe+Mn7Q0Y09WX+zIxFEbw81DgEjB1CrQS eKHlOqsClYQBSWSgmadHThc3/HVz5zWULf7xxrfW6U3qOnrNZqVGHyqevFh8 /+Slb1eieSiIQuiBCDnrKviBDBOvRdW/TGYK0M2a9J68g3E4RzP0rvTx9O/S 79AX09eZ687bzG2nA1oKu9m+mdti28Jut2/nOLvTUY3tqstVQHHTzUn2iCwF 1RirYkx2UjaJ9VhKG5WluKqla5JOzsXYMEYazDVYS2lxKskncbKAL5p6IhHH UPAS6eQIlUJUykiZqd4UkxpmWdmOWu3o13ZkJ0ZeR3ksiDwWGh4LIk8sGrEg ilibEQuiyN66r0A0AQg1g6f3TZIGB/j8swtcHFSxebIZxBF+SDIEMPjxjyh+ 8t613oDMDlqWRj5ChJxPq8Oa5qsIknKW8/+XipXgKifP0f5bHa1uXUeJuQ/c cjuVGqN+8rjRHhfdThlOBP1vtxae+8h3bXjyw0Vri42tC/Vi56NqSBB1vV55 gl5Tui/+ZfmyJMFrPmjTL0CbGlCX2e5k5tXhUCKcxLzIh7CSN/Mr8gNcr9gb GqgeFodDo+JoqKw2s7Fsaxkt5uvCbfne/PPM68xYnnHRz5adytPzOcBF/CQm ENS0BkutDlpqhQ5CXlhkzqnfUxMUxRibrKE9yZgDpeWoi0w+ag05ypIhQxvy tQnDAvYKrQImTNss3BUYgSFoCEC3K4csuhXwp2aZs7ktjrxxOY7BNm+YPPk1 cZ48jy9o7BmawgroM3kznUlbUFmoXbHKBUGJv6drU5xqUNJ2ntOTiVSiOkGz LrAtr+q7Dyky77OnnbWUW4OFV6CZOhJsLSrTPbVUyYhIjiM2VRI8sCXUhYhR EdkDFBUSyEq65yPm06j6SSfw+8C1LBEE8SPdIGh9hLkOsLcPnixObu3b+cmW Rc/Plmd/E7tDSyIV68a2FTe9vbtz1Zs7zi0cXDutvFyiQRDb931jwx9e/9eZ 4qkdcR09t6pFjccb9MeL3bNm3Hnr1sFXf/OdpWLKr+UA+RwI5AAwVaZOm2tV k0xWNcnUVDPZGFK7fT15TpawGhNlSVBjIVlCquaQJZ+qCT6gGyeGMMEtxJGB hxjy1VDM0ctt4cY4+i6HDK6NW8HRy7lT3HmO5hjyMc7iEFe4++kh8l24KZoR 8qe5bqUX+tWYShtqm7pCpU+p51Xc/R6gB4hZZAPoALsS4yyakb16g6z6V8ky NdcSmfDA5IkpjtQYBp5b/2A8BNxJG/qXWEHu7/zYuifcSIGWHYUJKdSoKUGS RAqlIDO2FD+KN+EhZbfymnJMcaFYAf3IzHl68h344SiGCdFqLNAk+WbGnLLE q5oiK5RBmRCW/1Hp43GlhmmOGkFrcAH/1swE/p81OBxOS3ic1q7TGppzr9rd 9YXwlM7wxATxBGIJV7qIJcA8UH8azlyQ/p8Q5I+zpXGAtEAKYnaq629fzXXq fkvsV61ZqvCu7A9W/uTp1WiTvTisT1PW048RoddRtTl4Z+RB2V9RtwGmAomf /RimYqCz5jWviDwUF/SE3ElvylvNGHZhJpqZWSauRavFxzOD4stoT+ac+K54 DX0out0ixALWmGfQeTFvfE2kA0ZCjBs0K9qMYJBOUyl4dx81IzhdbAw1Gi3Z 1uxq6glqozgYWm8MUdvEZ4zd1MvGa9TPjX3Z0ezbwbPiqex7wXfE89nx4Afi B6Gx7E3qs+AtQ5+PFvyH77KBbeI84/j7vOfEdhLb57Mdn322z3f+Osfx+RLH KZdAcxUrHws0aI34GhGtJlW02pqPAuVjqKiwBuhUOm0djEnAurYLAok2fAXK RDoNNK2biqapo2USTBpTty6jk7ruA+Lsec+BQTdNlu99fbZP9j3/5/n//uEF pdWwKry89FR4U+SSeNF4X3zfuCHeMLw1Xk/KUlRRdVnSFJXKkktJ1QhekaUc Oj6OKAJBIkYIRESRJcAHjVLQEMNGSUSCw98ejkYiYep2uQgxjJzmMr6MHRUp 6WoyqRxW3lSYgq8r9cpBqx3agbJLeHhf0udn7N1mSxtriYJmFv/ZANvM9Zul KhbUjoN2IMRHGN3DHHXNRkIXJkK2EWtchfUewL4YHkYrmb9mpSWV+GBTD9QO vCmKflPkBZO4RDM8MXP5VNgMG0HTJubacxUgOSvAlHG/57DhBHBPH93zNnAL pj+VMsuMqmYgLwS9vY/Cdvgz/B62l1YgP2SWlaYnjRWp5um/OTbc3rhNbslk OpIj3MbVWjyXuXXVYb+8vefuG3tuvYgdN3Nj5k/oRktIDt6xevcIIOwFZOa+ yl4KQpxCjhYDcwKbAvvpNTpDnQFVFbBmDYqKNZMUlWN1TQVZXVOC4AdKVUEN CoKKHfqq5csdgwa3G6gUdQluzq5Hk/Co35/kDd7iOX5i5vpJPxYHN5+eZH3H NjbW8Qfzdu5CrMtDMg+H89fzNB8IskuEFMVQYVIF1e5Y1bYflRlRA/uqGtEe f/VO1w4Ms769S3R4Avd/mMZp1lOr9dTUaK3MBJHBtEvs5OciJwyMzF9paW4h IuShh5hCH/misJasFgbJU8IW4ftwBN6GU8K78C8QblJgrrOKIFcMoyTOEjoz diIh9FAWLps9PWifH51GUVkxk23HZxfJXk5HTJzsbHvF8gmm0CyYlA/hM2IG 8Nx4o4mXuVxb/nEqaFLLb5LZbHYnpDFVkQEORdVx3yxOfV5lWTarJRji5jHF wBWmpfTt56VsHwqLCal7Xne8u27JbSfnvSOVW7sdX7j947vCOf5wa8CNpM84 ZhNyTBORyFtW2z5hzHmk4QjveBY2O0dhl9Mx3+XRCBfS6t3iXJkrcZRwPJfk DM7i6rjFcVbfaE8lGbfiNO6fy7uTbupzy27qXhybjUUMwJfyw4XPaiSO7GDD QjtIvkxjNpoNZL1N/iKRQCxC0Im75jrc8Q2eIkQoHgRXqEjCjlCR3HuzCphm B9BZEL8VdnygkyUDP88IQPDzyK9T4IId1S3Vj6sfVXf89sLfTz+9+6Wvnbjw z91Po+EPVn9dfbe6Dl6CuTD/F28tHh2rnq+ePLELWuAhWHN0F0tBOLEdBdvp W2HTWaLjX/12V6WkbxDXS+tjX9eG9Fdizs3imfQ57ap0NfZhuj6S43Uta2bM XLdm6KtzT+aG9O164yUC0Vg+1hv7TeSqVDemwc/TH4Q/TH+Qu6J9nK6PWam4 5vKyUaqCLDmVFA7akJIi8WRrS1zrSfWlEG+doRbMUCHqcroEEuWjRtSKDkXr oov12eREdLD0N3V6SJ/UL+uc3gq2QYJthWAbJKg+r91ts7Ru+6P3YFGfgGdP KAzPC4/8d4IaWDofmyHLFf8o2cvUqhqsTyGblwYQBE2h5qAsVaXz4ZiY0bL5 cLYM6RgecpGWMmQkZKf/pKrF/ZstPoHjJ9XtUBPJbiyhTMBmQFKwE+/wCOIf tmPhf0xY1hrteC+C9Sk1m2tmyFdhUKg64bVYdmnH9Nvoz0EJ/Rn+evpXL1/9 WdvIQ5UvxdftW7Szv7yMbq1u2C6jP8+R13NfZbve8S1vXPYubGj4wfaV+3oD WPkUIXXrsPIa6aDUGk+L7HZl7Js2qoLwjezF1MUitzj9oyIV5bD+RJpzgzuT zSwkK2GQDqa3wlb6jPxMcqO6KbMHRpP7i0fhaOZM9nxxJh2qT+6Eb6Z35g6k X4fX6Bvp48ULxSvGzeJM0SOQZohSQcPqtnXpXcYT6SdLDS0uGotBSJZ8ikoy mkQQL71KqlmWYkrKoq2ZdFqlEES0TB+jSepsyb/uZJoIs5/r5J3LnI85uZed h53USaRjsY4J+Jbla9fi8Rj1eb0AxCUo+PnxlRW2WA/3VYhyXKF9aMZUOcV3 goVp5XIn19nhshXlsu+Dy1aUS20O2YoK2SdDtqJCByuPn4UI+Vza4wdGMPAV CkxNpZqaSrNqmjXtqSke5TQwUipM44lIlJ8a9aJt41wHwYyiOnmMG5OFUb5u 20/bDJHprdiWSMmZYqpUhrYEHnS1tUxSaSPZXgaCqcKWHGaKEdTUiG31Z0lm 5vp4kwnoNeNBU0P7Oh20BzVuPznFmwbvw9EMtYmMNl8oKArYUvt/UnRCc3MY 2mfFiFqsW1f9brVSTnoSfCy7pGKL0oZG+MuVX+794VEQH9szeHteIOb+ycVD O7q+QrdQgOrG+6XZc2TDtolsdesLK5vod2Ds+ecOBRhhb5/5naMOp/YcusKK CK+0gg98tJEjPodG8nWFPuijbn/XBCywLnfO6YxykmOtuDayNrpWqq/z1HlJ y2SXY33jes9670bfUGJIHioNGbtdLzSOeka9O32jhTHHWJkXPGVPh6cSL8c7 4hVEN1p0JBNJOZ8vlh+EB2mPw4gYCUM2lHkd8yqLPIta+huXe1bwy/PLC3EZ ZCqV5YrU2S/2R/qjq9rXlNd0rKms6Vz9gJdrbMwHGqV8qjHZ1Z03ukaEkcDu 9H7n/tL3jLHSpPZOy6XCZNcnXcFHXHMkMkil4/AeUHgOAM6RCa7X8lQOtMWk +KAsJRLn4uxMR+RAsAU11uQNNjV5C00tXkfWbS/1KZhG8tbauJQWdNNjYCXU DgA5C9kJSFl8yX/BT6/5Iek/7r/m5/wTdPSMfCxR4LGj2QfkQzpc0G/qMzhS rYUVS38PX3BET+oGDlqHfh4WEBMWgFiT+8BAYfjfdFd/bBPXHb8739278zn2 2Weff5xz57NzvnOccOfEhlzIyGktGyVpCVsk4lADEj8aGjp+iCEQC6C1HfSH NH5ta5k2UW0dP9a1pAEaaLV2q9BUjUl0+wftjw0mRplaNKpl1Rg42XvP4Yc2 zSe/9+7dD9nvfT+/oMxtmbpZh+RZ3+LaxYbmYb5ElhQ2sKqLQeRFCfGzKVjS N2EaQaMaKW6GY8ykc1scIFl5oY3vJAohRKYSbIADT/3tgU5CCLQVTRFSayhY aDUikF45m0U1X8Q0ipuGVsLqh7Vfg0aIXy2sa3pKXF2ka9UaCbmd2Exg9xsQ EiGXdkJupxPCtqRKhnNzqFyWjaEgqFKYa5G3zbIgF+5UqUaZm/mWfL5SntvZ gWR37jzfz41I7Y0nR/YVF/ztly/1/f29+WXtw1SyGRhGaujMhrED87rN6Z8e 6r/yiw07uuIp3Q+VuLj36IrdSxd09o2te+bw0iN/5ple1SY/Pnhg1XPDHeva 1A+3vjx48A+VpGajyl8ANfkU1uTPve5hcpgabh5WR8lRarR5VOVsvVdfor/C /EA5zvxMARTZrMooS2Z5xJ45kMgRGiWGOH2S+sCTeLJIePFgbyQEXzdAvEXQ xCRleSmOxzzHY0rjMc/x2bisFVXEj0H0BKGK6kr1qEqr5ymLkGc+8wTEgjLm Pxm+fSKzBoZOEZrVqRoiPBUSrFBBL3hbCJXhAheviT2NKIp3hvCECvzeu3Qd S2y9B0qm+JH4EUorUA2lXB7tQe6/eAi5RLgtEv1aKC9I2lOD70MnaNd/hWzh T1Za5cUgLzL9078ebOmed2fqngWkA0Fpw5PkArSqwswVZhyu6hzy2XOEA+1u q112kO3NtODeG5TTZYvtZvvZHSHayBlmR67DXJhbaL5ugoLpmtSAs1XYGTpi vm/+K8/2BKFEUXpW05Sknm3VFFLPSZqS0HMwEkKdogyriW+F2eDz02jV4OA6 Dg54gFawgBKCyPOcF3A5D9pLzuEoDsYKLxyNIu3BOsSih9HsWSxIKfxLH+2t iA65yTnqnHKuOLSjZfBmZvBmZvBmZrKRyG6J3CiREtYuKYiuSSq6JiXtqQe5 A+UMvElPQCuEk0exho0RnkS4xtLVCJR9S3eMz+MgdPO65Q9n9ZxOsSHDNFqC mXZCDOcDhXZS8Oui0U5YgoHcLImBCh9uRRiFWCQ2I8iS951/lMW6k4da83Ag iGL8zSqQ72PySudAMbb05sU/XXcyCx/vpBaXB1uSzf3fHXn+949DxWFMw3hE 21z/48Wrrx35dvWfVGTsCcOotGypjy+5uGXx1jOXKWN3pg3WQQSmgTcRuqjI aX+I1ahxinpkcOi0TKpi06TvL+8ENUoGQWgk7N6I2yvWL136gLRLjgIToaiT Mie4J2QSu4kEdhMTnZUy7tts3HvPZnLlf0TuaLd03/n4ucS7qVP6bcCcSL6R eo85y54DMMYeY0+Ak7FjMvNDsD+0P3JE3q8z62Nr4lvpHf49OjMsL4sP6GvZ 9YBZDqrccv+KYDXGePoAMehbxnydZTJ6me6KfYV4LMgYbAFYnBWzZAZaTN3R V+mXdGacRX/KSxNBPeOXU3Kr7JNBE/qLShDqOOC0IIXwVxPrFy5cgC63Blnb dRUvSjCkQoRiohIKcvBmLa4q2uTMXi8sAzbDAQDdUBS6AYZlUQFX5Dg8i2sh aLMICrD8nTgZ/8SRPXm/fEum5RtOzIsNxE7FbsWYTGxVbFNsT4yOTVKfns3o 39dHX0wg8qglp2rXakRiNun27GUa2gH7BB4UoYogW/S/bRXSxubagw92NNBR b0GUz/sTETfkRVwapVfR5TjJhbbx8lnJ9VsSmr08HnLvpa0q9EFkjAVweXIk IiETFiOL1IEkG0JgVpg3FxmVwrRpTNOmmHxsAdW6omsOWSU9u3shE2D6jSa9 tPbOLvrAcFTLMYbBz2npePruX33hre3NFQGSAmIiZeYqGIMV6PrURu2d5cmu Qj4ahtXnhSIuZVJp3lFoIUIJHGHDMoy7vbgQ75dikmebQIDz88Dvd1gXRIIJ yQ3Ar4IKkePLsN+D+jTsvRtwMJev2Iv5Kj3EH+PZPFvk2gQrYElWqqC0WmZp Luumys5X2UdBn7BIGWSHwBBX9Q8FhlJDzmBpPbsGbBBGUiPKaOc2ehu7DWzz bxd2Bnamtitj6e2Zb9rP0y9zL6b32fucF0oHwavCIelQ4tXUK8ph63v2Yec4 d5I/KZxMHVdOpE82H7MnwAT3jn8yddr5jXObuy3cbb6dWTxir3VGSi/wdJey Qd2ofaOdXgvWciO8r4/v1xZZfTZdVZbZSx3fABjghgUfDQg/tFlp2W5NF7QS cAV+tuqbicj8bsXh07QQbqysEuGAQAqca0ZQ2cO678GFj0ofGxZU+m18Os3x vD8NfZeqcgQLgSCloopk2QXFigTgW0w1r5huqUtxJ2c2TSiCPzM5s9GLOhzI BAQhq8C7lVQ6rfJ+P0JHTEnDibTdzHFZx446jl1iAUBX0k4JnpakiGlZMFwS lOD3cxzg5/+Yfb0E9+xtr1JCFNONOy/f7pSd0p7S/pJvSWllaVVpEz65UrpV 4ko3uE/4rwnKmZRwnsoQKfLfnuAFBgKXAr7Ase75k9TTEw2gfVG7eS0pXkuI 9SkcUor16/dzCe4ayNsbHGsg78GAG3sIi/8fjA+3QAz2cPAAYg/C6D18Qv6H 5I9cGwJo1LLkpl4VNRkHNloiIvTiG1AoqZKx7CwcZxHZkAcMSck0843joclZ nOYqYKzyZTVanP6ONf3b6d+1TD/THogunE9+kah0tZHCVSsDU5yUTEoFSmzp KreTNEm1Ncv5L0EE58u55+6861t990f0ul3xvGEYTja3qw6ovVuWd+SlpgjH wqlC5+66Rn36LSducUGM6hBBMG9BVPf62mYVJUyDhAIxfZrtnmcZCNxiPqwT c+h8sovKU0mO5Yhe+EEliGVGvHsf4OKO8H8Yr/7YJs4z/H3f+e78K8n5Ev92 7PPZZzu52HeJ48TnmPjchJIsEDIoFFgDmUphUHUkYeuArqtZw6KM/UBa1XXT JNCqIpAqldIoC83+iLR2ajUhoQqk7Y8hJqH9tWhMyqa1W8ze7xwq1v0zK/e9 d5/Pl/f77n3e53lwU9CRKuFT6FtxVoQWfM9sbjE0oc0QqqZqVpkqLYwfxxK9 L6JTnjPytHom+3P5Z4nL+LJwNX5Vvpq4nL2qrSRWlJXU+8WlykfCh+EPpY+M 1eod8Y70qetBNSJqgiTKUlLN5DRti6CLujQQ70vr6jbUJKKqVNWrt6q232bx N7Lf1s6pC5ptSN3v3h9nHIlgwjdYqY6FhtKc2JbDydxz8bfib+VsmwiUbaGq 2eFJ5YgHxXO2sEK3IhziQna6FeFUMUVhaEFwM9BNeMRBYzlJw9m4pAmyR5DF CsJZscIJfJgLSfCUdDYDIKyUwgaLbWE2KAbCwZRMn6r1h4tZWRBknG3DOAud U6RgG5S0NknScnEPslkDlo1iEQqIhIJBjmPtX6vgioowWEwJ6/gZPIWn8TW8 iu/hB9iJl8lnZsuwtFs6LDFSD5IvyUReJr9ZMquvPwLW+iRYIaCwR3Cio9VZ GkbIQlLzJqT+L/g8PrbABzCEJkFFX4edAWBQKOGZoX1LGu6QtUEGvA5V2Mfi h9UT2lSVeh/gQBVZKGs5kj5WJJ0BAFhCaDIIkKHZ6jYSAZeRgyMx4jNSuo/O ry75DDnjo8x477rPaIOw5DICgki/fGC6RCNrFw1ZEo0iPOR6i5FuBBGYFILU CGojDP43vX7+QdZorQLBgEE+gMzv6wexB1ovzWDKuZ/P9WP8GBO3tjbuasxQ S8AM48Tpbx7YeL8U8YYdvP7n+v2s2Le9Hssrg9Mj2Kz//YU3niUnJwb0W3/r bHW35Ebwn4xk34Fd5K/18cVDwNHY5VBa/X7PNvxM/bVS2it1MorCCqF9X8Gv 4fmLz8IVk4so2+of4+6+jNcreD0Yplr848co7lsB91ctX3FnkUVYtBT6lUrB 1A8GDgYndFuX/yX/6dTp9Hn/QpoLskGOIN3LezOSPqGzLAuryHiJLY4knOQz 6WRGyen6k9jUv4z38Qei+zIT+knuJH8yc7JzWq/hGjfHz2VqnTX9Yueb+E1y Sf+g/U77PV06x83z8xkG8ySMG4YwlpLCMZTJhVHDGkYD7eFoMhXw+8HmtkH5 83Y7hYeczsBVJpDyaxlet2f4dCrAxgSMUCwWpVbS71t++NkitRhwsm7ZGHpi tlhOUDbtDmLZSJj7leUk35bSdBfEpoKU1tNmeiI9na6lL6T59DJ54z2NgiYo rE+qIfAY5VBg02k8jhvaCOgxb9uUgrZN+sGisQkg9TGINM4bzWexlCqlCZSW RTszMwhMB57FFAo3EEvbKAABZyjT0CFAS9hNdSENtKDfdRu0RmnhUklosQuw 0BccKS3L/+EesCq38B9CocO7yvUbkdSuro1V6lDrP3hC+1JbigxHtZ1bcBg7 y+19fcA1ub1f3diov/3IruIqKR7uSTgVpasrebA+hn95MBfpCtIqu1I/TqbY 5xGPzpoB04ER72BsbIohAs+loOocfn+IoYLBLDAN3cBQ5ZfoLwiMxEwzNcZW Yy4w5BKDmXmWu4bxBJkiBEjIsYy734t/cgD62Pj6DPV9ZVAHs7D48a3PDVOF sGMD3sxG2XondE9x3BP3wkGm6iN4uX4Xy/XjPN756S8gz7H6McJYec6ZSdNx yUGmHBgy5fgURgJrSxFGrDgwTRdjco1jG8nSYEYhWVZip9kaa6uxF1hyicXs vI7eQQRBnr/G3SiOnoKytFKd3NFIEzIbF2imk4+l2sh0ZrIV0izAMQZ5jkCe d9nn/1nfyR2GJ44+XGMWmHdQD9rCjDYY25QqJq3fiklr3Rvmc4rd5SJ7FDed VZA73+iCItmT99Fb4PruoiBYJ+uml4Igb92bN3gr8tkcXZnkgJ/k8ihq6+jS e92mAx7qNtvb6eiBr9zLD2+bUXqT2217JYAD1mzAuiMgKFG+3GVD2lplDdTX pGhotIHe1DboC7mt3sQaXFhNdXX1j6r6gXD7ZreuqmHzhCvy/TwRd/dhUYoZ tcoVx5KTEVXxZfRy/nvovOt8gWsXfSWhUqvYHJHt7HZuq7RV3l4yKwvtdmcz LyF5FI85R12jhbH+odLolqddR13nHHPOOVfLU75XfSRWOVQhU/Y86i3nOrK9 KyCY3cgNNOIw3BmX4aZrD5UKAqhRQiXplJuRrPCi2+YuA/J+b3a4jJ2BQ4ET AUYLvBIgge9A46Er1stmmcCyp7O1LMkWYN+WmSdNj82VW83i7JSC8k1ud28v bPy/4Q1we/Ir+ChKIoX+x2YDKTGlplxQbKbyQCE1BSsCvUlZIUNQml6ouZjh XcZHzWhYM7p5s9mQ+Am+xjMCjx/weILH/NDg0NcD6rhAq2xW3bG2vqYKGyot ufKGuimXhX9MQt9a37g/KazNVNZmQQSoHqOBHq3Rja4zbgy9aA3eVQM/Q6fN bYWBSIJt7S/2FQnnsDvthIvLkky4gsuQkKe9NYLE1pZYUwTLiQHWiKCivVfC hV6XGBEiuFmGocSVI7RJQRLQqGCAP7Wzs/Ps2bPQ66Dn4ZlZRPVCRbSYVkWz 0P8Wu2GlOUrughWWmo1+qZnyNu19EtWYLuB7yWX44YjQag+5DCe8yv4MjU6I TogOiA4DfYHY98M6FaCzhJwq9FLqhoaYkHnO629rzPXle/w+v8/rafP5aBPt 99L5tIcSOVB+vods+2Gyb8uhl6Idv/vL07srSopoKUW7dvHM+EBEdPpbBLe3 PH2ku4R/2rVzeG9x+9wLnuB3jw91D5/am1w4IstdpVxPb3bvhY7YE+q5+sev DrTxTeXi68M/wZPlYNeUMXIIIfLwXw/vMzfYHyEfSuJPGsh/N8pSBAv/obr6 Y5u47vh7d+d7Z/tsn8/2xY7t+A5j54eTOJQEYqDLsVDC0rFkC6Gk1MUC1O6P To1Dh0bVCiPGUKAd2aZVXVUEdLTbQBoZECDVprkrBcaIlP1QR6shson9AnlK NZiQWMa+3+dQVFt3773zPd977z6/HnLZEVRJ2IXsDQOA/8Z9T0WY4SVeQZ6r eL8H71fVcA2RBGcAE74/aDvhtmCIRFNOtzUkMNIFvO26lqlwX+M8vZYpaxeA tBD05/MymDIR4S+gH/bBvnUORzpFwiAj8mBYQPTicO6exjZU/nUWL6lqOuXn ggDEL2Ntav55U/g43Ens0NL0qHxGnmA3E+AY3Z78EjP9dXG79C1xr/SOeFxh PYwuU4L1npWBuuCqcI1KpKhBNIt+OpJFCVTjAujyCYfouKUaIMELVVXz9HuG PWMeqQSncY9IPJrH9LRBteyZ9jAPsP/sig5PIfWrxzmRkDzcX4A4c/mRCh/p SJe/Jnen8l96h1OjIWKKbpY2xTqT1rrCMRIJu9WYAq2EZJk04o7GSFyOmqTq 0EhCqOzaBYAHjIPPDw1RgJkRCrIqttCTF7D61GK/H0G3ZB6TdPmeN1793Vv7 j/e/vd5nhmNNXhpoWfy13MaDB7d2dDQI/5n85Le3v19atkyceHNNrZYcnmuY +9Mjiy/9cvwX0SD43GrAUC+4h0XvnFQk+sA/hFpZRUzIKmJE5h4gGymfkxWs YUuwYEkmEE9WHBT/dCAoDELl8hl0lPgiESQe5DuT7zpf4UCZOo8I0ZMoo9ua WtpJEt9ejecJhxALrJMGHAPyOrYhuiHGnnVsd5RIyToNW7xpc4b81eFcSnvo +vBgbFOyEC7EtodHYvv0bwfG/GPhd+hR4UTyFH2PXmQXI/9UbsRumrdpWBZ6 9Sf0/Yn9Zik5m2R+k/78/gwx4UiAYJA4QQFuA1wUrJIlEEuzTKvfwnmNWYet catsTVsz1qzlsZ6JX/dR30Uj5WRx3AsEc1jYnXoOJum2riRU2qceUAU1q5E2 YpMCGSZjZJyUyQxx4gWBHNtWu7tW6K+lh2pp7Tmq2vqsTImsyabcJtuyQ+5e 0D0pfIdwYI0U11byI8W5Yv5GkcMqk+mqVIpcum/o8xRzDcS3xLfFxe/FQY+L Q8CNzs5O2gkhAWFDQLJRIIkWzkVB984Ecg5Ny1GMJxoqY/lnWlXwaAYgVoRN SnKB0NFOONagXs/jIKpdsKptYm/q6u43/0Hp6b0/XdS8vM7vTiY/t/XRLx8Z 3fylpe30qYn3qXz9KvUeWJvOpkPbE3W9m48cvdfdugNmv+r+DckBCpUgLcLj 89hKZ21EVqMc5qBSqgDjYCNm3OCCZbhNlCU/4slUEWgmvxuu3rU5JM0w9jBj 74p/IXE0amjFEzpKlxawnV5hMBAkKXhxzc0iTxyoXFk46HzCuAb5oszBCRnj gXx9RYdexHSLInaNDcepHS/EhXjCDX/jNriGGRIKFowwiKUp+XxwFvAX08y2 NvJ7+OTkQVnOtnJVm8pUxS1TnoJ9Iw4mn5/qqoCygcABNyZJ9n75VE9PexYp 8vlMa3sh+5L0kmOfVMqeyJazzM6WsgLJGk2hzKBjUFmXeY2xNYya2aWuHtd6 1+vSj5oOZ1k5O5sRTJOY1ruAdje44GMrzD7zafMZ13Pmi+Yhcsg8xibZhSZ3 WgnUqyv1usCqULzeWBmri69KQDe31Bziq5Zops3NCdGdIG5LNTFg6KGCUTJO GGLCGDME41ZjvwxjPdXQ2o7l2Z4Oubu1e2dVHyFlzI3kIb/iB9IsiGMF5VHj +ki0hzJZm85ISn0qrTSaJCPBqYGlTNrkaObCSKuSmO9EhAO+i3SkmAd/Bneu GrEORtzxUBmrdlzjSHb4W4VPMSxc7C71vjZz9/0dfaCQtRkP9bf4LCPa4v7f bKu8Ykt2w2Mbx5/b+OzqR+998AHtWfuTg1wo71070hPzJ4u/pldXDef6vnrp 8h8B0V8EvRwQx0mQxMWX5xHdoBjgd6oPIEi8vPBywfSG2mxCTZAGgRANTrBQ XCuxYvv9fqgRdzTlZ4RpTGD4M/ZmXF3hPiadu/8h7wGVy2eRDdIit5sLAyZo QBCiKp/Pc1iDHWenyg/NOB4qkcMgR6LJ1UmsDqL6RAUfYi9ECGvMZONMJKwA wfEwk9h3pbekk5KIj2IwNWRiGuEcDCbqYJ5YhdkC7HG2UMA+FC55vYm6z1p4 ZmoaXTx/Pp/PPMLHCiNFuNsRfVM4HymQQvBD0RExYxDTYjnDjuUSOCpXd2+7 kkCLSHCINbTzywNNre1ROeLcEHja2FTzZHhjLaOiU2ZORXWEviCPCq/Ie9V9 2p74D4Xj4YnAH4SPfB9rt4V/iwG9wArKMMxu1Pkeu+SbZeB0zPNNQXQiT2Tg Se8S52qhx9mXWCesc24WRoTRwGjkB4GjzqOuc8qEc9x1Ufi7MKPedgWVaQab 1mkmFLHEtRuDRRtnMntZCpI2I4RDDeg5fVNoZ+hQ6HpICoWiv5covMFpMBAJ I2oAi6v2Gj2Ha/xUlOIbYVcUoyGa8xn0eWOnccAQjdvBYEmhbcqYIrQpB5Tr iqgptgIzUcaVGUVWjnlDEhlFXInNtt7mtb39XpF4Na/pFWe91IsjccJaervr uueTC2wB1s4VMbYU81BUIOdraDQjCKnMiB9eEWTt50OQtXFDCs4D1oNb0Dzp 7CTFPO3ecFomVBCKQ3xzgB+eyCcJg6e5kznVbsl54FDQcRpyrFqgRpyMVlvR 6m/zLVe15aq2nLxle525kBbJRUx/zgMHl4LPpPShoaGAXIM5aGnNvIPp6GAp C9wL5ED+mG7duvfJPS2J0OXX3771yZk3LsztpT92aJEtSwZ2C8uvvPDClm8E R/9M6Ue3KPvNsWUbFnbauyAP9REivuh4hWQEZZ7dqRbuVy022k6LjcSOZqjm lanibaQKtqkOa33T1pGgXp1Tn5uUV0Z7coInuZSFqboaQnyNvnM0elKXFZLt qpS1ctdURatUTamMcfq8dgG/53Hj+8CWJomP9yHQ1Y43ygvhn5RGyolIZWQg 5bmaD+P/TFd9bBPnGb/XZ5/tiz/OH3HOycX2JXe2Y+ccO7lz7CTEl89RhxAD gQBeIKOVpnaa4liCTfwxsjK2tZUai4lWqSaCNI1J2x+lqSluNQqbokmdlIL2 B5o20bIJ9S8yoa6Kpq0Je97XToXh3ve55/24ey/P7/k9v7/qTQSNxA/3fyP1 tcOhdO9R0EPcwOM3N3HdiuE4/EZotXk1TI/T47b9/kv0JZvpHSPqUS6IFaZi XrOsWa9yV103FCvHQJ46HTsdNwgWRzVgudyBqgFzjbbowc7AWuBOwBBwSXIL ihc4xCVjXW4XYzGzHAR4DR1+fwUEb82wvY5i8RridHu0C7mdLu6y04kkHKzv LyyopB8YqPe5XL2XUqTXfYKoVhwIh/hpR8lx13HfwTj83R/RDG2uV1Dz9aCc 3oLQJcp2CLov5h+XgYVyQEY75aHcDihb+BCEf9xyxOsLy81h2RcVqIhXElCD dTDVUHBBkeTyQqT1NYsahFtac3VqfSABiQYkFVO9YALl19zXjK4L8vCRnYdd 0VH/+vrxm0svHx9QAy19+WAwnNCFJ/SBnevLHd2SFB0/Yzi5f+i1j8+OK5mA Jn7f40l998Hofgg/at/uJP13qMkHqReoE/Tb+qtuX+Ht8GqaphSuaDgXO3fE QMWYBHP4jZAx1z9TXOw/Gy4VV4wrpostP+FXtNeHL06sTP105krLFX51pmb8 0FRtqfKfqJ9M3S3eLz4qPi22tYaa+zjNmw4WTb+x5NO5NspHp8V8G+Ufc7s4 p8Nua2KtVo/Ha7Usy8gt1559VnUDD8n4z+G15XCvN7mbcmvyu/IdmZZr6OrN 4/FlEFswVbfjue418V3xjkiLjTWkhyUizNX5Sh7ldfDmdXDluzF08gUv8taQ RfcsWtAFCxgu2MaiMatjaKxGp3SbP8/2+FHBv+w3+G8b/kIxAK5pagiGWMbs P4QOdXc7pz+mk8B3AWiz1DSd1INcEi0mV5JrSTrJY35N2jAkklo2QS/Poll8 NjugFYw/VzkvMT6r4ilgPNVZOwBpVg5GUZTEYEuruhJFM9FS9G70ftQYdeCZ MPRVFUMejH/pbpwwomdDxWRRL16Db24q4qVCk00tOlbemkSTHF40mQr5kNNX 8t2DZF979qXuwut8NlwY+Mg7+mqG27pnNYdyqSRdoA0FGlE0Rxto/Cn97Srp YVcaPx6Xydi4hc9Iv3yy+BH6Ieg69r3X+Hh8G8MCcvlWeYcYW/HyYy6+tE1u 4mWc/eNL3GOo3UDQclsNUtj5AlNEjtsqY9U7Dx2eD5OBJar3xM9FA/BE+ast KMri2CN/LoOnjIHnguIWMg6+EO7hP0Hc+am5gQlJE9pbeGQKy72pvpSaopmR 8Ew4IcfCx+RZAQmDAYGa0qZD1CjKhah9ppxAFZRpgTocnw2hcX5SQEcjcwI6 Ntc+0AbT2wapA6l8CE3ltbRuGAtBHh82DgnoYM8hgTrSdShETbSMCRRhEG4o jl9vryFo/+YXA+DjHyrPY7JbItSmswkOYlTj3NkEBMR7bqKfTqAwFKA4CwDv 4ExgBh7qbGgoBleeLeQfGcGySlNBTKX7ySrUARMIfWlqJIyY5+/gXps9uXnt 4sIf4w6aMdHO+A8yG78e/1Z3UEwKpU/3zS++8sv//eHSVJNLM59W41nUnH9p XC0cODPRt/ufnuTAS7erv+tT3/kHOtj1ixM/39BNjLWllTUx+0vLH3jDWa8r ZDbSJqu9dHjpxctzvWmel0etLwZTwc5Thp+dO391brR8fu3k6Nc/7jsuJ6Xh C/tVn88IpE/ZITn9G9Rc2rDS4Mb2jI6By7EulhAhy0v4nm/FNzyINYIJMB7p ROHxDhykfBizZRA7wqKqRRQkGm02w1GR7CEqPN5DqT37bxV7wdiu4gFlD2Ng PNGdhJTJfgoCFTbCAtW64ZLhisIVoVQgXqemW2GtlqYirvZuoxnCuqcHa0Fg 3SdPICgbepAUrdzGn3q5jXjdswkCceM5bXhcdWNIaqSFJ0ZU2BRv6YqwhH5Z QrksoWWWJy6euHji4vlMPxKJWyRukbhFOM1Tkm3A+LKKB8D4+hYeU5RMf4O1 CWk37E1cdMEpQEZuugiuIIjb9J6MHtPYzALUzU7ZGV7OVDLGG5m7mfsZOs6g QmYhU8IuPYNCFr4r4KrRTt3VoXQFIvkOtivA5TvFrkC4Rjv0RKcWSYyoAW0c hSJpipwSyiqXi2P9vGStsOgGi5xsiV1j77FGFicpWaFEKRFUCsqCUlKMy0pF MdxQEDCWcle5rxiVhf7roA65bVxQ4spyp94DL2MkwlmGXNksEYb445NU4W0V TBZGbgsLJr+AzJZWczumZwAtIeilMjWPIHnFMUVjPsYwxFzta3B1P5A1EYeM mUhD8Pb2p/ecoBjR9OKrIwdLbR4Hm9R3h5v1XpYOjidTr+Sbs5O7A/s6vbwz 2Nrc40Bu05s7Z85PHPu2/tvd38+FeEGSImHuIBp/61SPOrMrnEoEJcnDZo7R ++rqkYKyfAgaM+ClieowvFBHzIeUBETQjsPZbSfhbhd5HMkijyNb9PC0FRiE 5HIwHpHAt2IViIfB+PQDPNtq5/cyPhj/rDbg9mgPbg9uErSFaoCAlhlxUbwA NNyxCBheYBBDKllckd/CGzAdjAeqwQeQ1DfnuYd1KQlBVm8BEpAz4xs4xvaQ YA8RDIikxftUp6YaxshI3dD9/f3MUZ1BFHONMeCHUlRI7DB78PG2dQGvtFql TjvBg92Aw95O8IBPVscDj4FP8AOeW3UISZ3PYaCuMeHdH27mNueJHmlAwV+R 0IJUkirSNempZApJBcmg40bChNnbq5I+M1DvlWS975RJryf8rSoAxJPvsHcF 3ACLiH8kFBDHbX6bpwJHyVJUh83scbMVK7JmMQevj2m40505jf6ezWb32yVe j2d57GtND6gVHhV4tMCX+Ap/jX/Km/j1zvVfETjg197CGADq3aqXqcC8cDSu AQZyJPhBqM+jMsR6b6PsBB7xfBPXJKwje3HdFRscjMWGBn/kT43sjo0l2qzm QKsQdSCv6U08MBSLDe6KO6FjWQjk1qGj6DtXukP/Z7tsY9s2zjjOoyxSpk4i acmiXmyRsmTL8rmUHFuWFasVlTlyGkuJl1i21cGNt2XLgL3ENrChQDLU+zAE GIbERTEUaAYkn4Z+W5qmmYphqBEExj4sQ4a9D8NQbEWWN6PBkG5Fl8h77ig5 STFBIh8e704S73//5/eE5MQKx+98uVlG55znQLUpdL3l8+5BHyuCfDpdv4dX qEGzoCXPD9ry/JPls/Vpa1uizR69sdNkQyC4z4ZA8Fc2RKdDOukQnRNSSapX PAgNgE+pQOTXCpfevpGmbv2HGy1ZEtIWJtmC2uXqj8NICCFCn3Qxl/WQy2B/ FpklG+Qt71u9F4lgwMU6cSjQcpM4wq7BpFFKRgenQvQvCTVfuHMoFDFSWAw0 kNfyKByHRfhm+YIP+RrohFUYspfZms46TKJpYVhfW7UdTLUuptqErm8YSDbQ snHReGA4DIN2MRo7H0PFCB2My0PkNzG65uTQQ0ZihapCUaxwSNn/lalb1Yew +gBbkJ+KRXufXRJuRK4wvW2v1RUwyLzKUKqL5DmmDWaSSk/UK/f298h6D4p6 I5RyULt+gTQBBcxnBNOKaPkSGP2MbgZJoUBAHuu/vPiFxZFYOKJ+MRY0A0/U c47dHiKFpvHoq/c+3BeP7/GIC/0Lr/E/fIPEmIIQp3JcBwbfyzneb+mHhFn6 D7GjgakEVHZE7AgtVAEBegQ2uM00QgOL2JAwnjR11MKDDmaUAgMGk+V/M0DF ZbY5wWxzgkmdlE4AQdNSWJOCVL1jQNLC/YPsiyiy/xxoYYDLgva6xhktjOe4 gRBmPw2DJK92Yg+Tt+Pvb0sCrBDZJi2IeEw2Nzcp6j6FEWRzC1wT9Albl7O3 LvWk9+S8nue7BAXB+/XOH0kb7g18Xn5TPd/1pn4h/44k5UP58DHlmHpM/4Zy Uj2pn+c770W3dX6983veLceWfIe/I2+rH3W5imoxWNQnjGK+LK9J35ZdaX5I MfqNgXR+Ak0oYrdSQ0eUOaMjriygBfmW8rHifFE9oF/rvCb9Q3JqnQFF79X1 /fw+WXCrss8Txr1y1KsLRx21jqPOujKnzvmEkNzbG9WP8h0t20+PB5mmkeKQ kll4Rqcxwqdgb0hCKIkxfHWLbjCjG3jot5iPU2hmPg7Bp8zHTTM/8YRrGNZQ nrkBCYghjcaQJmLVFBnxapfPp4T0cDRkAqok+yS+MypRUknGx5PpUjY6PsWl OTf4TsLQ/QbiDR3YMIN4P0I8MjhD96GOJC9LihKUchynNdB9qxLEv3K7JQGU HwoFJXcGr2P+AUY38QeYX8GbmMdpTbsQRMGwnkd5QBsukU5zpmJeMjfNm6Zz 1kTr5obJm8sT+QZ65Z3YT77Ftvbq2hJsbKDLQ8rav2n4cAmIZxdzCvRWsRCi f5kWRSAcpVA44zWDxPtd5foZVyvgoEOwlQGUbaRs2scz9N51UazD81lbW11d 4pbW0BJ7cavcKhQr73EKbBs/1Cv6IFRe8Om1QHiDcp6necqdd9OTmpftU6d9 wnB6G9yFirUt2ToC61BpzZIdG0hmY92CIIo+VtPQjDNOixVE849mc1XuabA6 fOcgdsUG0Nkj3yzdu/elvkwi9ELzcwORweY/Q2a1aZbj3W7Za4S7h1SkOM8+ Wvn9VBfG/l7eMHhz8s/NP56Kpb1SIoG6fdooOtG8WZ8IokRCdWuxzzv2XZiO qHHqNM8DYcngNN3otTZfaYAXjK/8WEAiYp6BmGcg5hkIU8ymtgHBXVZh4DZC YQpa1DAg+Nu7dAx2/gLMwQUfkfOBQbh9fuYQ/m5ooBawhxYSqF0xEFozKFtP VQ1JH6Mkv5/lGhjGcSJioIPYZkEsidAfZUMPts2LBTb0YKwFngH/IuwRm3N+ tqFtag80h0bppVgeo2drb35yDGmXPcfHZzVkabPasraibWgXoaOIU1HxYB9K RYVk3J/0lHxR/xT8JFGQOJTw4NY0mGFLdnJsA6NZjJbxCt7AF/ED7MSXA09h i43vxcITUFlCq4i6HeOUZ9mkrYxTobHpZrFohr16MDyoItV59r+l+YlexiEO 6/y0Tc8siwgZx0+5BcdvW1lEq7Nqs27RtdJUtrRqrZJp+32GLihdPtpiyXSN M4T1IiO5crtXud2Ltlgx2qtcmi6xfiUmlBITSqnip99WaY+rtPNLpT0BBJ9a Idq3ItFpKoQNJ2w4ycECWm7akFPoMLj+neWm43I9dGK4vmvptGuOZ/d5OkdO ZXOobA7VoDmQzWFkWKJs7Fyz5zCG6Bxw/RfLTbsafOv+I9AozGMEQuk9+w9Q oDKm52oW7ZOuocO1k7VXa47avDA9EuwfdouFYadImWM7TTPa0hKA1eNN+mon tF3ieiZsSR2OoHfCzlusSiC7yi/A9DC7W3SKc7V5MTgyrTLFq0YHSyNEoDIn rI3kSuyqxK5KFfgfd5n4DWMRntMnbGuwgPaC4F/sbi63WKE5njZW2jsIgk/Y 3UqlvtjaOOruUYFfzj7wFzj2n28Ui9SUQb2XPDNzi+9z5Z3b3H74pOGT2bn9 bjgYCgaDE/arHrF6xsSb9Y8CjnWQeH0ZcJN40EYdGS4jFQ02+EdX+nKp6AgE lruvkopOH+xTU1Gt4fBeiZNUNNNweK7ES6loGQLrhXgtWS3NRWtTrlSuauVT gy5O7J+eX6AL0z+MJbcodDjF6fJIJqhJdaBPRU3EMgZaMS4ZvNFAWUvOpUyS mMjk0EruUo7P0bZAdaGUqFT06myVX69uVHmuqlT5Kuzrq/7AWHV5sd7gX4Kc 9WqwgY5/nyFpi0ihDoHg8Yf2qXCIsilscvoqsneVJTCGPPBwudbeJ6z2Ahz1 9yWw7OmPDyRwrAd55T5vfw9YglIgNpRySwQBk9YR5Atg0IBmHwPdql+z7WK0 nUuS4BiQcrQnPrLbLAri/698RtHs8a7nvjY6f7r7xNmZF1djAY80/nyz4JuM aVJHJDmf/XqF57v3lpsjlbzbGRs+PJ49+lxoZKY5WdwTZpyblJGf8PePywND x4+9MjNT23u6+Z15I6AnEpoSV2fRD1ZMK3vATZozL5vQCFnpCLSNWL3DuWb3 S+ORRCIyWUMvvzHc5mHMcY7/gJON8rtOlmVOlmE8PMKOXpcciFNLMOlVvPd/ ZJd/bBPnGcfvvbuczz9in39dLucfd45/nM9OcGzHARPWHAQKSQpJx1YSIJAy 1GqFLb9EGYySiBXWbp0a7Y920ipg2uimTl2CNFboVpa1HVq1pWRTN6n7o9of SBMr7qSpf4y1mD3PaztQNfK9fv2+7715z/483+f7JEyRSpJI9UCkeiDKCbxN VnFCdmGcyw15gs4HVJWg85GVwuUyE6E3R+hGEbpFxFRwC5MaZ7NhkM2aRaOd msiZqG0OvMNkwmyiE4XEnqeVWb7QfBUSogRXG1xJnEl4EgWb2s5SLcnlICfe uiWBQQZEPmuN79MPCQUEG1SNVdnYl5MxivGrEb6cp316gHxtf09CpNlTpEoh UtUQZRaHZDokizgky6UuJkJXRuhAhE5G6IPiqNmQCxPFBFeYZqnrnimtudLV nJuDx0JnWqbOFO38+pKVKYkljP/O0nBpvDRZmi81dfDEov05+LRYEhZLKyV2 sUTGYWCpxEVE2Yx6LnMey9tmmtHEQJtoRt0D8YgZjYNAWGvieSOzsTOa3xxm 4oUifeJEPO7xuB0tcsI2L5JFkXjESfGceF3kxcvsG1bILEYSGc0cNsfNSZOf M+fNRZNjTMlkTczjdgh4c7wLQh3SNo1yiPE7tfeGK8WALpdXQ5kGsk9p5QQ+ 2cq1hEmToDSpjTCGKB6bghczRsADYCR/LoDrXhAi8v7BeyagSAZ/9P3Bw7rs duY3VXv8VtHBb9x+9EmnGwMx8GDeozXisPLm4CMbTlSP7dJaw4mEkfIMkaNP TZ2qRsbkCETa1oPkSxe2qRhnLIj2De4KxJmHibCueqSFwQZSR+eidq5W00lO J7Qqj7GDk9ix/DjI02V8S1J0Skmmlhkpv8sUXPBdDU7tOI/rVLw5hEypfIAS F3BJ1MFJ1L7x1Adgl+ejLpcWRbBoKkK4IBfRfwIbW1t8c0HyU/lX8u/JO/a3 I+/bBd8/HWSbfYu8K3iaPGd/1vN+yKZZhRKv9QF25zRyLfiOyloa6Rcbp/Hx +KNnwf8PAYo8WcF2mB/nJ/l5fpEX+FsuCyYt1zkocfqifYNKdof08XR2e2UM Pd3gYnrn4OLww7svuqL9FzW+/4u7R95gXHeXGB4u7e4SpsC+kd8wKldgeCbA FW5KN0P3fYTsMFp/IICom0R8SXeKTYZTjqSQ8noCOhMhqk5kO/QUG/T8zZJO Qhw0QWeLzrQ2QVMrQFb/IG0Q9JtAHekbsbxH2CPCccdx93HfN+QjypGwODYK hRAUP5Y9LHnLIbiC8KVfdJZxp1FAtAB8BgQh3makSl3d3S1tghAM+JBJyBws s3Ly0JPXZ68ff/ypP+0sHdp07tSjJ7+6lVs4++2Fb346d+G7r568fXRj79kT f6h+cP6tj58bh6Lj7u3qAPc6sGYwZbatzprZY6GqFhwZfHMIiJJD8bcyOmf6 qQb7dZmaMxDXXzb8GtVdHSFqpsaOS2d9vFtQXwdtbcGSA+zHmqS7e1SwGVSF GarCDAE6QWHBuVWo4NKUnKsJ7dKSdA2ENUeJbUjrFaZw99NLCGLBgUwq2HU4 etbD6Si3fqqRfr2WAwQ81EdWiJo1HValBbfBkFY3HMaJp8ED4C/dK9WUkdQU E8RzpSaey1mk+qSjB2ktS/3SHulZL3+mnfS09/YMtu9pf8L7RPuMeMx7rP1p 8YLtpnjb3tzZM1Ic7TrcxVs9JCdyadPnB1vVeqbND+bKiDNGbMiIMptZXzbN 8WukboInYW14plbFXchrjnkHO+6Ycyw4OMeHOuu/TB63Qro+HJuMsXMxwsSk 2GJsKbYSa4qNr39zsF7MbJCoKk5XsKCpwGNNe1vKUl0RObeE/ocSredKtmYx 2ZVypTqTJVtBJ7lmaIr2bp3knWt0hllFF4RyanqMmRoDBLlkMYhOBzm0UQ6N hoEpymvvFUhNNcEEC1SqGx2WqKmtzw99Z+/UM5OvDHSnCy3lwareutbwB6V4 VEmSLrv7azsPPvDwXmukM5fgytN/O/bo4affq/xwNujpqN7cV4wmk0R25g9y B0Y7Ffds9ZWJ+PqRHY9d+cvUDsUHLDObqwM8AyxHmCx5r86ymqJSmQrK+BYU iC1KKMLEjTWJF02Em/oQN/UhMPoPqqXQ+e8lRNrdhASLQKxkiwieqC+eVARz 1Oe0uWvcADLgvCt1e7CcXaLE1qBZCmVQQkMZ5DCUQQZVjxp9ROJIB7XcumIM d7BWx1zHT9LnO/hOtTPWm1mXHZIs1YoNZbZlRzzD6mh0OLY7sz87IR1QD8Qm MiekKXU2OhWbzZ5Wv5d9yfOC+lL0hdgPMmezP5NfVn8efjV7Rb4KJ/h79lb2 k2xG75hJzqSf97/ofzGw1GHb6SdtotuM2ow2YkYFIx5SPFGNi6smwceKJyOK zSa4QyFG09yIXY7RyDxhx8kcWSAcEfEpyIepvBQcDrK/DV4P/jvIBSUcDfa1 981SJc5OTW+v3MmOYXrGIEIeN1R67yCPvnI9NyuJtL8l0ZLSmbQfmqQc14kR MPUae2izQQ8BvnVZZhoVkKyyVqCsoRKCEDLUf6/lauyBIgJ43dwhpThQLfjX RQLKnmf6T/+ZBN4qj6fWl75lHOydPP/jmZ693MInj40Uwsmk5CyD9T089J8/ 3iRJXQ8n7uTILyBfX/3dlaUiA863GfB6DchKk0t1rtIZqpGC1uI1qDk1FI14 KVmfqXy1hq/VGo5UQzXyImJaAOnTqIXVaMVLFxKJU+TWXwN0CpMC7NxDxoQx a3BG2qa4OBCrZaxwK1Dffs6VSm9fazjRRn6P43YpuHfCPmtn7bCBIsBJqVB6 aQWLZ/wfFUro/IsWodh5Dec0LWPeM5OwP5PrXV4eW/WQIWsCyjdPgS14LNby nOJtVobszxANVY7Wi2fihqFvTEWNzYzDmfEGdInwypyd2MuSi7hGOY6xQUW4 XyCWQIQ1WoZkGG9C0zSdzOnzOsvoElSIS/qK3qSPmy9/ncK1WuNN35iapmRJ lenKmLdWy5WZhuCBx50GfweJM4jmDlIn8FKvuup+rlGk1R0deWjm2NptXYn4 rqAv2NHpb970QDX7YFuro6k5rmqGgwS5hXff7Ws3urcEzH3V/ocMMG8JmdZT Xzn/hTAaOODl4N0b7F+BlzzfVefFKFJeiha6M5Yo/+e7amPbusrwPff62vfD 9v2ynfthO9dfuU58Yydx3OCqWm6h6SelRSDaDEyylUkUBkoDY0NrwfxgpWKi gVaCLICnSkhFSKwLa+ptyppOEQx1oZXoyvhRhlBUFakeYwr9QZWW9xw73faH Kue8595zfM7pPc95n+fB5490fN5IskzOCeL3TkraSD8SJtIh3C8NBjhHSvnU Aou+zaLHWcTmSgihvoDxZBIdSqJkzjbRpDll0qYqUqPLtRpooBJECDUg01EM EdB9K9dW5GttJn2AjqGU5HC+vlhSLbJ032CgPY2h7mHRV9mnWZrN9QW2JdGX kt9M0smcKiK8w/c9E6NFkspDJhcmLsZRcXCc8lCHMZfbcRk0VK2Gi7y8XBuV l9UqdMCmMHR6eddwaVUtemLVzYtVPTIefLhnTj6dZYWAkBd6J8tT5XrZL5Wb yPaOQ7q8HLocXs4u5/6SuZ79q3vTdzNzM/tPV1RH3Zr79f5j7kl0kj7J1KN1 s27V4yf6TxZDEpJogeGD/rjgvpH+Y4aLM7GIGo8ljF7LneVnhTn7VOZUVlQL oby7291Xnig/1fuU+0z4bOaF8i3mZjzYyw0mqUU6ibpRCdGoiQrz1GKxiUxP 6dOTxqKVNLtNJJs2fDncaSzGcGdaVbOZkOiTHBLYJPoDVSz1DVIU/qjmdwxD bzLbvUishD8s/aaKkHol9U7qXykm1WQinjgloUlpSpqRGKmJNnmGYxrFbg5x bsNBk86UU3cY2xlwaOcVZFNDyH5xz8bl2NuaXiPmaL32iYPz91OoNl4tga6c v4+gCdqgtQr9QF3YNq3KbcmFK1ClAvi0bEiMhELi8XCxED4mL4/rlHx7rVWb RnJrrdVuk2YbRC8VbT40TBXGSU6P53u7bVnxB7qVVBz5e7k4XOFknArk2Tja SOzYe8Fa/N3AHfmOcjfvq42jaQquKrw0GqhBN5iG+FxoJjpjzlgz8dn0TzON /iDI4wI6gqkAhomlTCn7Q3cuO+eytXEsmpW8bVT5vFFFnlCloVhgIeaFqomd hCFUi/DKJYWvBuWkOhq2cQUSct6qkmBUsyAK5rVqph2CEBa0qqtr7bnU9lyS CkuosIRadW0V/+Y9T5JgmFRl5BCsE8ITvOepIVgnBGOg6AopVOH//YNvM07S lZLpMFlXrKurnbeIisooZayqQFT1ZIkFwEoM+1R6JtXz5Be2f87unvjJ5cUn Pvt4KtoVSqXiv3x07MAj9/7W3z/39Ka9ZUVWg8wL99449ZXd/R/L9xZ3HDpz bDYpmGjHsz/6dHXsizObqweO/KxLCuuQwyL3/01v8V2iLLTeyWG5hKdCDkt4 OEGJQR2zVzCqIVYjTY0QmQa6iRCehpmPmAX8LYL4N5rIuVIs4msia55CfmCy 9asrpdZyh8NugNovfTQ/GV1BTEMxUkc/1IbzuPUSkVMbDQPruQhuTYlIlCwU PRxBuyKILOcBFGFt0UIsMQcsh2mOJSzIwgbfJVPgnRL+g8Z/LxAroSXiH/Bf 4eoK9oTrV2u1JXlFXq4BwZCdw7FaL1Mh2MDWYHUCTdD0aGJWmTUuRi/GmsYt I9BIoBMm2hfcF5oIToT+o7N+Pao7OhOL6obJIFxFrOcREx3o7JYZoGnkD1bw pmNXou8QjfVYxHqTEpvotufaQJ7FUuJcgk5QCPl8bDayX0N1DVGarJ3TlrSr 2t81vzYZ/82JDWuwjm/7Frm2BtqhBXliCzW6voqpU25B1yoC+qSIOhscALFP NP90AYOxHM0oRFONlIni6qkomcom4M0RtPv69XI+9ZDiZOrbigf7fjzyjf6u Xt+le3/evv7b8Yd6848eKk8cor+cih3e2fMYZkb6/iqzzpymcvRAB1Uxx8Po 4TqyXLTz+NF+oIfsZMdhrnoaMZYmGWiqcTxO3YCbuuFFobF2Hg9UsxvWM6zn /KId1v0JNywGOLjD57H15ASqdKOwAifalvC32zhcKZCwdKPwYR11IOBxk9wU x3CCaIt6OJvrglnbU4odTSxg7CACKmSbPvxkEollCvidqXJcj02QZ/uJMbV7 YLfvE+ypWB/iLtwg2FNVp6eDPQXXUMkr8ECqJQzEUQAhEWKgB1cwo1aQg12F 7WB+OOf4hsWR7s32zu6dNmty2j7sPFP7kjknwzloayDJbbPFXIJrojFPE6hc DigJ/3/CgiiIYsrG2j9MnUNIQlOoga4gH2rSi15ONcysqu7XZjS6DtU5jcGg szuwA9D1vP7dj+o0oCKAH6CPwngbbQOxhXf+QKkBdchWXFLikhmnZMWSE3Gw cfIWYAvwADUCxAixlF1sprKBQ9BtgUqqg054cirMISkV63bC997t/9bRsb1H 3PjITrR1fLTwtT3Vh5nT6281dsSVzJHX6x8ff7aOZrcOWSi3Plffv+mTdOBT I3QOMKoARluAUZu+1MboAs9TpuqPvAZ4UqDYUGjmHy9SkMJardu3R0vACCU4 gA5WBnWBtzieT6fgd2Ikhs83ovkV4v8U1U+TN3C/bdKw8TwrhQ/+VKJjSzdW 5BvkWHn1M8JB/fMGAznu7XmxksYs9Ei0EjEiZoZPCynFVrO6bdjmZr4qbFar esXYbO7mdvHbhDF9zNhlHuZ+zs3yvzCfsxrpX1NnuV/xZ4wz5lnrNe48vyAs 6BeMV8xXraX0W/od4Y5+1+xv8Aiv8ruhyWESC4PtmOxtxx072tFx2jGTaUdF IdHzjPiwlD5KTaNpeoo9an+P/b5yMs1v5oaFYb1q/d6/lHrbDPxAOKEfN5gR dadOa3okqVGWnaRUQUnCLXjGc3nTsHXDGOCFCM8LlmlmeQ5aXMDP+nwcSDJN BdlE+U1D1JsI6GlCQLKQFRrCgnBNYIVjvIVBLHv+0vPcy9yf4PYe440nzFeR RdkUD/uV1GEe79tIkDg/VMHhQrBC8Utgl5ro4oKcRvV0+2vAKBwXJG04hROr IRfA6K7VcL4w1/WbBmBeXzNbOE7r/2O72mLjuMrwnNldz2Uvc2ZvM7Pr3Z3N 7tw8uzPOXhyPZTSDmqYJaRpTNYEErVKpDSQIqXVESFNh2RKidh6QJWhLxUsq HhohBE3iNBesClcyUl4CeWlEI1XlwS2tiMFEAUUidvjPrF1SYFbn/P85c9uZ M9/3f99q35qE3zph19m+nJqNOXKY2KCrVhFeerSHigKqfXJLEYSfvo1OgL55 h1fzSR/I69MrELk66GUwC6BSeAgBn/FYFWQKNNSvSERMHDqUqeb6QiKTAdVg gKzoVnMD4IBQDem6oRsienvQsHLv35LY+LYOsjvZ2uDGorVxLW9WxFbkVU1X a8MbA3RytJTihLimRcXyrgd/jcRGXMyxgJbkw5XYJUBLI3JjEy16tSym6MZV wrwUp8ts1NQqA8IA+cx933UlD6/fhG3pEcxco3SonjsJ78mDoaUIe/BJABC2 38s6F6XM8OKnG6hBndSQFj9pIjPev3qj0axWnSaBDnAluZff83v4w154MzF0 HeFbLV5IO+QjHfS7eQMMpqgZqnPEOc696HymfWbe1+6bCXLAxUw3PO56sdKp Oo71/EhJUSrFGnaivF7SG7qnH5DOSefkczob13bUdxj7qSfRPmYP+0R9l7HP 3GfNMTN4RvyRNmfOWTPOz/Cr5GBtEV/Trpm/da5r180PtA/Mm06FikWZgVxU 4jTG4MwBqys9hh8TJ2JPMwflp60z8Xk8J59RztTmtDl9xpFmuVekWT2S5A6h U/iUGAVMwGpqGo8YQAWWxDJWa9WySlmNMiXwqbJQUcrlCoBqgTUNKKZTQSBr dZVlWI6pW2bWskz4GjRjmOWyLMuBOlFydV7L8rxWq9eHZSUry4ql1xRZ4gF/ PKzDIroDICqjOwsVJIhkhKkUaBOoghhXKqpK0WQSUQ04BEAqL6JvUxrForcC wQzgz9brZlx9IBzlwVNduLREHbVqVxEb5IKiO6GgNxX0rvIH5SNgvR/XXYB3 8YoqaAjDohMoxhMdbRFhSqdygPBEwLtHdBToMzqtg0C6xE0ZLvsbgDkLcopX KRPNmGsmbZLaD6eabzKEGIoTFpqxEGVhS7UC67y1ZN20GOvZ5ueqafWe3ZtU CqvrK2B6JjexDVMFmIDd8koBpBRpBOwE6gWip/xxIrHGN3/9fLXvswD9fRZI AQuwW3TAPjpj/z9i+N+ewew4Ox4SxiTqAVOcIBaiZxOu0HE24RNjsgAxQ3ii 5EmPhCwJaxclTyMhF44u5PrUQbY+cwz0icMgPNGnjS0i2RyjWqTPI0k0A2V4 +Xcd2ciPo0u7y1n25ntZw0PVr1kbv7c+3viHtnG7NDoOfBItD1Ya639Hv5od l1IRTYtIuJbNrd9F/xpRM2Va05LHH/yF3rN+JULvaSeJZixSVOTPwDCjkbub mjGh83JHjzYpuJQLPHOpmcH0KCSXqWZZ7BON6xKWWQq70OASsglm04/zaD45 n5oXZ/XZzq34Lem2cbvNCY7Oa/F64gR/Mv5Jixkcc4TDI1HHj/nYF0d13/Q6 w2N74vvxfnFXeY/+pLm3E4wdVA5qE2Mnmen4NJ4Wp/PT0mvMWXxWPCcv6uVU TMCCKDQquCJWGhZvSe4Yj8cOcIdHJsaim0qhDv/79CgaJQ/yPRe5jt6R+Sjl kGcoO6WS5zhj3hahua7vkycJGW2p35Nn+rkO2JTyeaPT6fLxRKIN8oNhFL3T 7bS7Wno+74pI7IIszSdKU8pEGZVd7YXadI2uzddQTdEcx2s371qW0Z6Atz3V Rd1YjNEUhql3tWy3qyXyhjHcTmTb7QSsvMwlpLahKfFRV5f5SKLDdIVBNFiB lXAdsgxQwEWRVGUn2kTNZrlc4hMgMd95IY/yjnYVpRZUBSmEVxO4GyjnlT8p a0qUTJBqrCzSI1SbYtC3LnYdA/hggWqj9iL9HuVRY/S+heoNgKb9z97qvVW8 bvfsyVXwM33s9baqLUjNsMPjPSKkQmNDoJdy7NnUVB9oJEFy2pty5Tt4pUfe 8Ur4otNez+3BDA6H+Pt3IGNYPJ4an03h8anlZRKW2WUGAguzhwCBJ3o9Uqon qUkA3zUqDpjivThYkyucJ6nltA/5pwsQc8SkcoOinwyK2JfJLAxIDDJSyo8F 6bjPyNCNkGyMSBGIlimQq61dFjxNFUjB/+NFwWMIkAWvBeFyEnYkw5lASHu6 SpoIcyI5DyRjKBIupvtB7EuGYtLD8AJEaFKQ9jAWPBFaI8h5mT4r5PshTUph zivAKMjkvBE255nDWc+CJrJ5jwsvlvesQISW81qkwZ0lcndo5PQL4n+45Ysb 9V9j9IUdIQ2F+iUvSTsI8WzpFyaTz0u5ardFZg2DUFM4JrZ0B9E5RfS2Va3F 81/eu3ubjka217cfmFp5Zre3MdFUMsErP9nZbG68Xy/qh5d+/ZWvfgmIaVCS W3jbsWPPFXIloCV524lzG1dPb4/U69mUJPWWl78hygZdr8eypVMPH3xnB2Al sbErcg+YqUVv22QmUKf2UIR6yUBGCRyDTIxolhCTGKYiSekwpUnaCtPW1S0z Ya/ad+Dnuzd6W5S1yRRlzqZKWZF+uYVaVBroofYyuYeQzbYpqtP+XPR82FsG XxhyA/FX24fP473PfP1dqvjwPqU8XKMKQPQ8HoXtUDH4JYfh80rZr1l0puPk nx/5QeyHAzTHxdKswhY4O1vQuXq6XtDtUTSS7hafSB/jjvHHlW8Wnisea7zE nuZPK6cK3y2+1DjDn1HeoN7gflp43V6kbnY+HqiBJrHtxtAQj0KlrhB532ht ynudVZVCYXiIz8IBDdsOhb09BKcMFbgozzYgKqA02NqmxDcIYaTg3xpuzSsJ HUkqKEQtFOd59BG/xtPP8i/yf+Mj/JTP7eeOcBFuCoxtKijZtwQVCepZlVbn jzSQ2/AbdENpd35RfQtcqv0UKPV9K73JlfV7vXtQSdefevzozk8o/9/sl3tM W9cdx7/nnmu4ftx7jWP72ryMwQZjY2xgQDAvBwhQgglJyIMkNEGLS0lIQkjS qOmmoVVZqzTbqm5qpKot3fZXNLXVmshjD01bm07VtElV1T+ibWqjNeseGlMV pazqAux3bWeQLVm6KdpfPvbn3N85vuf4/h7nd85NLF0LZdKJ7oh0+pDW7Nx0 1VPLXTfq1c2ZHdNTQ+huR/H0WTz9Otv4uaaGei39JtvMKtObroV91xEOe9// VUG+VB5iQX/AZXQvP9X06pbWweaotyVgKu3zbVj+vup1W7UGiuGqkqqNy/Xs 0+qAzWiW6bDu8iqdN4+cebKnJtjgVDtG54SLntoKi9VC0VtN++oURa+DXYhH bJLoEufEOXlOuSDOi/lzGpO1k3Jd0zB2qcMOXiRqyjr1QXGr+r74tpqfjcoA 45qTq4JisGwysMcMbNiw3yAYopa8HpWdUNk+9agqqFHBhM4lSpLpSs/ImTfc Fnq1xaLVusFRCvM888XrDYZLplKzqKiqj4t2zkVuFkSVWRRN1v9FHDYwQ1S2 5Fn3qUyNMsGk/kjogAJR6IjXcFY7R2rVDsssKsflaZnLhRGtU9uscc1Sa26E wAS3U/tWZgsZunEscePakHVskQLgxtg1K31oH1maaUtXt55Rf0yC3t2e+OJl F7Mu0DH34+wlnfoxE6KXtHTeV1bejhspy/MoVaIesDIJalxv+Zwt6vzKb1PO FjFg18UrKXuLOG3TxadTthbR5dDFP6YcJKpp8Xvq7UmTMuIo495G5i3Xo6ai 2etg3no94fG95ptXhP3L7463rSsSA3kcS8+xoclNmtXM3Mt/8PGgu6J+YNl/ 892KmrIJOlOtLLA3JZuggqPkBxB4VdwEFBrYhNjXTyff3w9ZFxFJLJB+3kav ZPvbbyQ/e3MAArr5BN9mOAQnwvgyuR+K6NL8RZ5AuVRgDsTLU1pB3JyCxsEj tERVv8c/6+e06wfjalHsJUrvb6iKR5lVuKL3GcXYq3Zmd9dG5tmJi96R3ZkV mVhYIrdQlV2MnQk6YNN3TehkkhvLnFH1RdNQ73TYs+vIf+du1rtr0GSU5Rpb dftAc/fUGWFPMm42W8w1zur2xPqug18xHKquPdBaIStqe01044ntB16urIzt 7ShWFGtrqK5/Zvvky1hZuWUFxnEZEL8D0nm6brZOABOCvBp0CtfPrT/jSXad bFWIzfESo5uymMFqtCMlx+28mIxjiKmaR5ul6CRTXLS6i4p/zILw4h3WjrQd EktjC6vpKKu4nlPW6ducnkMqyvMzujVnFM3P++uEv9BsUcy2woJAhycY6z40 2sqTkfbGykaPquYb28L1xZXHRh4Zj+veXL7Mt+EtaIjgqXj780XP116IzEfe ivwpkndaOamdVc5oostdXAUmql4paHGlgnGfGSlb3GKu6yyODYeZGvaEZ8M8 nHbxS7QnvSHGVIfHMevgDl0v1R2tW+tcXanFsaWxmQVabgvX6Ktrtdanx3T9 blcv60bDXfqPJztNZtnkdDqDbYnmrkNPsM/vTJhMFtmpFZCrm3qmzixfDraM tZMjJaktFO2f2Tn5ii8YTrZWKLIkdYSivSfJ2ciWR/4dduQOXAcE+k34ZBX+ LPERRUU/8cMMhheBfLrfOJjBdGUVy18yyF8AlIE7Y30HWLcIOKYB5+8yuJ6h BXsuQ9ErqxRTRHrKAO9uoJyezTedocoKBGmRh/YD4YeByJ+Bhp8CzfNArDTL zzO0Tt9O50FgA83dYwF63wMGfgIkuoAtvwa205w7aZ7dAvDgFLCf9E7agIdP Awc/BA6/BkzTuJk24BSZ8tEdwGOfAl8KAI+fBZ70AWdJn3Pv5bjffNUJfK2Y 6Mpy7X/j65/kyJEjR44cOXLkyJEjR44cOXLk+H8CAQx6sYPrEisk8nDPwmHQ LyazBVCtBTbYHU64gCKUlKZv8Pkrq1AdRA0QidbVN6CxqXl9S6y1DR2I0+89 G3v7+h8Y2DSYGNo8vGXrtpHtO3buGt29Z+/YXf4xdfES8Nq9n+w+FRFXqI6i jCQr1eWoRgSkBtajFT3owwMYxij2YAyn8Qy+ifNl9jJ3WXFZycoKjdRHVJH2 dekRMWxAL40YxNb0iHEa8Y21I1Y++M8f+GjGoqsvXn3h6vmr57M+++8Kv+cd Eh7KzswpHpCVRZLtWTmPpIAeKaKRegJoy8oCFBzIypz6Z7KySPJzWTmP5NeH Bvp6urpDI5OHk8eHkqe2Hj08fuSz9mEIA2T3HnShGyGMYBKHkcRx6k/iFFn2 KLXHcYSkJCZwElPUmvnMo+73fWQxQwDXyUZHabEIFEUR7KC+X1B8cGqTcdjT 9IskkqS3bl3xkGAj4/+z/KubOqnQGirDeUmf5peSwo9nvSV8OPGo+NEL+9S2 jyW3lL772x+UvK5f55+9tOfvJ5bOWWOSQk3df+mZ/zEA1mqN5wplbmRzdHJl YW0NZW5kb2JqDTQ5IDAgb2JqDTw8IC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNl UkdCIC9MZW5ndGggMjU3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAESQkjY BUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem 0+8f7/c593fv793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIR ADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1 cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKj MPFpnFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9n uj4nS4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeurlAaD MEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNFocHBQn8f0TuF+q+bv1Cm3s7T k8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+Hb74zn34 pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iav rqo26rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr /1MTf2XYTzQ/17i4Y68Br9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h 3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0WQICoAIm4AErYA+cgTsQAn8Q AsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsYA7vBfnAQjIOP wQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEs qAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02Ee bAe7wb6wGI6BU+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrC RxwRISJGJEg6UoiUIXqkFelGBpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKa i8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmLCCpCPaGLMEjYSfiI cIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIiRZDS STKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAo rpQwSjpFQWmk9FHGKMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZE C6Vl0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/YTAYboxoRiHD wFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXm IxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPO Kc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J +SQf4bvxpfwqfh//IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbdlgcsr1m+ tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsctLlpC9t62mbZ Ntt+YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6K mWMxWBU2hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4 OLikubS47HW56UpxFbuWu252Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj 3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7BXmqvrV6XvAneod5a71Hv G0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8tEUeULOoQ HRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgf vD/4QYhLSEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8J v79AsEC5YGzB3QinCFnEjojJSCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3Yjxi KmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdNxHPic+OH479OcEpQJexNmEkM SmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPqmapPPZYGpyWn bUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3Z T3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzC nYWzi+MXb1o8XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxd NiqbLZWWvlc6I5fIN8sfKqIVA4oHyghlv/JeWURZf9l9VYRqo+pBeVT5YPkj tUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3 WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3ahguN no1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2 yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2 rHndrej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3RG3Y1c/u b+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8 mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj 5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24 ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4 WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lb w1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls 2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5Pzl hOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy 8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+ S/7c/23//wIMAPeE8/sKZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgMiAwIFIg DS9Db250ZW50cyAzIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRv YmoNMiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250 IDw8IC9UVDIgNDAgMCBSIC9UVDYgNDIgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgNDUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDQzIDAgUiA+ PiANPj4gDWVuZG9iag0zIDAgb2JqDTw8IC9MZW5ndGggMjk5NSAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYRX247byBF9n69o7BMVSLQk irrAT94ssnCw8RgYwXmw89AiW1KvOaTSTUrWfn1OVTUv0sw4MOAhKbLrdurU qV+3D++226Waqe3+YTZXU/zDn81UrabreLNU2+eHd3/3S5V5/m2qfFY+vPv9 aaYO/mEaT6fTRG0zudqo7eXha1Tt1WytnkfreBZVZX3075Xe18ZdtMv9WNVH o0b/2f5TzG1/k2/ndMqkvaRjcl1rpZ2hkyI9msyi3KhTsytsVlyVPmtb6F1h YqW2OLHaeePOuq7ctf/gKoYmsDSZxbO0s5Z01ughWdNNXYnL+HIab6LaZrqA ocwZXcOwqzLjvckV+4XbvMlqL4Gs4vU6lWDkUDlT7V31zPE6feHv3tOdN+oy WsVpVDVFrg6mNI4tBV/lsFt/X2bnqM+Gj/ajRbyA04uIwjYUttIZ+aqcPRxr r7T3VWYRRK4utj7SV8/ImtibkqVlb2nRW1qIpfvs1tfTKIVJC1PxOpIs5aYw oajxbJMOCrvsDkwCPg5wxbc+Iu/HCuctI0fn4di/dG2rUp0qShIicnJuEs+S /tjZrD92GbJdV5yQzx8py7pWdgi2yTyNk/nbeZ2v6JRoGChqfLY5XJVTOXmj 7Z/kyjRtQ2Tw86fK/MiKxlvUJcQWHKLCjxV/OYtXiwFOuJaRLvPWhEXRjD9V pbeAttpXjr+bzBfxanPvfNo7zyCO/FE7Wx46o1Luo/XvjsaprJrY8mx8bQ/s yzKeDhI67ROKPLNbSAIyaEtEldOxOs8tlUYX5KTRLsOxXn2LTHyIxU85tHNz 0p5MztVNbsrafxtJdS4GrV1WtSoNJQues1fzeNPCJwKuAASKpgKULRlGTU6V 1wXwGxKaTIedN+hsoaPoI6CErGT2VJixOlYXczZurIBaBaJqs5vc5nYAr1lA LblB+UO7bSJO4pLJgm5rgi7IzhFW5Hmt9OnEl0gUOk8C4bdDNC11pDf+z+6Y KRoErbjpzX8bTW6v4+Xm1YaYJ+JxQThki0wGuJpJ084i5oUAz9Aey3i+uAPY gAtWPScHwu2csiVgStQ5j6RzCc+BLtXuqi5HmzHpXJnNfbOTl20NRmIm4S+Q LvQb3yNd7NT2bw+BTdvIAvkBxHo3WkaF9UccuB9toj0I0GYWCFO1azzOmUc1 hXhwGs8akG5F73DINbHVAuTiM/5TnTBGXtBhH/2aK/Hp8cOjInoAJXB74fRj U+YorycswSpBEq06f6Oi0gnUNNpVTWj7S+WKHEn9ly4pWRX7yrakpfi8tzp/ GsbXXme2QHfCtSNiTxmYSQS4nLTDKLMneUpDwJY8nBOZdKsIZqWHQZempFDQ o215cctfnkdT/A8aqa18bOTjsTIa5WWm0X3ZelrM7X6PVkcNsup5hyZmjCBd WVVggFeOeSb0M7TIPGiRJN6sRY7wFRRJOk3idE6KpB8swxzM4rkaTZLNFMPk g3pqUKjRZIPyXkcYHtEkd+DmUj32FI8BA0T8zhO4Jor7zPJC/UbV/Rb98fS0 RSo4qDdU0mKdxIs1+TQc/NQff2h3MOoJFAAHyuqEIohPV7UF/HwmU+80IneB AgtCghbgh4ZnuiPdcQ4PJvQahlLBxxL8PEM3/FLTrKtqXVAUnpXMov1NpTft 9EJMRNtf1QmVLUkuoBC3jElE2UkxBjgcSoYTfnNHuV8j+0wOrMSBBBBAJAXr MjzU4WEr5t4HNQhXNzdUOO8KLG523G3JQZ0ho2YcGHwZJ8nbGk/6TqRXF8vR QH3RhNXKHysXxsnixocwCmvKj61y4rKCxkBtDs7WV5rXAFkYRC8UgbN7a6i1 /wErrQQkTYLPxO35K2P9xQQ7VgXP39YHQkphv1NGd4Z9rwFWjdMxLyUO4Hrx ugibrYNaAgSFAqkc8wg4n6g/G1+rooItU1bN4UgMB0bg9xoGqhPiB1o6tUqW 3qKnbnjqAybeYQw2yr5ruWTSh4awZ9xSktAqq6hinnFQLQcSLa2q3PSFuSPV IC/OpuhEuQgMaJSmqEWDh3HEdoVV5cBX5l1bg3bmt9kX3psLpteRChNP7q5Q MfghxWWOABYsRlEcyiUhVoJY9tJ4MBr6IL5GSOxRnzAeII/Md1QTZlacFZw9 Q/bHUNonU7JHQRuFQsjhP18boj4PpGWq4szw5JTcLwI9ZOZh+IMXwrIyhnsA xtl6y044Y1RWBEbyAVjE8bppI1+vh221aPMLKfQXRpIIZlIWAEEaHUc0WqB/ rfOk48EUoMFVRHQxhmgs+W7SRY7D+8B78EnMwEHtbFYPzXwyP6BAsX+1Xb/q mpdGFpXul6zh0fRLq+ZFx3QfJXEylPID8CzCIWDO6nKzOkG27PcEjVZ2rmd3 FVv1WQ+N6szZmguWOHXlqGk2pGCkpnQYI7rdSN8LrbS+tuJysRx2TY+HgDfe QHsu4eGCS6y8+aQqccVznedJxPiGeu0bf5neSX2pa3QBN/LCsCNNcqWAdQmp T/Ms1yHlafrTfgZJA/0eK0begHKd6aHLAtS6fNyts2rnKo1NrQ7NLaffZnZ9 J+e42aiJl5H1hGNM0Avng4qv8/BTaYGeAQ5GaeTbfsYL60EMA7kc8N1DJmdZ tmj5ArqM3IaIpYddlpwRVqnOXVuzjbcw0tKrzDTwKX2eipE0KvWhW0VDrGkb KwlzATiDigVYJ3TelmDz9SKm4J7vCXPVSrBkIME+YzJhQXhqTidcMSLUF+vq Bg//Xbnv6gnjwGB2ffry+H901ny5CNh4vi/nLCwFcjK6A3tBL/JGxMmOtp55 RDr3C5BMxrBugEz4bVakXuYqZI+DWgTaNUGNvy7o60VEbSGnd2tp2CrofXUO gV1ggIYYrH6/1V2DugV8eIqfFzHfFoJsQVxjnohc4G73ssVJWTHfqNS+3zxZ 1/OLgaCFIsAMOz70ynSqvjyGqCVgVPxDiYCxy9ZCr7WwOV9jgN44v7hTU3Be ykrDqmwEtzuefRjboP4vsitZClDWC7jdTYPlQCzxqYkorRu6JGLiTejbiElj ihH3KpuF6SYlzMBeNQYlSTvh2VU8vWeDvhYtdM0PLR0iqlfqKamQvBe3Kcfi chBCJjWJgQ25wojAdpe1ka4xmtL7UMNcopo75gHrqNyAVcbqbRVvbrROn3r5 0PAWxyuAqb0I9lYFr+/JYtAnYU3qIAIkj1sYO9JM/KwWtIddJCwYsox4frt9 TC8LRiXvRw3WMj+youEX/GgaYd/qWVM5K/105O6oGfdQAN3b5hZxAxWZDGjO ljkvpGH/pO4Dq5HT2GQt7Rn883vVrQtw+iouVvI2tlzctxWarn+6y3hWwf6o uVYjGoHmuZs8yMJKrCcQrRnfUvdvIl5u+fXAsrjwPatP7wvVh9vus98iAmQS NZgh3AqU/dpoeSoil/3yXdeggUFBbWRJ+nKfkiRiVmbO7gAj7FLeZNz5oEgQ I7qmG6syTeWgN5cUadygDMNO95aofBnkFmY+lkxfyGDZhtCReTIkc8flu6oP RWF1mXVxrl/fdVrhio0tSNIciCiqE+t5GIYeK3PtCFDLKKwNotrAXl2p6Pi3 dLWsU1HHdIAKbYe8IqFjkIfHEnaohJ2xsKD9r/Cy50EQBsLw7q9g1IRoKhHi 6ODApInGxQkMgxFaAhj+vu9dr1CJH4sJmlh6H889p36qAyy3p+TIG8vuobsQ cClLJO6CxSCeHxZrfJ6IJCESWTxaz8+mcjkFJgTcuANAvJupKpTB7pgyO8n5 gD5FHsGzG0Nn6Bk/4NNauM6fvGFYm1HcDxGajrVyRXJYMPugJ8vA64j/xpba 0L5zKefHO0oDQCORyv3fOyxSllh0P3a6mvlDFdQhzxy7oB1wkCSbjzxQsYSs EFXgQuELCvURTDpABkYk/jUMkq37vhzvTId9w4Cbsz1MiUVBOr7ONHl+Y6B1 FgWZRaHGgoHYykQAq1x7xP7qJSnCrkALXGO0/Q8uLXuPkeZZIBKE6Sd03p9n L2+urHMKZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqDTw8IA0vVHlwZSAvUGFn ZSANL1BhcmVudCAzMCAwIFIgDS9SZXNvdXJjZXMgNSAwIFIgDS9Db250ZW50 cyA2IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg WyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNSAwIG9i ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIg NDAgMCBSIC9UVDYgNDIgMCBSIC9UVDggMTYgMCBSID4+IA0vRXh0R1N0YXRl IDw8IC9HUzEgNDUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDQzIDAg UiA+PiANPj4gDWVuZG9iag02IDAgb2JqDTw8IC9MZW5ndGggMjkzNSAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiYRX2Y7bSBJ811fUI7Vo 0SLFQ/Q82Z71YBaDNTAteB+m96GaKklls0ktj9bIX7+RmcVDLbUbBty6mJVH RGTUx83s3WaTqEBtdrMgVEv8w59sqdLl2s8StXmavfvUJCpv+LulavJy9u63 +0Dtm9nSXy6XK7XJZwt+manNaeYV1d6WalfVSue5aRqly/PpYGqj8HF7MKo5 6tz4Sm0O5qzmm2+zYO1HEWJvfpWQ6RAy4JB/eSdbFOrRKP1YGNVW6jiP/dTT c/wo9up2/t/Nv2apH2XxJEo8RFmtJYrN7VG3nMfTfO2vJEDqlWe1r6vu2Nwp jrQIYz9bxWoR+EE8xJsUupJ4RucHdbLtQekOCa289lDV9odubVVSllu726Hu UvILIj8IJvmFLxr3l6eaeeRHnpkvAq9tVLVTW91q9G+rGlM/W3QTbZMcMbbQ jW3lZ2uZHL/C8JIk9VfhMqDx8QHJVe6BH6n5YpXhr/epenqqSl3Y1prmvVK/ cTP43K+2bjtdqP9U9Xd1T4NrhvNvwSaJUj9cD+eOM6CXdC6GjilWz4BBbkpd 26pRzUEDHe2pUlbmcqzqVpdoaey1aAZGRMCR70wj3cwwbummICWQ+GjQZ1s3 rbINnuEQusV8MBp+U1O82OunNIEpBibTl9CXw+dhebVp2trmrdkqvKy6mtph ARsgam9KU+viDlDSJf2irRjbqZ8kPSwpyNLNWhBHQ+4wXBrsh1Y11dM89dcM AT/0VGGeDUIy0FxyEm/ITpobjH1OmYR9c5Hn/zqLZNEM9IGPYiJtt2OK4FIw Zc4kmuuqevAIDVtTGCptV3Oemfcw7+vYnkv9ZHNdFGeU8tHYct9nLOEv+zkB ZCJH9NSmKUfCzMQr9d7I8AZeEbVoroln1J7/8kgjD2lwvwQea399qQV0RkGo oANir5sT89FWoxtravQk1+gOP5z5SXqTqIETEkIjEMuoPR+l6l46kH36arFh KAF25oQzXeswmdJNhprsMlFHU0svrFQEYvVTkliOyU2DtuBR/N2XPNQ+cH5g EqUemlgQxKtda+STEU3h1WwmwuTS5QwlH8+O51W51QQHlsAexRJ5STGT+IYY 90QlIaiojyC98L3tCdszXTgM2IIktDierZN6pB1PW9GvCVKqEylVv2I+FIBO tz/0kS3RVbnXoiz7Q2H3/MGBahn6Er8kmcvbLbGvX5T5Wzu5AnIfoKirhzmk AGpzPBbWsKK0Q5U9LLMovr0EXK8lKsWkHquTKQoU8tXUZ1XoGpPMq6IwectD cNlK1Msprq+kt7Dfjfrj/n6jcuyZRDgWeaUqqxY6wZ8Bx/JiN19Bh+R/Og06 dAb30Kg1w1+1td5ayoI/crEKZlfiVVtDaOOnZYltLaST31uh62PHD1KE9wDP HGMHAU6EMOx6LmzzDyklGkuJpBTKmMpBThNXsK1OUCWoRlHprdKqtPsD9igQ McAmeU3omNneYVi6Mjtbq6LKHaqadtwZpJsLF++y79lIdkdQjdV6RoF+APxh lr9TyzKvaY3e3tEpZ8X+htqTkfQvgSlURq1MvWq+gHHA6lEHo5/5SdurDRun aUHj0EPXqYq7XELtMAld5wf7zJ8YshQ8j2f+jsyFkG03nVLRArqkSlzEDzMi LrpC3DgmporHfaRm0e5mv2cbidPgBZc8ztDtyiD4OTvyismBlEOvMH8rUwq9 h0UnNTDK6650MxxIHVyN69qhVKcS7L5vKwSj7C0g1Ivb564mMgvt8QMaXw+t KJ2mPrrFwMVl7s0TCM1mjhQ8dayrb6AWKVLuHGyS3Kw+lKUOxtutqWm1so/u jiScvGkJjnCtwZVrja/yoFoWOPvZkgXIQdVfEI5kEXJzYcDa4W1fY5DdLLE3 lQVWoQgTNa4xeVfbVoAciERkvNLnC4LxE5wxevorwWSc0E3nNcGAl9dG9yYE PcAK745EeFeMQ9ZBPw+gWi+ny2KSt6xjzxnAibsjL4hnUz/NbutFIBOhMfCy dfaqT6SfR/KG7eEAlDUvTjz0cm9OvIfk+pkMK1xQvddlb4lY2P/95cOXO8dw s+DKgbVJ8teW61HThWMtkpN4bGoNRZAWPorLYsrJtYR+Ba9LE2gAu8H08Elv 8eoSWu7+BwJV1Z06FppvTA6WSMRRbE4XvHbwdBeDDHtziqdogESEQapIYvpL U28rhwvf94mOLd+2PwyyoTdiGDl/NCgEr5+15Be8egPte1BbAz70O+ZB5Ax5 UepsqukNk3u4O6qdzq1czV7cWkGkwa/I0a/pcb82H88ME7h26pNgj2KGrKgR KaqV/Og711a2A3bYN+nNddM743IvDoEBBEHOvxdn+aQ0PKNWc7zWOKfQmxC9 d7I2yvUNJ30lBhOx9plA/9zgl+sU5n/yf5OXszVcv1pFkR+HKmKZRPwQY53t Zh83dJ8N3X028ZfuSsuvcKtdhZkfy62Wv6B4/aLDjc6Pg9RBJVR/yh4icZuH Ee15t6ux3NcSll9R2GVAB1DYYV7Y/VnAcuqFfqD+qNCX5t09rP2CDR9KRKpr l6rLk5MM10uK20d7CT4Kt/gzeK/6GInEWPlJdHvlplLS76166pqWjVZD6D+z umteikQtEWRSJSk08cPoZyYLBC9bwtmDZ32MraAagUmKWpWgWbGjkyxvRjFa ib9ev3mD5KzKc38lI2w75apxUSmgmeNHXYkE+nSTC9ZGLyQXAnMyjwrQhR9A pR0vYE33oaYq2RsC4ZEHg0i3jlESk+zlFaLHy7K3SA+e8fe+2tTYVjCayOmO c+T01CM60zzMITVfynzYZvHPHJLnxkK7fAcOQiGqDjcS4HxPDlwWRu9ep3cc 7t98gU57ZLHuYDffNeQycIEqtlObTZdTXnfSv/gSQJPt+mLc9unJbOnGWPDo KYnMD5KfLljCB10vqYitKfR5dN8g1/pKvEf3vXR3wkMnPlqLry7pdoYtowtq LFcw8in1V4HLhgfFKQhhFvzdjUut9wnzQoXvL2kFnUluk8DlBTNp66a9A7j6 HtPWS+UKkMAwPT0Sv8ZGr/wwnIRMr5hKhca8M1OvIY8VeC3Z+BjOH7Ovykp+ QRctDXdr5e0RoKBFQ30ejVj6knCj2K8c4VqTH8oKID3zPmHNL+XCAe6Wz/BT QF6Buxo2Sg+WaAqWcVyBa4vZYcD0dFvxXUcdquq4+OaGSGsq82RTaNaHUn7W 9onzAa8tDSEdxr/tcgrS5Cg8J7vRdEVLBv8edqfcylCchwqCy43HoHLz0oX9 4chAuCTiAGeBBxUCzEY7PGhCELy5pDmabOWOt3JD0CedofnoDmSopZnLF7e/ UfJlgTh/eOektMQgchhyFkdh320pCSLnTZEIGrHvdA3HZlyhZA1EQDI/i64k 7qrbLJMk8rzhkYcttwa6dDqIyQ5C2bevShoOPKsG1OcXAO4vCjqGaxiPqSoh JyUF1E3TIdG8T4/j3hLgCQ+9oSSXJ2WFHCldw9kF2GZXEgWvbEv6HT2JnSWd 4UXoGhtfO1XPiOfCdaPqnAOmdrglF8KrvAmO3MA9Wyq5rTtDvBKkVP9vu1py EISB6FXcuVEXEiTGE3CM0jZKVGgoLnp750utwAGYgXlfRYo21wJ+ne8Hhsx1 4d+2Id3BfrhlegcLtgOnRBNplj56/hXV8sKVaBKQLWDqNVPaSc8CCwEP8NGO QYL9Of9jRo4IDMXkA7krnlqvTAmSucH3/j8iD0K4CfF4QLnrWj8pd2Mwh5OY 98h5FH7Isd2TyEQeFD/YjBqR237WenI5VU29nY7le5zm6jBG4OD8IK2EV3Jq 9pKF/UQFV9e5ZfnAAeVXZLsV0s+IqUwFC7EMvLsz9umdALr+8TjGJxtdlxjP HRYnAzBKedcwCVeLArCqp9QYduYFTHAJOQLNzi7tFsL5F2xrov8KZW5kc3Ry ZWFtDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAz MCAwIFIgDS9SZXNvdXJjZXMgOCAwIFIgDS9Db250ZW50cyA5IDAgUiANL01l ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNOCAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAxNyAwIFIgL1RUMiA0 MCAwIFIgL1RUNiA0MiAwIFIgL1RUOCAxNiAwIFIgPj4gDS9FeHRHU3RhdGUg PDwgL0dTMSA0NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgNDMgMCBS ID4+IA0+PiANZW5kb2JqDTkgMCBvYmoNPDwgL0xlbmd0aCAyNDQyIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnFddj+LIFX3nV5T2yUiD B3/jeZudJKOJlETaYZNIvftgTAGVpW3ispvt/I3kB+fcewvbGOjZRC3RxkVV 3c9zzv1+PXu/XqcqUOvdLAjVEn/4F4SpypYrP0/V+nn2/pNNVWl5calsWc3e f/4aqL2dLf3lcpmrdTlb0GOYqPV59uR9aZWxqj3go9H/nCd+7nXzJT5No5/n Kz/zdNW+ww94SVf0WLSqq7byojma+c/rP86CxE8DXLn+ndwU9zfRI92krZwS e1pVWm/Vrm7Ud2dd/PKdKnXTmp0pi5Z/hQuKRis+eCEnLwI/SPrTg+H0gE73 jLUdjty8qqJrD3VjWnM5yR7q7oglTauwYP2PWZD6UXrX2JBP06ZRVdF2sOGo Lc5pOtueaefKj2SfXB7xz+umPdDRRaXqSsut9ONFGPtpOjE9GUx3KUDoKdKR VyPwidfQCXVTd/uDMpUyrVUvCFvi6Tm2ZV4jgTI1buP3u3mET2W2yJRpX32l JHKolpVUyyIiI1Ixgu5fst2hHyx+CD+QqUNlRX4Qj1yU8Cr1ZRzIwipdWLhc q2O9JyMrdTbtgb0OYj/PknGURtnK+DgEStu22ByNPSBrF8vp3KJ6VWX9/Azv znojYUQFBIjgdRyj/tCA4+hZ02qq4c40ptqrQkxDNJx/vyEW0cNYTK6UxD9N 42LN8+moubDhIiqxpsQGXkGZy70Wvl6aJQ5ciDxb79ozlXuxRxgoptqSGRnC eBPFUcm7+HGB9BGUskM9hNN4DTUerMR4yljdtVcxO3RkcUgWJ/7Kq1CRsUc2 2e50OiJD6lSIC6kfZ6PYjHKcSzrsuW62CP+XCnvQ3mV3LJp3MHcUMEkvH/XQ WoYP71RbazYILtVc0VXlwYX4QJ4TcGw5gK69x3kbTAvE8bZPzUpSE3p0xDzG 9yM5yU/tHCaFntrU89Sr20VrZId+p3bz2Guw7NXPiIiDKb6092Ja+aG4QaVd VFsgMwq/O+pG/eRpf+9Lkf4hcOiOalkJwPNTGOd+qpJV6icpnfksfgVD+ZZN XV3X7sAQYXa7l4Duki/BPEVmvW1FnvtR/KYZRfvIiCgI/eR2syT6qqXQ+T/+ +cvflSvE8mAqbX+av1Poql1Ty2tu72q/6CkiiZNp8AWcm66qqLZPTV0Cyxkd xcbQ2Rj1bvJTvlRJDAwL2UYxL8qDzMFEqD4Dm092AiuDp7QfwL9auf2ya/FD 8DbQSkaGhBC4fBQu+5eg/ak+mpJozfXPDiSM8kX3eM/zzE+JIAJ8qdpLh66S u+gVSmQKqnVGc2v2VXFpLqBmWRzVnr30p+gZ5H6eP0DQ8LexCcNmtTUvZtsV R6tKNDLMIB9W5EOK/D5vdGMdWAa4MXlTWtQ71cPWkmDr1ZmvwMRMyUbWtaz7 NwRJFBMlj/36P5jhEzRNAWIUCtAEqLknXzaA1cgjD2F5IbaqZ2gMTsfmkr5o dEN6LVGePMlWsd1y4271UYP+OkuHui4h4D7oAZ7i+J4UGVccG4IO+SwGsShh wzNPvmxYoeCOgzmB8Y9HtRlLE3Xgb4bqMPP2B9TX9rUqZK97W94G/xEjI+7x 23G/FVPq0p5yaSGGUZ2LH+qkG7dUEd0CVPSvJ0P0u2sBx7bu3aaNUjh9FHz2 /57AcuB/34vkG13hEFh9BMc6bWc5rUjniylFDwCEszu6aqQILsBQ1a06FC9c ICDhhhhNDsivEEeIekMa4HyoaQ4gHUfqVSpSxEQAGBmLid63J490OvWaedEV 9xh38DcEqIQk/QYa3vimPuKmutkX1QUPR3rUYddWs5/IVDgqkinVPXk7UArH F8mlEgm8ioDU2+seN7AouEg9hHGgJ5rVVNDnE+WDsDBsQ5VjimJbeVRyAA5t kXlA8aENHvNQlKR+GvdcmfRkFLraihhl+snpESXRjBhFOGugpE8QIqj/SRZi kPMocoNrUX5przWNilaLH5KHky7NTtylHo881lKZaCkMZoJnUNj5FDKHmeDJ 63GSpDIyMBZ3dI2s10A6tSks5B7e9diWTeVucpOV8Yzpq69akxd8csSKfTKD mQoviYwSh31u5KKCGCY2WPO/zFvRWzLgIZN8BKIXV+FBV/8icyZIvD5bdoDA vmx00V5mjGTMmtlkCMPcCcnIkAgSOuviFzWOEDuYeN2cUBDEVJSlPvHPGTP7 dkjzh8q9Z2cY1pyN1dSqpRNwJ54sEFNqXZ4dT82lTlb5GAmia4Xo6YX+1dgW mu6dsi10715dp/Zm4qOuHWuWe8yB5MQkX/rNfXrScXpGs4Rs+5EZdwRFlA8U J9Do391p3xRb/R/U8tnNJVeKbMTp0tCTJDDBK5kF0+ANrei5OJDUuUx1At6Q NZP83BbYEaMVC5GSmAYQgO7DzYJ726It+gr//RpnrDKg1OjTltVshVrBlIIX sYpZR0F+hJgsZ7vZ9+sxyKX+0sESPwHkQhiZL91IwEt04mIAoDFyRwpEjK25 93EeEaqqv/5lsWuMrrYAmz8xOkgZ3aJpkGeYX0azx1BZK3c6ojVfRPkSYvpa e6/r+mg/qE8fvzI1fD2YzaaG5Dr0rX8z8dCNGW68hu8rsbI+6BGQoAO0BeCh etAwmvi4B7peyPHhHCFCvZWrpgFjPh/rTcd6AckKc6AxDMsSCkEU+2moYEDa J2Y0n4X8m8HiPhOTUqVHhiWRmGw4oU9xFS9ZZPWVglz3rJ8ESWMBsZTmFMBr 6l3ABDNuOoXxod+cDriKCJFYV5n2dTIpfSXZxB0HqBkaLhh17+pCCuppngNY GwFWvUMDBN7P/OnPYQsrD7Q1xGGF018kYzmIghbJe+TpTnoWfPe1N9mQp6GC XK6oXGKUwgrTo4+CfJCnIObVIM797E6e7gjiHQN5Q8yceE6LayIQn8hcq2PR kvAtTqzdT01dlAfIR3LqQiRZOtadgetFgN32pahaZJfgY6MBycAr+2pbLdcI RRk3yC3CpR8s7xA1J6JrGl2xCS06ubOsIJDqzeu1lIcKZKCSHywaLQ+tTBeN Kal/8LbuHJ/kwJmb8XHMTziMhG9BkgbXbLUwlCHc+xuKox8blRhJ9m300egX PZQu3fFIFwauZTgaVCpoUpaE6FR2LpM2oobXSAY7hFGkM+55O6faJFC+jIZh OPVoPBvSHRzBFEkq0TEW0li+l+JKYzYIE5+W+3F+v0cCpxMqp/dy0nvzFGVf ocilU6QNmtGkCSDJpqQzFQXeriaepIKBYLEYdz4o1wf/HQCxk1RxCmVuZHN0 cmVhbQ1lbmRvYmoNMTAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50 IDMwIDAgUiANL1Jlc291cmNlcyAxMSAwIFIgDS9Db250ZW50cyAxMiAwIFIg DS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYx MiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExIDAgb2JqDTw8IA0v UHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0MCAwIFIg L1RUNCA0MSAwIFIgL1RUNiA0MiAwIFIgL1RUOSAxOCAwIFIgL1RUMTEgMTkg MCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDUgMCBSID4+IA0vQ29sb3JT cGFjZSA8PCAvQ3M2IDQzIDAgUiA+PiANPj4gDWVuZG9iag0xMiAwIG9iag08 PCAvTGVuZ3RoIDI4NDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSIm8V9uO28gRfZ+v6EcykGiSEkkRGwRwEniRAImDWOsgsPPQonqkjjkk 06Q01n7Gvuzv5lRVU5Q0Gu9DLjBgU6JVXZdzTp3+7frhzXpdqkStHx+SVMX4 g3+SeKWKeBXFuVo/Pbz5XZ+rqueXseqr5uHN9x8StesfYrWu6K/nh1/HcbH6 zfqfFC5JJF4cLXP8YP37h0CF8ir3J0XxUt7EURzTKdXDnB6TJQX7FKz3Rn1f t5tDr57aramV7VVvn8JVtAy6MI7yoDZO6WardNcZ7XoV/mP9x4ckj1b+yHiK mVLMYGjVXh+Nqttn/LRqn54Oja30YNtGtUfj9kZvOc25RJknUbLMzjkuz/Fi zjF4bJ1ypm/ro212Sh+GvWmGMaCmQEkSFVl2UWdyjpEmHIPyxw9bZ3/k30VK /WGgWmv7hSPEURJfRlhMVS04gqlPCpVtjDK6tygMH7amq9uT1JImYy3ZnTRi SYP62BmHip4QaRiMQyLjyDw4ECKjOEWandv7n0/+tqt3Jj8OmIafBi2Gvwyc lIva9VZ3g9kqmgZa2cr/0iFirgK8mKmmbea2QU26Gizmz0CJb1oyIZAeKY++ fRyeNQ5SehdmABym26Mt61OHIde+yYJIeiX4w3/M709cWv0pUO2jAlTUh73d bNraDHv16PRTWERlYMJ5HiXBc5hGi6B1X5T52tW2sgMK5fhzf8BV8skEirSU Q2xT1YetUVQ3kk8CFy4RkjsQ5ngyRICwxJsunC+iImgbKkJ9Dv4WEuiCt38f C1q+VtCKsfOOWVi3O9t8DunAVlkEOvTmHobyqMz/BzBKp6yE7O8PjlJQle5N r3QN0tNnwAj5+VBLHwrAvmQpNdbn9CmonNFoWAYocT+mDNLosi3ZxMvMz5m0 4eAqHP9sMWR8HJytCKu6wrf9zxhMFphoF/HDTB2tGw78zPAtgnoc+jKKs+xW kKapxyIFW9t/UX2nK/OzxqGmBnd61ZhntXPtoePS5WjuQAJ5v9KWYqrBw2jY I50CYDnX8h2we+hnpBZ92/BbcMFujTwPdjjNxqwl/jXPpj7Fvk/Pe1vtSfL2 doswQJDQA10vgj3YngXXRFkRfMM5HUdEKYgoMwpg5V3XukE3A6PPj+z/JGGy aO4vr1G95ktIiaOO6i3pFzF05/QgbCu+IR0BkMNIovbsnN3SsmhUpx22zqHW bsZvZIMVv7S+PgVjhheyynILNlMcYg+k6k+nv7j26wn5jgs2Sz1oPqHVvR2w vIDxzrVHwEBpH9BUe93Ynua0DOQr1miPDQnzmozJbmP2EbJIsAarWcggvCJg IalUbXbyNS9d6xWNASC/IiKVOJnlrw0T/A1hkFIwifx2jghU2x95oStUADCi B9TsiQLRHVFL8v8+rl5SZX29Nm4sh6Cf8eZMbc/zWi3uG4hU9LtXZFcwPzM3 X20/UO2PaLvzzujxAlUS7DVGj8rHOvsTlKhteoAD8Vq30w0rmw0XSFLMDn/R 04QWgWCZT/Jrpyzu2x4vTR/f02YfSNq9sD9bPDaG9E07oha7vfPaLIsp8av6 b9L0TgxqudcD9gcYxs4BO59Vs4gwyXvWNZXNg4OFkrbTA21g1R/oh0W0TLJv rSyooL7s/GfeDd7FLc98WU4VXPpJ8aQ0xaqtQQuj+gEOADt9pnamMd5NLpP7 S6uQrjqIeXfYwHPMzr9XaMMjsJWxSGTBqATxVNBFNhd6ZXeNgsWGtYZKQCM+ h6MjmKeLaCX15K/vBsI7REj3GK+MhOzY9fIG5JOLHNJpdwdAxy2/0uIq4YsR eNOnNrr6Ap09dGoDb0nbaA6jN+xn7JcKaHcn1S9wN8rub4FcPDWN8ShjOBGN JuaOS1RakUa3hi4uXyihHZjfhViDRXCS/b6h+E5D3Qq0ez/MH8GvEhsRznVL +77iV46/NYRHjTxAvJKWKv9LQy0DSos/zjdwTFvULZFcSJkFGqcc+H0l5w/y yQeW75Q/nAM6JvPH90LA9a9eA71cw4YTOesbecMi8jtKblPwjsV9z5V65emw hXS1N4IUAO/kL42LwGJBcsiqbQbS9fMioqDXyjCyoWpHRyHmmBWh31NsKq7X AoUkWpav3NF8XhQmkTZhGTnUN0JAX1Q8H8PBWd/oBBfpoSADQkjRenoAKBJA om7bL1K1FAdoZcUvO7CrFgEzVBsqxg2nr5zdMBq8LONesriP+tFVDHuYHRCW PAFAv22rgzcEcn06e7LUkxKQoXJjJU9lrBZFTHfW9dNFwpckXUSpwqWljMFG wswPOO6nXn20cLo48q+T0X7r3e61c4dN4/NSPiyD0+bDXqxaZ/51sM6cHSdZ coIBSbqpWKPHiS3K0RKh1/hhRWuJ+ohbKtkolk+6JO1oz9hm7GZWvOjmdLVC M1t1dZ9tsFvI3NScBHFHzNuIZshqmd+iebx4kqEb2q0+ya6FmRm9H2A0g54o bb1Ruz33i7nInW4RIPbcNHpTo8mS0ZnnV2iwzVYsxcGCN/jvsPCtP6RFf9xV Eb62yLd1Nd3LhE0+qFrD26V8N1gGYKTtxfk+WtcPavBFmNHF8kWwl5zPN5Ms +4aP8TZ+KpCdCuXGB50U3QpZS9EVb2vI/gUNtgZ/hhR6G7NY3VcGPxR4FnYe JKdQVYR0ZgfbvKQrJwWFkoodgHkO53QnEjH5Dm73ia9BJS5+yAa+49CxqYIS n10Pjr8uczUx1oOsP2woZI4dw+aPWwklX7GSrwInb2dTP8FwKnslZS+DI9/+ VoE0xDYzElr5hqTEQTONetInrCu8RYwQHcNJiHW0tKHywPSvLYpxGnz1cRO3 5SYLLP+AqpHbmVL3V4Tvt4FD/Dqoo4UlmUk1o/x17G5qktEd88tftnigUnmj r8SA94lvNR98TbyFuJgOBua5xTruzaC2Bzf2mAc9+OlicVE54gmAT0Dlnscc JVD6myODHe0yTjLnJNHNVUC8gnnhFvEX7LLBuYv+namAo64hcivqgczJ9KN9 i2+MWzEt4mSST8qM5rQ9amxcGFKiUREQtKh1dyQEuOch4hJXvjCWF7QJZBO3 TXVBcvHY58vpTWILsRt73XvybkewKlgrMWIgV3KrCi8NC/oKk81iSklIDMqG 5exFUT0PtLxJ7OUSjkQ31DvQxXz1OOtqM1P2cSryMnf+wW5yMuXNFeF2lnLd OVpNtz1puDuQYqk/v3+L25SV206NA1gyvd3RvoA8vvLOi3vORpqBBYEH2RSU uT8MwT50ujJTvhTyut0T0hOvTmtTw4a0nQH43h0cNZnOXMLjGlyRiIGdOVvy xbfuI26vu17V5AjazdG2MJZDS9Wh1a+pRjHiTQbwOZyNsBO8JYv7dzrP/Ukw aX8S6xhp2D/pq7qc5uPu5E3L22cl20c0dUKDHnVXfI6GPwAAxbbmLGjkDT2n 0vIuM0azO1haz0R1pin4rkbJhYSUso2wBS/Ul7+HZhksgGmqOOc1PRm33rBv ga+NObUYH5Wjt7K0eaHA50zCCMDXT2Trzkjig9IYGnHZ+guNKLn1dTSRiXmk pWkja3sBqAxEor1GfTEeAWVAVBkB/WzlBsa+hmYlU4ABfrP3ggR5LZP7d4OR QVD+Dm550LDtWz3o0SElMmihzL8HzwWIYtsSpazC7H0mZ4B6n6AozC8tUchI LAPXO+D0bgisC0zwuQpUUegmlgLtzyvJTAYWCLCSH2+73dDAEsSCtdvN4NnP FNZuN4a32/3LQHUKpMHuC+7HAFMtrJ+Fr71uYalngbDDEmwHxHhncLCZw3pr VhBjXEO4AJmTqyIKZW5kc3RyZWFtDWVuZG9iag0xMyAwIG9iag08PCANL1R5 cGUgL1BhZ2UgDS9QYXJlbnQgMzAgMCBSIA0vUmVzb3VyY2VzIDE0IDAgUiAN L0NvbnRlbnRzIDE1IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRv YmoNMTQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u dCA8PCAvVFQ2IDQyIDAgUiAvVFQ5IDE4IDAgUiAvVFQxMSAxOSAwIFIgPj4g DS9FeHRHU3RhdGUgPDwgL0dTMSA0NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8 IC9DczYgNDMgMCBSID4+IA0+PiANZW5kb2JqDTE1IDAgb2JqDTw8IC9MZW5n dGggMzM1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvJLN ToQwFIX3fYq7LAuYW4afMTEmIxoTo4lxunNcVKhYxTKhKM7bWwojG42JjqbJ LeWW850eeszJjPMDYMDvCQsB7bATwwWkuAgwAf5MZplJIDeuiWByTWZnKwal IQg870tHDhHTxRF/7OUYG/QwiBL7AT8hFLyhlYykAKOhgwEihr2Mv3vsCF3J jWhEKyFbGlDGvChdQifFEwhdgGmb2q5z2bRmJzwewWdBDLakoRPfiz022WPO 3g29lqWyLrwoCKnwkLaq1l5iF2Bk86pyL6YSvFt+/qm1eH/ekE3RMRfdRV0q PdqQ/5DO8PPo5faqqd+23wN/yhryTx0sW66+BMW/JrlTzadc5y5Xy/SlFneV LHbp/vXlo1kjC6lbJaoPdF4p+wbEZlOpXPT3zsCadg9Sg5Z2d7H2Aifoz3sr SRRPjFNO3gUYAHzH67MKZW5kc3RyZWFtDWVuZG9iag0xNiAwIG9iag08PCAN L1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAz MiANL0xhc3RDaGFyIDExNiANL1dpZHRocyBbIDI1MCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAzMzMgMjUwIDAgMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCAwIA0wIDAgMzMzIDAgMCAwIDAgMCAwIDAgMCA3MjIgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDcyMiAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgNDQ0IDAgMCAwIDAgMCAwIDAgODMzIDU1NiA1MDAgMCAN MCAwIDAgMzMzIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFz ZUZvbnQgL05KR0ZKRStUaW1lc05ld1JvbWFuLEJvbGQgDS9Gb250RGVzY3Jp cHRvciAyMCAwIFIgDT4+IA1lbmRvYmoNMTcgMCBvYmoNPDwgDS9UeXBlIC9G b250IA0vU3VidHlwZSAvVHlwZTEgDS9FbmNvZGluZyAvV2luQW5zaUVuY29k aW5nIA0vQmFzZUZvbnQgL0NvdXJpZXIgDT4+IA1lbmRvYmoNMTggMCBvYmoN PDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTAgDS9CYXNlRm9udCAv TkpHR0xPK1N5bWJvbE1UIA0vRW5jb2RpbmcgL0lkZW50aXR5LUggDS9EZXNj ZW5kYW50Rm9udHMgWyAyNiAwIFIgXSANL1RvVW5pY29kZSAyNyAwIFIgDT4+ IA1lbmRvYmoNMTkgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAv VHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAzMiANL1dpZHRo cyBbIDI3OCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VG b250IC9OSkdHTkErQXJpYWwgDS9Gb250RGVzY3JpcHRvciAyNCAwIFIgDT4+ IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciAN L0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIxNiANL0Zs YWdzIDM0IA0vRm9udEJCb3ggWyAtNTU4IC0zMDcgMjAzNCAxMDI2IF0gDS9G b250TmFtZSAvTkpHRkpFK1RpbWVzTmV3Um9tYW4sQm9sZCANL0l0YWxpY0Fu Z2xlIDAgDS9TdGVtViAxMzMgDS9Gb250RmlsZTIgMjEgMCBSIA0+PiANZW5k b2JqDTIxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg MTI4NjYgL0xlbmd0aDEgMjU1NzIgPj4gDXN0cmVhbQ0KSIlcVQt0jVcW/vY5 /7k3QiIakXjfuHkhGo+EeDU3yb0RQURHKyKWXEmIR9KUrHiOR9ASTGOQUjpD helgTa6Kd5FiqlMhHsNYWARhoqSsWdXOqNwzO9esPubf61/rPPbZ59t7f3sf EAAfLIFE2ujfRPWdPCJ9I5Cdyaup2fnOwgeDi8OBrCCAFmYXF1mcvg31vHcL 8PKaUjg1/7Pk/L485jV1ferMeVMCbesCgJjeQLuEvFxnzrndfmvY3l4+0z+P F/yHt6kGfD/neUheftHciMtRm3heB7TdNvOdbCcKki4CI4p4XpHvnFvok0Fr +fwQ1rcUOPNzc95cqQFnFeN5v/Cd2UWMmz/nhub9wlm5hTPKxtQC1iVAG5f6 HbqqkZ6/k9yAjoC+yz9j1Q3uFP1SzYDVPV3XSX+2FvLq/98XiuUIQQPKcRIT cU5IOOh1pMOgILSHoIEYQX4IhCJvRMCKEUhDAFLwgHxQiT74hpKwlEIxGlvR Daloh3iswzYaph9hKa7QNOzh05+SDeEYScn6DsYgTR/iO4DB+BAfkS+68o43 WfVttjAb7+MorkEjA5vUNraShjdRoA8hE5cogyboThiOAizCJmzHcdTTSqo2 lM5CDCZjFpnJnyJkif4Usep6iwP6jL4IP9bfzlafiJ5Gkv4WNjQYpPM4ov7o x1KAT3AQtyiIYmQifBHNd03EQlTKCMaYjFXs21FaQJXSV1ewNwOQjcWoo7lU LYLVdfVMz8dr7F80Iy1FBb7AaTxma0k0Vua743QqCF7oCQfftBzv4S8cuVMs Z6g1BdNwtvwF3aa7skA+ZMt/QiO+x78pgqbRIhEnSlTfpqX6AMLYQxvbGI5x mIm9FEY2msBnt4o5YpFYLA/KW0aE8VTH6tMwIYp1S7Cb/bqAK/gH5yuJRtE1 sUjuV+/pBYw3CnnsxXLsxBE8J0UtqBW1JQv1owHs2QKqpruis7CKdDlZVqo1 ep5ei2DmykTk8snpWIYVOIRa3MNjNFIHPhnFJ+MojdbSB3RG1MpxMlOWGzaj 3NhjnDJeqjbqlPuSu46j3mynN0axTMQUzOdYH2Y5jRskqSN1YUtDKYUtTaIp tJDKaCPtoF10kM7SRXpET+k/IkisERvEMfFXUSsuys6yh7TLP8oaI9i4Yfxo djZ1dp90P9UtdU/dT5fprfqmbvRkoRMzPg6JzK4Z3AuWowwb8THHvArncZV5 d8cj9XjGOfiRTMym9oyoG1kpnCLZu3GUTnOolNZTBX1Jd6meXgqIVqIbSw/R X6SITFEinoiX0ltaZbycKz+Ul+ULY57qy7JHHVDPTPXmUK+al1uabrvhnuYu d2/RMcxFEzPPn2suGgnMuRTOcg7eZZmFYszhGM3niG9l5lTiMxzDV6jh2Nfi JneoZrzN8ogz8R2a4CbB+VTkxfIKe2/OTCKzJYtyObevZAGV0CraxLKF/kDb Ob6X6DJdoTt0n56zTxC9RLwYxh6liQliIsskkS2WitWiiuWCuCZuinvihfST bWRXGS4dcqpcKUulS1bJv8urRpgRbyQbM4yzxiX2PFkNV5NUtlqttqsd6pT6 WtUrbVpv+sR02NRg9jb3N6eZx5pXmf9sPma+ZdZe4cynUYy+O37+1tMEI0qU kRaH2e8TokieExtozy80oEoZQQ4micPyuPh4YZm8J/eKEsCwe7aHcherweeo UVeMANWAs6IDvuV+uEE6xQmxWQRRfznYWGHUcNeZxzh3iDvCLCpZ4zFnYxLe ovb4l/E2nnL8a1UpxzRJ3KY94kuRwky+jgpxDJuxDbk0gNHl4ABeYB0dkRY6 yLxbjIt4grqf0RpRTQkizhQkik2DOENHaIw+K7rrx1z1d2kFbsoXzP23KZWi sAv3OetXKZq6Gm6jIy5x5+uCLczaf2I/1+DXRghX0HMckdHIMOo451FNf3Pb VZFcRt+LeE5noKdzj27uxtyDN3Gvau6jvqhkJnAX8VT0Y5ynbhzFK6Yb+Agf 4KgMQKjcKZYILb8yLPg96uRIvvW33J86UTRbysc09sOiH7or2MJ0xCKWJlMG 7LyTjC46n5Hv4l5k05l6sxqveuICjaQAnOTuFcRRLFct3I2sWcV1eBPJtBr7 3Tmo5ncliEKpL7OpURWrMrVbVakT6rypD+Zy1W7hLN7Dd/xqWCibY/ENfmCu J3D1RHL9xDOKZH7DZorx8jgSqQMKuQdGcN9O4BhkcCZns5USrOF62slvyAU8 Iz/KxAlc58oJ5DrP5vu92M4IvMVZn41d3B2X0X5eyUEX9OA4vSBfihVFfF9z ny3nPlvNmG7hIXcO7cEVSYPJztnLxg/Ntcw39Eca7UOSPshMSIVd1uABQvh1 TeAareBzWcwNX3TGQHWfBCLdqTpWTJPHqR2/hr7MqrH8sg+ldxlFa/ajCQE0 GjHuYRjIb+wSpKmdtvixtrg3hg4ZPGhg7ICY6H59+/SOer1XZM8e3SPCw0JD rN2CLV27dO7UsUP7oMB2AW39X2vj19rXp1VL7xZeZpMypCBEOqxJWRZXWJbL CLMmJ/dqnludvOD8xUKWy8JLSb/WcVmyPGqWX2vaWHPK/2naXmnaftIkP8sQ DOkVaXFYLa7zdqvlMGWMSefxWrt1vMXV6BmP8ozLPGMfHgcH8wGLIyjPbnFR lsXhSirOK3Vk2dncvpbeidbEXO9ekdjn3ZKHLXnkCrQW7qPAN8gzEIGOQfsE vHwYlKuD1e5wtbfamxG4ZKjDmeNKG5PusP+X9SqNjeq6wuct82ZMBzw2MduY MMPD64yBsMRbKYPHNthm8wKZcWk7XqCARYFa0FIa4qRQzMM0DVET0iKCoqaL acOzEyWmoshRpKT9gfqjMkqTJo6apIIESFIlVdUqfv3OnfeGsbEKrWr587n3 nLuce+53z3n2B4PxkrApRTv0dpP0KjMzJIZQVGxjalHTLbYJ7ODT0PHAQHjY 6BvyUXsi5O3UO9u2xEylLc57ZIWwb7U58zvvzbrVxeLZ0djRdKtfMWpm7Qhw 1zCOBsyzjbF0a5D/xuNYA3PlvNqEUYut+xDEhuYAdpOPxGOmdARbBvgkfKrk +bbqNaxJ7AyYGXqVvt3YmcDVzDFMajoQHJwzJ3LBeofm1ASMlpgeNFf69Xhb de7APWQ0HXh+diQwe7ylJDzgy0oGdmBapt3wTk1vbE3ZREsM51ZDUyqyEnuk 14EQZqAjAE9iOs5Uxn+2lpHRUYZh+IlLmGV24kZ2mBnRhOGrYD3PN115Pj1g fEZggH7j+nhNm63R8nyfETeZJymqwe60zVDILC5mirijuFP4+CXRX14S3j8k P63v8QUgED7aiNi2xSsWIfzBIF/w8aEItaNj9jTGkv0AtfsHKbIoFDflBFuG HUvOJrb0OJbU9IQOJr9A/A9KjunJT/1m+mZMr9leYUoz/oN5a9Le0Kw3NLbG AjVGwo5tQ8u4XtJelrLZLXN6NKb4Zbsl+xVhBSm3pAZzJ+Y11Tz8aoLUnUNu D1gpNFKg1vQl1iT/xqcEg3c5acj6mGcJcWua7aZZERrfrxzXH+ee11DgsJov N7S0GsaUcbZaZCDDqNUDtUbCaBuyetr1gE83LuBzpcDYU5NwbnTI+s1xv1nb F8chtksVYKtMVQO61Ns4EJF6m1tjF3z4t6u3JTYoS3I0URUfWABb7EKAKCK0 ckrLvQD38I8TmD4oe4TJfyFC1COsqlCIfseQRELncXQSdQzJSZ1P6PBTwnfv Do7V0AM++texsSZfjWBD+ndPoVYu5XJLdtBP59W9ZKpEhcAGD9EPtH5qksup T2bZT7Oh/6b6KBVifBX6SyBbYZehrweOAkuAILAUqAHW2nINsJL3AE5hjSJe R0iiB917aYvrNfK5NlMIshHwo12kvksLtXJqBkLKXDF2BtoLYct3n6AijJuL /kaMW8YS/Xy1m3bCXo/2Yl4T58iGnAZkQx/E/lfYZ8io+jN6XCXrBtr5WHsL 5oaUE7QecgPkBuiroF+Hfi3mFMv91mtoV6MdQmzWsl6cvZsKgPWY0wA/G8V6 3bQStunYNwtyEZAFe45SQM9Kr9DTkF9Wi8grzo0x4tybb50JcrXwaRKwj+xf Otgnudz6BHgLeNf2re42sF/pIOpQllIlZA+g8/ryZZy5iSTYK1z/pEqGh6zP ca73gBlqJ2Wifw1+NrpeoOXcB6YJ8Hfqafj0Ka2HLaQ9QQuhXybfB45to4Xy T6lMy6MMnK8VY6uBbsE95kInteA+LMip6vs0B7YFQD7u8LwdJx/HBn2+X5zP +gh+XMeYRqCZuSX41Uk+7M8x57vPkjaPgZvWNdi+AnwN56oE7of9G+BwXMzB fKxbafOwKCUB5l4aCtkHB3xPDpIcoRzgHhsFwCvAYeAxYA+wjcdg3WKMZ550 Yc0a9OczP5gbWIvvod7mThb4XSQ4lnwzP0Yc64FZQKaGt2VjKsbm8Hthzor3 grfAfGRuMWccyfwWvD8nvcTn5DtPk37X29TMPoizg1tpMp95xlIZpmIhi6mQ Oct8c6R4k0n/8/lNODLlD94nvxGWaojy+K0yF1MS75RjkZIzqQhrrtOege/f ogfUAqpXumiV2kp1ion8M8b7WTfUEXpO/h2F3MOCMzgjPTVB8j2fco9IO13D 9CJimadepqcgdXVEnq+OSC7XOeua65x8KAmnnS4nQhpO2lgy0m3/rf5/gXzF dY62of2BawRvZ4RO4qzk/lBaDAQcCf0g0AMUe0LSKU+XNOTehPdE9CmwW43g rUeoVB1GTsihCOKUB/0m7UfgXBcVYO3P5Qi9ivbryH2lCuF9Yi/5CvIFwOtD rkvj0TjOTcIlIR2+TiJDNpeEZD4jr71hyzdteRMyDE4WcG3g/Mz1gXM0sCbF V4eXBRSGbHD4OZGnNj/X2/y8nZe35FLIqF1bOHdn8zvFXm77zW7h/Mg5jnMk 5znOcc74iTI1v5+exBleF3n4MuYm3/U8IASEYT9g5xHkYeuwyIed1j53rbVP LbH2aeVWr/Yh5HZrv3zQ2pWqqSrdZ+eyoFNLRR29SBlOHXV1Ubed07juLnNV ojYl66ion9oK+LFd1Lcw+jP4HYo3eJyy5YOIawFNUUtpm3KJFGU96ib0agly Mtv20gLlJuWqx5DrHreuK4/RClE319BWJUHlPFcZpEzXwxR0/Qm17KD1sViP 6xUk69h/bRut4lzg2iVq7047H4f57j0aeT0qFYgxl5GbRimbzyJiUE/zRRx4 7sP4+sFa7ms0Ty0XcQgwxJy/k5fjwTEaF4tkba4Xa46KfDZNrD2KPX9Pmxna PKp3v4mcyXvtokSGzHnRumrX7DrU0zrlGXwHeYkE/y+TVyklP2plrY3V6oOI eTfGnra/K1gi74t6fxO5ChxxHaMm8T3Btu/hu+dlWs1Q+2mBthL5sRK5fx/l anMRoxbSBa/XJveGvk58n3Cd4u8Efi8ryKslMB/vQvjA9YbXLhKxrQNHV3mm oLa0U6bcL0ngXq749uvHvfdL/B31aBp+aOtyk1IKyldFfWXbTfmSfF6+ZHWJ el9KYeVXqI8fIce/BD7MphVyB5XJBpWpGfg2+yLa36Uy5ZfAScTgoDWqzkQO r4b+J8BRzPsj4pkJ2ycY8wvw4DDm3ov2WxRVXqQy1yPo54Grr0KOAv/AvC9Q n/Ic9Wk+OiJ3WCfF+oyDY39j8Ho8D1jkSPbVwaQ+/5y8k/pbfcvPlI+T+Mdr 8LpiHo8ptUaJrD8DeUk51iifoHPAWfkNzB2mQ9ITRBLuSXofOG3j17RGyAGg EXd4SOoFNgKqeojOQJZAfgCMAKeBi8BNdTlicYJehnxew78KDPkSxVjC/izw W+Btx5YO3msyfTrUv9K4vmsJPcSQw/gmDNPt48/QMvXbyLWL8S0JKPtpI0Ob RrvdHtot/wX6zZg3oe8qpCfV3XTvnfy5E6Q/0GIRwyQid3PGuwV/o3F9/n+t d7fA/T4EfF3E/ywtFBy6ivi7KUO6SF+V3qFVymlay7D7CRHPM7TYuSfoe4V+ wv2BK/crTRSZqEf7EYbTn3ivd+pj3fPpcHjgwL2Evs/4N/dVH9tWdcXvh+PE cZ79kvSLpO0zthtcp6nNS9p00Uie+0XH5jadon3RNZmEjAqsMaBtomuxy6Z9 SBu11EmQoDWBAmWA1vQ+troNof5jK2wIJUOTkhaWdGsrKAOSdQPWj6T73Wsn lKgVm7T9M1m/8zvn3nPPPe+86/vudYzCH5htl6TJDyScco0tU/YuiWl7Zt7r oY00oE7rwUStsVk29pBvSbAk7EeJXOfflJix23CuasuvTwnUdpsEakgk0Han BGpHJOD7fYmr6voVWVfMKceS6fczvc5nvx+Zl+M38DtD/NCrZvPM+i7sF59Y 85vz633GlnvJ2Vk+H/8nPv5v4L9yvZj/T8B/5/fAy8Dx//VcFPuD3CN0uU/I M+p2nFW34n/xGmkhZDJFyKVjhFzGqpi8DB4C9+IbUQX+FRBBG74Ok2vAC4A/ oO8jfEdwZJ9KOKrII4VzJfqmNsHvYSCbjzM1D3od4v8V2A/8GO1ngQTgA6Tf bQXch/4382OnvgP+EeyL4G8Dr6INK/ryLujPA1ugvw/8E9gHRPLxLsHv0mF5 HrnGPfS/y9e5f/y7nL9vkPA0z75D/Ee8/dN59p1j+v1/Gk/fJa7Bqg6Fe9Pb V919rnfH+QRj/biuBs7SAZwp/fIcLc+y8vwsz4/TrO5t2A8K81dexR55fpVn Z3l+BdeC1xedw57+U7JqOq+jpO1KzsHtdetMKwuuXa5YhJaaR2SHqFpoDjg4 6yI3EQMNVMyrVj1ErF5dUFauyit2uM4ci8nrxDjAHMRBSSg/yg4tNyeOwaZ8 ingpla38sq3PwWx80vZWmlZM5xeQ2wXCSB8/RHIAI538A5ICGNwPirqb5UT8 oF3qMXX4jxMfkAY46YWkyrYA6T9uV86T4d8S3nI1bkxEG/KKrS8wW2Nz+JvI 53f8dRIgBv8LeDH4ZfAi8HH+CtFUnk/aXt1MY779cN/PHyBL0f0U30FM8DP8 QVKt3E4IT36eEyIUNmOl/ADfqVzu5/eSBvA9/G5hGr5+/iQytfi7tsst83tX 6HPNAX4O17w58DoDr/mGd4BvJxFAPknWdmlmJlbGs3jMLMpiIEdKepS0+OsC gTDfL3iazEPfIN9N5oKf5Q+JuUaun3+k3D6UUTDfE6KkXpKtecxczIXVRVHx 86j4eTXbP+yaVSaJ1fCfkCjAUNTT0E5D03E9igKtQCeQAnoA7HL8PfS8B58I HyVJ/gbJAD3QHQj5gEAFjyglGDKP8F18Jyqh96N2FK0P2i6PzGynqKhUbjvt Mo/ZMsCHsSEMI6bFR+z5C8zOfv6wepSMvaBaDvijcJWhdN/NvwsM3CHfwQBP 84dUJXarCvS9BJMSL/+eGnzFLis3U3j7bTA7IfcAQ8A44IBbG56hjbQDHO6t tsdrevv519TgzwlPvTHAN+DRN6hqbRBz/SrnW20om/v557FINvGN4g4DCW4W GCx7N9qrmsxoP9+oHnijMAL5ZlF5g1LWC1d+8ayxS8vldGuVY60o8ajm2sL/ joftOfNNA4uxST1SvfyK4YLrA6JAGi2y4qatV2CJ38FNlbZJOoBeoA9w4EWa cDfxIk1ySrV4+Uo800p8vlbisZOQEwBD+82kBdgDHANOAUWqtQNgaI9ihg7I DMAQMQJbh7SADiAN9AI5YAIoJoO8DvPUwTsKmQb6gDHAgReyDHksQ18F95FJ fJ8NnHS7rCaaIimaYimecqSKUnqqvMRasWSZad0lxXIpQhCNHa6kK+3iUZfl anVx3eVzseyVnChuqgdZFc6m+pPxd+IX47yiMePMFLPBWBktJ2PAOMDJINVh 6bB064d8sHmsebyZD8bH4uNxPjg6Njo+ygfrxurG67gVr24yG9tpJ03RPdRh 0AhtoZuoo5138hTfwx0Gj/AWrAVHhzvpTrt51G25W91cd/vcLOPudfe5c+4h d1GfM+cccp5yTjiLWp0dzqQz7cw4e51OozhS3FJsOR0TsTXsDRS1F7IPYCQN mVGarnpykEPKzii7AzKpbAuyVWkByKjUgIC64FLEOYkRJ5WftAOQUWkDAWzh J9CWhMwAjJ2wFvqjQSvI9KAvyEiQTgTpUPBUkPUFc0GWizWxEZXlCLIcUVmO YOSImnsEcaEBAWQ7rPyG4Tes/IbhJ7VrtXVAJpVmQbYqLQAZlRobFoFGb2w+ ewwR2yF7gDGAkwhkC9CpLEN6sMcgLdZt37TMTGdZt6jBRgjy52lxnhYqsm+o MttjXtaNkN0I2Y0g0jKAFmldybEusVb6dolb8tRUPxZrxKdSptKFu1QXUt0E 2aO0CGSL0g4qH++M3Qd5SmlJyN6Zce1KMyCnx3LWjV8XNC/bgdYdlpuReThN korykoosOyq2VRhZ9oII6SA7T0JSrJJx1F6j7yv5SyV7lPyZkl9W0mu5A9qF gPbbgHYgoMVK2W0kiOYJJc8peZflCWpvB7XjQW1/UHsiqPXT08SPjhutKr92 1q/9ya8d9mvP+rW9fm2LX9vs177gl6FCxEc0tkhKulXJhdZ8n3bZp/3Zp73q 017xaY/7tK/6tCYf3Ol5fDQ13HWkfETJFYcbNKNBW9SgHWXYmejtwktc/YzR 24nGS0W42chylyJ2o4gvAS0U8RioWsS/CKoS8ftAlSK+14i5mJcewonEYB56 qERymQjvRrc7TyUivBVUJMKfMbJ0SoQDoEsisQh0USQWgz4UiQbQB5JepH8n CYYw9G8isQ/h6TskJMPSt0gNew6cFfEWeB/Oz05fIM10CZoFsWQW9HkRRnL0 GREOgQ6IcBD0dJ72i7ABelwkloP2icRe0M9F4gyoW4TukfG6SEjFeZTUKL5f xKvRfa+IywhJEY+AOkV8Behu0fwaaJtoPiOH3kkPUaxsmiBhlek3RCKM7vbC g3ydhFT3FrJCRb5VxGVJ1ssgMY2uKzzIWrpGHuzoanpIRbFEOAq3ZhGuAd2S r9xnRaIWtEqEUGPaKEL7ULmVhQmWyvfzIg0iDRkoIMLPwckQiaWgxSKxDlQt RyKpysKsFaRZJVUuwtJLF2Gf8RJ1k4SKWEpqaPevjUnEvdScpV8SxkUr+y/i qze2qeuK33Ofnfdix/azk9iOneT5DzHGjyQQxwGLYD+SOCu4DpTAZlPMkqCE QBFp6oQpW4tK14gCY0LbWLd2f/qlg7XQ2iQNDrARKdOkTqNE6qZ9GKLZlq3T tnyYFqim5s/OfWYNlfi0L7v2vee+c373nnt+vve+YwGuSp/4UUxI/0j0SH9P 5DGtlf6GR/jtCekjhN6LYFfRS3cDc9Lv+zzSrwKIUJzS+4E6ado3IuX9N6Sx RLWUw4Vl+3qkd/vUGd7x4bCr0iV/ngKOfqPvSel7AVl61Zdna/gWgk8xHzjR aGBEesl3UhrGrTCUOC1lAlXSs/4D0hE/c2STDgd2S/0YyCEc09t3SOoOfFvq CqkrPhC4LXWG1BjifWpE2yOq4Ym+3VI7rgANUWbAFWzBfdmAQ+tCNxhHpBZa x25LezfdpPgWhhexPqfU8T/jT/A9/B6+Bd83a/ka3s1X82WCRRAFo1Ai6ARB KBI0AhWIQGhZfmVWkQneXmVFIhNFGtZq1L5IWYsNy0koCJTsINlSLk7jnS3Z TXI8z6/szm6W41l+19PJHMA3UxDPTh0k8R5X9kGnNw+6p/Zltd4WyFriJL6n xY7gLH0lD2RPMg8rbMSoM2tpTU4SgPWj55xMto+eS6WI9XjUHrVEzOH2tsc0 XQ/bWJu8Wuyy/Lmnqux3453J7FtVqWwD66xUpeLZdZ2u/clJepQeibVN0meY SCUnoZ8eje1meuhvSyFsiwojEfoMwkiCCYTR/STCYKjf/wgMcqhuy0UiBdBO yDEQHpqdKmhfAdT6KIg7C60qqJU7q4J+VHAYwHWgQ4UJhGmPkoDqMKA9qsLs DJbz+XCmPh+D5Bp8CMj5GlTzU6tmf8F8pWC+wsx5gFV7yFdYrZ/4VA8+6keM /H8svS3/wyAY23r8WDLW6411eWO9WLuyZ4/327Mv9rhcuWPHmcGV5XxdPQf7 mezuzR739rZlj3nbXLmtyceYk8y81duWI8nYnmQuqfS2Xd2qbI15u9tSYx0n Nw9+ztfpz3xtPvmYyU6yyTYzXx2DjzEPMnMH8zXIfA0yXx1Kh+orvrsF4ruS OYG0pFr3F+QY1evwtHQ53akWq/hsRD06W9z2E87rGgKXiF5OZUu8LVkDVmaq 3Va7jZnwSDOTEdWmhyb7iS1u53W49NAkotrsbSFD9tjhNvxmsAwNDWNBjjOZ Atf2gmFIjql2BAxhb0gtiMQ+qxlV+9A+RIZXiywXsCQjtyZziUTMfrjNiUn8 GMu75VSGyHLBoSwT9IlRq4m+VU309UXW4G8Tf07cT3BTaoY/g3VWzfCnMLuf wTqLGX41NxWZicxGuKnETGIWsfdm7s3e46ZqZ2pna7lND1fAXKUAV7j6GZYz w0wtgxqtGjc+DskZmYX8Xw7wSWZaxgqWgl4dJ+Ms8mdj5dVOpmAcVocUtJnV DYz3Kt6vWvxgJDxpGacwXcTnOUEpJVrNNEd0vGYaSIVQpJ2m3E3YRoqhBr5I 7LL4oHmpuUNcaE4sNZMo9sVFbDZucJvd5hps8BYniy5ualHRkk+JSzPFrvEG GKAjNIK+HEoJ/nEgDi1UaK6cs8sd4pz4F1KfmN+4AdwhNx1ZmqRfgIE7bNS+ lY/hIjQSPfGMk+1Fei4PpYreVbyhmBZXlAycZqMX04l5EmWjG6zlZUVejy/U 2ASkvbsnFuvuhkZVxGI9bL5TGOxBbT+xka/fJEa4AiEiwJsTni/zAzwFTEGY hod/YwZrhTcxMfyElKPGSqliNAlEK/AlqJSAAuaHimg07jINmN41caIJTBV2 48/xlSXQXxI7tcFHKlNzyFM63ZwQl9KMq6glfH9+Ee7LkJZxweYyqzUYLHeH gg1NTSFzo8/n9fBra+jr1vaEtNS05ks7HJaNruB2C/xL2//p2y/E1tfU+Ntf pLcO1Ltda+ZUXjGiH2BEleSvyppX6Dv0MsetLbnAUZ1epweidVresI5bqbWS 4pp0eqEyD10Tlnpb1kZtefBcBYvAToLe0CjkuTXjRi2UIMkLipNoRS3V3rV8 aKqEW5VQ6ag2AdwCgIqq65CE80T95dKD4oP0YGJhKT1HotF5dnaUUkGxGqKC YjNiU2HCxhBmOy6FJLSyl40NHSLCxhwjSJVOUZVXK81RFTtnDofNljBgTZvD ljA+iu8jZWmSdrtDxBJqVLlqago2WPFn54vAjRxuCnK7Fv8IAz986cBre2ua 7p4/9FbXjt7ly1BzdFvAs8YK70Hd+cNnXzNM5bsubh89Pbn8nkWOMR7dK3/i ziCPMrmjSLzJZuqXR+TR8lHr66UXrD+1/MR6vVRfWxmtpGUC5OGCUkyIyDIU tx5TyC7MaNz01/gu+4A4iIDhGMyNKq+WcpT0gwnFqHUYSBn+ZRh3AWh11+EC 0YNjorpAc57TXTN/SNaJ6+g67Ctmkw1sjlpTNVQrpeWN1RXrH+FcRs4HE/Pp hfm0uLBkDtdXOOabiT0adczLsrg0J85ZwvXpeUu4QBeEIvRRtvCM8Iwy4vas ZUcl2GDDXdjQhBiofy6pjOz7Rk/NE384c+7a3qeHv7Z8e3n58s5wi+yuEqf3 7jgyRS953eHh5s6vfMdw8dLlTPxsKHzxxG+Wfxf2R+u2GYUfD+87/TESE8R9 eQX51BED+b5ijxogCMARDeWLdVrBUEI0gsGg1+dhvyISKMOfQE+AF/QG0JAb sIjXko6KSokAWqHEQDCFpMINrhgn5qFLsddrohpq0kgaqnGYCKOIVBjv/7NA D+7IdGKhWT1xUbymHjTj5mEbyRI+VSdrXhB/YTKZCtyUQtAcLPfixeXe5DYH 6ctfff755fnl8m44Ayvc4cVX7yzPwIY71IY7JLYyx41pnyQe2KXUGYugWFeh 8xM/pynTlTvLK7nNRduLrmk5vRYcTl2lpkrEtkoDDg3HFaL0YJQei8kDxCN6 qAdvkHEL0YDmP0xXfWwT5xm/984+f3+dfbbvzvbZ7/kj2HEMwfkSJpxJCGaQ j40CDcJrkwlGSUVJUBPSDkHUFgZIsK77gDIJOq3rtj9auvBhqKagtFpHmUSY YKMqm+gUTQPNo9JSxtbF2fOeDcKW7nlf33uX6Hme38dTQvfPc2FmiqHhIJ4E +hTB56tmh1t20+7bVhtdon83ia4bqQ9olsJUEH2piqqxz3jayBjFqPP6MYww yQEWlGoO5lIj3bPQJGWg1jkAZrlYBp4m4FM9jAoQY1TAG0MQyhCsaoirDGvg 1EHXwgldDZS6Gki1CEdJ/LXHqj2S6i8XyUNqCJOXYvJSTF6KyUuxCsewylmq Z1P9B/UNKUg+5eJ8pBw+6E9quIhGisMowkQMOh9pTZ3yqCu9PvhqfRmNYANq pV/eOn9vKeq/dOJopfLmz/vb86lE38Dyejnxjd2V05U5qVm/rlI5aDv1yod7 70+017emVoY7k07rnqfO3CbDxDqo37TG/QnAuMnDoG3eUS9tLi08VHnOk00y Uf5jnllh1GO/X9ab4vxv6E9gLvghyKQJvXkuHndSehgMzWedNnzbWkKfT1Li In+JvnLOIcoiLRLgWjykEB6h7lEhAKflHueD7gdEo4D+M2VneVbrRdKRSxZ3 jKsNUszsjsYDUlCiWS5mj8fMeBCFXOIgFXbASrHEB5HklgepiA0umlfQMppM TUxQRdCSIuLttKG5pQZvooEAeS6KWN7DVZPoTAADMNPnPtun1AfzK49f3fnJ 7r03xj5Db1SuGJsaIumGQkdqTZ1+e6Dh9WsnQibPn6cO3HnpEDKenEWH7s7v PKwerlSysaGfIc9znZDN90CZ/8dMgzL7qMaLlABOSeDcWXYNZbCu4SwOZo2p fopHvOC/dU3LBECS2IWyptSpJ7Xa/aRub9TEemCgs6bfzPRAVb8H5keeVPKv L3yu36QfoqIoeJHyLuyfNJmzgVI1srVog6j2w8IqmqRmd7d4wHtEPCYdChiH XEPcuGucO+R6h/2F7W3fx76rkpn1UvEObz6w3/ua74D0auCC7oOQORPfLo+x o7ZR6YD7ksPQYndx0SC1mQ4ikAGPCsvIL12cXb8jyNh38Cb0TMaFXOKuOIpz sZ0XUaNG2R1PqyaHWTbT5m5BmOu+W5Qmq6tyf4+z+KDYPaslBmjqH3Nl5CzP lSkidmvXj7/faIQOiXoDrM0a98WMJoOJZqW4zWuOUWwALha/PUaZRH0MVbsi mYKmQMVhClClzSkuhbgK1kBagXRCC0/6I6r1B6F+8pN+U6L+i+P7bixZseWj n+y/OTry77c/rbx34Srqnz52aosQzhj0Q5Vk6aPvj/744vnKzRO7Dr04NvQu 6ipNoy2X26MZIHuaioOb/BT4UaHSaI+6YoM4Ih7nGaPiV9aKqwOr8UDgW9jA AbGzTr2T1S3OfFsak8bwd5XfS1eVmYzxhPeG+B//V8JXoj5jtJbom2eDBoyR tmCxYoOF2hbksBKQKMkp0VJawR5FwfuUIwqtUMlARNqPZ/EcZpy4D89gZgZo 0ZcMYCUea5BK6K+qT6EoNppucLs5OvyHSARjljUYw5ES0qsmK5V0JunkX3wl hla91mgsRtWsXtpq7bMh296G5ReRoLm6Yo74OSf5zoMIazZY2wHNwg5QnivP 52r2ZXikCO6F+JiD9oZU0Q4U6IfCaNAPJ+o9Ih8T4nWxek8ygxIiXFLedAYt 8sczlCg5c4/ATqAOSNc4ug4oy2JtSxmtbQG/m29HKW2uIGKvWUpwlI8NZVOk ZpAMiDAqH0GMS7ObYAnosNRZnP/aNzskiPTog9nvPb/qO6hLlRY1VzZU1va3 HTnc+/pb9I7KqzvbcCymtO5kdpFV54WXfzTYLlea+r0yE6N30Cfm31362tDJ H5A+6AWeLTIfUjwVRk3q0yy31lP0vODZzm/1j3sMMfM79G/pK67r9HXmlu0W /y/moc28j68K2EZmG/MCHmP24VeYA/Z7tr/zpqRxwYuMJlOKeIAwCF5RH/ZS qMtbQnVnpbjboC+h0KTVYvJqw1qjsMKrCjjrfY6C/XnYOoAsNIdrz5Ko+l1N lJjBK/Az+D7W4fCiapEbneQQnNdiiKvG+OIsiarVas/OOJFTiLQerbIZKUk3 uF6C31RqGHg+larSG9AcdMJccRY5rwxrVQ65QsGY3yf4aDbAySFK9HjB2Lmk EPLxcKG0EgOZw1BABBHksKp8LT4CVSKHHBC7IRsnHA5A5pni/IJp86qB3GAr XlcanxnaOP+ro9f/qcR4JRtZhr689Pz6jk3ekxOnJ6buIf7uT9/aI3NL+08q kIp1AIEXoTpddI8qr6YRx8mqOdRidLipHNUlu+Ff72JRc4sQlcGt/uksTkfl OlioHpyPyjkFO6KyW1HUBMJROVGib11Q1GWoJSovg7WaVFZG5S5FMeB0c8SA dKFc4zZdaJvZrDNQXWxuWV3C4zYXVEhzgaR1QwhnqcLpwpnC5YKu4POJdodD dtCOpCioy5sENZXOnhKmhGsCowrHBFq4G8HJhjTcSmu30lPpa2lGTR9L0+m7 lKNFbqFbkivz5M1iEGefzd/J06fzZ/KX80wGLjN5Ji+sLpTo9ZORngnAYM9c cXgkBWNsMQdDDNRv/lEs5npWbe38G6wB2eQDoxsMcaDdNfMCAw0iykvagHHa czlU1EodzSyRghabnl0cD8SX6BtCiDUELWIIWW0ZtjGEJGuoWnAANsE2wBqA veapcZWTw0ZT2BhK6GVTJEGFI0YDIpwC0J6YAAGJPlu4U6BZa9SataqFP1r0 vfpeY4+p13K5oG+le9le639ZHaGI4ZF+jSQKxLAFtURPOvkVIIoPJ8GRaRFM mbW08MXj6LJVf4eo7R2W6t5Ru++sPQeR7N+3tFGpxx9o3n74w7w2XfhqExnw EHBNE3iS2lzLGlwejX/IOFIbdclvTx5LNKEr3a/0bH4p0vdG38DudKK9EmyT OE8qmPo/+1UXE0cVhc+d2Z1ddped2d1ZYBbYH2bYIQwLpd2FUqk7pQVasKQl lIpKKqHbWoXyV1Np04LRaKommMY0xhcNLyZ9UYNFjJqStFprTEo01qhJfWhj 6gNqajUxhsVzh93+oW2spk9zN989596Ze2fvuef3wZgnf126SI3xYlVhWaQq gc+C90ke9X72zYMd6zs6H9rSdeRY+um+uF1RrGphDzl6aEMkmUw7UoFSi6Iw cnU7OTqmK/5Qa9rRm+QUhQvn9THC43F7KdpFE4ClFu1CYyzvA7d4+YSzLocj MapLq1sTW2LEarVypRz7DXOe/SrA+rmEtYlhz5PvCxkv74YIaCG3EBG0t/iT vJ0UFolKiJ9hvtM9JVElFJFLHErILctFSig8w3yr+2VVCWmyHAmHed7tkHZZ WYsNY9SOqTmCicXiCb2zIEFGMdfjHKEcklPu94t6ZF1SRN3nRRIWz4mMqDc2 x0V9fULU69Ygk6jBbkU1dmgboq6WYVeiYBcMYSd44oJIxBnygc6HYm/HmKrY IJqNfn+CnnEKdzAobmJQ3MegFZVLFHczKO5lyIRHbx0r4iGEDr9cVaN0zo1/ 8BesIaOz0bkoS6ematfEDVpVbVA9p1iJR6UKan00OdY0NDe0KxpMs9rUPbTk XLMjNEfBKOXQp2pDGGDr55eCrXaD7RkKH8YPoUKHjQ+hpvO0ADFGPixHeFqY 8LrEY4d1Ck/rmIiYzH6oC4uRYep7u4fRCWtZbf4bRV6us6c2PvvAw0+JAqqk msgXvFqgs0VNpNWMeo62Nada6ybTr/QlbIpiK5V6yRsj9ZGDaeee1bab1BCF 2YLR8z3Uw1yIkA694EyAqC7i3W53R3MJ2PKjthy7s1i3GPJGN2rRo1qcxyIy INMDtSYM0rxEkgaZqlsbp1RXyrT4rDwnMyDr8qMyZa26/DomT7w35GW8+pyT ODNR0KC4NaXTGPycUgnuMf6umlg9RD3n0uVhcYPxD30obb/jVW2eh6ULqp83 3OEGEhFKmdJQMBxkONHn9zEcFy0sChRJRSzH53pVPGVxkOTleINQYCtWicfl VkmQdQeJz5EfhCJrvgpatuAp18ppeovOsLqM1JFNZJMw6rIOcmOuMWFQGucm XBPCuPQp80nIMWYbzB3kxwombOO54/xEgZ0mR0NdBMNrJh2SS2gKnI8poB/9 EobbWrxQep9Rkj7wRX/qwNdfXvrx3KpN+W7nxspYUM0Vo6UB9tThyy+ceW6S lJ06S7TmzRc/e6K7uUUqWbuDRI6PFftpZRJd/JU5ZlkACV7V3RPOCRdjdE4X SDNkWpeIRRRZ/zMM4cLOFU7dyTqHc1JuJ8POELdebHVOuwKFxGIB3hqyMtZy X55/VBR9uktM+ugtChjZqnyzvjkf65MCbduy6Qia0VXDUtA0aME5j0NILlzq TmJYMzKSekKLCjIEQ8Szyi8bmeJKzDGw8sIcwyMnampqycyFC3xUWLcmuHW6 66DHceDwOw2WhfTx3oWTW6uKe/Nme9eWHCN/yF2n0TllW99/xCTiynWQ0wCs C/3xI1hRVGK+8hOAvf4WfHhnONruHq7O/w+5V28PD57Vh6mzv3M58hpMmDBh woQJEyZMmDBhwoQJEyZMmDBxOwADBGgTgaUcCSA4uGNjbxwIHlzvz8svkHBQ nJ2N3rwisXyTjRm6ZWs7Jdvv/Nl71yzwGFCpCHhUC4ShEmpgDayHdkjBAOxb XMSnYYhB9bXZfjq7ePHWX0a+yxv7D/PXmx12ZVazQEVLMv9Mwt8SzyG3kt6c JQdnVkJrhmfADYcyPIvzL2Z4C/IfZXgO+Z/bWpqbWhq1jj39qZG21P72gf6e vRUNA307//0DaIMWaIYm7BtBgw7YgyJJwQjOp2A/imgAxz2wFyqgAfk+2GmI bTc8iXwPDN/F+nuxgkraWgZXoB5ftqJkBaiCbQC251EHWByjUMnL+MRuQY6O shR2MV5cfq3der1JbKCjFu2z020+tyfYkcwtMz/s/tj32qUdfP1vdsluvD15 MdFE6Ymzx0N/Hll4SWi0U5Oi927s/NcACgKNxwplbmRzdHJlYW0NZW5kb2Jq DTIyIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQg MTAwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjE5IA0vRmxhZ3MgNCAN L0ZvbnRCQm94IFsgMCAtMjIwIDExMTMgMTAwNSBdIA0vRm9udE5hbWUgL05K R0dMTytTeW1ib2xNVCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vRm9u dEZpbGUyIDIzIDAgUiANPj4gDWVuZG9iag0yMyAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDY1NzEgL0xlbmd0aDEgMTAyMzIgPj4g DXN0cmVhbQ0KSIncVwlUU2cWflmBpGxNUNuh+ANFBZL4AgZls4YQ8DkQMAkY rXVMwoM8zUbeA6SokKgIWi11wZWK2ooKjEtxmZ6pg0fHhQrFraLjNjJOtS7V FldA539QBG2dOWfOmTlz5r3zn/fu/3/33u//7725LwgDQRAeUoKwEJCowZIv FTZPhjN1CCIUGvMpEHa4cwF8b0QQDjvbnmN5gB7ORZC3DkPZO8dcmL19Qf1B BAkxQZ3dJlyf9ef6qTiCDId4JMoEJ7zFLCeCBJyB8rsmCzWrIB0bC+XHCMLs MtuM+iFxQ+IQZJg/gjBcFv0sO5PFqYH61RAP7A7cPtf7ILQX2IEgLOgXYfTc 9BMRdMOnEOm5BA9Ql+A+1yOsdHzpI0+GG7PaJbgGpy4zGQypF/oG1713hcnh IOh0Li+cy2AzXKOZDHa1Gk1HRQNm/DcFlPgjcT13GmJASMSGmBEcoeAYS98o eNke22dZ7cLrzbyu5XHnk2ufxckPV7u830NdzEY4QplCQXnDyUU3ag5/JTu6 bklZ09AmTeYnqOcLrgw2pOT8VDoUfYfLymDzBIMycQehIXKsQOvIIymgwqkC m2OmdDDqRwP4Aq8+gAhgVqNEKkLDeheC+zUJCw40lN5iJ6w5QIM78gkjDtQ2 GyUdhUb0osNVaSAFkydgKZh2MpArFMp0rTJRBEYYQ6NHg5d9oAGDPaNHozJp BDoahdcUKEZLIyKlP4v/+xtwbhh45gwOwnIugedeznQ6kdMScM80WySWOP13 cXfX8Pf5ek66oGnLaz8eGbb7zEOP90f9dLPimccbrX/5zZQ/NH/3sGxXVePC kFtzdD7kjFlf5/p1H9E9DK3VTatkd4sNvjqnf1PuirNBupFnTwg586O+XLG9 IXXCzbuxQfWZa+YGrjeXNk5IXjWjYUvU2S4P8emG6HVMFkzqV1KCBXnF+K5f wBl76mZJZ9HZbR11hV2crpXxucHbwkdc+UiAlz8TLWR8PGWtocm3pqRj3wHh vpOZa2a6G5RHNn1+QVbMCbrsELNLOTWzPQYtFyruPRqU+q3b0nU+Zt0znmxV U/mGK2z7+rA5+qUHb/Bz1249mm1IiF+5IihidVD5oqdZ7u8+OPUU5m8zHFFM P+Qr37UXFHcCO5N088ubksoqQu4Kp///JXGddDga0ms44J/T6Nsp/7U7/bco 9p0P7xfn44t60wtuAnfMSuEOK06hzqpfpPRiGIWFdErX6u801C+pSK642OA7 jbjIKzZUcKXNLc/LPkk6h8WsuHmG+15V/aZZU24/6TIq0/bzregPm6JqxR5X 7tuG13pOnM6RpRW3aNNa94kS2vitS/ZPe763pLW9sqE4CEvwMZ9evZORufnQ N5INMR3FW3VbzgXh1z+qnbX+j+eTE0zvi+d072EyWL+S0JbpnWt+9xnxxeki e7ghOCARTNwR7HeUYj7Bfhz+9tS60lyZe/jDjy9f3VN5Y3HNb9vJY+M9qnZe WHzBb1kT67pHSCb3O9VnyZ+fnJR0Zkzmg8DmQ8NixSERLeuu/Wlc8vdtluT8 643oZu+SluK22LnVT1aGScP9nh4T3rm082aG3J4kFs1FXR5b4PCuZjEZTKZP YXaldd7O1r2MN61VjQ147kDGTJjQ+l859ddHKBKV9gY87EVGKGwWC+4wEnoz 0NiyqQK9AwfpeQYzQZpwBwkU8p6UHIOOkkah6IuUpMWISFm0LHoK6mJ88B8n IU1CE3uV4gsKCiT5UJGEihKjzTISdmAbSVA2R+FIRbqG9mFz2CXAUAjUeLZE ROe1JEWbSOdylHQsGtdrR5ZI5BAUdIglAoVZT5IgEohBKmF02EhIoZ9Hpt5M ZOkpwmYF+RFSPupB63MFzAyNVID60oK7gDdJT5pg6VE2q9QH9eo9Cjc1nmWx WbOkAag/PcMS+vWbV0CONkeP2b51/mvW4QGDV6vIxfBE4Lw708VgIA0Vp4Zt zfr7Lb9Dzy1F8jTeE1tYbotkiGZLRNTVM6a/yrqxN9squ/BvNEJwgH38wwfH 7ZYVt098sSMMXRuhm71328yQnDWN1wq+51z/ob3yUT3/rS2/j5tvv/bYNjVt js1brVzkdw6/GAs47fEbzativPghgjuBX4Ol0R8a5nGOB7/dpa6qq0qpPBen 0sW7iu56yDL3mBoTlJtipZs721Z2ZhwVbd18KDStpWP5PdbQovt+Mdseb0+f x7EY7i0WlI053+7vRR7kjvtyxKFbzctyjx7I3r1RG/QtP2f244WF5XXZvO0T n3Y7ArtKPzjSMcHrtk4fnNq6KybrquDTaccWWFIG7Yh3g4W82cW5hLo453ui 846AzUQRlE+/erPZLCanGnWW0RKD7SxB55b4FFX+7aSi27T6pzEnrLE/8l0b jf+FQnJxmA3wqxANpJmwGYzn7MGoEKW//Pq/7AaxmG4lCIw2hPDYXBSS545D XeyoARgerepiB8PpodWhJcNNFGUnY0aO/BeFsdHF2u90sRq0JoIERtxBEdmE UU/hgOgpGDrZcJKuGgeejTtwqxEXAb01CxAUCfJICCMBSTkII2Uu5JF5hhm4 kQKUTQQoEw76D+GFXbpe0h16I0U3RNiaKNyCWykwAjIJ5UGaJA2QSlDoJF9P mPUGM83kZWv9GwB6Kob3uo3G0qyVYgs0A3EAehA78Nw8nKTIcS/jbA4ehPYB X46pCETIoiNhGPWwQ8rzcTiRasuzUnrIKpPAC0QwhCB6FDoqkpehkUOcvdBB 5JgouklKo6OjXjEHgNxsBmoaQcIfIhL2ZDxLAhRKtVaOqXiT5Gq1XKXFlBqQ iGkUKXIsVZkI5KrEAX04BUvFYBuW8Gi0ClMlxwDteCXI0ChBWhJ8xTQ95rAk TCHXKgEUNVo1ptCmTAaajIQJSoUWaNNoFV6mUo3BP06qAXgsTQXS1XKFFlMo oR40kKpUaSFt2gWm0WRAf0CeoR2fpoZceH0kNX07AFhqegr2M2elLl2t1PyD +WqPqzHN47/ned73lOOSJHQZDqHCtOe45BKNLqeLUukoErbTVXShU02pTBJb oYtbMxWJZJOhZiZiRsmsYmVZmdYkhlC2xRrjFnPOu7+TS7bd/Xz2r/3s++ut 3ud9fs/z+35/l+f3KiS9qJAEDwd3H0ftKr2jYrR7vtzbwQUf36H09JY4uS70 0Ko74f92Ei87tNHBx93OW+Ll4+3lqZBP6tlkkau7u8TDc6HYXt5Dkru8R8HB 00MhX+CDxrvauU9CFQ/Xha6+b3XeGeuJqLwljnbz7ZzlCiuJQi4Xa3Fqzwvt Go5ynOWuQKYdojH3o9Bl0aF9YzEsXIVlISRYEhUdpQ2r0PCQYMWbRLCLxcwI jMMEEockoH5PcMcrI+JCJKoVSoyDqOhYSWCIJCgaXwX3LKJUSZRBQXExbzIw NDomsidnxPFvjhucgZGqtcDVzkq83zp16n+T5u/GI6LDoq3CwkOl649qK4mE W39QmipNFfUP2ORCNr2UEx1CcMBCpItVheexgg4z/Y/rI0nSwPczqdRXajis Tz2UYrNCjOe8GzRX9TAb3nsSv68pkohwZaCVJCIWc+Gfu0vouaTDPqh0Jpyu VITVDn/69D3aTm2n+75En9bYpZvHnSmTPI6o+TrJKWlP8dqTa0QuhkNCmpZZ vlxgk7mm6unQGQmtOUf6p1rnLnPJPwszxIq6udOFLAPzSHCe+sLF3SrmSUPz OrVj9JicP28rvrPjYacA5888ijH9sYhFHasPSpqc4GizZ2PW6/RN0y2sOstm TLc9+esvaWayNG4M1uCRCF0a9z84P/5NMzhApPuGFMrzsHf9YanRe5b6MdmH BwuHPUbvU39Zn2NHOqpXkZMN4Qbzv1NNbppfWXOh6/nhqMaBx6ReH0wfILOX zt07InUYKCARIiEQoiECJBCKf6MgtmRs6hhtNL0Npsh3TU1PNMXGxIXEJq4O +U2floZLI7Ck0aBxZefuTOWtkyMf5laKq4tMbB+U2A13Cg1pyD634XjaMvuc rAe5F+fcmrfxq7VGR38uOsxe+dUWRd6Jvdze6vBzsEVdQrfnyu3Dj88fePFu VuDWVV8O3j1mhc5PQ40SM8f6PTRPDzQzSoij3Ixit7nGdX+R+9paeIzQ+SjI PGrJhJ1/Xfoqafc3MSNTyg8+V+gXPuvYktacWVw/eq1ee9fN8MUBUwrcaK3L oc9LMzbdt7mp8Sy80tna2B4x4eqpgG8bVlwtMFdanEtpVt7N871kGDHENeAu iXRVGXyxO8Dg9gGz5rUNSZIag7VlIwSIz2zqyLt9wS+7PW32+ZyDGZoLJ5Pu Tbk20aIkjVzGrq6p1xciWRo5hUMntEG2vub//vuVGsIp/YJWh4ejXzstTs/8 o1NG7rhHQwP6BKqfdMSHcdr//YMOwTB9/4aX6Wk/PWRS/NaQyqZNmbrkX8K0 Ky934NV94qp124UXBjv13PoG1fpUedK6SP/IafZJ8T/eu7a621DfLc+vpSml XgjztFU9S24LnaazKkQ+dJAJfCa8OlVQblkU31GdKByZnXJ96c6nj1JVxfrl /YxTNp8fnT55/dD6S/ck6a1dkzP8E29fE0zKd+TZpmX5j9t2Y/8z6RD7knVj PNP7ufx60rrQ5rtDzR4dWypUWNP4ZSDj3WEU3qZsB5gACLff3nc1fsJDfhWY aVYKbeZ6OPmbt/ebSwnjYDlYwjw4A4+hlkwALzgtXIYgWEw/hY9xPAeOw2m4 CY4QDBSMSTJIhCLYAuNhA+yFmZyxUA3ucF9XD4bBWJhFokEEhhAGe0gbuIIb rmEDzpAJMfh7AY6/IDPwDQExLMPdd0Ah1MKf4CcwwhWtoAVd9EL4Fhww84Mg CU7ATd6e3wwGkAcHoRzq4R6xIqWkiz0SqoUm4W+oZQkysAZ/rBKBsA1KcN5B uEDN2H7BWEgSfi+cA1O0vgJR18NZ3Os5kRBfEkTLWKLmlRAlVCAPA9BmtB7F DtF4QCwcwJkt8Jr0Q0mjEvoJDdLoC8NBB0ZhJZqI9vlgZVoHGbAVURRAMRyF ++QTsoJcJI/oQJpK63gvHQ8dj3516h8EZ+E57jEARqO1i2AVJKDmNtgOu1Cz BPf6A8pjUBNrYkNsiSvxJjlkEzlAXtKJ9Dp9zQYxPTaJ+bEAlszaWbcur/bU 5GsuC15CAnJJkHMxetIBcS6EpbAaVPApJEMqWpeNkovsVaBUIp91KN/DDbiD 0gH34QGhhEeMYjIBRYpiQ+aSecSH/JaEERXJJ8dIDaklZ0kXeUqnUms6k3pS bxpGV9NYmksraRWto3fpL2jlLCZnKvYZq2Bn2Dl2hbVywM3jlFw4F8ft4Cq5 H7jH3FNOwwNvhmLFK/m96n0aN42/MF6wEQKFrUIuyn3keCSiGQ/miMcLvRqE lT8MUa2GNSiJyN1GRLQL9iB3WvaOQQ18h1F6Bv3bAJehFfHdgHZ4Ad1Ijhaf IRlNPiYy5HcOcUZZgn6KJ8kklWSTAuS5ilSjnCZtiFKDCH2pH11O42ky3Urz aSE9QU/TFvSEwEToiRHMmbmxRcyfLWexbBf7nH3B9rBiVsNOswaOcrM4Ly6G 28Dlcvu4o1wj18y18VLehs9CqeSr+VN8h2iIyEQ0VaQQ1eiIdBN1O3U18DU0 QhVUQ5+LZJDBpAq+JJ2MY6m0iS6m/WkLSeMuEXP0wGwCfDaeik/Qwo/IFTqd LGJBZAnyl0ZCiT/sZqZsH5sHTXwUUTAvEgwKLh9+5b8HJZ9Fv8KP1yymJt20 AlZANl2lLhf8yCBQkFJahhGTArPBkjOGFjqTO0HGUUtap3OE1ICtjojNZLN0 9fCplN1BMxW6eqQLlKwd8+c25pY3LcOa0EHadDzROjU7inNSwJaUavShnPej AcSUlhJ39Qb1NVYoFBMj2g6g1lfbUQeMOB/hEK2Fv0O+ppu7BbX0Ovhg1Qjq yZwnmHv/IL96Y5s4z/jz3p3vLnb+OCY4TkzqM4edJhcTEv7kn5ecY19IMXgJ TpkP6Go7CUvQtiC1MDFGxValdKZErirRatqkakMbotP0OsDkVHTLt33qJ6ZM Wr+AgHYfxlpNwKQO8J734oSkQ9M+TtrZv/f59z7v89zzvnfve9/DN80BeMRV 4fOUxPfIMX1goP9r4b7enu6unTu2d3Zsa98aatNaW55vDga2qJv9iu+5pk3e xgZPvXtj3QZXrbOmuqrSYa+QJdEm4OkS2gx1KK3QYJoKQXV4OMRkNYOKzBpF miqoGlrfhyppq5uyvqeOPY98pae+3FNf7UmcShjCoTbFUBX6cUxViuTgaAr5 8zHVVOg9i99n8ULQEqpQ8PvRQzE8UzGFkrRi0KETUzkjHcPxCg57VI1O2kNt ULA7kHUgR+vVYwVS308shqs3egscyFWYFW1UYwZtUGMsBcoHjMwEHRlNGTGv 32+G2iiJjqtZCuogrdGsLhC1wlAxSiUrjDLNbgfOKYW2xdxbRSdk01rlhDqR OZyifMZkMWo1jBuj9d+/43kq4uCuaOrsWquXzxmeaYWJudxZhb4/mlpr9bPW NHEM9OUCQ+ncEIZ+C6sYTyoYjZs1U5TMYkiF3Qm7q+X7m1QNpkkfVWiFOqhO 5Y6mcW4acxT2n/TPNzbqC6Wb0GgoubGU6qcDXtXMxDYV6iC3/+SVBl1pWG8J tRWctcuFLVTXlJnKqrXM5KrN4qzujIvvX60sYRmpL+CKoMq4gpmkVLynbtZM dkNuvBu74WUS9KITOCPTtCKazjl7mZ75U1vAqSq5B4ArQL331/WaTFkjBpwP gLFsnayuNbSv8FTTaGsrWyJSFOcUc+y35J2hthNFLqIecypIsHwwgrXNmL3t WH6/n03wuaIOWRTomdHUsqxA1jsPertmUi7NLIsrlo0vMsuZFcuqe1rFlXwV 9y+AjVQOrv5rnO4NxlQvJe7/YJ5ctseTanz0YEoxculybeNj66Rle/eqrczR DdEU7+XKHOflLSsuysOrnZmQqqRCAP+itagnipKMq9LSEGWIOtPDy61p9/v/ S6di6QvmZZGnbuU0aa+2Xu5bJ69LrzLHY8JCkIuPHczl7GttwIomO570Y3vg yQePtsqvWmVce/1O+Bh3VXZ9CXi0Q1yGO7arkBEAAsIEjIqXYbfYA8P869CL tjFECG1voy2A/b9bpm9zPaUS6vcgvkC0IZIIBZFFmIi9iB8gRrke+DXiHPqG mT+j/HlIMd72B6izHYDNSF3CXWgUbkOz6IVh4QaoqAti/O22SkggH7Cdhjqp ifmU/oLyXjGAff6GObwCQeE6dKNvn20W3Jj7brR121pgUDyM8W6DG8f5lfgZ OYp0jy2GOih9LgD/Zxx7DPM4iRji74OBvi8IGuzm9+D93YAQ93OIIjXQvhHR IfwU70mD55Fn+XchbyKdxj4J9NXQvhvrGcFcR/i/wyGk7TjuIf5PcIP8BC4i XcL+O4SHsIF8acUNE5wt9NmFtQJRhAVRJNuQ/gPxUD4ALdJdiOP4L61Qfjsc YbXDHX66XNOT6H8E40T438DRco0ZtrBYMsCnwg2uR4bSebx3RbyAc34aQlib b0p3yY+wVgkLFyCDdB8DjteN6EL0ldFru0rsCAfakyjvEffDOIPkg0703Yqx xtjaQNs2zNNCOf+95fwtinm2Y10jK/7iHmhFH413QXINYBX38bxxH79zLEou os9x9O/nOvA76DT3y2VAlHeV3uFd3EvLFFTkf2hR9CUXYVNkI7i4ZvwFuSDM EDc+HS9b7detdsBq21nLtc+3+3xFbuv8+4y0zTe1INmiO241+jqaXb5wM5Pr 9b5vt/huXm7w3UJ80NzpezPc6Xsd0Y44gTLr13y5xTfTPPOdmTdmzgpd4Hbj LLtqZb1Ibv/2xbqKuoqufJH8Xu+R8h9J+StS/ltSfkLKf0PKD0n5XVJ+q5TX pHxAym+R6mSX7JSr5UrZLsuyKAsyJ4NcVyzd1DX28NeJTkZEgbWCxTs51rIH Hd8EHJE5/LqjG/g4F08O0m4tXpRK+2mXFqfSyKFUgZA5E7WUe7NIYCxVJCWm mvWyXXsBCCnNnveWqWmSOF0ch3hWoQ+TapHY8UVlUwcJdcUhPjboAfeJAc+A q7+2Zyj2jCZdbrWnl0dbe8VHTl4HHznOPr7Iq1ck3zsS0yZRm7e0eabNW1pP E70QT6bo5SaTdjKm1GSSK5Fr+il2DkirxiQiTc+dmPLQM1lFKejXygeEYDo7 PsVoZpJeUydjVFdjSiFy6hnmU8wcUWMFOGWMpQqn9MnYfESPGGomZi5AgmQL rXPrwv14JdwCtJLsv49YJFk2ZCuLmJh7RsQ5Zk6wiHMs4hyLmNATVkRjOjlI 4iOpggyDJm4+Fr3COew4VWmv3xx0O4/1W/PW5/e85v1QAHIJHLgXV+K5rgrB TKFIKMJMuGCYqZod+comz2t9fu+H5FLZ5ER1rToI2nHtK9cr7AKPMR1jwEwW SovcmXmXr1Mz2T7DsS0Iv/7wMcZJ69OfE6Vx1NmEcR7som2c57nGCkkYJ9Ag t3R7tITzfnjf43DC+TC8z/k4DAPhx2GGjm3+Wn9tABtc2/BI4Rcf6Tb4J+44 i9Yud4P7BN99DvAvAE+u6tUVEjRWiQ2VVZ/72bBa4o7zUxjYd69jG6kT1c3B nTt2be90c58svfve0tJ77y5xkWW6ZO2Onf9nP/N/7Ge9r2ARzyo2az44cEI7 6Mjds9VYGmbnzsCln30Uf7km/EBuki31L4av9zE6v/ePt0qlJ/3yZ7IDRcfK SehfAwCQrZZHCmVuZHN0cmVhbQ1lbmRvYmoNMjQgMCBvYmoNPDwgDS9UeXBl IC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgMCAN L0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtNjY1IC0z MjUgMjAyOCAxMDA2IF0gDS9Gb250TmFtZSAvTkpHR05BK0FyaWFsIA0vSXRh bGljQW5nbGUgMCANL1N0ZW1WIDAgDS9Gb250RmlsZTIgMjUgMCBSIA0+PiAN ZW5kb2JqDTI1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5n dGggNjgyOCAvTGVuZ3RoMSAxNzc0MCA+PiANc3RyZWFtDQpIiVxUCXRU5RX+ 7v+/NxOyETCQDeVNHkklkxgIRbY0hEwmoBDIAjqhIJksJEFChtVEI4sIocMi ciCViAgCEkTxhQYaKLSoaG0hhKIVsZZNKOARSHsOYkXm9c5AKfTd8967+/bf /4IAhGEhJPLGFaamlXhc0UD2YeaOLa12e1CojgCy8gBKL503R2v0nJjHsq8B S7+pnorqo3VFTYA1lOkZFdPrpmYlzTkLpGSyzvTKcndZe9i1jYAzkunHK5nR vbrbOxywnuk+ldVzav/81mzWDdsERG6aXlPqhkj227/L9NZqd62nywVax/ls ZX1thru6fOnJJy8CDpbjB0/N7DmcNz+OFX65Z1a5p8B3+AoQzz6DTXU/YviN VbcjRkkE12Ve4vey/++rMi/75f6/+Jat2+6+QDPeoyq8hz/gQ+pkq/exD634 FFHIxgbUYy0aYMFE5vwKBQwq89dSjNmKVGzmfDajnXWfxnzsR0+KNq9gAZbI z9hqCXc6HiOQhxqspDHmXEzCGWUxBmEMZsBDC02XucpcY27FNuyTn5q3EYJY lDK0m9fUL82vkcIW67AeZ2hNlz3I5CgLWfMNzEKTnKyQWWH+yBnY8BznoCAX 7XRI2Nl7OS5RNNVLB3vZYhrmYdbqhcmoRBP200AaKWzqJDPXbEdPjlHLXtdj N/YytOEgvqJQtdPcanYiBsl4gutpxTE6JH23F/mGc8dU7lJfDGFJDX6PP+I4 6fSBqFFD1TQ1U33e/ByR6I8JnO12tvwH3RTzGRbIT5QcMwvh3JdX/d3GxzhH sZRK4+gp0VfUiI1yFoI4Yn+GMlRxv19j76fJTntFqOiQW5Sdyi3Lw76zZjif SCJexxv4gMK4Uo1m00v0BX0jHGKKeF2cl2uVHcoJq5urfgbVWImduEndaTDl 0y+pkuqpgV6l9dROx+myGCHGi2fFdVkpZ8qDShZDoTJbWawuVZdbLvtcvsO+ v/hummnmUuTzPCzi7NdhI1e2Dx04xXAG50mlEApn0MhGE+gFhvm0kt6iZtpB rRzlOJ2nK/QvukG3BBgsIk7YRDyDLmaJ58RasUF0MBwX34l/yygZL+1yoEyX RbKGs2qQqxn2yHNKrNKhmNznNLVRfVNtVneqH6qdllDrS0EIOvrTlttJt0/7 4Fvma/Tt9rWa59CDzzCWu9Ab6Zy9m2Ean3cjT9z7+IxCuXexlEQZNIY7M4Wm 0Uyq5U6+TE20LZD7LjrAXTpJ1znnMNErkPNjYqDIEuMYnhHlYqZYLdaIVvGF +FFaZYjsKnvIJDlSTpblco6sk43SkEfl3+V5+b38icFUgpXeSrySqNiVkcoU Za6yUbmkXFInqUfUi5ZgS7VlqaXN8k/r49YMa5413zrZ+op1r/XzoGKezo+w B7/FfQ+dlYukU+7BKjFAiRHHxDGe5ykok7mCJ1U00zLxIrWKPmqtZZgYRmPR qSRyrz8Rb4rvxTCZS6OpENNE/zveLJEKbyukKx/hqnKAazvGnmstoTRfXLeE YjdBDOGYH8t+il0ewVfyDFmVzfibEkxRdFVsl3k8BQeVDNUFm9yAXXImvYg9 wsnb6VbQCp7jsfQO74XxlEY/SBNSjOUpGiS/wWI8K77EVb7Hy/BrKlMqsAoD qB6X8Dbfir7qDEuSpQf9SVQpXvEQtUIoO7i6IdSHpBqJl2mybLJcF6cwFx1K ME7Ldzn7DrFL5iqdagFV8g14EUsx01yEOtWlnKAKSHoKCcpZ3m71Mk2x8X8B b5VJvNP28u3ez3tghMxlTjRPzhieiwm8IZoYXuM9ofAEVfEdf5q32DG0WsaL NlSo4cRbB1CO+Aow0Xwb680KzDDXIIX3QYNZzx6bcRGvoJmW+F6AB4/wzTlN Y9Qc0aHmmCnCK06JQtH44PlytxMoGt8y7EIOMtTfwaucRCGGmyvMv/J0P8ob dj1K8CQucJXXOMIoeQgDfGNFi5kjPVzvGeSb283eFIxKczrG4QC2WVW4rfZM x4TxIzKHZ/wifdjQIYMHDfz5gLT+/VIfS0m2J/V99GeJCX30eJvW+5GHe8XF xkRH9ewR+VD3bhFdw8NCQ4K7BFktqiIFIdmp5xRrRmKxoSTqo0al+GndzQz3 fYxiQ2NWzoM6hlYcUNMe1Mxkzan/p5l5RzPzniZFaOlIT0nWnLpmtGfrWhtN zHcxvjJbL9KMqwE8N4CvDuBhjNtsbKA5oyuzNYOKNaeRM6/S6yzOZnctIcEO 3VEenJKMluAQRkMYM6J0TwtFZVAAEVHOoS0CQWGclBGrZzuNGD3bn4EhE5zu MiMv3+XMjrPZilKSDXKU6iUG9Cyjqz2gAkcgjGFxGNZAGK3KXw2Way3Jh7wr 2iJQUmwPLdPL3JNchnQX+WN0s3PcbCPq+QvR/yPZeXeHq+F+aZz0OqOrND/p 9TZoxqZ81/1Sm/9bVMQ+2FYk5BR7czj0Cm7i6EKNo4klRS6DlnBIzV+Jv6o7 9ZXrTj+neJpmdNGz9ErvtGI+mlivgYI62+7Y2Mx95lnEOjXveJduM4bH6UXu 7F4tkfAW1P0mJlOLeVCSktwS0e1OY1vCu95FQsPuR8rvyQJYQN2PjS6411ny Z6Q/wQNhaKUaZ+LSuabB/k/5YHhLB7MaP0XEVkYZn0iV0cVR7I0Y6uf77Q01 IULXvDfAE6Bf/e5Bjvsux5IQcQN+1D8n90aN5f/FDbvdSEryj4jVwWfKOWYE 6IEpyfPahK57IjT+cfuQx711Fw1N5fbbbP4DXt6WiRImjIX5rju0hpK43chM tf+H+6oPiuq64ue9d9/b1WhdpWujjBFEE42iKOMX1bqKEpVogrCwbGxFoamR 2NjQpLZj4joo4gqdNI0OUWOBaqVgx8WQBpy0QWcSajrRaaaYtrEf+WCmCZ02 yZjMRAKvv3Pfe+vydIJN2n/K7I/fPed+nXvuuefeVxxTS7im06nxB7km4tTE u5ekIZLbiJ+y/pj39vhvlG9s0orNWTFl7GdUf9Oqz81Py80Lh1JWREts3+YW DJKs+gXxOrsUS8oOacmqXVKTNVmLoFwfb8xCaERMTMHPkEFd1u7xIiqlRknJ iflKVlr/i4enpt5kp3bzfe4l6Vo328xY1vTB8lcHyYPMGxHVYDCuwdyCcDQ6 fFAdQs2acJVNiHgqCKWmZMcoiJM5Bb92s3MBozg5FoDLsrkB4s9S2eKghsl2 uRh/HJ3pM3KQ6KLRnLSUnGhJdGO7GdmUluJLi3ao59Rz0W0rSpzAaTfP7E+O 5dQUw1eblSwcCpWWtaYp1XmtAaU6Pxzq8OE7oLogdFpV1OySZcWtk1EX6kgh CkitylpWspDCAuUqWORp1SvbJ3fgyyEia4VUSLm0XSGp8zo6hUrbVUvnc3Qq dMLSBaSO/zjHZBeEEqNHHsnidL7K8OX0tYG1lO2jq6cGMn1ZMkYT/vSphq3i d4aNmPo6fUNUkB9Y5ZlA39MLKaTspbDaTDsY2gQKiJP0MNo2Q14KPsN90T4I /BVYBBQC423dGmAjkM8y2nZwX4yxjceRXEFh70R6SC80+zHfQb2L7geOotwo 3qYmYyFthXwM/V4URPO5DfocNJqpDvojqC+F7ig4BLkB5fXol2GXh3lq8a0G Bgzop2Gc/fZ679DO0jxRYb6JtRRjzNVAFea4F5wD5KJNEngZsFfpomqly2xE PZgqMf9e1gPLbV6Jcfagfgn6TYZcifJ42GGARwGpwFT1JC1Uv0wvgGdh/UXW uoEu2sxrjq8J9ts2XQ/LxtxEYM5fAWnqQrMHPCzBNjcqXVilZVIEXA4kA3nq q7RV3E0K/PW03kMaw0vEfvoLsFiU0VrICuzM19voEMvAGokKs18coXrtCi1A 3Q+Mg1hHGfyNl6/6Mc1S/0HpxhTaifhajvF3AUcx5t9lPJRRAeafCc4UPTKG qoAazPUvx0/sG8i7sK/rMNenXo7hZsoH7sK+RIAH2R7MP4t9zvuuFA4sRNt3 0GY9A/qvSGDtHJPch/tjrCl2HDZeY2pEm1r49W9gAfjZBgcyzmyg7mWMMw4w gAnATKAHaATKgSzgeWAq5ibMq8l4RcxwbMr4QGzoXfAhbJMxa63hqNxP68w0 2GPxPKnGSSq3kcpj8nnhmIUtrc7YfKY4ZhyW8V3Oca98wOvkmIozzp7opbvY BnkGEVsO87mDzXweDqpBqgYfQhxXcsyyfQ6zXzjWpE9wJmxelLDWDHlGwBpR mh3rlQ47vojzZjqGMUuMTcgp9bRSfBdv7x/RJvE+Ldem0Uw9AzqsB21jai+t 8+Jdjr28B/LTLq5jeLqVLXon1tkCf3bTM/Dpd0S3Okl0K7reYr6rk3Jeb1Ef l+Xr2A2l06pjZiTW/af6zwP1kt6CnNlivqd3mybW8ySfCU+vkgGkOAz9aSAC 3OmdrtR5y5V2T5B8BtEV4CERoCw9QPNFJ/bHjzyPswB9UH+TXtRqaZ/oNv+o RCiidlOVx08b8f00iudSL1Elg8cHb0uIo0Ex544lh514dTPnfDumJoINnL8L Nt6x8THwEeLop4o1x3zOz/J+QI4Gqqx4Na/G4/M8HQfvd+LTFaflrvgc4Y5L N8u7BfndOaewY5+zfs6PnOM4R3Ke4zzjtHdzQv+o2ow45jz8KoXtcz3JxmrY +JZ99pGHsd9FpmnkmCeMNrNJG2M2GXNQ/gOgmyew7u3xOzVkDtj36TTnLrX0 dItzj+qZtNXOZ8dkvvmQnpL3aKG0b5hxinbqfdh35EBpb719BuFP2F0uSuDz Q1SDdYzT9uI8Qg+sZ5/IvSC6le8FvhO1A/Az30W1VKm9gfcC982k0fK+WEJF sP281OFOZWadXkSNRi/NEUHk2k4q473idbA9vPfeR2ik14880U2zxc/Rxk/D 0a5e+iBAJ2RccN9yvH7gC08peRCza9GGx2uQfQI0xvbHMekL2R9vEY4v9gXG NPy0Tr4neuknepCKcIYaPBFqMII4c35qwhjH0S/ItqDfeHlfH6D7cL6qkZuq kXNIxn/Y7NNasJ7tyOuAFoGPWuhWPQIflsu1LxdWjt3L50drpts5RowDyMP8 njhAUTGdVhjlVAtdrY48iXn3Q7cb5zcDZ3cf+k+08zZh7n3Qc98l/JbhNwKf F0+AkoyIfAeQtIHfKZhfe5catNVUjThe6j0AP+yhdNwXCmLvNmC2BSk/bqPG gtT5LFZSNR89JvWZ9JrarN2CuOU7tEPsogdEIc3RZtM4MZrSxe9wVj+hw9oo 2iBeocOinWpYFkk0VcMrXWvD25L1F+le1quvQa6jsFiE/tX0bbGBKrRWxN7v abi4H3uNfvoPESeT0f9DjGtDeZvCWiHOVhXKn5gnuZ2co80sYoiVlC77JUDa 6sBls5oLv63GnsJeLg+yF7bG7XRsvIF9cp08LvpxG3GYFhGZl4EpFg/kqbXU AtSrf6JsbQ19X2lCgjlCOUoPcMTGL2il5FYgD3f8XGUHMFPMpeeBXSjPAP8a OGXJeLvNpTeAPRj7LPhZ/i5gqMtoHjN0R4E64LdOXSJ4rhvpE6En02D5OYow lCtmP8PdHn6eh/nmicXwJ4BYfIJh7KSw51Hs3x3Q34YxXTLmmSOeoy1D2TMU lIuUIX1oIZC4Rmc/wGNvApcTOIXZvhu+kH2fB9jfncDXpX//SX47hr6kXKJJ 4EJwofYIbWdATodc7PhTuYJYYzTRj6U+vn+WHrFCeMctduvdsntfh5LVZ+l4 Ipw4iMfDk7SbIZagPeCWvedpN8N4CXUvXS+LE0MgTHdqh6RNJGPMJRv34M4E 1MmwdbzsU8OIyxdxlgFuK/uPpFqGPLuA2kYPMOL1c5G/gQS/zmO/Yk5Z7+yP sy/u/YF9AXEBCOOuuEAZ4HzwUofj8W3ni0Exn2fFe1zmXNLjanPtTFw7Gxf5 rrnxmP9PwNl5BegCXv5fz8VZhnOEj/PEZbxDluAd2Y33yX1USdSPXPLpLOBn yEMF4Nehw+09MA0YifJo6L4Ffoao7yOUH4a+24KpimSqt9+V46D7pd3Xa4+X b/Xv+w3RVUTU1VNW/75mYAvKHwCPofxn8FlwHdq/h367wees+v4NkB8FXoDc C/lBIITyE2A/eAaQBIxB/4MMfo9c9x36X+cbf3/cLOPNUgo7J4LPgHe4vyFu mp39HILd3xrO/g/Fuv0tcT1bfsA301t498USv30+6xvHYeznQCJE0OzHm3IE v6P5Lcvv53+zX/6xTZxnHH/e9xz7Egh2XJqkxPGd88NATAm4dIEkxedgLxSr JEDK4iwjCSEtUCRQnYBUafSYhlTUlqBOYoVJC+OPaVpVcbGrzAlIyZStWzM2 qo0xqT+h8Mf6R5dSbe3oirzve3eBsYHa/TVN8p0/z/O8z/u9933vufP5bL4/ 2t78/2a+x2JeooVzHuspFO+v4t1ZvL/C/wj+OWeBuZ7Hsa5esa7RDne0Siqj WZADEimw9aAN9IBhMAKc5LYze8GzYBJ8bPZoUln6pYe0LNzzpsvs3hM2m31W s/tbZjPzjaTlH9tk+dijlqzRkq1cZaWXt1h+8TLLe2vDuvBFxeGpaKlUSm8C TvtgGf8FuRkjhU5J95MBuOS0M5rkzdQEwyOTkoOYxCVGO0jJTUksXVwSjhbx HJ8lL+61v/CPrB7+UWZBSXgkuoF/QGfAJJD4B9iv8Cv4Yb+MZ4YHNgJGwCS4 AGaBk1/G/j729/h75ObvUj2IgB4wAibBLHDxd2E9/B3xBDKtiCOA83dgPfxt nNbbsG68hjL+Fn8LS/tDumFNeNwMQvV2oNTaQVmFHXhLw1n++/SNpUqWX82o IeVUdAW/SAbgmOwiBr9IKmgHvWAfcCK6hOgS6eAYOAUMgL83sB6g8hlwHlyi FUAD7UDmb6YxTZZfSAdblGgp/x3/FZWhqL/lvzb9ef666X/Df2n6N+D98DP8 9bRfoeg89BOO8cB74OvRX8B/nqnxKrloCZ9EeRTYehABbaAHDAMnn+RV6R2K F4OcpRk8XBWepg9N/2M6LZO2W9GC63CPqcIEGx9BBDOijgS5Fjx+Ak1hgkdf QiRM8LsvIBIm+MwhRMIE9+xHJExwx25EwgS7ehAJE2zrQAST5T/8Wc1ipaHt KaZG3fwAqnQAVTqAKh0gBz8gdrrhEGv7QbquDhU7qYWW1in6BNPPMX0z008z fYDpB5l+iOnNTN/G9BDTfUz3M11j+lm2GqXQmfbaHc01WjnTZ5j+KtNTTA8y vZbpNUxXWYOW5YH0ow+ZLm66TFR8r+AfWRt2Y40BVDSA2zqAr/0k7AWQM1sa RGqVJX7AL3xVpi5itZc3hvdG1/NpHDiNyzBN7wMHLtA0bqNpDDKNAdywEdAD psAsyAEn1FVY+LBp3bD1IAJ6wLNgFjjN5cwCTnvtJZ4xF1ZvL7pNtPg09irs AR7QKj0+T8izXhr2Mbeftflzft5ApfhTQN4SuSTLisc+K/77Z8VUGC3kR/kw VeJCHLP9cPpGpZJlL6eDZ5Xo/ez75HfgrmNrKMhq4Vfj/VK0HyafLPwq8vFX 4MNp31Yc5k4HlykTbIE4aky54bumfOjLcoR/9p1V/qRmHSyt/BGZV8aUi74j yhv1WRmZc8Esg5tQTem4b7Xy6owpPYSOk2nloHBjyrd9rcpTPrNjwOrYlkJL cyubg13KeowX821XtBTGHFMivm1Ks6V6WBwzpqzAEkJWWIfFLvWZk1b7zQEf b8iyndoy13FXp6vN9TVX2LXMFXAprkpXhWuh7JU98gJ5vlwky7JTdshcJnlh NndZC+E1mBY6PcKJHz380zFjDxcWxnyuMZnTBjLukxI8saWFJYypfkpsV41P t1RnWdGmLqOguoUZ3gQlOlqM1aFE1pXbbDSEEoar/Zudo4wdTSJr8OeyjDo6 sywnUocrDO+6znFirOTwixXCLzn8YjJJ5aX7I+UR79qSNV+P3cX02jZ0eyu/ I640jie2dBo/rUwaYRHkKpMJ43tb1O7OcfYJ+zgeG2fXhUt2jktr2SfxzSIv rY0lk4ks22rqSGXXocMdc93UyX5ShY5U2W/pTlq6WhwPXY1w0BUWUq2pqy0s NHUOJnSjqZp4bLSmxtSUqZQyNaky9V81M7XQ1NaamlKdZkzNTKkuNMZaU+Lz QeL3mRK2iHymxMcWmZKttyX1tuTILckRcyaJ3db4LE3x5TlN8WVoQl91G2gJ hVimKdnfHR+ojvdWxwdAr/H8/p3lhr5dVUf7k6JDNaRg7/b+ncL3DRjJ6oGY 0V8dU0ebuu/S3S26m6pjo9Qd7+gc7dYGYukmrSle3RdLZlrbVzXcMdeRW3Ot ar/LYO1isFVirtaGu3Q3iO5WMVeDmKtBzNWqtZpzkXmPt3eOytSSXNdt+Qyf V4T7tbcikGwp9exba968TYHygxUTDvHPdF4oacyvbjGKgeh6MPpgVHThOyW6 FiDttrvKDzYFKibYT+wuD9Il1S0UGhxKDVF5fFfM+qSwITU4JApu2VDqXhv6 4obWF0sNEiWMui0JI7Kpq3PU5UK2V5yS0TiXmzcvns1NWcnlSDaKpCTdEopc s8gVFtrC/7z+Q7ZfJ74FOj+bYZqfDVIqKRn+RAfHo6CjC+fa3dU5gdcl8fOQ SuIEUyzEUnNjmMsmKyZxvnMMDtmRXYdB21tH4ZDUXDlubaJK4jmF51UBdvy4 uKjlNc6uOV1ZfkK7jwoc1yQqcjmuMXpAdhZc49I5vpIK2Qm2nMpDnk+bbzZv 9Py1+bGbzRRB7PkCZuWKQEmgpBYGT0X6QpWmvtAK6B+kOqbI3vbkyZMnT548 efLkyZMnT548efLkyZMnz/8ITozEtpAkEbFFwElfuklfLvn/3hy0xLQOsz5q LmfZ3FW7Xl+lBDI9Yaslmg/L7JHnY7diJ6JyUXlHITLlVGPHnBZQsx1LyG+w Ywfi7XbsRPzMxg2trRujoejTu/r23CumjTi+FftGilIIPE27qA9XfzMN0JM0 hKgPuXup/ts8zqxgCUyE+qkAZ+KhetqK0y5GDSW0RUmPoUcWxbVKbHl6gntR pFvbv5czgo00UkmVxTDn5fnSy3ZV+edX1l84tqLH3fw3uUI21aevLq4TPlvy ncDnZ24+6WmUxTUQdTZH/ucA+yT1IAplbmRzdHJlYW0NZW5kb2JqDTI2IDAg b2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL0NJREZvbnRUeXBlMiAN L0Jhc2VGb250IC9OSkdHTE8rU3ltYm9sTVQgDS9Gb250RGVzY3JpcHRvciAy MiAwIFIgDS9DSURTeXN0ZW1JbmZvIDw8IC9SZWdpc3RyeSAoQWRvYmUpL09y ZGVyaW5nIChJZGVudGl0eSkvU3VwcGxlbWVudCAwID4+IA0vRFcgMTAwMCAN L1cgWyAxMjAgWyA0NTkgXSBdIA0+PiANZW5kb2JqDTI3IDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjE3ID4+IA1zdHJlYW0NCkiJ VFA9T8UwDNzzKzyCGJIXIQFS1eWxdOBDtLDnJW6JRJ3ITYf+e5KofYjBtnz2 6c6W5+65I59AvnOwPSYYPTnGJaxsES44eYKTBudt2rua7WwiyEzutyXh3NEY oGmE/MjDJfEGN8PwdKduQb6xQ/Y0ZeRef35lpF9j/MEZKYGCtgWHo5DnFxNf zYwgK/EPHLaIoGt/2rWDwyUai2xoQmiUenhsj4Lk/s8P1mW034bFsa2V1q3I 2zteeOWmqw+7MmeL9fBqpFjwhNffxBCLWgnxK8AA7YxqmAplbmRzdHJlYW0N ZW5kb2JqDTI4IDAgb2JqDTw8IA0vUyAvRCANPj4gDWVuZG9iag0yOSAwIG9i ag08PCANL051bXMgWyAwIDI4IDAgUiBdIA0+PiANZW5kb2JqDTMwIDAgb2Jq DTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMzUgMCBSIDEgMCBSIDQgMCBS IDcgMCBSIDEwIDAgUiAxMyAwIFIgXSANL0NvdW50IDYgDT4+IA1lbmRvYmoN MzEgMCBvYmoNPDwgDS9DcmVhdGlvbkRhdGUgKEQ6MjAwNTAyMTcwMDE3MDMt MDYnMDAnKQ0vTW9kRGF0ZSAoRDoyMDA1MDIxNzAwMTcwMy0wNicwMCcpDS9Q cm9kdWNlciAoQWNyb2JhdCBEaXN0aWxsZXIgNS4wLjUgXChXaW5kb3dzXCkp DS9BdXRob3IgKFJheSBQbGFudGUpDS9DcmVhdG9yIChQU2NyaXB0NS5kbGwg VmVyc2lvbiA1LjIpDS9UaXRsZSAoTWljcm9zb2Z0IFdvcmQgLSBDb21tdW5p dHlBdXRob3JpemF0aW9uUDEuZG9jKQ0+PiANZW5kb2JqDTMyIDAgb2JqDTw8 IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5ndGggMTEzMCA+ PiANc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49JycgaWQ9J1c1TTBNcENlaGlI enJlU3pOVGN6a2M5ZCcgYnl0ZXM9JzExMjknPz48cmRmOlJERiB4bWxuczpy ZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1u cyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPjxy ZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9ucy5hZG9i ZS5jb20vcGRmLzEuMy8nIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNv bS9wZGYvMS4zLycgcGRmOkNyZWF0aW9uRGF0ZT0nMjAwNS0wMi0xN1QwNjox NzowM1onIHBkZjpNb2REYXRlPScyMDA1LTAyLTE3VDA2OjE3OjAzWicgcGRm OlByb2R1Y2VyPSdBY3JvYmF0IERpc3RpbGxlciA1LjAuNSAoV2luZG93cykn IHBkZjpBdXRob3I9J1JheSBQbGFudGUnIHBkZjpDcmVhdG9yPSdQU2NyaXB0 NS5kbGwgVmVyc2lvbiA1LjInIHBkZjpUaXRsZT0nTWljcm9zb2Z0IFdvcmQg LSBDb21tdW5pdHlBdXRob3JpemF0aW9uUDEuZG9jJy8+CjxyZGY6RGVzY3Jp cHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8nIHhtbG5zOnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LycgeGFwOkNyZWF0ZURhdGU9JzIwMDUtMDItMTdUMDY6MTc6MDNaJyB4YXA6 TW9kaWZ5RGF0ZT0nMjAwNS0wMi0xN1QwNjoxNzowM1onIHhhcDpBdXRob3I9 J1JheSBQbGFudGUnIHhhcDpNZXRhZGF0YURhdGU9JzIwMDUtMDItMTdUMDY6 MTc6MDNaJz48eGFwOlRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9 J3gtZGVmYXVsdCc+TWljcm9zb2Z0IFdvcmQgLSBDb21tdW5pdHlBdXRob3Jp emF0aW9uUDEuZG9jPC9yZGY6bGk+PC9yZGY6QWx0PjwveGFwOlRpdGxlPjwv cmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHht bG5zPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgeG1sbnM6 ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpjcmVh dG9yPSdSYXkgUGxhbnRlJyBkYzp0aXRsZT0nTWljcm9zb2Z0IFdvcmQgLSBD b21tdW5pdHlBdXRob3JpemF0aW9uUDEuZG9jJy8+CjwvcmRmOlJERj48P3hw YWNrZXQgZW5kPSdyJz8+CmVuZHN0cmVhbQ1lbmRvYmoNeHJlZg0wIDMzIA0w MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwODMyODIgMDAwMDAgbg0KMDAwMDA4 MzQzMyAwMDAwMCBuDQowMDAwMDgzNTc5IDAwMDAwIG4NCjAwMDAwODY2NDgg MDAwMDAgbg0KMDAwMDA4Njc5OSAwMDAwMCBuDQowMDAwMDg2OTU3IDAwMDAw IG4NCjAwMDAwODk5NjYgMDAwMDAgbg0KMDAwMDA5MDExNyAwMDAwMCBuDQow MDAwMDkwMjg2IDAwMDAwIG4NCjAwMDAwOTI4MDIgMDAwMDAgbg0KMDAwMDA5 Mjk1NiAwMDAwMCBuDQowMDAwMDkzMTQwIDAwMDAwIG4NCjAwMDAwOTYwNTkg MDAwMDAgbg0KMDAwMDA5NjIxMyAwMDAwMCBuDQowMDAwMDk2MzczIDAwMDAw IG4NCjAwMDAwOTY3ODIgMDAwMDAgbg0KMDAwMDA5NzE3OSAwMDAwMCBuDQow MDAwMDk3MjgxIDAwMDAwIG4NCjAwMDAwOTc0MzQgMDAwMDAgbg0KMDAwMDA5 NzYxNCAwMDAwMCBuDQowMDAwMDk3ODM0IDAwMDAwIG4NCjAwMDAxMTA3OTEg MDAwMDAgbg0KMDAwMDExMDk5NiAwMDAwMCBuDQowMDAwMTE3NjU3IDAwMDAw IG4NCjAwMDAxMTc4NjIgMDAwMDAgbg0KMDAwMDEyNDc4MCAwMDAwMCBuDQow MDAwMTI0OTk2IDAwMDAwIG4NCjAwMDAxMjUyODcgMDAwMDAgbg0KMDAwMDEy NTMxOCAwMDAwMCBuDQowMDAwMTI1MzYyIDAwMDAwIG4NCjAwMDAxMjU0NjAg MDAwMDAgbg0KMDAwMDEyNTcxOSAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXpl IDMzDS9JRFs8N2Q5MjFiYWZkODU2MTc2NjEwMGRiMWNkMWQ2N2EyNGE+PDg5 NmMxNTM3Y2NkMTFmN2I4M2MxMTlkYTlkMTc2MDZkPl0NPj4Nc3RhcnR4cmVm DTE3Mw0lJUVPRg0= ---1903330751-914646686-1110471466=:30645-- From owner-grid@eso.org Thu Mar 10 19:35: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 j2AIZJOm025396 for ; Thu, 10 Mar 2005 19:35:19 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2AIZJTk025395 for grid-outgoing; Thu, 10 Mar 2005 19:35:19 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2AIZDOm025388 for ; Thu, 10 Mar 2005 19:35:14 +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 j2AIZBpB013389 for ; Thu, 10 Mar 2005 19:35:12 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:63644) by ppsw-2.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.132]:25) with esmtp id 1D9SUv-0005lI-6f (Exim 4.44) (return-path ); Thu, 10 Mar 2005 18:35:01 +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.12.10+Sun/8.12.10) with ESMTP id j2AIYxoL027602; Thu, 10 Mar 2005 18:35:00 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2AIYxRN022462; Thu, 10 Mar 2005 18:34:59 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2AIYxts022459; Thu, 10 Mar 2005 18:34:59 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 10 Mar 2005 18:34:59 +0000 (GMT) From: Guy Rixon To: Ray Plante cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.10.9 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray, thanks for the comments. regarding "single registration", I do of course mean each user registering just once rather than all users registering at one point. We have a per-project registration in the UK. The national e-Science programme operates a CA with registration authorities in each university. The Cambridge RA isn't in our department, it's in the central computing service down town. The CA itself is at RAL. To get a certificate, I have to apply to the CA, then make an appointment (!) to see the RA then drive across town with my (physical, none-M$) passport (!) and sign for the certificate (!), then go back to the office and extract the actual certificate from the on-line system. The whole process sucks, and one would have to be desparate (or silly) to use that system. We need something a lot more user-friendly. For the early days, we can register users remotely at project-level CAs, based on email and phone checks. As the user-base grows, this system will fail to scale and I still think we'll go back to department-based registration. However, departments may be able to register guests from other HEIs; it will just take longer to check those applications. In the UK, JISC is getting ready to set up Shibboleth registration-points all over the accedemic community. Part of Shibboleth is a service that emits SAML statements to do with users being logged on. Our authorization tickets may also be SAML statements. We may be able to merge our community services with Shibboleth's facilities such that users registered with Shibboleth can automatically use the VO. More likely, it will work the other way: our community services will be valid as identity agents in Shibboleth. Your weak certficates: how does a receiving service distinguish them from a strong certficate? Do they have a different CA? Cheers, Guy On Thu, 10 Mar 2005, Ray Plante wrote: > Hi Guys, > > (no pun intended.) > > I think the time is right to try to tackle this on in the VO. I pretty > much agree with Guy's write up. I just want to share my current take on > some of the issues he brings up. I also want to share part 1 of a 3-part > white paper (attached) I'm working on addressing authorization issues > (but which also talks about authentication). I think it's largely > consistant with Guy's vision. One caveat about the white paper: it is > meant to layout how we could manage authorization using a particular grid > tool (Globus Community Authorization Service); however, the model need not > be dependent on this. I think an equivalent system could be assembled > using, say, Shibboleth. > > > single sign-on > > Yes! > > > single registration system > > As Guy points out, if we want trust to transfer across administration > domains, we need to minimize the number of roots of trust (i.e. CAs). A > single registration system for the global VO would do it; however, > administratively, I'm not sure how practical this is (because services > need to be maintained...$$$...and the whole thing). So, I was thinking > perhaps this might be handled on a per-project basis--e.g. NVO, > AstroGrid/EVO, JVO, etc.--and then these projects would agree to trust > each other's CAs. At least a per-project approach might be a good first > step to ultimately a global CA. > > > where to register (home institutions) > > I'm not sure how doable this is in the near-term for a few reasons: > > o I'm not sure I could convince anyone at my home astronomy department > (let alone someone higher up in the University food chain) to take > this responsibility. Perhaps after VO gets more community traction, > this would be more practical. > > Shibboleth operates this way, but typically it leverages the > university's library, which already manages users on a university > level. I guess if we use Shibboleth, perhaps we can leverage this > infrastructure. > > o Many legitimate users may not be part of an institution that can > readily manage approval. In addition to amateurs and astronomers > working in industry, I think we might include the lone astronomer at > a small teaching college. > > Nevertheless, strong trust starts with trusted humans, so this may be the > only practical way to do it on the large scale. I'll note that > observatories have an operational trust model when the dole out telescope > time. Perhaps we can leverage this. > > On Thu, 10 Mar 2005, Paul Harrison wrote: > > * In the document you talk about "less-trusted" entities - surely in a > > trust model something should either be trusted or not-trusted, there can > > be no degrees of trust. > > Actually, I think we do need to support "less-trusted" entities, as the > attached document argues. Many services we'll want to provide, including > VOStore, do not actually require that the user connecting is actually who > they say they are; they only need to guarantee that the person connecting > is the person who originally, say, created the space. This is the model > for the hundreds of portals we already have logins for today to which we > could have registered a fake name. > > I have proposed the concept of a "weak" certificate. These are less > trusted certificates that are granted without a human in the loop as is > done with a traditional "strong" certificate. > > cheers, > Ray > > > > 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-grid@eso.org Thu Mar 10 19:45: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 j2AIjQOm026483 for ; Thu, 10 Mar 2005 19:45:26 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2AIjQBj026482 for grid-outgoing; Thu, 10 Mar 2005 19:45:26 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2AIjGOm026467 for ; Thu, 10 Mar 2005 19:45:17 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2AIjEkW026088 for ; Thu, 10 Mar 2005 19:45:15 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu X-Envelope-To: Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2AIj6e15180 for ; Thu, 10 Mar 2005 12:45:06 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2AIj6Wh011119 for ; Thu, 10 Mar 2005 12:45:06 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2AIj6BZ011115 for ; Thu, 10 Mar 2005 12:45:06 -0600 Date: Thu, 10 Mar 2005 12:45:06 -0600 (CST) From: Ray Plante To: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.10.9 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 10 Mar 2005, Guy Rixon wrote: > Your weak certficates: how does a receiving service distinguish them from a > strong certficate? Do they have a different CA? Yes. And the name of the weak CA explicitly features the word "Weak" in it. Applications then may choose whether to trust this CA depending on their security needs. See document for details. An important point of the weak cert is to avoid the pain-in-the-ass processes we have now when it isn't needed, but to be compatible with it when it is. cheers, Ray From owner-grid@eso.org Fri Mar 11 10:02:30 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 j2B90dRM007257 for ; Fri, 11 Mar 2005 10:00:39 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2B90dYK007256 for grid-outgoing; Fri, 11 Mar 2005 10:00:39 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2B90ZRM007236 for ; Fri, 11 Mar 2005 10:00:36 +0100 (MET) 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 j2B90Z210873 for ; Fri, 11 Mar 2005 10:00:35 +0100 (MET) Message-ID: <42315E33.9050700@jb.man.ac.uk> Date: Fri, 11 Mar 2005 10:00:35 +0100 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: grid@ivoa.net Subject: Re: SSO authentication: a new approach References: <42303EEC.9010804@jb.man.ac.uk> 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-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: >Paul, > >thanks for the comments. > >The "less-trusted" entities are the case where I trust some service to perform >a specific action, which I state via authorization tickets, but not to use my >other privileges. I think this _is_ a form of partial trust; maybe it bneeds >better explanation. > > I still think that we should distinguish between trust (i.e. do we know that the entity is what it says it is - i.e. it has identity signed by a certificate authority that we know) and the privileges that we assign to that identity. I realise that this is not quite the same semantics as the ordinary english language word "trust", but I believe that it is the meaning that is attached to the word in the security world. In the discussion so far of "less-trusted" or "weak certificates" - what is actually meant is lower priviledges assigned to an identity that is still confirmed by reference to a CA signature, in just the same way that a "strong certificate" - i.e. as far as the cryptographic confirmation of the identity goes there is no difference. I might just be being a pedant, but whatever words we use, this way of thinking is important in the design. Paul. From owner-grid@eso.org Sun Mar 13 10:29:08 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 j2D9SFnx021428 for ; Sun, 13 Mar 2005 10:28:16 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2D9SF2Z021427 for grid-outgoing; Sun, 13 Mar 2005 10:28:15 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2D9SBnx021422 for ; Sun, 13 Mar 2005 10:28:11 +0100 (MET) Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2D9S9pB021211 for ; Sun, 13 Mar 2005 10:28:10 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:42786) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp id 1DAPOE-0006FL-Sy (Exim 4.44) (return-path ); Sun, 13 Mar 2005 09:28:02 +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.12.10+Sun/8.12.10) with ESMTP id j2D9S2oL000621; Sun, 13 Mar 2005 09:28:02 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2D9S2RN003834; Sun, 13 Mar 2005 09:28:02 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2D9S1t8003831; Sun, 13 Mar 2005 09:28:01 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Sun, 13 Mar 2005 09:28:01 +0000 (GMT) From: Guy Rixon To: Paul Harrison cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <42315E33.9050700@jb.man.ac.uk> Message-ID: References: <42303EEC.9010804@jb.man.ac.uk> <42315E33.9050700@jb.man.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.13.0 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Fri, 11 Mar 2005, Paul Harrison wrote: > I still think that we should distinguish between trust (i.e. do we know > that the entity is what it says it is - i.e. it has identity signed by a > certificate authority that we know) and the privileges that we assign to > that identity. I realise that this is not quite the same semantics as > the ordinary english language word "trust", but I believe that it is the > meaning that is attached to the word in the security world. Can you suggest a term to replace "trust"? > In the discussion so far of "less-trusted" or "weak certificates" - > what is actually meant is lower priviledges assigned to an identity that > is still confirmed by reference to a CA signature, in just the same way > that a "strong certificate" - i.e. as far as the cryptographic > confirmation of the identity goes there is no difference. > > I might just be being a pedant, but whatever words we use, this way of > thinking is important in the design. > > 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-grid@eso.org Sun Mar 13 11:08: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 j2DA80nx023611 for ; Sun, 13 Mar 2005 11:08:00 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2DA80Vf023610 for grid-outgoing; Sun, 13 Mar 2005 11:08:00 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2DA7unx023592 for ; Sun, 13 Mar 2005 11:07:56 +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 j2DA7skW003842 for ; Sun, 13 Mar 2005 11:07:54 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:43694) by ppsw-4.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.134]:25) with esmtp id 1DAQ0X-00003m-Dj (Exim 4.44) (return-path ); Sun, 13 Mar 2005 10:07:37 +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.12.10+Sun/8.12.10) with ESMTP id j2DA7aoL001143; Sun, 13 Mar 2005 10:07:36 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2DA7aRN003906; Sun, 13 Mar 2005 10:07:36 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2DA7apa003903; Sun, 13 Mar 2005 10:07:36 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Sun, 13 Mar 2005 10:07:35 +0000 (GMT) From: Guy Rixon To: Eric Saunders cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.13.1 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Eric, you've given us a lot to think about. I'd like to reply first concerning your initial question and your detailed sequence of operations; I'll defer discussion of the other web-of-trust model to later email. On Thu, 10 Mar 2005, Eric Saunders wrote: > Guy, > > I have a couple of issues with the trust model as it's been defined here. > > Firstly, what is the benefit of allowing fully trusted agents other than > your personal user agent to assume your identity? If each step of a > workflow is authorised, then it follows that the whole workflow must be > valid. If you run a workflow or similar long-running experiment, and if you leave it to run unattended, then something has to be left in charge, activating each stage of the experiment when it comes due. If this is your personal user-agent (running as a background process on your desktop PC, say), then you don't need any other agent to have access to your full set of privileges. However, if your local user-agent isn't running all the time (e.g. it is on your lap-top) then you may have another agent, on a server, quite probably associated with your portal/community, looking after things for you. In this case, it helps for the latter agent to have all your privileges at hand. The set of tickets you generate to authorize bits of an experiment varies according to which services you choose. If the agent doing the workflow has all your privileges, then it can choose among equivalent services at the time of execution to optimize thing; if it doesn't, then you'll have to choose all the service and issue all the tickets when you set the experiment up. > Consider the following simple example. I want to run a set of simulations > on some remote facility, and have the final output returned to my VOSpace > for further processing. The delegation proceeds as follows. You've made a few assumptions in this sequence that don't hold for all likely use cases. I'll point them out as they come up. > 1. I instruct my user agent. > > 2. My user agent contacts the portal agent for the facility and makes the > request. My user agent provides the portal with a single use 'ticket' > which allows the portal access to a single directory of my VOSpace, for > writing only, with a short but reasonable expiry date. You're assuming that your user agent can do this. If it's a web browser, then it probably can't issue tickets by itself. It might be able to get the tickets from, say, your community, but it may be difficult to push these tickets back to the portal (would they go as HTTP cookies, perhaps?). > 3. The portal agent verifies my community and decides to trust me. > > 4. The portal agent authorises cpu time and temporary scratch disk > allocation from separate services at the remote facility, *using its own > identity*. These facilities are completely abstracted from everybody > beyond the portal. This assumes that the portal itself has privileges at the remote facility. Can we require this in all cases? If the privileges are actually tied to your identity, then either the portal can't use them; or you need a ticket authorizing the portal to do so; or you need to open your identity and all privileges to the portal. > > 5. The job runs. The portal agent uses the ticket to dump the data from > the internal data store to my VOSpace location. The ticket is now > invalidated. The portal returns a status message to my user agent. You're assumming that the data flow to VOSpace via the portal. This is undesirable since it involves two transfers of every byte. Some systems may want to move the data direct from the producer to VOSpace. AstroGrid's CEA does this routinely. If the data go direct from the remote service to VOSpace, then the ticket for access to VOSpace has to be passed to the remote service. It has to authorize that service, not the portal. Therefore, either the user agent has to be made aware of the specific service being used, or the portal has to be able to make of get a new ticket without reference to the UA. > In this example, we only had to export our user privileges to access the > final data write back. When we did so, we minimised the extent of these > privileges. If we needed other services requiring user privileges, the > same temporary ticket model still works. This is just an example of the > Gang of Four 'Facade' pattern: allow encapsulation of a subsystem using a > high-level interface, simplifying subsystem usage and hiding structural > details. I like encapsulation, too. That's why I think it's useful to make the portal fully trusted and authorized: so that we don't have to break encapsulation by passing authorization details up to the UA. > In this case, our high-level interface is simply the set of > allowed personal actions which we make available to the other components > of the workflow. We could even make this explicitly OO by passing the > interface API of our agent to the other workflow components. Now, when > the portal wants to give us our data back, it calls a 'dumpDataToVOSpace' > method on our user agent, which verifies the portal is allowed to do this, > then goes ahead and unlocks the storage location, passing back a suitable > URI or whatever to the portal. The idea of a callback for authorization - it's usually called "pull authorization" - is good. However, the agent making the authorization responses needs to be on-line all the time. As discussed above, this may be a job better done in the portal, or in the community service. > > The advantages of this approach are the same as those of encapsulation in > any other piece of software. The less each component knows about each > other component, the less can go wrong, whether maliciously, because of > bugs, erroneous assumptions or simply poor security. Each component is now > effectively sandboxed. > The other big advantage is that we are not giving away our private > identity to arbitrary software entities, and simply trusting that they > will do the right thing, now and forever. This is inherently risky, > because if a single point in the trust model ever fails, we lose our > identity integrity permanently. I agree with both points. However, I think there are cases where the encapsulation counts than the restriction of the identity. Regards, 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-grid@eso.org Mon Mar 14 07:11: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 j2E6Aj8s014384 for ; Mon, 14 Mar 2005 07:10:45 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2E6Ajnn014383 for grid-outgoing; Mon, 14 Mar 2005 07:10:45 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2E6Ad8s014332 for ; Mon, 14 Mar 2005 07:10:39 +0100 (MET) Received: from 21cn.com (send.forptr.21cn.com [202.105.45.48]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id j2E6AKpB008042 for ; Mon, 14 Mar 2005 07:10:23 +0100 (CET) Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6 P2) with SMTP id jma42355eac; Mon, 14 Mar 2005 14:12:07 +0800 Received: from 21cn.com([10.2.1.3]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Mon, 14 Mar 2005 14:12:07 +0800 Received: from apollo.hq.eso.org([10.2.100.2]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm3742307ad3; Thr, 10 Mar 2005 20:11:07 +0800 Received: from apollo.hq.eso.org([134.171.42.42]) by 21cn.com(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 10 Mar 2005 20:13:53 +0800 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 j2ABQokW011745; Thu, 10 Mar 2005 12:26:50 +0100 (CET) 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 j2ABQKR5026285 for ; Thu, 10 Mar 2005 12:26:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2ABQKwH026284 for grid-outgoing; Thu, 10 Mar 2005 12:26:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2ABQGR5026276 for ; Thu, 10 Mar 2005 12:26:17 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.4.129]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2ABQDpB000210 for ; Thu, 10 Mar 2005 12:26:13 +0100 (CET) Message-Id: <200503101126.j2ABQDpB000210@rocky.hq.eso.org> Received: from [143.210.36.14] (helo=gnowee) by artemis.le.ac.uk with esmtp (Exim 4.44) id 1D9Lnr-0005Zb-LK for grid@ivoa.net; Thu, 10 Mar 2005 11:26:07 +0000 From: "Tony Linde" To: Subject: RE: VOSpace discussion Date: Thu, 10 Mar 2005 11:26:05 -0000 Organization: University of Leicester MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUlYr25h+7Sav97S+q2CwoLacyrLQAAOcIQ X-UoL-Id: 975e1f30b9281700c3b86d2dc2e25ecb@1D9Lnr-0005Zb-LK@artemis.le.ac.uk X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.13.21 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.10.2 X-Virus-Scanned: by amavisd-new X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-grid@eso.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Tony.Linde@leicester.ac.uk Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I've asked the organisers of the Kyoto Interop meeting for a BOF at which VOSpace can be discussed prior to a new workgroup being established (did this before I knew it had been raised in this forum). I still think VOSpace needs its own workgroup but will open the discussion here. Cheers, Tony. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy Rixon > Sent: 10 March 2005 10:43 > To: grid@ivoa.net > Subject: VOSpace discussion > > Two meetings were held on 2005-03-07 in which VOStore and > VOSpace were discussed. The minutes are at > > http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceBrainstormMeeting > > These were not official IVOA meetings, but should inform the > discussion on this list. The people protoyping VOStore were present. > > 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-grid@eso.org Mon Mar 14 11:04: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 j2EA4S8s012581 for ; Mon, 14 Mar 2005 11:04:28 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2EA4R47012580 for grid-outgoing; Mon, 14 Mar 2005 11:04:27 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2EA4N8s012572 for ; Mon, 14 Mar 2005 11:04:24 +0100 (MET) Received: from apollo.le.ac.uk (apollo.le.ac.uk [143.210.16.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2EA4MkW025550 for ; Mon, 14 Mar 2005 11:04:22 +0100 (CET) Message-Id: <200503141004.j2EA4MkW025550@apollo.hq.eso.org> Received: from [143.210.36.14] (helo=gnowee) by apollo.le.ac.uk with esmtp (Exim 4.44) id 1DAmQq-0006tJ-Vb for grid@ivoa.net; Mon, 14 Mar 2005 10:04:17 +0000 From: "Tony Linde" To: Subject: RE: VOSpace discussion Date: Mon, 14 Mar 2005 10:04:17 -0000 Organization: University of Leicester MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200503101126.j2ABQDpB000210@rocky.hq.eso.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUlYr25h+7Sav97S+q2CwoLacyrLQAAOcIQAMZaIYA= X-UoL-Id: e03d30ba4d71d4ef2413449780197249@1DAmQq-0006tJ-Vb@apollo.le.ac.uk X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.14.1 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Not sure why this has reappeared but, as I said earlier, this request has been cancelled since Guy has scheduled a VOSpace session under GWS. T. > -----Original Message----- > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Tony Linde > Sent: 10 March 2005 11:26 > To: grid@ivoa.net > Subject: RE: VOSpace discussion > > I've asked the organisers of the Kyoto Interop meeting for a > BOF at which VOSpace can be discussed prior to a new > workgroup being established (did this before I knew it had > been raised in this forum). I still think VOSpace needs its > own workgroup but will open the discussion here. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-grid@eso.org [mailto:owner-grid@eso.org] On > Behalf Of Guy > > Rixon > > Sent: 10 March 2005 10:43 > > To: grid@ivoa.net > > Subject: VOSpace discussion > > > > Two meetings were held on 2005-03-07 in which VOStore and > VOSpace were > > discussed. The minutes are at > > > > http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceBrainstormMeeting > > > > These were not official IVOA meetings, but should inform the > > discussion on this list. The people protoyping VOStore were present. > > > > 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-grid@eso.org Mon Mar 14 19:50:42 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 j2EIoN1H021288 for ; Mon, 14 Mar 2005 19:50:24 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2EIoNdd021287 for grid-outgoing; Mon, 14 Mar 2005 19:50:23 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2EIoK1H021277 for ; Mon, 14 Mar 2005 19:50:20 +0100 (MET) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2EIoIpB015358 for ; Mon, 14 Mar 2005 19:50:18 +0100 (CET) Received: from [144.173.229.5] (helo=butch.astro.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 4.41) id 1DAudp-01Co9I-2A; Mon, 14 Mar 2005 18:50:13 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=localhost) by butch.astro.ex.ac.uk with esmtp (Exim 4.24) id 1DAudk-0003Dc-RQ; Mon, 14 Mar 2005 18:50:08 +0000 Date: Mon, 14 Mar 2005 18:50:08 +0000 (GMT) From: Eric Saunders To: Guy Rixon cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach 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.0.3.0, Antispam-Data: 2005.3.14.10 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Eric Saunders X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy, Thank you for your detailed reply. As I understand it, you have two main concerns: 1) The user agent may be transient, e.g. a laptop web browser, and thus cannot guarantee itself available to orchestrate the workflow. Even if it were available, it may not be able to do so if it is a simple browser-like entity. 2) Unless user identity is passed freely, data must pass back through the intervening software layers, with each communication incurring a potentially large and wasteful data transfer. To answer your first point: I think we may have a misunderstanding about what we each mean by 'user agent'. You describe the user agent as the primary interface between the human astronomer and the grid architecture. You give the example of a browser-like process running on a laptop. To me, this browser application is just the *interface* to a persistent user agent (an intelligent agent), running permanently on my local community server, as you have described. For what follows, we can essentially ignore the browser, as we would like this to remain decoupled from the rest of the system. I shall use the phrase 'local agent' to describe the other, persistent, local software entity. Now I think we are mostly in agreement. As you have argued, the local agent must have full user privileges - that is fine. The local agent is persistent - we have some guarantee that it is not going to disappear during the lifetime of the workflow. This means it can deal with coordinating workflow components. Let's assume that we use the laptop 'user agent' as a way to talk to the local agent, as if we were logging on to an internet email service using a username and password. Once connected to the local agent, we can make our experiment request, and then log out. It's now up to the local agent to carry out our wishes, to the best of its ability. Now to your second point. In the example with the portal, I suggested that the portal was authorised to run backend jobs. In the general case, that may not be true - user privileges might be required to access a specialised service elsewhere as part of the workflow. There are many ways this could be handled. Obviously we could just pass our full privileges to the portal, and let it freely talk to anything we have access to. I have argued against this. We could pass a unique, single-use ticket to the portal, digitally signed by the local agent, allowing access to the specialised service under whatever restrictions we like - one time write, write only, expiry date etc. etc. To get around the problem of multiple data transfers, we essentially need to pass this privilege on to whoever needs to do the data transfer. It is likely that we don't actually know who that will be, if it some backend service hidden behind a portal. Looking at the portal example again, let's say that the backend scratch store needs to return the data directly to my VOSpace. Now there are several possibilities: 1) The portal pretends to be me, and simply authorises the transfer. 2) Since we trusted the portal with the authorisation to write to our VOSpace, we give the portal the right to pass the ticket on to whomever it deems fit. However, the ticket is valid only for the portal, not any other service. One solution would be to make the ticket globally valid (i.e. relax the checking constraint), but encrypted with the portal public key, so it could not be intercepted by others. Once the portal has the ticket, if it wants to pass it on, it can do so, by decrypting and resending. Since the key is still only single use, and we trusted the portal anyway, this seems reasonable. 3) We don't give the portal any user authorisations, but we tell it what personal actions we will allow. In this case, we tell the portal that we will allow a single data transfer to our VOSpace. The portal passes the message on to the backend scratch space, which responds asking for access to the VOSpace. The portal passes on the access request, with the server id of the previously hidden backend scratch service. We choose to accept or deny the request. If we accept, we generate the ticket, locked to the backend service, and send the ticket back. Now the backend service has the direct connection it requires, and sends the data to our VOSpace. The thing I like about this architecture is that nothing needs to be known a priori. Each trust relationship and the logic required to make the decisions at each stage is local. Our local agent doesn't even have to be aware that a particular service exists. This is important when we have a service landscape in constant flux, and one which has the potential to scale upwards indefinitely. By combining small numbers of relatively 'stupid' local agents, that know only about their specific local environment, we can discover paths to arbitrary successful workflows, and authorise those paths in a secure manner. Cheers Eric ------------------------------------------- Eric Saunders eSTAR Project (http://www.estar.org.uk) Astrophysics Group University of Exeter ------------------------------------------- On Sun, 13 Mar 2005, Guy Rixon wrote: > Eric, > > you've given us a lot to think about. I'd like to reply first concerning your > initial question and your detailed sequence of operations; I'll defer > discussion of the other web-of-trust model to later email. > > On Thu, 10 Mar 2005, Eric Saunders wrote: > > > Guy, > > > > I have a couple of issues with the trust model as it's been defined here. > > > > Firstly, what is the benefit of allowing fully trusted agents other than > > your personal user agent to assume your identity? If each step of a > > workflow is authorised, then it follows that the whole workflow must be > > valid. > > If you run a workflow or similar long-running experiment, and if you leave it > to run unattended, then something has to be left in charge, activating each > stage of the experiment when it comes due. If this is your personal user-agent > (running as a background process on your desktop PC, say), then you don't need > any other agent to have access to your full set of privileges. However, if > your local user-agent isn't running all the time (e.g. it is on your lap-top) > then you may have another agent, on a server, quite probably associated with > your portal/community, looking after things for you. In this case, it helps > for the latter agent to have all your privileges at hand. > > The set of tickets you generate to authorize bits of an experiment varies > according to which services you choose. If the agent doing the workflow has > all your privileges, then it can choose among equivalent services at the time > of execution to optimize thing; if it doesn't, then you'll have to choose all > the service and issue all the tickets when you set the experiment up. > > > > Consider the following simple example. I want to run a set of simulations > > on some remote facility, and have the final output returned to my VOSpace > > for further processing. The delegation proceeds as follows. > > You've made a few assumptions in this sequence that don't hold for all likely > use cases. I'll point them out as they come up. > > > > 1. I instruct my user agent. > > > > 2. My user agent contacts the portal agent for the facility and makes the > > request. My user agent provides the portal with a single use 'ticket' > > which allows the portal access to a single directory of my VOSpace, for > > writing only, with a short but reasonable expiry date. > > You're assuming that your user agent can do this. If it's a web browser, then > it probably can't issue tickets by itself. It might be able to get the tickets > from, say, your community, but it may be difficult to push these tickets back > to the portal (would they go as HTTP cookies, perhaps?). > > > > 3. The portal agent verifies my community and decides to trust me. > > > > 4. The portal agent authorises cpu time and temporary scratch disk > > allocation from separate services at the remote facility, *using its own > > identity*. These facilities are completely abstracted from everybody > > beyond the portal. > > This assumes that the portal itself has privileges at the remote facility. Can > we require this in all cases? > > If the privileges are actually tied to your identity, then either the portal > can't use them; or you need a ticket authorizing the portal to do so; or you > need to open your identity and all privileges to the portal. > > > > > > 5. The job runs. The portal agent uses the ticket to dump the data from > > the internal data store to my VOSpace location. The ticket is now > > invalidated. The portal returns a status message to my user agent. > > You're assumming that the data flow to VOSpace via the portal. This is > undesirable since it involves two transfers of every byte. Some systems may > want to move the data direct from the producer to VOSpace. AstroGrid's CEA > does this routinely. > > If the data go direct from the remote service to VOSpace, then the ticket for > access to VOSpace has to be passed to the remote service. It has to authorize > that service, not the portal. Therefore, either the user agent has to be made > aware of the specific service being used, or the portal has to be able to make > of get a new ticket without reference to the UA. > > > In this example, we only had to export our user privileges to access the > > final data write back. When we did so, we minimised the extent of these > > privileges. If we needed other services requiring user privileges, the > > same temporary ticket model still works. This is just an example of the > > Gang of Four 'Facade' pattern: allow encapsulation of a subsystem using a > > high-level interface, simplifying subsystem usage and hiding structural > > details. > > I like encapsulation, too. That's why I think it's useful to make the portal > fully trusted and authorized: so that we don't have to break encapsulation by > passing authorization details up to the UA. > > > In this case, our high-level interface is simply the set of > > allowed personal actions which we make available to the other components > > of the workflow. We could even make this explicitly OO by passing the > > interface API of our agent to the other workflow components. Now, when > > the portal wants to give us our data back, it calls a 'dumpDataToVOSpace' > > method on our user agent, which verifies the portal is allowed to do this, > > then goes ahead and unlocks the storage location, passing back a suitable > > URI or whatever to the portal. > > The idea of a callback for authorization - it's usually > called "pull authorization" - is good. However, the agent making the > authorization responses needs to be on-line all the time. As discussed above, > this may be a job better done in the portal, or in the community service. > > > > > The advantages of this approach are the same as those of encapsulation in > > any other piece of software. The less each component knows about each > > other component, the less can go wrong, whether maliciously, because of > > bugs, erroneous assumptions or simply poor security. Each component is now > > effectively sandboxed. > > > The other big advantage is that we are not giving away our private > > identity to arbitrary software entities, and simply trusting that they > > will do the right thing, now and forever. This is inherently risky, > > because if a single point in the trust model ever fails, we lose our > > identity integrity permanently. > > I agree with both points. However, I think there are cases where the > encapsulation counts than the restriction of the identity. > > Regards, > 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-grid@eso.org Mon Mar 14 23:49:52 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 j2EMnMxv020368 for ; Mon, 14 Mar 2005 23:49:22 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2EMnMGW020367 for grid-outgoing; Mon, 14 Mar 2005 23:49:22 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2EMnIxv020356 for ; Mon, 14 Mar 2005 23:49:19 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2EMnGkW004949 for ; Mon, 14 Mar 2005 23:49:17 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu X-Envelope-To: Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2EMmpn09795 for ; Mon, 14 Mar 2005 16:48:51 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2EMmrWh028864 for ; Mon, 14 Mar 2005 16:48:53 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2EMmqf1028860 for ; Mon, 14 Mar 2005 16:48:53 -0600 Date: Mon, 14 Mar 2005 16:48:52 -0600 (CST) From: Ray Plante To: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <42315E33.9050700@jb.man.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.14.13 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hey Paul, On Fri, 11 Mar 2005, Paul Harrison wrote: > In the discussion so far of "less-trusted" or "weak certificates" - > what is actually meant is lower priviledges assigned to an identity that > is still confirmed by reference to a CA signature, in just the same way > that a "strong certificate" - i.e. as far as the cryptographic > confirmation of the identity goes there is no difference. In my view of the idea of "weak certificates" is not simply an issue of lower priviledges. Consider your definition... > I still think that we should distinguish between trust (i.e. do we know > that the entity is what it says it is - i.e. it has identity signed by a > certificate authority that we know) ... With a weak certificate, we *don't* know that the entity is what it says it is. We only know that the entity is the same entity as the last time it came around. The point is that with a Weak CA, we cannot put full trust in it because it is easy for users to register false identities. I sense that an underlying principle that you are trying to get at is that authentication and determining authorization are separate operations. If so, I agree whole-heartedly. In the case of weak certificates, the CA that signs the cert can be used in part to assign priviledges. cheers, Ray From owner-grid@eso.org Tue Mar 15 00:59:42 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 j2ENxIxv024855 for ; Tue, 15 Mar 2005 00:59:19 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2ENxI4E024854 for grid-outgoing; Tue, 15 Mar 2005 00:59:18 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2ENxExv024848 for ; Tue, 15 Mar 2005 00:59:15 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2ENxCpB023455 for ; Tue, 15 Mar 2005 00:59:12 +0100 (CET) Received: from [134.4.70.173] (oasis.ipacds.ipac.caltech.edu [134.4.70.173]) by rain.ipac.caltech.edu (8.12.11/8.12.11) with ESMTP id j2ENx5Qv009510; Mon, 14 Mar 2005 15:59:05 -0800 (PST) Message-ID: <42362548.1020209@ipac.caltech.edu> Date: Mon, 14 Mar 2005 15:59:04 -0800 From: John Good Organization: IPAC / Caltech User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ray Plante CC: grid@ivoa.net Subject: Re: SSO authentication: a new approach References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: 02_Outbound_Opt_Out X-Spam-Score: undef - spam-scanning disabled X-Scanned-By: MIMEDefang 2.35 X-Scanned-By: CanIt (www . roaringpenguin . com) on 134.4.10.130 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.14.15 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray - I can't see that I would be willing to let someone with one of your "weak certificates" do much more than someone with an HTTP cookie. I would not, for instance, let them have file upload access (unless I wanted to be in the business of supplying free storage to the world). - John Ray Plante wrote: > Hey Paul, > > On Fri, 11 Mar 2005, Paul Harrison wrote: > >>In the discussion so far of "less-trusted" or "weak certificates" - >>what is actually meant is lower priviledges assigned to an identity that >>is still confirmed by reference to a CA signature, in just the same way >>that a "strong certificate" - i.e. as far as the cryptographic >>confirmation of the identity goes there is no difference. > > > In my view of the idea of "weak certificates" is not simply an issue of > lower priviledges. Consider your definition... > > >>I still think that we should distinguish between trust (i.e. do we know >>that the entity is what it says it is - i.e. it has identity signed by a >>certificate authority that we know) ... > > > With a weak certificate, we *don't* know that the entity is what it says > it is. We only know that the entity is the same entity as the last time > it came around. The point is that with a Weak CA, we cannot put full > trust in it because it is easy for users to register false identities. > > I sense that an underlying principle that you are trying to get at is that > authentication and determining authorization are separate operations. > If so, I agree whole-heartedly. In the case of weak certificates, the > CA that signs the cert can be used in part to assign priviledges. > > cheers, > Ray From owner-grid@eso.org Tue Mar 15 05:12:09 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 j2F4Bmxv007987 for ; Tue, 15 Mar 2005 05:11:48 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2F4BmOJ007986 for grid-outgoing; Tue, 15 Mar 2005 05:11:48 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2F4Bixv007980 for ; Tue, 15 Mar 2005 05:11:44 +0100 (MET) Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2F4BgkW010093 for ; Tue, 15 Mar 2005 05:11:42 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:36593) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp id 1DB3P3-0002Pm-St (Exim 4.44) (return-path ); Tue, 15 Mar 2005 04:11:33 +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.12.10+Sun/8.12.10) with ESMTP id j2F4BXoL020738; Tue, 15 Mar 2005 04:11:33 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2F4BXRN006366; Tue, 15 Mar 2005 04:11:33 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2F4BXd7006363; Tue, 15 Mar 2005 04:11:33 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 15 Mar 2005 04:11:33 +0000 (GMT) From: Guy Rixon To: Eric Saunders cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.14.20 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Eric, I agree that we need a mechanism to authorize 3rd-party transfers into VOStores. Wil O'Mullane and I are lookin at that and will report at or before the Kyoto meeting. Let's forget "user agent" since the term is ambiguous. What we both mean, I think, is that the agent running the experiment has the user's identity and the things it calls don't, so have to get tickets for each action. In AstroGrid, and I think in eSTAR, the agent-running-the-experiment is a service that is accessed through a portal. In AstroGrid, the SSO point is another service accessed through the portal. In this mode, the portal also has the user's identity because it's in the message chain when the user signs in; it's the place where the user types in the password. I think that generally, we identify a set of "home" services logically close to the user, some combination of desktop UI, agent-running-the-experiment, SSO service and portal. These form one logical client app and have the user's trust. Guy On Mon, 14 Mar 2005, Eric Saunders wrote: > Guy, > > Thank you for your detailed reply. As I understand it, you have two main > concerns: > > 1) The user agent may be transient, e.g. a laptop web browser, and thus > cannot guarantee itself available to orchestrate the workflow. Even if it > were available, it may not be able to do so if it is a simple browser-like > entity. > > 2) Unless user identity is passed freely, data must pass back through the > intervening software layers, with each communication incurring a > potentially large and wasteful data transfer. > > > To answer your first point: I think we may have a misunderstanding about > what we each mean by 'user agent'. You describe the user agent as the > primary interface between the human astronomer and the grid architecture. > You give the example of a browser-like process running on a laptop. > > To me, this browser application is just the *interface* to a persistent > user agent (an intelligent agent), running permanently on my local > community server, as you have described. For what follows, we can > essentially ignore the browser, as we would like this to remain decoupled > from the rest of the system. I shall use the phrase 'local agent' to > describe the other, persistent, local software entity. > > Now I think we are mostly in agreement. As you have argued, the local > agent must have full user privileges - that is fine. The local agent is > persistent - we have some guarantee that it is not going to disappear > during the lifetime of the workflow. This means it can deal with > coordinating workflow components. > > Let's assume that we use the laptop 'user agent' as a way to talk to the > local agent, as if we were logging on to an internet email service using a > username and password. Once connected to the local agent, we can make > our experiment request, and then log out. It's now up to the local agent > to carry out our wishes, to the best of its ability. > > > Now to your second point. In the example with the portal, I suggested that > the portal was authorised to run backend jobs. In the general case, that > may not be true - user privileges might be required to access a > specialised service elsewhere as part of the workflow. > > There are many ways this could be handled. Obviously we could just pass > our full privileges to the portal, and let it freely talk to anything we > have access to. I have argued against this. > > We could pass a unique, single-use ticket to the portal, digitally signed > by the local agent, allowing access to the specialised service under > whatever restrictions we like - one time write, write only, expiry > date etc. etc. > > To get around the problem of multiple data transfers, we essentially need > to pass this privilege on to whoever needs to do the data transfer. It is > likely that we don't actually know who that will be, if it some backend > service hidden behind a portal. Looking at the portal example again, let's > say that the backend scratch store needs to return the data directly to my > VOSpace. Now there are several possibilities: > > 1) The portal pretends to be me, and simply authorises the transfer. > > 2) Since we trusted the portal with the authorisation to write to our > VOSpace, we give the portal the right to pass the ticket on to whomever it > deems fit. However, the ticket is valid only for the portal, not any other > service. One solution would be to make the ticket globally valid (i.e. > relax the checking constraint), but encrypted with the portal public key, > so it could not be intercepted by others. Once the portal has the ticket, > if it wants to pass it on, it can do so, by decrypting and resending. > Since the key is still only single use, and we trusted the portal anyway, > this seems reasonable. > > 3) We don't give the portal any user authorisations, but we tell it what > personal actions we will allow. In this case, we tell the portal that we > will allow a single data transfer to our VOSpace. The portal passes the > message on to the backend scratch space, which responds asking for access > to the VOSpace. The portal passes on the access request, with the server > id of the previously hidden backend scratch service. We choose to accept > or deny the request. If we accept, we generate the ticket, locked to the > backend service, and send the ticket back. Now the backend service has the > direct connection it requires, and sends the data to our VOSpace. > > > The thing I like about this architecture is that nothing needs to be known > a priori. Each trust relationship and the logic required to make the > decisions at each stage is local. Our local agent doesn't even have to be > aware that a particular service exists. This is important when we have a > service landscape in constant flux, and one which has the potential to > scale upwards indefinitely. By combining small numbers of relatively > 'stupid' local agents, that know only about their specific local > environment, we can discover paths to arbitrary successful workflows, and > authorise those paths in a secure manner. > > Cheers > > Eric > > ------------------------------------------- > Eric Saunders > eSTAR Project (http://www.estar.org.uk) > Astrophysics Group > University of Exeter > ------------------------------------------- > > > > > On Sun, 13 Mar 2005, Guy Rixon wrote: > > > Eric, > > > > you've given us a lot to think about. I'd like to reply first concerning your > > initial question and your detailed sequence of operations; I'll defer > > discussion of the other web-of-trust model to later email. > > > > On Thu, 10 Mar 2005, Eric Saunders wrote: > > > > > Guy, > > > > > > I have a couple of issues with the trust model as it's been defined here. > > > > > > Firstly, what is the benefit of allowing fully trusted agents other than > > > your personal user agent to assume your identity? If each step of a > > > workflow is authorised, then it follows that the whole workflow must be > > > valid. > > > > If you run a workflow or similar long-running experiment, and if you leave it > > to run unattended, then something has to be left in charge, activating each > > stage of the experiment when it comes due. If this is your personal user-agent > > (running as a background process on your desktop PC, say), then you don't need > > any other agent to have access to your full set of privileges. However, if > > your local user-agent isn't running all the time (e.g. it is on your lap-top) > > then you may have another agent, on a server, quite probably associated with > > your portal/community, looking after things for you. In this case, it helps > > for the latter agent to have all your privileges at hand. > > > > The set of tickets you generate to authorize bits of an experiment varies > > according to which services you choose. If the agent doing the workflow has > > all your privileges, then it can choose among equivalent services at the time > > of execution to optimize thing; if it doesn't, then you'll have to choose all > > the service and issue all the tickets when you set the experiment up. > > > > > > > Consider the following simple example. I want to run a set of simulations > > > on some remote facility, and have the final output returned to my VOSpace > > > for further processing. The delegation proceeds as follows. > > > > You've made a few assumptions in this sequence that don't hold for all likely > > use cases. I'll point them out as they come up. > > > > > > > 1. I instruct my user agent. > > > > > > 2. My user agent contacts the portal agent for the facility and makes the > > > request. My user agent provides the portal with a single use 'ticket' > > > which allows the portal access to a single directory of my VOSpace, for > > > writing only, with a short but reasonable expiry date. > > > > You're assuming that your user agent can do this. If it's a web browser, then > > it probably can't issue tickets by itself. It might be able to get the tickets > > from, say, your community, but it may be difficult to push these tickets back > > to the portal (would they go as HTTP cookies, perhaps?). > > > > > > > 3. The portal agent verifies my community and decides to trust me. > > > > > > 4. The portal agent authorises cpu time and temporary scratch disk > > > allocation from separate services at the remote facility, *using its own > > > identity*. These facilities are completely abstracted from everybody > > > beyond the portal. > > > > This assumes that the portal itself has privileges at the remote facility. Can > > we require this in all cases? > > > > If the privileges are actually tied to your identity, then either the portal > > can't use them; or you need a ticket authorizing the portal to do so; or you > > need to open your identity and all privileges to the portal. > > > > > > > > > > 5. The job runs. The portal agent uses the ticket to dump the data from > > > the internal data store to my VOSpace location. The ticket is now > > > invalidated. The portal returns a status message to my user agent. > > > > You're assumming that the data flow to VOSpace via the portal. This is > > undesirable since it involves two transfers of every byte. Some systems may > > want to move the data direct from the producer to VOSpace. AstroGrid's CEA > > does this routinely. > > > > If the data go direct from the remote service to VOSpace, then the ticket for > > access to VOSpace has to be passed to the remote service. It has to authorize > > that service, not the portal. Therefore, either the user agent has to be made > > aware of the specific service being used, or the portal has to be able to make > > of get a new ticket without reference to the UA. > > > > > In this example, we only had to export our user privileges to access the > > > final data write back. When we did so, we minimised the extent of these > > > privileges. If we needed other services requiring user privileges, the > > > same temporary ticket model still works. This is just an example of the > > > Gang of Four 'Facade' pattern: allow encapsulation of a subsystem using a > > > high-level interface, simplifying subsystem usage and hiding structural > > > details. > > > > I like encapsulation, too. That's why I think it's useful to make the portal > > fully trusted and authorized: so that we don't have to break encapsulation by > > passing authorization details up to the UA. > > > > > In this case, our high-level interface is simply the set of > > > allowed personal actions which we make available to the other components > > > of the workflow. We could even make this explicitly OO by passing the > > > interface API of our agent to the other workflow components. Now, when > > > the portal wants to give us our data back, it calls a 'dumpDataToVOSpace' > > > method on our user agent, which verifies the portal is allowed to do this, > > > then goes ahead and unlocks the storage location, passing back a suitable > > > URI or whatever to the portal. > > > > The idea of a callback for authorization - it's usually > > called "pull authorization" - is good. However, the agent making the > > authorization responses needs to be on-line all the time. As discussed above, > > this may be a job better done in the portal, or in the community service. > > > > > > > > The advantages of this approach are the same as those of encapsulation in > > > any other piece of software. The less each component knows about each > > > other component, the less can go wrong, whether maliciously, because of > > > bugs, erroneous assumptions or simply poor security. Each component is now > > > effectively sandboxed. > > > > > The other big advantage is that we are not giving away our private > > > identity to arbitrary software entities, and simply trusting that they > > > will do the right thing, now and forever. This is inherently risky, > > > because if a single point in the trust model ever fails, we lose our > > > identity integrity permanently. > > > > I agree with both points. However, I think there are cases where the > > encapsulation counts than the restriction of the identity. > > > > Regards, > > 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 > > > > 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-grid@eso.org Tue Mar 15 06:00: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 j2F50Qxv010222 for ; Tue, 15 Mar 2005 06:00:26 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2F50Qe3010221 for grid-outgoing; Tue, 15 Mar 2005 06:00:26 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2F50Jxv010208 for ; Tue, 15 Mar 2005 06:00:20 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2F50HpB027892 for ; Tue, 15 Mar 2005 06:00:18 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2F506n21086; Mon, 14 Mar 2005 23:00:06 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2F508Wh032451; Mon, 14 Mar 2005 23:00:08 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2F508jt032447; Mon, 14 Mar 2005 23:00:08 -0600 Date: Mon, 14 Mar 2005 23:00:08 -0600 (CST) From: Ray Plante To: John Good cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <42362548.1020209@ipac.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.14.20 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 14 Mar 2005, John Good wrote: > I can't see that I would be willing to let > someone with one of your "weak certificates" > do much more than someone with an HTTP cookie. > I would not, for instance, let them have file > upload access (unless I wanted to be in the > business of supplying free storage to the > world). The motivation for this is the fact that many sites happily do this now, albeit in restricted ways. Take the example of the what we want to do with the OpenSkyQuery Portal. We want users to be able to upload their own catalogs as a VOTable (perhaps something they've constructed themselves using client tools or was the result of a query from another site) in order to cross-correlate it with a skynode. Now consider how we would do this without certs and such: we set up a little registration page, a user database, and use cookies to track the session. There is nothing preventing a user from entering a false identity, but who cares? We will place restrictions on how big a file, maybe its contents, etc. All we care about is if we allow this uploaded data to persist that only the person who registered can get access to it, whoever that schmo is. This is common practice all over the web; we all have accounts like this (travelocity, blogs, etc.). What a cert-based model can give us is interoperability between portals offering storage space for what ever reason. A weak cert is equivalent to the scenario above. Some sites will be more general purpose in terms of what allow users to store, and thus may want a strong cert that guarantees identity, but some can be more restrictive and not worry about true identities. But we can have a common authentication model based on certs. The number one user complaint about certificates is that is such a pain in the ars to get one. And as many sites maintaining persistant state today demonstrate, they are not needed. Weak certs allow users to do simple things simply. cheers, Ray From owner-grid@eso.org Tue Mar 15 08:38:39 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 j2F7cKxv021596 for ; Tue, 15 Mar 2005 08:38:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2F7cK57021595 for grid-outgoing; Tue, 15 Mar 2005 08:38:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2F7cFxv021585 for ; Tue, 15 Mar 2005 08:38:16 +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 j2F7cDpB000432 for ; Tue, 15 Mar 2005 08:38:14 +0100 (CET) Received: from Ropy (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-6.6) with ESMTP id j2F7c2BJ020217 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 14 Mar 2005 23:38:07 -0800 Message-ID: <141601c52931$ec6908d0$6701a8c0@Ropy> From: "Roy Williams" To: "John Good" , "Ray Plante" Cc: References: <42362548.1020209@ipac.caltech.edu> Subject: Re: SSO authentication: a new approach Date: Mon, 14 Mar 2005 23:37:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.14.23 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray's "weak certificate" does not prove who the person is in a real-world context, but only for example that the reader of data be the same as the writer. In my "HotGrid", (*) I would extract a description of what they are doing and who they are through simple registration -- in exchange for a *quantitative* increase in some sort of limit -- a limit that is more stringent for anonymous users. The OpenSkyNode.net at Baltimore truncates SQL queries at 5,000 and all users are anonymous. Perhaps they would allow 50,000 for those who have registered. This kind of information about usage looks fabulous in an Annual Report. Roy (*) http://us-vo.org/pubs/files/hotgrid.pdf -------- California Institute of Technology roy@caltech.edu 626 395 3670 ----- Original Message ----- From: "John Good" To: "Ray Plante" Cc: Sent: Monday, March 14, 2005 3:59 PM Subject: Re: SSO authentication: a new approach > > Ray - > > I can't see that I would be willing to let > someone with one of your "weak certificates" > do much more than someone with an HTTP cookie. > I would not, for instance, let them have file > upload access (unless I wanted to be in the > business of supplying free storage to the > world). > > - John > > > Ray Plante wrote: > >> Hey Paul, >> >> On Fri, 11 Mar 2005, Paul Harrison wrote: >> >>>In the discussion so far of "less-trusted" or "weak certificates" - what is actually >>>meant is lower priviledges assigned to an identity that is still confirmed by reference >>>to a CA signature, in just the same way that a "strong certificate" - i.e. as far as >>>the cryptographic confirmation of the identity goes there is no difference. >> >> >> In my view of the idea of "weak certificates" is not simply an issue of lower >> priviledges. Consider your definition... >> >> >>>I still think that we should distinguish between trust (i.e. do we know that the entity >>>is what it says it is - i.e. it has identity signed by a certificate authority that we >>>know) ... >> >> >> With a weak certificate, we *don't* know that the entity is what it says >> it is. We only know that the entity is the same entity as the last time >> it came around. The point is that with a Weak CA, we cannot put full >> trust in it because it is easy for users to register false identities. >> >> I sense that an underlying principle that you are trying to get at is that >> authentication and determining authorization are separate operations. >> If so, I agree whole-heartedly. In the case of weak certificates, the >> CA that signs the cert can be used in part to assign priviledges. cheers, >> Ray > From owner-grid@eso.org Tue Mar 15 09:54: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 j2F8rYxv000873 for ; Tue, 15 Mar 2005 09:53:34 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2F8rYeA000870 for grid-outgoing; Tue, 15 Mar 2005 09:53:34 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2F8rRxv000814 for ; Tue, 15 Mar 2005 09:53:27 +0100 (MET) 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 j2F8rR202532 for ; Tue, 15 Mar 2005 09:53:27 +0100 (MET) Message-ID: <4236A287.2090809@jb.man.ac.uk> Date: Tue, 15 Mar 2005 09:53:27 +0100 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: grid@ivoa.net Subject: Re: SSO authentication: a new approach 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-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray Plante wrote: >Hey Paul, > >On Fri, 11 Mar 2005, Paul Harrison wrote: > > >>In the discussion so far of "less-trusted" or "weak certificates" - >>what is actually meant is lower priviledges assigned to an identity that >>is still confirmed by reference to a CA signature, in just the same way >>that a "strong certificate" - i.e. as far as the cryptographic >>confirmation of the identity goes there is no difference. >> >> > >In my view of the idea of "weak certificates" is not simply an issue of >lower priviledges. Consider your definition... > > > >>I still think that we should distinguish between trust (i.e. do we know >>that the entity is what it says it is - i.e. it has identity signed by a >>certificate authority that we know) ... >> >> > >With a weak certificate, we *don't* know that the entity is what it says >it is. We only know that the entity is the same entity as the last time >it came around. The point is that with a Weak CA, we cannot put full >trust in it because it is easy for users to register false identities. > >I sense that an underlying principle that you are trying to get at is that >authentication and determining authorization are separate operations. >If so, I agree whole-heartedly. In the case of weak certificates, the >CA that signs the cert can be used in part to assign priviledges. > > I think that the terms "weak" and "less trusted" are already provoking people into saying - "I'm not going to let one of those use my service". I think that my original definition of trust is too narrow - it is more than just identity - the best definition I found is Generally an entity can be said to trust a second entity when the first entity makes the assumption that the second entity will behave exactly as the first entity expects. contained in this Sun Blueprint http://www.sun.com/blueprints/1202/817-0775.pdf I think that the distinction would have a bearing on any design - instead of having different classes of CA, all CAs would be equal, but the less privileged user would only be registered in a low priviledge community for instance. Paul. From owner-grid@eso.org Tue Mar 15 10:05: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 j2F95Bxv002585 for ; Tue, 15 Mar 2005 10:05:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2F95AtD002584 for grid-outgoing; Tue, 15 Mar 2005 10:05:10 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2F956xv002564 for ; Tue, 15 Mar 2005 10:05:06 +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 j2F954pB002757 for ; Tue, 15 Mar 2005 10:05:04 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:45035) by ppsw-2.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.132]:25) with esmtp id 1DB7yq-0005ez-9Z (Exim 4.44) (return-path ); Tue, 15 Mar 2005 09:04:48 +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.12.10+Sun/8.12.10) with ESMTP id j2F94loL025503; Tue, 15 Mar 2005 09:04:47 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2F94kRN006570; Tue, 15 Mar 2005 09:04:46 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2F94k1e006567; Tue, 15 Mar 2005 09:04:46 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 15 Mar 2005 09:04:46 +0000 (GMT) From: Guy Rixon To: Roy Williams cc: John Good , Ray Plante , grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <141601c52931$ec6908d0$6701a8c0@Ropy> Message-ID: References: <42362548.1020209@ipac.caltech.edu> <141601c52931$ec6908d0$6701a8c0@Ropy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.14.24 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Roy, what happens when all service providers require local registration? Doesn't it get a bit tricky for hte end users? Guy On Mon, 14 Mar 2005, Roy Williams wrote: > Ray's "weak certificate" does not prove who the person is in a real-world context, but > only for example that the reader of data be the same as the writer. > > In my "HotGrid", (*) I would extract a description of what they are doing and who they are > through simple registration -- in exchange for a *quantitative* increase in some sort of > limit -- a limit that is more stringent for anonymous users. > > The OpenSkyNode.net at Baltimore truncates SQL queries at 5,000 and all users are > anonymous. Perhaps they would allow 50,000 for those who have registered. > > This kind of information about usage looks fabulous in an Annual Report. > > Roy > > (*) http://us-vo.org/pubs/files/hotgrid.pdf > > -------- > California Institute of Technology > roy@caltech.edu > 626 395 3670 > ----- Original Message ----- > From: "John Good" > To: "Ray Plante" > Cc: > Sent: Monday, March 14, 2005 3:59 PM > Subject: Re: SSO authentication: a new approach > > > > > > Ray - > > > > I can't see that I would be willing to let > > someone with one of your "weak certificates" > > do much more than someone with an HTTP cookie. > > I would not, for instance, let them have file > > upload access (unless I wanted to be in the > > business of supplying free storage to the > > world). > > > > - John > > > > > > Ray Plante wrote: > > > >> Hey Paul, > >> > >> On Fri, 11 Mar 2005, Paul Harrison wrote: > >> > >>>In the discussion so far of "less-trusted" or "weak certificates" - what is actually > >>>meant is lower priviledges assigned to an identity that is still confirmed by reference > >>>to a CA signature, in just the same way that a "strong certificate" - i.e. as far as > >>>the cryptographic confirmation of the identity goes there is no difference. > >> > >> > >> In my view of the idea of "weak certificates" is not simply an issue of lower > >> priviledges. Consider your definition... > >> > >> > >>>I still think that we should distinguish between trust (i.e. do we know that the entity > >>>is what it says it is - i.e. it has identity signed by a certificate authority that we > >>>know) ... > >> > >> > >> With a weak certificate, we *don't* know that the entity is what it says > >> it is. We only know that the entity is the same entity as the last time > >> it came around. The point is that with a Weak CA, we cannot put full > >> trust in it because it is easy for users to register false identities. > >> > >> I sense that an underlying principle that you are trying to get at is that > >> authentication and determining authorization are separate operations. > >> If so, I agree whole-heartedly. In the case of weak certificates, the > >> CA that signs the cert can be used in part to assign priviledges. cheers, > >> Ray > > > 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-grid@eso.org Tue Mar 15 10:30: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 j2F9Trxv005884 for ; Tue, 15 Mar 2005 10:29:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2F9TrEn005883 for grid-outgoing; Tue, 15 Mar 2005 10:29:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2F9TZxv005826 for ; Tue, 15 Mar 2005 10:29:35 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2F9TXpB003583 for ; Tue, 15 Mar 2005 10:29:33 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu X-Envelope-To: Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2F9TQn11741 for ; Tue, 15 Mar 2005 03:29:26 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2F9TTWh002271 for ; Tue, 15 Mar 2005 03:29:29 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2F9TSGq002267 for ; Tue, 15 Mar 2005 03:29:29 -0600 Date: Tue, 15 Mar 2005 03:29:28 -0600 (CST) From: Ray Plante To: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <4236A287.2090809@jb.man.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.15.0 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 15 Mar 2005, Paul Harrison wrote: > I think that the distinction would have a bearing on any design - > instead of having different classes of CA, all CAs would be equal, but > the less privileged user would only be registered in a low priviledge > community for instance. I'm trying to address a very practical problem: the hassle of getting a certificate. I want to allow users to be able to fill out a registration form and begin access restricted services immediately. This is not the current practice with cert-based trust models. Many sites provide immediate restricted access without the use of certs, so why bother? Because we don't need to support two forms of authentication, for one; interoperability across sites, for two. So, do you want to see an easier way to get a certificate? If not, then weak certs are not useful. If so, can you really trust a process that cuts corners for expediancy as much as a process that takes greater care? When you assign lower priviledges to a user (because we're not really sure they are who they say they are), how do you do that? For one, how do you recognize that this person should get lower priviledges? You can only do it if you control both the granting of the certificate AND the assigning of priviledge. Priviledges, however, are assigned by the maintainer of service and not the CA. I claim that the current existance of register-and-go portals (which we all have more accounts on than we can remember) demonstrates the desire on both the part of users and providers for weaker authentication. cheers, Ray From owner-grid@eso.org Tue Mar 15 17:47:58 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 j2FGlWqm016559 for ; Tue, 15 Mar 2005 17:47:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2FGlW0W016558 for grid-outgoing; Tue, 15 Mar 2005 17:47:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2FGlSqm016546 for ; Tue, 15 Mar 2005 17:47:28 +0100 (MET) Received: from pop-a065d19.pas.sa.earthlink.net (pop-a065d19.pas.sa.earthlink.net [207.217.121.253]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2FGlQkW003553 for ; Tue, 15 Mar 2005 17:47:26 +0100 (CET) Received: from h-69-3-128-162.lsanca54.dynamic.covad.net ([69.3.128.162] helo=ipac.caltech.edu) by pop-a065d19.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1DBFCL-0003Jf-00; Tue, 15 Mar 2005 08:47:13 -0800 Message-ID: <42371191.8030407@ipac.caltech.edu> Date: Tue, 15 Mar 2005 08:47:13 -0800 From: John Good User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ray Plante CC: grid@ivoa.net Subject: Re: SSO authentication: a new approach 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.0, Antispam-Data: 2005.3.15.8 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray - IRSA allows uploading of files now, too. However, in each case those files are for a specific purpose (e.g. cross-compare against catalog X) and are not then directly downloadable again. If you allow general essentially anonymous upload of files which are then URL-accessible, you will have created the world's largest porn repository. You can't police this by file content unless you know a way to identify a JPEG as containing astronomical imagery. I think the answer is not weak certificates but "weak" CAs. With a local small-community CA, which also acts as proxy for the user as a SSO site, the user isn't really having to handle certificates themselves. - John From owner-grid@eso.org Tue Mar 15 18:30: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 j2FHTqqm024124 for ; Tue, 15 Mar 2005 18:29:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2FHTqur024122 for grid-outgoing; Tue, 15 Mar 2005 18:29:52 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2FHTkqm024107 for ; Tue, 15 Mar 2005 18:29:46 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2FHTgpB024296 for ; Tue, 15 Mar 2005 18:29:42 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2FHTXn28535; Tue, 15 Mar 2005 11:29:33 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2FHTXWh006923; Tue, 15 Mar 2005 11:29:33 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2FHTTqO006919; Tue, 15 Mar 2005 11:29:29 -0600 Date: Tue, 15 Mar 2005 11:29:29 -0600 (CST) From: Ray Plante To: John Good cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <42371191.8030407@ipac.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.15.8 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 15 Mar 2005, John Good wrote: > I think the answer is not weak certificates but "weak" CAs. In my mind, these are equivalent. ;-) > the user isn't really having to handle certificates themselves. Yes!! Ray From owner-grid@eso.org Tue Mar 15 20:08: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 j2FJ8Nqm009725 for ; Tue, 15 Mar 2005 20:08:23 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2FJ8NtL009724 for grid-outgoing; Tue, 15 Mar 2005 20:08:23 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2FJ8Jqm009711 for ; Tue, 15 Mar 2005 20:08:19 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2FJ8GkW014388 for ; Tue, 15 Mar 2005 20:08:17 +0100 (CET) Received: from [134.4.70.173] (oasis.ipacds.ipac.caltech.edu [134.4.70.173]) by rain.ipac.caltech.edu (8.12.11/8.12.11) with ESMTP id j2FJ89s7011189; Tue, 15 Mar 2005 11:08:09 -0800 (PST) Message-ID: <42373298.3090805@ipac.caltech.edu> Date: Tue, 15 Mar 2005 11:08:08 -0800 From: John Good Organization: IPAC / Caltech User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ray Plante CC: grid@ivoa.net Subject: Re: SSO authentication: a new approach References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CanItPRO-Stream: 02_Outbound_Opt_Out X-Spam-Score: undef - spam-scanning disabled X-Scanned-By: MIMEDefang 2.35 X-Scanned-By: CanIt (www . roaringpenguin . com) on 134.4.10.130 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.15.10 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray - Even a "weak" CA would be expected accurately vouch for the fact that the person involved is indeed some they know "personally". It is only weak in the sense that the VO as a whole trusts, for instance, the University of Minnesota Astronomy Department to keep track of the people they grant certificates to without further vetting. If there are repeated problems with any CA, we can stop accepting their certificates. If that is what you mean, then I am fine with it but I don't think this should be referred to as "weak" in any way. More accurately, we are talking about a fairly relaxed system of trusted CAs. - John Ray Plante wrote: > On Tue, 15 Mar 2005, John Good wrote: > >>I think the answer is not weak certificates but "weak" CAs. > > > In my mind, these are equivalent. ;-) > > >>the user isn't really having to handle certificates themselves. > > > Yes!! > > Ray From owner-grid@eso.org Wed Mar 16 15:30:29 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 j2GETwNH020392 for ; Wed, 16 Mar 2005 15:29:58 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2GETwOx020391 for grid-outgoing; Wed, 16 Mar 2005 15:29:58 +0100 (MET) Date: Wed, 16 Mar 2005 15:29:58 +0100 (MET) Message-Id: <200503161429.j2GETwOx020391@mercury.hq.eso.org> X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f From: Paul Harrison To: grid@ivoa.net Subject: Re: SSO authentication: a new approach Sender: owner-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Virus-Scanned: by amavisd-new X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray Plante wrote: > On Tue, 15 Mar 2005, Paul Harrison wrote: > >>I think that the distinction would have a bearing on any design - >>instead of having different classes of CA, all CAs would be equal, but >>the less privileged user would only be registered in a low priviledge >>community for instance. > > > I'm trying to address a very practical problem: the hassle of getting a > certificate. I want to allow users to be able to fill out a registration > form and begin access restricted services immediately. This is not the > current practice with cert-based trust models. Many sites provide > immediate restricted access without the use of certs, so why bother? > Because we don't need to support two forms of authentication, for one; > interoperability across sites, for two. > > So, do you want to see an easier way to get a certificate? If not, then > weak certs are not useful. If so, can you really trust a process that > cuts corners for expediancy as much as a process that takes greater care? > When you assign lower priviledges to a user (because we're not really sure > they are who they say they are), how do you do that? For one, how do you > recognize that this person should get lower priviledges? You can only do > it if you control both the granting of the certificate AND the assigning > of priviledge. Priviledges, however, are assigned by the maintainer of > service and not the CA. > > I think that we are both looking at solving the same use case of making it easy to get a certificate that can be in use minutes after the user has registered. Effectively what I am arguing for is that once an identity has been issued to a user (in the form of a certificate) they keep that identity. In the document that you distributed, there is a requirement 2.4-R2 'Users should be allowed to "upgrade" a weak certificate to a strong one without loss of access to their data' - if there are different classes of certificate, this necessarily means issuing a new certificate and effectively changing identity, which then means that the effective owner of all user's resources needs to be changed to maintain access permissions - not a nice process.... What makes it a pain normally to get a certificate (in the UK at least) is that once you have made the certificate request with the shared secret from your private key, you are expected to turn up in person at the CA before they will push the button to send the signed certificate back to you - we could relax that process so that the CA always will return the signed certificate without this human step. At which point the identity confirmed by the certificate is effectively a member of the anonymous community - for this identity to be admitted into other more priviledged communities perhaps they would have to undergo some more rigorous identity check. It means that when checking for authority to do an operation, the priviledges will have been assigned to communities and then a community service will have to be consulted to check it the identity belongs to the community. There is the other side of the coin, that the user has to trust the CA not to allow easy identity theft - if the standard procedures are relaxed too much then that becomes a real possibility, accidental or malicious. -- Paul Harrison ESO Garching www.eso.org From owner-grid@eso.org Wed Mar 16 16:24: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 j2GFOPGb029572 for ; Wed, 16 Mar 2005 16:24:25 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2GFOP9S029570 for grid-outgoing; Wed, 16 Mar 2005 16:24:25 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2GFOGGb029539; Wed, 16 Mar 2005 16:24:17 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2GFOEpB006757; Wed, 16 Mar 2005 16:24:14 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2GFNSn22271; Wed, 16 Mar 2005 09:23:29 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2GFNTWh020689; Wed, 16 Mar 2005 09:23:29 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2GFNTpR020685; Wed, 16 Mar 2005 09:23:29 -0600 Date: Wed, 16 Mar 2005 09:23:29 -0600 (CST) From: Ray Plante To: Paul Harrison cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <200503161429.j2GETwOx020391@mercury.hq.eso.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.16.6 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 16 Mar 2005, Paul Harrison wrote: > What makes it a pain normally to get a certificate (in the UK at least) > is that once you have made the certificate request with the shared > secret from your private key, you are expected to turn up in person at > the CA before they will push the button to send the signed certificate > back to you - we could relax that process so that the CA always will > return the signed certificate without this human step. At which point > the identity confirmed by the certificate is effectively a member of the > anonymous community - for this identity to be admitted into other more > priviledged communities perhaps they would have to undergo some more > rigorous identity check. It means that when checking for authority to do > an operation, the priviledges will have been assigned to communities and > then a community service will have to be consulted to check it the > identity belongs to the community. This seems a reasonable alternative. I had had the idea that authorization policy should set locally by service providers; however, this plan would require this association with the anonymous community at a higher (say, VO project) level. (Thanks for pushing on this thread!) cheers, Ray From owner-grid@eso.org Thu Mar 17 10:44:59 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 j2H9iNKj014378 for ; Thu, 17 Mar 2005 10:44:24 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2H9iNSc014377 for grid-outgoing; Thu, 17 Mar 2005 10:44:23 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2H9iKKj014358 for ; Thu, 17 Mar 2005 10:44:20 +0100 (MET) 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 j2H9iKD12748 for ; Thu, 17 Mar 2005 10:44:20 +0100 (MET) Message-ID: <42395174.9010209@eso.org> Date: Thu, 17 Mar 2005 10:44:20 +0100 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: grid@ivoa.net Subject: Re: VOSpace discussion 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-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: > Two meetings were held on 2005-03-07 in which VOStore and VOSpace were > discussed. The minutes are at > > http://www.ivoa.net/twiki/bin/view/IVOA/VOSpaceBrainstormMeeting > > These were not official IVOA meetings, but should inform the discussion on > this list. The people protoyping VOStore were present. > I have been tasked with looking at the possibility of adding a VOStore interface to the NGAS archive system here at ESO (http://archive.eso.org/NGAST/). I hope to be able to provide some input on the issues involved in using the proposed VOSpace interface as a facade to this system in time for the interop. Paul. -- Paul Harrison ESO Garching www.eso.org From owner-grid@eso.org Sat Mar 19 07:28: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 j2J6RXKr006075 for ; Sat, 19 Mar 2005 07:27:33 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2J6RXIs006074 for grid-outgoing; Sat, 19 Mar 2005 07:27:33 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2J6RTKr006067; Sat, 19 Mar 2005 07:27:29 +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 j2J6RRkW023010; Sat, 19 Mar 2005 07:27:27 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:51959) by ppsw-2.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.132]:25) with esmtp id 1DCXQd-00018h-8z (Exim 4.44) (return-path ); Sat, 19 Mar 2005 06:27:19 +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.12.10+Sun/8.12.10) with ESMTP id j2J6RJoL004467; Sat, 19 Mar 2005 06:27:19 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2J6RJRN012866; Sat, 19 Mar 2005 06:27:19 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2J6RJWp012863; Sat, 19 Mar 2005 06:27:19 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Sat, 19 Mar 2005 06:27:18 +0000 (GMT) From: Guy Rixon To: Paul Harrison cc: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <200503161429.j2GETwOx020391@mercury.hq.eso.org> Message-ID: References: <200503161429.j2GETwOx020391@mercury.hq.eso.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.18.22 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: If the initial, unchecked registration puts the user into an anonymous _group_ inside a community, and if the access authorized for that group is lower, does that serve? Once the user is checked, then they are moved to another group. If we went with this model, what privileges can be authorized for the anonymous group? If they can't be allowed to use VOStores then it's not very helpful. On Wed, 16 Mar 2005, Paul Harrison wrote: > Ray Plante wrote: > > On Tue, 15 Mar 2005, Paul Harrison wrote: > > > >>I think that the distinction would have a bearing on any design - > >>instead of having different classes of CA, all CAs would be equal, but > >>the less privileged user would only be registered in a low priviledge > >>community for instance. > > > > > > I'm trying to address a very practical problem: the hassle of getting a > > certificate. I want to allow users to be able to fill out a registration > > form and begin access restricted services immediately. This is not the > > current practice with cert-based trust models. Many sites provide > > immediate restricted access without the use of certs, so why bother? > > Because we don't need to support two forms of authentication, for one; > > interoperability across sites, for two. > > > > So, do you want to see an easier way to get a certificate? If not, then > > weak certs are not useful. If so, can you really trust a process that > > cuts corners for expediancy as much as a process that takes greater care? > > When you assign lower priviledges to a user (because we're not really sure > > they are who they say they are), how do you do that? For one, how do you > > recognize that this person should get lower priviledges? You can only do > > it if you control both the granting of the certificate AND the assigning > > of priviledge. Priviledges, however, are assigned by the maintainer of > > service and not the CA. > > > > > > I think that we are both looking at solving the same use case of making > it easy to get a certificate that can be in use minutes after the user > has registered. > > Effectively what I am arguing for is that once an identity has been > issued to a user (in the form of a certificate) they keep that identity. > In the document that you distributed, there is a requirement 2.4-R2 > 'Users should be allowed to "upgrade" a weak certificate to a strong one > without loss of access to their data' - if there are different classes > of certificate, this necessarily means issuing a new certificate and > effectively changing identity, which then means that the effective owner > of all user's resources needs to be changed to maintain access > permissions - not a nice process.... > > What makes it a pain normally to get a certificate (in the UK at least) > is that once you have made the certificate request with the shared > secret from your private key, you are expected to turn up in person at > the CA before they will push the button to send the signed certificate > back to you - we could relax that process so that the CA always will > return the signed certificate without this human step. At which point > the identity confirmed by the certificate is effectively a member of the > anonymous community - for this identity to be admitted into other more > priviledged communities perhaps they would have to undergo some more > rigorous identity check. It means that when checking for authority to do > an operation, the priviledges will have been assigned to communities and > then a community service will have to be consulted to check it the > identity belongs to the community. > > There is the other side of the coin, that the user has to trust the CA > not to allow easy identity theft - if the standard procedures are > relaxed too much then that becomes a real possibility, accidental or > malicious. > > -- > Paul Harrison > ESO Garching > www.eso.org > 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-grid@eso.org Sat Mar 19 07:30: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 j2J6UAKr006438 for ; Sat, 19 Mar 2005 07:30:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2J6UAsr006437 for grid-outgoing; Sat, 19 Mar 2005 07:30:10 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2J6U6Kr006427; Sat, 19 Mar 2005 07:30:06 +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 j2J6U4kW023028; Sat, 19 Mar 2005 07:30:05 +0100 (CET) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:52025) by ppsw-2.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.132]:25) with esmtp id 1DCXTA-0001YF-96 (Exim 4.44) (return-path ); Sat, 19 Mar 2005 06:29:56 +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.12.10+Sun/8.12.10) with ESMTP id j2J6TuoL004502; Sat, 19 Mar 2005 06:29:56 GMT Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1]) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j2J6TuRN012878; Sat, 19 Mar 2005 06:29:56 GMT Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id j2J6TtKG012875; Sat, 19 Mar 2005 06:29:56 GMT X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Sat, 19 Mar 2005 06:29:55 +0000 (GMT) From: Guy Rixon To: Ray Plante cc: Paul Harrison , grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.18.22 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray, it's always been the AstroGrid plan that group membership would be managed in community services, not at service-provider sites. This is to remove from the providers the admin burden of herding ~10,000 users. Cheers, Guy On Wed, 16 Mar 2005, Ray Plante wrote: > On Wed, 16 Mar 2005, Paul Harrison wrote: > > What makes it a pain normally to get a certificate (in the UK at least) > > is that once you have made the certificate request with the shared > > secret from your private key, you are expected to turn up in person at > > the CA before they will push the button to send the signed certificate > > back to you - we could relax that process so that the CA always will > > return the signed certificate without this human step. At which point > > the identity confirmed by the certificate is effectively a member of the > > anonymous community - for this identity to be admitted into other more > > priviledged communities perhaps they would have to undergo some more > > rigorous identity check. It means that when checking for authority to do > > an operation, the priviledges will have been assigned to communities and > > then a community service will have to be consulted to check it the > > identity belongs to the community. > > This seems a reasonable alternative. I had had the idea that > authorization policy should set locally by service providers; however, > this plan would require this association with the anonymous community at a > higher (say, VO project) level. > > (Thanks for pushing on this thread!) > > cheers, > Ray > 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-grid@eso.org Mon Mar 21 07:46: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 j2L6jstX029066 for ; Mon, 21 Mar 2005 07:45:55 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2L6js6C029065 for grid-outgoing; Mon, 21 Mar 2005 07:45:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2L6jntX029027 for ; Mon, 21 Mar 2005 07:45:50 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2L6jlpB017528 for ; Mon, 21 Mar 2005 07:45:48 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu X-Envelope-To: Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2L6jYn10058 for ; Mon, 21 Mar 2005 00:45:39 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2L6jbWh018597 for ; Mon, 21 Mar 2005 00:45:37 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2L6jWac018593 for ; Mon, 21 Mar 2005 00:45:37 -0600 Date: Mon, 21 Mar 2005 00:45:32 -0600 (CST) From: Ray Plante To: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.20.21 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Sat, 19 Mar 2005, Guy Rixon wrote: > it's always been the AstroGrid plan that group membership would be managed in > community services, not at service-provider sites. This is to remove from > the providers the admin burden of herding ~10,000 users. I think this needs some thought. Groups are the focal point of authorization policies which are decided ultimately by service providers. I think that they will want full control over their creation and management. In practice, I envision groups be created at the portal level. Consider the case of the PI-driven observatory. They will be continuously creating many groups around telescope proposals to support propietary access to data. It is not until a particular group created by the observatory wants to interoperate at a broader level--that is, the group wants additional priviledges from other sites assigned to that group--that community coordination becomes necessary. I can think of several ways to handle this: a. the observatory uses a community service to define the group. This can be probablamatic for the observatory if access to the community service is occasionaly disrupted. b. the observatory defines the group themselves, but uses a community service to register it. The intended difference here is that registering is not required to start assigning local priviledges and letting the users use it. Registration could be user-triggered; that is, postponed until the group wants to explicitly "go global". c. don't have any community-wide notion of a group because, perhaps, it's not needed. Groups would only be defined on a per-portal basis. As long as we have community-recognized user identities, portals and services will always be able to resolve a user's priviledges. The fact that they operate as a member of one group and from a different one at another site may not matter. Of course, we still need the community notion of an anonymous group... It sounds like you Astrogrid guys have some use cases/examples in mind about how you see this working for you. Anything written out I could look at? cheers, Ray From owner-grid@eso.org Mon Mar 21 07:48:26 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 j2L6mBtX029205 for ; Mon, 21 Mar 2005 07:48:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2L6mBEA029204 for grid-outgoing; Mon, 21 Mar 2005 07:48:11 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2L6m7tX029199 for ; Mon, 21 Mar 2005 07:48:07 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2L6m4kW003442 for ; Mon, 21 Mar 2005 07:48:05 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu X-Envelope-To: Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2L6lon11449 for ; Mon, 21 Mar 2005 00:47:50 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2L6lrWh018606 for ; Mon, 21 Mar 2005 00:47:53 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2L6lrsb018602 for ; Mon, 21 Mar 2005 00:47:53 -0600 Date: Mon, 21 Mar 2005 00:47:53 -0600 (CST) From: Ray Plante To: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.20.21 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Sat, 19 Mar 2005, Guy Rixon wrote: > If we went with this model, what privileges can be authorized for the > anonymous group? If they can't be allowed to use VOStores then it's not very > helpful. Sorry--I feel like a broken record here. Maybe it's time someone told me to sit down. But here goes... Fact: many, many portals today allow users to store state on their sites without confirmed assurance of their identities. (Take shopping carts, for example.) What state can be stored is highly controlled so as not to be a security risk, and yet it is highly useful. Will VO providers wish to do a similar thing? Will they want to put their users though the hassles of confirmed registration just so that they can temporarily store the output of a database query from their own service (like saving a travel itinerary)? This is the kind of permission that could be assigned to anonymous group. If we want this, do we want the access control associated with this feature to be compatible with stronger authorization policies? Will VO providers wish to do a similar thing? If we really don't think so, then I'll get off my hobby horse. cheers, Ray From owner-grid@eso.org Mon Mar 21 17:48: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 j2LGm788029353 for ; Mon, 21 Mar 2005 17:48:07 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2LGm7BQ029350 for grid-outgoing; Mon, 21 Mar 2005 17:48:07 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2LGm188029270 for ; Mon, 21 Mar 2005 17:48:01 +0100 (MET) Received: from pop-a065d05.pas.sa.earthlink.net (pop-a065d05.pas.sa.earthlink.net [207.217.121.249]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2LGlxpB004876 for ; Mon, 21 Mar 2005 17:47:59 +0100 (CET) Received: from h-69-3-128-162.lsanca54.dynamic.covad.net ([69.3.128.162] helo=ipac.caltech.edu) by pop-a065d05.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1DDQ4D-0002gR-00; Mon, 21 Mar 2005 08:47:49 -0800 Message-ID: <423EFAB5.9030003@ipac.caltech.edu> Date: Mon, 21 Mar 2005 08:47:49 -0800 From: John Good User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ray Plante CC: grid@ivoa.net Subject: Re: SSO authentication: a new approach 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.0, Antispam-Data: 2005.3.21.8 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray - >Fact: many, many portals today allow users to store state on their sites >without confirmed assurance of their identities. (Take shopping >carts, for example.) What state can be stored is highly controlled so as >not to be a security risk, and yet it is highly useful. > All the portal I can think of allow either creation of trivial amounts of data or creation/upload of data for a very specific purpose. Of course such use will continue and will continue to be accessible anonymously. The problem with VOStore (and the one that requires user authentication) is that it will also be useable as a distributed file system. Basically, if a user can upload an arbitrary file anonymously and propogate a URL so that others can access it anonymously, we have a big problem. All IRSA services create result subdirectories in a workspace tied to the user by HTTP cookie. As soon as there is a final spec, that workspace will become a VOStore. We will continue to allow anonymous access through the same mechanisms we do now, including upload of files for specific purposes (e.g. catalog cross-comparison) but we will NOT allow a general "PUT" by anyone who does not have a confirmed identity. >Will VO providers wish to do a similar thing? Will they want to put their >users though the hassles of confirmed registration just so that they can >temporarily store the output of a database query from their own service >(like saving a travel itinerary)? This is the kind of permission that >could be assigned to anonymous group. If we want this, do we want the >access control associated with this feature to be compatible with stronger >authorization policies? > In some ways, I see this as a non-issue. The VO community has to have ways of reliably checking and passing identity to support certain usage scenarios. However, the individual service provider is a perfect liberty to only use this when they feel it is warranted; any "requirement" for this on our part will be ignored. - John From owner-grid@eso.org Mon Mar 21 19:35:34 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 j2LIZG88012082 for ; Mon, 21 Mar 2005 19:35:16 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2LIZGYx012081 for grid-outgoing; Mon, 21 Mar 2005 19:35:16 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2LIZC88012076 for ; Mon, 21 Mar 2005 19:35:13 +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 j2LIZApB007655 for ; Mon, 21 Mar 2005 19:35:11 +0100 (CET) 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 j2LIZ6BJ014537 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 21 Mar 2005 10:35:07 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <2e2b8331b6aebf3682b4700a99293b46@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: grid@ivoa.net From: "Matthew J. Graham" Subject: SAML and Axis 1.1 Date: Mon, 21 Mar 2005 10:34:58 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.21.9 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Matthew J. Graham" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I have just discovered that the SAML schema and Axis 1.1 are incompatible! The SAML schema uses choice groups which Axis 1.1 does not support for doc/literal services. This means that if we want interoperability (Basic WS-I) and SAML, we need to be using Axis 1.2. Cheers, Matthew From owner-grid@eso.org Mon Mar 21 20:06:55 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 j2LJ6a88015267 for ; Mon, 21 Mar 2005 20:06:36 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2LJ6aZn015266 for grid-outgoing; Mon, 21 Mar 2005 20:06:36 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2LJ6W88015256 for ; Mon, 21 Mar 2005 20:06:32 +0100 (MET) Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2LJ6UpB008440 for ; Mon, 21 Mar 2005 20:06:30 +0100 (CET) Received: (from nobody@localhost) by newb6.u-strasbg.fr (8.9.3/8.9.3) id UAA16827; Mon, 21 Mar 2005 20:06:21 +0100 (MET) X-Authentication-Warning: newb6.u-strasbg.fr: nobody set sender to schaaff@astro.u-strasbg.fr using -f To: "Matthew J. Graham" Subject: Re: SAML and Axis 1.1 Message-ID: <1111431981.423f1b2dc37ca@astro.u-strasbg.fr> Date: Mon, 21 Mar 2005 20:06:21 +0100 (MET) From: Andre Schaaff Cc: grid@ivoa.net References: <2e2b8331b6aebf3682b4700a99293b46@cacr.caltech.edu> In-Reply-To: <2e2b8331b6aebf3682b4700a99293b46@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.21.10 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andre Schaaff X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The 1.2 seems to be near the final status. Quoting "Matthew J. Graham" : > Hi, > > I have just discovered that the SAML schema and Axis 1.1 are > incompatible! The SAML schema uses choice groups which Axis 1.1 does > not support for doc/literal services. > This means that if we want interoperability (Basic WS-I) and SAML, we > need to be using Axis 1.2. > > Cheers, > > Matthew > From owner-grid@eso.org Mon Mar 21 21:28:01 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 j2LKRe88026051 for ; Mon, 21 Mar 2005 21:27:40 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2LKRegQ026050 for grid-outgoing; Mon, 21 Mar 2005 21:27:40 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2LKRa88026043 for ; Mon, 21 Mar 2005 21:27:37 +0100 (MET) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2LKRYkW026453 for ; Mon, 21 Mar 2005 21:27:35 +0100 (CET) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu X-Envelope-To: Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j2LKRQn07001 for ; Mon, 21 Mar 2005 14:27:27 -0600 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j2LKRRWh026739 for ; Mon, 21 Mar 2005 14:27:27 -0600 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j2LKRRna026735 for ; Mon, 21 Mar 2005 14:27:27 -0600 Date: Mon, 21 Mar 2005 14:27:27 -0600 (CST) From: Ray Plante To: grid@ivoa.net Subject: Re: SSO authentication: a new approach In-Reply-To: <423EFAB5.9030003@ipac.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.21.11 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi John, > Basically, if a user can upload an arbitrary file anonymously and propogate > a URL so that others can access it anonymously, we have a big problem. I don't dispute this. While VOStore provides a major motivation for addressing the authentication/authorization issue, this thread started with a more general perspective that was not intended to be limited to the VOStore application. > All IRSA services create result subdirectories in a workspace tied to > the user by HTTP cookie. As soon as there is a final spec, that workspace > will become a VOStore. We will continue to allow anonymous > access through the same mechanisms we do now, including upload of > files for specific purposes (e.g. catalog cross-comparison) but we will > NOT allow a general "PUT" by anyone who does not have a confirmed > identity. I take it from your discussion that your IRSA users do not have to "log on" to take advantage of use of the workspace. Perhaps because a user's access to it is short-lived (a single session) and thus would be restricted to a single client machine? I have to log on to Travelocity to get my saved itineraries (thus I can do this from any machine). In the VO, if I save results from a database search, not only would it be nice to let it persist beyond my session, but also allow agents I direct from other sites to access it. The log-in used to protect this data should not be separate from our VO single-sign-on, and it would be nice if I didn't have to wait to get my identity confirmed to begin using it in this restricted sense. Hopefully, I've exhausted this thread. ;-) cheers, Ray From owner-grid@eso.org Wed Mar 23 17:55:43 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 j2NGtK4x025753 for ; Wed, 23 Mar 2005 17:55:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j2NGtKJH025752 for grid-outgoing; Wed, 23 Mar 2005 17:55:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j2NGtG4x025747 for ; Wed, 23 Mar 2005 17:55:16 +0100 (MET) Received: from ironport-c60.metropolis-inter.com (ip60.metropolis-inter.com [200.27.66.3]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j2NGtDpB003088 for ; Wed, 23 Mar 2005 17:55:14 +0100 (CET) Received: from allot-smtp.metropolis-inter.com (HELO tonto) (200.27.66.8) by ironport-c60.metropolis-inter.com with ESMTP; 23 Mar 2005 13:00:05 -0400 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= X-IronPort-AV: i="3.91,115,1110164400"; d="scan'208"; a="42140919:sNHT21700564" Received: from www-data by tonto with local (Exim 4.34 #1 (Debian)) id 1DE7ic-0003k0-4g for ; Wed, 23 Mar 2005 11:24:26 -0400 Received: from 139.229.7.42 (SquirrelMail authenticated user andrew); by localhost with HTTP; Wed, 23 Mar 2005 11:24:26 -0400 (CLT) Message-ID: <3972.139.229.7.42.1111591466.squirrel@localhost> In-Reply-To: References: <423EFAB5.9030003@ipac.caltech.edu> Date: Wed, 23 Mar 2005 11:24:26 -0400 (CLT) Subject: NSA A/A [Was: SSO authentication: a new approach] From: "andrew cooke" To: grid@ivoa.net User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.23.7 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "andrew cooke" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, You don't know me, but I've just been told I'm responsible for security in the NOAO Science Archive (NSA). I've stumbled across this thread while casting aroud trying to understand a little more what other people are doing wrt security and the VO (Ray - I think Arno will be contacting you soon, or has already done so, and I guess we will be talking in more detail). So I'm trying to work out how the NSA would fit into the scheme of things. I think it would be great for us to have an external authentication service, which manages/verrifies identities, but I think we would want to keep control of authorization (because access to particular data will be a function of both the user's identity and the data's provenance - provenance being a complex fuction of the metadata within the archive). At first glance, that seems clean enough. But I can see at least two problems, which I think others have also discussed here. 1 - It's not always easy to separate authentication and authorization. In a typical ACL scenario you need to search through relationships between subjects and permissions (for example, the user may not have the appropriate permission, but is a member of a group that does). In such cases, who is responsible for managing groups? It seems that naturally this is a job for the authentication service, but that gives me an efficiency headache if I want to do local authorization. 2 - How does this fit with the whole trust model? This affects the NSA in at least two ways. 2a: We need to start worrying about who is doing the request (ie implementing whatever trust model is decided on) 2b: We might need to start worrying about generating requests ourselves. On the last point, what are people's opinions on the internal architecture of large(?) web services? Do issues like 2b mean that we should have message security internally, or is it more practical to handle authentication at the gateway and use whatever internal architecture we want (typically transport or network security), since we trust our own code, do our own authorization, and in general aren't worried about third party support? Sorry if this seems rambling or just plain stupid in parts (and I guess perhaps the last question is not 100% relevant to this list). I'm still trying to get my head round the issues involved... Thanks, Andrew Ray Plante said: > Hopefully, I've exhausted this thread. ;-) > > cheers, > Ray > > -- ` __ _ __ ___ ___| |_____ work web site: http://www.ctio.noao.edu/~andrew / _` / _/ _ \/ _ \ / / -_) personal web site: http://www.acooke.org/andrew \__,_\__\___/\___/_\_\___| list: http://www.acooke.org/andrew/compute.html From owner-grid@eso.org Fri Apr 1 02:56: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 j310u3PI008584 for ; Fri, 1 Apr 2005 02:56:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j310u3F3008583 for grid-outgoing; Fri, 1 Apr 2005 02:56:03 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j310txPI008566 for ; Fri, 1 Apr 2005 02:55:59 +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 j310tvkW013806 for ; Fri, 1 Apr 2005 02:55:58 +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 j310trBJ003270 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 31 Mar 2005 16:55:54 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <080b64509a5b134c06a3eabd63489471@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: grid@ivoa.net From: "Matthew J. Graham" Subject: Axis + DIME attachments Date: Thu, 31 Mar 2005 16:55:45 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.3.31.15 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Matthew J. Graham" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I have a web service in Java which is returning files as (DIME) attachments. The server side adds the file to the ResponseMessage and then returns the response object: boolean success = addFileToResponseMessage(); if (success) { return new MethodResponse("Attachment successful"); } else { return new MethodResponse("Attachment failed"); } Now on the client side, I am not getting a MethodResponse object but can access the attachments from the client stub. This strikes me Axis not handling attachments and message contents properly. Does anyone else have any experience with similar? Cheers, Matthew From owner-grid@eso.org Mon Apr 25 13:39: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 j3PBcQqT004495 for ; Mon, 25 Apr 2005 13:38:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j3PBcQBW004494 for grid-outgoing; Mon, 25 Apr 2005 13:38:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j3PBcMqT004486 for ; Mon, 25 Apr 2005 13:38:22 +0200 (MEST) Received: from athena.le.ac.uk (ntp3d.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j3PB9TXW003476 for ; Mon, 25 Apr 2005 13:09:30 +0200 (CEST) Message-Id: <200504251109.j3PB9TXW003476@rocky.hq.eso.org> Received: from [143.210.36.14] (helo=marindi) by athena.le.ac.uk with esmtp (Exim 4.44) id 1DQ1Sq-0006mu-04; Mon, 25 Apr 2005 12:09:20 +0100 From: "Tony Linde" To: "'Guy Rixon'" , Subject: matu Date: Mon, 25 Apr 2005 12:09:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVJhzqyBW966VzeS1KKFq0hemZdMQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-UoL-Id: 535994ed5454af196b757854c71d8532@1DQ1Sq-0006mu-04@athena.le.ac.uk X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.4.25.2 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This might be of use to people: UK JISC is funding programmes to middleware take-up much of which involves Shibboleth installation, trial and use and MATU is supporting this: http://www.matu.ac.uk/ Cheers, Tony. __ Tony Linde Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 Fax: +44 (0)116 252 3311 Email: Tony.Linde@leicester.ac.uk Post: Department of Physics & Astronomy, University of Leicester Leicester, UK LE1 7RH Web: http://www.star.le.ac.uk/~ael Project Manager, EuroVO VOTech http://eurovotech.org Programme Manager, AstroGrid http://www.astrogrid.org Co-Director, Leicester e-Science Centre http://www.e-science.le.ac.uk/ From owner-grid@eso.org Tue Apr 26 18:45: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 j3QGj9Kn028707 for ; Tue, 26 Apr 2005 18:45:09 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j3QGj82N028705 for grid-outgoing; Tue, 26 Apr 2005 18:45:08 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j3QGiwKn028661 for ; Tue, 26 Apr 2005 18:44:58 +0200 (MEST) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id j3QGiwD07671 for ; Tue, 26 Apr 2005 18:44:58 +0200 (MEST) Message-ID: <426E7009.1010307@eso.org> Date: Tue, 26 Apr 2005 18:44:57 +0200 From: Markus Dolensky Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en, de-AT MIME-Version: 1.0 To: grid@ivoa.net Subject: WSDL and optional parameters Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Markus Dolensky X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Did we ever come to a conclusion on how to describe optional parameters of a SOAP service in WSDL? Cheers, Markus From owner-grid@eso.org Tue Apr 26 19:01: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 j3QH13Kn001020 for ; Tue, 26 Apr 2005 19:01:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j3QH12FX001016 for grid-outgoing; Tue, 26 Apr 2005 19:01:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j3QH0vKn000966; Tue, 26 Apr 2005 19:00:58 +0200 (MEST) Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j3QH0tXW023918; Tue, 26 Apr 2005 19:00:56 +0200 (CEST) X-Envelope-From: rplante@poplar.ncsa.uiuc.edu Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id j3QH0ko30326; Tue, 26 Apr 2005 12:00:46 -0500 Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1]) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id j3QH0kWh028848; Tue, 26 Apr 2005 12:00:46 -0500 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id j3QH0fa8028843; Tue, 26 Apr 2005 12:00:42 -0500 Date: Tue, 26 Apr 2005 12:00:41 -0500 (CDT) From: Ray Plante To: Markus Dolensky cc: grid@ivoa.net Subject: Re: WSDL and optional parameters In-Reply-To: <426E7009.1010307@eso.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information X-NCSA-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.4.26.3 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 26 Apr 2005, Markus Dolensky wrote: > Did we ever come to a conclusion on how to describe optional parameters of a > SOAP service in WSDL? My take on this is to wrap optional bits together in a required XML object, e.g. . If no optional parameters are specified, then this tag is empty. hope this helps, Ray From owner-grid@eso.org Tue Apr 26 19:48:55 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 j3QHmcKn007565 for ; Tue, 26 Apr 2005 19:48:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j3QHmc2m007564 for grid-outgoing; Tue, 26 Apr 2005 19:48:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j3QHmXKn007547; Tue, 26 Apr 2005 19:48:34 +0200 (MEST) 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 j3QHmVXW025105; Tue, 26 Apr 2005 19:48:32 +0200 (CEST) Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:62762) by ppsw-3.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.133]:25) with esmtp id 1DQUAa-0000xV-A0 (Exim 4.44) (return-path ); Tue, 26 Apr 2005 18:48:24 +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 j3QHmNoL006165; Tue, 26 Apr 2005 18:48:23 +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 j3QHmNhA008443; Tue, 26 Apr 2005 18:48:23 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j3QHmNwK008440; Tue, 26 Apr 2005 18:48:23 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 26 Apr 2005 18:48:23 +0100 (BST) From: Guy Rixon To: Ray Plante cc: Markus Dolensky , grid@ivoa.net Subject: Re: WSDL and optional parameters In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.4.26.4 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: If the service takes its parameters in the form of a document with a schema, then it's easy to have optional parts in that schema. Any optional element could just be left out of the document. The OOP equivalent of this is a method taking one object, e.g. a Java bean, as argument. If the service takes a list of parameters that are separate XML fragments - i.e. faking an RPC while using document/literal encoding; see "wrapped" mode in Apache Axis - then we could use Ray's idea. We'd add a mandatory parameter on the end of the list to contain the optional bits. Myself, I'd rather have services taking input as documents than as lists of parameters. But both schemes work. Cheers, Guy On Tue, 26 Apr 2005, Ray Plante wrote: > On Tue, 26 Apr 2005, Markus Dolensky wrote: > > Did we ever come to a conclusion on how to describe optional parameters of a > > SOAP service in WSDL? > > My take on this is to wrap optional bits together in a required XML > object, e.g. . If no optional parameters are specified, then > this tag is empty. > > hope this helps, > Ray > > 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-grid@eso.org Thu Apr 28 15:54: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 j3SDrlox029367 for ; Thu, 28 Apr 2005 15:53:47 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j3SDrk28029362 for grid-outgoing; Thu, 28 Apr 2005 15:53:46 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j3SDrbox029272 for ; Thu, 28 Apr 2005 15:53:37 +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 j3SDrZXW019677 for ; Thu, 28 Apr 2005 15:53: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]:39592) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1DR9SA-0006pz-Nf (Exim 4.51) for grid@ivoa.net (return-path ); Thu, 28 Apr 2005 14:53:18 +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 j3SDrIoL003979 for ; Thu, 28 Apr 2005 14:53:18 +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 j3SDrHML010791 for ; Thu, 28 Apr 2005 14:53:17 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j3SDrHuY010788 for ; Thu, 28 Apr 2005 14:53:17 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 28 Apr 2005 14:53:17 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: GWS at Kyoto interop 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.1, Antispam-Data: 2005.4.27.26 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, we have three GWS sessions at Kyoto: Wednesday afternoon, Thursday Afternoon and Friday morning. I see them split up this way: Wednesday: security issues, including: - trust models and establishment of certificate authorities; - single-sign-on arrangements; - privilege delegation; - account naming; - attribute authorities and interoperation with Shibboleth. Thursday: 1. IVOA service basic profile, including: - review of VO support interfaces, including the WSDL contracts; - reports on SOAP interoperation experiences (possible "clinic" to discuss specific SOAP problems). 2. Possible adoption of the "Universal Worker Service" pattern, including - possible IVOA standardization of AstroGrid CEA ideas and schema; - possible refactoring of the UWS contract to use WS-RF. Friday: VOStore/VOSpace, including: - review of current VOStore document; - reports from projects that have VOStore prototypes; - preliminary discussion of the VOSpace layer. Does anybody have any other major topics they want to discuss? Documents I would expect to have available (either because they already exist, or because I'm volunteering to write them): - VO support interfaces spec (exists). - VO support interfaces WSDL (GTR to produce if nobody else does it first). - VOStore draft spec (exists). - VO service basic profile (exists). - UWS proposal (exists). - CEA standardization proposal (exists, IIRC). - Report on usefulness of Shibboleth (GTR to produce) - Outline architecture for SSO and authorization support (GTR to produce). Any other material would be most welcome, particularly in the security area. I would like to come out of the meeting with - VO support interfaces promoted to PR; - community approval of the VOStore direction (or a redirection if need be); - a strategic direction for CEA/UWS; - consensus on how we do the security this year (allowing for changes later). I'll follow this email tomorrow with notes on current versions of documents. 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-grid@eso.org Thu May 5 19:15: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 j45HEtjv005885 for ; Thu, 5 May 2005 19:14:55 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j45HEtmW005884 for grid-outgoing; Thu, 5 May 2005 19:14:55 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j45HEnjv005865; Thu, 5 May 2005 19:14:50 +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 j45HElXW008137; Thu, 5 May 2005 19:14: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]:61375) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1DTjvs-0001WX-1F (Exim 4.51) (return-path ); Thu, 05 May 2005 18:14:40 +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 j45HEaoL018371; Thu, 5 May 2005 18:14:36 +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 j45HEa6d018928; Thu, 5 May 2005 18:14:36 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j45HEZ8I018925; Thu, 5 May 2005 18:14:35 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 5 May 2005 18:14:35 +0100 (BST) From: Guy Rixon To: Roy Williams cc: "Wil O'Mullane" , dave@ast.cam.ac.uk, webservices@ivoa.net, grid@ivoa.net, Roy Williams Subject: Re: VOstore -- context document? In-Reply-To: <427A4D4C.1040405@ballandclaw.com> Message-ID: References: <427A4D4C.1040405@ballandclaw.com> 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.1, Antispam-Data: 2005.5.5.18 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Roy, the main AstroGrid usage is simple. In an executing job, each job step is a filter that maps zero or more inputs to zero or more outputs. Where the inputs and outputs are clumps of data, the sources and sinks are VOStores. Thus, a DAL service is a filter that maps zero input stores to one or more outputs. An image-mosiacking service maps multiple input stores to one output store. A visualiser, were it possible to run one from a workflow, would map one or more input stores to zero output stores. We're using the stores mainly as pipes between job-steps. Using stores instead of real pipes (e.g. direct socket connections between services) satisfies some of our design goals: - The system is tolerant of network outages. - Everything runs asynchronously; job-steps can be queued by services without upsetting other services that are waiting for the data. - Jobs that fail to conplete can be restarted from intermediate data products without having to start from the beginning. - In workflows where a few data items out of a flock have problems (e.g. the few FITS files with incomplete headers), the evidence of the problem stays around so that the users can check back. - There's an audit trail of intermediate data products by which a workflow can be checked. - The final products of a workflow are held in the system until the user calls for them. The secondary use is as a place to keep user-accessible, private records of what processing was done; the AstroGrid workflow executor keeps a log of what was attempted and what happened. This, in principle, makes for better science, as the results can be checked and the experiments reproduced. I can write notes that discuss the other points in your email if you wish (but not tonight). Cheers, Guy On Thu, 5 May 2005, Roy Williams wrote: > Wil, Dave, Guy > > I have been reading the VOStore document that you guys are authoring, > and I look forward eagerly to the next version. > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/vostore0.15.pdf > > So far it seems to be a specification of services and methods, but > without much "real-world context". Perhaps there could be a second > document, as part of the VO Architecture series of documents? If we are > lucky, the technical and the explanatory documents would synchronize...... > > By real-world context, I mean topics like this: > > -- use cases, what is this thing for > > -- scope and limits, what is it no for > > -- do customers see any vostore explicitly or is it all hidden in the > backend? > > -- if the former, how do our customers leverage their knowledge of file > systems and web browsers to make them comforatble and trusting of vostore > > -- what is the model of the data objects? Blobs only? Blobs and Tables? > Mime-typed objects? Collections? Virtual data? > > -- how they (or their proxy) gets a certificate, and what motivates them > to do so > > -- on how vostore relates to srb, webdav, etc, and why the VO is making > something new rather than adopting something that already exists > > -- how vostore translates references from those other systems to vostore > references > > -- on what it takes to turn a web server into a vostore server (so > customer data can be exposed to VO services) > > -- on how to ensure that the metadata content matches the data content, > while keeping the efficiency of indirect references > > -- how to use vostore in a workflow > > In particular, there are some threads from the NVO TechWG that have > discussed some of these topics, see below (Be sure to click and repeat > on "Next Message" for each, there is a lively conversation, not just a > single message) > > I would like to see any material from Astrogrid or any other VO that > discusses any of the "context" matters above, especially anything that > might be the beginnings of an architecture/context document. > > Roy > > -------------------- > > what is vostore and what is vospace > http://www.us-vo.org/pipermail/techwg/2005-February/000728.html > > vostore as global file system (and no more) > http://www.us-vo.org/pipermail/techwg/2005-February/000781.html > > suggested use cases for vostore > http://www.us-vo.org/pipermail/techwg/2005-March/000814.html > > vostore metadata and organization > http://www.us-vo.org/pipermail/techwg/2005-March/000830.html > 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-grid@eso.org Thu May 5 19:35:37 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 j45HZHjv008707 for ; Thu, 5 May 2005 19:35:17 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j45HZHc7008706 for grid-outgoing; Thu, 5 May 2005 19:35:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j45HZDjv008696; Thu, 5 May 2005 19:35:13 +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 j45HZAXW009288; Thu, 5 May 2005 19:35:11 +0200 (CEST) Received: from [131.215.146.179] ([131.215.146.179]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id j45HZ4Qn014462 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 5 May 2005 10:35:05 -0700 Message-ID: <427A5940.3030903@cacr.caltech.edu> Date: Thu, 05 May 2005 10:34:56 -0700 From: Roy Williams User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Rixon CC: Roy Williams , "Wil O'Mullane" , dave@ast.cam.ac.uk, webservices@ivoa.net, grid@ivoa.net Subject: Re: VOstore -- context document? References: <427A4D4C.1040405@ballandclaw.com> 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.1, Antispam-Data: 2005.5.5.19 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Roy Williams X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy Rixon wrote: >the main AstroGrid usage is simple. In an executing job, each job step is a >filter that maps zero or more inputs to zero or more outputs. > Can I simplistically say this? (1) We both want single signon security. (2) VOStore services are avialable through SOAP only (3) Astrogrid wants reliable, asynchronous, third-party transfer as a priority. (4) NVO priority is to have table structure as a primitive concept, interoperable between multiple formats, including CSV and VOTable. (5) The other VO projects are waiting for US and UK to agree and make a consistent presentation of VOStore context/meaning/reasoning From owner-grid@eso.org Thu May 5 20:09: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 j45I92jv013428 for ; Thu, 5 May 2005 20:09:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j45I92rV013427 for grid-outgoing; Thu, 5 May 2005 20:09:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j45I8vjv013315 for ; Thu, 5 May 2005 20:08:57 +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 j45I8t73015354 for ; Thu, 5 May 2005 20:08: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]:63872) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1DTkmF-0003Ig-Pg (Exim 4.51) (return-path ); Thu, 05 May 2005 19:08:47 +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 j45I8joL019726; Thu, 5 May 2005 19:08:45 +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 j45I8jCx019002; Thu, 5 May 2005 19:08:45 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j45I8jTs018999; Thu, 5 May 2005 19:08:45 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 5 May 2005 19:08:45 +0100 (BST) From: Guy Rixon To: Roy Williams cc: "Wil O'Mullane" , dave@ast.cam.ac.uk, grid@ivoa.net Subject: Re: VOstore -- context document? In-Reply-To: <427A5940.3030903@cacr.caltech.edu> Message-ID: References: <427A4D4C.1040405@ballandclaw.com> <427A5940.3030903@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.1, Antispam-Data: 2005.5.5.20 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 5 May 2005, Roy Williams wrote: > Guy Rixon wrote: > > >the main AstroGrid usage is simple. In an executing job, each job step is a > >filter that maps zero or more inputs to zero or more outputs. > > > Can I simplistically say this? > > (1) We both want single signon security. Yes; but we want it in more than just VOStores and this influences the form it takes. > (2) VOStore services are avialable through SOAP only The Store services are SOAP only. The data - what you called the outrigger payloads in previous email - may be accessed via other protocols. Therefore, a non-SOAPy service might be given a URL to an OP by a SOAPy workflow agent. > (3) Astrogrid wants reliable, asynchronous, third-party transfer as a > priority. Yes. > (4) NVO priority is to have table structure as a primitive concept, > interoperable between multiple formats, including CSV and VOTable. Probably. > (5) The other VO projects are waiting for US and UK to agree and make a > consistent presentation of VOStore context/meaning/reasoning Probably. You mean, I presume, that we should write the context document before arguing about the details? I'd support that. 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-grid@eso.org Thu May 5 20:29: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 j45ITEjv017625 for ; Thu, 5 May 2005 20:29:14 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j45ITEAY017623 for grid-outgoing; Thu, 5 May 2005 20:29:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j45ITAjv017616 for ; Thu, 5 May 2005 20:29:10 +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 j45IT8XW011174 for ; Thu, 5 May 2005 20:29:09 +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]:64713) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1DTl5o-0000rg-Mv (Exim 4.51) for grid@ivoa.net (return-path ); Thu, 05 May 2005 19:29:00 +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 j45ISxoL020181 for ; Thu, 5 May 2005 19:29:00 +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 j45ISxpE019032 for ; Thu, 5 May 2005 19:28:59 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j45ISxC4019029 for ; Thu, 5 May 2005 19:28:59 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 5 May 2005 19:28:59 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: SSO documents from last year 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.1, Antispam-Data: 2005.5.5.20 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, there are two documents concerning single sign-on on the GWS wiki page. They're stuff I wrote last year. "Single-Sign-On Authentication for the IVO: introduction and description of principles" v0.1 seems still to be relevant to me. I would like to issue a v0.2 of this note with minor updates to be discussed at Kyoto. If that issue pleases the group, then I'd like to release the Note at v1.0 immediately after Kyoto. "IVOA single-sign-on profile: message protocol" v0.1 I now consider obsolete; we should not implement this protocol. Most of the complexity of the protocol is there to guard against message-modification and replay attacks. In the short term, I don't think these are enough of a threat to warrant the complexity. In the longer term (2007 and later) I expect that there will be computer-industry standards that we should follow instead of doing our own protocol. Carlo Nicola, who is working at Cambridge on IVO security, has suggested a simpler use of digital signatures and I'll post that for discussion at Kyoto. There was going to be a third paper about the use of communities as trust anchors. That didn't get written in 2004. The "v0.0" draft of this paper is the trust-model discussion we had on this list last month. I'll try and draw that discussion together into a IVOA draft next week. Finally, I now feel in a position to write a strawman document describing a possible security architecture that we can start to implement: something for you all to rip to pieces :) . I'll try and get v0.1 of that out next week, too. For a preview, you could have a look at http://wiki.astrogrid.org/bin/view/Astrogrid/SecurityArchitectureFor2005 and http://wiki.astrogrid.org/bin/view/Astrogrid/IdentityDelegation 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-grid@eso.org Fri May 6 22:19:56 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 j46KJYDV010665 for ; Fri, 6 May 2005 22:19:34 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j46KJY3Q010664 for grid-outgoing; Fri, 6 May 2005 22:19:34 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j46KJUDV010656 for ; Fri, 6 May 2005 22:19: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 j46KJS73026849 for ; Fri, 6 May 2005 22:19:29 +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]:33200) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1DU9I9-0007Hk-W0 (Exim 4.51) for grid@ivoa.net (return-path ); Fri, 06 May 2005 21:19:21 +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 j46KJLoL024287 for ; Fri, 6 May 2005 21:19:21 +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 j46KJL4Y020192 for ; Fri, 6 May 2005 21:19:21 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j46KJLhw020189 for ; Fri, 6 May 2005 21:19:21 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 6 May 2005 21:19:21 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Trust model specification 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.1, Antispam-Data: 2005.5.6.24 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I've uploaded a draft of a trust-model specification to http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/trust-model-v0.1.html This covers the arrangements for setting up communities and groups and for issuing certificates. It's a formalization of the document I posted about in March, taking into account the email discussion. 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-grid@eso.org Tue May 10 01:13: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 j49N6f1u012047 for ; Tue, 10 May 2005 01:06:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j49N6fo4012046 for grid-outgoing; Tue, 10 May 2005 01:06:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j49N6Z1u012037 for ; Tue, 10 May 2005 01:06:35 +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 j49N6X73021215 for ; Tue, 10 May 2005 01:06: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]:34674) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1DVHKU-0003co-T9 (Exim 4.51) for grid@ivoa.net (return-path ); Tue, 10 May 2005 00:06:26 +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 j49N6PoL005840 for ; Tue, 10 May 2005 00:06: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 j49N6Pbr023900 for ; Tue, 10 May 2005 00:06: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 j49N6Por023897 for ; Tue, 10 May 2005 00:06:25 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 10 May 2005 00:06:25 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: IVOA note reviewing Shibboleth 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.1, Antispam-Data: 2005.5.9.28 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I've posted a note reviewing Shibboleth on the GWS wiki page. This review informs the possible definition of a security architecture for us that uses bits of Shibboleth but is a more-capabale system. 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-grid@eso.org Wed May 11 19:14:58 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 j4BHEctP020389 for ; Wed, 11 May 2005 19:14:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4BHEcIW020388 for grid-outgoing; Wed, 11 May 2005 19:14:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j4BHEYtP020380 for ; Wed, 11 May 2005 19:14:34 +0200 (MEST) Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j4BHEW73027900 for ; Wed, 11 May 2005 19:14:33 +0200 (CEST) Received: (from nobody@localhost) by newb6.u-strasbg.fr (8.9.3/8.9.3) id TAA27605; Wed, 11 May 2005 19:14:26 +0200 (MET DST) X-Authentication-Warning: newb6.u-strasbg.fr: nobody set sender to schaaff@astro.u-strasbg.fr using -f To: grid@ivoa.net Subject: About Axis 1.2 final release Message-ID: <1115831666.42823d7262a25@astro.u-strasbg.fr> Date: Wed, 11 May 2005 19:14:26 +0200 (MET DST) From: Andre Schaaff MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.5.11.19 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andre Schaaff X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Axis 1.2 final release is available since last week (2 years after 1.1 ... but it seems that they want to reduce the time between final versions) and i have tested it before upgrading CDS Web Services. I have currently encountered no problem but i will make some more tests and perhaps more comments. If somebody else has comments about this new release, thanks for replying. André From owner-grid@eso.org Wed May 11 19:33: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 j4BHWvtP022101 for ; Wed, 11 May 2005 19:32:57 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4BHWvPA022100 for grid-outgoing; Wed, 11 May 2005 19:32:57 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j4BHWrtP022094 for ; Wed, 11 May 2005 19:32:53 +0200 (MEST) Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j4BHWp73028402 for ; Wed, 11 May 2005 19:32:52 +0200 (CEST) Received: (from nobody@localhost) by newb6.u-strasbg.fr (8.9.3/8.9.3) id TAA27887; Wed, 11 May 2005 19:32:45 +0200 (MET DST) X-Authentication-Warning: newb6.u-strasbg.fr: nobody set sender to schaaff@astro.u-strasbg.fr using -f To: grid@ivoa.net Subject: CDS SOAP Web Services reliability Message-ID: <1115832765.428241bd569e1@astro.u-strasbg.fr> Date: Wed, 11 May 2005 19:32:45 +0200 (MET DST) From: Andre Schaaff MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.5.11.19 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Andre Schaaff X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, It has never been published but since last year, CDS SOAP Web Services are available from CDS, CFA, CADC and ADAC. These services use as much as possible local resources like VizieR mirror. So if consumers implement an alternative access to a few clones they will have a good availability guarantee. A great thanks to CFA, CADC and ADAC people involved in the reliability of the servers. André For more information, please have a look at CDS Developer's corner : http://cdsweb.u-strasbg.fr/devcorner.gml From owner-grid@eso.org Wed May 11 20:49: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 j4BImrtP001388 for ; Wed, 11 May 2005 20:48:53 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4BImreS001387 for grid-outgoing; Wed, 11 May 2005 20:48:53 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j4BImmtP001378 for ; Wed, 11 May 2005 20:48:49 +0200 (MEST) Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j4BImk73000329 for ; Wed, 11 May 2005 20:48:47 +0200 (CEST) Received: from [130.167.14.29] (eon.stsci.edu [130.167.14.29]) by donner.stsci.edu (MOS 3.5.8-GR) with ESMTP id BTG16701; Wed, 11 May 2005 14:48:01 -0400 (EDT) Message-ID: <428253A4.3020804@stsci.edu> Date: Wed, 11 May 2005 14:49:08 -0400 From: Alberto Conti Organization: Space Telescope Science Institute User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Schaaff CC: grid@ivoa.net Subject: Re: CDS SOAP Web Services reliability References: <1115832765.428241bd569e1@astro.u-strasbg.fr> In-Reply-To: <1115832765.428241bd569e1@astro.u-strasbg.fr> Content-Type: multipart/alternative; boundary="------------020302020402080407020706" X-Junkmail-Status: score=20/50, host=donner.stsci.edu X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.5.11.22 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alberto Conti X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------020302020402080407020706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Andre, I think this is great and as you know MAST/GALEX discovered this the hard way. Advertising the existence of mirrors for these kind of services should be done regularly. Ciao, Alberto Andre Schaaff wrote: >Hi, > >It has never been published but since last year, CDS SOAP Web Services are >available from CDS, CFA, CADC and ADAC. >These services use as much as possible local resources like VizieR mirror. >So if consumers implement an alternative access to a few clones they will have a >good availability guarantee. > >A great thanks to CFA, CADC and ADAC people involved in the reliability of the >servers. > >André > > >For more information, please have a look at CDS Developer's corner : >http://cdsweb.u-strasbg.fr/devcorner.gml > > -- Alberto Conti Branch Manager Astronomer Tools and Applications ESS/STScI --------------020302020402080407020706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andre,

    I think this is great and as you know MAST/GALEX discovered this the hard way. Advertising the existence of mirrors for these kind of services should be done regularly.

Ciao,
Alberto

Andre Schaaff wrote: 
Hi,

It has never been published but since last year, CDS SOAP Web Services are
available from CDS, CFA, CADC and ADAC.
These services use as much as possible local resources like VizieR mirror. 
So if consumers implement an alternative access to a few clones they will have a
good availability guarantee.
 
A great thanks to CFA, CADC and ADAC people involved in the reliability of the
servers. 

André


For more information, please have a look at CDS Developer's corner :
http://cdsweb.u-strasbg.fr/devcorner.gml

--
Alberto Conti
Branch Manager
Astronomer Tools and Applications
ESS/STScI
--------------020302020402080407020706-- From owner-grid@eso.org Wed May 11 23:05: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 j4BL4ctP016496 for ; Wed, 11 May 2005 23:04:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4BL4crR016495 for grid-outgoing; Wed, 11 May 2005 23:04:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j4BL4YtP016485 for ; Wed, 11 May 2005 23:04: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 j4BL4W73004960 for ; Wed, 11 May 2005 23:04:33 +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]:52937) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1DVyNV-0001rw-UM (Exim 4.51) for grid@ivoa.net (return-path ); Wed, 11 May 2005 22:04: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 j4BL4PoL007762 for ; Wed, 11 May 2005 22:04: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 j4BL4Onp026756 for ; Wed, 11 May 2005 22:04:24 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j4BL4Oh7026753 for ; Wed, 11 May 2005 22:04:24 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Wed, 11 May 2005 22:04:24 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Security architecture 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.1, Antispam-Data: 2005.5.11.26 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I've posted v0.1 of the promised (threatened? :) )security architecture on the GWS-WG page. It's incomplete at present, and I hope to do a more-complete v0.2 tomorrow. 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-grid@eso.org Thu May 12 00:30: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 j4BMU5WX025180 for ; Thu, 12 May 2005 00:30:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4BMU553025179 for grid-outgoing; Thu, 12 May 2005 00:30:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j4BMTtWX025095; Thu, 12 May 2005 00:29:55 +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 j4BMTsD14286; Thu, 12 May 2005 00:29:54 +0200 (MEST) Received: (from apache@localhost) by atum.hq.eso.org (8.11.6/8.8.8) id j4BMTsu17001; Thu, 12 May 2005 00:29:54 +0200 Received: from p5496BE4D.dip.t-dialin.net (p5496BE4D.dip.t-dialin.net [84.150.190.77]) by webmail.eso.org (IMP) with HTTP for ; Thu, 12 May 2005 00:29:54 +0200 Message-ID: <1115850594.42828762d312c@webmail.eso.org> Date: Thu, 12 May 2005 00:29:54 +0200 From: Alberto Micol To: Alberto Conti Cc: Andre Schaaff , grid@ivoa.net Subject: Re: CDS SOAP Web Services reliability References: <1115832765.428241bd569e1@astro.u-strasbg.fr> <428253A4.3020804@stsci.edu> In-Reply-To: <428253A4.3020804@stsci.edu> 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: 84.150.190.77 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Alberto Micol X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dear All, What is the current status of Registries regarding publishing SOAP services? Are those services published in some Registry? Thanks, Alberto Quoting Alberto Conti : > Andre, > > I think this is great and as you know MAST/GALEX discovered this the > hard way. Advertising the existence of mirrors for these kind of > services should be done regularly. > > Ciao, > Alberto > > Andre Schaaff wrote: > > >Hi, > > > >It has never been published but since last year, CDS SOAP Web Services are > >available from CDS, CFA, CADC and ADAC. > >These services use as much as possible local resources like VizieR mirror. > >So if consumers implement an alternative access to a few clones they will > have a > >good availability guarantee. > > > >A great thanks to CFA, CADC and ADAC people involved in the reliability of > the > >servers. > > > >André > > > > > >For more information, please have a look at CDS Developer's corner : > >http://cdsweb.u-strasbg.fr/devcorner.gml > > > > > > -- > Alberto Conti > Branch Manager > Astronomer Tools and Applications > ESS/STScI > -- Alberto Micol ST-ECF HST Archive Scientist ESO & ESA/DSCI/RSSD/SN Space Telescope Division From owner-grid@eso.org Thu May 12 19:48:48 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 j4CHmJq6015151 for ; Thu, 12 May 2005 19:48:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4CHmJZ1015150 for grid-outgoing; Thu, 12 May 2005 19:48:19 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j4CHmFq6015145 for ; Thu, 12 May 2005 19:48:16 +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 j4CHmE73005023 for ; Thu, 12 May 2005 19:48:14 +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]:37152) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1DWHmy-0001DU-WD (Exim 4.51) for grid@ivoa.net (return-path ); Thu, 12 May 2005 18:48:01 +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 j4CHm0oL004853 for ; Thu, 12 May 2005 18:48:00 +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 j4CHm0Qq001476 for ; Thu, 12 May 2005 18:48:00 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j4CHm0LX001473 for ; Thu, 12 May 2005 18:48:00 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 12 May 2005 18:48:00 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: GWS timetable and materials for Kyoto 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.1, Antispam-Data: 2005.5.12.19 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I've updated the GWS page for the Kyoto meeting with timetable (as discussed on this list) plus links to current specs. Let me know if there's anything I've missed off. It would be helpful if you could add your names to the lists of intending participants. 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-wgchairs@eso.org Thu May 12 21:52:58 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 j4CJqoq6000532 for ; Thu, 12 May 2005 21:52:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4CJqox7000531 for wgchairs-outgoing; Thu, 12 May 2005 21:52:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-wgchairs@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 j4CJqLq6000445; Thu, 12 May 2005 21:52:22 +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 j4CJqK73008254; Thu, 12 May 2005 21:52:20 +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]:41301) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1DWJjB-0004y9-Th (Exim 4.51) (return-path ); Thu, 12 May 2005 20:52:13 +0100 Received: from cass89.ast.cam.ac.uk (cass89 [IPv6:2001:630:200:4240:a00:20ff:feb0:c66f]) by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j4CJqCoL007147; Thu, 12 May 2005 20:52:13 +0100 (BST) Received: from cass89.ast.cam.ac.uk (localhost [127.0.0.1]) by cass89.ast.cam.ac.uk (8.13.3+Sun/8.13.3) with ESMTP id j4CJqCP4000854; Thu, 12 May 2005 20:52:12 +0100 (BST) Received: from localhost (naw@localhost) by cass89.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j4CJqC3m000850; Thu, 12 May 2005 20:52:12 +0100 (BST) X-Authentication-Warning: cass89.ast.cam.ac.uk: naw owned process doing -bs Date: Thu, 12 May 2005 20:52:11 +0100 (BST) From: Nicholas Walton X-X-Sender: naw@cass89 To: grid@ivoa.net, wgchairs@ivoa.net cc: astro-rg@gridforum Subject: astro-rg session at the Kyoto IVOA interop 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.1, Antispam-Data: 2005.5.12.23 X-Virus-Scanned: by amavisd-new Sender: owner-wgchairs@eso.org Precedence: bulk Reply-To: Nicholas Walton X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dear All, the Astro-RG session at the IVOA interop is due to take place - Mon 16 May 2005 at 14.00. The meeting page is available at http://www.ivoa.net/twiki/bin/viewauth/IVOA/InterOpMay2005Astro-RG. At this meeting, we'll be looking current areas of interface and relevance between the astro-specific stds and mainstream grid computing stds worlds. Particular areas to be consider include proposals for the Universal Worker Service, being discussed in the GWS session - and how this could be brought forward in the context of the GGF. Also, presevation and curation issues will be targetted. There is plenty of time for discussion, so please email if you have any further agenda topics. Look forward to seeing you at the session. Yours, Nic ======================================================================== Dr N. A. Walton (AstroGrid Project Scientist http://www.astrogrid.org) (Euro-VO VOTC Project Scientist http://www.euro-vo.org) Institute of Astronomy Tel: +44 1223 337503 University of Cambridge Fax: +44 1223 337523 Madingley Road WWW: http://www.ast.cam.ac.uk/~naw Cambridge, CB3 0HA email: naw@ast.cam.ac.uk ======================================================================== From owner-grid@eso.org Fri May 13 13:36:10 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 j4DBZmsE003288 for ; Fri, 13 May 2005 13:35:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4DBZmH5003287 for grid-outgoing; Fri, 13 May 2005 13:35:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j4DBZisE003273 for ; Fri, 13 May 2005 13:35:45 +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 j4DBZiD03258 for ; Fri, 13 May 2005 13:35:44 +0200 (MEST) Message-ID: <42849110.6000905@eso.org> Date: Fri, 13 May 2005 13:35:44 +0200 From: Paul Harrison User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: grid@ivoa.net Subject: CEA Note Published Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Paul Harrison X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I have published the Common Execution Architecture Proposal (with associated schema and WSDL) to the IVOA site as a note http://www.ivoa.net/Documents/latest/CEA.html -- Paul Harrison ESO Garching www.eso.org From owner-grid@eso.org Tue May 17 02:24:11 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 j4H0NlbO022312 for ; Tue, 17 May 2005 02:23:47 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j4H0NlHo022311 for grid-outgoing; Tue, 17 May 2005 02:23:47 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j4H0NhbO022306 for ; Tue, 17 May 2005 02:23:44 +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 j4H0Ng73011390 for ; Tue, 17 May 2005 02:23:42 +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]:40771) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1DXprz-0006qd-W0 (Exim 4.51) for grid@ivoa.net (return-path ); Tue, 17 May 2005 01:23:35 +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 j4H0NZoL018260 for ; Tue, 17 May 2005 01:23:35 +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 j4H0NZKw006105 for ; Tue, 17 May 2005 01:23:35 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j4H0NZR5006102 for ; Tue, 17 May 2005 01:23:35 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Tue, 17 May 2005 01:23:35 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Note on securing web services 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.1, Antispam-Data: 2005.5.16.34 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: Guy Rixon X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Matthew Graham has posted a note on securing Java web services at http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/Java-security-howto.html This should be read as one of the current-practice reports for the GWS meeting tomorrow. 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-grid@eso.org Sat Jun 11 03:36:48 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 j5B1aQhb026660 for ; Sat, 11 Jun 2005 03:36:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j5B1aQAK026659 for grid-outgoing; Sat, 11 Jun 2005 03:36:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@eso.org using -f 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 j5B1aMhb026647 for ; Sat, 11 Jun 2005 03:36:22 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j5B1aMcp026646 for ws-outgoing; Sat, 11 Jun 2005 03:36:22 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ws@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 j5B1aIhb026636 for ; Sat, 11 Jun 2005 03:36:18 +0200 (MEST) Received: from hermesnew.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 j5B1aG73020705 for ; Sat, 11 Jun 2005 03:36:17 +0200 (CEST) Received: from vpn001.ex.ac.uk ([144.173.5.1]) by hermesnew.ex.ac.uk with esmtp (Exim 4.50/mail) id 1Dguux-0005NF-Dg for ws@ivoa.net; Sat, 11 Jun 2005 02:36:11 +0100 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ws@ivoa.net From: Alasdair Allan Subject: Fwd: WSRF::Lite version 0.4 released Date: Sat, 11 Jun 2005 02:36:14 +0100 X-Mailer: Apple Mail (2.622) X-Exeter-Interface: mail X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.6.10.32 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: For those of you who don't read the OGSI-Lite mailing list, and might be interested, it looks like Perl now has support for WS-Addressing and WS-Security... Begin forwarded message: > From: Mark McKeown > Date: 10 June 2005 11:49:39 BST > To: ogsi-lite@lists.man.ac.uk, > Cc: sjzasada@btinternet.com > Subject: [OGSI-LITE] WSRF::Lite version 0.4 released > > > Hi folks, > There is a new release of WSRF::Lite (0.4) available at: > http://www.sve.man.ac.uk/Research/AtoZ/ILCT/ > > The new version supports the current versions of the WS-Addressing > (http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/) and WSRF > (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf). The > new version of WS-Addressing has caused major changes in WSRF::Lite > which might cause interoperability problems with older versions of > WSRF::Lite. > > Unfortunately these specifications are not standards yet - so things > could change again. > > The other big news is support for signing SOAP messages with X509 > digital certificates according to the OASIS WS-Security standard - the > support for this is still beta quality. Big thanks goes to Stefan > Zasada who did most of WS-Security work for his Master's project. > > cheers > Mark > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Mark Mc Keown RSS > Mark.McKeown@man.ac.uk Manchester Computing > +44 161 275 0601 University of Manchester > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > _______________________________________________ > Ogsi-lite mailing list > Ogsi-lite@lists.manchester.ac.uk > http://lists.manchester.ac.uk/mailman/listinfo/ogsi-lite From owner-grid@eso.org Thu Jul 14 17:02: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 j6EF27il016717 for ; Thu, 14 Jul 2005 17:02:07 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6EF27qs016716 for grid-outgoing; Thu, 14 Jul 2005 17:02:07 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j6EF23il016702 for ; Thu, 14 Jul 2005 17:02:03 +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 j6EF21in005519 for ; Thu, 14 Jul 2005 17:02:02 +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-6.6) with ESMTP id j6EF1sgi004657 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 14 Jul 2005 08:01:55 -0700 Mime-Version: 1.0 (Apple Message framework v622) To: grid@ivoa.net Message-Id: <35f7564e3a83dc63c60781ac72fbe7bf@cacr.caltech.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-1--835290537 From: Roy Williams Subject: good paper on workflow from UK guys Date: Thu, 14 Jul 2005 08:01:53 -0700 X-Mailer: Apple Mail (2.622) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.14.13 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: --Apple-Mail-1--835290537 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Good paper on workflows. Forwarded from Teragrid. > http://www.e-framework.org/SOAandWorkflow2.pdf Roy Begin forwarded message: > From: Catlett Charlie > Date: July 14, 2005 7:56:30 AM PDT > To: gateways@teragrid.org > Cc: Catlett Charlie > Subject: [gateways] good paper on workflow from UK guys > Reply-To: Catlett Charlie > > > http://www.e-framework.org/SOAandWorkflow2.pdf > > > California Institute of Technology 626 395 3670 --Apple-Mail-1--835290537 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Good paper on workflows. Forwarded from Teragrid. http://www.e-framework.org/SOAandWorkflow2.pdf Roy Begin forwarded message: Helvetica0000,0000,0000From: HelveticaCatlett Charlie < 0000,0000,0000Date: July 14, 2005 7:56:30 AM PDT 0000,0000,0000To: gateways@teragrid.org 0000,0000,0000Cc: Catlett Charlie < 0000,0000,0000Subject: [gateways] good paper on workflow from UK guys 0000,0000,0000Reply-To: Catlett Charlie < http://www.e-framework.org/SOAandWorkflow2.pdf HelveticaCalifornia Institute of Technology 626 395 3670 --Apple-Mail-1--835290537-- From owner-grid@eso.org Thu Jul 21 18:38: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 j6LGbfcq029919 for ; Thu, 21 Jul 2005 18:37:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6LGbfF7029918 for grid-outgoing; Thu, 21 Jul 2005 18:37:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j6LGbacq029907 for ; Thu, 21 Jul 2005 18:37:37 +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 j6LGbZhx014084 for ; Thu, 21 Jul 2005 18:37: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]:51412) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1Dve34-0006Qm-P0 (Exim 4.51) for grid@ivoa.net (return-path ); Thu, 21 Jul 2005 17:37:26 +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 j6LGbQZu020060 for ; Thu, 21 Jul 2005 17:37:26 +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 j6LGbQc5025469 for ; Thu, 21 Jul 2005 17:37:26 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j6LGbQUV025466 for ; Thu, 21 Jul 2005 17:37:26 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 21 Jul 2005 17:37:26 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: New mailing list: vospace 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.7.21.16 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, we have a new mailing list vospace@ivoa.net for discussions of VOStore and associated protocols. This results from a groups decision at Kyoto to seperate the VO-Store discussion from the main, group list. Please subscribe to the new list if you want to keep up with VOStore developments. 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-grid@eso.org Fri Jul 22 07:56: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 j6M5u5YG029894 for ; Fri, 22 Jul 2005 07:56:05 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6M5u5xs029893 for grid-outgoing; Fri, 22 Jul 2005 07:56:05 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j6M5u1YG029889 for ; Fri, 22 Jul 2005 07:56:01 +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 j6M5txin029113 for ; Fri, 22 Jul 2005 07:55:59 +0200 (CEST) Received: from esa-spas2.gmessaging.net (relay [172.24.21.38]) by esa-av-smtp1.gmessaging.net (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IK0009HALT3OA@esa-av-smtp1.gmessaging.net> for grid@ivoa.net; Fri, 22 Jul 2005 07:55:51 +0200 (MEST) Received: from localhost (esa-spas2 [127.0.0.1]) by esa-spas2.gmessaging.net (Postfix) with ESMTP id 8C239219E7C; Fri, 22 Jul 2005 07:55:51 +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 10799-04; Fri, 22 Jul 2005 07:55:50 +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 19B2B219E74; Fri, 22 Jul 2005 07:55:50 +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 B023D11F8EF; Fri, 22 Jul 2005 07:55:51 +0200 (CEST) Received: from isoc01.esa.int (isoc01 [193.147.153.89]) by iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id j6M5toHE028431; Fri, 22 Jul 2005 07:55:50 +0200 (MEST) Date: Fri, 22 Jul 2005 07:55:43 +0200 From: Christophe ARVISET Subject: Re: New mailing list: vospace In-reply-to: To: grid@ivoa.net Cc: Christophe.Arviset@esa.int Message-id: <6.2.3.4.0.20050722075521.02dc8a48@iso.vilspa.esa.es> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: Content analysis details: (-1.2 points, 4.5 points required to be considered as spam) -1.2 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] References: X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.7.21.47 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Guy I can not find it on the IVOA subscription page http://www.ivoa.net/forum/index.html ? Thanks Christophe At 18:37 21/07/2005, you wrote: >Hi, > >we have a new mailing list > >vospace@ivoa.net > >for discussions of VOStore and associated protocols. This results from a >groups decision at Kyoto to seperate the VO-Store discussion from the main, >group list. Please subscribe to the new list if you want to keep up with >VOStore developments. > >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 Cheers Christophe --- Christophe ARVISET --- European Space Agency (ESA) --- European Space Astronomy Centre (ESAC) --- Research and Scientific Support Department (RSSD) --- Science Operations and Data Systems Division (SCI-SD) --- Urb. Villafranca del Castillo --- P.O. Box 50727, 28080 Madrid - SPAIN. --- Tel: +34 91 813 12 78, Fax: +34 91 813 11 72 --- E-mail : Christophe.Arviset@esa.int From owner-grid@eso.org Fri Jul 22 08:47: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 j6M6lWA0006054 for ; Fri, 22 Jul 2005 08:47:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6M6lWOc006053 for grid-outgoing; Fri, 22 Jul 2005 08:47:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j6M6lRA0006017 for ; Fri, 22 Jul 2005 08:47:28 +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 j6M6lPhx007421 for ; Fri, 22 Jul 2005 08:47: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]:45690) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1DvrJX-0005kI-5B (Exim 4.51) (return-path ); Fri, 22 Jul 2005 07:47:19 +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 j6M6lJZu003340; Fri, 22 Jul 2005 07:47:19 +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 j6M6lJ8x026003; Fri, 22 Jul 2005 07:47:19 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j6M6lHgq026000; Fri, 22 Jul 2005 07:47:17 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 22 Jul 2005 07:47:16 +0100 (BST) From: Guy Rixon To: grid@ivoa.net cc: Christophe.Arviset@esa.int Subject: Re: New mailing list: vospace In-Reply-To: <6.2.3.4.0.20050722075521.02dc8a48@iso.vilspa.esa.es> Message-ID: References: <6.2.3.4.0.20050722075521.02dc8a48@iso.vilspa.esa.es> 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.49 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Christophe, Marco may not have set up the index and archive yet. You can still subscribe. IIRC, you need to send an email to majordomo@ivoa.net containing only the line subscribe vospace Cheers, Guy On Fri, 22 Jul 2005, Christophe ARVISET wrote: > Guy > > I can not find it on the IVOA subscription page > http://www.ivoa.net/forum/index.html ? > > Thanks > > Christophe > > > At 18:37 21/07/2005, you wrote: > >Hi, > > > >we have a new mailing list > > > >vospace@ivoa.net > > > >for discussions of VOStore and associated protocols. This results from a > >groups decision at Kyoto to seperate the VO-Store discussion from the main, > >group list. Please subscribe to the new list if you want to keep up with > >VOStore developments. > > > >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 > > > > Cheers > > Christophe > > --- Christophe ARVISET > --- European Space Agency (ESA) > --- European Space Astronomy Centre (ESAC) > --- Research and Scientific Support Department (RSSD) > --- Science Operations and Data Systems Division (SCI-SD) > --- Urb. Villafranca del Castillo > --- P.O. Box 50727, 28080 Madrid - SPAIN. > --- Tel: +34 91 813 12 78, Fax: +34 91 813 11 72 > --- E-mail : Christophe.Arviset@esa.int > 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-grid@eso.org Fri Jul 22 09:08:09 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 j6M77p0R008545 for ; Fri, 22 Jul 2005 09:07:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j6M77p0E008544 for grid-outgoing; Fri, 22 Jul 2005 09:07:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j6M77d0R008518 for ; Fri, 22 Jul 2005 09:07:39 +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 j6M77dE14898 for ; Fri, 22 Jul 2005 09:07:39 +0200 (MEST) Message-ID: <42E09B5B.1030608@eso.org> Date: Fri, 22 Jul 2005 09:08:11 +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: grid@ivoa.net Subject: Re: New mailing list: vospace References: <6.2.3.4.0.20050722075521.02dc8a48@iso.vilspa.esa.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090206040105040102060104" X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------090206040105040102060104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, everything was working, but the forum page (http://ivoa.net/forum/) wasn't updated, yet: now it is. Cheers, Marco On 22/07/2005 08:47, Guy Rixon wrote: >Christophe, > >Marco may not have set up the index and archive yet. You can still subscribe. >IIRC, you need to send an email to majordomo@ivoa.net containing only the line > >subscribe vospace > > > Right! >Cheers, >Guy > >On Fri, 22 Jul 2005, Christophe ARVISET wrote: > > > >>Guy >> >>I can not find it on the IVOA subscription page >>http://www.ivoa.net/forum/index.html ? >> >>Thanks >> >>Christophe >> --------------090206040105040102060104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

    everything was working, but the forum page (http://ivoa.net/forum/) wasn't updated, yet: now it is.


Cheers,
    Marco

On 22/07/2005 08:47, Guy Rixon wrote: 
Christophe,

Marco may not have set up the index and archive yet. You can still subscribe.
IIRC, you need to send an email to majordomo@ivoa.net containing only the line

subscribe vospace
Right!

Cheers,
Guy

On Fri, 22 Jul 2005, Christophe ARVISET wrote:

  
Guy

I can not find it on the IVOA subscription page
http://www.ivoa.net/forum/index.html ?

Thanks

Christophe
--------------090206040105040102060104-- From owner-grid@eso.org Thu Aug 18 18:39: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 j7IGcAUd028448 for ; Thu, 18 Aug 2005 18:38:10 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j7IGcAhl028447 for grid-outgoing; Thu, 18 Aug 2005 18:38:10 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j7IGc6Ud028437 for ; Thu, 18 Aug 2005 18:38:06 +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 j7IGc3hx021215 for ; Thu, 18 Aug 2005 18:38:04 +0200 (CEST) Received: from [172.16.1.35] (adsl-69-234-37-135.dsl.irvnca.pacbell.net [69.234.37.135]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id j7IGbvgh003954; Thu, 18 Aug 2005 09:37:57 -0700 Message-ID: <4304B964.3070302@cacr.caltech.edu> Date: Thu, 18 Aug 2005 09:37:56 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: techwg@us-vo.org, grid@ivoa.net Subject: Attachments and WS-Security 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.18.17 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I have been doing some background reading on advanced WS technologies and it turns out that SwA and DIME are incompatible with WS-Security (and other WS-*): the problem is both SwA and DIME introduce data structures that are external to the XML Infoset and so when you come to do something like digitally signing the SOAP message with WS-Security, there are no rules to specify how the attachment content relates to the SOAP envelope. Of course, the solution is to use MTOM which has support in Axis2 and WSE 3.0 at least, although these are both very new (bleeding edge). Cheers, Matthew From owner-grid@eso.org Fri Aug 19 12:40: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 j7JAeGQF002793 for ; Fri, 19 Aug 2005 12:40:16 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j7JAeGpF002792 for grid-outgoing; Fri, 19 Aug 2005 12:40:16 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j7JAeCQF002777 for ; Fri, 19 Aug 2005 12:40:12 +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 j7JAeAin011643 for ; Fri, 19 Aug 2005 12:40: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]:45967) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1E64I5-00073B-0j (Exim 4.51) for grid@ivoa.net (return-path ); Fri, 19 Aug 2005 11:40:01 +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 j7JAe0Zu010278 for ; Fri, 19 Aug 2005 11:40:01 +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 j7JAe0lh029668 for ; Fri, 19 Aug 2005 11:40:00 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j7JAe09U029665 for ; Fri, 19 Aug 2005 11:40:00 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 19 Aug 2005 11:40:00 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: availability schema v0.2 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.19.4 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, I am implementing the getAvailability interface as one of the prototypes required before VO support interfaces can go to PR. I've posted v0.2 of the availability schema at http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/availability-v0.2.xsd This version has two main changes. First, I've included a vr:Contact element to satisfy the requirement in the text of the spec. Second, I've include a boolean element called "available" to show whether a running service is currently available for work. This second element is needed to cover the case where a service is up but some of its dependencies (DBs etc.) are down so it can't do useful work. 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-grid@eso.org Fri Aug 19 18:04: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 j7JG4VQF019294 for ; Fri, 19 Aug 2005 18:04:31 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j7JG4Vu6019293 for grid-outgoing; Fri, 19 Aug 2005 18:04:31 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j7JG4RQF019286 for ; Fri, 19 Aug 2005 18:04:27 +0200 (MEST) 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 j7JG4Oin022808 for ; Fri, 19 Aug 2005 18:04:25 +0200 (CEST) Received: from chandra.pha.jhu.edu (chandra.pha.jhu.edu [128.220.233.43]) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id j7JG4IU24334 for ; Fri, 19 Aug 2005 12:04:18 -0400 Received: from localhost (thakar@localhost) by chandra.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id j7JG4IN05811 for ; Fri, 19 Aug 2005 12:04:18 -0400 X-Authentication-Warning: chandra.pha.jhu.edu: thakar owned process doing -bs Date: Fri, 19 Aug 2005 12:04:18 -0400 (EDT) From: Ani Thakar X-X-Sender: thakar@chandra.pha.jhu.edu To: grid@ivoa.net Subject: Re: availability schema v0.2 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.0.3.2, Antispam-Data: 2005.8.19.15 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Fri, 19 Aug 2005, Guy Rixon wrote: > Hi, > > I am implementing the getAvailability interface as one of the prototypes > required before VO support interfaces can go to PR. I've posted v0.2 of the > availability schema at > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/availability-v0.2.xsd > > This version has two main changes. First, I've included a vr:Contact element > to satisfy the requirement in the text of the spec. Second, I've include a > boolean element called "available" to show whether a running service is > currently available for work. This second element is needed to cover the case > where a service is up but some of its dependencies (DBs etc.) are down so it > can't do useful work. hi guy, i'm not sure why we need this distinction, i.e. if it cannot do useful work, is it not effectively unavailable? OTOH, i think this parameter is a good idea anyway because the current spec (SI-3) does not include anything that directly tells you if the service is currently available or not, which seems like a major oversight (or am in missing something?). ani -- Aniruddha R Thakar, Research Scientist, The Sloan Digital Sky Survey Ctr for Astrophys Sci, JHU, 3701 San Martin Dr Baltimore MD 21218-2695 410-516-4850 fax:410-516-5096 thakar@jhu.edu www.sdss.jhu.edu/~thakar ----------------------------------------------------------------------- Good judgment comes from experience, and experience -- well, that comes from poor judgment. From owner-grid@eso.org Fri Aug 19 19:02:41 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 j7JH2LQF025377 for ; Fri, 19 Aug 2005 19:02:21 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j7JH2L6k025376 for grid-outgoing; Fri, 19 Aug 2005 19:02:21 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j7JH2GQF025367 for ; Fri, 19 Aug 2005 19:02:16 +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 j7JH2Ein024742 for ; Fri, 19 Aug 2005 19:02: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]:49023) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1E6AFr-0005Zj-TY (Exim 4.51) for grid@ivoa.net (return-path ); Fri, 19 Aug 2005 18:02:07 +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 j7JH26Zu027916 for ; Fri, 19 Aug 2005 18:02:06 +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 j7JH26bB000053 for ; Fri, 19 Aug 2005 18:02:06 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.3+Sun/8.13.3/Submit) with ESMTP id j7JH26xZ000050 for ; Fri, 19 Aug 2005 18:02:06 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Fri, 19 Aug 2005 18:02:06 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Re: availability schema v0.2 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.8.19.18 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ani, yes, a service that cannot work is formally unavailable. That was what I meant. Guy On Fri, 19 Aug 2005, Ani Thakar wrote: > On Fri, 19 Aug 2005, Guy Rixon wrote: > > > Hi, > > > > I am implementing the getAvailability interface as one of the prototypes > > required before VO support interfaces can go to PR. I've posted v0.2 of the > > availability schema at > > > > http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/availability-v0.2.xsd > > > > This version has two main changes. First, I've included a vr:Contact element > > to satisfy the requirement in the text of the spec. Second, I've include a > > boolean element called "available" to show whether a running service is > > currently available for work. This second element is needed to cover the case > > where a service is up but some of its dependencies (DBs etc.) are down so it > > can't do useful work. > > hi guy, > > i'm not sure why we need this distinction, i.e. if it cannot do useful > work, is it not effectively unavailable? OTOH, i think this parameter > is a good idea anyway because the current spec (SI-3) does not include > anything that directly tells you if the service is currently available > or not, which seems like a major oversight (or am in missing > something?). > > ani > > -- > Aniruddha R Thakar, Research Scientist, The Sloan Digital Sky Survey > Ctr for Astrophys Sci, JHU, 3701 San Martin Dr Baltimore MD 21218-2695 > 410-516-4850 fax:410-516-5096 thakar@jhu.edu www.sdss.jhu.edu/~thakar > ----------------------------------------------------------------------- > Good judgment comes from experience, and experience -- well, that comes > from poor judgment. > 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-grid@eso.org Thu Sep 22 09:10: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 j8M7A3SM017098 for ; Thu, 22 Sep 2005 09:10:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j8M7A3Pf017097 for grid-outgoing; Thu, 22 Sep 2005 09:10:03 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j8M79sSM016960 for ; Thu, 22 Sep 2005 09:09:54 +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 j8M79qin020138 for ; Thu, 22 Sep 2005 09:09: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]:53955) by ppsw-1.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.131]:25) with esmtp id 1EILAA-00008i-4r (Exim 4.53) for grid@ivoa.net (return-path ); Thu, 22 Sep 2005 08:06:34 +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 j8M76TZu003131 for ; Thu, 22 Sep 2005 08:06:34 +0100 (BST) 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 j8M76TG3015046 for ; Thu, 22 Sep 2005 08:06:29 +0100 (BST) Received: from localhost (gtr@localhost) by cass123.ast.cam.ac.uk (8.13.4+Sun/8.13.3/Submit) with ESMTP id j8M76O06015043 for ; Thu, 22 Sep 2005 08:06:29 +0100 (BST) X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs Date: Thu, 22 Sep 2005 08:06:24 +0100 (BST) From: Guy Rixon To: grid@ivoa.net Subject: Topics for GWS at next Interop 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.9.21.44 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, we need to set an agenda for the GWS session at the interop meeting. I suggest that we concentrate on progressing the security and VOStore stories since these are the most critical and have the most need for discussion. We can talk about UWS if people want to, but my feeling is that UWS is going to slip into 2006 and is less urgent. By the interop meeting, we should all have seen a VOStore demonstration (run during ADASS). I'd particularly like to get feedback on that demonstration. Please let me know if this is OK, or if there are other topics you want to cover. I'd also like to show a summary of implementations of the draft standards. To that end, please send me a note of any implementations you have on hand, including draft-spec version, endpoint and WSDL URL if pos. 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-grid@eso.org Fri Sep 23 19:58:17 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 j8NHtm04012349 for ; Fri, 23 Sep 2005 19:55:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j8NHtmXg012348 for grid-outgoing; Fri, 23 Sep 2005 19:55:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-grid@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 j8NHta04012334 for ; Fri, 23 Sep 2005 19:55:37 +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 j8NHtVhx018992 for ; Fri, 23 Sep 2005 19:55:32 +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 j8NHtNGM009097; Fri, 23 Sep 2005 10:55:23 -0700 Message-ID: <43344186.1060908@cacr.caltech.edu> Date: Fri, 23 Sep 2005 10:55:18 -0700 From: Matthew Graham User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nvoss@us-vo.org, grid@ivoa.net Subject: WS-* poster Content-Type: multipart/mixed; boundary="------------050106050902070800010700" X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.9.23.19 X-Virus-Scanned: by amavisd-new Sender: owner-grid@eso.org Precedence: bulk Reply-To: grid@ivoa.net X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------050106050902070800010700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Attached is a very nice poster illustrating all the WS-* standards that we need to keep track of :-) Cheers, Matthew --------------050106050902070800010700 Content-Type: application/pdf; x-mac-type="0"; x-mac-creator="0"; name="Web_Services_Standards_09_2005.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Web_Services_Standards_09_2005.pdf" JVBERi0xLjMNJeLjz9MNCjcgMCBvYmoNPDwNL0xlbmd0aCAxODU0NDMNL0ZpbHRlciAvRmxh dGVEZWNvZGUNPj4Nc3RyZWFtDQpIiaRXyZIjtxH9Av4DjkVJrMG+3GzNaAk5dJCGETpIOnDY 1dPUcGmRHLVGP+TwZ/lP/DIBVKHYHWFH+MBg8RHIfPlyAer3hRI7sZBC+WiFNlGJFT+eh8VP 4riQvTT8Xy81/S37FPMKAsoiJd4vXn3zFl+XaUNZHRqD959hqexVFBJf3ol/wPF3+PGb0H00 TjwJJcX34udfpbhbqBRd74NQ1jjYEUabXjlYU971kg0W2ofFW/jFfjj3ho1rHcSHxUrZXsGC T5G+TUq9J/pB6V7pmQVw+3K9ePW1F0qs7xfKq96RJZGfnO990glkYCPYKNaHm1g+kASaJFiB hoQ66+2Cn2DwafFz99NSq952w1L3vnsn3g7nJWLpdffHbjtcxNslfqjumr82S9kd78rzeaki 9txdlr+uv1sAC4UaP0En22unoZ2GTt4SNzhWyTCF7H13PJ5+EG+Gj9fL9mG/Od6Jbw7vvl2u bAy6/Pl2+/A07P7Kf5CnV1+nrIbM7hCjhHq9jM6L9Rt2Eiw5+bn7drO/fBguV+Yaus0/h+UK SehNp5ZOdmG5SsEExP/N8DSc3zUrL5dmKVIe8EXe15/B7JvVcuWQzs7KGKX4cXPdHd8Px+Uq 2oTq6F4jBO26uspDUgfJjJHi9cPmUA0xU09Mc3JMFmVNFFI37If70/FzstHZJH7pIEsCLhn5 ZSn00nj8VrBuNQjKvE+TN3IL98EhRtQDRZoXqSXqNFOyZbGkBSv8oTsJ41rFgIUvsViq6jCE 7hkhODKdsCMrgJWCpvCtwcaEnsIOQ0xWiYqO5U2TvFP+Vm2hrnNiBpQgKG3+pDIlh5/XVGSJ HAUjC1ZFClWklEUKVSSbGWIpBGp0SqwTqyTJyao+SDIXyZxRENCPtBpOeuJEgoUiGPF5gaAd CU5JYz6a8pM1a/1Gzd8QN5V2qMPhpvG5KQwaqTbFTefdn/5GHfZ7vz0dEE7A8On+zQ/d09PT 0jn46acVN63nxcrDlzYG4yN5JYxFk+An9Tknzqncg+uH3UU8ni7X4SzwdDxdxfUk3g2CWy12 w2PpudPdx+1wJ05ncS1/bY6Xw+56Bbg7is3xk7g/nQ+0AN/8+/HjGZYH8bS7Ppw+wvDDIIY/ yWBCNMMFjofzYXe57E5HcboXeaTQKBEckMPYMJi0kjRCX0+DqIcSGkOVJdFU5q9Pj5/Ou/cP 17xVikRzbpXy3EPkOHy8FjTFdUo87kiA7l/L9W8vCRZofDoTnwnWkGwJib/v9+JHInARPw6X 4fzHAHCNiIu4h80ngXl3EtvT8bqBYiyD7ob7oSg8HGmmQ/0ThDpj3eERKi6d776AqnnN+81x d8FAOx2/EO/GPNwJ+jxW0bxXropW1lD2ruK4OQwXZoWsjPapv/9HD8+tiU0tFPHxglJ4GKNB iFQIu7vheN3d77Zss9bERZyO+09slIRBvVXyLiBNhTwVzLWUy+ZuOGzOHy5UKMB357FCL4/D 9rr7YxCnp+NQwEvP9r5aL/hkR19INF059nA+414gPa4HiD0h9aQZHe01/3SBwOHiyin/6qvD u+Hubrh7c9p+PCAe8er710p8+eb14ofF7/k69F9t//QZ3Y3+r0vTdKbi3mDo3qC1M73XVigX LOaJB2Gt4ZMvHhXb53XOQgiHEybCNmEYCtqEOXZrb7+4p5W6t1rNvWAiBh3mXrDO2LlB6jzc s+aOb8xlJzTk/I0Tb/ro3NwJ1unbUCCYszeh3NrLXqLpDW58My8Y6tLFuRess/YmloTbk003 nm/slVhirwP5TqFPpnjBNALkpUJMSTBpDCRCAu6yJiOJAIwpqazYkk/cWRwvitC28LC9DcQN hCSqFBvROZJZoOxkAOKhktcFUYZtWRyqyRYMCUB24ChQRDAZrSPE9FoxTbRdDLzP4BIsqbbp 8qlzWmPvcG/EMip3MmXBhchTyHRH4DRTWGzc4i5VKOAJ2zwKm7elHAuGFoRk5jjLoylIyCoE HJ+proq0DwoblWXRyovnkm8XD+QPc1wXVi4YTkTFvLR0MRVc9UmWoI23mYRVZkKIhMfdiVt8 XEWlKG1rqSLV33bRYqpoVS05urxyONVfRbaLidW0aoqmWrqNb8uvTAlvLzGWNqZjDGHjDOsD JtOIIY1Smd64CdJSQ2j6jRzKNP3GrZPeT8CqIglXHmRkMoG3HIu7TeOnINuWT8H2L3DcU8Jw 0QbK9hzQkJnjVSqnNmPMXPbtMgCo4MhuMV1MCzTkJ4yOGqZf7KB8LJXf5Kwg25ZUwfYvEN2T 8pDHw3DOWRUeUOBAY2QiQPByySMspjwLpAENHokFIa9oRbw7zlZBqVDyMSJB2cnf9jmFrCsO tKR5xlEGeCJJXFszjTF4mCtIQMuzA1WIFYQdIHPOt6vGEGFdxygaEprfNDke+s9P2H6GoZBp Hx+8tDFRXcUsjcsVlhFmgDzqdpHGmZditpMQXovgSLMub6vYRJw0KkWIscfx+tolSmXeeAqx XeMnwCvRiuu4rLYvCF7qw2FulSpNPI4kHc15mjO0byFwfwbVynUYr/moDvyAGYO55NKEEA3r IXCYrfKsPizJUkQTYrjt6z7GJlaY8NS7L0JgZfQNRkOExpa0pvIqAlq8xKq5yPSC1UAcHlUS a0pMWILgSnHKUuvARhFkGWoTNg26KvsLUI0G57b09J6QpZHBcnoqFDzGChHD8FZGN0w92jPq WTQBcijVrMEZYFUpmRxNMBNSOxcYLiO5IQ1CIJrYGSqWpweMJzdLfKCz188TD1bFVl3l0bbW t006IqUUeN+IJZqj+0xLpvAyNNXCuPEliAZejqfqiQMEh/ccmjai57V9GZpIjNl6juT85aRi WCauJBjzeSRHJDNDiENSgjAspTbtSIkkfINwgtLtKup4vjsmxfE0CPzWwTNhqiQx0vGRW87y vKpAmA6AEYocDQDK/Gw80x3ShPl4JpLJtqvw4LRuLQW6fxWkVgxIFluYrsnlPAcIVbBc/rBu bDsxQUr5eTOTmLOGj3TWq9zMuRhHBBHUmTNhnjudw3NsKGZKLUJlbfK+EQM3vpQgd1mC8eik e3qcn69gma9c4xrMPFmOZbpMcel4X0pMhuJtXk5cYwoXQFyTMxicoiJTErWrylFG1Q8Es1u7 tnxwH3LcuU2R4ZHu4u0qZLkSY0sNYkYZRoyuwoqOcxgIpj254C4E2+aKOAXT5ErhYqN8STmP CQrO1TepoELehtedPEzo4FZULLQzh1fGF0sgdTuElJRQtDmPmHjgu/w0qRJdIU0ujlx1E9LE O2KBzzg2lNWETtR67M41wHbRcJoWIVGuVAIdVBxJ5PldrhPbF1JcEo9zx6lpjFPi8ZoUayOV 02bCEMBzzOXqVnjxczG03BQa1el5BApVoM1sFZDcAT63fINYjqnuq21ZOfyH7irZseM4gl/w /qHPAjisvbqupggBEngQdNBB0MWPlCBxhoZMG/p9R0TW1jNj8MDpeLVk5RIZGaAwUv4/2EmB mK8YskzO9iF0y0aaeo9qUdWtZPYY2PyOAYndevhRoxv90NxpZ6do24ZrDNq9VRy1RrCM695/ DVsvYpwosNW1lzD30HoudfEpVkZff0hu5wQfQWXnJtVpHKRdLf6y6uyj7hDmRFrN6777KzZI mUNvw0PHLsx9wqM1MQ5hzuM60jndQ4SaYYv5PSYG78/LqvHE0fM3I6Yy9xBoOW1q/fGCmTL3 0HXFn3skOXw8Iy8fWjdrrsIkEMoqpQ2YwnxC024cY0cPVkIczrKoTK+FTy7MRbd1civ6Hp6d qvy5s02Uw9gHZ0w9h06kFIK8YfRJwZvEp2Pq9AV/2M70AoG/kt06MfiA1KGTgk5nN4nHdp0B 990qgx5fMdQyKEP1+E3dPu0rt7peByblu56E7m2yasOojsLC0EwoM0JnBAVoInhmt3dBKAK2 Yb67+7BpJtAzuwcNue/md+zxlSf1QPEK53vuwI6nHZtdh41r8K8SA20kunZJHirAfd7wqOWu rcYxE+mXadvEmlUFSvmiErfLtqqgorqUznpIP+f5y+6KLCWZobDSArugYpmDmgnzKHWDacHW M6gz9z4CJI2n1B7lheg2bZuQ74HnSHoZKDfvzpbuoS9NOM1Vy26vpvLicXeFOFBY1Dzl1RMh TLq1CyKpdbwX0fO7Q5E7vvir11Ek6boIuWrzSBfrC1lifcO6WA9QEaHsan0hS65vWFfZHmNP jG3nNZSGH4Jo5BTN3JkcCHzsLwcFe8lS64T6SVOtc585aqh1nl33YZUGZGmdWQpyZtrKJbiM h3TiVPAWstT6hnW17jHSdcd1tb4hU61vWFfrdFPae6yiWctVrtPM7DdMeTFkv+Q6c8flLvu7 XH+eT1IDEAkPKWyD4tOOIXflPHShh9Q2+Qz6egjp0oQCNU/dnedB8WfvQuylQNpCuhQgVtJG Wo+G+YFZ3nn+uBURb0tlQ3RUHkfNVYiMD1vTXwjeO/y5sNYlFi2w41+B4L7WobHxNejUgPK4 +7MVFdsVm1tdQa68imxGzHC9AlkEGdf3H97d3r5/+uenjx8/ffz2X/f/Pn368p/j7Yd34fjH t+9uP97+uvnjj+OGhGP7PRCeh3xEyAZ0gjdSVOX496fbz98cX24OqhJRCxHDzRv9yV/4wwMV YmFvDPzZgQ9tBYG5CGSCldjs8H9o4fh8e/vdT+n4/as90ZPIInMSyYkkTSdPcWRXXfUbzvDa jf3I+8/WfeJJuxlFPB4FEBrNQ23AZdqFNyp7bGODbfzr/vTsuB/wwO/x8Sc+IwL89wHuKOn4 cPzyqzs+0tYoW9nhvOOlkNikCc5PjXfqf9z5Ezzr7VQejg5OWzNcrKwHZXZJlTJ4uEwICq71 eu3uoKIMFQVWqDXbEJSZRVjQpRJZJqDfId1JcWX7RkhZZdpiCLuFj8c8ggSdYlrXkMJa7mLS TMGYAbrg/91Y/PHgtQlWeyloA+5dPPkqyEX+BCOTb9splXoz66Yz19EaSdLLmsrWVTd7B7A9 aUDz1f0U3uh1db9pd123Ru5tfEq3dwXgWZBMdHB0Qbvk9WcflDoChsmumNIOvAyXRhsO2KIT y+IhF+N5OFCKo6AZZD4r4RRkry9BXl+3d0BaEDewFcw1w+R5CpSzhsztJujVyE40rcHDC+XB tHcA9qTuGyEcZ+3cfgg6ZlDvGhdRWbhwiTdSv0k+dHPZZE6/PWkA8oM9e62BY3Jq2ynDedtN w8HTmhGCae81Sne2NQcRWdQ2kW0+M3QDYi9z4mUHwqoSji8Q6iwfDArWwUFUlTnpwAJRJYNa 4kTqzlNKnqkeqvLNQTgFJ9tAfFyDoYizJoGWeAraQ4ttAnwpLk01rjUepdKr1IrUO4w/qjIZ zD0kf/EFHqeKwU+RvnVovsQ9R8sq8x20hvag+dLbCEMO9Ch6FumZr646HoBqC4VZewUBOjlS wu7ChuGhAFwsiotTMAdAUdJnzAH1KFCY4U1eEuslhLbB9r1DaIVOAyy1y4lmA9Fmz0VUclai xJ7HFG+BrkUHKObhquRCDFqPQQvnBBQneOu6BuSdLQFy6MH18h947JQqdlB5HKroHWpaAEnO p29qkO+jKpICr4Zgm+Bbdku4Kza69qRqbeI6ZiUCAAdzAZ5hSQQkK6+pDvuSyFHiZHu+ANjj ytgkaPn3eS1I9zkkzHmtD0O2Yghsn+k1ZCuPgNzciiNAgqnqR3GEsw9Zqzgi5etWGxEZlLa8 d+hAQXtmbaDfYbhs2xpQR01+1YYDuYSQttpw2YnYZm04iJwi0rLacKColvNeG2h8eFlateHg oHjWVRsEaml7bTh2lexXbRCI6NCzNiawamNCW6DUJ/Kr0KqNCY3acAm/USb22oAv0SHjXhsu oRWSSUZtiDL3vEcMfFyAwgRvyTtzDaVc22oDsU05XmojFE1QqzYCi24rDeRLrdfSCOz2W2WE oBY8KwPf5t5ZGYHPiFtlACg1bJUxgVUZA9q8ey0CFgYMRQa4PPLIW0N4g2gF5IN0pdZIgTGT kY1POxQhlpQLJAWcA4XVWH3tzKKsAHGN6MMkQJAsnPsimqdefHY3IT7ecRP4KINBB8BN5Ky8 L1HbW2fAj15nrHsaO3rcbGGqcLCb1k7AXqRNHYJmPKPW9FMQ9mg395ugMl0NtsmMAQ2cUfRs xuLb1+059i0X9BePFcMl84Thtu2S4dppyHD+NPVZgKQJApREJocg3yIKh5Mu3k9WHlDgkV5v BGfoB/zS1IHgurONibWqDpB9GHg1i5Z8zuoa36zQLC25IHQGT1k8DvEVhElKHRf50jCqaA9s YTJT8IVTRqIgXJWwzRpv8aIk2WgAN6X6wI47l2TKl6ZDpFoChBql1XYP1kaXzRQWeoDeY9HQ 2EAynMD2oA7NN/dD6JRw+nUPHXc2kfiwhc7NjheZscv7zyIkET5AqceiVjWi5BNkonLDg4k4 6OCGpggw7hwBoBFPM5iDZa0aE07aRYpqVDQV8jnvAF4JU22TQWNomadAAKOHBbspJfoVQfI9 1jiQrQLJ19hDZlKBZKnvRtj69/AMvTdWQPRzYlhHIFpZeYORy2gzYO4pp/Q6ZhvaBvGKDxlb qd4GsD9oQJQj1KzonSDVonGqZNUyOSJqqkAC2E2WTEyqqkdjQvD0JVgxV5UzZkYf5P+zZNtU cQPOAedweHjkK1nr5QKpdxVFEtkkBN2gx3Yg4BBOAD0BACDnGO0dyHGtuL/MGnL7XzfKl3A4 /kPyn/rrDvbGp9cXfHD8cHPH9/j4E58Rfvz7AKeVdHw4fvnVHR9vb7/7KR6/fyV7cJq0dK3t tMwEJ4jwDFJZn8p13K0fUPim1NHGbS6yP41Q6qm1yP9gKjTksgBGsnkr9AGhSJMKu5/CMm7K yH6Th/7jSlFKVATJBsUpNSm1FFkmpF7k5vfdnN9KXSsS8yXrhGr0Iu2x3YGkOElKtXRSzhz7 bOTMyu4BbK/p0HpxP4U+Kc2vm/jM2Dd1W8gnmqWGscv7zyJkhNJBZhhYysJmUSIk+ULWcnwE p1iag8krMOUK+4If3ODlGRQK44n2SIlGPmkivgHgmSXYjNIhKk471s5gDbdY7R6vgmc5djpB yZMUoceiyHGklN7hV9QGMFzj/LYGDnZhP6Vw6Au6KZfOKHC+hlT4PokLwCRqbDhFhdaB7UkT OikTixEI405GaerkyI1MzimnOFPdA82c4xx4TlaxfdRUxCinrIIQz8yzHHW1bkIsTrFHw4Ui FDQ1f0FQ9gGBZiBj1oRCoVTqC4i6fGRAoHhK8bwCnAMHcH+ZNo+3r7f3H97dfsQ/MMvxxwHe 8Bp+IjL5jf6EXvz5+HJzD06MCs+Q1EHCsPHNAMYiI6bjMxnGk2EYDxqFroC+7M9KvYV90LwP TVr0GxwNVnGiTPIXvPQ/yqttOW7ciH6B/gGPoy3NmLgR5KPt3a3SJi5voqlSquw8UBxKYpZD ToYcKcp/5n9yugGQnIvt5I0Acek+6D59ekZgijXUK1TsyF4/PPOOrbWBJcEmOA9FjtT8q7hC 7HgeQP2g9IAqy8gV6jnsuN2F3dpvlnyVRvAr5qUVwSOhZrK4hZhXgIZ5OYJDTusdMbkVS47K 6YqUjudr/hSN+v4OKZn5Eay8B6RCZA8zSIh5OjZimSoS/HGPnu+It8QdlEDYkaHQaTX5ARiC I6khyjrbML/iw/rq3a/k+RoC1bA7RMfQRcheqpRQUc7ibdenVeoPAgEaQKxLXLt+vfqyuG2H an8N9ZEuul38Kh7qph7erv++/g3rlsA+Q+Svf75a3Pb9oeqv1/+4+mV9JaE0iJK1owaOOhrU VOrTdErNEaJ9XIFuSWbzCb+loWjUOdE103iOQwyxt2dARRkTflNXlppp7JfPD5jsiEeMdowr oh0nW/gY4DrBafC2oCnAKaFWwbE5wbn4VA3FphgKQmD909XibleV9WNdFkPdtRGXeDhEO2rV zB7JQnd2fYIEYqFxsuXcHketTMbBN7fnr1VTx9f6nkmOxO3MIrRPK+Lb0aKwYDToeEMzYw0l QwblljTOGKpa458+C9XJBbRC4FkSF0cu3FXlYQ/7xUXDcxC4mxmeo2Skc8PDgtHw4w3nQIJA WZ9nx2Z8AZR9dwgJUFYc+9+EU6YoQlbN7AIBKYokHIqKRXE7rklyR8A0Z7sCqqnnYivCJ4o8 iIDgzNyPiGDml4bAVnkuT/1ak0tuwZ5li6Lti5Jc+YGD2uIeOXdQk4zRM+THNSP2p7u+E8YG PIcabUNW9X3xVLdPl2PAx6LB/ZmdYtdYqlxjqBrgZPNp6FdfeH/riIJktCDzQfj5/e/RdQs9 gYPH+6AvUMXNdOG4Il55suXCpcRWNud6M2PnxaeiLZ6qbdUOlz2XqLVQHXOKJTmYH3HsuGYk 2ZNdbA9Vgsz6ek+VAEqF3wpNJdIBaYHjqKZT1Y4ygdaiLKPxZImRZpY0SNiRoQ0D2R/vWFEA G+Xvkf6iFBZbE7eFAnu07Vu2Kag/hDHbdnrTZdvCjv/XtrDtom3Q5Su0PREn/EIaKkWd7v+E 06UdH+hpV14vBaIFl8qMNAXYiXqWy8U7g2pA8f6yuBuKdlMEutr04kO3qVGYKanf/Zp7cWBX XuAJUtvcW0luWHL0CSnUFa7w6lF6/ahIPy5xS4J2Brcs1s+VoEgc5Yak5pDMhhbghZC7WMif kMKsKD7DqHwlF09FW/+bo1k8dnsx4Kz3m5eiLX28d4/ibtgfyuHA69Wi2ojbFiu3fg+7Yqko XvAgy6iSsAfeDBvN0EhDNmMGUE4AfV18fn93e/f1WhyDRFpUzz2KJ6ksnFT3ohBtNyxh3HIX eLR7rIcbUZN6atngohElErfbD/VhC2+LIXjg7MyD+MykZlAKs9EDpCuJMrwwQUrXbvb1S9Uz bpvqpWq6HeF2Q7e8eKHmFk8V4LwR8FQUm27HwAHYavlw6OsWrCr6CQYHGFaC3nQydCbxklwR CFSKwCtswi4qw82hhCnbLpxTifvw8SD6av9S09+TmwiCFpa9iQ4u7EXcOwuLoulA+a/18Hy2 GVDHAkXwWBOCqw9i4Rpcly1uZp56FPqjtIgXVY84b+jxXAzn7vDQ1CUsLwcEJm2jAC12uybQ 77IPZDy3IUnUqJsX22L/RzX0K8oOsK5Doi2hVyUYfgwk9a0csi4z84hzMeQMSgW7GeDt9s1G 3NebOd4fpyD7urjXH88CmoSrTY+SVI7Z4cLLvha9KONrFgNyD9h8Bh4PeCp0rEYMnWiqYsOA XcpFNG82U5o/UpOOgYxu1wdyome+pKe+5OQL7qjxLI+HphG7bkB410ijh7cY8KQIym67xRPu QiZ3Q1d2DUfXwJOY2mLrpWQbTdQQYKnLJ7qIyZYTcXCOw4zqpWsOPjARElXbRzVYsZX1eafk xk6Jw3El8B4CdLGp+vqpJesJvbp9jH1VPzIeA38zIqsvcQQpwJyIwZst1US2eAq2myzdVI/1 eFlkvPK5HqpArnCA1g2c+WECP5/brumeUDU4/O95fsrnFdhY/Fa0h2L/hmYr8ceqGz7m3lN8 dQ1j0sXDd5lOmZWVSp6Dn2Yh2u8ihbyHMn2hVoDCsykObflcbW5Ef3joD9vo4d8+/Vn8Hh+C o2Haxw/3LwTShlbTq/UlHmvFBqaoovYoT30uX6pyzp5nKJtsjxIUeI3G38b4yM7jQ3w+Zz9k 793y9ix9IW4tqdLkhEjo9qkegeZ3VYvQ2hwQU28X48gqktrUgNiVdlTNYoqOhCNjselCEZ7Z Vz4Xe/YoFGck6y6MOON8EKijGhByhNfs4lfEoCjjL9SlXVMMVOz7m+8FT54H3j2LHRsSYAb1 QG/ev/VDte05Esby9RSXbDmKmqJ9OkB3h2rYhWWT7//xy5HI9Vhq+4qp6NCSK6ixgdaq6yTE /1kVtSbWrIAO8el4nHiumh1IGO/XbadZoBzIbyIcdxRQzcXqC9LcxcUvNYf/06HekNy6iVUs 8fZE9iF3kCnVBBR1hnQYV9LDbkd1BgfFDX0XmYv4gU+lHuVIpaJzJQn9KkhQShKUMnHUGyl0 fqjiCqSWAikEZ8oSWynkJYRQhg6KO5y7q3e/bB+qDQz7uSsPLBbfffqoxYefP1795eqfuLAW kM9mhV3SGmrNFAlDnOqoa7h06P1PooX/kjhHaeibJX9i6T39QGXkf1B99Dsh+b6ME3HRXCpr 9oxtoJYS4ZrAN+h9NJaIVLqBlP4VJB56gNQno8mpgUPTiMqEGQlj8YfGoEcao7cTvEPSGOzv UlHyGSkoiGaMy3iFMn4FGhcub85pHmuoY9rhVpoyn2YIJY2e0Voepzrlscsd35mgEaIdAExm PGO4ZGIcVuTG+BMyyX7Qnf4OlSueSSHF2Qrjx47uJiuT8N9kwQ8DeUAz1hle4a1QwcpjrErg 50FPPOiGQaddaeotk5oRxT5leCalh8Q4cwFRFErGL/V45fgfLJEeH5t7WxPChRCmlfAltX6H tSOiJvcIKsUrEjudyfikHj8V8Myst8m6NPz345x9J0kS8FQRT6s9GibzcZBI49HSHi0d8NW4 2Xth1fQm7GemA/H78RypCc+jIKZ3yny5QNh5OLVzR8eY1BtC7ZF/Rjs7lg3R3jkXTI/jVPqx sd4Qm8SQ1pmchRsZEcaJ5LF0fofO4x3jDKRc4x8x848I+/2EzPV8wuFxcr8HnviZTMVzQ9Dq bLzHP7w9uncKhfFQNvF8AgBqFWbS3CMmg3eMHI2tESeQfzvOZYjiHCb7h1HJ9J4TD0juYXls vbvZmHEqgBYfZhwnxyekY0zJ1Oe9DTGVmBDHrEkBqc7HcQTIjjPN0UxuTmHn3WNsUzaIU1eP A5VSJwnP6oDv1s84n66Z8hegAARKnGbmuxo6E5ejSpG4IsIntCXpNQpR9Aq5YzbhGeVnCIH5 CozfrqRCwXO0AmFu6C6oGhvoxFm+HUtylR/NKNyejceEGROvdjyDAsKkMe5CtdRMy5dmktyf Q4+KuwwoG+HhZzSdgxlLj4mx4ZswJpQUEYffEfJRoQhJP6MolDB2FNOG9JjmViRJMh5LH1nE jBgbhGTO/y3lrwH5cxFDaaKHNgg0ULO/gbjfABg4QkOTGB5LcgcmpXQBqqHL8/+yX+06ch1H 9Av2HyYmQLLfj1QkExEMBAcMBCXiLmDJXAoSJej3fR51Z2cWNhzYieABg2XV3O6u56lTOoCa IR5C08gJMdKnxd4s5uwL0rAP3R9C0zlgIScWPWwoLHZEdzXbtNZxYq8pqyvqj5GD/znsZgTj UYiJanIYukcv1mHlVrVAI7OQDE4/nMhEa4aeUAC5LQFK4dTL0uxkz7dOFBEaits27XxELlUX 5Ej54gBiT3hnNqflGX4RKLqyVXKX2cwC5brtRl7Obitqe/jZ5Cg1PSJhDfpo5aiqxtsaU1fO mn3WXMk5n65O5OOdpABa89k5UGVtFQI1FZBTlOkR7yAWaV5p0Oe1yrqGpg5N1HTb6iYyVSI3 T/ktatq4vIe0N+crDWLUx2XH5SF2d6m5Bo1/iS3vAWHf4u/PVACt/zyBJGKMfjh9/0M63V+Q yBsC3RDohkA3BPqvEOjrFWNCDEnWGgoYHj1K43yQd7ObGlaiIp9TtpyUH8QgFp7qZQ2aUug5 YlIdySQKh7UuIGhoWaMmqdCW2VlllTdZISyoJJ2BEtnUEZRRhYhO8oGRXCTcGCW74eOB43e0 kbY0yNUQYG7KByzXUuNEjbITGYScjSF7WOTyxffXPp4o/KWR5hZ9oU2mcaWs8jp1R2WmFl63 4Wxpg2GcZiCo3gDsi/tz1fTu01DX/qLJTWDudmSnVkPkPzvwKccumVZAealBbmuOIjbgPks5 R5KM74Yftu2jNHuOwIZxsvHGjtUjyXlKnjUfZZCscU44xXxiyFhAQKDPipg3gZsQS290jKaw giQf8lIDYmuNFQv+GbmbIkZc7ZIH8agSEf37CuhHh2WD4nRf8cwyapZ++UjSGYfH4N+qH+3O E9Gb4WZHEM0J/zU6olsec0QoAgK6/ID9zZERoLAap59Yex7FlOx5VwulJ8+LR5pbCODSa8y0 Xe26zGW9aowWD79nGeWihBGElm7azDqgjxMcMXmJIY27f3vAJ+8+vLl7/e7xx4f7+4f7t798 +uPx4cvvp9cf3rTTN2/f3H139+tdPv10iqtOhBskjAHAPZkVz3sKkJP5WEgHNsLHu48vTl+A Onng9VIXv+V/8elH/kAaRAWAhT9zXvkLKo6PQI5g+vXiW7YLBjjYgTSPnomIRhqKggF67nKl oZnISsaUA1oYjivHx9M3Gb3Rr07BYQ2ueMrfFMLehYYAyNdRGN5mCypbcTp/A3uAOlcapIHE 5+LUMGRffHPt6GevvRGQK/4I3vhv+eP/b7i+PtWMMAPnYeHKMfCyDPPgNkKmyuP13PCLZC3T GMPw5CiEXPoKJBvNJ2ryiRYnKkkbsY96yN1ECRCx2enQDBEI/C0+MQUuuHuHXGN6iKXrg+Wp OiyPYrlnX9hGHKjDN5TtgVS2bUBSQx72u604USISi7bwBvoPeWafqCwOyANyjDSiTubjRjoy cIitxOT393XM+H4131iaR57wDXLOlqf2GE6fHnESVaJmeO7s0SxXT5U8XZ5rHrlQeVIjPwnX EmMKrXhhxNxC/hV5Ym/1UJXVYATiCiiiuI902yemTUrDB8TMMydI91QalslKPYVqsybHnGp0 P3Fi+ITCCDmZFUvDKl9mX7yBjCkt82hOOnUBOm8fk451A0WvHmuiJWl63FUypaYWXbOEF2W6 aTV8ERhuSRAVUIZxt+jpIxW+EhNTvA6VxqcS9y5nmy9RHP2op0MzTZEmjecFzTSP7IvyPha1 NY1H6lFuapwNkMv0ppZZsjS579g31vIJtRHkUS0vjmCubmxZyNxW/UbVG0s7rrfUxsaARijG YZsc6zlsxcyRi5VjXOfiO1oyvSSzpywoIZ/1hWkedZ+L07V7dNY+0jfOjXKRTTbl8cGORnF6 t4oSsRfi4sV+cI4RftVi+jX3ktznDnZpeeeDsKleUXWuSpxoRtZaA5JISiAzPkHxhut09ACp 5RvmPBhtlsw2j4bvvmMHQIgcUp5mldxE0RgpnzGIrUHN8BfiM2odh3pWyyUdRLxFu5VldlWq 76y6gewyux37UWVqcFSXIoV8sywhj26ypdiyn8txosSj2nchJ+EcnxqqMhI5QUgrUZfTKLXo Lsuyr8C9EANXV3w+urGaGwDFFeOETus2/9zHcf9KHkGa15SHwX0PWySkBoVaJVxIJKskbryK LmV/oSTL6e6xOA6nx/YwzsUrUCoe4LW6yFuLIRvTIIt3UCPzVeUSp7oXzgloIYdR9dWI34NH C0chJ49ZLSp8YB3QvriTQtOGQS0vP+i9EX+XTS7tALlRfWdOBnN9QBKRT8/IAEnymSzdeMKN J9x4wo0n3HjCjSfceMKNJ1zxhK936aR/r/rpH+QMzZwBoDrcfXju8UnBhHSBSMM82q7bgUL/ /PzQZ3CQp7vfX/CR/8XduAf3Dt1/YXerTjYjiJZAuaERXm5NiN8eYNHTqQuL/sOpv929+/Dm 7vW7xx8f7u8f7t/+8umPx4cvv59ef3jTT9+8fXP33d2vuPin052KDdHei+XeJ5rl9JJjtfGe UoDZ+HkB3Bs9//ji9AUxygMuod3wpv6LTz/yh1esdyhQRPw5cWa8PBTnj+DNq/U8DqUbbjfw a4r0nTUgLCziQhKIgtigBaRdBRSPqLnxTBaEF9KKLA3nbCFTQf8sxIUsowCwe5ac3D/Q8MMF 5zWJMDOIGZDrZAmiQzm5QsaBjPnDljx/MY3PvCGzT6av3+KDGaXL7qABLvDOQzRvR8EfDphJ IRmTB+Di7O58tpVCoCY6ZAfJJ6yB68PY4RsYrH7xBub3sAu0Al/uEYBFMsEb5it14XAhb5at +lM+VpVIzcSKiAHkLrciSiEzrETvJw3jOrpPtJKVCMHT5mTUgWDxfJS2QO4cqZA7YQaJTc1G JQ+tQuBZ8kIxhbwI25AT3UCxCP7hd4viAOCsokitVE5P5dWc9GcF+Onu76qPdl2TZ8WiPRRz 3LFcYTX7jbZmVFghdkMzeTvkxGKGXYnogNAseU7rPGeyeMbu3hUg1uEPBvMCORFHIa8YTMmc gClWnySvAAwF5/k5P5aZ0S2a/PQFq9dFM0WjkZdp2fwbJTA5rxk7UjjIPduronlzyE91eWhK 7GHHDfBfE+t4gt6OaK0ho9iEbj7RKXYH/57dsGzH/UZ8AXkP35lIjhg6jn7IxfsWNJONvslH hr7wncF6iQdkhbtoi3T+KlkCO5C7zFEARS37rECwxL64wrf3wMpv8ffnk0f7n6eq8fvh9P0P 6XT/hOc39Luh3w39buj310a/rxe0lhlvurvijccLDRLG9oA8LBYuPRAr/wItDDZQqCugqAWv tGqYAths9jTkNAxGs8q/Vlw00DRWGzj52hdwBTlz53kCtJauII6yiokyTzZuXMs3lhwn8jRo Nu1o215BVjYg17BhVO9oAIxmkJzc3iDXgNlN/6r2A7qZY6mzApHr8OKzbqjF0F+4fEGeAqnY 9vBm4c0I5XJt0Crugzu5qmB14QzYyRGin72e5U/aX0qrF1/gdRfXkDBTidQdn69mMN/EMq4/ YaIKXHK5LL4LTWdL8E5+yeKrPtG7b9gw2Scq9wmWI/dCJqtZLns4ObNIbjuH27ttt11RXNp2 PRP9KafAuHLOzdQTQNzkyNYVAOdUZQaYjd7zkRu1CIqX8YE8u9Ens8Ev5LF2nLAGKxRTohti AKXmNwQNE39bGFWZZsK/zIaR8nMiMtXpjvExD7eX+ppV6my3ejGAjrp/GlEMfv4n+1WyHMdx RL9g/qGPA0WArn25SqYjLJph2UAEDwwdwNGQggyCNMDF/Hu/XKqnerqGlK/WXMjJRL+qyleZ +bJK9wX1abXpomGnKCt6EXNUG/VKOKhRkxk4SXGIJMXIvRO2EWqpfCWIaiyXt8uicawEVO5F baffi4OEKFLaY81anXKZeI8Yu05PDSAnZtLKAEENoEpnD8QtbKO9P1rJ0hjCbAsRQk37gpqp 3FYIWihJbG+CNgBuQ7QrKRPs6PRUxEhnZz3VwROz7CErkDh3W0ADtbjaIZBU1NmpNmlQQ9Jx egdRDVbV0AL3URKVUwd2DaJYNOsRVZ7nIs9Do9xnceIJVdovXyRsCQsa3hSsBL2glGQaC6Ty XYevIU/HHR+z8GG8PavBWQ3OanBWg7Ma/GHVoH8bIPn5kSd91OHV66ZLVCteYQ/7hW58/cur w5oxywvloDCzRxUGti8HhYFpcugUJqIEc6cwsH3oFCbiyWkWCgOPi53CRHDiO4WJSFm3UBh4 squLL0LpFAa2rQuFibg72ylM1JdYUxjYJi4UJiKtS6cwkZpwpzARCVh6hVHHQWEIkTqFoRV9 pzCwa10oDE4RUqcwdOrUKQzFqWqvCkPclNB9gVxtAoPfISwEBp5YOoEhplMnMGwvBKbzsMDQ Cr4TGNiuLgQGHhM6gcEJE59QBQa2swuBQZTpoC+wnO/0BSwVlQ8330wInb7A5gVVX3APJS30 BZ7kOn2BHVglVV86W/Vl9qi+8AqdvtAe3CVnfeFDdPpCl207faEE872+UAaGTl8oZzvxaEl/ kBe6zth/QY2rk5dIPX4hL1Rq8SAvkYLp5CUmyZmDvMCj8sHyQrVtO3mBbZ3r5GV2zPJC1e87 eaE9aycvdCS7kBc6djioC6IqrlMXSrCyUJeZmfYFEix16hI1LQ7qAg+3oKYulIKpU5fOVnXp PKwu8wqiLvMWs7rMh1B1oUPGTl2oLtNCXRC3qZ26RGKsUxcwZ91CXei+UqcusKvp1IVuIy7U BZ5gOnXpujury1G3X7w1zkpwVoKzEpyV4KwEf0gl6N4ZKUk3RnbQEwtKkCru0s8e3HY26GRp 9pCd1Da032xnXCIdqDnQNWOOukTS5l6oqLFJ1TbriDDaNM0mlkhYK9TZc8ee0Ho5MQi7eFUg esnBTtzbsbTTJVgmqDGSdiHUXKUxU0El3CHdSKXOI3vivov0LEvdLlHXlZ4U6P+EJDWtBckW uNUq903yQDa3AdgFd/NlQ7uwCiBjDOkL7RokpcDVJ/7AV82ozH9PST4wFC1sJooyLFkNK2pG JZM4bj5t1WRGmDVLNtBZdnzHuUivjhxXYrIpPXCGL7KkKpjlG0+khrJGot5BdpIkRaf4JB8k OVYmErFC9UkagpfLsRQuatG4rIeY6zU6Diwa7QjRsx1slCSKXAjETJS0ykw/1mLJoHFAwuhT dzHgnNP6nNb/L2n9uDGTeUKLTGb6V9e6oWN0r5SOiYf4RJOA0+FVbrbowBwCmyHJrOsiK0ey T1LOs4cowswYwuwh20dN8HIwKw3Bu02zpUTuDjaVkJ/m1VqJtf3m2DgZk3osrxCawX+Lslos VWydbGjCFnQWh6OpCqZPcpyQPdtR7oIUVL5PUQa+6GTF7GXI4Gm2T+Ogl2WSJICdJOutZDF/ HuS5wXXR1i8yHyQr4TimnqZUmrHI9FnEHBn4ST7wMjibIEE7HdZtlT2MjvfFWK3OxJWB6ZXS l2pLnws+Sy32eUF9sUugZ12TPCfQOYF+TwKhA+GlCTzyZ9GCvH9isqztQAsyyONXOXju2FPo hUh9uXBInuZUv/DgZWr1aWbY4yrULelM2xzOqsOzpwj3OCY1bfHYoPkZuOM7XIQJC08FXvIF 1OlxWD86D0lqD/IkjceePvI7KrKOo67KzhzNcT5unj7/YfMPakeHTLLM0nQ7bVB2GMkQYghA 0ASG2SdNlxZjSJ4e9hvnEnS4TAVKj6J4u3n93eb7682f/oIIp+vXyGzoO68sv2xFIeOZVafo aPDCYtfgn5ohXxNqGWcwNMKE6XqHc11/3rzcfv/x8fZ+//g4/fRwYdFJtu92ZF293+9uX9/u bj7cvrt/vPj5+sfN02tC07V7DQhbolf6CW/WJzy2oGVOlyXPEQT0IOwuB8oSA51gIpJ0EWcM JrAwBRpp6AHnqFteWow+iVaRsBNNNwRIaNoTMGhaDm0k4L1nquFYhWcrTDti+hKbYXkOl35Z ifnF1eUPv77jeP12/+6N/rp5/+uX6fm7X/Z3098/7R8+3e4/z4Hr0s/w60f8+g0RxOnzZM30 fHr5s5l+mW/3W/E4a4iVqEe3YOXqNCkguCwXyScW+QZPKIoEWRjSpKnwgmgo2/2r6Yqi3+2n xlKcWQrC0p/3j7uH2/eUHNPfbu7ffLx5s29crYg4GUNA6c4n+yoNBdjfs8Q3SMiQvALokIX/ iYC/3n/YP7y+2Z2O+uSRDTWlIIfRsCd7HHCo9P0oeY7Q34gYzSXTE+JExEfVH7T6n9/c40Lf 7u8/fPt2T56UugmdVI6g9+upcNBUl+FGG6lnDMhaLfL1eKOJ9N6zX2kHibrBIfKLS4fu7rY/ aRNgAsRpt0//s999pCRvX81sqP0a6aHfcvLk7f4C+bt91bxXF2YrufR4isHTwUdMZBAyDUpT xVBXwTBThEEX8RjDW5F7MI2D6AdWmnA6sYpQaCZMPNMl/WMmiA1eaHiOoaFgf38iYQ7qsX0O mm7e3N6/ubj+TaSBKpfLl0u40zvncsVfkp6xrM8ou2e0CpLudOqMNLNhdguRZjl74pJfbq/l Jh7kv5v7x5sd3+EsYiEqiwtZdg4annEwkTPXH1P1TA8QjYNk11PHDBh4fU3cm2vAyD085/YK ufVw++HLTKCNkzm8e/VMFpOQC0pdHZyJdqMmGzAEuFNHcg6zvvM4Eg35/gR123/u725vXt3e HU71byRQQv/DAQxt6bngLt2T4mV7WZlvzkaS+BffTffU0VIJk/MoxUv+iY9f0B9ADf8NUdGf 8eQp8gU59CNsivUDn++S3kjgmn7v3hJLUvg81jzjiSRBiGfGMj3jAu0aAnoHHjZve5/HI4Sf Tle8VKCcNVbXc1iQvq1mjVffEb4w3ik+NHwa4NMAj7mvxyfGy7NpiZ99R/jEeK/40vBlDS9r tGdwEHBVLCg5xorrCCvgqGCnaLcCuwE2T9KIBRsaNq3BaY0OdoFunPn11n6wN5c+5ELRLWq/ ZswPGMPIT2iZp52xig5rzsKAsyicVUV7RccVOA6weYGNDYtxf4UW3xKfmDWr8KzwZNdw9R3B mTbb8I22lAf4PMIzcVYSHT1N8dmv8epb4jMXivWKb9TlOsDXET4t8I2+MqCvjOjjOrdB4Y2+ OqCvjugr3GdsVHyjrw7oqyP6iuwvOQ9NYHxCKz1O29m3xFehLyveN3wd4OsInxb4qHgb13j1 LfCyu1aNy4p2do1W3xJthD3NfVcbPg/weYRn9jT3vFO4H5DnB+RRthpuv4IPDT8gzw/Io2zr 8UnxYUBeGJFnuXZcO39RfBzQF0f0OW47TnO/HT/mvIaL7wjOncdp7odGX/JrvPqWeC/0ae6H tn+qA3wd4eMC3+jLcY1X3xFe6NPaCY2+Ytd49S3xQejT3G+pXwb0lRF9QejT5I+Nvjqgr47o i3aBb/TVAX11RF/k4nFaPFHoyzyOL/Gz7wjPxaPJE4vCrV3D1beEJ659r8nfdqd+vILnEZwb j9fcT07xVEXHePUt8XkBjw1eB/A6gjN5XqNPWfF+QJ4fkZeFPK2dVBX/X7bLIEl6nIjCJ/jv 0GsiprGVkjLzBCxYESw4AEGwgghgwfVxZb40LenNbGZe11e2v3opWZ3Y68yepT10X+/iib7O 9FnqQ/dVwA/Z3znebOV9wUvfcII7w2N0BKOjpW+Ok0e28fnzofta+vQ+eWQLL1fMjqD7VvpU Ca+Mj6UHv56VPSP2jNiTy3/iZc+IPSP2JN/PO0bHyp4Te07syR32Ospvac/iNWTl32zlW9jr KL/fxev+tvtmGz8WXsDfcvLINj71wZ+P4p3wTniJ4ekYHlfwnxVx55FtfAxPz/bX3ctxPnqz lY6Vo2f15WqFE3nC5PWV7+A7kdeZvB4rTzfws/jnZzj4zFZ+pDwHb+DHOHlkGx/y0r1UdeZ9 0shWOuEbdMn7QAeuDO8LX/JUTh7Zxoe80cCXPCXylMnL08oQ8CXPiDxj8jQmZ2TzpR7fiT1n 9jQGZ0B+e3miz5k+k4VPfR776Mq/2cbHwjMwONj0n8864Z3wHgvPQPebgb/HySPb+NSH7gvw dp84sg33BX95JbyefL9SH0ZHBngh+oTo61fogz3Rwok9IfZ6Hlcmyi8OvhN7ndjrdwzPRPn7 DX4837vzyDbeFr70DSW8Er7F8EwMTy99U04e2cbH4jExPL38TSe8Ez5+vYny99Kn48SRbXjq w883Sp8Rfcb0iS186TOiz5i+nvowPKP0OdHnTF9PfWj/KH3PUBy4n3RM3kT1R8jT2AcW+I02 ONThzucNeBf3RhusP2EpWE/4PCT1GTOjmJk5QTc56Haul33GUysaP61oP2mibMZyo+i7At7f Md9ohVUWuIHup7NOnGk6w6hoL3qed45s5S21YVa0tA3y5IM9uqU4dF1L3DDCG+NTHX70wmc/ cWQrnseTFy95ep08so2PUVGMipU+JfqU6MuHx6xYyTMiz4i8ccW01MXr4Y24M+JuXLHOGCpf k+rPG+OOI1vxuy14uru/r2vn32zjw51hZrwXPwk/CZ+XR+99Ar/biSPb8JSH5rsXb4Q3xqe9 bH6/bvDt0PdmK59nk5cX8EL0CdMnUR6b4EfxRJ8wfRKTYwpewXfirzN/uUuagS9/3fb19s02 Xn/yd/n75DuPbOVHrDzm4MvfvE4e2caHv8JL35wEnwwPfX6DL33aTh7Zys/Q5w186VOiT5m+ qT/5VvqM6DOmT0OfC/jS50SfM315QPEOvvz5s3MefGYbH+PjqH9Lf+37ajv/ZitvMT6O+jcv 3ghvjJ8/+TyfPp+9+8kjW/n8+TE90oG368SRbXisPo72yyz+0PdmG5/6UF9sfC2OWjsvRN+8 PvpQ3rp5Ie6EuJufk8kLN9C97+8rb7bSn+LdV+F18XG8Ib7ZhvfgUfxe5sYk/GS8Bo/i9zI3 28kjW/l2/+RH4UZwY/gIHHMzyp4Se8rsNQ8eczNKnxF9xvSJBI/ej9JnRJ8xfZL6UPxR+pzo c6av3z/5urw/+/CBZ7bhqQ9zM1OffF99599s41Mf5mZ28J8fZOeRrfwIfSjv1MInwSfDY3Je 3sG3dvLIVn7B9S78sPdmGx6zc2N2VMALsSfM3udM+PDovg7wndjrzJ7GqnOj/Fr6+txPWW+2 8XPhS984TmlvtvJ5+5gdK33DCG4MT32YHSt9s588so3P66P7Vvr0OnlkK++pD+W30qdEnzJ9 Phe+9BnRZ0yfx/DcGB4vf0b8GfH3eaaHR/u89DnR50SfXrH0NLTfU19/Dhdt499s5e9Yelpd X4ufhJ+MHz/4uvrn/3ca2UaHvJazM65WvBHeCN9SXgffwbd+8sg2Pu0N8BO8EHvC7Enam+Ct eGJPmD0ZP/kbeCf6OtMnMTtNgZe+zxQffGYr32N2moEvfaOfPLKNj9lpDr70zevkka38WPCy NyfBJ8Nj6UF56uG1nTSyjQ55cgN/eSJPmbwZ8gTNbyXPiDxj8nLfkrr9kudEnjN5uuAlz/fX 1Yo2ONVhcHLVGd9H7Sva4Lw0pkZa0XbSdtIWMyPovAzQ975dVrTR0RlB5UVBnzdO7tt8Yb3Y XVlFK+2x1giGpd+g5by0kGt7OkPXexmX05mczuwKZ/i1einrz9ftNLIND2kdVe8lrTvhnfG+ 8CVujJNHtvJ3qOsYlVHq5n3yyDY+5HV0/a3rVMIr4WNSO/SN0qdEnzJ9rS986VOiT5m+FitN x7yM0mdEnzF9kvePiZmlz++zPMg2Plaajt7P0udKeCV8Pj6KP1Pf/L6O7r7Zhq+8Fe+Ed8an PoyOAr/HiSNb8RH2IF8b8HbIe7MND3kD3dde/CHvzTY+Zmeg+zrBC7EnzN6UhS978iwoB5/Z xsfsDMxO4X2cOLIV11h5BrpvpW/cJ49s42PpGdBvpW8o4ZXxqQ/dt9I35eSRrbzJwtfzT6Jv Mn2W+jA7DlyJPmX6PPWh+176jOgzps9TH7rvpc9037PebON94Uufy8kjW3i/Ynhgz8ueH28Z b7bhMTwzh+fzCvjh9fsaO/9mKx/2ZgMuwD+nzR1HtuGx8kwBP4o/7L3ZxtvCK/h22HuzlW9p r4P34g99b7bxqS+HZ96lT4g+Yfqi+3MCL339WQx3HNmGpz4FX/q6El4Zbwtf+j7vfDuPbOV7 /vwGvvQNJ7wzPoZnZvlnK31znDyyjY/hwe230qdEnzJ9I/Qryt9KnxJ9yvQNXfjSZ0SfMX0z 9Cmmp5U+8/1N+802PvQp2i+lz8fJI9v41If2S65d9n0db/pvtvIqCz+LV8Ir49MfpkcM/OfU s/PIVj7aq5ieuvv7sPdmGx3Do2hPb+DbYe/NNj4vj/L3ur4Qe8LseVv4sicPdfCZbXysPYrh 6WWvy8kj+8FH83DpUaQT0nfyT8+///rVnqn/Hl/Pn59t7Uueze3pd3tq/vXvv/1qzz/f8uwK z1kltuZ//PrL777++ev6eqj+1eQ5Yf4W//l8+C+fPzzvpfG3z2n2+XP8tr9VgA89F32+P8r2 9dv1rKctHv3rr/94+DuGMB/qj5/vexbV/379+v0f/nx//f0/v3T25zX1c9V+tWcttM/jvZmY fesDpNg7NqXruvF9UYzns36dfGY7b8E38L34SfhJ+NiU/s9HMeZ4TOx8ZTs/gxfwVryduJ20 BJwznSv688Hs78JGtLMJD8ANdDvgRlgNdoLtxc4TnicdO9H/6XIm56WFXDv2oetS0PXUchoT Yix2oevKaWr5DvV8tJ/OOnE20pmDFtDjgAdhdWFHsXlGXenINj42IBS95dvT89HPRr7jme14 aLuLL21TCa+MD3F3Fr3dJU7l5DPbeI1BuQV8qVMnvDN+LnzpM6LPmL6Y87sDL31O9DnTFxvQ hYNve2fNiT5n+iyvn51v+fY057OU7rWtbOM99f2P7TJIlly5regKeg9vrIj/TCYyE8AKNPDI 4cFfgMPhkRQha6DtiwVcdDwib/ek+1adInl4kWQqeCneCe+M3y9+gf9spjqf2ZvPo2Nq8uXp +ea4TzqzRl9pD93Pl6fPd5Xwyviwh+7JAC5EnhB5n7ZesfwmP4sn8oTI+7TtJ7/BTyJvMnl3 zM6o8zfwi+hbTN+IZWeg+3X6S/XEI+t4rDwD3Z+lb8vJZ9Z4SX3o/qzjbye8M369+NKn6+Qz 63zqw+zM0mf3yWfW+Jn60P2qvhF9xvTN1Ifyr9LnRJ8zfet+8aXPiT5n+lYMz8DwrNSn39fq T9vKOh/Dg/IsA37fJ55Zw3fMvqD8dfTPenzgyvBYeATd3wP8Z4o6n1nj9YWvwp3gzvCQJ7j6 reCFyBMmT1MeZmc7+EnsTWbP0h66r3fxRN9k+iz1ofsq4Jf0d47KGu8vvPQtJ7gzPEZHMDpa +vY6+cw6n7cP3dfSp/fJZ/bm5YrZEXTfSp8q4ZXxsfTg7lnZM2LPiD25/Cde9ozYM2JP8v18 YnSs7Dmx58Se3GFvovyW9ixeQ958ZY0fYW+i/H4Xr/1tt7LOrxcv4G85+cw6n/rgz1fxTngn vMTwTAyPK/jPitj5zDofwzOz/XX2cuyPKmt0rBwzqy/XKJzIEyZvvvkJfhJ5k8mbsfJMA7+L f27DwUfW+JXyHLyBX+vkM+t8yEv3UtXZ90ln1uiEb9AlbyvBleHzxZc8lZPPrPMhbw3wJU+J PGXycreyBHzJMyLPmDyNyVnZfKnLd2LPmT2NwVmQP37zRJ8zfSYvPvV5PEfffGWdj4VnYXDw 0H++64R3wnssPAvdHwb+XiefWedTH7ovwMd94pl13F/4b14Jryc/r9SH0ZEFXog+IfrmFfpg T7RwYk+IvZnblY3yi4OfxN4k9uYdw7NR/nmDX8/vdj6zztuLL31LCa+EHzE8G8MzS9+Wk8+s 87F4bAzPLH/bCe+Ej7u3Uf5Z+nSdeGYdT324fav0GdFnTJ/Yiy99RvQZ0zdTH4ZnlT4n+pzp m6kP7V+l7xmKA/eTjsnbqP4KeRrPgRdcUYdDHc5834C7uIo6rD9hKVhP+NwkzR0zo5iZvUEP Oehxrpdzx1UrGr+taD9pomzHcqPouwLu75gVNVjlBQ/Q83Q2iTNNZxgVnUXv88wza7ylNsyK lrZFrnyxS7cUh65riVtGeGN8qsNNL3zPE8+s4bk9+Y2XPL1OPrPOx6goRsVKnxJ9SvTlxWNW rOQZkWdE3rpiWurgdfFG3Blxt65YZwyVr0n1542x45k1/B4vPN3d39fV+co6H+4MM+Oz+E34 Tfg8PHrvG/g9Tjyzjqc8NN+9eCO8MT7tZfPndYMfh77KGp97k9+8gBeiT5g+ifLYBr+KJ/qE 6ZOYHFPwCn4Sf5P5y6ekGfjyN62vt5V1Xn/yd/n75J3PrPErVh5z8OVvXyefWefDX+Glb2+C b4aHPr/Blz4dJ59Z43fo8wG+9CnRp0zf1p/8KH1G9BnTp6HPBXzpc6LPmb7coPgEX/78+cbB R9b5GB9H/Uf6G9/X6HxljbcYH0f9hxdvhDfG75987k+f797z5DNrfN5+TI9M4OM68cw6HquP o/2yiz/0Vdb51If64sE3YqvVeSH69vXRh/LWyQtxJ8Td/uxMfsMD9Jz9faWyRn+Kd1+F18HX 8YZYWcdn8Cj+LHNrE34zXoNH8WeZ2+PkM2v8uH/yq3AjuDF8BY65WWVPiT1l9oYHj7lZpc+I PmP6RIJH71fpM6LPmD5JfSj+Kn1O9DnTN++ffB3en+fwgUfW8dSHudmpT76v2fnKOp/6MDd7 gv/ckM5n1vgV+lDerYVvgm+Gx+T85h38GCefWeNfuN6FH/Yq63jMzo3ZUQEvxJ4we5894cOj +7rAT2JvMnsaq86N8mvpm7vvsirr/H7xpW8du7TKGp+nj9mx0reM4Mbw1IfZsdK358ln1vk8 PrpvpU+vk8+s8Z76UH4rfUr0KdPn+8WXPiP6jOnzGJ4bw+Plz4g/I/4+1/TwaJ+XPif6nOjT K5aegfZ76pvP5mI0vrLG37H0jDq+Fr8Jvxm/fvB19M//O51Zp0PeyNlZ1yjeCG+EHylvgp/g xzz5zDqf9hb4DV6IPWH2JO1t8FY8sSfMnqyf/A18En2T6ZOYnaHAS99nig8+ssbPmJ1h4Evf miefWedjdoaDL337OvnMGr9eeNnbm+Cb4bH0oDx18TpOOrNOhzy5gf/miTxl8nbIEzR/lDwj 8ozJy+eW1OmXPCfynMnTF17yvL+uIupwqsPg5Kqzvo/aI+pwHhpTI6NoO2k7aYuZEXReFui7 Py4RdTo6I6i8KOjzxMl5m79YL7YrQ9Roj7VGMCzzBi3noYUc29MZuj7LuJzO5HRmVzjD3Zql bD4/1+nMOh7SJqo+S9p0wjvj/cWXuLVOPrPG36FuYlRWqdv3yWfW+ZA30fXfdd1KeCV8TOqE vlX6lOhTpm/MF1/6lOhTpm/ESjMxL6v0GdFnTJ/k+WNidunz+yxPZp2PlWai97v0uRJeCZ+X j+Lv1Le/r6O7lXX8zVvxTnhnfOrD6Cjwe514Zg1fYQ/ydQAfh7zKOh7yFrqvs/hDXmWdj9lZ 6L5u8ELsCbO35cWXPXkWlIOPrPMxOwuzU/hcJ55ZwzVWnoXuW+lb98ln1vlYehb0W+lbSnhl fOpD9630bTn5zBpv8uLr+jfRt5k+S32YHQeuRJ8yfZ760H0vfUb0GdPnqQ/d99Jn2p9ZlXXe X3zpczn5zN68XzE8sOdlz4+3jMo6HsOzc3g+r4AfXr+v1fnKGh/29gAuwD+7zY5n1vFYebaA X8Uf9irrvL14BT8Oe5U1fqS9Cd6LP/RV1vnUl8Oz79InRJ8wfdH9vYGXvvkshh3PrOOpT8GX vqmEV8bbiy99n3e+zmfW+Jm338CXvuWEd8bH8Ows/x6lb6+Tz6zzMTw4/VH6lOhTpm+FfkX5 R+lTok+ZvqUvvvQZ0WdM3w59iukZpc+8v2lX1vnQp2i/lD5fJ59Z51Mf2i+5dtn3dbzpV9Z4 lRe/i1fCK+PTH6ZHDPxn19P5zBof7VVMT539fdirrNMxPIr2zAF+HPYq63weHuWfdXwh9oTZ 8/Hiy548Vg8+ss7H2qMYnln2ppx8Zj/5aB4OvYp0Qnon/+v5+49f45n67/U1P5OtX/I83J5+ j6fmX///v7/G8+dbnqfCs1eJR/Pffv35l6+//7q+Hmp+DXl2mH/EP58v//n54Hkvjc8+u9nn 47i3f1SALz0HfX4/yvb1x/WspyMu/et//vbwdwxhXtR/fn7vOdt/ff36j7/+9/31f//8pfvf bNdRluM6CEXRGfWyhCRg/hN7Dlz8StL9bFbtTnKC7Hi8P1N/r/peht+vo/8+3v+z0d/rkyNs i5vS8zT8f7EY79/6c3vMDm/hO/wov4hfxMdN6X8fi7HmW+L03+zwK7zAW3m7ud1aAueZziv6 +4e5v5vN0WETT+AO3S/cidWwC3aUXTdet4470f+6msn90kJeO+5Dz6PQ9anlLiakWNyFnidP U8/fUO+fjrvZIM1mNnNogZ4XnsTqZmfZfEbddc52HzcgLHrPX0/vn/5u5CfH7OCRrZWvbEuJ V+YjXMtF763Cqdwes91rHJQm8JVOnXhnfm2+8hnJZyxfnPM2wCufk3zO8sUN6MGDb//OmpN8 zvJZvn7ufM9fT2u9l9Jzbb/Z7j3zKbyUd+Kd+bX5Cf97mDo9ZpvPV8epyR9P71/2dmvMdv1k Pex+/nj6/a0Sr8xHPeyedHAh8YTE+23rE5ff9KM8iSck3m/b/voFP0i8weK1ODu93r/BT5Jv snw9Ljsdu19vf6rePGcHjytPx+6Pyrfk9pjtXjIfdn/U6y8n3pmfm698Om+P2eEzH87OqHzW bo/Z7kfmw+7X6hvJZyzfyHxY/ln5nORzlm+2zVc+J/mc5ZtxeDoOz8x8+u+Z5932mx0+Dg+W Zxp4azfHbOcrzr5g+evVf9fjiyvjceER7P7q8L9TdHrMdq8bn8WdcGc84gk+/VJ4IfGExdOM h7OzHH6QeoPVs6yH3ddWnuQbLJ9lPuy+CvyU8zfHN9u9b7zyTSfcGY+jIzg6WvnWvD1mh8+v D7uvlU/b7THbvDxxdgS7b5VPlXhlPi49+Pas6hmpZ6SePP6XVz0j9YzUk/x9PnB0rOo5qeek nrSoN7D8lvUsfobs/pvtvke9geX3Vl7PX7vf7PBz8wL//tnlMTt85kM/n+WdeCde4vAMHB5X +N8V8fSYHT4Oz8jtr3cv1/PRN9t1XDlGrr48vTiJJyze2P2AHyTeYPFGXHmGwa/y79dw+Zzt fmY8hzf4OW+P2eEjXraXWp3Vbo3ZrhM36Iq3lHBlfGy+4qncHrPDR7zZ4SueknjK4uXTyhT4 imcknrF4Gidn5uZLfXwn9ZzV0zg4E/H750k+Z/lMNp/5PO6ju/9mh48Lz8TBwU3//Vsn3on3 uPBM7H43+DZvj9nhMx92X8B7uzlmB/eNf16J19uPJ/Ph6MiEF5JPSL7xRD7UEy1O6gmpN/Jx ZWH5xeEHqTdIvdHi8Cws/2jw8/1/T4/Z4W3zlW8q8Up8j8OzcHhG5Vtye8wOHxePhcMzqt9y 4p34+PYWln9UPp03x+zgmQ9f36x8RvIZyye2+cpnJJ+xfCPz4fDMyuckn7N8I/Nh+2fle//g 4n7rOHkLqz8jnsZ9YMPf6MCRDu98NeAz3Dc6sP7FUlhvfD8kjRVnRnFm1oLucul+Xy/Hik+t 2Phlpf3WJNmKy41i3xX4/I35jXassuEOPe5mgzTTbIajoqP0ut85Zru3zIazopVtkk8+2Ue3 DIdd1wo3jXhjPtPhSy++xs0x23k+nny84ulze8wOH0dFcVSs8inJpyRffnicFat4RuIZiTef OC314vXhjbQz0m4+cZ0xrHydVH9/MZ4cs523vvFs1/49z+m/2eGjneHM+Ci/iF/E58tj732B t35zzA6e8bD57uWNeGM+6+Xmj6fB9yvfN9t9Ppt8XuCF5BOWT2J5bMHP8iSfsHwSJ8cUXuEH 6TdYv7xLmsFXv2Hn9fabHV7/+lb9fvPTY7b7GVcec/jqt57bY3b46Fe88q1F+GI88nmDr3za b4/Z7lfk8w5f+ZTkU5Zv6V/fK5+RfMbyaeRzga98TvI5y5cPKD7gq5+/d87L5+zwcXwc69+z X//39NN/s91bHB/H+ncvb8Qb8+uvz+fT92/buD1mu8+vH6dHBnh/bo7ZwePq49h+WeWvfN/s 8JkP64sbX49HrdMLybeeXz4sb715Ie2EtFu/J5MPd+gxzt8r32zXv8VrT/F68Xn9QvxmBx/h sfijys1F/GJew2PxR5Vb/faY7b63v34WN8KN8Rkc52ZWPSX1lNXrHh7nZlY+I/mM5RMJj72f lc9IPmP5JPNh8Wflc5LPWb7R/vp6eX/vwxfP2cEzH87Nynzy7xmn/2aHz3w4N2vA/76Q02O2 +xn5sLxLiy/CF+Nxcj7v8L3fHrPdb1xb8aveNzt4nJ2Gs6MCL6SesHq/Z8LXY/d1wg9Sb7B6 GledhuXXyjfW+ZT1zQ6/Nl/55vWU9s12n28fZ8cq3zTCjfHMh7NjlW+N22N2+Hx97L5VPn1u j9nuPfNh+a3yKcmnLJ+vzVc+I/mM5fM4PA2Hx6ufkX5G+v0+0+uxfV75nORzkk+fuPR0bL9n vvE+XPTDf7Pdt7j09Hp9Lb+IX8zPP75e/ffvU2N26IjX8+zMp5c34o34nvEG/IDv4/aYHT7r TfgFL6SesHqS9Ra8lSf1hNWT+dc38EHyDZZP4ux0Ba98v1N8+ZztfsTZ6QZf+ea4PWaHj7PT Hb7yref2mO1+brzqrUX4YjwuPVie+vDab43ZoSOeNPDPk3jK4q2IJ9j8XvGMxDMWL+9bUm+/ 4jmJ5yyebrzi+flztUYHznQ4OHnVmf+uta/RgfOlcWqkl7Zb260tzoxg52VCt/N2WaNDx84I Vl4U+n7j5H2bb9bLnslqtGuPa43gsIwGLfdLC3ltz2bY9VHF5W4mdzN7ohm+rVHJxvvfnRqz g0e0gVUfFW048c68b77CzXl7zHbfIt3AUZmVbrXbY3b4iDew69+6LiVeiY+TOpBvVj4l+ZTl 62PzlU9JPmX5elxpBs7LrHxG8hnLJ/n+cWJW5fN2Lw9mh48rzcDer8rnSrwSnx8fi78y3/r3 XLv7zQ6+eyvvxDvzmQ9HR8HbvDlmO59RD/G1g/cr3jc7eMSb2H0d5a943+zwcXYmdl8XvJB6 wuot2XzVk/eCcvmcHT7OzsTZKT7mzTHbucaVZ2L3rfLNdnvMDh+Xnon8VvmmEq/MZz7svlW+ JbfHbPcmm6/Pv0i+xfJZ5sPZcXAl+ZTl88yH3ffKZySfsXye+bD7XvlMz3vWNzu8b77yudwe s837E4cH9bzq+fUr45sdPA7PysPz+wn48/rvmaf/ZruPequDC/jvafPkmB08rjxL4Gf5q943 O7xtXuH7Ve+b7b5nvQHv5a983+zwmS8Pz2qVT0g+Yfli99cCr3zjvRieHLODZz6Fr3xDiVfm bfOV7/eb7/SY7X7k12/wlW868c58HJ6Vy7965Vvz9pgdPg4P3n6vfEryKcs3I7/+x3YZJFmO 20D0BH2HWjuiyyIBEuQJZuGVw4s5gMPh1TjC9sLXtwQkqktgzmxmsvVa0vsJUkT5e+ozos+Y vmEvPvUtom8xfdP1Gaanp76165f2V1Z412dov6S+PU4eWeFDH9ovsXatz+v40v/K3rzJi5/J G+GN8eEP0yML/HPqqTyyN+/tNUxPPn077H1lhfbhMbRHO/h+2PvKCh+3R/k17y/EnjB7u7/4 tCe31YOPrPC+9hiGR9Oeyskj+8Z783DrkeQm5K7kX+9///2j31P/OT50ts/741nuze3ud3++ RP/zjx/9/udT7l3hPqv41vzHj9//9PGvH9fHTelHl/uE+dP/87749+cP7u9S/7PnNHv/sf+2 PzPARfdN7zHysn38vO71tPurf/z9j5tvPoTxUn95/r57Uf3fx48///a39vHP//6wqfezPXeV 9lz8PNKv7F7aP/XefEJs803puhr+Pi/Gfe2+Tj6yyi/nO3hNfhJ+Et43pV+8F2OO20TlM6v8 dF7Ar+TXia+TFodjpmNFvy+M/r5Yjyob8ADcQfcD7oQ1ZydYTXae8Dxp34l+0elMzlsLubfv Q9dloPOt5TQmxJjvQtcV09TjG+q+VE9nSpyNcLZBC+hxwIOw9mJHsnFGfdOeFd43IBS9x9fT femzkVc8soq7tpZ8aptGeGO8i2tR9N5SnMnJR1Z480FpAj7V2Sb8Zvx88alvEX2L6fM5bwo8 9W2ibzN9vgFdOPj2r1nbRN9m+lbcPzrf4+tpznsprbXNrPA79Bl4SX4TfjN+vvgB/jlMVT6y Nx93x9TEx9N9ZW8nHVmhr7CH7sfH03OtEd4Y7/bQPenAhcgTIu9p6+XLb/CaPJEnRN7Ttu/8 BK9EnjJ5zWen5/Mv8IPoG0xf92Wno/v5+MPsxD2ruK88Hd3X1Dfl5CMrvIQ+dF/z/nMTfjN+ vPjUZ+PkI6t86MPsaOpb7eQjK7yGPnQ/q7+IvsX0aehD+Ufq20TfZvpGe/GpbxN9m+kbPjwd wzNCn31eo+62mVXehwflGQt4ayceWcGnz76g/Hn3Zz0+cGO4LzyC7s8O/pmiykdWeHvhI/FN 8M1wlyd4+2nghcgTJs9CHmZnbvBK7Cmzt8Ieum8teaJPmb4V+tB9E/BD6jdHZoXfLzz1jU3w zXAfHcHoWOqb4+Qjq3z8fOi+pT5rJx/Zm5fLZ0fQ/ZX6zAhvjPelB7/eSnuL2FvEnlz7O572 FrG3iD2J73PF6Ky0t4m9TexJc3uK8q+wt/wz5M1nVvju9hTl3y15q1+7mVV+vHgBfx8xDz6y yoc++Nsj+U34TXjx4VEMzzbwz4pY+cgq78Oj0f58ejnOR5kV2lcOjerL1RMn8oTJ0zev4JXI UyZPfeXRBX4mf/8MB+9Z4UfI2+AX+DFOPrLKu7xwL1md2U46skIH3ECnvGkEN4bri095Jicf WeVd3ujgU54RecbkxWllCPiUt4i8xeSZT86I5ku+/ib2NrNnPjgD8vsXT/Rtpm/Jiw992/fR N59Z5X3hGRgcbPr3tZvwm/DbF56B7vcFvo2Tj6zyoQ/dF+C9nXhkFd8v/Is3wtvJ6xX6MDoy wAvRJ0SfXq4P9sQSJ/aE2NM4rkyUXzZ4JfaU2NPmwzNRfm3gx/33Vj6yyq8Xn/qGEd4I3314 JoZHU9+Uk4+s8r54TAyPpr+5Cb8J77/eRPk19dk48cgqHvrw843Ut4i+xfTJevGpbxF9i+nT 0IfhGalvE32b6dPQh/aP1HcPxYHvk/bJm6j+cHnm+8ALzqjCrg5PPhvgKi6jCtt3WBK2Ez4P STp9ZgwzMyfoLgfdz/VSp7+1ofFzJb1PmiibvtwY+m6A6zdmRgU2ecEdtJ7OlDizcIZRMU16 nk8eWeFXaMOsWGob5M0He/UV4tB1S3FjEX4xPtThR0986olHVvA4nnzhKc+uk4+s8j4qhlFZ qc+IPiP64uUxKyvlLSJvEXnj8mnJm+fLL+JuEXfj8nVmofI5qfv+Yqx4ZAVv/YWHu/Z5XZXP rPLubmFmtiY/CT8JH7dH7/cE3vqJR1bxkIfm7538IvxifNiL5uvVwPdDX2aFj7PJFy/ghegT pk+8PGuCH8kTfcL0iU/OMvAGXok/Zf5il1wLfPrTVdfbzCpv3/mW/p688pEVfvjKszb49Dev k4+s8u4v8dQ3J8Enw13fbuBTn/WTj6zw0/XtDj71GdFnTN+073xPfYvoW0yfub4t4FPfJvo2 0xcHlK3g09++d86D96zyPj4b9e/hr39evfKZFX75+GzUv+/kF+EX4+d3Ps6n97VNTz6ywsfP j+kRBd6vE4+s4r76bLRfZvKHvswqH/pQX2x83Y9alReib16PPpQ3H16IOyHu5nMy+YI7aNX6 vZJZoZ/itSvxvPk4vhAzq7g6j+JrmhuT8JPx5jyKr2lu9pOPrPC9fedH4ovgi+HDcczNSHtG 7Bmz17fzmJuR+hbRt5g+EefR+5H6FtG3mD4JfSj+SH2b6NtMn7bvfN5+3/vwgXtW8dCHuZmh Tz4vrXxmlQ99mJup4J8fpPKRFX64PpR3WuKT4JPhPjlf/Abf+8lHVvgXbi3xw15mFffZaZgd E/BC7Amz95wJ72vQfRvgldhTZs981Wkov6U+nfWUlVnl54tPfeM4pWVW+Hh8zM5KfWMRfDE8 9GF2VuqbevKRVT7uj+6v1GfXyUdW+B36UP6V+ozoM6Zvzxef+hbRt5i+7cPTMDw7/S3ibxF/ zzvd16B9O/Vtom8TfXb50tPR/h369D5c9MJnVvjmS0/P+1vyk/CT8eMbn3d//r/SkVXa5fWY nXH15BfhF+F7yFPwCr7ryUdW+bA3wE/wQuwJsydhb4JfyRN7wuzJ+M434Er0KdMnPjvdgKe+ Z4oP3rPCq89OX+BT39CTj6zyPjt9g0998zr5yAo/Xnjam5Pgk+G+9KA8+fLWTzqySrs8acC/ eCLPmLzp8gTN7ylvEXmLyYt9S/LxU94m8jaTZy885e36uYqowqEOgxOrzvg8ao+ownFrTI30 pNdJr5NePjOCzssA3ep2iajS3hlB5cVAnw9OnnvtF7uTrcoQFXr7WiMYFm2g5by1kHvvcIau axqX05mcztblzvBraSrT+6+rdGQVd2mKqmtK0034zfj94lPcGCcfWeGbq1OMykh1s518ZJV3 eYquf9V1GuGN8D6pCn0j9RnRZ0xf1xef+ozoM6av+0qjmJeR+hbRt5g+iefHxMzUt9tZnsgq 7yuNovcz9W0jvBE+Xh/Fn6Fvfl5HdzOr+JtfyW/Cb8aHPoyOAW/jxCMr+HB7kG8deD/kZVZx lzfQfdPkD3mZVd5nZ6D7NsELsSfM3pQXn/bkXlAO3rPK++yM/7NdBkmS4zYUPUHdodaOmLJI kAR4gll45fBiDuBweDWOsL3w9S0BH5oEge5N9698JenlB0VidhwfM+OWHTjryjPRfXF9s2Xe spPXpWdCv7i+yQXPFW/60H1xfYsyb9nBCwXen38V+lalT0wfZmcD50IfV/q26UP3t+uTQp9U +rbpQ/e36xM+31menfwOvOvblHnLIr8vHR7Y225vp12GZyeuw7NseJ4t4MPzzzVP3rODV3ur Ayfgz2nzxC07cV15FoGfzid7np28BJ7B92TPs4PvZm+A384nfZ6dvOmz4VnN9VGhjyp92v21 gLu+cS+GJ27ZiZs+Bu/6Bhc8V7wE3vU9e76Tt+zgh339At71zV3wu+J1eJaVf3XXt2bmLTt5 HR7cfnd9XOjjSt9U/Yzyd9fHhT6u9E0OvOuTQp9U+pbqY0xPd32yz522Zyev+hjtJ9e3Z+Yt O3nTh/aTrV3yc6WdvmcHzxT45TwXPFe8+cP0kIB/Tj0nb9nBa3sZ0+N335I9z05ah4fRntHB 92TPs5O3y6P8w69PhT2q7O0eeLdHt9XEa3byuvYwhme4vUGZt+yT1+bh0tPJXZD7JP96//33 V7+n/md+jzGer4Hul9vd7/7sRP/zj69+//mh+61wn1X01fz7129/+v7X1/V9U+O7033C/EX/ eX/4t+cH975Uf/acZu8f63f7iwf40H3Re4y0bN+/XPd62vXRv//++9dzx/pvfai/PL/vXlT/ 9/3151//1r7/+d8vXuO+t+eqfZEu+79/ZvO6t5bw2vSddF0Nv057cX90XxlHFnFRvAMfjq8C XxnXN9IfuLZizVvDib9ZxJfiBFwcl0xLgklZG2dbzO/PWXUDalFEjZ1gO+Ce2J5RVnQBHY6u zK4E6xvoD9h1Ub4w5Svr6+e6GLA/MWVZlGXpu+e6bIa67ZzuT46sa2Rd03RtwAR4JnZmlAM6 HbVzaYQtC7i+c1Dubhum+5PPu/ukkUVajTXH3djiAucCV2fNyt2bO2PKOLKAs85GI+BujXeB 7wJfAXdzUpiTwpzOdRug3dwuzO3CnL5tLpxy+ztduzC3C3NiV7eed9sprXUvm2dX3yzg28wx cHJ8F/gu8BXwCfw5Np04sk/cro1BsV3S/cHeMowswJeJQ99tk/R8lAucC1zFoXHUQVPhjbK3 p6KXrrOGD8cLb5S9PR37xBfwUXgbhbem49L95gX4LMzNwlzXRaaj737vkznTlkVa15mOvg83 tyjjyAJOZg59H371tQt8F/gMuJvjmXFkETdzGJfh5qRlHFnAh5lD373uUpiTwtwwcyj8dHO7 MLcLc7MF3M3twtwuzE2dl455mWaOf655vk/fLOI6L+jMFNCtZRpZoJfOOqHwfu1n5U00F7Qu M4S+rw78GZwTRxZwDvR0ehf0Lmj1RnjyxcCp8EaFNzZvGJe1gY9C3CjEiYlD37k5XpgbhTkx c+g7E/BJ547izQK+A+3m5i7oXdA6LYRpYTe3ZsaRRdy+N/Sd3Ry3jCP7xOnScSH0Xdwcc4Fz getCg69NXJwU4iSLo2t/0i5OCnGSxZFtuAemRVzcLsTtLI6aihsovJg40U1GxN8s4F3FDRR+ N8f53MG+WcRnwAl4o4wji7iZg7o9Hd8FvjNOOi8D87IZ+LP6nTiyiOu8DGu83zqlo86bBVgX imF1p6s7XXijwtuI+AA+Cm+j8DZ0nRkCfDl+fwEJtyzg07xt4AJ8zowji7h6M+vkjVktw8gC bGwD7N4WFzQX9Ai4e2PKOLKIq7fZgbs3Lrxx4c2OHpOAuzcpvEnhjXVYprWd/NF3IW4X4lhn ZUJ7f/HC3C7MCQXczG19VUb8zSKuy8zErOClfn90F/jO+NZlZqLvXYC3mXFkETdz6DuB7i3T yCK9A/3iXOCc8HGZOUwLTeBUmKNsblxqDuKInS7EURY37OyxUHjawEchbmRxo+m8LBR+NODz /rUnjiziEnA3N7nAOeNd52VhXoabW5RxZBHXtWJhXoarW7vAd8b1a1so/HBzPDONLNJmDt/b dHNSmJPCHEnA3ZwU5qQwN8wc5mW6uV2Y24W5YebQ+Onm7kFI9E6wztpC3ad6Y13vA/tGkVVr uO3VwJ7O3iiy/MmSs5zZdN4ZS8eEMSZrAe6U4J6WxrH0iRktX+LwznC2tXRxYXScwZ47xzcK LFNgO+CRdY2si00XpoOHwyvfNrKAixnDeLAbm8VTz+KxxZyh3+zOphS4FLhZw5ft9BqZRhZo O2u8tHvjK+PIIq7TwZgOcXNcmONszh4c4yHuTQpvkr3NSwfEL+0PLoU2ydrmpauKoOY+mvve CJ40skC3HmjT1n6u68TfLOKqTTAmezi+Cnxl3C6Oru8FuvVMI4u0eUPb93ZcClwK3MRZ28fV gPdk7s0CbgeNFyfgVJijwhxpZ2QBn44X5qgwRzoswsAZ+CjUjUKdvQhFgLu6IefK+mYR50+8 ubonP3FkAZ+6zsgG7urWlXFkEVd1Tru5tQp6FbSa2w24m+OecWQBX2pud+BujgtzXJhb/Il3 NyeFOSnMsZrbBNzN7cLcLszZaWMP4K5u3y/HhFsWcZ2Yjcp3U9d/rn7ibxZw0YnZqHzfjkuB S4GvT9wOmfdH28g4soDb146BoQG6X5lGFmldazYaT8vxZO7NIm7m0Fm83Loemk6csrl1PebQ WL9zKrRR1raeY8bLdsBjnJuRNwvwU7d2Oe2Xnmnj92aRHoqj7MOlzVXgq8BZcZR9uLTVM44s 4L194tNpKWgp6Kk0RmW6OC7EcSGub8UxKtPNSWFOCnNEiqPr081JYU4Kc2TmUPbp5nZhbhfm RvvE/eL7ftMm2rJImzmMyjJz9HONE3+ziJs5jMoawJ+v4sSRBXyqOTR2sdOroFdB67C8+Abe e8aRBTzQ3JxO4t4s0jouDePCBJwKcVSIe452N46+8wQ+CnGjEMe6xjQUnt3cWOd56c0ivgLu 5mY6br1ZwO3eMS7i5qYUtBS0mcO4iJtbI+PIIm5XR9/FzfGVcWQB32YOhRc3x4U5LsztFXA3 J4U5KcxtnZeGedmuTgp1ktU9z3Pj6Nx2c7swt7M5vnSh6Wj8NnPjPir0A3+zgDddaLpfnR1f Bb4KfH7gfu3n/yeMLMLqrdu4zKs7LgUuGe/mbQAfwPvIOLKIm7gJfAGnQhwV4sjELeDieCGO CnE0P/EGehTmRmGOdFw6g3Zzz9gm3LKADx2XLsDd3BwZRxZxHZe+gbu5dWUcWcBnoF3cWgW9 CloXGnTGH5x7hpFFWL1RA/3ihTcuvC31Rmh7d29SeJPCm72cyO/dve3C2y68caDd2z73oB5F 1qxhVmyNmT+p6h5F1i6MQaHu8HnO9SjAomNC6Pn/6S6fHb9yIgo/Qb9DL5OR0lz/LdcWCSGB WEBamgVi0YRM1MwkMEkQ4u2xq0790q5yFKmTnL7fLfu4jq9dGuDkv4gm7bC0SkGbFwIcRx0H PXhD2VDvlkkbzLKzFOSjJsAlFi6xMqtd6O9qXpdoVwl2jUvswjJVc6vOt3kY2k6LXxXtXc2v ygecDzhvuHnWWsShbXgS1yrS0cy1niIObcfFt4r+vvVopwNOEZdoVjjXzDk6OEcH53LdcHOO Ds7Rwbks+0pFRJo5Nw7OjYNzRQePkHRzjlPsGWg7LvtKRa93c47pgFPEdepo9q7O9YcrNOxN 2+kdH4bzAecDrs4hLQQ6tUhD2+gmxsF2yqBz8O2m7bT41tDvVA0Pvt20HZe4NPQ7deDlYFw5 GNfLhptxZe4fAVdtxyUuDXExurZIQ9tokn2mod+HOddSxKHtuGw0DcYPc67RAacDrs6h34c5 10vEoW34KBtuc+8H5/rBuaHOIS4Mmg7O0cE5VufQ72zOjYNz4+Acq3PodzbnBvkP003bcd5w c45LxKG9xPmSvMA4NuM4nCFu2k5LXrrmZZ3sFk4PV/P4TdtwMa5n0AX0ujN6GtpOyz7TC/Bm eDDupu342HACnoNxN23DsxpXgbPhwbmbtuPqnOalJ3OuHJwrB+ek33sHbc7VufF5GtpOq3ME 3JyrdMDpgI8NN+fWWc7j0Da86rIP4OZc4wPOB1zy0rXhezbneos4tB2XvGDs2Zyjg3N0cK6J 8YSGz+YcHZyjg3ONNtycGwfnxsG5Ls4RApPNucH+7HzTdlycI3R8Mee4RRzajqtz6PiiG9V4 uMLJ/aZtOJUN74bTAacDrtYhMGUAXzcYj0PbcGlZQmBs6CkYd9N2WPJCaJqagedg3E3bcS2O hq9WvRyMKwfjOG+4GVemoQFXbcdlpyHkpZpxtUQc2jdc+g2Fm4F8ANmBf55/fvt4l9YXc+H3 +q/EPB+esakpzYvl3HwfP7oiP9/95vdv0/2HL3d/ffX4Oo0HevV5/TVePX368vTu6/O/Pt2/ /ff7d88/Pb97Wv/78vpvj3+4+93jummtBr/kp/wo821astzXq8xzzxxHfVgWJ36Y3fD5/V3O 1xza7CcMac7opx/u1mDy6jg5xv48n2rz0DWvrvqacb8+5HO685w+3zGBOdnrnh9mZteP6z7n vnaQuUWXtm6yM7pzqpd6oZPMa5Kv/vT+y5enD8+fPrx+/KfOQja4LM32wo2cieUjKiOoawQz ZvtMtOR8Is28sM4kDoznsNdRoOR56Ztv/c7A3r5/95/Pz1//dxuXnKqTG9SyZaa1LC9sSH2e srKOSGrNX/c8P6LleyMyqzLXNbX6nRH95f0vz09/f/7l5aDqYUylPNBVsVTttlTphUl0X+ps lZ6/N6Ta5t2G1+rNk08q31m9+Yp1s3x8t9bx69M/nr4+YWS/3uX5iZsvm1bP3fS+zRfPjOS5 r+swVoE1xhWZZcyPP9x/uls5mdPPq9PeyD/nsz+uX8zRyO9mi65fy472xgQ89OtdWdc17Zw3 88Xjkt32/t3HtXzy1dGs/XG9cI7kv/c32+YJaE50la3X3MbmZvfxhVZ4haNiT0ly9LquhPet DVGeHT3yonl+CJ/BV+GHrMfOm+Z4OXx94zv4JFeDnVfN8134An6AzynWV83xRXD9lMkBRp4c I9KieVrxBjyDL70EXjXPk/AdvLlXS6yvmuPlAPaNN/eafHt2XjXPyzZ7EXibfxscedE8z8Lr lp/l1rCe7T3WV83xTf1j8AU8RZxONG10Az3ktLfjqjleDmFo/SzXBnk0zv00dTmCXclos467 D45pnhfrkjZ+Tmrd/C5UH1zTHE8SnFTAF/B6vdp51TzfN74Zzz44pjlecp8qcAI+9+SAq+Zx 2XdSA8/gS43lVfO81tfOz9nsq8knxzTHs9pH4M0+Pf44ng/J5b7xZl/rsb5qO6/VkZts7q0T padVc/Sl7qHzs7lHyfeuaZ4X99B7JRvOsbxqDk8SnIzeLxX8iGs/4tKvXntJd9DrOuhx1Twv yck2etnyk75x42+a47NsOhmdXw3nHnGOwclymFz/VzyDX3dBz6vm+KLmofOr1c811lfN823j O/iSc+BV87zah+RUs68wRZ4Py1fVPnR+A16pBFw1j6t9aP1m9rU6Aq+a41vaeLOv51hfNc9L dDKi08y+zrG+ap6X6KB5mrlH/pN10xzeJfkFzW/VR+WAq+Zx2XYKer+be5xb4FVzPG24Lp7v 20PPkphWMOtOyskFzbHQPK+mITOdwacWakNz/FDX0POUwM8rQOBV87zahp6nAr5csb5qjucN b4aTj4xpHpfIFESGzL7afGRN87wuG3qezL6WY33Vdn5NafHo+WH29ctnxjTPy5aD1RvmXicf GdM8zi9xc49arK6aw/WMXhGZYe6N7DNjmufFvYqmH+YeXz6ypjk+i3sVzc/mHlOsr5rn28ar fXndNx1vmufVPvjHDXzy9kFydJHoVESHCfQ6LntcNc9LdKr2vo09Dx8c0xwt+0bVxi9XBl6a z61pHt/5Cr6WWF41z8u+Uwf4Dr5dPjimOb6peQx+GD98cE3zvJin3pcEurdYXTVHK5xAm3lU 4sKr5vG68WbeuHxsTfO8mNcyeDNvjFhfNcfrDaUV8GYeN58b0zwvuWna93pITUW+Ijtumscl Ng3mZ+PT5cub5vhRNr4aP3xwTPO8bDsNwcGnvjyETxYkR7NsOg2dnwfoUmJ11Tyv5qHzC/Aa PvameZw3/MaPOHrVdr5eah6CUxr41mN91Twv5sG7QsB78ckxzeF6Qelo/cLgKfncmuZ5iU5H 69dkvL/h3DTPj403+0b30THN8Vmi0xGdavZx8dE1zfOydXREp6p/dd4YfX3THC+r19H6lQ0f PjqmeVztw/K1BD51H13TPD82voBfVxfPq+b4qvYhPK2BL8mHxzTPq33o/mb2HcqfqkvyOlq/ mXm1x+KqeVzMw9i7edeqT45pHqeXuFnXkw+uaQ7vkhxCcno3nmN51Twvsyd0fh/gqfvkmOZ5 2XgInW/Oj+qDa5rDqWx4Bs8pllfN8+oegkPVeI7BUc3xQ+1Dckjta9JLO2+a59U+dD4N8Kn6 +qZ5Xu3D8huek+9c0xyuF5Ubno1nH1zTPC/BIQRnVPBh24a00zp15GaYdbX63Jjm6EtyY6Vt 6uGKBcnDsuMMtD0bzLG2ag5PecPNt04+NaZ5XnwbSA2bb1R9ak1zvJZH17NZN3KcvGoeV+vQ 9WzTHxzXTTXPq3va9fVK4JlifdUcr3eUG6+bVpeD/86b5nlpndHBN/Ap+9SY5nlJzSDwZDz7 1JrmeP1ejgGewWfysTHN8/SSTwn8+vJ6XjXHN9l1BoM3/2qO9VXzvPhnuNnne18Vj4p1nMCa dY0ONB34LtZxBm/WhY8lJE/TSzqbcRQO2aY5nsQ4LuDNuHH53JrmeTWugjfnBsX6qnlegsNo /Gzucdi1THP8kOAwGj+rezSf8MExzfP9JY8b6v/ZLptcSXIbCJ/g3aHWBrqcEkX9nMALrwwv 5gCDgVdtYOyFr+9MMqguBR9mM/i6vseqSIYyc9zvQzw/GPl+8dEbaaEP7k0w1u3cWdh76fCr cm+Dse/xYXFxuxv2usS+s9Pv1xMfVje+fLu4NMFY7h9yDXtwZYOR/SxeuUKP4ap5uDPWm/lY /BbJpfcLILaH2Vj7FrmNi1sXjPxaPn0NPaf+zUXvVU1GZzSSm8qdCcb+Mh+d0YhuCXc2GPki 5mPn1aOb7+vi+cHY9/Cw9DrDn9yZYOS38unH+KJc2WCse3zoTK/wq+Txztj3+NCZ3uDLxVcv GPlq8WFx+wh98uYFY91as/0F/8mRfWfkH/oo0FW4N8FYt94U9GYI/H5xbYOxP83H5g8Nf+b5 zsgfduIULP+I+NL9AojtftgR3hTubTDy/cujOTPCS692QCx7dOjNjOjWzN/dGfs+HXs/Pbp1 vwbx+GDkL48Oiz8H/CI8Pxj7/fAX/Fq4OMHYt+IUFGeV8CcXN9jpj8uKg81bAl16Hu+MdTt2 KjZ/RXzPXY99Z+QXO3ZqzI/4tHBxg7GvH35M15mnO2PbwqveG70q/KeP7Dsjv3p4DX6DP4R7 G4x9T0/hd/iz5PnOyBdPr8Of4efx85vpop92bM5KD7nBWLfm1AHdwqv3gw9990BkN+tNnbAb 7KfJrDtj33pTF/wePh8bm5Gvhz6h157HO2Pdjh0sTvx0aTXZzti26KRAD/95UWHfGfndwhNs fY3w2srznbFv4Ul8/QhP+0y+M/LHoUd4vUnSnbHu4aE2An2UPN0Z6z4erZFIb6y8ec7In9Ya wd6Lwp99Jd8Z+7Y7gsWXAX+1PN8Z++vw7civzydIByJ72ZkjKE4rYS/N+vqmtsvTw+Y3gZ9W D+i0n9fN28aV82fs+5O1cW2CsW7RNSx+G/ClcmuDsb8OP6KTlec7I79YeA3F0QivjZy9M/Yt vIbN1wjv+SXsOyPfetsQn0Z8vebxzlhvhx/x9cXNCca+nTsNzdGIbwwubjDyxb8/mtMjvtm4 OcHYt3OnYfN7xLcqNycY+f7zsfo94lsrj3fG+un7uVXf1+DqBGPf40N1BvSS7fKNrJYdoh8V cq3Zdsa6RafY/NHgy8XNCca+NUex+aOHz8/4m5Hf5fAju6Z5vjP2rTmK5oSulYsTjPRh545i 82fE19OhGYx9O3gU8c+Ir4883xn7Hh82f0Z8Q7k5wcifcvjx+59Gsu+MfY8PzVnQ15XHOyN9 eXzY/BXxrcHNCca+x4fNXx6fvC/l4gZjfx1+h/88gLHv7PTXZeVBemtCrxeXJxjrVp7u5elX CZ/DByLbsusVskAWzcOdsW6nThf4Cr8JNycY+/PwB/zndYF9Z+RXz67BX+HPPN8Z+x6eV6eX CK8rVycY+bb5vUOP+IZwc4Ox7vEN+BHfvPJ4Z+zPw4/4nkYmf+bqrOaXf8KP+Jbm5XHGvlWn ++rftybz2/sSnh+MfasOvn4V6OXi5gQjXS3+gdWvGv7k5gZjfxz+gF81z3dGfrf4BtpTF3wR bk8w9i2+ge2XiK/x8gKx7eFh96WFPfN0Z+QPOfwO/3n0Yd8Z+54euiMT/vOX2HdGvu3uQHfi 24+Spztj26ozsDuthj+5OsHY9/FY/RbzZ+fqBiN/1cOP9Jbk+c7Yt5NnoDrN09P3Vbg6wT59 2zuM1jAnlzbYp/mP+78/v+rd+be+ZIzH1/W8qP64787y+s8fX7W222yvdl3veo/++fXbX17/ /rpet9ReVewcff73/uxvzz/c3bZ/e17p7n+2S/sjAD7055c8T7V2uV4/7j88L1u81+8/7z9Q rIL+o/7+/MH7m/zv9fXXv/2zvP7136/7xnDfKmwJ1J80fn4yeR4MIthit6TrKvh7thjPZ2fP vjPyp/kVvi3GHerlS/Dhb3b6dkv65Xf4xZfg8MHI7+YL/Am/ljwf7PTFdG+1n+jPJ30RTtsZ 2a4r9ApfuiQfjPxhfocf6TXJ88FO3+5Iv/xIT0tLPhj5av6AH79f58q+M/KX+d6t6k9T92d7 z/PBTl89vwVf4I+sj+/scdgKe/o716GDnb7dkLD61Z+mno/m3/7dT7e70VXCjuhW5+JsRr5F V3zxqz9LXes+Sbi4m53+sOIUgS/wS+H5m5HfD1/DX1yczU7fel8a9AG9du7tZqTbuVMU/oIv LY8HI9/n++bXGvG1ws3Z7PSXxzfgR3xtcXM3I78ffsSnPc8HO3yfjt7USO+5sbINdtqXp4fN r5HeKLy7m5Fv6WH3pIa+8niwUy9WnIrd92ep+7MzX/uZL/2za592h/08HrMORr41p8a3tyO/ +F88/F/s9KsdOhWb30JfPesrF+e5Wpc9ILhe4T8PxuyDnb54eNj8FvNry/PByNfD7/Cl1uSD ke/xoTkt4pM1sr++uXzN48PmK/Q2JOlgpHt8WH2N+LTN5IOdvpbDj/ie9yH2wci36lRURyO+ vvJ8MPKtOlgejfQG37J+sVPv1nzB8sf02VbSwUi3Y0ew+z3SW1WTD3b649D94vHefrOzw0IT /Oo+3Htfg8duRr6Hhs70Bb9omh3s9Kenhp0fBX6t3JnNyPfYsPND4MuV54Od/jp0DX1wZTYj 3SojqMyI+JpyZTcj3y8bdn5EfFrzfLDDf37S42PnZ8TXL+7MZuTbkYOrNyO9Prgym5G+PvVI b2ieDnbq/ozeUJkZ6c3KndmMfEuvYelnpPd8gn2w06+WXsPyr0hvjTwfjHw9fI+vvi/l8mxG vseH/JbCLxxfoNMWq05DddaA/Twusw5GvlWn+e7Hd6+Ti7PZadu50Xzx5arQRbm3m5F++g1+ kzwejHw7d9qE3+HrxcXZ7PTVw1vwZ/iTi7sZ+RaeZy8Fdtc8Hey0XS6wI7wh+cKDkd4OP8Kb F9d2M/ItPK3wI7w583yw0/c3FBX4Ed5S7s1m5Ftv1PfeH1KL2F3k1Dcj3WqjCL+GXy4ev9np Tzn8Fv7k4mxGvh07iuLgVi/vdMsKdNrLDh3F5tcJWyRPByPfw8PmC/SWbvabkb4Offszf3uw w2+Xh4fiiMLXnueDkW/hITsZ0LtwczY7dX9B6Vh9WfBH4d5uRr5Vp2P1Wwmf33B+MfLn4Ud8 s3N1Njv9atXpqE6L+JZwdTcj346Ojuo0z6/db4w8f7PTt6vXsfpthT65OpuR7vHh8mmBXzpX dzPy5+EL/OfVhX2w028eH8qjCl8Kl2cz8j0+bL9GfN+M/266Na9j9TXCaz0PByPdwsN375Gd Nm7OZqSPTz2i64WLu9mpd2vOQHN6D3/l8WDk268f2Pw+4Y/OzdmMfDt4BjY/kp+Ni7vZqQ85 9Ap/lTwejHxPD8UZLfyViwN2+vP/bJdNjuzIDYRP0HfotYFXVv4yeQIvvDK8mAMYhldjYOyF r2+JDGYXIwuzGXyvvmZViJGSPD40Rzy+YbuU/c3I9/iw+bLgl87zNyPf48PlD70W3tzNsu4v Kluv4SsXdzPyrTiC4qwO/zi2AyXbfzp6syK63rk3m2X7st7E6PjpxytWIJLtxFlYew1Zz9lg WS816ZHbFG7NZuRbbgut0chNOrd2s+z7eGy9RnSrnj8ejHSPDluv8fOXntcNjHxPz7e+XwW+ yjkfLPv+jrJ9P7SmPfhnfzPybXXWhD/gl8qt2Yx8a80S+BK+cms3y77fL9eCr/CrcG02I1/e /VLgP3de9sGyP+zUWQo/8uv1nA9GvuUXesTHuw9CqkWnBW5EN+SDLR/8adFphR/RHTfLQGTL u10jODkesjfLvlhw2uBHcOvi3m5GvgfX4UdyS875YORbcRSLXyM9PU6tzbK/rDiKxa+enryu ysXZjPz57uMNVe73IZ6/Wfb94qM3rYcu3JvNSLdzR7H3bcKvg3u7GfkeHxYXtzux1yX2wZI/ ryc+rG58+X5xaTYjeb7JNWzhym6W7WfxyhV6DB/jHA5Gejcfi98jueP9IhDZYjbWvkducnHr Nst+Le/+CP1M/cNFn3WYjM6MSG4N7sxm5Kv56MyI6LRxZzfLfmvmY+eHR7de18XzNyPfw8PS jxX+4s5slv1e3v0YXwZXdjPSPT50Zlb4tZ3jwcj3+NCZ2eG3i6/eZtkfFh8Wd0roizdvM9Kt NdtX+E+O7INlP+lSoI/GvdmMdOtNQW+kwZ8X13Yz8pf52HwZ4a9zPlj2xU6cguWXiO+4XwQi eyY7wluNe7tZ9v3Lozkrwjte7QKR7NGhNyui03V+dzDyfTr2fnl0er8G8fjNsq8eHRZ/CfzS eP5m5M/kK/xauDibkW/FKSiOlvAXF3ez5MtlxcHmaYPe5jkejHQ7dio2XyO+567HPlj2ix07 NeZHfKNwcTcjf7z5MX2sczoY2RZe9d6Mq8J/+sg+WParh9fhd/jSuLebke/pDfgT/irnfLDs N09vwl/hn+PXh+ltvNuxOXo85G5GujWnCnQLr94PPvTdN8p2t97UBbvDfprMOhj51puq8Gf4 fGz8sOyPpC/odZ7jwUi3YweLEz+99XrYYGRbdK1AD/95UWEfLPvTwmvY+hrhdT3ng5Fv4bX4 +hHemOvwwbIvSY/wZm+HDka6h4faNOhSzulgpPt4tKZFeqLn5oFlf1lrGva+Dfhr6uGDkW+7 07D4TeBrP+eDka/JtyO/lhe/3WyUbbUzp6E4vYSt49T1Q23V08Pm9wb/WL1AyX5eN++P4Mr5 M/b9ydq5NpuRbtF1LH4X+K1yazcjX5Mf0TU954Nlv1h4HcUZEV6XM3sw8i28js0fEd7zS9gH y771tiO+EfHNeo4HI70nP+Kbys3ZjHw7dzqaMyI+ES7uZtlv/v3RnBnxrc7N2Yx8O3c6Nn9G fFq5OZtl338+Vn9GfKrneDDSs+/nVn1dwtXZjHyPD9UR6OW0ywd5WHaIXirkWk8bjHSLbmDz pcNvFzdnM/KtOQObLzN8fsb/YdmfLfmRXR/nfDDyrTkDzQl9VC7OZlkXO3cGNn9FfPM4NDcj 3w6egfhXxDflnA9GvseHzV8RnwxuzmbZXy358fufRrIPRr7Hh+YodL3O8WBZV48Pm68Rnwo3 ZzPyPT5svnp87XUNLu5m5GvyJ/znAYx9sOTrZeVBerqg14vLsxnpVp7p5ZlXCZ/DD5Rty25W yA1yG+dwMNLt1JkN/oDfGzdnM/JX8gX+87rAPlj2q2fX4Wv465wPRr6H59WZJcKbg6uzWfZt 8+eEHvFJ4+ZuRrrHJ/AjvnWd48HIX8mP+J5GHv46q6PdL/+CH/HpOJcHjHyrzvTVv29N5vfX 1Xj+ZuRbdfD1a4NeLm7OZlkfFr9g9esIf3FzNyNfki/w6zjng2V/WnyC9lSF3xq3ZzPyLT7B 9reIr/PyBiLbw8Putx72OqeDZV9a8if859GHfTDyPT10py34z19iHyz7truC7sS3l3JOByPb qiPYnV7DX1ydzcj38Vj9HvPX5Opuln2tyY/0tJ3zwci3k0dQne7pjddVuDqbvfm2dxg9wlxc 2s3ezL/d//3xVe/Ov8Z3m/erxPge+ryo/rrvzu37P//8qrXfZv/u1/Wq9+jfv3770/e/v67v W+rftdk5+vzv/dnfnn+4u23/9rzS3f9sl/ZXAHzoj6/2PNXa5fr+df/hddniff/j9/sPFKug /6i/Pn/w/ib/+/7681/+Xr7/9d+v+8Zw3yqesVWfx9fn1/0gua/Q7Xmuxe5I11Xw52wvns+u eeiOSF+mV+i2Ftd6XbYCb/pGWbf70Y8+oRfbgKQDkT5Nb9AX9FqO6UBZb2Z7of0wfz5pO5Bl RyS7PWBX6G021oFIF9Mn9Aiut2M6UNbtTvSjR3CjdNaBSB+mC/T47WPpoTsiXU33RlV/hro/ O+cxHSjrw6NT6A26HLZ8kiXJA/Ky96xkA2Xd7kFY9+oPUM9Hj9/96Wfb/ecqIUdqOifbQKRb asWXvfrD06X30UFN3SjrYl0pDXqDXspkHYj0mfQRutZD1w9dsZ6XDltg1ylsA5FtpwzeeCu6 pq/Wj+FApPt03/ZaI7leFutAWVdPTqBHcl3boeuHqupMeiQ35jEdKOk+G1WpEdxzByUZKMuX B4dtrxGcFGUdiHQLDhvXath6DAfKdrGuVOy7PzHdn13HNV/nJX827F2ekJ9nYLKBSLey1Pjq drQX/4Pv+g/KerUjpmLbe9g6D1vPrjyX6bGx7f6wVPzRl3SgrDfPDdveY3rtx3Qg0kfSJ/RW K+tApHtyKEuP5JrKoeuH69Y9OWz7gN2lsQ1EtieHdR+R3OiLdaCsj5L0SO551yEdiHRrS0Vb RiQ39ZgORLq1BTszIjih+9IPyva0pjcsfMxeXdkGItsOmYZ9nxGc1sE6UNYl2X7VaFk/LKpY Xg2/eIprt0BDNyLd80JNpkIvgycHyvrywLDnUqDXOlkHIt0Tw55Lg96uYzpQ1jXZI2yRw5YP LVFrSUNLJJLro7IORLpfL+y5RHKjHtOBkv78nkfHnq9Ibl6NdSDS7YDBZVsR3JR12HK2pF36 bkdwMo7ZQNn2h+6OlqwIblVlHYh0C65j0VcE97yukQ6U9WrBdSy8RnAqx3Qg0kfSPblbGtSX jUj35BCdDuilsV0+BNesLR1tUYH8PAGTDUS6taX7vscXr6sc8jq70uyY6L7s7aqw25hsA5Gd 9Q69t2M4EOl2yvQFfUIfl7AOlPXhuSn0Ffqqh77Opj4/6NY99VYgz3HMBsqyuwVy5CbtuOBA ZPekR27rWqz/n+26yXEluYEAfIK+Q68NvHblD5PkCbzwyvBiDmAYXo2BsRe+vlXMYHUzUpjN IJ6+TilElqoQEY/epINnb2bH6Ygq348bMsCzNxdnjoh4rIrsWd93nm3Ej0XRT0Q6NkVQe0/e LmeOqHIbhc/kJge3N7ticZER7Ap+yscX/y5lUrHHJUYw7d2AxzjORkR894ZpH9CTf8yfiLQX /XA73jqiwue1e8OuDAGXdZyOiHj0htqGQq+hrBFVvZ82FsZ9OLi2zhwR8diWhXGfLbkdp+ub x5W5H3Afns3ZGswRVd5jWxa2ZWZzPow5IuJxpVjYlrmrm68HPzr9iSqPr21h3KenNj+0ndsy 9+V94XuTBt7WZI6IuBU+wO/nEOKIKp+7OeyLCPhowhwR8d0c