From w3c-dist-auth-request@w3.org Wed Sep 2 17:46:43 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA09718 for ; Wed, 2 Sep 1998 17:46:42 -0400 (EDT) From: w3c-dist-auth-request@w3.org Received: by www19.w3.org (8.9.0/8.9.0) id RAA26821 for webdav-archive@lists.ietf.org; Wed, 2 Sep 1998 17:46:17 -0400 (EDT) Date: Wed, 2 Sep 1998 17:46:17 -0400 (EDT) Message-Id: <199809022146.RAA26821@www19.w3.org> To: webdav-archive@ietf.org Subject: Re: subscribe webdav-archive@lists.ietf.org X-Loop: w3c-dist-auth@w3.org ******* Note from the listmaster: (listmaster@w3.org) ******* You have been added to the subscriber list of: w3c-dist-auth@w3.org with the following mail address: webdav-archive@lists.ietf.org This mailing list is now being governed by SmartLists. All administrative requests should be sent to the request address: w3c-dist-auth-request@w3.org Commands to the request address are processed automatically. The desired command should be sent in the Subject of a mail message to 'w3c-dist-auth-request@w3.org'. ******* About the W3C Mailing Lists ******* There are many mailing lists provided by the W3C for discussion and development on the World Wide Web. A full list of them is available at: http://www.w3.org/Mail/Lists.html NOTE that this list is not the place for any of the following: How do I configure [insert-favorite-software-here]? I'm new to the web -- what is it? I tried to ask [insert-company-here] customer support, but [I didn't get any response / they told me to RTFM] What does RTFM mean? Answers to the above are often found in the WWW FAQ maintained by Thomas Boutell. The FAQ is available from several sites. Use the mirror closest to you: Sunsite, eastern United States (North America): http://sunsite.unc.edu/boutell/faq/ Internex Online, Montreal, eastern Canada (North America): http://www.io.org/faq/www/index.html New Software Technologies Service, Austria (Europe): http://nswt.tuwien.ac.at:8000/htdocs/boutell/ Glocom, Japan (Asia): http://www1.glocom.ac.jp/mirror/www.boutell.com/faq/index.htm The FAQ also lists the names of all the USENET newsgroups that are available regarding the WWW (most under the comp.infosystems.www.* hierarchy). ******* Administrative Requests ******* The -request mail address should be used for all list administrative requests. It accepts the following commands (in the Subject of an e-mail message): subscribe -- Subscribe to the list. If you want to subscribe under a different address, use a Reply-To: address header in the message. unsubscribe -- Unsubscribe from the list. help -- Get information about the mailing list. archive help -- Get information about the list archive(s). In the event of an address change, it would probably be wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe from the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be "Re:", without the quotes of course); the -request server does not react to replies. ******* Archive Server ******* Every submission sent to this list is archived. Archives of public lists are available at URL: http://lists.w3.org/Archives/Public/ If you want to access this archive by e-mail, you have to send mail to the -request address with the word "archive" as the first word of your Subject:. To get you started, try sending a mail to the -request address with the following: Subject: archive help Rev. 18/Jul/97 -JK ================================================================= Welcome to the Internet Engineering Task Force (IETF) Working Group on World Wide Web Distributed Authoring and Versioning (WEBDAV). The purpose of this working group is to develop the HTTP extensions necessary to enable distributed web authoring tools to be broadly interoperable, while supporting user needs. If you are new to this working group, please examine the working group's home page, and read the group's charter. WEBDAV Working Group Home Page: WEBDAV Charter: If you are new to the IETF , please also read "Overview of the IETF," available at: Mailing list archives are available at: This mailing list is graciously provided by the World Wide Web Consortium . For your reference, your original subscription request is included below. > From webdav-archive@lists.ietf.org > From: request (w3c-dist-auth-request@w3.org) > Reply-To: webdav-archive@lists.ietf.org > To: w3c-dist-auth-request@w3.org > Subject: subscribe webdav-archive@lists.ietf.org > Comments: Action requested by ejw@ics.uci.edu From w3c-dist-auth-request@w3.org Wed Sep 2 19:16:29 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA11438 for ; Wed, 2 Sep 1998 19:16:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA27963; Wed, 2 Sep 1998 19:11:42 -0400 (EDT) Resent-Date: Wed, 2 Sep 1998 19:11:42 -0400 (EDT) Resent-Message-Id: <199809022311.TAA27963@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: Jeffrey Ricker , WEBDAV WG Date: Wed, 2 Sep 1998 16:08:55 -0700 Message-ID: <000401bdd6c6$a8da7640$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <199809011803.OAA16575@www10.w3.org> Subject: RE: WEBDAV servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2016 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jeffrey Ricker > Sent: Tuesday, September 01, 1998 10:58 AM > To: w3c-dist-auth@w3.org > Subject: WEBDAV servers > > > I'm brand new to this forum. One of the best ways to get up-to-speed on WebDAV is to read through the introductory materials on the WebDAV Web site, at: http://www.ics.uci.edu/pub/ietf/webdav/ In particular, there is a flyer there, at: http://www.ics.uci.edu/pub/ietf/webdav/intro/webdav_flyer.pdf Other introductory materials are available at: http://www.ics.uci.edu/pub/ietf/webdav/intro.html I'm also currently in-process of revising the ACM StandardView article which is an introduction to WebDAV, and these new revisions will appear soon in the ASIS Bulletin and IEEE Internet Computing. I'll post URLs once they're available. > Has anyone built a webdav server yet? Does anyone have one in the works? While I know of several commercial WebDAV servers which are under development, none have yet been publically announced. However, this seems like a good time to repeat my call for volunteers to work on an Apache (or perhaps some other code base) server to add WebDAV capability. If you're interested in working on this project, please send me an email. > When will the spec be submitted to the W3C? Has a date been set? As was pointed out by John Stracke, WebDAV is a working group of the Internet Engineering Task Force -- for an introduction, see . The IETF is a standards developing organization, like the World Wide Web Consortium, however, though these two organizations do cooperate on Web-related standards, they are distinct organizations, with different procedures and membership criteria. With respect to the Web, traditionally the IETF has worked on transport and identifier standards (e.g., HTTP, URI, WebDAV, IPP, etc.) while the W3C has worked on content standards (HTML, XML, CSS, PNG, etc.) Revision -08 of the WebDAV Distributed Authoring Protocol specification was submitted to the Internet Engineering Steering Group (IESG) for approval in April, 1998, and is currently pending review by our Application Area Advisor, Keith Moore. No date has yet been set for when this review will complete, or when the WebDAV specification will be approved. I am hopeful this will occur in September, but currently most variables which affect this process are out of my control. However, the specification has undergone significant community review, and appears to be a solid specification. Other current work items can be found on the WebDAV home page. - Jim From w3c-dist-auth-request@w3.org Wed Sep 2 19:16:45 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA11452 for ; Wed, 2 Sep 1998 19:16:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA27991; Wed, 2 Sep 1998 19:12:04 -0400 (EDT) Resent-Date: Wed, 2 Sep 1998 19:12:04 -0400 (EDT) Resent-Message-Id: <199809022312.TAA27991@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: martind@netfolder.com, WEBDAV WG MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu Date: Wed, 2 Sep 1998 16:08:58 -0700 Message-ID: <000501bdd6c6$aa6d4b40$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <000501bdd5d6$af438f80$7fcfa7d1@server.total.net> Subject: RE: A working prototype? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2017 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list There is a working WebDAV client called the WebDAV Explorer, which is available at: http://www.ics.uci.edu/~webdav/ - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Didier PH Martin > Sent: Tuesday, September 01, 1998 11:31 AM > To: WEDAV Working group > Subject: A working prototype? > > > Hi, > > Do any one has done a WebDav working prototype? > > > Didier PH Martin > mailto:martind@netfolder.com > From w3c-dist-auth-request@w3.org Wed Sep 2 20:56:14 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA12738 for ; Wed, 2 Sep 1998 20:56:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA29406; Wed, 2 Sep 1998 20:51:07 -0400 (EDT) Resent-Date: Wed, 2 Sep 1998 20:51:07 -0400 (EDT) Resent-Message-Id: <199809030051.UAA29406@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu Date: Wed, 2 Sep 1998 17:42:46 -0700 Message-ID: <001501bdd6d3$c4d85f80$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <001401bdd622$798f2ba0$15d0000d@copper-208.parc.xerox.com> Subject: RE: multiple parents Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2018 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > The concern is that protocol-07, as written, doesn't allow interoperable > implementation with a server that employs aliasing, and makes > some requirements on servers that wind up being (false) assumptions that > clients will make. I don't think there were any changes between -07 and -08 which affect this discussion, but just to make sure we're all talking about the same rev. of the spec., the latest revision of the WebDAV Distributed Authoring Protocol specification is -08. The Web page is a bit confusing, since it has a "click here for changes from -07" link, but doesn't state that the current rev is -08 quite as prominently -- I should change this. > I think that it's simple to fix the protocol by adding a "parent" > property, and removing the language that requires clients to munge > 'the' URL for a resource in order to find the parent. With this fix, > the 1-1 relationship between 'resource' and 'resource locator' wouldn't > be mandated for all implementations (although it would be allowed). Well, if performing string manipulations to discover a parent of a resource is a "munge", then it is no worse a munge than those perpetrated by relative URLs. Section 3 of RFC 2396 ("Uniform Resource Identifiers (URI): Generic Syntax") discusses hierarchical URI schemes, and explicitly notes that the slash character is used to separate hierarchical components. In Section 5 of this document, there is discussion of the meaning of ".." as it appears within a relative URI. So, there seems to be significant, Draft Standard precedent for performing string manipulations on a URI to find its parent. > With "case insensitivity", you might treat "http://host.dom/PATH/x" the > same as "http://host.dom/Path/x" and "http://host.dom/PaTh/x". True. Although seems to me that if there is some interoperability problem lurking here, HTTP/1.1 DELETE and PUT share it. How was this issue resolved during discussion of the semantics of these methods? How is it that the current definitions in HTTP/1.1 don't lead to interoperability problems? (Lack of widespread use?) > Let us suppose that I have a webdav that does 'case folding' and treats > http://host/AB to be equivalent to http://host/ab. These are two _different_ > URLs, but they are the 'same' resource. > > Jim, are you saying that these represent two different resources, which happen > to map to the same 'persistent chunk of state'? Yes. So, if I perform a DELETE on http://host/AB, then according to the HTTP/1.1 specification, the server won't return a 2xx unless it intends to either delete the resource or make it unavailable. At this point, it is server policy whether the operation on resource http://host/AB has side effects for other resources. In this example, it seems to make sense for the server to have a policy to remove http://host/ab when it removes http://host/AB. But, it might be just as meaningful to have a delete on http://host/AB have no effect on http://host/ab. Specifying server policy (i.e., standardizing one of Jim Davis' four cases) doesn't make sense for these multiple-mapping cases. > Notes that in the 1-many interpretation, it should be made clearer > that properties are associated with resources rather than with their > URLs (e.g., that a PROPPATCH on one URL associated with a resource > will affect the PROPFIND returned by the other URL). Note that PROPPATCH borrowed its language from the HTTP/1.1 specification, stating in section 7.2 that, "The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI." So, here at least it's clear that the properties are being set on the resource, not on the URI. But, it's left just an ambiguous as DELETE and PUT whether there is a many-to-1, or 1-to-1 relationship between URI and resource. > >Since it is impossible for a client to tell the difference between these two > >cases, it makes sense to me that there is a 1-to-1 correspondence between > >URI and resource. > > There is no way for a client to tell whether a server does case folding. This suggests it might be difficult to falsify the 1-to-1, URI to resource interpretation. - Jim From w3c-dist-auth-request@w3.org Wed Sep 2 21:02:13 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA12869 for ; Wed, 2 Sep 1998 21:02:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA29494; Wed, 2 Sep 1998 20:56:36 -0400 (EDT) Resent-Date: Wed, 2 Sep 1998 20:56:36 -0400 (EDT) Resent-Message-Id: <199809030056.UAA29494@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: WEBDAV WG Date: Wed, 2 Sep 1998 17:50:18 -0700 Message-ID: <001601bdd6d4$d22e4360$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Subject: FW: RFC 2413 on Dublin Core Metadata for Resource Discovery Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2019 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list FYI. Dublin Core is significant for WebDAV, and especially DASL, since it defines a common metadata set for bibliographic metadata. WebDAV servers which define Dublin Core metadata on their resources will be amenable to searches on that metadata using DASL searching. - Jim -----Original Message----- From: RFC Editor [mailto:rfc-ed@isi.edu] Sent: Wednesday, September 02, 1998 12:26 PM To: IETF-Announce: ; Cc: rfc-ed@isi.edu Subject: RFC 2413 on Dublin Core Metadata for Resource Discovery A new Request for Comments is now available in online RFC libraries. RFC 2413: Title: Dublin Core Metadata for Resource Discovery Author(s): S. Weibel, J. Kunze, C. Lagoze, M. Wolf Status: Informational Date: September 1998 Mailbox: weibel@oclc.org, jak@ckm.ucsf.edu, lagoze@cs.cornell.edu, misha.wolf@reuters.com Pages: 8 Characters: 15501 Updates/Obsoletes/See Also: None URL: ftp://ftp.isi.edu/in-notes/rfc2413.txt The Dublin Core Metadata Workshop Series began in 1995 with an invitational workshop which brought together librarians, digital library researchers, content experts, and text-markup experts to promote better discovery standards for electronic resources. The Dublin Core is a 15-element set of descriptors that has emerged from this effort in interdisciplinary and international consensus building. This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute From w3c-dist-auth-request@w3.org Tue Sep 8 18:58:39 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA16821 for ; Tue, 8 Sep 1998 18:58:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13215; Tue, 8 Sep 1998 18:53:25 -0400 (EDT) Resent-Date: Tue, 8 Sep 1998 18:53:25 -0400 (EDT) Resent-Message-Id: <199809082253.SAA13215@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: WEBDAV WG Date: Tue, 8 Sep 1998 15:47:58 -0700 Message-ID: <004101bddb7a$b9e493e0$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Subject: Updated minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2020 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Updated minutes from the Chicago IETF are available online at: http://www.ics.uci.edu/pub/ietf/webdav/chicago/chi_minutes.txt These minutes need to be submitted on September 11, so if you have any comments/corrections, please send them to me by noon Friday. Big thanks go out to John Stracke, Stephen Martin, and Jim Davis for taking notes during the meeting. - Jim From w3c-dist-auth-request@w3.org Wed Sep 9 03:07:50 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA29258 for ; Wed, 9 Sep 1998 03:07:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA17553; Wed, 9 Sep 1998 03:01:55 -0400 (EDT) Resent-Date: Wed, 9 Sep 1998 03:01:55 -0400 (EDT) Resent-Message-Id: <199809090701.DAA17553@www19.w3.org> From: "Larry Masinter" To: "Webdav" Date: Tue, 8 Sep 1998 23:58:11 PDT Message-ID: <000401bddbbf$356e4ee0$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: aliasing and other (primarily) editorial issues with -protocol-08 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2021 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I've owed it to the group to submit an analysis of -protocol-08 over the issue of URL aliases; I apologize for the delay. As you may recall, the issue I raised was one of whether the webdav draft required that a DAV-compliant resource had one, and only one, URI. I pointed out the various situations of aliasing, of which 'case sensitive URI' is only one instance, but other kinds of aliasing might also be possible. A collection is a resource whose state consists of at least a list of internal members and a set of properties, but which may have additional state such as entity bodies returned by GET. An internal member resource MUST have a URI that is immediately relative to the base URI of the collection. That is, the internal member's URI is equal to the parent collection's URI plus an additional segment where segment is defined in section 3.2.1 of RFC 2068 [Fielding et al., 1996]. In this paragraph, it isn't clear whether "MUST have a URI that is ..." means "MUST have only one URI; that URI is ..." or "MUST have at least one URI which is ..." that is, is the requirement of the member resource be that it has no aliases anywhere, or just that aliases are out of scope, or is it just that the requirement on member resources be that there is at least one way of accessing it. Now, if it is allowed that referent of "the internal member's URI" is "the URI that fits the description above", i.e., an internal member might also have other URIs too. Any given internal member MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URI in a collection. Perhaps you mean "e.g." instead of "i.e." here; that is, the example of 'the same URI' is one way of having 'the same resource' in a collection; but it is probably intended that it be illegal to have "Ford" and "FORD" as elements of the "Cars" collection, if the server is case insensitive, even though their URIs aren't 'the same'. I will note the curious phrase under 'locking': Some servers automatically replicate resources across multiple URLs. In such a circumstance the server MUST only accept a lock on one of the URLs if the server can guarantee that the lock will be honored across all the URLs. and note that this might be considered a kind of aliasing, but seems to also allow for other operations ("replication"). In any case, these are, as far as I can tell, the only places in the entire WebDAV protocol document anything that hint at requirement that a resource have only one URI. Adding that requirement in order to be WebDAV compliant would seem to eliminate popular features of web servers; eliminating the confusion and clarifying that a resource might have multiple URIs would improve the spec. Having done so, there seems to be no good reason to require that the multiple URIs for a resource have the same parentage property. In some ways, this just means that clients cannot easily be interoperable if they have some need to perform a (currently unsupported) DAV operation of "going up the parent tree". However, it's not clear, at this point, whether "going up the parent tree" is a necessary operation, so my original call for adding it may be moot. Mainly all we need is to remove the presumption that one can "go up the parent tree" merely by manipulating the URI used to originally access the resource. ----------------------------------- A few minor (editorial) issues that occurred to me as I was looking for areas that might affect this: Throughout the document, the phrases "DAV compliant server" and "DAV complaint resource" are used. But what is the scope of a DAV compliant server? Is it required that all resources served by a DAV compliant server be DAV compliant resources? In the middle of the document, there is the phrase "DAV compliant proxy". However, section 14, DAV Compliance Classes, only describes the compliance classes for DAV resources, and not for servers or proxies. Is a "Dav compliant resource" one that is served by a DAV compliant server, then? Or are some resources served by DAV-compliant servers themselves not DAV-compliant? What are the new requirements for "DAV compliant proxy" that are not requirements for HTTP/1.1 proxies? (That there would be any is curious for a protocol whose T-shirt proclaims it to be Firewall Friendly.) WebDAV servers MUST treat HTTP URL namespaces as collections, regardless of whether they were created with the MKCOL method described in section 7.3. So presumably all http: URLs served by a WebDAV (compliant) server, when the URL is a "namespace" (which, although not defined, I assume means "terminated with "/") are supposed to also function as DAV (compliant?) collections. From w3c-dist-auth-request@w3.org Wed Sep 9 14:56:04 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09907 for ; Wed, 9 Sep 1998 14:56:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA26295; Wed, 9 Sep 1998 14:50:46 -0400 (EDT) Resent-Date: Wed, 9 Sep 1998 14:50:46 -0400 (EDT) Resent-Message-Id: <199809091850.OAA26295@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host mail.saros.com [192.112.1.2] claimed to be saros.com Message-Id: <98Sep9.114138pdt.55569@firewall.saros.com> From: "Babich, Alan" To: "'Whitehead, Jim'" , "'Ruby, Sam'" Cc: "'webdav'" Date: Wed, 9 Sep 1998 11:51:28 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Subject: Minutes of Versioning Meeting in North Carolina Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2022 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list When will the minutes of the WebDAV Versioning and Variants meeting in North Caroline be posted to the WebDAV mailing list? Did I somehow miss them? I assume Sam and Jim got my supplementary notes. Also, I would like to confirm that the e-mail discussions for versioning and variants are taking place in the WebDAV mailing list, not a separate mailing list for versioning and variants only. Thanks. Alan Babich From w3c-dist-auth-request@w3.org Wed Sep 9 16:44:10 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA12185 for ; Wed, 9 Sep 1998 16:44:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28018; Wed, 9 Sep 1998 16:39:11 -0400 (EDT) Resent-Date: Wed, 9 Sep 1998 16:39:11 -0400 (EDT) Resent-Message-Id: <199809092039.QAA28018@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: "Babich, Alan" , "'Ruby, Sam'" Cc: "'webdav'" Date: Wed, 9 Sep 1998 13:31:39 -0700 Message-ID: <000001bddc30$d997ff40$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <98Sep9.114136pdt.55567@firewall.saros.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: RE: Minutes of Versioning Meeting in North Carolina Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2023 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Alan Babich wrote: > When will the minutes of the WebDAV Versioning and > Variants meeting in North Caroline be posted to > the WebDAV mailing list? Did I somehow miss them? > I assume Sam and Jim got my supplementary notes. The way things were left, Sam was charged with producing final minutes from the Design Team meeting. However, if Sam would send me his raw minutes, I could turn them into final minutes. > Also, I would like to confirm that the e-mail > discussions for versioning and variants are taking > place in the WebDAV mailing list, not a separate > mailing list for versioning and variants only. I can confirm this. I want the discussion of versioning and variant authoring capability to be as transparent as possible, so that people who are unable to attend the WebDAV or design team meetings can still provide input into the specification process. - Jim From w3c-dist-auth-request@w3.org Wed Sep 9 18:26:45 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA13752 for ; Wed, 9 Sep 1998 18:26:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA29887; Wed, 9 Sep 1998 18:21:25 -0400 (EDT) Resent-Date: Wed, 9 Sep 1998 18:21:25 -0400 (EDT) Resent-Message-Id: <199809092221.SAA29887@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: Larry Masinter , WEBDAV WG Date: Wed, 9 Sep 1998 15:10:00 -0700 Message-ID: <000201bddc3e$96649860$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <000401bddbbf$356e4ee0$15d0000d@copper-208.parc.xerox.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: RE: aliasing and other (primarily) editorial issues with -protocol-08 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2024 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Larry, Thank you for taking the time to perform a detailed review of the DAV spec. on this issue -- it has helped me understand your concerns much better. My comments are below. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Larry Masinter > Sent: Tuesday, September 08, 1998 11:58 PM > To: Webdav > Subject: aliasing and other (primarily) editorial issues with > -protocol-08 > > > I've owed it to the group to submit an analysis of -protocol-08 over > the issue of URL aliases; I apologize for the delay. > > As you may recall, the issue I raised was one of whether the > webdav draft required that a DAV-compliant resource had one, and > only one, URI. I pointed out the various situations of aliasing, > of which 'case sensitive URI' is only one instance, but other kinds > of aliasing might also be possible. > > A collection is a resource whose state consists of at least a list > of internal members and a set of properties, but which may have > additional state such as entity bodies returned by GET. An internal > member resource MUST have a URI that is immediately relative to the > base URI of the collection. That is, the internal member's URI is > equal to the parent collection's URI plus an additional segment > where segment is defined in section 3.2.1 of RFC 2068 [Fielding et > al., 1996]. > > In this paragraph, it isn't clear whether "MUST have a URI that is ..." > means "MUST have only one URI; that URI is ..." or > "MUST have at least one URI which is ..." > that is, is the requirement of the member resource be that it > has no aliases anywhere, or just that aliases are out of scope, > or is it just that the requirement on member resources be that there > is at least one way of accessing it. > > Now, if it is allowed that referent of "the internal member's URI" > is "the URI that fits the description above", i.e., an internal > member might also have other URIs too. > Let me create a small example which I hope will make my 1:1 URI to resource mapping position clear, and show how it doesn't have the namespace restrictions which are being attributed to it. In my view, there is a 1:1 correspondence between a URI, and an instance of a resource. Since a resource is an abstraction, there is a mapping step where this abstraction is concretely mapped onto the abstractions provided by a particular repository. For a file system respository, a resource is mapped onto a file. If I understand Larry's position correctly, for a given file "foo.html", there is exactly one resource instance. In my view, there can be multiple resource instances associated with "foo.html". But, we both recognize that there can be multiple paths by which "foo.html" can be accessed. There might be an FTP URL, and an HTTP URL. As Larry has pointed out, there can be multiple HTTP URLs (aliases) by which "foo.html" can be accessed, and I agree that a GET on any of these HTTP URLs will retrieve an entity based on the contents of "foo.html". The point of divergence lies with the modeling of "foo.html" with the resource abstraction. My position is that there can be many instances of the resource abstraction which map to the same physical file "foo.html". Each instance corresponds to a different URI. I believe that Larry models "foo.html" as having exactly one instance of the resource abstraction associated with it, but that there can be multiple URIs which identify this instance. So, if the file "foo.html" can be retrieved from the following URLs: http://www.web.com/foocollect/foo.html http://www.web.com/FOOCOLLECT/foo.html http://www.web/com/anothercollect/baz.html Then I view these as being three URLs which identify three resources which each represent the file "foo.html", while Larry views these as three URLs which identify one resource which represents the file "foo.html". Based on this, I view a collection as containing the exactly one URI for a resource. However, as the example above shows, this doesn't imply that the file "foo.html" cannot appear in more than one collection. This also means I don't find the language, "MUST have at least one URI which is a member of the collection", since it isn't meaningful to me for a resource to have more than one URI. But, I know what you mean, and this language is perfectly meaningful if a there is only one resource for an underlying chunk of state, such as the file "foo.html". Note that by having a 1:1 correspondence between URI and resource, this doesn't mean the underlying chunk of state (the file "foo.html") only has one parent. However, in the 1:1 mapping, each *resource* does have one parent, and each resource's parent can be determined by evaluating the relative URI ".." operator on the resource's URL. So, getting back to the previous example, for the 1:1 mapping of URI to resource: Resource: http://www.web.com/foocollect/foo.html Has parent: http://www.web.com/foocollect/ and Resource: http://www.web.com/FOOCOLLECT/foo.html Has parent: http://www.web.com/FOOCOLLECT/ and Resource: http://www.web/com/anothercollect/baz.html Has parent: http://www.web/com/anothercollect/ For the many-to-one mapping of URI to resource: The resource which models file "foo.html" has three parents: http://www.web.com/foocollect/ http://www.web.com/FOOCOLLECT/ http://www.web/com/anothercollect/ It is currently impossible to determine two of the three parents using URL manipulations. As for how state-changing operations such as PUT, DELETE, and PROPPATCH behave when issued against one of many resources which map to the same underlying chunk of state (the file "foo.html"), this is a server policy issue. If the server wishes to delete all resources, and the underlying chunk of state when a DELETE is issued against one of the URLs for a chunk of state, that server is OK to do so. So, following the example some more, if the file "foo.html" can be retrieved from the following URLs: http://www.web.com/foocollect/foo.html http://www.web.com/FOOCOLLECT/foo.html http://www.web/com/anothercollect/baz.html The 1:1 mapping of URL to resource would mean that a DELETE issues against one of these URLs, say, http://www.web.com/foocollect/foo.html, would at minimum mean future GET requests against http://www.web.com/foocollect/foo.html would not retrieve an entity based on "foo.html". The server could also decide to remove file "foo.html" and also ensure that accesses via http://www.web.com/FOOCOLLECT/foo.html and http://www.web/com/anothercollect/baz.html do not retrieve an entity based on file "foo.html", but this is up to the server. > Any given internal member MUST only belong to the collection once, > i.e., it is illegal to have multiple instances of the same URI in a > collection. > > Perhaps you mean "e.g." instead of "i.e." here; that is, the > example of 'the same URI' is one way of having 'the same resource' > in a collection; but it is probably intended that it be illegal > to have "Ford" and "FORD" as elements of the "Cars" collection, > if the server is case insensitive, even though their URIs aren't > 'the same'. Based on the 1:1 mapping of URI to resource, this language is internally consistent, and the "i.e." is seen to mean "that is". > I will note the curious phrase under 'locking': > > Some servers automatically replicate resources across multiple URLs. > In such a circumstance the server MUST only accept a lock on one of > the URLs if the server can guarantee that the lock will be honored > across all the URLs. > > and note that this might be considered a kind of aliasing, but seems > to also allow for other operations ("replication"). This language is inconsistent with the 1:1 mapping of URI to resource. I would rewrite it as: Some servers allow the same chunk of persistent state to be accessed via multiple resources, hence URLs, sometimes by replicating and distributing the persistent state. In such a circumstance the server MUST only accept a lock on one of the resources if the server can guarantee that the lock will be honored across all the resources. > In any case, these are, as far as I can tell, the only places in the > entire WebDAV protocol document anything that hint at requirement that > a resource have only one URI. Adding that requirement in order > to be WebDAV compliant would seem to eliminate popular features of > web servers; eliminating the confusion and clarifying that a resource > might have multiple URIs would improve the spec. > > Having done so, there seems to be no good reason to require that > the multiple URIs for a resource have the same parentage property. > > In some ways, this just means that clients cannot easily be interoperable > if they have some need to perform a (currently unsupported) DAV operation > of "going up the parent tree". However, it's not clear, at this point, > whether "going up the parent tree" is a necessary operation, so my > original call for adding it may be moot. Mainly all we need is to > remove the presumption that one can "go up the parent tree" merely by > manipulating the URI used to originally access the resource. This is dependent on your view of how a resource maps to a URI. - Jim From w3c-dist-auth-request@w3.org Wed Sep 9 18:40:48 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA13902 for ; Wed, 9 Sep 1998 18:40:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA00661; Wed, 9 Sep 1998 18:35:45 -0400 (EDT) Resent-Date: Wed, 9 Sep 1998 18:35:45 -0400 (EDT) Resent-Message-Id: <199809092235.SAA00661@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <35F702D0.DFB7E25C@netscape.com> Date: Wed, 09 Sep 1998 15:36:00 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b1 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Webdav References: <000401bddbbf$356e4ee0$15d0000d@copper-208.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: aliasing and other (primarily) editorial issues with -protocol-08 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2025 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Larry Masinter wrote: > However, it's not clear, at this point, > whether "going up the parent tree" is a necessary operation, Don't base HTTP clients need it for relative links? -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |Reality is what refuses to go away when I| |francis@netscape.com | stop believing in it. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Thu Sep 10 02:48:42 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA23818 for ; Thu, 10 Sep 1998 02:48:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA04903; Thu, 10 Sep 1998 02:43:12 -0400 (EDT) Resent-Date: Thu, 10 Sep 1998 02:43:12 -0400 (EDT) Resent-Message-Id: <199809100643.CAA04903@www19.w3.org> From: "Larry Masinter" To: Cc: "WEBDAV WG" Date: Wed, 9 Sep 1998 23:43:01 PDT Message-ID: <000201bddc86$415ec460$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal In-Reply-To: <000201bddc3e$96649860$d115c380@galileo.ics.uci.edu> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: RE: aliasing and other (primarily) editorial issues with -protocol-08 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2026 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In the context of DAV, I can see things both ways, and that it would be possible to interpret the DAV spec so that 'a resource' had a 1-1 mapping to 'a URI', and that different URIs would be considered different resources. However, I don't think that's consistent with the language of the URI document, the architecture of URN resolution, etc. I can't quite imagine how we might write a document that described URN resolution as mapping the URN (a URI for a resource) to a URL (a URI for a resource) without describing the relationship of the resources represented by the two URIs as 'the same resource'. I suppose I'm surprised that the URI document isn't clearer on this point. In any case, I don't think it is good to leave it ambiguous for WebDAV, since the document actually winds up making different requirements depending on which reading is taken. For example, when the spec says: > Any given internal member MUST only belong to the collection once, > i.e., it is illegal to have multiple instances of the same URI in a > collection. If you take the 1-1 model, this basically says that it is OK to have the same 'chunk of state' as an internal member of a collection more than once, as long as it is reached using a different URI, e.g., you could have a "http://server/cars" resource with internal members "http://server/cars/Ford" and also "http://server/cars/FORD". In this situation, the restriction makes no sense -- what purpose does it serve? There are other places where the spec seems to read awkwardly if URI:resource were 1:1. For example, the wording in section 4.1 on "Collection Resources": # There is a standing convention that when a collection is referred to # by its name without a trailing slash, the trailing slash is # automatically appended. Due to this, a resource may accept a URI # without a trailing "/" to point to a collection. (Should it be 'a server may accept a URI' rather than 'a resource may accept...'?) Is http://server/a/b a different resource than http://server/a/b/? That is, they're two (different) collection resources? This would seem to be the model you're advocating. unless there's a special case that URI:resource is 1-1 except when the URI is a collection, in which case there (may) be a 2-1 relationship, where both http://server/a/b and http://server/a/b/ are actually considered the same resource. Section 4.4: # For this simple case, the URL at which a # resource is accessed is identical to the URL at which the source # (the persistent state) of the resource is accessed. This would be more simply said (if URLs = resources) that "the accessed resource is identical to the source resource", wouldn't it? # Sometimes the entity returned by GET is the output of a data- # producing process that is described by one or more source resources # (that may not even have a location in the URL namespace). In this paragraph, it seems that URI:resource might be 0:1, i.e., if there are resources that don't have URLs. ------------------- More editorial issues: # DAV compliant # resources MUST maintain the consistency of the HTTP URL namespace. Is there a definition of what 'the consistency of the HTP URL namespace' means? It's not defined anywhere, and this sentence only gives an example. # However, the server can sometimes process HTML resources before they # are transmitted as a return entity body. The ability to do server-side processing is not restricted to HTML entities. From w3c-dist-auth-request@w3.org Thu Sep 10 03:09:56 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA23949 for ; Thu, 10 Sep 1998 03:09:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA05077; Thu, 10 Sep 1998 03:05:14 -0400 (EDT) Resent-Date: Thu, 10 Sep 1998 03:05:14 -0400 (EDT) Resent-Message-Id: <199809100705.DAA05077@www19.w3.org> From: "Larry Masinter" To: "John Stracke" , "Webdav" Date: Thu, 10 Sep 1998 00:04:56 PDT Message-ID: <000301bddc89$514a5c60$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal In-Reply-To: <35F702D0.DFB7E25C@netscape.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: RE: aliasing and other (primarily) editorial issues with -protocol-08 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2027 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > However, it's not clear, at this point, > whether "going up the parent tree" is a necessary operation, # Don't base HTTP clients need it for relative links? First of all, relative URI processing is independent of the protocol. Relative links work for "ftp" and for "gopher" and for "urn" and for "vnd.blablah". Relative URI processing is entirely syntactic. It merely performs a string manipulation of a "relative URI" against a "base", without regard to any of the semantics. There is not an operation for "going up the parent tree", there is only an operation for performing relative URI processing of the ".." form. Relative URI processing is entirely under the control of the data form or context that is providing the URI in the first place; e.g., an author of a HTML document may or may not choose to provide relative links within it. Since DAV does not restrict itself to authoring HTML documents, any particular form of document at all, there is no particular reason why DAV resource processors need to deal with relative forms at all. Larry From w3c-dist-auth-request@w3.org Thu Sep 10 05:35:54 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA24606 for ; Thu, 10 Sep 1998 05:35:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA06935; Thu, 10 Sep 1998 05:30:44 -0400 (EDT) Resent-Date: Thu, 10 Sep 1998 05:30:44 -0400 (EDT) Resent-Message-Id: <199809100930.FAA06935@www19.w3.org> To: Larry Masinter cc: ejw@ics.uci.edu, WEBDAV WG In-reply-to: Your message of "Wed, 09 Sep 1998 23:43:01 PDT." <000201bddc86$415ec460$15d0000d@copper-208.parc.xerox.com> Date: Thu, 10 Sep 1998 02:29:25 -0700 From: "Roy T. Fielding" Message-ID: <9809100229.aa15774@paris.ics.uci.edu> Subject: Re: aliasing and other (primarily) editorial issues with -protocol-08 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2028 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >I suppose I'm surprised that the URI document isn't clearer on this >point. It is about as clear as it can get without belaboring the point or specifying something that isn't the case for all resources. I've been busy writing a paper about the Web's architectural style this past month and a good part of it tries to explain the relationship between URI and resources. Most of it is just a rehash of what I already wrote for the URI spec's introduction, but I include more rationale as to why resources are defined the way they are. A brief summary is that a resource is a conceptual mapping, not a chunk of state. It is possible to have both many names for the same resource (many URI that represent the same conceptual mapping) and many resources that point to the same chunk of state (URI with different conceptual mappings that just happen to point to the same representation at a certain point in time). Thus, the 1:1 model does not adequately describe resources even though it is sufficient to define the namespace requirements. Likewise, the allocation of the 'chunk of state' within a server has no relation to a resource other than as the endpoint of a mapping, and thus it doesn't make sense for WebDAV to require anything along those lines (and, as far as I know, it doesn't). I hate to sound like a broken record, but the problem with the WebDAV specification is not on the requirements it makes, but rather on using terminology that makes the requirements seem like they apply to more than what is actually being specified. >For example, when the spec says: > >> Any given internal member MUST only belong to the collection once, >> i.e., it is illegal to have multiple instances of the same URI in a >> collection. It is in fact making a very simple requirement in a very complicated way by using the wrong terminology. What it should say is Each name must be unique within a given namespace. Because the whole issue of multiple "entries" appearing within a single "collection" is totally irrelevant when you aren't defining what we would normally refer to as a collection. >If you take the 1-1 model, this basically says that it is OK to have >the same 'chunk of state' as an internal member of a collection more >than once, as long as it is reached using a different URI, e.g., >you could have a "http://server/cars" resource with internal members >"http://server/cars/Ford" and also "http://server/cars/FORD". >In this situation, the restriction makes no sense -- what purpose >does it serve? No purpose other than to answer a question leftover from when a collection was equivalent to a directed graph. >There are other places where the spec seems to read awkwardly if >URI:resource were 1:1. For example, the wording in section 4.1 on >"Collection Resources": > ># There is a standing convention that when a collection is referred to ># by its name without a trailing slash, the trailing slash is ># automatically appended. Due to this, a resource may accept a URI ># without a trailing "/" to point to a collection. Ummm, this is bogus. If there is no resource without the trailing slash, and the server feels like helping the user, it might REDIRECT the request to a DIFFERENT RESOURCE that is, in fact, the collection. At no time is the URI without a trailing "/" the same resource as the URI with a trailing "/" within a good server implementation of HTTP. ># Sometimes the entity returned by GET is the output of a data- ># producing process that is described by one or more source resources ># (that may not even have a location in the URL namespace). > >In this paragraph, it seems that URI:resource might be 0:1, i.e., >if there are resources that don't have URLs. Everything and anything that can be identified can have a URI, and certainly anything within a server already does have a URI (the file scheme gets around). What it should say is that they might not be accessible independently, since the ability to access is separate from the fact that they are resources. While it is certainly possible for a resource not to have a URI, there is no need for WebDAV to even think about them because if it can't be identified, it can't be used. I should also mention, since it has come up here and on the URI list a few times, that a good HTTP server administrator does not allow multiple URI to the same resource to be accessible unless there is a good reason (such as differentiated access control). The common case is for the case-insensitive or misspelled URI to be externally redirected to the true URI, thus helping a clueless user while at the same time preventing an exponential explosion of resource references when spiders come to index your site. Like the case with the trailing "/" redirect, these other resources do not exist at the time of the redirect. The server is simply making a temporary (and very unstable) mapping based on an implementation decision that is limited to the GET method. ....Roy From w3c-dist-auth-request@w3.org Thu Sep 10 13:38:10 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA02352 for ; Thu, 10 Sep 1998 13:38:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA12094; Thu, 10 Sep 1998 13:32:56 -0400 (EDT) Resent-Date: Thu, 10 Sep 1998 13:32:56 -0400 (EDT) Resent-Message-Id: <199809101732.NAA12094@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-46.netscape.com [205.217.237.46] claimed to be netscape.com Message-ID: <35F80D56.EBD981F8@netscape.com> Date: Thu, 10 Sep 1998 10:33:11 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Webdav References: <000301bddc89$514a5c60$15d0000d@copper-208.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: aliasing and other (primarily) editorial issues with -protocol-08 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2029 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Larry Masinter wrote: > Relative URI processing is entirely under the control of > the data form or context that is providing the URI in the > first place; e.g., an author of a HTML document may or > may not choose to provide relative links within it. Sure, if they don't mind taking on extra pain when they try to maintain their site. It's a scalability thing: someone who authors a large-scale corpus has pretty much got to use relative links. > Since > DAV does not restrict itself to authoring HTML documents, > any particular form of document at all, there is no particular > reason why DAV resource processors need to deal with relative > forms at all. I disagree. Since relative links are so important for the way people write content for the Web, it is vital that DAV accommodate them. Making DAV collections correspond to the syntax that relative links depend on will make it easier for people to organize their content into DAV collections and write relative links accordingly. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | I'm not imaginary. I'm ontologically | |francis@netscape.com | challenged. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Thu Sep 10 14:24:22 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA03223 for ; Thu, 10 Sep 1998 14:24:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA12710; Thu, 10 Sep 1998 14:19:21 -0400 (EDT) Resent-Date: Thu, 10 Sep 1998 14:19:21 -0400 (EDT) Resent-Message-Id: <199809101819.OAA12710@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: WEBDAV WG Date: Thu, 10 Sep 1998 11:07:27 -0700 Message-ID: <001801bddce5$de79fd00$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <9809100229.aa15774@paris.ics.uci.edu> Subject: RE: aliasing and other (primarily) editorial issues with -protocol-08 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2030 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Roy Fielding wrote: > A brief summary is that a resource is a conceptual mapping, not a > chunk of state. It is possible to have both many names for the > same resource (many URI that represent the same conceptual mapping) > and many resources that point to the same chunk of state (URI with > different conceptual mappings that just happen to point to the same > representation at a certain point in time). Thus, the 1:1 model > does not adequately describe resources even though it is sufficient > to define the namespace requirements. Likewise, the allocation of > the 'chunk of state' within a server has no relation to a resource > other than as the endpoint of a mapping, and thus it doesn't make > sense for WebDAV to require anything along those lines (and, as far > as I know, it doesn't). This makes sense to me. > I hate to sound like a broken record, but the problem with the WebDAV > specification is not on the requirements it makes, but rather on using > terminology that makes the requirements seem like they apply to more > than what is actually being specified. > > >For example, when the spec says: > > > >> Any given internal member MUST only belong to the collection once, > >> i.e., it is illegal to have multiple instances of the same URI in a > >> collection. > > It is in fact making a very simple requirement in a very complicated > way by using the wrong terminology. What it should say is > > Each name must be unique within a given namespace. When I read this, I first went, "broken record? What broken record?" Then I went "namespace -- what an overloaded term!" However, checking through the list archives I find: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0095.html which was posted on January 26, 1998, where Roy advocates the use of the term "namespace" instead of "collection", and discusses containment models. Of course, not having been involved in the XML Namespace discussion, "namespace" might seem like a less overloaded term than collection. But, given that the DAV spec. currently uses the term "namespace" with its XML meaning, it behooves us not to reuse the term "namespace" when discussing collections. > Because the whole issue of multiple "entries" appearing within a > single "collection" is totally irrelevant when you aren't defining > what we would normally refer to as a collection. Reading though the DAV spec., I agree that the wording of the terminology in the collections section could be more precise. In particular, I do like Roy's new wording for this requirement: > Each name must be unique within a given namespace. Except I'd change it to read: Each collection member URI MUST be unique within a given collection. Although, this is *exactly* equivalent to the existing language in the spec. which reads: "A collection is a resource whose state consists of at least a list of internal members and a set of properties..." "Any given internal member MUST only belong to the collection once, i.e., it is illegal to have multiple instances of the same URI in a collection." Granted, this last sentence would be more clear if it read, "Any given internal member *URI* MUST ...", but in combination with the definition of a collection, the implication that the internal member is a URI seems fairly clear. > ># There is a standing convention that when a collection is referred to > ># by its name without a trailing slash, the trailing slash is > ># automatically appended. Due to this, a resource may accept a URI > ># without a trailing "/" to point to a collection. > > Ummm, this is bogus. If there is no resource without the trailing slash, > and the server feels like helping the user, it might REDIRECT the request > to a DIFFERENT RESOURCE that is, in fact, the collection. At no time > is the URI without a trailing "/" the same resource as the URI with a > trailing "/" within a good server implementation of HTTP. I'm OK with tweaking the wording here to say that this is due to a redirection, since I agree that a client cannot know ahead of time whether http://foo.bar.com/a and http://foo.bar.com/a/ are the same resource -- only the server has this knowledge. - Jim From w3c-dist-auth-request@w3.org Thu Sep 10 14:50:56 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA03532 for ; Thu, 10 Sep 1998 14:50:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA13038; Thu, 10 Sep 1998 14:45:47 -0400 (EDT) Resent-Date: Thu, 10 Sep 1998 14:45:47 -0400 (EDT) Resent-Message-Id: <199809101845.OAA13038@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: WEBDAV WG Date: Thu, 10 Sep 1998 11:32:02 -0700 Message-ID: <001901bddce9$4d7d7440$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2031 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Larry Masinter writes: ># DAV compliant ># resources MUST maintain the consistency of the HTTP URL namespace. > >Is there a definition of what 'the consistency of the HTP URL namespace' >means? It's not defined anywhere, and this sentence only gives an example. This does appear to be an omission in the specification. By consistency, we meant: No gaps: Given HTTP URL U, for all unique HTTP URL Ux, where Ux is constructed from U by removing all characters to the right of a "/", Ux MUST be the HTTP URL of a WebDAV collection. So, if there is an HTTP URL: http://www.foo.bar.org/a/b/c Then http://www.foo.bar.org/a/b/ http://www.foo.bar.org/a/ MUST be HTTP URLs of WebDAV collection resources. There are two ways to maintain this consistency when a new resource is created: a) create intermediate collections automatically b) refuse to create a resource if intermediate collections do not yet exist. The example in Section 4.3 implies we were recommending option b). Also, consistency implies: 100% containment: Given HTTP URL U, U MUST be a member URL of the collection whose URL, Uc, is contructed by removing the trailing path segment of U. Exception: when U is the top-level resource, "/", of a namespace (i.e., the first slash after the domain name in an HTTP URL), it belongs to no collection, since it is the URI of the root collection. - Jim From w3c-dist-auth-request@w3.org Thu Sep 10 16:55:51 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA05320 for ; Thu, 10 Sep 1998 16:55:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15178; Thu, 10 Sep 1998 16:28:13 -0400 (EDT) Resent-Date: Thu, 10 Sep 1998 16:28:13 -0400 (EDT) Resent-Message-Id: <199809102028.QAA15178@www19.w3.org> Date: Thu, 10 Sep 1998 13:28:27 -0700 From: howard.s.modell@boeing.com (Howard Modell) Message-Id: <199809102028.NAA22829@warlok.ds.boeing.com> To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2032 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list H>From w3c-dist-auth-request@w3.org Thu Sep 10 11:53:20 1998 H>Resent-Message-Id: <199809101845.OAA13039@www19.w3.org> H>MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu H>From: Jim Whitehead H>To: WEBDAV WG H>Date: Thu, 10 Sep 1998 11:32:02 -0700 H>X-Priority: 3 (Normal) H>X-MSMail-Priority: Normal H>Importance: Normal H>Subject: Namespace consistency H> H>Larry Masinter writes: H>># DAV compliant H>># resources MUST maintain the consistency of the HTTP URL namespace. H>> H>>Is there a definition of what 'the consistency of the HTP URL namespace' H>>means? It's not defined anywhere, and this sentence only gives an example. H> H>This does appear to be an omission in the specification. H> H>By consistency, we meant: H> H>No gaps: Given HTTP URL U, for all unique HTTP URL Ux, where Ux is H>constructed from U by removing all characters to the right of a "/", Ux MUST H>be the HTTP URL of a WebDAV collection. H> H>So, if there is an HTTP URL: H> H>http://www.foo.bar.org/a/b/c H> H>Then H> H>http://www.foo.bar.org/a/b/ H>http://www.foo.bar.org/a/ H> H>MUST be HTTP URLs of WebDAV collection resources. H> H>There are two ways to maintain this consistency when a new resource is H>created: H> H>a) create intermediate collections automatically H>b) refuse to create a resource if intermediate collections do not yet exist. H> H>The example in Section 4.3 implies we were recommending option b). H> H>Also, consistency implies: H> H>100% containment: Given HTTP URL U, U MUST be a member URL of the collection H>whose URL, Uc, is contructed by removing the trailing path segment of U. H>Exception: when U is the top-level resource, "/", of a namespace (i.e., the H>first slash after the domain name in an HTTP URL), it belongs to no H>collection, since it is the URI of the root collection. H> H>- Jim H> So if I have a personal webspace, ... http://warlok.ds.boeing.com/~howie/ .. and I choose I create a "WebDAV collection" in my space, .. http://warlok.ds.boeing.com/~howie/a/b/c .. am I in violation of the rules above since the URL of my personal space is NOT of and by itself the URL of a collection? Howard S. Modell ________________________________________________________________________ Comptg Sys.Progr-Analyst/4 POBox 3707, m/s 4A-25, Boeing ISDS howard.s.modell@boeing.com Seattle, WA 98124-2207 http://warlok.ds.boeing.com/~howie/ (206)662-0189[v] (206)662-4018[f] From w3c-dist-auth-request@w3.org Fri Sep 11 14:01:53 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA26039 for ; Fri, 11 Sep 1998 14:01:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA25395; Fri, 11 Sep 1998 13:55:27 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 13:55:27 -0400 (EDT) Resent-Message-Id: <199809111755.NAA25395@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host mail.saros.com [192.112.1.2] claimed to be saros.com Message-Id: <98Sep11.104612pdt.55569@firewall.saros.com> From: "Babich, Alan" To: "'Ruby, Sam'" , "'webdav'" Date: Fri, 11 Sep 1998 10:55:59 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Subject: Versioning: Minutes of meeting in North Carolina Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2033 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Sam: Please e-mail ASAP whatever you have to Jim Whitehead and take him up on his offer to produce the minutes of the last Versioning SC meeting in North Carolina. I'm sure you're very busy, but it has been far to long since the last meeting. We need to get the minutes out to the WEBDAV mailing list, so that e-mail discussion can be started. The lack of the minutes is acting as a log jam. We need people's input now, not at "Last Call". If you already posted the minutes and I missed them, please accept my sincere apology. I'm very behind in my e-mail. Thanks. Alan Babich From w3c-dist-auth-request@w3.org Fri Sep 11 15:25:20 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA27405 for ; Fri, 11 Sep 1998 15:25:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26318; Fri, 11 Sep 1998 15:10:20 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 15:10:20 -0400 (EDT) Resent-Message-Id: <199809111910.PAA26318@www19.w3.org> Message-ID: From: "Babich, Alan" To: "'webdav'" Cc: "Fay, Chuck" , "Whelan, Dan" , "Green, Jim" , "Palmer, Ann" , "Johnson, Andrew" , "Tucker, Michael" , "Fink, Evangeline" Date: Fri, 11 Sep 1998 12:10:52 -0700 X-Mailer: Internet Mail Service (5.5.1960.3) Subject: Versioning: The Next Versioning and Variants meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2034 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The next V&V meeting will be hosted by FileNET in Costa Mesa California, on October 1 and 2 from 9 am to 5 pm Pacific time. If you plan to attend, please e-mail me ASAP so I can order the catered lunches. There is a sandwich place called the Business Park Cafe only a couple of minutes walk away. So you will have the option of going there for lunch instead of eating the catered lunch (unless we decide to work through lunch). The following file has directions from three airports, hotel information, and local maps. The closest airport is John Wayne Orange County airport. Use that airport if you can get a flight. The second closest (and second choice) is Long Beach airport. Since the following file has no directions from Long Beach airport, get in touch with me if you want to use the Long Beach airport. LAX and Ontario airport are a ways away. <> The meeting will be held in "FileNET building 4" of the Harbor Gateway business complex on the second floor in room 2349: <> Enter the lobby, and take the door on the left. Both doors have a badge reader. I will prop the left door open until 9 am on Monday and Tuesday. If you're late, use the phone in the lobby, dial 5883, and ask our sectary Nelsy to please come down and let you in to the WEBDAV Versioning and Variants meeting. There is no receptionist in building 4. We're not going to issue badges. Enter the door on the left, turn left, go up the stairs, go about half way down the corridor, and it's on your right. It's a large room. The room has power for laptops, whiteboards, an overhead projector, and an LCD screen to project what's on your laptop screen using the overhead projector. So, it will be possible to presentations without printing them out. We can also have the secretaries print things out and make copies. I am assuming Jim Whitehead will supply the agenda. If you have any questions, get in touch with me. Alan Babich ABabich@filenet.com 714-966-3403 begin 600 Directions.doc MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````$ M````0@``````````$```1`````$```#^____`````$$```"`````Q````&0! M``#_________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________LI<$`60`)!```"!*_````````$```````!``` M>CL```X`8FIB:O-7\U<````````````````````````)!!8`)5P``)$]`0"1 M/0$`4C<````````G``````````````````````````````#__P\````````` M``#__P\```````````#__P\``````````````````````%T``````*@"```` M````J`(``*@"````````J`(```````"H`@```````*@"````````J`(``!0` M`````````````+P"````````O`(```````"\`@```````+P"```X````]`(` M`"0````8`P``3````+P"````````+Q$``-`!``"``P``I@```"8$```H```` M3@0```````!.!````````$X$````````3@0``%H```"H!```'````,0$```0 M````,@H```(````T"@```````#0*````````-`H``$X```"""@``3`,``,X- M``!,`P``&A$```````#_$@``]`$``/,4``!\````&A$``!4````````````` M````````````J`(```````#4!`````````````````````````````!.!``` M`````$X$````````U`0```````#4!````````!H1``````````4```````"H M`@```````*@"````````3@0``````````````````$X$````````@`,````` M````!0`````````%``````````4```````#4!```%@```*@"````````3@0` M``````"H`@```````$X$````````,@H````````````````````````````` MO`(```````"\`@```````*@"````````J`(```````"H`@```````*@"```` M````U`0````````R"@`````````%``!2!`````4```````!2"0``.@```/P) M```L````J`(```````"H`@`````````````````````````````````````` M````````````````````````````````````````````,@H```````!.!``` M`````&0#```<``````7_UAG=O0&\`@```````+P"````````Z@0``!8````H M"@``"@`````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````0L-1FEL94Y%5"!#;W)P;W)A=&EO;B`O(#,U-C4@2&%R8F]R($)O M=6QE=F%R9"`O($-O&EM871E;'D@,2!H;W5R(&%W87DA M#49R;VT@3$%8+"!T86ME($-E;G1U2`H-#`U*2!3 M;W5T:"`H=&\@3&]N9R!"96%C:"!O2!F;W(@87!P2`T-2TU,"!M:6QE6]U M(&%R92!O;F4@97AI="!A=V%Y(&9R;VT@2&%R8F]R($)O=6QE=F%R9"X@17AI M="!O;B!(87)B;W(@0F]U;&5V87)D(&%N9"!T=7)N(&QE9G0@870@=&AE(&5N M9"!O9B!T:&4@;VXM2!;3F]R=&A=*2X-06QT97)N871E(&9R;VT@3$%8.B`@(%1A:V4@4V5P=6QV M961A($)O=6QE=F%R9"!797-T('1O($EM<&5R:6%L($AI9VAW87DN("!';R!3 M;W5T:"!T;R!386X@1&EE9V\@1G)E97=A>2`H-#`U*2!3;W5T:"`H=&\@3&]N M9R!"96%C:"!O2!O;B!T:&4@-#`U(&9R965W M87D@9F]R(&%P<')O>&EM871E;'D@-#4M-3`@;6EL97,N("!7:&5N('EO=2!A M<'!R;V%C:"!T:&4@175C;&ED(%-T&ET+"!Y;W4@87)E(&]N92!E M>&ET(&%W87D@9G)O;2!(87)B;W(@0F]U;&5V87)D+B`@17AI="!O;B!(87)B M;W(@0F]U;&5V87)D(&%N9"!T=7)N(&QE9G0@870@=&AE(&5N9"!O9B!T:&4@ M;VXM2!;3F]R=&A= M*2X-#41I6YE($%I M&EM871E;'D@,3`@;6EN=71E M2X@17AI="!O;B!(87)B;W(@0F]U;&5V87)D("AO;F4@97AI="!P M87-T($9A:7)V:65W*2!A;F0@='5R;B!R:6=H="X-#4-O;G1I;G5E(&]N($AA M6]U2`Q+C4@:&]U2$-#2AL97-S(&)U6)E('-A M>7,@4V%N=&$@06YA(&]R($]R86YG92!#;W5N='DI#3DQ(%=E&-E;&QE;G0@'0@<&%G92DN("!9;W4@;75S="!U M2!F86-I;&ET:65S(&%N9"!A;B!O=71D;V]R(&AE871E M9"!P;V]L(&%N9"!S<&$N("!4:&5Y('=I;&P@<')O=FED92!S:'5T=&QE('-E M6]U M('!A2!3=6ET97,@ M2&]T96P@:&%S(&-O;64@=7`@=VET:"!A(&1I9F9E2!T:&%N('1H92!O=&AE6YE($%I2!E=F5N:6YG+B`@0V]M<&QI;65N=&%R>2!M96%L2!Y;W4@8V%N(&5N M:F]Y('!I>GIA(&%N9"!B965R+@T-5&AE($1O=6)L951R964@2&]T96P@*&9O M2!H879E(&%N(&]U=&1O;W(@:&5A=&5D('-W:6UM:6YG('!O;VP@ M86YD(&IA8W5Z>FDN("!!(&9U;&P@9FET;F5S2!W:&5N("!Y M;W4@2!W:6QL($Y/($Q/ M3D=%4B!P2`D,3`N,#`N(`T@#4UA6]U('=A;G0@=&AE($9I;&5.150@8V]R<&]R871E(')A=&4N("`@5&AE M(%)E2!Y;W5R(&]W;B!F;V]D+B`@5&AE(&AO=&5L&EM871E;'D@ M)#,S+V1A:6QY(&]R("0Q-C`O=V5E:VQY(&9O6]U('5P(&%T('1H92!Y96QL;W<@8W5R8B!O M=71S:61E('1H92!B86=G86=E(&-L86EM(&%R96$N("!4:&ES(&ES(&]N;'D@ M9V]O9"!I9B!Y;W4@8V]M92!I;G1O($IO:&X@5V%Y;F4@06ER<&]R="X@("!! M;GD@;W1H97(@86ER<&]R="P@>6]U('=O=6QD(&YE960@=&\@=&%K92!T:&4@ M2D@6]U(&%R92!P2!C86X@=7-E(&]U2!D;R!N;W0@;6%K92!R97-E2!W92!C86X@=&\@;6%K92!T:&4@ M6]U('=A;G0@;W(@;F5E9"X@($%L2!P6]U6]U6YD:&%M($=A&5C=71I=F4@;W(@1&5L=7AE(%-U:71E M*0U4;R!E;G-U6YE+T]R86YG92!#;W5N M='D@06ER<&]R="P@=7!O;@UR97%U97-T+B`@06QS;R!P2!S875N82!A;F0@FDN("!3 M:'5T=&QE('-E7-U:71E2!C;V-K=&%I;',-"0EA;F0@8V]M<&QI;65N=&%R>2!M96%L&5R8VES92!F M86-I;&ET>2!O;BUS:71E("AH;W=E=F5R('EO=2!D;R!G970@;65M8F5R2!F86-I;&ET>2!A;F0@9VEF="!S:&]P('=I=&@@ M5D-2(')E;G1A;',N("!!8F]U="`Q,"!M:6X@9G)O;2!T:&4)"0ES:&]P<&EN M9R!M86QL+@T,#0$+#49I;&5.150@0V]R<&]R871I;VX@+R`S-38U($AA6YE+T]R86YG92!#;W5N='D@06ER<&]R="P- M"0EU<&]N(')E<75E&5R8VES92!R;V]M*0T)"51W;R!B M;&]C:W,@9G)O;2!&;W5N=&%I;B!686QL97D@2&EG:"!38VAO;VP@9&ER="!T M2!!:7)P;W)T+`T)"75P M;VX@2!-87)R:6]T=#H)"3$M-"!N:6=H=',))#$P.0D) M)#$S-`T)"0D)"0D)-2TQ,2!N:6=H=',))#DT"0DD,3(Y#0D)"0D)"0DQ,BL@ M;FEG:'1S"20X.0D))#$Q.0T-"0DJ($EN8VQU9&5S(&)R96%K9F%S="!A;F0@ M2`H4D%415,@1D]2(#$Y.3@I#0D)"2A.3R!,3TY'15(@24Y#3%5$15,@ M0E)%04M&05-4*0T)"0T-66]U('=I;&P@3D\@3$].1T52("!R96-E:79E(&$@ M8V]M<&QI;65N=&%R>2!H96%L=&@@8G)E86MF87-T(&)U9F9E="!C;W5P;VX@ M;F]R('-H=71T;&4@F$@4VAO<'!I;F<@36%L;"P@7-I9&5I;FXN M8V]M(`$4:'1T<#HO+W=W=RYC;W5N=')Y2`Q-2P@,3DY.`T)"2I4 M;R!E;G-UGII('1U8BX-"0E4:&ES(&AO M=&5L('=I;&P@2!!:7)P;W)T#2@W,30I(#@S,RTY.3DY(&]R("@X,#`I($A)3%1/ M3E,-,3@X,#`@36%C07)T:'5R($)L=F0N#4ER=FEN92P@0T$N(#DR-S$U#5)A M=&4Z("`D.3`@2`S,"!M:6YU=&5S(&)Y(&-A``!!'@``E"```,H@ M``"N)```KR0``,8D``#Z`/+JXMW7W=?=U]WRZN+=U]W4\NKBW=0`SP#-`,6_ MQ;_%O\6_N;_%O\6_Q;_%O\6_Q;_%O[0`OZR_Q;^G```````````````````` M````````"0-JQ'$``U4(`0\U"(%#2A@`3TH$`%%*!``)`VK"%@``50@!"S4( M@4]*!`!12@0`"S8(@4]*!`!12@0`#C4(@38(@4]*!`!12@0```,U"($)`VIA M"P``50@!!$-*)```"S4(@4]*`P!12@,`"$]*`P!12@,```\V"(%#2AP`3TH# M`%%*`P`/-0B!0THD`$]*`P!12@,`#S4(@4-*'`!/2@,`44H#``D#:@````!5 M"`$`/@`$```#!```4P0``%0$``!5!```5@0``&T$``"4!```KP0``"(&``"N M!P``KP<``,8'``#N!P``#@@```\(```$"0``!0D``.8)``#G"0``_@D``"0* M``!""@``0PH``)X*``#Z````````````````]````````````````/(````` M``````````#N````````````````[@```````````````.L````````````` M``#K````````````````ZP```````````````.0```````````````#D```` M````````````WP```````````````.L```````````````#K```````````` M````ZP```````````````-P```````````````#7````````````````UP`` M`````````````-<```````````````#2````````````````ZP`````````` M`````.L```````````````#K````````````````W````````````````-P` M``````````````````````````4```,D`1.D\``%```#)`,.A-`"`P```R0# M!0```R0#$Z3P``<```,D`PZ$T`(3I/```P```R0!``,```Z$F/X``0``!@`` M`R0!)&0$`0`!!0```R0!#H1H`0`8``0```,$``"[*P``]RL``#TL``!Z+``` MQ"P```LM``!;+0``BRT``.XM``!?+@``82X``&0N``"T+@``M2X``.,N```, M+P``52\``&@O``"_+P``$C```'(P``!S,```H3```,HP```3,0``)C$``'TQ M``#6,0``\C$``/,Q``#T,0``03(``$0R``!@,@``E#(``+$R``#-,@``SC(` M``HS``#^_OKV\N[JYN+>VM;2SLK&PKZZMK*NJJ:BGIJ6DHZ*AH)^>G9R;FIF M!P8;\___#0$'!ASS__\-`0<&.//__PT!!P95\___#0$'!HGS__\-`0<&I?/_ M_PT!!P:H\___#0$'!O7S__\-`0<&]O/__PT!!P;W\___#0$'!A/T__\-`0<& M;/3__PT!!P;#]/__#0$'!M;T__\-`0<&'_7__PT!!P9(]?__#0$'!G;U__\- M`0<&=_7__PT!!P;7]?__#0$'!BKV__\-`0<&@?;__PT!!P:4]O__#0$'!MWV M__\-`0<&!O?__PT!!P8T]___#0$'!C7W__\-`0<&A??__PT!!P:(]___#0$' M!HKW__\-`0<&^_?__PT!!P9>^/__#0$'!H[X__\-`0<&WOC__PT!!P8E^?__ M#0$'!F_Y__\-`0<&K/G__PT!!P;R^?__#0$'!B[Z__\-`0(!`2B>"@``U@H` M`"$+``!5"P``D`L``,<+``#("P``R@L``,T+```=#```"PT```P-``!S#0`` MXPT``(X0``"/$```AA,``(<3``"*%@``BQ8``(,9``"%&0``-!P``#4<``#. M'0``_````````````````/P```````````````#\````````````````_``` M`````````````/P```````````````#W````````````````\P`````````` M`````.X```````````````#H````````````````V````````````````-0` M``````````````#4````````````````U````````````````-0````````` M``````#4````````````````U````````````````-0```````````````#4 M````````````````U````````````````-0```````````````#4```````` M````````U````````````````-0```````````````#4```````````````` M``````````````````,```Z$P@$`#P``#H3"`21D!@$``25D!@$``29D!@$` M`2=D!@$``08```,D`21D!`$``04```,D`0Z$:`$``P``#H3@_`4```,D`1.D M\``#```#)`,`&,X=``#/'0``T!T``-,=```C'@``)!X``"4>```F'@``01X` M`$(>``")(0``BB$``,(B``##(@``+R0``#`D```Q)```IR0``*@D``"I)``` MRB0``,LD``#,)```SB0``-$D``#[````````````````]P`````````````` M`/(```````````````#L````````````````XP```````````````/<````` M``````````#W````````````````WP```````````````-L````````````` M``#;````````````````VP```````````````-L```````````````#;```` M````````````VP```````````````-L```````````````#;```````````` M````VP```````````````-L```````````````#;````````````````\@`` M`````````````-8```````````````#6````````````````U``````````` M`````/(``````````````````````````````````0``!0```R0!#H3@_``# M```.A&@!``,```Z$=?P`"```#<8+``/L!%`9(!P````&```#)`$D9`0!``$% M```#)`$.A&@!``,```Z$?/P``P``#H3"`0`8QB0``,VM?:UP#2`,K2Q](`Q0#:U]K7OM>TOL>^UP#7 MVM>^UZJ^Q[[7VM>FU]H`Q0#%Z:$`Z=K7OM<```````````D#:J4P``!5"`$' M/BH!0TH8`!,""($#:K@O```&"`%#2A@`50@!$P((@0-J5RX```8(`4-*&`!5 M"`$-`VH`````0TH8`%4(`0,^*@$$,$H1```/`@B!`VJ$+0``!@@!50@!"0-J M`````%4(`01#2A@```B8``'LF M``#8)@``,R<``/8G``#W)P``-B@``&`H``"9*```SR@``.SKZNDH)R8E)",A8%]=F]H9&````````````<&"?___PT!!P:# M____#0$,!L+___\(`@`)`0T!``P"!``%`P;N____#0$`#`(#``4"!J3^__\- M`0`'!KK^__\-`0<&VO[__PT!#`;X_O__"`$`"0$-`0`'!OG^__\-`0<&#/__ M_PT!!P9-____#0$'!HK___\-`0<&C?___PT!!P;/____#0$,`@(`!0$&_>[_ M_PT!``<&2N___PT!!P9B[___#0$'!G?O__\-`0<&FN___PT!!P:Y[___#0$' M!KKO__\-`0<&N^___PT!!P:^[___#0$'!HGQ__\-`0<&BO'__PT!!P:-\?__ M#0$'!J_Q__\-`0<&]O'__PT!!P;X\?__#0$'!DWR__\-`0<&B/+__PT!!P:) M\O__#0$'!HKR__\-`0<&VO+__PT!!P;>\O__#0$'!M_R__\-`0`D8#,``&$S M``"<,P``\3,``/,S```Z-```7#0``%\T``!@-```*S8``"XV```O-@``,#8` M`$\V``!R-@``AS8``)\V``#L-@``'3<``%\W``!B-P``GS<``.`W``#S-P`` M]#<``/D```````````````#P````````````````Z@```````````````.H` M``````````````#J````````````````Z@```````````````.H````````` M``````#F````````````````Y@```````````````.H```````````````#B M````````````````X@```````````````/````````````````#<```````` M````````W````````````````-P```````````````#<```````````````` MV@```````````````-P```````````````#<````````````````T@`````` M`````````-P```````````````#<````````````````W``````````````` M``````````````<```Z$T`(/A*`%$830`@`!`@``!0``#H30`@^$\P0``P`` M#H1H`0`#```.A-`"``4```Z$T`(/A.P$``@```Z$T`(/A.P$$F1H`0``!@`` M`R0!)&0$`0`!`!CT-P``$C@``#(X``!(.```6C@``)@X``#7.```43D``%(Y M``!6.0``ICD``*OW__PT! M!P9^_?__#0$'!G_]__\-`0<&B_[__PT!!P:1_O__#0$'!I+^__\-`0<&D_[_ M_PT!!P:R_O__#0$'!K/^__\-`0<&M/[__PT!!P8$____#0$'!@C___\-`0`2 MQ#D``,4Y``#&.0``R3D``,\Y``#;.@``W3H``-XZ```S.P``-#L``$X[``!/ M.P``4#L``%$[``!2.P``4SL``%D[``!:.P``8CL``&,[``!E.P``9CL``&P[ M``!M.P``=3L``'8[``!Z.P``^O4`[^P`YP#B`-K5X@#B`.(`X@#B`.(`X@`` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````````````"0-JPFX``%4(`0\#:A9&?#D*"`%5"`%6 M"`$)`VH`````50@!"0-J86,``%4(`01#2A@```HU"($V"(%#2A@```D#:B>S M``!5"`$)`VJ%50``50@!`!HS.P``4CL``'<[``!X.P``>3L``'H[``#[```` M````````````^0```````````````/<```````````````#W```````````` M````^P`````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````!`````1````,```Z$T`(`!2,`%#`('[#0+R"P MX#TAL-`"(K#0`B.0H`4DD-`");```!BP:`$````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````80L``$0`9`````````````````````$``````/P2"0;N`NX"```` M```````````````````````````````````````/``3PL````+($"O`(```` M`00````*``!C``OPC`````1!`0````7!:`````8!`@```($!$0``$+\!```0 M`/\!```(`$D`.@!<`%0`10!-`%``3`!!`%0`10!<`$<`4@!!`%``2`!)`$,` M4P!<`$8`:0!L`&4`3@!%`%0`(`!,`&\`9P!O`%P`1@!I`&P`90!.`$4`5`!? M`&,`;P!L`&\`<@`N`'<`;0!F```````0\`0```````"`,@`'\%T*```#!$=P M(V+#9(XABL-[@'CB$>W_`#D*```(````1```````>`!@(1OP,0H``$=P(V+# M9(XABL-[@'CB$>TH%``````````````!`````0```,@7+P`(^`X`_PD```#^ M>)REV`EP5=4=Q_'?N;>H*$-M<1FGTQEUJE0M5=`*@E@%VU)!ZP)8I[@@BE6! M$`@0"`J1J,``T:POZTM80A5DR<;VLD!8$J`D0`@A>^RT)$@"A(316J7?=]XC MBC/5F4;GX[WW;/__/UWM?0C;3"2_TJ!N4J]N%[C^$O\=WT<(_.] M=8&[$:;+_:;6W_X*8W0EU_]0%81/ER M>&B3:=9JG5FC7+-:>TRFJDR:_FF2=-[$(5:M)EYU)D&5)E$'L--XM`5K$,=S M%/6S:#?9?*@_FVAB+M4(,T]CS'P]:][2R^9M:?H+>3H@NFA!U MFNGT"2''$%68:=IKIFJ'F:+-YDVEF=>TQ+S"G$YD;E\DEQ?(Z7D];B:0DW25 MN5GG-5[&C-.UYB[6XN<:;/ZBV]"/-@YM._2"_J$7=4P3M4^3M$.O:J->TQJ] MKAA-U;N:K@C-1)B6:`9EH4JE+$LARM8T%>(@3N!?E'7@:]I<;6;H!C.3O3!' M_9/*VAPGRR\HN=JL(G:6KC?YNDC& MG41KY0WKM8'XGVBWUBL?:Q#'\R+*PZA_59OT+.T?8\2':'&'MNM&WK8W&8M> MTA[U50EENW0+97>I6(-5I)%XDG;/Q$M6G%YQO'K56875UJ2@ERE[R&*-)<[3>)(8 M#W/]+1ZR/!I.F^'D-ISQACO;]"A&8;2S58\[6_2$DT^_/.3J*2<'&QAK/=;I M&8S%.&L]?-A-S#*N`6.=_;0K^Y92^NYFG)V,R=?'*21.`?%\Q/41WT<>?OM0 MC1KRK"7G.G*OTR-.O4;B]_@C'K,:T!C49(W"[S`8=Z(_;N_6B`;44UZO7^(N M#,#=Q+@'`XDYD-B#R&&04XY]=BTO[9'_;U=LYSJDEZ,'V-WSG"I%$"&"2!%$ MG$_TM_`V%B`2[Y!E0".:K$@L0#A>OTPC&JPWZ#L5TS`=H8P?2IQ0YX1F.,=P M`#YLIVP;MM)NBT(PE15_\S)YR$4.]=F:Z6S6'&>3YK(3YB&BVT9D(Y_R(OM^ MT]E=H>RR4'9;*+MO!CM\)L+8P;,PF]T\AVLXYE(^#Q&TBZ#]?/K-I_]\3DT$ M.S3"2:4^C7;IM/?2STM_+^-X&<_+N.F,GT:<5*0@V<;OV8K-L.=XL+R\C9?5 M\C*+&8#&M%D96$U4A&-%=T:T6!%TS<&L8A#/.,G$">! MO9?@',$^9"(5R=3SIR@S%(L89NL#1%OQB.,YEG8Q2G8^4)H33<[?R*#,2YV7 MOEYFS?]>/9NAIN">'L]7>X=3@KTHPT'Y.#D%O$$1>ZZ82+N11Y,*:>.C[79F>BM]MQ`OGWAYY)G+V#G.81S" M067S+CF\4P[OELM7*Y(6MF3`8EJ82_ZM;(?_4ZA$U\%?8WKW(VZU2W4O6X%?+K/_8CK*G@UR$W5 M0#=%][C)UMUNDG[E>G0G;@^ZS4I$`OAS,^@W&(E'NR4@$1YK)![&0WB0<8=A M*+$>(.80-QV9&NRNT_WD=K][%$V,V=SM/O=3]<(7;H"NM1C195\#%Y^S2-IQ":[>& M;I\Q5CO.HH.QSZ.36)W$[")^%[OV`KOC`K\)+O#MN,!9[^+KV,&7\0Q?Q7;6 MJBVX9CW;`1?L#IBK"63]!,9@=+=&-%AC>./'\22>QEBW3N.L6HUW:U"-"I1B M`[Q(0PIM^(W*2CV#IUBY,1AM)2(!\=88/(T)F(Z%6!041;OWW0PM<5=KL;O& M>A_O!46Q^R*)&4&L><0)QVQBA.$5[B<%O4S]1"L-F=BFOV(*0MRM"L4,-U\S MW3SZYFF6F\,XZ[%..H=N-4X\9:M6X,8E6'>E:V MD?/8Y*Y4,ZO3[&9QGT59EAIXKJ.\AM6J9A6JV"&5K,@15J<T+F,T"WJR0&2AD)HJ8I6+L9&9*L!>E*./-`QK19)5B+[;B8ZQ%5K=& M-%AKZ?\1UF,#-C'^9JM6V<3-)GXV,YQ#+CGDE$W^V>2XF5S]-I'[!JR$E^+YH=',N\Q3*G<9*:X3I90TS/8MTLXW4E_^K M&VKZX,?F$?-3KM=9(TP_:YBYEFM?].&^#]=KK*$_&/W[=^[2X&^<6_BWG5D^ M@W/LP`ZIBU3I9P?.L2`??GG,XPXRWHPV?\7P* MK=2WTJZ%]B?I=Y+^)QFGA?%:&+>5\4\1YS3:B.N/WT*;%MJVLFM:Z7>*_I\Q MSFFT,6:[C96@LSR?L_']>?CS248*4I&&=,J]U&<@D_:9]%M)?W\L?\Q,QO7' M]^?A13IQTVS\GLWHJ.",7J\^1/$0T4-D#QDD6>?(]"R9!J12%W"6Z.?(YBS. M<-]NI9*M7P9C9=CQVNC7CC.720Y*LMK19J7\S[=Q@W\[\%\<8$9680L``$0` M9`````````````````````$``````/P2"0;N`NX"```````````````````` M```````````````````````/``3PL````+($"O`(`````@0````*``!C``OP MC`````1!`0````7!:`````8!`@```($!$0``$+\!```0`/\!```(`$D`.@!< M`%0`10!-`%``3`!!`%0`10!<`$<`4@!!`%``2`!)`$,`4P!<`$8`:0!L`&4` M3@!%`%0`(`!,`&\`9P!O`%P`1@!I`&P`90!.`$4`5`!?`&,`;P!L`&\`<@`N M`'<`;0!F```````0\`0````!``"`,@`'\%T*```#!$=P(V+#9(XABL-[@'CB M$>W_`#D*```(````I0L`````>`!@(1OP,0H``$=P(V+#9(XABL-[@'CB$>TH M%``````````````!`````0```,@7+P`(^`X`_PD```#^>)REV`EP5=4=Q_'? MN;>H*$-M<1FGTQEUJE0M5=`*@E@%VU)!ZP)8I[@@BE6!$`@0"`J1J,``T:PO MZTM80A5DR<;VLD!8$J`D0`@A>^RT)$@"A(316J7?=]XCBC/5F4;GX[WW;/__ M/UWM?0C;3"2_TJ!N4J]N%[C^$O\=WT<(_.]=8&[$:;+_:;6W_X* M8W0EU_]0%81/ER>&B3:=9JG5FC7+-: M>TRFJDR:_FF2=-[$(5:M)EYU)D&5)E$'L--XM`5K$,=S%/6S:#?9?*@_FVAB M+M4(,T]CS'P]:][2R^9M:?H+>3H@NFA!UFNGT"2''$%68:=IK MIFJ'F:+-YDVEF=>TQ+S"G$YD;E\DEQ?(Z7D];B:0DW25N5GG-5[&C-.UYB[6 MXN<:;/ZBV]"/-@YM._2"_J$7=4P3M4^3M$.O:J->TQJ]KAA-U;N:K@C-1)B6 M:`9EH4JE+$LARM8T%>(@3N!?E'7@:]I<;6;H!C.3O3!'_9/*VAPGRR\HN=JL(G:6KC?YNDC&G41KY0WKM8'XGVBW MUBL?:Q#'\R+*PZA_59OT+.T?8\2':'&'MNM&WK8W&8M>TA[U50EENW0+97>I M6(-5I)%XDG;/Q$M6 MG%YQO'K56875UJ2@ERE[R&*-)<[3>)(8#W/]+1ZR/!I.F^'D M-ISQACO;]"A&8;2S58\[6_2$DT^_/.3J*2<'&QAK/=;I&8S%.&L]?-A-S#*N M`6.=_;0K^Y92^NYFG)V,R=?'*21.`?%\Q/41WT<>?OM0C1KRK"7G.G*OTR-. MO4;B]_@C'K,:T!C49(W"[S`8=Z(_;N_6B`;44UZO7^(N#,#=Q+@'`XDYD-B# MR&&04XY]=BTO[9'_;U=LYSJDEZ,'V-WSG"I%$"&"2!%$G$_TM_`V%B`2[Y!E M0".:K$@L0#A>OTPC&JPWZ#L5TS`=H8P?2IQ0YX1F.,=P`#YLIVP;MM)NBT(P ME15_\S)YR$4.]=F:Z6S6'&>3YK(3YB&BVT9D(Y_R(OM^T]E=H>RR4'9;*+MO M!CM\)L+8P;,PF]T\AVLXYE(^#Q&TBZ#]?/K-I_]\3DT$.S3"2:4^C7;IM/?2 MSTM_+^-X&<_+N.F,GT:<5*0@V<;OV8K-L.=XL+R\C9?5\C*+&8#&M%D96$U4A&-%=T:T6!%TS<&L8A#/.,G$">!O9?@',$^9"(5R=3S MIR@S%(L89NL#1%OQB.,YEG8Q2G8^4)H33<[?R*#,2YV7OEYFS?]>/9NAIN"> M'L]7>X=3@KTHPT'Y.#D%O$$1>ZZ82+N11Y,*:>.C[79F>BM]MQ`OGWAYY)G+V#G.81S"067S+CF\4P[OELM7 M*Y(6MF3`8EJ82_Z MM;(?_4ZA$U\%?8WKW(VZU2W4O6X%?+K/_8CK*G@UR$W50#=%][C)UMUNDG[E M>G0G;@^ZS4I$`OAS,^@W&(E'NR4@$1YK)![&0WB0<8=A*+$>(.80-QV9&NRN MT_WD=K][%$V,V=SM/O=3]<(7;H"NM1C195\#%Y^S2-IQ":[>&;I\Q5CO.HH.QSZ.3 M6)W$[")^%[OV`KOC`K\)+O#MN,!9[^+KV,&7\0Q?Q7;6JBVX9CW;`1?L#IBK M"63]!,9@=+=&-%AC>./'\22>QEBW3N.L6HUW:U"-"I1B`[Q(0PIM^(W*2CV# MIUBY,1AM)2(!\=88/(T)F(Z%6!041;OWW0PM<5=KL;O&>A_O!46Q^R*)&4&L M><0)QVQBA.$5[B<%O4S]1"L-F=BFOV(*0MRM"L4,-U\SW3SZYFF6F\,XZ[%. M.H=N-4X\9:M6X,8E6'>E:VD?/8Y*Y4,ZO3[&9Q MGT59EAIXKJ.\AM6J9A6JV"&5K,@15J<T+F,T"WJR0 M&2AD)HJ8I6+L9&9*L!>E*./-`QK19)5B+[;B8ZQ%5K=&-%AKZ?\1UF,#-C'^ M9JM6V<3-)GXV,YQ#+CGDE$W^V>2XF5S]-I'[!JR$E^+YH=',N\Q3*G<9*:X3I90TS/8MTLXW4E_^K&VKZX,?F$?-3KM=9 M(TP_:YBYEFM?].&^#]=KK*$_&/W[=^[2X&^<6_BWG5D^@W/LP`ZIBU3I9P?.L2`??GG,XPXRWHPV?\7P*K=2WTJZ%]B?I=Y+^ M)QFGA?%:&+>5\4\1YS3:B.N/WT*;%MJVLFM:Z7>*_I\QSFFT,6:[C96@LSR? ML_']>?CS248*4I&&=,J]U&<@D_:9]%M)?W\L?\Q,QO7']^?A13IQTVS\GLWH MJ.",7J\^1/$0T4-D#QDD6>?(]"R9!J12%W"6Z.?(YBS.<-]NI9*M7P9C9=CQ MVNC7CC.720Y*LMK19J7\S[=Q@W\[\%\<8$9680L``$0`9``````````````` M``````$``````/P2"0;N`NX"```````````````````````````````````` M```````/``3PL````+($"O`(`````P0````*``!C``OPC`````1!`0````7! M:`````8!`@```($!$0``$+\!```0`/\!```(`$D`.@!<`%0`10!-`%``3`!! M`%0`10!<`$<`4@!!`%``2`!)`$,`4P!<`$8`:0!L`&4`3@!%`%0`(`!,`&\` M9P!O`%P`1@!I`&P`90!.`$4`5`!?`&,`;P!L`&\`<@`N`'<`;0!F```````0 M\`0````"``"`,@`'\%T*```#!$=P(V+#9(XABL-[@'CB$>W_`#D*```(```` M!A<`````>`!@(1OP,0H``$=P(V+#9(XABL-[@'CB$>TH%``````````````! M`````0```,@7+P`(^`X`_PD```#^>)REV`EP5=4=Q_'?N;>H*$-M<1FGTQEU MJE0M5=`*@E@%VU)!ZP)8I[@@BE6!$`@0"`J1J,``T:POZTM80A5DR<;VLD!8 M$J`D0`@A>^RT)$@"A(316J7?=]XCBC/5F4;GX[WW;/__/UWM?0C M;3"2_TJ!N4J]N%[C^$O\=WT<(_.]=8&[$:;+_:;6W_X*8W0EU_]0%81/ER>&B3:=9JG5FC7+-:>TRFJDR:_FF2=-[$ M(5:M)EYU)D&5)E$'L--XM`5K$,=S%/6S:#?9?*@_FVAB+M4(,T]CS'P]:][2 MR^9M:?H+>3H@NFA!UFNGT"2''$%68:=IKIFJ'F:+-YDVEF=>T MQ+S"G$YD;E\DEQ?(Z7D];B:0DW25N5GG-5[&C-.UYB[6XN<:;/ZBV]"/-@YM M._2"_J$7=4P3M4^3M$.O:J->TQJ]KAA-U;N:K@C-1)B6:`9EH4JE+$LARM8T M%>(@3N!?E'7@:]I<;6;H!C.3O3!'_9/*< MR]U>VAPGRR\HN=JL(G:6KC?YNDC&G41KY0WKM8'XGVBWUBL?:Q#'\R+*PZA_ M59OT+.T?8\2':'&'MNM&WK8W&8M>TA[U50EENW0+97>I6(-5I)%XDG;/Q$M6G%YQO'K56875UJ2@ MERE[R&*-)<[3>)(8#W/]+1ZR/!I.F^'D-ISQACO;]"A&8;2S M58\[6_2$DT^_/.3J*2<'&QAK/=;I&8S%.&L]?-A-S#*N`6.=_;0K^Y92^NYF MG)V,R=?'*21.`?%\Q/41WT<>?OM0C1KRK"7G.G*OTR-.O4;B]_@C'K,:T!C4 M9(W"[S`8=Z(_;N_6B`;44UZO7^(N#,#=Q+@'`XDYD-B#R&&04XY]=BTO[9'_ M;U=LYSJDEZ,'V-WSG"I%$"&"2!%$G$_TM_`V%B`2[Y!E0".:K$@L0#A>OTPC M&JPWZ#L5TS`=H8P?2IQ0YX1F.,=P`#YLIVP;MM)NBT(PE15_\S)YR$4.]=F: MZ6S6'&>3YK(3YB&BVT9D(Y_R(OM^T]E=H>RR4'9;*+MO!CM\)L+8P;,PF]T\ MAVLXYE(^#Q&TBZ#]?/K-I_]\3DT$.S3"2:4^C7;IM/?2STM_+^-X&<_+N.F, MGT:<5*0@V<;OV8K-L.=XL+R\C9?5\C*+&8#&M%D96$U M4A&-%=T:T6!%TS<&L8A#/.,G$">!O9?@',$^9"(5R=3SIR@S%(L89NL#1%OQ MB.,YEG8Q2G8^4)H33<[?R*#,2YV7OEYFS?]>/9NAIN">'L]7>X=3@KTHPT'Y M.#D%O$$1>ZZ82+N11Y,*:>.C M[79F>BM]MQ`OGWAYY)G+V#G.81S"067S+CF\4P[OELM7*Y(6MF3`8EJ82_ZM;(?_4ZA$U\%?8WK MW(VZU2W4O6X%?+K/_8CK*G@UR$W50#=%][C)UMUNDG[E>G0G;@^ZS4I$`OAS M,^@W&(E'NR4@$1YK)![&0WB0<8=A*+$>(.80-QV9&NRNT_WD=K][%$V,V=SM M/O=3] M<(7;H"NM1C195\#%Y^S2-IQ":[>&;I\Q5CO.HH.QSZ.36)W$[")^%[OV`KOC M`K\)+O#MN,!9[^+KV,&7\0Q?Q7;6JBVX9CW;`1?L#IBK"63]!,9@=+=&-%AC M>./'\22>QEBW3N.L6HUW:U"-"I1B`[Q(0PIM^(W*2CV#IUBY,1AM)2(!\=88 M/(T)F(Z%6!041;OWW0PM<5=KL;O&>A_O!46Q^R*)&4&L><0)QVQBA.$5[B<% MO4S]1"L-F=BFOV(*0MRM"L4,-U\SW3SZYFF6F\,XZ[%..H=N-4X\9:M6X,8E6'>E:VD?/8Y*Y4,ZO3[&9QGT59EAIXKJ.\AM6J M9A6JV"&5K,@15J<T+F,T"WJR0&2AD)HJ8I6+L9&9* ML!>E*./-`QK19)5B+[;B8ZQ%5K=&-%AKZ?\1UF,#-C'^9JM6V<3-)GXV,YQ# M+CGDE$W^V>2XF5S]-I'[!JR$E^+YH= M',N\Q3*G<9*:X3I90TS/8MTLXW4E_^K&VKZX,?F$?-3KM=9(TP_:YBYEFM?].&^ M#]=KK*$_&/W[=^[2X&^<6_BWG5D^@W/LP`ZIB MU3I9P?.L2`??GG,XPXRWHPV?\7P*K=2WTJZ%]B?I=Y+^)QFGA?%:&+>5\4\1 MYS3:B.N/WT*;%MJVLFM:Z7>*_I\QSFFT,6:[C96@LSR?L_']>?CS248*4I&& M=,J]U&<@D_:9]%M)?W\L?\Q,QO7']^?A13IQTVS\GLWHJ.",7J\^1/$0T4-D M#QDD6>?(]"R9!J12%W"6Z.?(YBS.<-]NI9*M7P9C9=CQVNC7CC.720Y*LMK1 M9J7\S[=Q@W\[\%\<8$9680L``$0`9`````````````````````$``````/P2 M"0;N`NX"```````````````````````````````````````````/``3PL``` M`+($"O`(````!00````*``!C``OPC`````1!`0````7!:`````8!`@```($! M$0``$+\!```0`/\!```(`$D`.@!<`%0`10!-`%``3`!!`%0`10!<`$<`4@!! M`%``2`!)`$,`4P!<`$8`:0!L`&4`3@!%`%0`(`!,`&\`9P!O`%P`1@!I`&P` M90!.`$4`5`!?`&,`;P!L`&\`<@`N`'<`;0!F```````0\`0````$``"`,@`' M\%T*```#!$=P(V+#9(XABL-[@'CB$>W_`#D*```(````9R(`````>`!@(1OP M,0H``$=P(V+#9(XABL-[@'CB$>TH%``````````````!`````0```,@7+P`( M^`X`_PD```#^>)REV`EP5=4=Q_'?N;>H*$-M<1FGTQEUJE0M5=`*@E@%VU)! MZP)8I[@@BE6!$`@0"`J1J,``T:POZTM80A5DR<;VLD!8$J`D0`@A>^RT)$@" MA(316J7?=]XCBC/5F4;GX[WW;/__/UWM?0C;3"2_TJ!N4J]`0`` M``(````#````!`````4````&````!P````@````)````"@````L````,```` M#0````X````/````$````!$````2````$P```!0````5````%@```!<````8 M````&0```!H````;````'````!T````>````'P```"`````A````(@```",` M```D````)0```"8````G````*````"D````J````*P```"P````M````+@`` M`/[___\P````,0```#(````S````-````#4````V````-P```#@````Y```` M.@```#L````\````/0```#X````_````0````&4!``#]____0P```$D```#^ M____1@```$<```!(````?@```&0```!+````3````$T```!.````3P```%`` M``!1````4@```%,```!4````50```%8```!7````6````%D```!:````6P`` M`%P```!=````7@```%\```!@````80```&(```!C````_O___W\```!F```` M9P```&@```!I````:@```&L```!L````;0```&X```!O````<````'$```!R M````0```'H```![````?````'T` M``#^____P@```,,```!2`&\`;P!T`"``10!N`'0`<@!Y````;@`N`&@`=`!M M``````#U`@"@6,!$`#P`0``P@R=P`````#A!1`#=`@"@%@`%`?__________ M'@````8)`@``````P````````$8`````<@!E`&4`+@`@I@;7&=V]`44````` M&P``;`!E`$0`80!T`&$```!E`&P`,0`V`#$`+P`Q`#<`.0`O`#$`-P`Y`$T` M80!I`&X`+@!H`'0`;0``````80(`H%C`1``*``(!________________```` M````````````````````````````````````````````+P```,:9```````` M5P!O`'(`9`!$`&\`8P!U`&T`90!N`'0````````````````````````````` M`````````````````````````!H``@$=````__________\````````````` M````````````````````````````````````````)5P```````!/`&(`:@!E M`&,`=`!0`&\`;P!L```````````````````````````````````````````` M````````````````%@`!`2````#_____"0`````````````````````````` M````0)9OUAG=O0$@I@;7&=V]`0```````````````%\`.0`S`#,`-P`V`#<` M.``T`#`````````````````````````````````````````````````````` M```````6``$`__________\&`````0D"``````#`````````1@``````OGC6 M&=V]`2!?@-89W;T!`````````````````P!0`$D`0P`````````````````` M``````````````````````````````````````````````````````````H` M`@'_______________\````````````````````````````````````````` M````````````3``````````#`$T`10!4`$$````````````````````````` M````````````````````````````````````````````````#``"`04````' M````_____P````````````````````````````````````````````````(` M``#H`P````````,`4`!)`$,`5``````````````````````````````````` M```````````````````````````````````````,``(!_____P@```#_____ M````````````````````````````````````````````````$@```"`"```` M`````0```/[___\#````!`````4````&````!P````@````)````"@````L` M```,````#0````X````/````$````!$```#^____$P```!0````5````%@`` M`!<````8````&0```!H```#^_____O____[___\>````_O____[____^____ M(@```",````D````)0```"8````G````*````"D```#^_____O___RP```#^ M_____O____[___\P````,0```#(````S````-````#4````V````-P```#@` M```Y````_O___SL````\````/0```#X````_````0````$$```#^____0P`` M`$0```!%````1@```$<```!(````20```$H```!+````3````$T```!.```` M3P```%````!1````4@```%,```!4````50```%8```!7````6````%D```!: M````6P```%P```!=````7@```%\```!@````80```&(```!C````9````&4` M``!F````9P```&@```!I````_O___VL```#^________________________ M____________________________________________________________ M__________________________],````````````"`#'$0``]@0``!0*``#0 M`@```````````````````````.@#``#H`P`````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````@`QQ'V!(8,`0`)```#V0$`````C@$`````!0````L" M```'``4````,`B0`@0`$````!`$-``0````N`1@`!`````(!`0`%````"0(` M````!0````$"____``,````>``H````F!@\`"@#_____!@``````!`````^`JJH??^``#C___\`>!#@`3`0#@_@``/OX`"`XX`'_`/`0X`!,%`8`YY\'P M_@`(..55``'@$.``$@0!@!SSX/T`"..````/___P``P$`,`.>?#W``(!\``* M`0!X]0`#`_^```H!`#_U``'__O\`"0$`!_7_`/S^``@B````36EC'```` M``````H````F!@\`"@!43E!0```"`/0#"0```"8&#P`(`/____\#````#P`` M`"8&#P`4`%1.4%`$``P``0````$`````````!0````L"``````4````,`FH( M.@L$````!`$-``<```#\`@``____````!````"T!```)````^@(%``````#_ M__\`(@`$````+0$!``0````M`0``"0```!T&(0#P`'`(0`L`````!````"T! M```$````+0$```D```#Z`@`````````````B``0````M`0(`!P```/P"`0`` M```````$````+0$#``0````M`0$`!P```!L$^0$Q"9@!$`($````+0$```0` M```M`0(`!````"T!`P`$````+0$!``<````;!$`#$0@?`C`#!````"T!```$ M````+0$"``0````M`0,`!````"T!`0`'````&P21`]D),`-H`00````M`0`` M!````"T!`@`$````+0$#``0````M`0$`!P```!L$2P2"".H#00`$````+0$` M``0````M`0(`!````"T!`P`$````+0$!``<````;!'8%L03Y!'D`!````"T! M```$````+0$"``T```#[`@``````````````````````````!````"T!!``% M````"0(````"!0```!0"``````0````"`0(`$````"8&#P`6`/____\``!H` M``#(````%`H``,\````)````^@(```0`````)Y\`(@`$````+0$%``0````M M`0,`"````"4#`@`=`,L`$`K+``0````M`0(`!````/`!!0`$````+0$```@` M```F!@\`!@#_____`0`0````)@8/`!8`_____P``00```.$!``!Z"0``Z0$` M``D```#Z`@``!``````GGP`B``0````M`04`!````"T!`P`(````)0,"`$0` MY`%V">4!!````"T!`@`$````\`$%``0````M`0``"````"8&#P`&`/____\! M`!`````F!@\`%@#_____``#W`0``3`0``#X+``!9!```"0```/H"```$```` M`">?`"(`!````"T!!0`$````+0$#``@````E`P(`^@%5!#H+3P0$````+0$" M``0```#P`04`!````"T!```(````)@8/``8`_____P$`$````"8&#P`6`/__ M__\``&?`"(`!````"T!!0`$````+0$#``@````E`P(`U051`-`%C`<$ M````+0$"``0```#P`04`!````"T!```(````)@8/``8`_____P$`$````"8& M#P`6`/____\``'<&``!=````@P8``)X'```)````^@(```0`````)Y\`(@`$ M````+0$%``0````M`0,`"````"4#`@!_!F``>@::!P0````M`0(`!````/`! M!0`$````+0$```@````F!@\`!@#_____`0`0````)@8/`!8`_____P``<`@` M`&X```!W"```KP<```D```#Z`@``!``````GGP`B``0````M`04`!````"T! M`P`(````)0,"`',(<0!S"*L'!````"T!`@`$````\`$%``0````M`0``"``` M`"8&#P`&`/____\!`!`````F!@\`%@#_____```1"0``9P```"8*``#A!@`` M"0```/H"```$`````">?`"(`!````"T!!0`$````+0$#``@````E`P(`(@IJ M`!0)W08$````+0$"``0```#P`04`!````"T!```(````)@8/``8`_____P$` M!````"T!`P`$````+0$!``<````;!,T`'0)W`%X!!````"T!```$````+0$" M``4````)`@````(%````%`(`````$````/L"T/\```````"\`@`````````B M07)I86P`KH$$````+0$%``0```#P`00`!0````D"`````@4````4`@`````$ M````+@$8``0````"`0$`$````#(*M`!Z`08```!3;&%T97(@``X`&@`0`!L` M$@`$````+@$!``0````"`0(`!`````(!`@`$````+0$#``0````M`0$`!P`` M`!L$W@$6"(`!T`$P`$````+@$!``0` M```"`0(`!`````(!`@`$````+0$#``0````M`0$`!P```!L$Q``."&X`+P<$ M````+0$```0````M`0(`!0````D"`````@4````4`@`````%````"0(````" M!0```!0"``````0````N`1@`!`````(!`0`0````,@JK`$P'!@```%=A``T`!````"X!`0`$ M`````@$"``0````"`0(`$````"8&#P`6`/____\``(X&``#7`@``Y08``'L# M```(````)@8/``8`_____P$`!0````D"`````@4````4`@`````0````^P+0 M_P``C`J,"KP"``````<``")!`!H`&P`:``X`(@`;`!T`$``;`!(`!````"X!`0`$```` M`@$"``0````"`0(`!````"T!`P`$````+0$!``<````;!&P#4P05`WX#!``` M`"T!```$````+0$"``4````)`@````(%````%`(`````$````/L"T/\````` M``"\`@`````````B07)I86P`3F4$````+0$$``0```#P`04`!0````D"```` M`@4````4`@`````$````+@$8``0````"`0$`$````#(*4@.;`P8```!38V5N M:6,@`!L`&@`>``T`&P`$````+@$!``0````"`0(`!`````(!`@`0````)@8/ M`!8`_____P``P,```D```#Z`@``!``````GGP`B``0` M```M`04`!````"T!`P`(````)0,"`'8#=P-V`]("!````"T!`@`$````\`$% M``0````M`0``"````"8&#P`&`/____\!`!`````F!@\`%@#_____``!6`@`` M%P(``"8$``#>`@``"0```/H"```$`````">?`"(`!````"T!!0`$````+0$` M``<````;!,\"%P0G`F8"!````"T!`@`$````\`$%``0````M`0``"````"8& M#P`&`/____\!``0````M`0,`!````"T!`0`'````&P2/`C0$.0)E`@0````M M`0``!````"T!`@`%````"0(````"!0```!0"``````4````)`@````(%```` M%`(`````!````"X!&``$`````@$!`!\````R"G8"@0(0````1FEL94YE="!4 M`7<` M"@```$)R;V]K:'5R`!(`&P`0``0````N`0$`!``` M``(!`@`$`````@$"``0````M`0,`!````"T!`0`'````&P1:!$L#!`0H`@0` M```M`0``!````"T!`@`%````"0(````"!0```!0"`````!````#[`M#_```` M````O`(`````````(D%R:6%L`$YE!````"T!!``$````\`$%``4````)`@`` M``(%````%`(`````!````"X!&``$`````@$!`!4````R"D$$10()````4W5N M9FQO=V5R`"``'@`=`!``#@`=`"8`&@`3``0````N`0$`!`````(!`@`$```` M`@$"``0````M`0,`!````"T!`0`'````&P3B`Z<)BP-F"`0````M`0``!``` M`"T!`@`%````"0(````"!0```!0"``````4````)`@````(%````%`(````` M!````"X!&``$`````@$!`!@````R"L@#@@@+````079E(&]F($%R=',`(P`: M`!L`#0`>`!``#0`C`!(`$``;``0````N`0$`!`````(!`@`$`````@$"`!`` M```F!@\`%@#_____``"D"```X`,```D)``")!```"0```/H"```$```````` M`"(`!````"T!!0`$````+0$#``@````E`P(`IPCC`_8(:@0$````+0$!``0` M``#P`04`!P```/P"```````````$````+0$%``H````D`P,`Y@AQ!`4)A00" M"6`$!````"T!`@`$````+0$```@````F!@\`!@#_____`0`0````)@8/`!8` M_____P``9@@``",%```""0``*P4```D```#Z`@``!``````GGP`B``0````M M`08`!````"T!`P`(````)0,"`&D()@7^""<%!````"T!`@`$````\`$&``0` M```M`0``"````"8&#P`&`/____\!`!`````F!@\`%@#_____```3"0``200` M`!L)```H!0``"0```/H"```$`````">?`"(`!````"T!!@`$````+0$#``@` M```E`P(`%@DD!1<)3`0$````+0$"``0```#P`08`!````"T!```(````)@8/ M``8`_____P$`!````"T!`P`$````+0$!``<````;!-L$!@EV!*8(!````"T! M```$````+0$"``0````M`0,`!````"T!`0`'````&P3\!-()K@2!"00````M M`0``!````"T!`@`0````)@8/`!8`_____P``^@8``'($``!U"```-08```D` M``#Z`@``!``````GGP`B``0````M`08`!````"T!```'````&P0F!F8(@@0* M!P0````M`0(`!````/`!!@`$````+0$```@````F!@\`!@#_____`0`$```` M+0$#``0````M`0$`!P```!L$\05K"$0%OP<$````+0$```0````M`0(`!0`` M``D"`````@4````4`@`````0````^P+8_P```````+P"`````````")!F$`&P`+`!8`%``6``0````N`0$`!`````(!`@`$```` M`@$"``0````M`0,`!````"T!`0`'````&P1I!CL*&P;J"00````M`0``!``` M`"T!`@`0````)@8/`!8`_____P``_____T$&```P"P``308```0````M`0$` M!P```/P"````)Y\````$````+0$$``0````&`0(`#````"0#!``$`$(&!`!* M!BH+2P8J"T,&!`````8!`0`$````+0$"``0````M`0``!````/`!!``(```` M)@8/``8`_____P$`$````"8&#P`6`/____\``%T$``"3!0``X00``#\&```) M````^@(```0`````)Y\`(@`$````+0$$``0````M`0,`)@```"4#$0#?`"(`!````"T!!@`$````+0$` M``<````;!`L'+0M2!J`)!````"T!`@`$````\`$&``0````M`0``"````"8& M#P`&`/____\!``0````M`0,`!````"T!`0`'````&P1@!V$&$@<0!@0````M M`0``!````"T!`@`$````+0$#``0````M`0$`!P```!L$[P8C"U\&S@D$```` M+0$```0````M`0(`!0````D"`````@4````4`@`````%````"0(````"!0`` M`!0"``````0````N`1@`!`````(!`0`6````,@J`!(`$``$````+@$!``0````"`0(`!`````(!`@`$ M````+0$#``0````M`0$`!P```!L$I@@3!!8(H0$$````+0$```0````M`0(` M!0````D"`````@4````4`@`````%````"0(````"!0```!0"``````0````N M`1@`!`````(!`0`>````,@I3"+X!#P```"H@34%0($E3($Y/5"!43P`3``T` M*``C`"``#0`.`"``#0`C`"4`'@`-`!X`)0`$````+@$!``0````"`0(`!0`` M``D"`````@4````4`@`````$````+@$8``0````"`0$`#P```#(*C0B^`04` M``!30T%,10`@`",`(@`>`"``!````"X!`0`$`````@$"``0````"`0(`$``` M`"8&#P`6`/____\``%D$``"=`P``Q`0``+H%```(````)@8/``8`_____P$` M!0````D"`````@4````4`@`````0````^P+`_P``C`J,"KP"``````<``")! M_O__LP@``.W^__\`"0``"0```/H"```$`````">?`"(` M!````"T!!``$````+0$```<````8!/P(Z?ZV"*'^!````"T!`@`$````\`$$ M``0````M`0``"````"8&#P`&`/____\!`!`````F!@\`%@#_____``#]```` MM`<``#4*``"\!P``"0```/H"```$`````">?`"(`!````"T!!``$````+0$# M``@````E`P(```&W!S$*N`<$````+0$"``0```#P`00`!````"T!```(```` M)@8/``8`_____P$`!````"T!`P`$````+0$!``<````;!`X(=0:X!YD%!``` M`"T!```$````+0$"``4````)`@````(%````%`(`````$````/L"T/\````` M``"\`@`````````B07)I86P`3F4$````+0$$``0```#P`08`!0````D"```` M`@4````4`@`````$````+@$8``0````"`0$`#P```#(*]0>V!04```!!9&%M M?`"(`!``` M`"T!!@`$````+0$#``@````E`P(`/0#Q!JX"\@8$````+0$"``0```#P`08` M!````"T!```(````)@8/``8`_____P$`!````"T!`P`$````+0$!``<````; M!.0&GP*7!LX!!````"T!```$````+0$"``4````)`@````(%````%`(````` M$````/L"V/\```````"\`@`````````B07)I86P`KH$$````+0$&``0```#P M`00`!0````D"`````@4````4`@`````$````+@$8``0````"`0$`$P```#(* MS`;K`0@```!'87)F:65L9!\`%@`0``T`"P`6``L`&0`$````+@$!``0````" M`0(`!`````(!`@`0````)@8/`!8`_____P``!OK__ZL$``"I^O__+`4```D` M``#Z`@``!``````GGP`B``0````M`00`!````"T!```'````&`0H!:7ZK@0) M^@0````M`0(`!````/`!!``$````+0$```@````F!@\`!@#_____`0`0```` M)@8/`!8`_____P``%@```!8%``#>````'04```D```#Z`@``!``````GGP`B M``0````M`00`!````"T!`P`(````)0,"`!D`&07:`!D%!````"T!`@`$```` M\`$$``0````M`0``"````"8&#P`&`/____\!``0````M`0,`!````"T!`0`' M````&P1F!:$`&045``0````M`0``!````"T!`@`%````"0(````"!0```!0" M``````4````)`@````(%````%`(`````!````"X!&``$`````@$!``\````R M"DX%,@`%````16QL:7,`&P`+``L`"P`6``0````N`0$`!`````(!`@`$```` M`@$"``0````M`0,`!````"T!`0`'````&P3_`:P!J0&L``0````M`0``!``` M`"T!`@`%````"0(````"!0```!0"`````!````#[`M#_````````O`(````` M````(D%R:6%L`$YE!````"T!!``$````\`$&``4````)`@````(%````%`(` M````!````"X!&``$`````@$!`!(````R"N8!R``'````5&%L8F5R=``>`!H` M#@`=`!L`$@`0``0````N`0$`!`````(!`@`$`````@$"`!`````F!@\`%@#_ M____``"T````Y0```"X!``"L`0``"0```/H"```$`````">?`"(`!````"T! M!@`$````+0$```<````;!)T!'P'U`,0`!````"T!`@`$````\`$&``0````M M`0``"````"8&#P`&`/____\!`!`````F!@\`%@#_____``#*````$P,``$T! M``#\`P``"0```/H"```$`````">?`"(`!````"T!!@`$````+0$```<````; M!.T#/@$C`]H`!````"T!`@`$````\`$&``0````M`0``"````"8&#P`&`/__ M__\!`!`````F!@\`%@#_____```V````;0(``+D```#\`P``"0```/H"```$ M`````">?`"(`!````"T!!@`$````+0$```<````;!.T#J@!]`D8`!````"T! M`@`$````\`$&``0````M`0``"````"8&#P`&`/____\!`!`````F!@\`%@#_ M____``#+`0``Z`$``"\"``!G`P``"0```/H"```$`````">?`"(`!````"T! M!@`$````+0$#`"8````E`Q$`*@)B`R$"8`,7`EH##P)1`P8"10/^`34#]P$B M`^\!#`/I`?0"XP':`MX!O0+9`9X"U0%]`M(!6P+0`3<"SP$1`LX!ZP$$```` M+0$"``0```#P`08`!````"T!```(````)@8/``8`_____P$`$````"8&#P`6 M`/____\``+D!```B`@``/@(``/$"```(````)@8/``8`_____P$`!0````D" M`````@4````4`@`````0````^P+8_P``0`M`"[P"``````<``")!?````!````"T! M!@`*````)`,#`)@*3`&'"BL!=PI,`00````M`0(`!````"T!```$````\`$& M``@````F!@\`!@#_____`0`0````)@8/`!8`_____P``:0$``&P$``#*`0`` M6`4```@````F!@\`!@#_____`0`%````"0(````"!0```!0"`````!````#[ M`LC_``","HP*O`(`````!P``(D%R:6%L`*Z!!````"T!!@`$````\`$$``4` M```)`@````(%````%`(`````!````"X!&``$`````@$!`!`````R"HD$A0$& M````175C;&ED)@`B`!\`#P`0`"(`!````"X!`0`$`````@$"``0````"`0(` M$````"8&#P`6`/____\``.\)``!N`P``#PL``'8%```)````^@(```0````` M)Y\`(@`$````+0$$``0````M`0``A@```"0#00#S"6\$\PF)!/4)HP3X";L$ M_`G3!`(*Z00("OX$$`H2!1D*)04B"C4%+0I$!3@*405$"EP%40IE!5X*:P5L M"G`%>@IQ!8@*<`66"FT%I`IG!;$*7@6]"E0%R0I'!=0*.`7>"B@%Z`H6!?`* M`P7W"NX$_@K7!`,+P`0&"Z<$"0N.!`H+=`0*"UH$"`M!!`4+*`0!"Q`$^PKZ M`_0*Y0/M"M$#Y`J_`]L*K@/0"I\#Q0J2`[D*AP.L"GX#GPIX`Y$*=`.#"G(# M=0IS`V<*=P-9"GT#3`J%`T`*CP,T"IP#*0JK`Q\*NP,6"LT##0K@`P8*]0,` M"@P$^@DC!/<)/`3T"54$\PEO!`0````M`0(`!````/`!!``$````+0$```@` M```F!@\`!@#_____`0`%````"0(````"!0```!0"`````!4```#[`H#_``!Z M`WH#O`(`````!P``$E1I;65S($YE=R!2;VUA;@`A``0````M`00`!````/`! M!@`%````"0(````"!0```!0"``````0````N`1@`!`````(!`0`/````,@I= M!:D*!0```$Y/4E1(`%T`8P!=`%4`9``$````+@$!``0````"`0(`!`````(! M`@`$````+0$#``0````M`0$`!P```!L$#056"7T$5`@$````+0$```0````M M`0(`!0````D"`````@4````4`@`````0````^P+0_P```````+P"`0`````` M`")!`"``'0`$```` M+@$!``0````"`0(`!`````(!`@`$````+0$#``0````M`0$`!P```!L$L@?4 M"G4&:@@$````+0$```0````M`0(`!0````D"`````@4````4`@`````%```` M"0(````"!0```!0"``````0````N`1@`!`````(!`0`,````,@JR!H<(`P`` M`%)E9``C`!H`'@`$````+@$!``0````"`0(`!0````D"`````@4````4`@`` M```$````+@$8``0````"`0$`%@```#(*[`:'"`H```!,:6]N($AO=&5L'@`- M`!X`'0`.`"(`'@`0`!H`#@`$````+@$!``0````"`0(`!0````D"`````@4` M```4`@`````$````+@$8``0````"`0$`&````#(*)0>'"`L```!$3R!.3U0@ M5T%,2P`C`"4`#@`B`"8`'0`.`"T`(P`=`",`!````"X!`0`$`````@$"``4` M```)`@````(%````%`(`````!````"X!&``$`````@$!`!L````R"E\'AP@- M````2&%V92!T;R!G;R!O;@`C`!H`&P`:``X`$``=``X`'0`>``T`'@`=``0` M```N`0$`!`````(!`@`%````"0(````"!0```!0"``````0````N`1@`!``` M``(!`0`6````,@I?!\4)"@```"!O=F5R8W)O2$`'@`:`!L` M$@`.`!``$@`;`!H`)@`:`!L`$``$````+@$!``0````"`0(`!`````(!`@`$ M````+0$!``0````M`0,`$````/L"$``'``````"\`@`````!`@(B4WES=&5M M`&X$````+0$$``0```#P`08`#P```"8&#P`4`%1.4%`$``P````````````` M````"0```"8&#P`(`/____\!`````P`````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````$`0P!O`&T`<`!/`&(`:@`````````````````````````````` M```````````````````````````````````2``(!________________```` M````````````````````````````````````````````'0```'L````````` M`P!/`&(`:@!)`&X`9@!O```````````````````````````````````````` M`````````````````````````!(``@$+````#P```/____\````````````` M```````````````````````````````````?````!`````````!0`&D`8P!T M`'4`<@!E`',````````````````````````````````````````````````` M````````````````$@`"`?_______________P`````````````````````` M`````````````````````````&4````#,0```````$,`=0!R`'(`90!N`'0` M(`!5`',`90!R```````````````````````````````````````````````` M```````:``(!#@```!$```#_____```````````````````````````````` M````````````````(````"P``````````&X>\-$)``#6!>!4LJ-*=4#=3#AH MPE&/_XE03D<-"AH*````#4E(1%(```)#````<0@#````X#/OD@(?V!&T(&,7J2/,ZUECK\`'=@0MR-A5ZLCR MFO;8*E":(VA!QJY21Y;7M,=6@=(<00LR=IDZHKRN17:*E&8(6I"QZ]21Y+5M MLE&H-%W0@HQ=J(X@KV^5?6*ER8(69.Q*=>1XC;ML$RQ-%;0@8Y>J(\;K7&:7 M:&FBH`49>V]/HV,%[L0]#CCVWIY&QPKA\_;L!,)TLEV!2W(6*#(?!TV;\=2($@G.V$"Z8T) MHEE+J=SW,77&"'5E6I`Q:\U@UE(L\WE.G3$R527T_@0@1#77!7I%03K9&W=] M?P(0HAKL`KVB()WLC;N^/P$(44UV@5Y1D$[VQEW?GP"$J$:[0*\H2"=[XZ[O M3S#2-#58LOM>G_QZ"="]!:`%2185OQ[(`^C8L M7-$&XD0+,K9E"4JB<"^2NY:QS3IDR&N\8 M+$;9Y2Z%DVT@3K0@8[&JS[:1B0=@*4G,7@<=AVLH#=C#Z0(Q$+VKCL`-Y>P= MTD&X6]U0,&"T#O>&DOY)U@UO*!OQ.C<4#1!$S0T18@IKW5#`_V^.=N\;"B3\ MCFPYS6*$A/T#,P:ZXPT%`OY@YL#R#47<'Z`ISAUO*)#O)W2D*O,FYY M0U7[U8.F.GIN2-VK-EP42BZH9E%INV8.GC35P8#5EK2UYH:>B!5G%J&K#@3D MSM9>PE?C7PG4OSPC%U MK[FA!R*WEAUA-?.."$>\3PV>ZP5JK'0,FD,X2Z"G1.Q!B-?(\#H`;UIH; M>DA@A$0/$T&?Y@EPPUYS0_\3&"'1PT"(FI"MO]?H./J&LP-\1E'+*M1H>'J&LP- M\1E'+*O3H>[J&LP-T1FKB)$L>$(?<4-S1.\1NZ"YH=&QV`7]FAM2>P`[GO': M]YK?0_\3]*6$68TE3WC=:\T-/21HC,FR.EN>\)K7FAMZ2-"9T^2#-8]YS6O- M#3TFD(.R5S*^4.4K'AX4]YH;>DB@)H6/1'JM2\G8VVMNZ"&!F)6^4-CU,E_P M"J/*7G-#CPFDM'B^3-;:_,DK#=?W:OT3/\KNF4`Z3*#DY=,UKEZGX/S"OS)< MX18%HU_GA@J?"8\7LJ;Z%*R?W]3@MURUNS>\BG+\<*X$K/0G6!! MQB*EK+;17XK1G+=:N#CP\V\H^T/1>JQNOF$OD9SEX8"2!1E+=.+_7DBO;A:G MQ<+L).O:-Q1L),$(\F)[B7R=_*&Z:QW=:]VDIJ3NH]%H-!J-1J/1 M:#0R]`^O$>BN0N^1!@````!)14Y$KD)@@F`A&_`B)P``5F_TBC4%#PO3'O+6 MX-D^%^#[!P```````````,H(``!\"0``$*5H`*CF<`#P)@```/YXG.V=/^_\ M.%Z`_=O=@UL=$'0"RM-60',U-1(M%`B)&L&==,6QTAT2#2^!XM[6(6I:WD(D M2H3")+83)Q-GXL1V/K:?9W\[W\P_QY-G[-B?>.POZENEOO[O__M:?:7^XG6K MU!^]_O_3W^G43]3PXIOI_M]__ZM_^@/UU[_XQU]]_^OO?_XOWXWW?_!Z_$=? MO6[4N/5[7_W;M__QP]]_;?WO]-B*+^JOOGG]^>D7I<:_7WWYHOYX>N5_#?H% MO_DRWKZ>^_'?_>*7/_OU=W_SLW_][F^__^4__+/Z]]_H=WZ9]O+ME/:8RY^H MWWW=_LDWXU[?'_OMYK$?OQX;7_G;']J\ZJTE_^XG^<$W__/U\MAX5/[R1]^I M_U3CX].KS-\_?_T_;OW@F_$C?O/VL?_P[9%P!HA(S_%L%MRW"^[;!??M@OMV M*67\$4YQZB@?MVP7V[X+Y=<-\NN&\7W+=+J^Y? M'[OOQH__NC%;ZK6M!XCH02)J>F9ZKM//ZL>4?M7XQ.H!G=C\G-JDJW>KYAT. M\ZN4?NGK5=.KY_?HY-.-6&GE$>ZXMZ+MV\RK-@_HQ.;GU#K=^>5J MV+B?GK/N._-O3MID)@7-N5_$+L=YXU[9XASF7B[Y7 M[@/S&5UWVP[*O.^\%M M]&_VE>A0M.;><**/][KM`MW/FTLUO^=>V8[$<,H];;VX*$?>>YUO5!OWWG;^ MF>^3>C>FZ[<(4M.H><-\RN&\7W+<+[ML%]^V"^W;!?;O@ MOEUPWRZX;Y?2W#/'7CQ*<]\_G8&**,T]Q*,X]Z7E5S#%N8=HE.:>\WT\2G,/ M\2C-?4?!CT9I[B$>N&^7TMQ3Y\>C-/<0#]RW"^[;!??M@OMVP7V[X+Y=<-\N MK;I70[],P6%_EL'+O3+4V MN-.N]'I>3+_[95.Y:91U,)MS;\_ATV2&Z[FL7/?V3&[/_,/R-5C5$L-J_J6R M#F9I[F^WI>R\FMJ]J>:=F5=3";==^9 M_]?N[;E"^78IS7UI^!5.<>X@& M[ML%]^V"^W;!?;O@OEUPWQK]?)D9]ZW1SV'GQ7U)D6BX3C^/+^F7+P'NVV"^ MWC2[+^H*%-Q@+OB]VCP`U6.+>6__4.R;P99SX[ZL`:9P#U/0>W-+L6\(4_![ M.];HX>Q`3K3O7M]0XS>%%J['F%+L&\.,.Z78-\BDO%<4^Q91TX_2*/8M,DKO M%?V[)GE9[Q5AG2:9Q%/LVP3U[4*-WS`4^P?H990V^G3FJ%7E'6EZ.RH`Z'\XC[TC+ MRU&MR#O2\G)4*_*.]*,YTNM$F+6"QO4C5,5S%.-^A3+K@\S+`>$^)T^[GU:% MU&N"X#XS#[OO MD9:7HV-*R^^"O)S+R]$QI>5W05[.Y>7HF-+RNR`OY_)R=(R4_(:W2J7D?$%> MCHXI+;\+\G(N+T?'E);?!7DYEY>C8\3DE]A.=DK+[X*\G.?.T=W(G;PC>!9Y M.<=]+N3E'/>YD)=SW.="7LYQGPMY.<=]+N3E'/>YD)=SW.="7LYQGPMY.<=] M+N3E'/>YD)=SW.="7LYQGPMY.4^5(Y]CW,L!][F0EW/SG&?"WDYQWTN MY.4<][F0EW/SG&?"WDYQWTNY.4<][F0E_,FW(M891OW#[C7\S<]OLXV M[O.[M^]X^M@_O?]WZG<_OR%\2;NHX#Z[>\?XLP^( MGY7Y]?S4[I[UZI\[T(<=^OW_7DXNMT?M[GOW78\>?=S7X9 MI^NC?O>,S_?1@'M^E^.A"??Y&8<,9.3:0<%]$C*[AU@D^CJD^];R38O&F]FINBN)=##O=3<$5'6'`OB`SN>[?(XSX"NAI] MW8R#4%__QKL7#FP&]YV[48O[\,\1T_WX;](^BI_LRW3?K[9J<1].7/>3]O&F M[RY7J.G=.SOHGSE=7QB:S`_9;XYWMENG>3=]6+N;J$^RW1W=].-)-[4R/A/@IJ/KXEN*?SOEM1B[DY1SWN9"7<]SG0E[.<9\+>3G'?2[DY1SW MN9"7<]SG0E[.*W4?>1:2&`<)][B7`^YQ'YO'W=_JG#^!+@/`O=;<(][.>#^!+@/`O=;<(][.;3K M/N"3XSX(W-_87R9P?P+^<5]$`6X M5W:!J3'-PW09GQ]$`>[-(D/33;#[<'#_L/OI][D#[B=:<]_I:A[W0W/NAV75 M:-RWZKYSW2O[.(Z+BLX-+.M_T\'WOM_%/96.\Y^"V):=5]K]S^_8=Y M52CW04AU[_-(G1\/T>YWG@QV3VS'BUCWGD5[*/?Q$.O^"K@/HBSW'UZ-^R#* MOD\!X'L!]="2Y M'X[<]\J<#LSEW+V+.K@/H@#W7==/HS:4VM0,[YG&?0CRW4\7\97.$^YC(LV] M&:1A;X;9_7B^GT;Q+6,YWC.-^Q#$N3>#-,S-,(_>>E7YG78_C^5XSS3N0Q#G M?OOFWO;H3X#[('#_EB7$^B&3NSR7`V(T3X/X$N`\"]UMPCWLY MX/X$N`\"]UMPCWLYX/X$N`\BE?N3">#^!+@_LT_ZG>?3"XS^0^.9SO_=3N/ASM9#] MU.X^'-SC7@ZXOP9UOI_:W8>#>]S+`?>YP#WNY8#[7.`>]W+`?2YPCWLYX#X7 MN,>]''"?"]SC7@ZXSP7N:W'/^'P_M;L/!_>YWZ)[7B1X_Z!3E[<'P%#)'#?+KAO%]RW2Q;W MNPAOZ_7Q#HZ8MIZ8@+YL]S&+A2#W0HZY:/=QIA2RB04^?CMA'VV[/SQ:2X[B M'B3<;WG$_>%.YR[M#$D/U+\1W4^*N[7[N1(86VYCXTWI5QX<+[,D] MLJ\]S%&"N*=,]XOR_)5^)/=C2?:4>V5O)O=38_"S^P1=8)GNE\^9O^#'=F_; M>N,Y0*W=F^_&J7*?H-DKR?WRZ74E-Q65N_D()E9;3UGW3A]/C0V_7M],?_2) M7LT-`6^.4D0=Y+K71:%<]_U<[B=TG3^VZZ?(A2WHK^^`;A1^<)\BZBG2?:\3 MF(Y.]A-^0O_2!)IQOR5V3%?I:^XW!B/A/A[W:O/W^>:Z*\WT+[MWWJ!B9N`+N'W5>PF$7Z#Y1CG"_!?>XET,+[F5,NX)[W,L! M][G`_3/N)73P<8][.>`^%[A_Q+V(H"[N<2\'W.<"]P^Y%W#<<5^+^SK&YZ=) MMW;W%S(A(`]KFG`O(K"'>]S+`?>YP/U#[@5T\G!?B_L+/PO$?:J$C]]$N=^A M#?<2`GNXK\8]L1TOU;L/SP/N4R5\B(3`'NZ]ZOI/*UAW'Q(X`O=[X#X7N/>[ M_Y"1_HY["8$]W.->#KC/!>Z?ZGS(PK=ZE.C^YP\3..;YX`[N3Y[O]Y\_3.`8W+\CR[UMYWN>/TS@&-R_ M(\K]$3?=/Q_G=O=5K(>+^TS@_C'WL0-[U/E> MJG<[_U<=*\OW*LIQ-=WO=YRGK_C_N%CC_MC]]-0K2FDK\:7 M*C-V:W[^*($/1'9?Q5K(HMQ/8_2,]NFE8MU?R`#N#S/RYEY%<_]X8`_WG\=J M:NW]5.,K-0AU3YWOYZ[[R;OJ!JGNP\']:?>FXH_H_N$./NY/N$_3SL?]&Z+< MF]_BF/Y]I^M]%:=_C_LW)+K??<=M]T\'=7%_(K:S_P[<1T>6>^#^V8./>]S+`?>YP/US[I\.[.$>]W+`?2YP_Z3[F)T\QN?[J=U].+C' MO1QDN9_Z8>:F[\Q-MSQ_E,!''@[LX?[3M9QEP);2XS9QGPQ1[GLS[\8RO2+N M$R+*_3"D=1_QLX9G`_>UN+^P>]Q_R(@:<)\+6>Y'/+>_T[!OW*Z2Y7^7'G6SO MHWOEUAC[^WZTDX?[$[$=]\5![IV6POZ^<;]"EOM-4_RC^W'TONIP?PU9[@_P MN)\C`B?AM.7^R<./^]C7[_6E7MW(U^U\Y=T'[M=4X;Y3 M=JT-<\>3!.Y7E.Y^.8>?.)GC?@7NZ?#.SAOA;WG._]9.OC]]S+H3WW<3XPX_/]U.X^'-SC7@ZMN7\N MN(-[W,L!]W'Y."TPR.'B5\'W%<1]062KB:GS4];YI][T6%`7]\^X=X@5V".V MXZ5Z]^$[QGVJA,]2NOOIG*4ZLQQDK]=^GQ[3QV9LP9S\B`VZ?ZC\Q3G29M'7 MWG4_/6;<3P_@?I_"W4^&EQNK>EH3M+=%'O?[%.Y^\+KONK['_8<$ZG2OQK/^ M>*/:K/-/?9C2W9OFG<_]T.CY_E0;OG#W2@T>]\[VN5W5Y=[Y@98_@8;': M^8-UKUO\IIVOM\W6R8]8E_OQ4MXG_66[MVVYE_M^;-R//?WQ(YF9Y+5W=2Z( M49_[X?*WW<&W"?"]PG=_^YTL>]H3[W M'PO^0X$]W.->#E6YUWSZ1+@W5.C^4\%_*+"'>]S+H4+WGRI]W!MJ=/^AX#\4 MV,,][N50H_L/E3[N#56Z_U#P<:_!_<5L!'\0W.?Y7<[QAXKAGO5P_3SK_MC, M,X$]W%?CGCK?R[/N)8[0QWTF]X<%/T9@C_.]G]K=AX/[3.X/*_T8P1W60O93 MN_MP<)_+_5&QQ+VF5O>'!9\Z?P+WNX/"OXC@3WXEP/N+Z;`6$TOPMT_T,G#?53WX_8XFW`W-M^F)Z96G'GXM:%ONW[K&O[M2M);-R_?X5[M\IVWVG:_EQG[C.[5\/\@`ON1\IV;T_U9E5`IYVO&WJCX[UV?@3WQ':\Y'9O;$[+ M`>NS^^2^TTV^MSX=Y7XHW?V^0_T2VY[;_82X'W"?#]Q'=K\[+LM8-Y]LWWW^ M#C[N95S+P?T([G.!>R'N'PCJXA[WSG@/A>XE^(^?V`/][B70[ON[E@/M[E@/MJI;K"3CS7M/G-PYT'WRMST\R;NLR+!?6>GH<3]#8JJ\W&_(7=`_]'S/>Y7 M-.1^FD@<]PMMN%=VAME!M^ZM>Y4P1R6XSROC\?.]B1\$@?9[%SC]AV)OEFW=\/ MZO;S2@UNS,1L3^=4W;Z:U^_(#^X]*45P_]YWTM^&I4\]#+C_\/CMA"^DE,2] MJ?`=]_V#[@]IV?W=I/;U_!'[N>>-.ZK]<+<6](/>W`WNFW+O%7+?UE@;?O(@;[NMQK]1\ON_5JG^O'S'NQW[> MM$[70_W[0W!_(X'N+3O3X7Q/EW)_]/CMA,.Y'=CKWPLS[H=&W*NWYB+NAS;< M!^X.]ZD2OI(4[I-0N_OP;."^%O?AX%Z4^ZRCMG!?C?O@]^*^&O?!X%Z2^[PC M=7&/>SFT[3ZG#MSC7@ZXSP7N);G/&]S!/>[E@/MEZPL]SD[>>VX+Z/< MXSX%N-^">U'NLP;V<(][.>`^%[@7YCZC#]SC7@ZXSP7N1;G/&MC#/>[E@/M< MX%Z8^XR=/-SC7@ZXSP7N9;G/&=C#/>[E@/M`^%[B7Y?YZ M8"^\=XC[6MRS'JZ?VMV'@WMI[B\G1YWOI7KWP>"^%O><[_T4XCYC8`_WM;@O M9"WD0W"?"_^15E7@?![?Y[Q["&.[SU8:<5^+^]QU?HH*JODZ7T"Y/P7NHQ\# MW,<']UM*O-&7WZV^L%P,9_RM[YG%7<7R2_^T[O=5[B6;]\ MOM/;E2'-G<]9%><^6R_%.SQKYKN6/?VSN>LXOXB M0?G<69/]K70&N.\[W-\BH_O>KM&JWS47WB'8?3^]49FSO\V&;@I8]^;.YZQ* M]4^G;6_69+_2SG_;M79_G*U2W.<+[N1MYP]S M_WY8UF0/[]^_[_I$#._(O5E#>%H4WL0,SR/$??;Q^<%]O%,O._7L:M>]VGP5 MWCET;YN-;B/B+$+WOU3\<,8R1\E6R!/=PO[7RU=$-#\B#$??B[<.^V\VWA#ZIV MA;B_L"/<#W-LR%P:['3LX6["5\D6V,.]XSYNPE>YZEYR;.,^Z]O3;<7P3WN(\(=7ZNP![N M<7^"E!,C7,M1$+A_VP_N4R5\F5R!O1#W)Q^[E2#NBW%_"]SOL/SH(#FX%^9^ MNI:,^QQ[D^=^^ME*W"3]>SH+[A,EL`;W\7G6_?3C$3U9P/S+X7F2(#M^X/6\ M'BB`HX1O@_LER;^:(L>X' M/3\4[O/L[8FVWG@E0W4K]\,\*YQVGZ63A_M,[J>?>3I]O+'+-Y@;I:-YT_=` M#?9UR<%]KG(_?S+MOE?+/*/*O$3IGX'B/L_>GG+_X=6XS[`WW)\"]S<2L/VY M89@G@CUZ->XS[$W>M9PIR2R=/-SC_@2X3Y3`3I(7TDPZOQ[N$R7PSI7`7M+U M<'&?*(%W\@1U<2_3_86#0)T?N+>*W(?O!?>I$K[!%?><[T/W)M-]GN`.[FMQ MGW0M9/L9S2`#.\Q4/W9JZ3M/@I=S%$3M[L.YYK[7,\WKT67Z.>.[/UKZSI/@ MY1P%49;[')V\B^['>\LDI,L0%/VB94@"[B^F&9YHMCK?7I3L[<"#X1*\G*,@I>\\"5[.41"X?]M)+/<7E.'>BU#WYM1NZWDGMK/[\L\)7L]1$$6Y MSQ+8NWR^GWY)T*UBNOLO_YS@Y1P%@?LM7,O!_0EPGRB!W40S=/)PC_L3X#Y1 M`KN)XC[YWJ2Z#P_LR1Z?O_T9&N[]Y`CJ9G2_7/S0SF;LWM7NG6_ M75>^*/=J^:;;`7>"E="W"_[LNZ=>8ICN-=ISY>N[8=JTKT>N-.K M>=,^/9WONP?=]]TR:DB9>:ECNE<9W(<'=T+?<*_8[N9JG..;Y7G_[6W2_M/--O?#W9*T/5L ML:I79A3OJUKH[)^4_7ME=ZXGGU^YG\OKX]W>>XBCNW]^6T'WR3MZUME[G] MA;7UG-?C_A9QVWIJ\^[([@_V?32X3)>!)%O>)]R;7??K`'NYQ?P+<)TI@G_3!'=SC_@2X3Y3`/KA/O3>Y M[M,'=W"/^Q.HZ-S-41"XWX)[N>Y3=_)2'>GKX-ZFB_M8X'X+[L6Z3Q[8PSWN MY8![`^ZC4:#[Q&YPCWLYX-X0Z#[I_'J9P/V<<-"12+H>;B9P/R=,G1^)ZMU3 MYWLIT'WB3A[N:W'/^=Y/[>[#P;U<]V&!O:1K(6<"]Y;405W$!?:H M\_W4[OY"^KA/E?!M#KA?4L9] M'`ITGSBPAWO[E@/N9(/>,S_=3H/O$@3W2 MQGT4BG2?M).'>]S+`?=.T@%IAV<#]Y+=IPWLX1[WXEP/NW;1Q'X,BW2<-[.$>]W+` MO0/NHU"H^X1^<(][.>#>`?=1*-)]TL`>[G$O!]RO$L=]!`IUGW)T`.Y3)1P% MW,<`]UMP+]M]RL`>[G$O!]R[X#X&I;I/)PCWN)<#[EUP'X,RW:<,[.$>]W+` M_3IUW-^G5/?IDL=]+>Z97\]/[>Y9#]=/H>X3!O9P7XU[ZGPOU;L/3QKWJ1*. MP^G`'N=[/[6[OY`T[E,E'(?3[ED+V4^A[A,&]G"/>SG@?I,\=?YMBG6?+'W< MXUX.N-\DC_O;E.H^76`/][B7`^[7I`OLX1[W]''"_ M31_W=RG7?:H=X![W]W+`_0;XEP/NWW9P[H@0V_%2L/M$>\`][N6`^[<=X/XF MY;I/%=C#/>[E@/LMN+]+R>[3'!+#^#=S?I&CW28X)[G$O!]R_@?N; M%.P^46`/][B7`^YW=H'[6Q3M/LD^<(][.>!^9Q>XOT7)[M,$]G"/>SG@_ITT MP1W^?7\U.Z>]7#]E.P^37`']]6XI\[W4KW[8'!?AOO/.^%\[Z=V]^'@ MOA;WK(7LIVCW20)[N,>]''"_PPGW'^I\!4]RXTM]/Z#_](>'6]RT_P9U?IXZ M'_=GJ-/][9TD."JXQ_T=U-"/Z;P:,VIJE*@IW>E6O1X?_[W^GMT3[G=W(MJ] MMJRF_ZQ[-3A+L)8[[T>QD>;QY=V]OLN5H/Y=AC]].."IEN!]K^K%1 MBON8B'7_*N1CQ=Y9]]TPX#XN*8*Z$=V/C3V=G-+G>-S'0ZQ[96*.YGQOW'<; M]R=SC_L]9+M?VOFZH3>>H<8GYB_`R6X*[O=(,4(_BOMN^G^*.DYYU.ZG)M]K ML[.%_USV<;_'9_?/C,\W[C>/3'\OI(_[/<26^[=T<'^=TMW'WPWN:W$?G@WJGW:#^\L4[Y[?XUT&]UMPCWLYX'Z? M^)T\W.->#KC?!_?7*=U]_!,^[G$O!]S[]H/[JQ3O/OH5?-SC7@ZX]X#[R^#^ M+4'K@H$ZOR0XW[=+'/?]7%G@ M/CZI.GU1W$_"U;()48E[3)=R&L.]R9MRMB$F,0N^4TYC7,CKG+^.>SL9HIX; M=YPA-5O(JC(B'C:WG!Z[/_7-Z-V-Q?TT]>DT+:8SZ_VE_+9+KQ?#FN:75%0-E,)WW>_+J>W=?2+\'YSOL?] M37HS?ZPI\O?==^[6!_ZM)L3E3D% M0`C3*@*ZNE?J_!)!_O2&83#K:7YT?^9\[WXAN_=V_K#4^2K)ZDPUX[@/62[" M2SVN+K?N[AZ\;]%(4>OOX(NZ'M9!M M>G/!7Y_L!]._[Z:NRE0-)%E[NUXF]_8+H&Z/MC`V300VPN`-)UBP=3^?X(GV M76.NZ;7WL\M%>)/3?]*[-[$=LWUS)XW2=U$/W<;]NTE^J3`@G,?$=*,EYR89R;W39P3!K"ZXQ'+_O@D"B>Y^'2,& MP6S=QTDQ7FJ0D,X9MA.GH':;OR"5SK-]'7,*?;Y;3@ZH-V.0```"Q\\VH9_-F7_;]???FBQK\_ M_:+4U]-D+3__R/\#RLO@DP`````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`/8/)````!0```!?P)'CI$T```P`]`,#`&(`3F%N8WD@0V]T=&5R"``````` M````````````````````````_O\```0``@```````````````````````0`` M``+5S=6<+AL0DY<(`"LL^:XP````#`(```\````!````@`````,```"(```` M!````*P````&````M`````<```"\````"````,0````)````S`````H```#4 M````%P```-P````+````Y````!````#L````$P```/0````6````_`````T` M```$`0``#````*L!```"````Y`0``!X````9````3&5T=&5R(%!A<&5R("@X M+C5X,3$@:6XI`%-L:0,```#+?@```P```"H````#`````P````,````````` M`P`````````#``````````,```!J$`@`"P`````````+``````````L````` M````"P`````````>$```"0```!````!4:6UE7!E($-O0!)`&X`9@!O`'(`;0!A M`'0`:0!O`&X````````````````````````````````````H``(`________ M________````````````````````````````````````````````````@0`` M```T````````4`!O`'<`90!R`%``;P!I`&X`=``@`$0`;P!C`'4`;0!E`&X` M=````````````````````````````````````"@``@$0````$@```/____\` M``````````````````````````````````````````````";````R$T````` M```%`$0`;P!C`'4`;0!E`&X`=`!3`'4`;0!M`&$`<@!Y`$D`;@!F`&\`<@!M M`&$`=`!I`&\`;@``````````````.``"`/_______________P`````````` M`````````````````````````````````````"$````\`@```````%\`.0`V M`#0`-``T`#4`-P`Q`#@````````````````````````````````````````` M```````````````````6``$`__________\7````$(V!9)M/SQ&&Z@"J`+DI MZ`````"@&*O6&=V]`6"JS-89W;T!````````````````_?___X(```"#```` MA````(4```"&````AP```(@```")````B@```(L```",````C0```(X```"/ M````D````)$```"2````DP```)0```"5````E@```)<```"8````F0```)H` M``#^____G````)T```">````GP```*````"A````H@```*,```"D````I0`` M`*8```"G````J````*D```"J````JP```*P```"M````K@```*\```"P```` ML0```+(```"S````M````+4```"V````MP```+@```"Y````N@```+L```"\ M````O0```+X```"_````P````,$```#^____8@$```P!``#]____Q@```,<` M``#(````R0```,H```#+````S````,T```#.````SP```-````#1````T@`` M`-,```#4````U0```-8```#7````V````-D```#:````VP```-P```#=```` MW@```-\```#@````X0```.(```#C````Y````.4```#F````YP```.@```#I M````Z@```.L```#L````[0```.X```#O````\````/$```#R````\P```/0` M``#U````]@```/<```#X````^0```/H```#[````_````/T```#^````_P`` M```!``#^_P``!``"```````````````````````!````X(6?\OE/:!"KD0@` M*R>SV3````#0,P``$0````$```"0`````@```)@````#````Q`````0```#T M````!0````@!```&````%`$```<````@`0``"````$`!```)````6`$``!(` M``!D`0``"@```(@!```+````E`$```P```"@`0``#0```*P!```.````N`$` M``\```#``0``$0```,@!```"````Y`0``!X````C````0V]S=&$@365S82!- M87`@9F]R(%=A=&5R;6%R:R!C;&%S0``'@````D```!N(&-O='1E<@`@ M9F\>````!````&UA<``>`````0````!A<``>````&````&,Z7'!O=V5R<&YT M7&1E9F%U;'0N<'!T`!X````-````3F%N8WD@0V]T=&5R`&5F81X````"```` M,@!N8QX````9````36EC'``````````H````F!@\`"@!43E!0```"`/0#"0```"8& M#P`(`/____\#````#P```"8&#P`4`%1.4%`$``P``0````$`````````!0`` M``L"``````4````,`LH"N@,$````!`$-``<```#\`@``____````!````"T! M```)````^@(%``````#___\`(@`$````+0$!``0````M`0``"0```!T&(0#P M`-`"P`,`````!````"T!```$````+0$```D```#Z`@`````````````B``0` M```M`0(`!P```/P"`0`````````$````+0$#``0````M`0$`!P```!L$J0`1 M`X@`L``$````+0$```0````M`0(`!````"T!`P`$````+0$!``<````;!!8! ML0*U`!`!!````"T!```$````+0$"``0````M`0,`!````"T!`0`'````&P0Q M`4D#$`%X``0````M`0``!````"T!`@`$````+0$#``0````M`0$`!P```!L$ M;P'7`DX!%@`$````+0$```0````M`0(`!````"T!`P`$````+0$!``<````; M!-,!D0&H`2@`!````"T!```$````+0$"``T```#[`@`````````````````` M````````!````"T!!``%````"0(````"!0```!0"``````0````"`0(`$``` M`"8&#P`6`/____\```D```!"````70,``$8````)````^@(```$`````)Y\` M(@`$````+0$%``0````M`0,`"````"4#`@`*`$,`6P-$``0````M`0(`!``` M`/`!!0`$````+0$```@````F!@\`!@#_____`0`0````)@8/`!8`_____P`` M%@```*`````I`P``I`````D```#Z`@```0`````GGP`B``0````M`04`!``` M`"T!`P`(````)0,"`!<`H0`G`Z(`!````"T!`@`$````\`$%``0````M`0`` M"````"8&#P`&`/____\!`!`````F!@\`%@#_____``"H````;P$``,`#``!T M`0``"0```/H"```!`````">?`"(`!````"T!!0`$````+0$#``@````E`P(` MJ0!R`;X#<`$$````+0$"``0```#P`04`!````"T!```(````)@8/``8`____ M_P$`$````"8&#P`6`/____\``'@````D````>P```)`"```)````^@(```$` M````)Y\`(@`$````+0$%``0````M`0,`"````"4#`@!Y`"4`>0".`@0````M M`0(`!````/`!!0`$````+0$```@````F!@\`!@#_____`0`0````)@8/`!8` M_____P``?`"(`!````"T!!0`$````+0$#``@` M```E`P(`\@$;`/`!A`($````+0$"``0```#P`04`!````"T!```(````)@8/ M``8`_____P$`$````"8&#P`6`/____\``"@"```?````+`(``(L"```)```` M^@(```$`````)Y\`(@`$````+0$%``0````M`0,`"````"4#`@`J`B``*0*) M`@0````M`0(`!````/`!!0`$````+0$```@````F!@\`!@#_____`0`0```` M)@8/`!8`_____P``T`(``"0```#3`@``D`(```D```#Z`@```0`````GGP`B M``0````M`04`!````"T!`P`(````)0,"`-$")0#1`HX"!````"T!`@`$```` M\`$%``0````M`0``"````"8&#P`&`/____\!`!`````F!@\`%@#_____```& M`P``(@```&,#``!,`@``"0```/H"```!`````">?`"(`!````"T!!0`$```` M+0$#``@````E`P(`80,C``<#2@($````+0$"``0```#P`04`!````"T!```( M````)@8/``8`_____P$`!````"T!`P`$````+0$!``<````;!$4`M0`H`'4` M!````"T!```$````+0$"``4````)`@````(%````%`(`````$````/L"\/\` M``````"\`@`````````B07)I86P`KH$$````+0$%``0```#P`00`!0````D" M`````@4````4`@`````$````+@$8``0````"`0$`$````#(*/`!^``8```!3 M;&%T97(+``0`"0`%``D`!@`$````+@$!``0````"`0(`!`````(!`@`$```` M+0$#``0````M`0$`!P```!L$H`"S`H(`3@($````+0$```0````M`0(`!0`` M``D"`````@4````4`@`````%````"0(````"!0```!0"``````0````N`1@` M!`````(!`0`5````,@J7`%<""0```$UA8T%R=&AU<@`-``D`"0`,``8`!0`* M``H`!@`$````+@$!``0````"`0(`!`````(!`@`$````+0$#``0````M`0$` M!P```!L$0@"P`B4`90($````+0$```0````M`0(`!0````D"`````@4````4 M`@`````%````"0(````"!0```!0"``````0````N`1@`!`````(!`0`0```` M,@HY`&\"!@```%=A`0``)`$```D```#Z`@```0`````GGP`B M``0````M`04`!````"T!`P`(````)0,"`+D`(@'<`2`!!````"T!`@`$```` M\`$%``0````M`0``"````"8&#P`&`/____\!`!`````F!@\`%@#_____``!O M`0```0$``/,!```B`0``"````"8&#P`&`/____\!``4````)`@````(%```` M%`(`````$````/L"\/\```8.!@Z\`@`````'```B07)I86P`KH$$````+0$% M``0```#P`00`!0````D"`````@4````4`@`````$````+@$8``0````"`0$` M&````#(*%@%Z`0L```!,86ME($-E;G1E<@`*``D`"0`(``4`"P`)``H`!0`) M``8`!````"X!`0`$`````@$"``0````"`0(`!````"T!`P`$````+0$!``<` M```;!"4!<@$'`2H!!````"T!```$````+0$"``4````)`@````(%````%`(` M````$````/L"\/\```````"\`@`````````B07)I86P````$````+0$$``0` M``#P`04`!0````D"`````@4````4`@`````$````+@$8``0````"`0$`$``` M`#(*&P$T`08```!38V5N:6,+``D`"``*``4`"0`$````+@$!``0````"`0(` M!`````(!`@`0````)@8/`!8`_____P``)@$``/`````I`0``*@$```D```#Z M`@```0`````GGP`B``0````M`04`!````"T!`P`(````)0,"`"?`"(` M!````"T!!0`$````+0$```<````;!/``7@&X`,T`!````"T!`@`$````\`$% M``0````M`0``"````"8&#P`&`/____\!``0````M`0,`!````"T!`0`'```` M&P3;`&P$$````+0$!``0```#P`04`!P```/P"```````````$````+0$%``H` M```D`P,`]P)\`0(#@@$``W8!!````"T!`@`$````+0$```@````F!@\`!@#_ M____`0`0````)@8/`!8`_____P``S0(``+8!```!`P``N@$```D```#Z`@`` M`0`````GGP`B``0````M`08`!````"T!`P`(````)0,"`,X"MP'_`K@!!``` M`"T!`@`$````\`$&``0````M`0``"````"8&#P`&`/____\!`!`````F!@\` M%@#_____```&`P``;@$```H#``"Y`0``"0```/H"```!`````">?`"(`!``` M`"T!!@`$````+0$#``@````E`P(`!P.W`0@#;P$$````+0$"``0```#P`08` M!````"T!```(````)@8/``8`_____P$`!````"T!`P`$````+0$!``<````; M!)\!`P-]`>("!````"T!```$````+0$"``0````M`0,`!````"T!`0`'```` M&P2J`4<#CP$K`P0````M`0``!````"T!`@`0````)@8/`!8`_____P``50(` M`'T!``#0`@``$`(```D```#Z`@```0`````GGP`B``0````M`08`!````"T! M```'````&P0-`LT"@0%9`@0````M`0(`!````/`!!@`$````+0$```@````F M!@\`!@#_____`0`$````+0$#``0````M`0$`!P```!L$_`'/`L$!E0($```` M+0$```0````M`0(`!0````D"`````@4````4`@`````0````^P+S_P`````` M`+P"`````````")!F$`"0`$``<`!P`'``0````N M`0$`!`````(!`@`$`````@$"``0````M`0,`!````"T!`0`'````&P0D`FH# M"0).`P0````M`0``!````"T!`@`0````)@8/`!8`_____P``_____Q4"``"\ M`P``&P(```0````M`0$`!P```/P"````)Y\````$````+0$$``0````&`0(` M#````"0#!``!`!8"`0`9`KD#&@*Y`Q<"!`````8!`0`$````+0$"``0````M M`0``!````/`!!``(````)@8/``8`_____P$`$````"8&#P`6`/____\``'0! M``#;`0``H@$``!8"```)````^@(```$`````)Y\`(@`$````+0$$``0````M M`0,`%@```"4#"0"?`1,"EP$2`H\!#P*(`0H"@0$#`GP!^P%X`?(!=@'G`74! MW`$$````+0$"``0```#P`00`!````"T!```(````)@8/``8`_____P$`$``` M`"8&#P`6`/____\``%0```!<`@``:`,``%\"```)````^@(```$`````)Y\` M(@`$````+0$$``0````M`0,`"````"4#`@!5`%T"9@-=`@0````M`0(`!``` M`/`!!``$````+0$```@````F!@\`!@#_____`0`$````+0$#``0````M`0$` M!P```!L$80+?`40"GP$$````+0$```0````M`0(`!0````D"`````@4````4 M`@`````0````^P+P_P```````+P"`````````")!6YE"0`*``H`"0`%``\`"0`) M``H`"``$````+@$!``0````"`0(`!0````D"`````@4````4`@`````$```` M+@$8``0````"`0$`$@```#(*1P).`P<```!!:7)P;W)T``P`!``&``H`"@`& M``4`!````"X!`0`$`````@$"``0````"`0(`!````"T!`P`$````+0$!``<` M```;!.,"7`&R`HL`!````"T!```$````+0$"``4````)`@````(%````%`(` M````!0````D"`````@4````4`@`````$````+@$8``0````"`0$`'@```#(* MQP*5``\````J($U!4"!)4R!.3U0@5$\`!@`%``T`#``*``4`!``+``0`#``, M``H`!0`*``P`!````"X!`0`$`````@$"``4````)`@````(%````%`(````` M!````"X!&``$`````@$!``\````R"MH"E0`%````4T-!3$4`"P`+``P`"@`* M``0````N`0$`!`````(!`@`$`````@$"`!`````F!@\`%@#_____``!R`0`` M-`$``)?`"(`!````"T!!``$````+0$#``@````E`P(`/P`W`#\` MH`($````+0$"``0```#P`00`!````"T!```(````)@8/``8`_____P$`$``` M`"8&#P`6`/____\``*8```!;````,@$``*(````)````^@(```$`````)Y\` M(@`$````+0$$``0````M`0``!P```!L$GP`O`5\`J@`$````+0$"``0```#P M`00`!````"T!```(````)@8/``8`_____P$`!````"T!`P`$````+0$!``<` M```;!)T`.@%M`/\`!````"T!```$````+0$"``4````)`@````(%````%`(` M````$````/L"\/\```````"\`@`````````B07)I86P````$````+0$$``0` M``#P`08`!0````D"`````@4````4`@`````$````+@$8``0````"`0$`#P`` M`#(*@0`(`04```!0_[C_Q?\$````+0$"``0```#P`08` M!````"T!```(````)@8/``8`_____P$`$````"8&#P`6`/____\``'`"```/ M`0``T`(``%\!```)````^@(```$`````)Y\`(@`$````+0$&``0````M`0`` M!P```!L$7`'-`A,!=`($````+0$"``0```#P`08`!````"T!```(````)@8/ M``8`_____P$`!````"T!`P`$````+0$!``<````;!$\!U@(5`8X"!````"T! M```$````+0$"``4````)`@````(%````%`(`````$````/L"\_\```````"\ M`@`````````B07)I86P`KH$$````+0$&``0```#P`00`!0````D"`````@4` M```4`@`````$````+@$8``0````"`0$`#P```#(*)@&8`@4```!3;W5T:``) M``@`"``%``@`!````"X!`0`$`````@$"``4````)`@````(%````%`(````` M!````"X!&``$`````@$!``\````R"C8!F`(%````0V]A`00````M`0``!````"T!`@`%```` M"0(````"!0```!0"`````!````#[`O#_````````O`(`````````(D%R:6%L M````!````"T!!``$````\`$&``4````)`@````(%````%`(`````!````"X! M&``$`````@$!``\````R"J<"YP$%````061A;7,`#``)``D`#@`)``0````N M`0$`!`````(!`@`$`````@$"``0````M`0,`!````"T!`0`'````&P2G`0X# MD0'J`@0````M`0``!````"T!`@`0````)@8/`!8`_____P``$P```$\"``#G M````4P(```D```#Z`@```0`````GGP`B``0````M`08`!````"T!`P`(```` M)0,"`!0`4`+E`%$"!````"T!`@`$````\`$&``0````M`0``"````"8&#P`& M`/____\!``0````M`0,`!````"T!`0`'````&P1-`N``,@*:``0````M`0`` M!````"T!`@`%````"0(````"!0```!0"`````!````#[`O/_````````O`(` M````````(D%R:6%L`*Z!!````"T!!@`$````\`$$``4````)`@````(%```` M%`(`````!````"X!&``$`````@$!`!,````R"D0"I``(````1V%R9FEE;&0* M``@`!0`$``0`!P`$``@`!````"X!`0`$`````@$"``0````"`0(`$````"8& M#P`6`/____\```+^__^.`0``.O[__[L!```)````^@(```$`````)Y\`(@`$ M````+0$$``0````M`0``!P```!@$N0$X_H\!`_X$````+0$"``0```#P`00` M!````"T!```(````)@8/``8`_____P$`$````"8&#P`6`/____\```<```"R M`0``2P```+4!```)````^@(```$`````)Y\`(@`$````+0$$``0````M`0,` M"````"4#`@`(`+,!20"S`00````M`0(`!````/`!!``$````+0$```@````F M!@\`!@#_____`0`$````+0$#``0````M`0$`!P```!L$S0$V`+,!!P`$```` M+0$```0````M`0(`!0````D"`````@4````4`@`````%````"0(````"!0`` M`!0"``````0````N`1@`!`````(!`0`/````,@K%`1$`!0```$5L;&ES``D` M!``#``0`!P`$````+@$!``0````"`0(`!`````(!`@`$````+0$#``0````M M`0$`!P```!L$JP"/`(X`.0`$````+0$```0````M`0(`!0````D"`````@4` M```4`@`````0````^P+P_P```````+P"`````````")!`;``&P&M`!?`"(`!````"T!!@`$````+0$# M``@````E`P(`@@-M`(,#(`$$````+0$!``0```#P`08`!P```/P"````)Y\` M```$````+0$&``H````D`P,`B`-O`((#9`!]`V\`!````"T!`@`$````+0$` M``0```#P`08`"````"8&#P`&`/____\!`!`````F!@\`%@#_____``!X```` M>`$``)D```#)`0``"````"8&#P`&`/____\!``4````)`@````(%````%`(` M````$````/L"[?\``(P*C`J\`@`````'```B07)I86P`KH$$````+0$&``0` M``#P`00`!0````D"`````@4````4`@`````$````+@$8``0````"`0$`$``` M`#(*@P&"``8```!%=6-L:60-``L`"@`%``8`"P`$````+@$!``0````"`0(` M!`````(!`@`0````)@8/`!8`_____P``3P,``"0!``"Q`P``TP$```D```#Z M`@```0`````GGP`B``0````M`00`!````"T!``!&````)`,A`%$#>@%2`XL! M5`.;`5@#J@%=`[2$`"@`)``D`!@`$``8`!@`)``@`#0`)``D`!0`$````+@$!``0` M```"`0(`!`````(!`@`$````+0$!``0````M`0,`$````/L"$``'``````"\ M`@`````!`@(B4WES=&5M`&X$````+0$$``0```#P`08`#P```"8&#P`4`%1. M4%`$``P`````````````````"0```"8&#P`(`/____\!`````P``````#P#H M`T$&```!`.D#*````(`6``#@$```X!```(`6```%````"@````(````#```` M`0`!``````$/`/(#-@,``"\`R`_J````,`#2#P0````"``````"Z#R@````8 M(!P@"/\4,#O_6_\(,`HP##`.,!`PY?\$_R0`*`!;`%P`>P!B_^'_$`"Z#Z8` M```!,`(P#/\.__LP&O\;_Q__`?^;,)PP_3#^,)TPGC`%,/PP&2`=(`G_%3`] M_UW_"3`+,`TP#S`1,+``,"`R(#,@`R'@_P7_03!#,$4P1S!),&,P@S"%,(

_Y__#P#5!WP!`````+`S#0!P`&4`(`!#`&\`<@!S`&D`=@!A````8@"LTV(`N,]B`(7>`S#````_Q\` M``4`0`(````````@`2`!0`)``F`#8`.`!(`$``"I#PH````'`````@`)!``` M0`"C#VX````%`/_]/P```"(@``!D`````````&0```````````!``@`````" M````___O``````#_______\8``````$````%```@`2`!```````%``!``D`" M```````%``!@`V`#```````%``"`!(`$``````\`"P18`0``#P``\%`!```` M``;P0`````(<```'````:@````8````!````#P````(````)`````P````,` M```$````4`````4````"````!@````,````O``'P6````&(`!_`D````!@;6 M!>!4LJ-*=4#=3#AHPE&/_P#9"0```0```````````(L`,@`'\"0````#!%9O M](HU!0\+TQ[RUN#9/A?_`"HG```!````V0D`````BP`#`0OP8````(`!"0`` M`($!!```"(,!````"+\!$``0`,`!`">?`,$!```!`,0!`````,L!G#$``,T! M`````,X!`````-`!`````-$!`````-?`/P!*`!``![Q M$`````0```@!```(`@``"/<``!`?`/`/'```````\P,4````!`````0````` M````````@``````/`-`'BP```!\`_P,4`````@``!`P```````````````(` M```/`/H#9P``````_@,#``````$```#]`S0````V````9````#8```!D```` MZ,]B``O?`S#@SV(`"````%H2``#`"0``&/K___3___\!````<`#[`P@````` M````<`@``'``^P,(`````0```$`+```/`/`/5```````\P,4````!0````0` M``````````$``````````/,#%`````8```````````````$!``````````#S M`Q0````'````!``````````"`0````````$``010`````````?___W\````` M```````````````````````````````````````````````````````````` M``````````````````````````$`8@```.H#``````\`^`,@#````@#O`Q@` M```!`````0('"0@`````````````````!3!@`/`'(````/___P``````@("` M````````S)D`,S/,`,S,_P"RLK(`8`#P!R```````/\`____``````#__P`` M_YD```#__P#_````EI:6`&``\`<@````___,``````!F9C,`@(```#.9,P"` M`````#/,`/_,9@!@`/`'(````/___P``````,S,S``````#=W=T`@("``$U- M30#JZNH`8`#P!R````#___\``````("`@```````_\QF````_P#,`,P`P,#` M`&``\`<@````____``````"`@(```````,#`P```9O\`_P````"9``!@`/`' M(````/___P``````@("````````SF?\`F?_,`,P`S`"RLK(```"C#SX````! M`/_]/P```"(@``!D`````````%H```````````!``@`````"````___O``,` M`0#_______\8``````,``!``HP]^````!0#__3\`#P!Q``(`9``````#``!D M`#(```#8````0`(``````@```/__[P`!``$`________%`````#^``#0!0`` M$R`!`%``L`$@`0$``@```!(`0`4``&0`B`+X`0(``@`"``X```4``&`#T`(` M``````4``#@$J`,`````(`"C#X8````%`/_]/P```"(@``!D```````#`%H` M*`````````!``@`````"````___O`````0#_______\*``````$``(D%```) M`!0@D`"0``(````"`(D%`````"(@0`)``@$``0`#`````#T`````9``>`&`# M8`,#``(````,```%``"`!(`$`````%``HP]2````!0````$)```.``$````` M`````0`!"0``#@`!`"`!``````(``0D```X``0#X`0`````#``$)```.``$` MT`(`````!``!"0``#@`!`*@#`````&``HP\,`````0``````````````<`"C M#SX````%`````````````@`2``$``````````@`0``(``````````@`,``,` M`````````@`,``0``````````@`,`(``HP\^````!0````````````(`$``! M``````````(`#@`"``````````(`"@`#``````````(`"@`$``````````(` M"@`/``P$1@@```\``O`^"```$``(\`@````.````#@0```\``_#X"#P`1\!```````,,+"``````````!`(<`#P`-\%0````` M`)\/!````````````*@/(````$-L:6-K('1O(&5D:70@36%S=&5R('1I=&QE M('-T>6QE``"B#P8````A`````````*H/"@```"$````!```````/``3P1@$` M`!(`"O`(````!`0````*```#`0OP8````'\``0`!`(``%"B'`($`>&$!`((` MHJT``(,`>&$!`(0`HJT``+\`$``?`(`!"0```($!!```"(,!````"+\!`0`1 M`,`!`">?`,L!G#$``/\!`0`)``$"`@``"#\"```"````$/`(````>@,(`T$5 M3`X/`!'P$```````PPL(`````0````(`AP`/``WPG@``````GP\$`````0`` M````J`]2````0VQI8VL@=&\@961I="!-87-T97(@=&5X="!S='EL97,-4V5C M;VYD($QE=F5L#51H:7)D($QE=F5L#49O=7)T:"!,979E;`U&:69T:"!,979E M;```H@\>````(0``````#0````$`#`````(`#0````,`#`````0```"J#PH` M``!3`````0``````#P`$\%(```!"`0KP"`````4$````"@``@-\ M`;(">@,/``3P6````$(!"O`(````"@0````*``"#``OP,````(4``@```(<` M`0```+\!```0`,`!````",L!G#$``/\!"``(``$"`@``"#\"```"````$/`( M````\`-\`;0"\`,/``3P6````$(!"O`(````"P0````*``"#``OP,````(4` M`@```(<``0```+\!```0`,`!````",L!G#$``/\!"``(``$"`@``"#\"```" M````$/`(````8@1\`;0"8@0/``3P6````$(!"O`(````#`0````*``"#``OP M,````(4``@```(<``0```+\!```0`,`!````",L!G#$``/\!"``(``$"`@`` M"#\"```"````$/`(````V`1\`;0"V`0/``3P6````$(!"O`(````#00````* M``"#``OP,````(4``@```(<``0```+\!```0`,`!````",L!G#$``/\!"``( M``$"`@``"#\"```"````$/`(````2@5\`;0"2@4/``3PV0```!(`"O`(```` M#@0````*```#`0OP8````(``U"B'`($`>&$!`((`HJT``(,`>&$!`(0`HJT` M`(4``@```+\`$@`?`(`!"0```($!!```"(,!````"+\!```0`,`!`">?`,L! MG#$``/\!```(``$"`@``"#\"```"````$/`(````:P^]"J,,%A`/``WP20`` M````GP\$````!```````J`\!````*@``H0\<`````@````````````(````! M``<``0`!``P`````_@``]P\(``````````!]AP`/``3P0@```!(`"O`(```` M`00````,``!S``OP*@```($!````"),!CI^+`)0!WKUH`+\!$@`2`/\!```( M``0#"0```#\#`0`!`!``\`<@````____``````"1D9$`P@```!%/^P#__P`` M?_\``/\`_P`@`+H/%@```&0`90!F`&$`=0!L`'0`+@!P`'``=``/`/`#0P8` M``$`\0,(````````@```"C`/``P$`P8```\``O#[!0``(``(\`@````(```` M"`@```\``_"9!0``#P`$\"@````!``GP$``````````(````@,KX?X#*^'\" M``KP"``````(```%````#P`$\!X!```2``KP"`````((````"@```P$+\&`` M``"``#0IAP"!`!!5`0""`**M``"#`!!5`0"$`**M``"%``(```"_`!(`'P"` M`0D```"!`00```B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(` M``@_`@```@```!#P"````&T57@P[#@T6#P`-\(X``````)\/!`````0````` M`*@/!@```%!A9V4@*@``H0\<````!P```````!@```$`6@`'`````@`#``(` M`0`,````V`\$````!0``````J@\>````!0````$```````$````!```````! M`````0````````"F#Q8```#Q'@``(P(2`1(!(P(C`C4#-0-&!$8$#P`$\'`` M```2``KP"`````,(````"@``@P`+\#````!_``0`!`"'``$```!_`0```0"_ M`0$`$0#``0$```C+`9PQ``#_`0@`"0`_`@$``P```!#P"`````D"```C`A(!$@$C`B,"-0,U`T8$1@0/``3P MW````!(`"O`(````!P@````*```#`0OP8````(``M"J'`($`>&$!`((`HJT` M`(,`>&$!`(0`HJT``(4``@```+\`$@`?`(`!"0```($!!```"(,!````"+\! M```0`,`!`">?`,L!G#$``/\!```(``$"`@``"#\"```"````$/`(````9`V+ M`2<##PX/``WP3```````GP\$````!```````J`\&````3F]T97,Z``"A#Q@` M```'````````````!P````$``P`!``$`#````*H/"@````<````!```````/ M``3P6````$(!"O`(````"`@````*``"#``OP,````(4``@```(<``0```+\! M```0`,`!`0``",L!G#$``/\!"``(``$"`@``"#\"```"````$/`(````6!7* M`5X/6!4/``3P0@```!(`"O`(`````0@````,``!S``OP*@```($!````"),! MWKUH`)0!CI^+`+\!$@`2`/\!```(``0#"0```#\#`0`!`!``\`<@````____ M``````"1D9$``````&&/_0``K@``_`$H`,[.S@`/`,D/R`$```\`#`28`0`` M#P`"\)`!```P``CP"`````(````"#```#P`#\"X!```/``3P*`````$`"?`0 M```````$``,`!``&````!@`#``(`"O`(``````P```4````/``3P]@```!(` M"O`(`````@P````*```#`0OP8````(``%"N'`($`$%4!`((`HJT``(,`$%4! M`(0`HJT``(4``@```+\`$@`?`(`!"0```($!!```"(,!````"+\!```0`,`! M`">?`,L!G#$``/\!```(``$"`@``"#\"```"````$/`(````;Q62!TX)#Q8/ M``WP9@``````GP\$````!```````J`\&````4&%G92`J``"A#QH````'```` M````&````0!:``<````#``(``P`,````V`\$````!0``````I@\6````\1X` M`","$@$2`2,"(P(U`S4#1@1&!`\`!/!"````$@`*\`@````!#`````P``',` M"_`J````@0$````(DP'>O6@`E`&.GXL`OP$2`!(`_P$```@`!`,)````/P,! M``$`$`#P!R````#___\``````)&1D0``````88_]``"N``#\`2@`SL[.``\` M[@-*,````@#O`Q@````0``````````````````"```````8`!3```/D#$``` M`````````````@`!``(````/``P$XB\```\``O#:+P``0``(\`@```!/```` M3Q````\``_!*+P``#P`$\"@````!``GP$``````````````````````````" M``KP"``````0```%````#P`$\&H````2``KP"`````(0````"@``LP`+\$(` M``"%``(```"'``$```"``0D```"!`00```B#`0````B_`0``$`#``0`GGP#+ M`9PQ``#_`0``"``!`@(```@_`@```@```!#P"````#`#(`1@$O`##P`$\&H` M```2``KP"`````,0````"@``LP`+\$(```"%``(```"'``$```"``0D```"! M`00```B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(```@_`@`` M`@```!#P"````#T$8`8@$'T&#P`$\&H````2``KP"`````00````"@``LP`+ M\$(```"%``(```"'``$```"``0D```"!`00```B#`0````B_`0``$`#``0`G MGP#+`9PQ``#_`0``"``!`@(```@_`@```@```!#P"````&`&T`*P$R`'#P`$ M\&H````2``KP"`````40````"@``LP`+\$(```"%``(```"'``$```"``0D` M``"!`00```B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(```@_ M`@```@```!#P"````-0'@0`!$90(#P`$\-,````2``KP"`````80````"@`` M\P`+\%H```"``'0KAP"!`'AA`0""`**M``"#`'AA`0"$`**M``"_`!(`'P"` M`0D```"!`00```B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(` M``@_`@```@```!#P"````/$)\0!?">D*#P`-\$D``````)\/!`````0````` M`*@/`0````L``*$/&@````(````````@```R``(````"``,``@`#``H```"J M#PH````"`````0``````#P`$\%@```!"`0KP"`````<0````"@``@P`+\#`` M``"%``(```"'``$```"_`0``$`#``0`GGP#+`9PQ``#_`0@`"``!`@(```@_ M`@```@```!#P"````)4!.@`@%)8!#P`$\%@```!"`0KP"`````@0````"@`` M@P`+\#````"%``(```"'``$```"_`0``$`#``0`GGP#+`9PQ``#_`0@`"``! M`@(```@_`@```@```!#P"````,D#B`#L$LD##P`$\%@```!"`0KP"`````D0 M``"`"@``@P`+\#````"%``(```"'``$```"_`0``$`#``0`GGP#+`9PQ``#_ M`0@`"``!`@(```@_`@```@```!#P"````)\(]`-T%JH(#P`$\%@```!"`0KP M"`````H0````"@``@P`+\#````"%``(```"'``$```"_`0``$`#``0`GGP#+ M`9PQ``#_`0@`"``!`@(```@_`@```@```!#P"````.$`U0+5`E&$!`((`HJT``(,`>&$!`(0`HJT``(4``@```+\`$@`?`(`!"0`` M`($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```(``$"`@``"#\" M```"````$/`(````VP!>#AH0A@$/``WP.@``````GP\$````!```````J`\& M````5V%R;F5R``"A#Q@````'````````````!P````$``P`!``$`#``/``3P M:@```!(`"O`(````$Q`````*``"S``OP0@```(4``@```(<``0```(`!"0`` M`($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```(``$"`@``"#\" M```"````$/`(````^`.^"V0,D@0/``3PS@```!(`"O`(````%!`````*```# M`0OP8````(``M"V'`($`>&$!`((`HJT``(,`>&$!`(0`HJT``(4``@```+\` M$@`?`(`!"0```($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```( M``$"`@``"#\"```"````$/`(````O0,S$JD4:`0/``WP/@``````GP\$```` M!```````J`\*````-34@1G)E97=A>0``H0\8````"P````````````L````! M``,``0`!``P`#P`$\-$````2``KP"````!40````"@``$P$+\&8````$```` M60"``!0NAP"!`'AA`0""`**M``"#`'AA`0"$`**M``"%``(```"_`!(`'P"` M`0D```"!`00```B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(` M``@_`@```@```!#P"````)<$-Q#B$#D&#P`-\#L``````)\/!`````0````` M`*@/!P```$)R:7-T;VP``*$/&`````@````````````(`````0`#``$``0`, M``\`!/#.````$@`*\`@````6$`````H``!,!"_!F````!````%H`@`!T+H<` M@0!X80$`@@"BK0``@P!X80$`A`"BK0``A0`"````OP`2`!\`@`$)````@0$$ M```(@P$````(OP$``!``P`$`)Y\`RP&<,0``_P$```@``0("```(/P(```(` M```0\`@```"O!1X-R0WU!@\`#?`X``````"?#P0````$``````"H#P0```!" M96%R``"A#Q@````%````````````!0````$``P`!``$`#``/``3PS````!(` M"O`(````%Q`````*```#`0OP8`````0```!9`(``-"^'`($`>&$!`((`HJT` M`(,`>&$!`(0`HJT``+\`$@`?`(`!"0```($!!```"(,!````"+\!```0`,`! M`">?`,L!G#$``/\!```(``$"`@``"#\"```"````$/`(````O02M"U@,6@$`````H` M``,!"_!@````!````%H`@`#T`:$`@0!X80$`@@"BK0``@P!X80$`A`"BK0`` MOP`2`!\`@`$)````@0$$```(@P$````(OP$``!``P`$`)Y\`RP&<,0``_P$` M``@``0("```(/P(```(````0\`@````#`KT`:`&_!`\`#?!0``````"?#P0` M```$``````"H#PH```!"&$!`((`HJT``(,`>&$!`(0`HJT` M`(4``@```+\`$@`?`(`!"0```($!!```"(,!````"+\!```0`,`!`">?`,L! MG#$``/\!```(``$"`@``"#\"```"````$/`(````!PA0!),&L@@/``WP/0`` M````GP\$````!```````J`\)````4W5N9FQO=V5R``"A#Q@````*```````` M````"@````$``P`!``$`#``/``3PR0```!(`"O`(````(!`````*``#S``OP M6@```(``=`.A`($`>&$!`((`HJT``(,`>&$!`(0`HJT``+\`$@`?`(`!"0`` M`($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```(``$"`@``"#\" M```"````$/`(````%@?+$$P3P0````0@$*\`@````A$`````H``),`"_`V````A0`"````AP`!```` MOP$``!``P`$!```(RP&<,0``T0$!````_P$(``@``0("```(/P(```(````0 M\`@```#&!TX1"A(*"0\`!/!8````0@$*\`@````B$`````H``(,`"_`P```` MA0`"````AP`!````OP$``!``P`$`)Y\`RP&<,0``_P$(``@``0("```(/P(` M``(````0\`@```!-"M(0_!%-"@\`!/!8````0@$*\`@````C$```@`H``(,` M"_`P````A0`"````AP`!````OP$``!``P`$`)Y\`RP&<,0``_P$(``@``0(" M```(/P(```(````0\`@```"9""T2+1)("@\`!/!J````$@`*\`@````D$``` M``H``+,`"_!"````A0`"````AP`!````@`$)````@0$$```(@P$````(OP$` M`!``P`$`)Y\`RP&<,0``_P$```@``0("```(/P(```(````0\`@```#L"$P1 M"1*T"0\`!/!J````$@`*\`@````E$`````H``+,`"_!"````A0`"````AP`! M````@`$)````@0$$```(@P$````(OP$``!``P`$`)Y\`RP&<,0``_P$```@` M`0("```(/P(```(````0\`@```!<"0(3HA/V"0\`!/!J````$@`*\`@````F M$`````H``+,`"_!"````A0`"````AP`!````@`$)````@0$$```(@P$````( MOP$0`!``P`$`)Y\`RP&<,0``_P$(``@``0("```(/P(```(````0\`@````$ M"10.RA!*#`\`!/#5````$@`*\`@````G$`````H```,!"_!@````@``T!*$` M@0!X80$`@@"BK0``@P!X80$`A`"BK0``A0`"````OP`2`!\`@`$)````@0$$ M```(@P$````(OP$``!``P`$`)Y\`RP&<,0``_P$```@``0("```(/P(```(` M```0\`@```"'"GX/TQ#?"P\`#?!%``````"?#P0````$``````"H#Q$```!3 M;W5T:`U#;V%S=`U0;&%Z80``H0\8````$@```````````!(````!``,``0`! M``H`#P`$\&H````2``KP"````"@0````"@``LP`+\$(```"%``(```"'``$` M``"``0D```"!`00```B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``! M`@(```@_`@```@```!#P"````#8,U!-T%-`,#P`$\%@```!"`0KP"````"D0 M````"@``@P`+\#````"%``(```"'``$```"_`0``$`#``0`GGP#+`3AC``#_ M`0@`"``!`@(```@_`@```@```!#P"````(T,"`!4%HT,#P`$\``!```R`0KP M"````"H0````"@``(P$+\-@```"%``(```"'``$```!%P4X```!'`0``6@!( M`0``M`!)`6!4``!*`0````!1P1X```"``0D```"!`00```B#`0````B_`0`` M$`#``0`GGP#+`9PQ``#7`0````#_`0@`"``!`@(```@_`@```@`)``P`"``` M````H*O__\"H``!@5```8%0``&!4``````````````````"@J___P*@``&!4 M``!@5```8%0`````````````8%0````````#``0`"`!@5```8%0````````` M````8%0``````````!#P"````"L+P`BX"70,#P`$\%@```!"`0KP"````"L0 M````"@``@P`+\#````"%``(```"'``$```"_`0``$`#``0`GGP#+`9PQ``#_ M`0@`"``!`@(```@_`@```@```!#P"````"X._P%C%"X.#P`$\,D````2``KP M"````"P0````"@```P$+\&````"``)0$H0"!`'AA`0""`**M``"#`'AA`0"$ M`**M``"%``(```"_`!(`'P"``0D```"!`00```B#`0````B_`0``$`#``0`G MGP#+`9PQ``#_`0``"``!`@(```@_`@```@```!#P"````)4-N@DU"T`.#P`- M\#D``````)\/!`````0``````*@/!0```$)A:V5R``"A#Q@````&```````` M````!@````$``P`!``$`#``/``3P:@```!(`"O`(````+1`````*``"S``OP M0@```(4``@```(<``0```(`!"0```($!!```"(,!````"+\!$``0`,`!`">? M`,L!G#$``/\!"``(``$"`@``"#\"```"````$/`(````HPP_$U@6%0X/``3P M:@```!(`"O`(````+A`````*``"S``OP0@```(4``@```(<``0```(`!"0`` M`($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```(``$"`@``"#\" M```"````$/`(````(PX@#,`,O0X/``3PU@```!(`"O`(````+Q`````*```# M`0OP8````(``5`6A`($`>&$!`((`HJT``(,`>&$!`(0`HJT``(4``@```+\` M$@`?`(`!"0```($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```( M``$"`@``"#\"```"````$/`(````O0R;$T,6VPT/``WP1@``````GP\$```` M!```````J`\2````2F]H;B!787EN90U!:7)P;W)T``"A#Q@````3```````` M````$P````$``P`!``$`#``/``3PTP```!(`"O`(````,!`````*``#S``OP M6@```(``%`:A`($`>&$!`((`HJT``(,`>&$!`(0`HJT``+\`$@`?`(`!"0`` M`($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```(``$"`@``"#\" M```"````$/`(````+!!"`R0(2A$/``WP20``````GP\$````!```````J`\5 M````*B!-05`@25,@3D]4(%1/(%-#04Q%``"A#Q@````6````````````%@`` M``$``P`!``$`#``/``3PR@```!(`"O`(````,1`````*```#`0OP8`````0` M``!:`(``=`:A`($`>&$!`((`HJT``(,`>&$!`(0`HJT``+\`$@`?`(`!"0`` M`($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```(``$"`@``"#\" M```"````$/`(````/`>T"(8)<@L/``WP.@``````GP\$````!```````J`\& M````2$%20D]2``"A#Q@````'````````````!P````$``P`!``$`$``/``3P M:@```!(`"O`(````,A`````*``"S``OP0@```(4``@```(<``0```(`!"0`` M`($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\!```(``$"`@``"#\" M```"````$/`(````IP6Z"UH,008/``3P:@```!(`"O`(````,Q`````*``"S M``OP0@```(4``@```(<``0```(`!"0```($!!```"(,!````"+\!```0`,`! M`">?`,L!G#$``/\!```(``$"`@``"#\"```"````$/`(````!A`L#X@3H!`/ M``3P6````$(!"O`(````-!`````*``"#``OP,````(4``@```(<``0```+\! M```0`,`!`">?`,L!G#$``/\!"``(``$"`@``"#\"```"````$/`(````2@%\ M`7P!P`\/``3P:@```!(`"O`(````-1`````*``"S``OP0@```(4``@```(<` M`0```(`!"0```($!!```"(,!````"+\!$``0`,`!`">?`,L!G#$``/\!"``( M``$"`@``"#\"```"````$/`(````.P+]`Q8'M@,/``3PS@```!(`"O`(```` M-A`````*```#`0OP8````(``-`>A`($`>&$!`((`HJT``(,`>&$!`(0`HJT` M`(4``@```+\`$@`?`(`!"0```($!!```"(,!````"+\!```0`,`!`">?`,L! MG#$``/\!```(``$"`@``"#\"```"````$/`(````BP+W!5,'J0,/``WP/@`` M````GP\$````!```````J`\*````4')I8V4-0VQU8@``H0\8````"P`````` M``````L````!``,``0`!``P`#P`$\&H````R``KP"````#<0````"@``LP`+ M\$(```"%``(```"'``$```"``0D```"!`00```B#`0````B_`1``$`#``0`G MGP#+`9PQ``#_`0@`"``!`@(```@_`@```@```!#P"````%'^GOXM_]S^#P`$ M\&H````2``KP"````#@0````"@``LP`+\$(```"%``(```"'``$```"``0D` M``"!`00```B#`0````B_`1``$`#``0`GGP#+`9PQ``#_`0@`"``!`@(```@_ M`@```@```!#P"````',&M@[*$"0(#P`$\-$````2``KP"````#D0````"@`` M\P`+\%H```"``/0'H0"!`'AA`0""`**M``"#`'AA`0"$`**M``"_`!(`'P"` M`0D```"!`00```B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(` M``@_`@```@```!#P"````'L&50_]$-,'#P`-\$<``````)\/!`````0````` M`*@/$P```%-O=71H#4-O87-T#59I;&QA9V4``*$/&````!0````````````4 M`````0`#``$``0`*``\`!/!J````,@`*\`@````Z$`````H``+,`"_!"```` MA0`"````AP`!````@`$)````@0$$```(@P$````(OP$0`!``P`$`)Y\`RP&< M,0``_P$(``@``0("```(/P(```(````0\`@```!K$4+]T?WV$0\`!/!8```` M0@$*\`@````[$`````H``(,`"_`P````A0`"````AP`!````OP$``!``P`$` M)Y\`RP&<,0``_P$(``@``0("```(/P(```(````0\`@```!O#_\!8Q1O#P\` M!/##````$@`*\`@````\$`````H``/,`"_!:````@`!4"*$`@0!X80$`@@"B MK0``@P!X80$`A`"BK0``OP`2`!\`@`$)````@0$$```(@P$````(OP$``!`` MP`$`)Y\`RP&<,0``_P$```@``0("```(/P(```(````0\`@```!O#S(+YPP: M$`\`#?`Y``````"?#P0````$``````"H#P4```!!9&%M1%,$N8) M#P`$\%@```!"`0KP"````#X0````"@``@P`+\#````"%``(```"'``$```"_ M`0``$`#``0`GGP#+`9PQ``#_`0@`"``!`@(```@_`@```@```!#P"````.,- M>0!=!>,-#P`$\,P````2``KP"````#\0````"@```P$+\&````"``!0)H0"! M`'AA`0""`**M``"#`'AA`0"$`**M``"%``(```"_`!(`'P"``0D```"!`00` M``B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(```@_`@```@`` M`!#P"````"X-G`,[!<8-#P`-\#P``````)\/!`````0``````*@/"````$=A M?`,L!G#$``/\!"``(``$"`@``"#\"```" M````$/`(````6PD2]$GU3PH/``3P6````$(!"O`(````01`````*``"#``OP M,````(4``@```(<``0```+\!```0`,`!`">?`,L!G#$``/\!"``(``$"`@`` M"#\"```"````$/`(````,@HQ`+4!,@H/``3PRP```!(`"O`(````0A`````* M```#`0OP8````(``=`FA`($`>&$!`((`HJT``(,`>&$!`(0`HJT``(4``@`` M`+\`$@`?`(`!"0```($!!```"(,!````"+\!```0`,`!`">?`,L!G#$``/\! M```(``$"`@``"#\"```"````$/`(````,0HJ`#\!R0H/``WP.P``````GP\$ M````!```````J`\%````16QL:7,``*$/&@````8````````(```!``8````! M``,``0`!``H`#P`$\-<````2``KP"````$,0````"@``\P`+\%H```"``-0) MH0"!`'AA`0""`**M``"#`'AA`0"$`**M``"_`!(`'P"``0D```"!`00```B# M`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(```@_`@```@```!#P M"````%$#5P%6`_P##P`-\$T``````)\/!`````0``````*@/!P```%1A;&)E MP+9!P\`!/!J````$@`*\`@```!&$`````H``+,`"_!"````A0`" M````AP`!````@`$)````@0$$```(@P$````(OP$0`!``P`$`)Y\`RP&<,0`` M_P$(``@``0("```(/P(```(````0\`@```#Y!(L`4@'9!P\`!/```0``,@$* M\`@```!'$`````H``",!"_#8````A0`"````AP`!````1<%.````1P$``%H` M2`$``+0`20%@5```2@$`````4<$>````@`$)````@0$$```(@P$````(OP$` M`!``P`$`)Y\`RP&<,0``UP$`````_P$(``@``0("```(/P(```(`"0`,``@` M`````*"K___`J```8%0``&!4``!@5```````````````````H*O__\"H``!@ M5```8%0``&!4`````````````&!4`````````P`$``@`8%0``&!4```````` M`````&!4```````````0\`@```#5`YL#5`3%!@\`!/#B````$@`*\`@```!( M$`````H``!,!"_!F````!````$@`@``T"J$`@0!X80$`@@"BK0``@P!X80$` MA`"BK0``A0`"````OP`2`!\`@`$)````@0$$```(@P$````(OP$``!``P`$` M)Y\`RP&<,0``_P$```@``0("```(/P(```(````0\`@```!4!*H#0@30!0\` M#?!,``````"?#P0````$``````"H#P8```!(>6QA;F0``*$/&`````<````` M```````'`````0`#``$``0`*````J@\*````!P````$````#``\`!/!J```` M$@`*\`@```!)$`````H``+,`"_!"````A0`"````AP`!````@`$)````@0$$ M```(@P$````(OP$``!``P`$`)Y\`RP&<,0``_P$```@``0("```(/P(```(` M```0\`@````Y`HX$-P7F`@\`!/#)````$@`*\`@```!*$`````H``/,`"_!: M````@`#T"J$`@0!X80$`@@"BK0``@P!X80$`A`"BK0``OP`2`!\`@`$)```` M@0$$```(@P$````(OP$``!``P`$`)Y\`RP&<,0``_P$```@``0("```(/P(` M``(````0\`@```"P"VT)WPVH#`\`#?`_``````"?#P0````$``````"H#PL` M```T,#4@1G)E97=A>0``H0\8````#`````````````P````!``,``0`!`!0` M#P`$\%X```!"`0KP"````$L0````"@``DP`+\#8```"%``(```"'``$```"_ M`0``$`#``0`GGP#+`9PQ``#0`0$```#_`0@`"``!`@(```@_`@```@```!#P M"````%8"#Q4/%<(&#P`$\,H````2``KP"````$P0````"@```P$+\&`````$ M````6@"``%0+H0"!`'AA`0""`**M``"#`'AA`0"$`**M``"_`!(`'P"``0D` M``"!`00```B#`0````B_`0``$`#``0`GGP#+`9PQ``#_`0``"``!`@(```@_ M`@```@```!#P"````-D(U`*2`ZX*#P`-\#H``````)\/!`````0``````*@/ M!@```$5U8VQI9```H0\8````!P````````````<````!``,``0`!``X`#P`$ M\-<````R``KP"````$T0````"@``(P$+\&P````$````#P&``+0+H0"!`'AA M`0""`**M``"#`'AA`0"$`**M``"%``(```"'``$```"_`!``'P"``0D```"! M`00```B#`0````B_`1``$`#``0`GGP#+`9PQ``#_`0@`"``!`@(```@_`@`` M`@```!#P"````.,&Y1,4%N,*#P`-\#L``````)\/!`````0``````*@/!0`` M`$Y/4E1(``"A#QH````&````````"````0`&`````0`#``$`!``@``\`!/#+ M````$@`*\`@```!.$`````H``/,`"_!:````@`#T0:$`@0!X80$`@@"BK0`` M@P!X80$`A`"BK0``OP`2`!\`@`$)````@0$$```(@P$````(OP$``!``P`$` M)Y\`RP&<,0``_P$```@``0("```(/P(```(````0\`@```#Z"*<0J1(8"@\` M#?!!``````"?#P0````$``````"H#PT```!715-424X@#4A/5$5,``"A#Q@` M```.````````````#@````,``P`#``$`#``/``3P)@$``!(`"O`(````3Q`` M```*```#`0OP8````(``5$*A`($`>&$!`((`HJT``(,`>&$!`(0`HJT``(4` M`@```+\`$@`?`(`!"0```($!!```"(,!````"+\!```0`,`!`">?`,L!G#$` M`/\!```(``$"`@``"#\"```"````$/`(````Z@S4$*8580\/``WPE@`````` MGP\$````!```````J`]`````4F5D#4QI;VX@2&]T96P-1$\@3D]4(%=!3$L- M2&%V92!T;R!G;R!O;B!O=F5R8W)OO6@`OP$2`!(`_P$```@`!`,)````/P,! M``$`+P`%\"```````!3P"`````$````J$``````4\`@````"````1Q```!`` M\`<@````____``````"1D9$`P@```!%/^P#__P``?_\``/\`_P`/`.X#"`$` M``(`[P,8````$```````````````````@``````'``4P``#Y`Q`````````` M``````(``0`"````#P`,!*`````/``+PF````%``"/`(`````0````$4```/ M``/P,`````\`!/`H`````0`)\!```````````````````````````@`*\`@` M````%```!0````\`!/!(````$@`*\`@````!%`````P``(,`"_`P````@0$` M```(@P$%```(DP&.GXL`E`'>O6@`OP$2`!(`_P$```@`!`,)````/P,!``$` M$`#P!R````#___\``````)&1D0#"````$4_[`/__``!__P``_P#_``\`[@.& M`0```@#O`Q@````0``````````````````"```````<`!3```/D#$``````` M`````````@`!``(````/``P$'@$```\``O`6`0``8``(\`@````"`````A@` M``\``_"N````#P`$\"@````!``GP$``````````````````````````"``KP M"``````8```%````#P`$\'8```"R!`KP"`````(8````"@``TP`+\$X```!_ M````@`"%``(```"'``$````$00(```"``0D```"!`00```B#`0````B_`0`` M$`#``0`GGP#+`9PQ``#_`0``"``!`@(```@_`@```@```!#P"````)P#3@`H M$2@``[DL`````]0\<``````$``'`0``,` M````?$T```$````'`````0`````````````````````````````````````` M````````````````````````````````````````92!4:71L90`/````3F\@ M4VQI9&4@5&ET;&4`#!````8````>````"P```$9O;G1S(%5S960``P````4` M```>````$````$1EP`````````#`$\`8@!J`$D`;@!F`&\````` M```````````````````````````````````````````````````````````` M$@`"`14````9````_____P`````````````````````````````````````` M`````````"T````$``````````$!```"`0```P$```0!```%`0``!@$````$``'D!``!Z`0``>P$``'P!``!]`0``?@$``'\!``"``0``"`"",1LE```! M``D```.61@``"@"$```````1````)@8/`!@`_____P``$````````````#H+ M``!J"```"0```"8&#P`(`/____\"````%P```"8&#P`C`/____\$`!L`5$Y0 M4!0`````,@I@!44(#P```$9O`!@`%0`, M`",`#0`8`!,`$@`6`!@`&``H`!(`#``%````+@$!````!0````(!`@````4` M```)`@````(%````%`(`````!0```"X!&`````4````"`0$````8````,@J9 M!44("P```#$@=&AR;W5G:"`X;Q@`#``0`!L`%0`8`!L`&``:``P`&``%```` M+@$!````!0````(!`@````4````)`@````(%````%`(`````!0```"X!&``` M``4````"`0$````A````,@H,!D4($0```#$U-3`@4V-E;FEC($1R:79E`!@` M&``8`!@`#``;`!4`%@`:``X`%0`,`",`%0`.`!@`%0`%````+@$!````!0`` M``(!`@````4````"`0(````0````)@8/`!8`_____P``-@H``-T!``!+"P`` M7`4```@````F!@\`!@#_____`0`%````"0(````"!0```!0"`````!P```#[ M`J#_``"""H(*D`$`````!P```%1I;65S($YE=R!2;VUA;@`J@NUWP&?O=](" M"B````H`!````"T!`P`$````\`$%``4````)`@````(%````%`(`````!0`` M`"X!&`````4````"`0$````3````,@J-`ML*"````$UO;F1A=FD@5@`P`#`` M,``J`#``&P`8``4````N`0$````%`````@$"````!0````D"`````@4````4 M`@`````%````+@$8````!0````(!`0```!`````R"@`$U`H&````5VEN97)Y M6@`;`#``*@`@`#``!0```"X!`0````4````"`0(````%`````@$"````$``` M`"8&#P`6`/____\``*T*```N!@``%`L``"T'```(````)@8/``8`_____P$` M!0````D"`````@4````4`@`````<````^P+(_P``@@J""KP"``````<```!4 M:6UE(!*`'B`2@!W@$,````)`,$`#0! MW@$T`>(!1`'B`40!W@$,````)`,$`%`!W@%0`>(!8`'B`6`!W@$,````)`,$ M`&P!W@%L`>(!?`'B`7P!W@$,````)`,$`(@!W@&(`>(!F`'B`9@!W@$,```` M)`,$`*0!W@&D`>(!M`'B`;0!W@$,````)`,$`,`!W@'``>(!T`'B`=`!W@$, M````)`,$`-P!W@'<`>(![`'B`>P!W@$,````)`,$`/@!W@'X`>(!"`+B`0@" MW@$,````)`,$`!0"W@$4`N(!)`+B`20"W@$,````)`,$`#`"W@$P`N(!0`+B M`4`"W@$,````)`,$`$P"W@%,`N(!7`+B`5P"W@$,````)`,$`&@"W@%H`N(! M>`+B`7@"W@$,````)`,$`(0"W@&$`N(!E`+B`90"W@$,````)`,$`*`"W@&@ M`N(!L`+B`;`"W@$,````)`,$`+P"W@&\`N(!S`+B`@"W@$,````)`,$`/0"W@'T`N(!!`/B`00#W@$,````)`,$ M`!`#W@$0`^(!(`/B`2`#W@$,````)`,$`"P#W@$L`^(!/`/B`3P#W@$,```` M)`,$`$@#W@%(`^(!6`/B`5@#W@$,````)`,$`&0#W@%D`^(!=`/B`70#W@$, M````)`,$`(`#W@&``^(!D`/B`9`#W@$,````)`,$`)P#W@&<`^(!K`/B`:P# MW@$,````)`,$`+@#W@&X`^(!R`/B`<@#W@$,````)`,$`-0#W@'4`^(!Y`/B M`>0#W@$,````)`,$`/`#W@'P`^(!``3B`0`$W@$,````)`,$``P$W@$,!.(! M'`3B`1P$W@$,````)`,$`"@$W@$H!.(!.`3B`3@$W@$,````)`,$`$0$W@%$ M!.(!5`3B`50$W@$,````)`,$`&`$W@%@!.(!<`3B`7`$W@$,````)`,$`'P$ MW@%\!.(!C`3B`8P$W@$,````)`,$`)@$W@&8!.(!J`3B`:@$W@$,````)`,$ M`+0$W@&T!.(!Q`3B`<0$W@$,````)`,$`-`$W@'0!.(!X`3B`>`$W@$,```` M)`,$`.P$W@'L!.(!_`3B`?P$W@$,````)`,$``@%W@$(!>(!&`7B`1@%W@$, M````)`,$`"0%W@$D!>(!-`7B`30%W@$,````)`,$`$`%W@%`!>(!4`7B`5`% MW@$,````)`,$`%P%W@%(!;`7B`6P%W@$,````)`,$`'@%W@%X!>(!B`7B M`8@%W@$,````)`,$`)0%W@&4!>(!I`7B`:0%W@$,````)`,$`+`%W@&P!>(! MP`7B`<`%W@$,````)`,$`,P%W@',!>(!W`7B`=P%W@$,````)`,$`.@%W@'H M!>(!^`7B`?@%W@$,````)`,$``0&W@$$!N(!%`;B`10&W@$,````)`,$`"`& MW@$@!N(!,`;B`3`&W@$,````)`,$`#P&W@$\!N(!3`;B`4P&W@$,````)`,$ M`%@&W@%8!N(!:`;B`6@&W@$,````)`,$`'0&W@%T!N(!A`;B`80&W@$,```` M)`,$`)`&W@&0!N(!H`;B`:`&W@$,````)`,$`*P&W@&L!N(!O`;B`;P&W@$, M````)`,$`,@&W@'(!N(!V`;B`=@&W@$,````)`,$`.0&W@'D!N(!]`;B`?0& MW@$,````)`,$```'W@$`!^(!$`?B`1`'W@$,````)`,$`!P'W@$P(W@$,````)`,$`/@(W@'X".(! M"`GB`0@)W@$,````)`,$`!0)W@$4">(!)`GB`20)W@$,````)`,$`#`)W@$P M">(!0`GB`4`)W@$,````)`,$`$P)W@%,">(!7`GB`5P)W@$,````)`,$`&@) MW@%H">(!>`GB`7@)W@$,````)`,$`(0)W@&$">(!E`GB`90)W@$,````)`,$ M`*`)W@&@">(!L`GB`;`)W@$,````)`,$`+P)W@&\">(!S`GB`(!Z`GB`>@)W@$,````)`,$`/0)W@'T">(!!`KB`00*W@$, M````)`,$`!`*W@$0"N(!(`KB`2`*W@$,````)`,$`"P*W@$L"N(!/`KB`3P* MW@$,````)`,$`$@*W@%("N(!6`KB`5@*W@$,````)`,$`&0*W@%D"N(!=`KB M`70*W@$,````)`,$`(`*W@&`"N(!D`KB`9`*W@$,````)`,$`)P*W@&<"N(! MK`KB`:P*W@$,````)`,$`+@*W@&X"N(!R`KB`<@*W@$,````)`,$`-0*W@'4 M"N(!Y`KB`>0*W@$,````)`,$`/`*W@'P"N(!``OB`0`+W@$,````)`,$``P+ MW@$,"^(!'`OB`1P+W@$,````)`,$`"@+W@$H"^(!.`OB`3@+W@$%````!@$! M````!````"T!```$````+0$"``0```#P`0,`"````"8&#P`&`/____\!`!`` M```F!@\`%@#_____``#]____90$``$0+``!L`0``!````"T!`0`'````_`(` M``````````0````M`0,`!0````8!`@````P````D`P0```!F`0``:@$0`&H! M$`!F`0P````D`P0`'`!F`1P`:@$L`&H!+`!F`0P````D`P0`.`!F`3@`:@%( M`&H!2`!F`0P````D`P0`5`!F`50`:@%D`&H!9`!F`0P````D`P0`<`!F`7`` M:@&``&H!@`!F`0P````D`P0`C`!F`8P`:@&<`&H!G`!F`0P````D`P0`J`!F M`:@`:@&X`&H!N`!F`0P````D`P0`Q`!F`<0`:@'4`&H!U`!F`0P````D`P0` MX`!F`>``:@'P`&H!\`!F`0P````D`P0`_`!F`?P`:@$,`6H!#`%F`0P````D M`P0`&`%F`1@!:@$H`6H!*`%F`0P````D`P0`-`%F`30!:@%$`6H!1`%F`0P` M```D`P0`4`%F`5`!:@%@`6H!8`%F`0P````D`P0`;`%F`6P!:@%\`6H!?`%F M`0P````D`P0`B`%F`8@!:@&8`6H!F`%F`0P````D`P0`I`%F`:0!:@&T`6H! MM`%F`0P````D`P0`P`%F`<`!:@'0`6H!T`%F`0P````D`P0`W`%F`=P!:@'L M`6H![`%F`0P````D`P0`^`%F`?@!:@$(`FH!"`)F`0P````D`P0`%`)F`10" M:@$D`FH!)`)F`0P````D`P0`,`)F`3`":@%``FH!0`)F`0P````D`P0`3`)F M`4P":@%<`FH!7`)F`0P````D`P0`:`)F`6@":@%X`FH!>`)F`0P````D`P0` MA`)F`80":@&4`FH!E`)F`0P````D`P0`H`)F`:`":@&P`FH!L`)F`0P````D M`P0`O`)F`;P":@',`FH!S`)F`0P````D`P0`V`)F`=@":@'H`FH!Z`)F`0P` M```D`P0`]`)F`?0":@$$`VH!!`-F`0P````D`P0`$`-F`1`#:@$@`VH!(`-F M`0P````D`P0`+`-F`2P#:@$\`VH!/`-F`0P````D`P0`2`-F`4@#:@%8`VH! M6`-F`0P````D`P0`9`-F`60#:@%T`VH!=`-F`0P````D`P0`@`-F`8`#:@&0 M`VH!D`-F`0P````D`P0`G`-F`9P#:@&L`VH!K`-F`0P````D`P0`N`-F`;@# M:@'(`VH!R`-F`0P````D`P0`U`-F`=0#:@'D`VH!Y`-F`0P````D`P0`\`-F M`?`#:@$`!&H!``1F`0P````D`P0`#`1F`0P$:@$P$:@'\!&H! M_`1F`0P````D`P0`"`5F`0@%:@$8!6H!&`5F`0P````D`P0`)`5F`20%:@$T M!6H!-`5F`0P````D`P0`0`5F`4`%:@%0!6H!4`5F`0P````D`P0`7`5F`5P% M:@%L!6H!;`5F`0P````D`P0`>`5F`7@%:@&(!6H!B`5F`0P````D`P0`E`5F M`90%:@&D!6H!I`5F`0P````D`P0`L`5F`;`%:@'`!6H!P`5F`0P````D`P0` MS`5F`@%:@'X!6H!^`5F`0P````D M`P0`!`9F`00&:@$4!FH!%`9F`0P````D`P0`(`9F`2`&:@$P!FH!,`9F`0P` M```D`P0`/`9F`3P&:@%,!FH!3`9F`0P````D`P0`6`9F`5@&:@%H!FH!:`9F M`0P````D`P0`=`9F`70&:@&$!FH!A`9F`0P````D`P0`D`9F`9`&:@&@!FH! MH`9F`0P````D`P0`K`9F`:P&:@&\!FH!O`9F`0P````D`P0`R`9F`<@&:@'8 M!FH!V`9F`0P````D`P0`Y`9F`>0&:@'T!FH!]`9F`0P````D`P0```=F`0`' M:@$0!VH!$`=F`0P````D`P0`'`=F`1P':@$L!VH!+`=F`0P````D`P0`.`=F M`3@':@%(!VH!2`=F`0P````D`P0`5`=F`50':@%D!VH!9`=F`0P````D`P0` M<`=F`7`':@&`!VH!@`=F`0P````D`P0`C`=F`8P':@&`':@'P!VH!\`=F`0P````D`P0`_`=F`?P':@$,"&H!#`AF M`0P````D`P0`&`AF`1@(:@$H"&H!*`AF`0P````D`P0`-`AF`30(:@%$"&H! M1`AF`0P````D`P0`4`AF`5`(:@%@"&H!8`AF`0P````D`P0`;`AF`6P(:@%\ M"&H!?`AF`0P````D`P0`B`AF`8@(:@&8"&H!F`AF`0P````D`P0`I`AF`:0( M:@&T"&H!M`AF`0P````D`P0`P`AF`<`(:@'0"&H!T`AF`0P````D`P0`W`AF M`=P(:@'L"&H![`AF`0P````D`P0`^`AF`?@(:@$("6H!"`EF`0P````D`P0` M%`EF`10):@$D"6H!)`EF`0P````D`P0`,`EF`3`):@%`"6H!0`EF`0P````D M`P0`3`EF`4P):@%<"6H!7`EF`0P````D`P0`:`EF`6@):@%X"6H!>`EF`0P` M```D`P0`A`EF`80):@&4"6H!E`EF`0P````D`P0`H`EF`:`):@&P"6H!L`EF M`0P````D`P0`O`EF`;P):@',"6H!S`EF`0P````D`P0`V`EF`=@):@'H"6H! MZ`EF`0P````D`P0`]`EF`?0):@$$"FH!!`IF`0P````D`P0`$`IF`1`*:@$@ M"FH!(`IF`0P````D`P0`+`IF`2P*:@$\"FH!/`IF`0P````D`P0`2`IF`4@* M:@%8"FH!6`IF`0P````D`P0`9`IF`60*:@%T"FH!=`IF`0P````D`P0`@`IF M`8`*:@&0"FH!D`IF`0P````D`P0`G`IF`9P*:@&L"FH!K`IF`0P````D`P0` MN`IF`;@*:@'("FH!R`IF`0P````D`P0`U`IF`=0*:@'D"FH!Y`IF`0P````D M`P0`\`IF`?`*:@$`"VH!``MF`0P````D`P0`#`MF`0P+:@$<"VH!'`MF`0P` M```D`P0`*`MF`2@+:@$X"VH!.`MF`04````&`0$````$````+0$```0````M M`0(`!````/`!`P`(````)@8/``8`_____P$`$````"8&#P`6`/____\``*T! M``#=`0``%`L``.0!```$````+0$!``<```#\`@``````````!````"T!`P`% M````!@$"````#````"0#!`"P`=X!L`'B`<`!X@'``=X!#````"0#!`#,`=X! MS`'B`=P!X@'<`=X!#````"0#!`#H`=X!Z`'B`?@!X@'X`=X!#````"0#!``$ M`MX!!`+B`10"X@$4`MX!#````"0#!``@`MX!(`+B`3`"X@$P`MX!#````"0# M!``\`MX!/`+B`4P"X@%,`MX!#````"0#!`!8`MX!6`+B`6@"X@%H`MX!#``` M`"0#!`!T`MX!=`+B`80"X@&$`MX!#````"0#!`"0`MX!D`+B`:`"X@&@`MX! M#````"0#!`"L`MX!K`+B`;P"X@&\`MX!#````"0#!`#(`MX!R`+B`=@"X@'8 M`MX!#````"0#!`#D`MX!Y`+B`?0"X@'T`MX!#````"0#!````]X!``/B`1`# MX@$0`]X!#````"0#!``<`]X!'`/B`2P#X@$L`]X!#````"0#!``X`]X!.`/B M`4@#X@%(`]X!#````"0#!`!4`]X!5`/B`60#X@%D`]X!#````"0#!`!P`]X! M<`/B`8`#X@&``]X!#````"0#!`",`]X!C`/B`9P#X@&<`]X!#````"0#!`"H M`]X!J`/B`;@#X@&X`]X!#````"0#!`#$`]X!Q`/B`=0#X@'4`]X!#````"0# M!`#@`]X!X`/B`?`#X@'P`]X!#````"0#!`#\`]X!_`/B`0P$X@$,!-X!#``` M`"0#!``8!-X!&`3B`2@$X@$H!-X!#````"0#!``T!-X!-`3B`40$X@%$!-X! M#````"0#!`!0!-X!4`3B`6`$X@%@!-X!#````"0#!`!L!-X!;`3B`7P$X@%\ M!-X!#````"0#!`"(!-X!B`3B`9@$X@&8!-X!#````"0#!`"D!-X!I`3B`;0$ MX@&T!-X!#````"0#!`#`!-X!P`3B`=`$X@'0!-X!#````"0#!`#P$X@'L!-X!#````"0#!`#X!-X!^`3B`0@%X@$(!=X!#````"0#!``4!=X! M%`7B`20%X@$D!=X!#````"0#!``P!=X!,`7B`4`%X@%`!=X!#````"0#!`!, M!=X!3`7B`5P%X@%@%X@'H!=X! M#````"0#!`#T!=X!]`7B`00&X@$$!MX!#````"0#!``0!MX!$`;B`2`&X@$@ M!MX!#````"0#!``L!MX!+`;B`3P&X@$\!MX!#````"0#!`!(!MX!2`;B`5@& MX@%8!MX!#````"0#!`!D!MX!9`;B`70&X@%T!MX!#````"0#!`"`!MX!@`;B M`9`&X@&0!MX!#````"0#!`"0&X@'D!MX!#````"0#!`#P M!MX!\`;B`0`'X@$`!]X!#````"0#!``,!]X!#`?B`1P'X@$`'X@'@!]X!#````"0#!`#L!]X![`?B`?P' MX@'\!]X!#````"0#!``("-X!"`CB`1@(X@$8"-X!#````"0#!``D"-X!)`CB M`30(X@$T"-X!#````"0#!`!`"-X!0`CB`5`(X@%0"-X!#````"0#!`!<"-X! M7`CB`6P(X@%L"-X!#````"0#!`!X"-X!>`CB`8@(X@&("-X!#````"0#!`"4 M"-X!E`CB`:0(X@&D"-X!#````"0#!`"P"-X!L`CB`<`(X@'`"-X!#````"0# M!`#,"-X!S`CB`=P(X@'<"-X!#````"0#!`#H"-X!Z`CB`?@(X@'X"-X!#``` M`"0#!``$"=X!!`GB`10)X@$4"=X!#````"0#!``@"=X!(`GB`3`)X@$P"=X! M#````"0#!``\"=X!/`GB`4P)X@%,"=X!#````"0#!`!8"=X!6`GB`6@)X@%H M"=X!#````"0#!`!T"=X!=`GB`80)X@&$"=X!#````"0#!`"0"=X!D`GB`:`) MX@&@"=X!#````"0#!`"L"=X!K`GB`;P)X@&\"=X!#````"0#!`#("=X!R`GB M`=@)X@'8"=X!#````"0#!`#D"=X!Y`GB`?0)X@'T"=X!#````"0#!```"MX! M``KB`1`*X@$0"MX!#````"0#!``<"MX!'`KB`2P*X@$L"MX!#````"0#!``X M"MX!.`KB`4@*X@%("MX!#````"0#!`!4"MX!5`KB`60*X@%D"MX!#````"0# M!`!P"MX!<`KB`8`*X@&`"MX!#````"0#!`","MX!C`KB`9P*X@&<"MX!#``` M`"0#!`"H"MX!J`KB`;@*X@&X"MX!#````"0#!`#$"MX!Q`KB`=0*X@'4"MX! M#````"0#!`#@"MX!X`KB`?`*X@'P"MX!#````"0#!`#\"MX!_`KB`0P+X@$, M"]X!!0````8!`0````0````M`0``!````"T!`@`$````\`$#``@````F!@\` M!@#_____`0`0````)@8/`!8`_____P``K0H```4!``"T"@``1`@```0````M M`0$`!P```/P"```````````$````+0$#``4````&`0(````,````)`,$`*X* M0`BR"D`(L@HP"*X*,`@,````)`,$`*X*)`BR"B0(L@H4"*X*%`@,````)`,$ M`*X*"`BR"@@(L@KX!ZX*^`<,````)`,$`*X*[`>R"NP'L@KR"M`'L@K`!ZX*P`<,````)`,$`*X*M`>R"K0'L@JD!ZX*I`<, M````)`,$`*X*F`>R"I@'L@J(!ZX*B`<,````)`,$`*X*?`>R"GP'L@IL!ZX* M;`<,````)`,$`*X*8`>R"F`'L@I0!ZX*4`<,````)`,$`*X*1`>R"D0'L@HT M!ZX*-`<,````)`,$`*X**`>R"B@'L@H8!ZX*&`<,````)`,$`*X*#`>R"@P' ML@K\!JX*_`8,````)`,$`*X*\`:R"O`&L@K@!JX*X`8,````)`,$`*X*U`:R M"M0&L@K$!JX*Q`8,````)`,$`*X*N`:R"K@&L@JH!JX*J`8,````)`,$`*X* MG`:R"IP&L@J,!JX*C`8,````)`,$`*X*@`:R"H`&L@IP!JX*<`8,````)`,$ M`*X*9`:R"F0&L@I4!JX*5`8,````)`,$`*X*2`:R"D@&L@HX!JX*.`8,```` M)`,$`*X*+`:R"BP&L@H`0,````)`,$`*X*;`2R"FP$L@I`&R"G@!L@IH`:X*:`$,````)`,$`*X*7`&R"EP!L@I,`:X*3`$,```` M)`,$`*X*0`&R"D`!L@HP`:X*,`$,````)`,$`*X*)`&R"B0!L@H4`:X*%`$% M````!@$!````!````"T!```$````+0$"``0```#P`0,`"````"8&#P`&`/__ M__\!`!`````F!@\`%@#_____```%`0``#?___PT!``!T"```!````"T!`0`' M````_`(```````````0````M`0,`!0````8!`@````P````D`P0`!@%P"`H! M<`@*`6`(!@%@"`P````D`P0`!@%4"`H!5`@*`40(!@%$"`P````D`P0`!@$X M"`H!.`@*`2@(!@$H"`P````D`P0`!@$<"`H!'`@*`0P(!@$,"`P````D`P0` M!@$`"`H!``@*`?`'!@'P!PP````D`P0`!@'D!PH!Y`<*`=0'!@'4!PP````D M`P0`!@'(!PH!R`<*`;@'!@&X!PP````D`P0`!@&L!PH!K`<*`9P'!@&`8*`6@&!@%H!@P````D`P0` M!@%`$!@'@!`P````D`P0`!@'4!`H!U`0*`<0$!@'$!`P````D`P0` M!@&X!`H!N`0*`:@$!@&H!`P````D`P0`!@&0# M!@'D`PP````D`P0`!@'8`PH!V`,*`<@#!@'(`PP````D`P0`!P&\`PL!O`,+ M`:P#!P&L`PP````D`P0`!P&@`PL!H`,+`9`#!P&0`PP````D`P0`!P&$`PL! MA`,+`70#!P%T`PP````D`P0`!P%H`PL!:`,+`5@#!P%8`PP````D`P0`!P%, M`PL!3`,+`3P#!P$\`PP````D`P0`!P$P`PL!,`,+`2`#!P$@`PP````D`P0` M!P$4`PL!%`,+`00#!P$$`PP````D`P0`!P'X`@L!^`(+`>@"!P'H`@P````D M`P0`!P'<`@L!W`(+`P!!P'L`0P````D`P0`!P'@`0L! MX`$+`=`!!P'0`0P````D`P0`!P'$`0L!Q`$+`;0!!P&T`0P````D`P0`!P&H M`0L!J`$+`9@!!P&8`0P````D`P0`!P&,`0L!C`$+`7P!!P%\`0P````D`P0` M!P%P`0L!<`$+`6`!!P%@`0P````D`P0`!P%4`0L!5`$+`40!!P%$`0P````D M`P0`!P$X`0L!.`$+`2@!!P$H`0P````D`P0`!P$<`0L!'`$+`0P!!P$,`0P` M```D`P0`!P$``0L!``$+`?``!P'P``P````D`P0`!P'D``L!Y``+`=0`!P'4 M``P````D`P0`!P'(``L!R``+`;@`!P&X``P````D`P0`!P&L``L!K``+`9P` M!P&<``P````D`P0`!P&0``L!D``+`8``!P&```P````D`P0`!P%T``L!=``+ M`60`!P%D``P````D`P0`!P%8``L!6``+`4@`!P%(``P````D`P0`!P$\``L! M/``+`2P`!P$L``P````D`P0`!P$@``L!(``+`1``!P$0``P````D`P0`!P$$ M``L!!``+`?3_!P'T_PP````D`P0`!P'H_PL!Z/\+`=C_!P'8_PP````D`P0` M!P',_PL!S/\+`;S_!P&\_PP````D`P0`!P&P_PL!L/\+`:#_!P&@_PP````D M`P0`!P&4_PL!E/\+`83_!P&$_PP````D`P0`!P%X_PL!>/\+`6C_!P%H_PP` M```D`P0`!P%<_PL!7/\+`4S_!P%,_PP````D`P0`!P%`_PL!0/\+`3#_!P$P M_PP````D`P0`!P$D_PL!)/\+`13_!P$4_P4````&`0$````$````+0$```0` M```M`0(`!````/`!`P`(````)@8/``8`_____P$`$````"8&#P`6`/____\` M`'4```#E____?0```$P)```$````+0$!``<```#\`@``````````!````"T! M`P`%````!@$"````#````"0#!`!V`$@)>@!("7H`.`EV`#@)#````"0#!`!V M`"P)>@`L"7H`'`EV`!P)#````"0#!`!V`!`)>@`0"7H```EV```)#````"0# M!`!V`/0(>@#T"'H`Y`AV`.0(#````"0#!`!V`-@(>@#8"'H`R`AV`,@(#``` M`"0#!`!V`+P(>@"\"'H`K`AV`*P(#````"0#!`!V`*`(>@"@"'H`D`AV`)`( M#````"0#!`!V`(0(>@"$"'H`=`AV`'0(#````"0#!`!V`&@(>@!H"'H`6`AV M`%@(#````"0#!`!V`$P(>@!,"'H`/`AV`#P(#````"0#!`!V`#`(>@`P"'H` M(`AV`"`(#````"0#!`!V`!0(>@`4"'H`!`AV``0(#````"0#!`!V`/@'>@#X M!WH`Z`=V`.@'#````"0#!`!V`-P'>@#@#`!WH`L`=V`+`'#````"0#!`!V`*0'>@"D!WH`E`=V`)0'#````"0#!`!V M`(@'>@"(!WH`>`=V`'@'#````"0#!`!V`&P'>@!L!WH`7`=V`%P'#````"0# M!`!V`%`'>@!0!WH`0`=V`$`'#````"0#!`!V`#0'>@`T!WH`)`=V`"0'#``` M`"0#!`!V`!@'>@`8!WH`"`=V``@'#````"0#!`!V`/P&>@#\!GH`[`9V`.P& M#````"0#!`!V`.`&>@#@!GH`T`9V`-`&#````"0#!`!V`,0&>@#$!GH`M`9V M`+0&#````"0#!`!V`*@&>@"H!GH`F`9V`)@&#````"0#!`!V`(P&>@",!GH` M?`9V`'P&#````"0#!`!V`'`&>@!P!GH`8`9V`&`&#````"0#!`!V`%0&>@!4 M!GH`1`9V`$0&#````"0#!`!V`#@&>@`X!GH`*`9V`"@&#````"0#!`!V`!P& M>@`@``!GH`\`5V`/`%#````"0#!`!V M`.0%>@#D!7H`U`5V`-0%#````"0#!`!V`,@%>@#(!7H`N`5V`+@%#````"0# M!`!V`*P%>@"L!7H`G`5V`)P%#````"0#!`!V`)`%>@"0!7H`@`5V`(`%#``` M`"0#!`!V`'0%>@!T!7H`9`5V`&0%#````"0#!`!V`%@%>@!8!7H`2`5V`$@% M#````"0#!`!V`#P%>@`\!7H`+`5V`"P%#````"0#!`!V`"`%>@`@!7H`$`5V M`!`%#````"0#!`!V``0%>@`$!7H`]`1V`/0$#````"0#!`!V`.@$>@#H!'H` MV`1V`-@$#````"0#!`!V`,P$>@#,!'H`O`1V`+P$#````"0#!`!V`+`$>@"P M!'H`H`1V`*`$#````"0#!`!W`)0$>P"4!'L`A`1W`(0$#````"0#!`!W`'@$ M>P!X!'L`:`1W`&@$#````"0#!`!W`%P$>P!P!`!'L`,`1W`#`$#````"0#!`!W`"0$>P`D!'L`%`1W`!0$#````"0# M!`!W``@$>P`(!'L`^`-W`/@##````"0#!`!W`.P#>P#L`WL`W`-W`-P##``` M`"0#!`!W`-`#>P#0`WL`P`-W`,`##````"0#!`!W`+0#>P"T`WL`I`-W`*0# M#````"0#!`!W`)@#>P"8`WL`B`-W`(@##````"0#!`!W`'P#>P!\`WL`;`-W M`&P##````"0#!`!W`&`#>P!@`WL`4`-W`%`##````"0#!`!W`$0#>P!$`WL` M-`-W`#0##````"0#!`!W`"@#>P`H`WL`&`-W`!@##````"0#!`!W``P#>P`, M`WL`_`)W`/P"#````"0#!`!W`/`">P#P`GL`X`)W`.`"#````"0#!`!W`-0" M>P#4`GL`Q`)W`,0"#````"0#!`!W`+@">P"X`GL`J`)W`*@"#````"0#!`!W M`)P">P"<`GL`C`)W`(P"#````"0#!`!W`(`">P"``GL`<`)W`'`"#````"0# M!`!W`&0">P!D`GL`5`)W`%0"#````"0#!`!W`$@">P!(`GL`.`)W`#@"#``` M`"0#!`!W`"P">P`L`GL`'`)W`!P"#````"0#!`!W`!`">P`0`GL```)W```" M#````"0#!`!W`/0!>P#T`7L`Y`%W`.0!#````"0#!`!W`-@!>P#8`7L`R`%W M`,@!#````"0#!`!W`+P!>P"\`7L`K`%W`*P!#````"0#!`!W`*`!>P"@`7L` MD`%W`)`!#````"0#!`!W`(0!>P"$`7L`=`%W`'0!#````"0#!`!W`&@!>P!H M`7L`6`%W`%@!#````"0#!`!W`$P!>P!,`7L`/`%W`#P!#````"0#!`!W`#`! M>P`P`7L`(`%W`"`!#````"0#!`!W`!0!>P`4`7L`!`%W``0!#````"0#!`!W M`/@`>P#X`'L`Z`!W`.@`#````"0#!`!W`-P`>P#<`'L`S`!W`,P`#````"0# M!`!W`,``>P#``'L`L`!W`+``#````"0#!`!W`*0`>P"D`'L`E`!W`)0`#``` M`"0#!`!W`(@`>P"(`'L`>`!W`'@`#````"0#!`!W`&P`>P!L`'L`7`!W`%P` M#````"0#!`!W`%``>P!0`'L`0`!W`$``#````"0#!`!W`#0`>P`T`'L`)`!W M`"0`#````"0#!`!W`!@`>P`8`'L`"`!W``@`#````"0#!`!W`/S_>P#\_WL` M[/]W`.S_!0````8!`0````0````M`0``!````"T!`@`$````\`$#``@````F M!@\`!@#_____`0`0````)@8/`!8`_____P``CP```$\!``#W````!P(```,` M```>``4````N`0`````%````"@(`````!0````D"``````4````!`O___P`$ M````+0$$``0````M`0$`!`````,!"``'````$@1P"+<`0`MG``4````+`JKM MM_<%````#`+-!U\$!0````P"S0=?!`,````>``X````F!@\`$@#_____```( M````T_W]^S("R@,*````)@8/``H`_____P(``````!<````F!@\`)`#_____ M!``:````5$Y04!0`36EC_WR`8']Y@&)_=P!DOW4 M`9O]RP&E_<8!KOW``;K]N@'&_;0!U/VP`>#]JP'L_8H!A/Y^`_F$#-/^Z`0C^"@```"8&#P`*`/____\!```````.```` M)@8/`!(`_____P``"````-W]J@&O_H`#!P```/P"``#_@``"```$````+0$' M``0```#P`0@`!````"T!`0`(````^@(&``@````````"!````"T!"``$```` M\`$&`"X````D`Q4`I?ZJ`=W]J@'T_;`!`/ZV`0K^O`$6_L0!(/[-`2C^U@$Q M_M\!-O[H`3S^]`%"_@`"2/X.`DS^&@)1_B8"`.G_G@#"@```"8&#P`*`/____\!```````*````)@8/``H`_____P$````` M``X````F!@\`$@#_____```(````1P!9`/(!9`,.````)@8/`!(`_____P`` M"````%@!O0'R`60#!P```/P"````H``"```$````+0$&``0```#P`0<`!``` M`"T!`0`(````^@(&``@````````"!````"T!!P`$````\`$(``L````:"+T! M7`%C`UP!9`/R`;T!Q@`*````)@8/``H`_____P$```````X````F!@\`$@#_ M____```(````50&M`2<"@P,'````_`(``/^```(```0````M`0@`!````/`! M!@`$````+0$!``@```#Z`@8`"`````````($````+0$&``0```#P`0<`+@`` M`"0#%0!7`:T!'P*M`0@"LP'\`;D!\@&_`>8!QP'<`=`!U`'9`L! MP`'W`;H!`P*T`1$"L`$=`JL!*0**`<("?@$!`W8!*@-L`50#70%[`U4!>P,* M````)@8/``H`_____P$```````H````F!@\`"@#_____`0``````"@```"8& M#P`*`/____\!```````.````)@8/`!(`_____P``"`````C^F?_R`40!#@`` M`"8&#P`2`/____\```@````(_IG_P/]!`0X````F!@\`$@#_____```(```` M"/Z9_Z+^00$'````_`(``.#@``(```0````M`0<`!````/`!"``$````+0$! M``@```#Z`@8`"`````````($````+0$(``0```#P`08`"P```!H(00&>_IG_ MGOY!`33_F?\(_@H````F!@\`"@#_____`0``````#@```"8&#P`2`/____\` M``@```#=_8G_K_Y@`0<```#\`@``_X```@``!````"T!!@`$````\`$'``0` M```M`0$`"````/H"!@`(`````````@0````M`0<`!````/`!"``N````)`,5 M`*7^B?_=_8G_]/V/_P#^E?\*_IO_%OZC_R#^K/\H_K7_,?Z__S;^R/\\_M3_ M0O[@_TC^[O],_OK_4?X&`'+^G@!^_MT`AOX'`9#^,0&?_E@!I_Y8`0H````F M!@\`"@#_____`0``````"@```"8&#P`*`/____\!```````.````)@8/`!(` M_____P``"````$<`G/_R`40!#@```"8&#P`2`/____\```@```!8`9S_\@%$ M`0<```#\`@``X.```@``!````"T!"``$````\`$&``0````M`0$`"````/H" M!@`(`````````@0````M`08`!````/`!!P`+````&@B<_UP!1`%<`40!\@&< M_\8`"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P``"````%4! MC/\G`F,!!P```/P"``#_@``"```$````+0$'``0```#P`0@`!````"T!`0`( M````^@(&``@````````"!````"T!"``$````\`$&`"X````D`Q4`5P&,_Q\" MC/\(`I+__`&8__(!GO_F`:;_W`&O_]0!N/_+`<+_Q@'+_\`!U_^Z`>/_M`'Q M_[`!_?^K`0D`B@&A`'X!X`!V`0H!;`$T`5T!6P%5`5L!"@```"8&#P`*`/__ M__\!```````*````)@8/``H`_____P$```````H````F!@\`"@#_____`0`` M````"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P``"````-3_ M*O\Q`'+_#@```"8&#P`2`/____\```@````L___[S``X_0<```#\`@``X'`` M`@``!````"T!!@`$````\`$'``0````M`0$`?````"0#/`"Q_S?]L?_R_%__ M\OQ6_^_\3O_M_$;_Z/P^_^+\-__;_#+_T_PO_\W\+/_$_"S_N_PL_[+\+_^H M_#7_GOP\_Y7\1/^-_$[_AOQ5_X'\7O]^_+/_?ORS_T'\MO\Y_+O_+_S`_R;\ MR/\<_-'_$_S:_PS\XO\'_.W_`OSY___[!0#_^Q(``?P=``;\)@`+_#``$_P[ M`!W\0P`F_$<`+_Q+`#G\30!%_$T`??R=`'W\I@"!_*X`AORV`(S\O@"4_,0` MG/S)`*7\RP"O_,P`N/S,`,/\R0#,_,0`UOR^`-[\MP#F_*X`Z_R<`/+\30#R M_$T`./T*````)@8/``H`_____P$```````X````F!@\`$@#_____```(```` MP/]\_#X`^?P'````_`(``/^@0`(```0````M`0<`!````/`!!@`(````^@(& M``@````````"!````"T!!@`$````\`$(``<````8!/G\/@!\_,#_!0```!0" M``````H````F!@\`"@#_____`0``````"@```"8&#P`*`/____\!```````. M````)@8/`!(`_____P``"````)7^'?UG`<8#!P```/P"``#_@``"```$```` M+0$(``0```#P`0<`!````"T!`0`(````^@(&``@````````"!````"T!!P`$ M````\`$&``<````;!,8#9P$=_97^!0```!0"``````H````F!@\`"@#_____ M`0``````#@```"8&#P`2`/____\```@```#)_W#_.0"\``X````F!@\`$@#_ M____```(````S/]P_SD`V/\.````)@8/`!(`_____P``"`````7_3/WT``S_ M!P```/P"``#_H$`"```$````+0$&``0```#P`0@`!````"T!`0!4````)`,H M``7_YOT&_]C]"O_)_1#_O/T8_Z_]'_^E_2?_F_TQ_Y#]/O^%_4[_>_UB_W#] M=?]G_8S_7_VA_UC]NO]3_=#_3_WB_T[]]_],_0T`3/T>`$[],`!0_40`5/U6 M`%C]:0!>_7H`9/V,`&S]F0!R_:0`>?VO`(#]NP"(_<8`D?W1`)W]V@"H_>$` MLOWG`+O][`#%_?``S_WT`-S]]``,_P;_"O\*````)@8/``H`_____P$````` M``X````F!@\`$@#_____```(````S/]U_SD`V/\.````)@8/`!(`_____P`` M"`````7_9/WT`"3_!P```/P"``#@<``"```$````+0$(``0```#P`08`5``` M`"0#*``%__W]!O_P_0K_X?T0_]3]&/_'_1__O?TG_[/],?^H_3[_G?U._Y/] M8O^(_77_?_V,_W?]H?]P_;K_:_W0_V?]XO]F_??_9/T-`&3]'@!F_3``:/U$ M`&S]5@!P_6D`=OUZ`'S]C`"$_9D`BOVD`)']KP"8_;L`H/W&`*G]T0"U_=H` MP/WA`,K]YP#3_>P`W?WP`.?]]`#S_?0`)/\&_R+_"@```"8&#P`*`/____\! M```````.````)@8/`!(`_____P``"````"+_<_W0`"+_!P```/P"``#_0$`" M```$````+0$&``0```#P`0@`"````/H"!@`(`````````@0````M`0@`!``` M`/`!!P`'````&`0B_]``<_TB_P4````4`@`````*````)@8/``H`_____P$` M``````X````F!@\`$@#_____```(````!`"!_QH`EO\.````)@8/`!(`____ M_P``"````!0`H/U$`-#]!P```/P"``#_P,`"```$````+0$'``0```#P`08` M!````"T!`0`'````&`31_44`H/T4``H````F!@\`"@#_____`0``````#@`` M`"8&#P`2`/____\```@````Z`+[]7P#D_0<````8!.7]8`"^_3H`"@```"8& M#P`*`/____\!```````*````)@8/``H`_____P$```````H````F!@\`"@#_ M____`0``````"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P`` M"````,G_YO\W`$X`#@```"8&#P`2`/____\```@```#X_H/_YP!#`0<```#\ M`@``_Z!``@``!````"T!!@`$````\`$'`%0````D`R@`^/X=`/G^#P#]_@`` M`__S_PO_YO\2_]S_&O_2_R3_Q_\Q_[S_0?^R_U7_I_]H_Y[_?_^6_Y7_C_^M M_XK_P_^&_]7_A?_J_X/_``"#_Q$`A?\C`(?_-P"+_TD`C_]<`)7_;0";_W\` MH_^,`*G_EP"P_Z(`M_^N`+__N0#(_\0`U/_-`-__U`#I_]H`\O_?`/S_XP`& M`.<`$P#G`$,!^?Y!`0H````F!@\`"@#_____`0``````#@```"8&#P`2`/__ M__\```@```#)_^K_-P!.``X````F!@\`$@#_____```(````^?Z6_^@`5@$' M````_`(``.!P``(```0````M`0<`!````/`!!@!4````)`,H`/G^,`#Z_B(` M_OX3``3_!@`,__G_$__O_QO_Y?\E_]K_,O_/_T+_Q?]6_[K_:?^Q_X#_J?^6 M_Z+_KO^=_\3_F?_6_YC_Z_^6_P$`EO\2`)C_)`":_S@`GO]*`*+_70"H_VX` MKO^``+;_C0"\_Y@`P_^C`,K_KP#2_[H`V__%`.?_S@#R_]4`_/_;``4`X``/ M`.0`&0#H`"8`Z`!6`?K^5`$*````)@8/``H`_____P$```````X````F!@\` M$@#_____```(````%O^E_\0`5`$'````_`(``.#@``(```0````M`08`!``` M`/`!!P`(````^@(&``@````````"!````"T!!P`$````\`$(``<````8!%0! MQ`"E_Q;_!0```!0"``````H````F!@\`"@#_____`0``````#@```"8&#P`2 M`/____\```@````"`/;_&``+``X````F!@\`$@#_____```(````"`#2_S@` M`@`'````_`(``/__P`(```0````M`0@`!````/`!!@`$````+0$!``<````8 M!`,`.0#2_P@`"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P`` M"````"X`\/]4`!8`!P```!@$%P!5`/#_+@`*````)@8/``H`_____P$````` M``H````F!@\`"@#_____`0``````"@```"8&#P`*`/____\!```````*```` M)@8/``H`_____P$```````X````F!@\`$@#_____```(````R_]6`#D`O``. M````)@8/`!(`_____P``"`````3_FP'S`%H#!P```/P"``#_H$`"```$```` M+0$&``0```#P`0@`5````"0#*``$_S0"!?\F`@G_%P(/_PH"%__]`1[_\P$F M_^D!,/_>`3W_U`%-_\H!8?^_`73_M@&+_ZX!H?^G`;G_H@'/_YX!X?^=`?;_ MFP$,`)L!'0"=`2\`GP%#`*,!50"G`6@`K0%Y`+,!BP"[`9@`P0&C`,@!K@#/ M`;H`UP'%`-\!T`#K`=D`]@'@```"Y@`)`NL`$P+O`!T"\P`J`O,`6@,%_U@# M"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P``"````,S_60`Y M`+P`#@```"8&#P`2`/____\```@````%_ZL!]`!J`P<```#\`@``X'```@`` M!````"T!"``$````\`$&`%0````D`R@`!?]$`@;_-@(*_R<"$/\:`AC_#0(? M_P,")__Y`3'_[@$^_^,!3O_9`6+_SP%U_\8!C/^^`:'_MP&Z_[(!T/^N`>+_ MK0'W_ZL!#0"K`1X`K0$P`*\!1`"S`58`MP%I`+T!>@##`8P`RP&9`-$!I`#8 M`:\`W@&[`.8!Q@#O`=$`^P':``8"X0`0`N<`&0+L`","\``M`O0`.@+T`&H# M!O]H`PH````F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@````B M_[H!T`!H`P<```#\`@```*```@``!````"T!!@`$````\`$(``@```#Z`@8` M"`````````($````+0$(``0```#P`0<`!P```!@$:`/0`+H!(O\%````%`(` M````"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P``"`````0` M90`:`'H`#@```"8&#P`2`/____\```@````4`.8!1``6`@<```#\`@``@/^` M`@``!````"T!!P`$````\`$&``0````M`0$`!P```!@$%P)%`.8!%``*```` M)@8/``H`_____P$```````X````F!@\`$@#_____```(````.@`$`E\`*@(' M````&`0K`F``!`(Z``H````F!@\`"@#_____`0``````"@```"8&#P`*`/__ M__\!```````*````)@8/``H`_____P$```````H````F!@\`"@#_____`0`` M````"@```"8&#P`*`/____\!```````*````)@8/``H`_____P$```````X` M```F!@\`$@!43E!0!``(```````````````*````)@8/``H`_____P$````` M``0````M`0$`!````"T!!``$````\`$(``0```#P`0<`!````"X'+@+N!T8"W0=7`I@&5P)^!F4"V`5E`L(%50(!^E4"BOGI`2SY#0(@^>\` M!?H8`&O[(`"T`OH!Z0+!`1<#+@%9`[4`'014`-,$60!;!:``"@```"8&#P`* M`/____\!```````.````)@8/`!(`_____P``"`````OXT?^R`?D`#@```"8& M#P`2`/____\```@````+^`0`C_[Y``X````F!@\`$@#_____```(````"_AK M`'+X@P`'````_`(``("`@`(```0````M`0<`!````/`!"``$````+0$!``@` M``#Z`@8`"````,#`P`($````+0$(``0```#P`0D`!P```!L$@P!R^&L`"_@% M````%`(`````"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P`` M"`````OX$0!R^#\`!P```/P"``"`@(`"```$````+0$)``0```#P`0<`!``` M`"T!`0`(````^@(&``@```#`P,`"!````"T!!P`$````\`$(``<````;!#\` M``X````F!@\`$@#_____ M```(`````?B.`?;XI0$'````_`(``("`@`(```0````M`0D`!````/`!!P`$ M````+0$!``@```#Z`@8`"````,#`P`($````+0$'``0```#P`0@`!P```!L$ MI0'V^(X!`?@%````%`(`````"@```"8&#P`*`/____\!```````.````)@8/ M`!(`_____P``"````/;WC@$:^*4!!P```/P"``"`@(`"```$````+0$(``0` M``#P`0D`!````"T!`0`(````^@(&``@```#`P,`"!````"T!"0`$````\`$' M``<````8!*4!&OB.`?;W!0```!0"``````H````F!@\`"@#_____`0`````` M"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P``"````%/^6@"/ M_F4`#@```"8&#P`2`/____\```@````!^*\!]OC'`0<```#\`@``@("``@`` M!````"T!!P`$````\`$(``0````M`0$`"````/H"!@`(````P,#``@0````M M`0@`!````/`!"0`'````&P3'`?;XKP$!^`4````4`@`````*````)@8/``H` M_____P$```````X````F!@\`$@#_____```(````]O>O`1KXQP$'````_`(` M`("`@`(```0````M`0D`!````/`!!P`$````+0$!``@```#Z`@8`"````,#` MP`($````+0$'``0```#P`0@`!P```!@$QP$:^*\!]O<%````%`(`````"@`` M`"8&#P`*`/____\!```````*````)@8/``H`_____P$```````X````F!@\` M$@#_____```(````4_Y,`(_^5P`.````)@8/`!(`_____P``"`````'X:P'V M^(,!!P```/P"``"`@(`"```$````+0$(``0```#P`0D`!````"T!`0`(```` M^@(&``@```#`P,`"!````"T!"0`$````\`$'``<````;!(,!]OAK`0'X!0`` M`!0"``````H````F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@` M``#V]VL!&OB#`0<```#\`@``@("``@``!````"T!!P`$````\`$(``0````M M`0$`"````/H"!@`(````P,#``@0````M`0@`!````/`!"0`'````&`2#`1KX M:P'V]P4````4`@`````*````)@8/``H`_____P$```````H````F!@\`"@#_ M____`0``````"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P`` M"`````_XHO\&"!<"!P```/P"``#_```"```$````+0$)``0```#P`0<`!``` M`"T!`0`(````^@(&``@````````"!````"T!!P`$````\`$(`(`````D`SX` MV_BB_R?XHO\/^`(`7_@"`%_X70'\^/H!'_D*`CWY#P(X^<`!-/EB`4GY$@%F M^=<`C/FC`,/Y<``#^DH`7?HR`-/Z*0`E^SX`8?M?`)/[A0#/^\``]?L!`0[\ M.P$6_',!%OSM`0P##P(,`YD!)0-(`4(#"0%N`\X`K0.:`.T#>``L!&0`FP1D M`-8$<``2!8H`2`6X`'P%]`">!3L!LP6(`;,%V`'^!]8!_@>\`>L'O`'K!Y8! M_0>4`?T'(0'M!PD!90?%`,\&B@`:!E,`5@4D`*($_O_V`^#_NP/@_Y0#\?_= M`@L`3`(8`%/_Z/_F_ M_20!30&F`0<```#\`@``@````@``!````"T!"0`$````\`$(``0````M`0$` M"````/H"!@`(````@````@0````M`0@`!````/`!!P`*````)`,#`-[]:`'> M_9X!10$D`0H````F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@` M``#>_2$`1`&Y``0````M`0$`"````/H"!@`(````@````@0````M`0<`!``` M`/`!"``*````)`,#`-[](0#>_5D`/`&Q``H````F!@\`"@#_____`0`````` M#@```"8&#P`2`/____\```@```#>_78`1`'7``0````M`0$`"````/H"!@`( M````@````@0````M`0@`!````/`!!P`*````)`,#`-[]=@#>_:T`/`'/``H` M```F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@```#>_<<`30$& M`00````M`0$`"````/H"!@`(````@````@0````M`0<`!````/`!"``*```` M)`,#`-[]QP#>_?X`10'H``H````F!@\`"@#_____`0``````#@```"8&#P`2 M`/____\```@```#>_08!30%6`00````M`0$`"````/H"!@`(````@````@0` M```M`0@`!````/`!!P`*````)`,#`-[]%P'>_4X!10$&`0H````F!@\`"@#_ M____`0``````"@```"8&#P`*`/____\!```````*````)@8/``H`_____P$` M``````H````F!@\`"@#_____`0``````"@```"8&#P`*`/____\!```````. M````)@8/`!(`_____P``"````)W^#0`T`9T`#@```"8&#P`2`/____\```@` M``"F``T`-`&=``X````F!@\`$@#_____```(````'0,^`*D%T0('````_`(` M``````(```0````M`0<`!````/`!"0`$````+0$!``@```#Z`@8`"``````` M``($````+0$)``0```#P`0@`!P```!@$T0*I!3X`'0,%````%`(`````"@`` M`"8&#P`*`/____\!```````.````)@8/`!(`_____P``"````"\$Z0&H!'P" M!P```/P"``#_```"```$````+0$(``0```#P`0<`!````"T!`0`(````^@(& M``@````````"!````"T!!P`$````\`$)``X````D`P4`+P1J`EL$Z0%V!.D! MH`1O`FD$=`(*````)@8/``H`_____P$```````X````F!@\`$@#_____```( M````*029`*0$+`$$````+0$!``@```#Z`@8`"`````````($````+0$)``0` M``#P`0<`#@```"0#!0`I!*,`5P0D`7$$)`&`$#!),!?@.\`7D#A@$*```` M)@8/``H`_____P$```````X````F!@\`$@#_____```(````<`./`%$%=P(( M````^@(&`!````#___\"!````"T!!P`$````\`$)``0````M`00`!P```!@$ M=P)1!8\`<`,*````)@8/``H`_____P$```````X````F!@\`$@#_____```( M````U@`\``0!:P`.````)@8/`!(`_____P``"`````($(0'!!.4!!P```/P" M```````"```$````+0$)``0```#P`0@`!````"T!`0`(````^@(&`!````#_ M__\"!````"T!"``$````\`$'``<````8!.4!P00A`0($!0```!0"``````H` M```F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@````E!$7Z?`('````_`(` M`/\```(```0````M`0D`!````/`!"``$````+0$!``@```#Z`@8`"``````` M``($````+0$(``0```#P`0<`#@```"0#!0!M^FH"F/KI`;/ZZ0'=^F\"I_IT M`@H````F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@```!F^ID` MXOHL`00````M`0$`"````/H"!@`(`````````@0````M`0<`!````/`!"``. M````)`,%`&;ZHP"4^B0!L/HD`=KZGP"B^ID`"@```"8&#P`*`/____\!```` M```.````)@8/`!(`_____P``"`````#[2P&3^\0!!````"T!`0`(````^@(& M``@````````"!````"T!"``$````\`$'``X````D`P4`@?M+`0#[>`$`^Y,! MA?N\`8O[A@$*````)@8/``H`_____P$```````X````F!@\`$@#_____```( M````M?E+`4CZQ`$$````+0$!``@```#Z`@8`"`````````($````+0$'``0` M``#P`0@`#@```"0#!0"_^4L!0/IX`4#ZDP&[^;P!M?F&`0H````F!@\`"@#_ M____`0``````#@```"8&#P`2`/____\```@```"L^8\`COMW`@@```#Z`@8` M$````/___P($````+0$(``0```#P`0<`!````"T!!``'````&`1W`H[[CP"L M^0H````F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@```#-_CP` M^_YK``X````F!@\`$@#_____```(````/OHA`?_ZY0$'````_`(```````(` M``0````M`0<`!````/`!"0`$````+0$!``@```#Z`@8`$````/___P($```` M+0$)``0```#P`0@`!P```!@$Y0'_^B$!/OH%````%`(`````"@```"8&#P`* M`/____\!```````.````)@8/`!(`_____P``"````&/Z1P'7^L`!!P```/P" M```````"```$````+0$(``0```#P`0<`!````"T!`0`(````^@(&`!````#_ M__\"!````"T!!P`$````\`$)``<````8!,`!U_I'`6/Z!0```!0"``````H` M```F!@\`"@#_____`0``````"@```"8&#P`*`/____\!```````*````)@8/ M``H`_____P$```````H````F!@\`"@#_____`0``````"@```"8&#P`*`/__ M__\!```````.````)@8/`!(`5$Y04`0`"```````````````"@```"8&#P`* M`/____\!```````$````+0$!``0````M`00`!````/`!!P`$````\`$(``0` M```G`?__!````"T!`@`$````+0$```0````G`?__"````"8&#P`&`/____\! M`!`````F!@\`%@#_____``"$!```+0```*P$``"L````"````/H"```$```` M``````0````M`0<`!````"T!!``(````)0,"`)@$,`"8!(D`!````"T!`0`$ M````\`$'``<```#\`@``````````!````"T!!P`*````)`,#`(<$AP"8!*@` MJ`2'``0````M`0``!````"T!`@`$````\`$'``@````F!@\`!@#_____`0`$ M````+0$$``0````M`0$`!P```!L$D`'.!*@`:`0$````+0$"``0````M`0`` M!0````D"`````@4````4`@`````%````"0(````"!0```!0"``````4````N M`1@````%`````@$!````"0```#(*[0"%!`$```!.`"D`!0```"X!`0````4` M```"`0(````<````^P*0_P```````)`!``````````!4:6UE0`@`!@`&P`:`!@`!0```"X!`0````4````"`0(````%`````@$"````!``` M`"T!!``$````+0$!``<````;!-D#Z09(`T`%!````"T!`@`$````+0$```4` M```)`@````(%````%`(`````!0````D"`````@4````4`@`````%````+@$8 M````!0````(!`0```!P````R"H4#704.````2%0@,B!#;&%S0`@`!@`&P`:`!@`!0```"X!`0````4````"`0(````%`````@$"````!``` M`"T!`0`$````+0$$`!P```#[`A``!P``````O`(``````0("(E-Y.^\$*8WLS>>_?N[KGG_,XYNWOSF%H2.6=:$X51 M!OF.,"FME+FXW_CN6JL]+<9Z'+GK3-?(.3:\+;4CR$$4(?7]QESLK78YD8&V M2'^;\DOJ&'C6W?_,0]%23TX:/KP#W3OIH?3)CTU^Y/&NPR<_\7#Z\,F3'GV\ M5:!W:W\?(I^,X?1]N8Y?;H,>OIX>OQXL?\&T3Y"[\V)E9W\/6D:4A2RJF$)4 M44&$.^X@J1*6R=7KE?=X_=VR`J>LP$U6H.*5/MY#7GIU5Q7A8A4M6_:*/,XB M^+K)"8$;!"H^5!YYTD<,\NE_FRO'")MAJGF\9'C;7Q-M\T]>N-H/L1C/$;C/WV'UFF#UL1M@O3;J= M:3.MUV;;K^Q\VP%+[>U8(<7-HE"MO)MF!/54*OO:XER]X00L\UR&0`.I.F_, M,*-%HJ]4B_22D/5,X+B'J=Z[TQ2J1V49--A)IJ-#\MULXT ME?R<.<0OFG)>9$JYP)1PH?%RL2GF$O,&EYNU7&%6\VDSAY^QF;S-3N,S-HT[ M8@P/1HJ44+T1JN41]CX*GF?WD1?C@K05<[X=Y]03DQFF&?%;Y[UQ3IY(S;,/ M.'U0S$W)I=>XR&8Y;MYK>B0UY-)K[)-<(SXANX$C[6:.LMNYJ]W#/>P!CK=' MN*\]R8-L#0^QI.ZQUZAA-EJ-L+$JW6Y5F=:J;!OGS+%E.;E4G!/ MI?(6]K6Y>:/I\5OGC2T\FA]R1HO4:I'>E%Q:PW%JEJLWKGQF&R52NZ@U'*'6 ML^:WQ=JM7,GO\2$NXW+^A$OY&)?P*?;R>2YF1[W!UZFU'*-6\\_5''Y793([ MT_@F)XV3G3'\M),BY>KGTD*9=Q(Y6)L7"4';\FT"UQ.3%;K9,V&"Y-%"69L2 MN`\6HBFY]!R*[#B^NC-A@7T./LDU9A[(+D"D780HNQQ=[;_0P[Z)>+L5?>U. M#++E&&(K<(_]&L/L!8RPX91N\RC3'J9LVX+GVWA>:E-YA93FY=+BH)Y*Y;HV M-V]E%S*09QZR-4;5SZSC1*I750.(M2+T)PKUN:ADE_% M(2Y".;^%4GX7)5P*+W\D\_!QO,'_Q5HV6,TM:0Z_3)E<0=,XDM.X#X_A/W"* ME.;D4J@TRG$3XBG==3=Q,W!Q-_4WE[PVI;&XS?"3&$2OHY]Y'=5ZK)21.*N3 M<$;?A9-Z,([I?OA4]\9^W1-[],W8+F63E'527ZEO0YX>A`4Z$<_+F&R=@IGZ M?F3J]?Z2H#=@@-Z$GMJ+6+T3/]7[T%X?1&M]#"WT&2A=*]J&R4ZZ';&.H7`= M2ZUT+VJO;Z<8/91B]=W44_^&!NA[Z4XI?]%+I+Q*,W4A9>L-E*/?H;_K[;18 MOT\%NI2*]&YZ2\HVJ>^6YP>D_3.]D2JE_RF]F*I%AJ_T-Z&2]B)##Z9:?2GN MEOUX;\:7B7T/^49W\M2*I`PAX=M9=U#-C8$%-L9,X))&5Y=0YR?V:WB#I\29 MP#%F@6U<0S=MWL<4#*#-KFV[_6T?NT9K&(:9&FH--[[\H[Q.]D=K#QE5:<+Q ML8G$^^9:;#:=4&2ZH,#$89&)QWPS&+--$IXV#V**F8H))@=CS)'7 M\(WVW3QNF,D:B!@A4B5$C@J142(C!( M+!,BJX3(FT+$*T1V"9']0N2P$#DAVI_S6Q".;B$3Z8;'3)F1;-Y318Z;;9?+-30L/S40TO>3JEPYB=2*579I?X?6ZS`CU$5NGR3YSIXSJ M$/+[!]([9BQ];NI&?V'&27U@LU:1T/.X$OTHR;7M6SL+)V@H-Y:KSJ6(_-;& M4*UM2\82.3B'5B*Y'0XA&A^@.]Y#/#8C`>N0@A68B#S,P$M8@'E8@SG8AFQ\ MB-GX"K/DW;-P'YS%#?@"/\-!],9>#,$.C$0Q)N%U9&&5,,E' M(99@N^Q=#R`7I^0)2V2VHUQTIW^B/^7AUY2/,;02CU*A+`(;\#QM1BYMPW+: MA2+Z`,7T*7;0"?Q'2'PH)#ZE,*J@MO0Y74\G*99\%ERPR2$3B4*!$$YVW10HXJ^02?95;I^1XC5_:DN^_R1"F\C.]EH?D1[T46&(52W1 M4;5%I.H(PYUQCF/Q)??"9_Q+V07?BUW\`+;RX]C`&G:#W/I4V<2__FY;23"VDO%]-'O(.. M2#%*Z.TK7J!%VO3M.-JHIN434T4/DL",?$D(ETD^^5,IK8 MZ/]!0EU')SIE5,Q7MHX^3-$TW;6M@UB=2%&J7L,L9%UV'>VH[I1135E'/6JL MQ%/=Z%^H<5*_^NMHTW.YX9>+^L.M_W=MUXH#/=WVQO4[_3BN_Y7D?[7-@OU@ M(1OP0P@``/FYFT71,+_JZ.F1W%4U+4\4'```]?<``*+^```0"`$`U0(!`*#= M8P"@"1H`$0@```#^>)RU60U0%.<9?M]O=^_XBQCK%(*#R`"QSI`X36W33H`D M;1*TJ$-B#$/5.%:A04;P;\3,6`>J=AS3@:;03+`U.BBF&G^BUEH;IIXQ"9W\ M&;2"U_/1#B`92$ M<0`NV`R!0V-)%"WRUD#@+$E\1YTT7N&SR<"3X'Y7,DP`X@,@CJ]O#;3(\7$7 M1,+06((U)BRDE*%[V=8]%=+X^MFYQ<4384[%TM75:ZK+UTXIKJXI6UU<75&U M-G%H=I(U!R"`40QWXBH6;HA'8*9J\4#^"\?^!WPVP%:F63-J`U);"QZ/!]@( ML$P9NA_XJ!TZJ1VZ",SS?.J!O>_W`9E]L&O7'FN]M8H"ZP=/:.@B@*?RG1EL M0(#O=VW]EN@]24=1CWJL3IZD\SQB-S:73E-#F+$F>H>6@MMV3/=WRU;Y,;GY MW"P#%T'V7]=YO.0EQ%15A%?T*#?H'_I0".G4ZG M/`[XSLG?B*R(-@_R4*'`XI$.)WQ2/N'WRC=9'I=]LIWE>>J3/713YH!?+H1X M:H8,CN3#]#JV4JJX2*5"P&2!K/,5.N0[08O$)-@FO@%K1#\5\7@OS]N!&^A3 M2*>$Q1MU-^7H3_5JOH[_IJZA?7T8/&?.IS'B*=AH/TWDCE\:9651@3J*?F1-I MCYE`%TU!\3Y#YOG^+7\6 M/D/_XLC5@Y3Y\+DTJ5O6<10^DQWR6[)3;O=?YFA\+O?[WOU:F3=%3P4E;H4( M1@1NBT@HWYS5!\+WK(CMI7E0S3='^+?W09^Y7Y0?.5^2EQQEXA7 M725BHZM,7-3*Q-O:?('&?+%-[\5<_1XQ1;\!FI$*E>84^*,PL%>ZW$0139P2O??RVD=MV8Q>.2$V(=:#;!YEQ'MC9#.+URZQ M93-ZUH38A%@/LEG"B+-B9/,R5'GU,8I48'^0%J=#A?>WC&S`^]YO\[=3+O/D M/,ZHYVW'T%N/_=Y6',L8MC)B/6(,7NL?J,>T,&QBBV$JLTD+V#@P.AOGOOP) M^[(LC"\/L^7MMNQCKLD[TMY(I+$6.SLZF%P'.T M`"XSZE269*^`Q98L0I_7P`P]0>3KR>+[N@=GZ#_%6?H$+->[X%?Z;CBCKP3% M^#$L,AZ"\\8TR#$+8(FY&!K-+7#6],`M$W&<[Q'\IF\-RW5,4I)%DM*,.P2/\?/]F'81 MI;N3I0V_M.05]+N;6#+QNCL>R]SOPEG7-DASS8/GM&QH427U*U?I+98FY3]T M123";)$*\^@+NN;_@.I]1^BJV6J[H['S>HV\P#NO).%LWXR0:ODUP5I7(P?P M$*KB$(Z'QU&#-\"DB7"3CM*7]`SUT"?RDF,>6=1!L\&^ZU\V,ZC.MS',6\]H MU55K\P8RF,\;&3&#+IO15Y?7S*<4WT(:;;_G-$^#U;60$?/)&P.;>N81SF_= M_FR<@WO1SF_JJ'V@UB;R"5;D%49]`;O]K^&3F(U.67;[,^$)/!E!5ZAZ0[HR M64HA#X\X]DBW?QWKZHK!KG4L!UG7V2ATM<,<=&'T=K6S2'@2OXA"EXNC^5P$ M779VI7"\YG*\7+;Q&NM[=MQWR'M@!NZP'=L+XQ[)+K185ZEKAE-$TM1GV MJ+FV.3'2`SBLA@Q$X4:?2WDJ(6X7?78L@GZ1HO`1KNK,CV,6(@Y$=A\W3Z42_:] MIE0O@&NF?:^)MKJUX5YSC?>.I7KT_EUA]&*/8=]KPD<[W*XM6`\KC.7B548^ MQG+%J!:O&\Y[3;G1#)\9D7I-Z%D7U%EN[(8F(QO?9+ED[(06PWFO`;,(&\U( M=3_2SCI>!^9ZED;<8K;A2Z;SNC^N%^%,PVE_"]EYBM<]9JQG:<2W]#8\KCO7 M>4!O@'HS7*^Y._M"W:7>;."U3K5\)//`E/;=I<#(1#+LNTNL]=S#B)E88$2? M_4N-0NPR[+M+^%JT[]#:<'?I8M2E$=C\_W9#H?^`!0^[^4&;[-Y[@Q4_%8/_ M7_L?/?@X&P`````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````````````#^_P``!``"```` M```````````````````!````X(6?\OE/:!"KD0@`*R>SV3````#840``#``` M``$```!H`````@```'`````$````B`````@```"@````"0```+@````2```` MQ`````H```#D````"P```/`````,````_`````T````(`0``#P```!0!```1 M````'`$```(```#D!```'@````\```!.;R!3;&ED92!4:71L90``'@````T` M``!.86YC>2!#;W1T97(`90``'@````T```!.86YC>2!#;W1T97(`90``'@`` M``,````Q-0!C'@```!4```!-:6-R;W-O9G0@4&]W97)0;VEN=```4`!````` M`)1G5A(```!`````(,9^-A;&O0%`````P$M2L4(8O`%`````T*,XS4O&O0$# M````-0```$<```"T4```_____P,````(`&\030P```$`"0```U(H```"`*$G M`````!$````F!@\`&`#_____```0````````````N@,``,H"```)````)@8/ M``@`_____P(````7````)@8/`",`_____P0`&P!43E!0%`!P\``P`````!0` M``#D%WH`````````"@```"8&#P`*`%1.4%````(`]`,)````)@8/``@`____ M_P,````/````)@8/`!0`5$Y04`0`#``!`````0`````````%````"P(````` M!0````P"R@*Z`P4````)`@````(%`````0+___\"!0````0!#0````4````' M`0,```"A)P``00L@`,P`>`"@``````#*`KH#`````"@```"@````>`````$` M"````````$L```````````````````````````````"```"`````@(``@``` M`(``@`"`@```P,#``,#WM[>WM[>WM[>WM[>WM[>WM[>WM[>WM[>WM M[>W______P#_________________________________________________ M____________________________________________________________ M______________________________________________________\````` M``````````````````````````````````#M______\`_P#_____________ M_____________P#_____________________________________________ M____________________________________________________________ M____________________________`/______________________________ M______\`[?________\`__________________________\`____________ M____________________________________________________________ M____________________________________________________________ M_P#_____________________________________`.W__________P#_____ M_________P#_________`/______________________________________ M____________________________________________________________ M__________________________________\`________________________ M_____________P#M_________P``______________\`_________P#_____ M____________________________________________________________ M____________________________________________________________ M________`/____________________________________\`[?______`/__ M________________`/__________________________________________ M____________________________________________________________ M_________________________________________P#_________________ M____________________`.W______P#__________________P#_________ M____________________________________________________________ M____________________________________________________________ M______________\`_____________________________________P#M____ M__\`________________________________________________________ M____________________________________________________________ M________________________________________________`/\``/\``/\` M`/\`````_P```````/________\`[?______`/______________________ M______\`____________________________________________________ M____________________________________________________________ M_____________________P#_``#_``#_`/________\``/______________ M`.W_____________________________________`/__________________ M____________________________________________________________ M______________________________________________________\`____ M_________________________________P#M________________________ M__\`_________P#_____________________________________________ M____________________________________________________________ M____________________________`/______________________________ M______\`[?__________________________`/________\`____________ M____________________________________________________________ M__\`________________________________________________________ M_P#_____________________________________`.W______P#_________ M_________P#_________________________________________________ M________________________`/\``/\`_P#_`/______________________ M__________________________________\`____________`/__________ M_____________P#M______\`__________________\`________________ M_________________________________________________________P`` M____`/______________________________________________________ M________`/\`_P```/\```#_`/\`__________________\`[?______`/__ M____________________________________________________________ M____________________________________________________________ M_________________________________________P#_`/\``/_______P#_ M`/__________________`.W______P#_____________________________ M`/__________________________________________________________ M____________________________________________________________ M______________\`_____________________________________P#M____ M_________________________________P#_________________________ M____________________________________________________________ M________________________________________________`/__________ M__________________________\`[?__________________________`/__ M______\`____________________________________________________ M____________________________________________________________ M_____________________P#_`/\``/\`_P#_``````#_````____________ M`.W__________________________P#_________`/__________________ M____________________________________________________________ M______________________________________________________\`_P`` M____````_________________________P#M______\`________________ M__\`________________________________________________________ M____________________________________________________________ M____________________________`/______________________________ M______\`[?______`/__________________`/______________________ M____________________________________________________________ M____________________________________________________________ M_P#_`````/\```````#_`/\``````/\``````/__`.W______P#__P#_____ M____________________________________________________________ M____________________________________________________________ M__________________________________\`_P``______\`_____P```/__ M_____________P#M______\`_P#__________________________P#_____ M____________________________________________________________ M____________________________________________________________ M________`/____________________________________\`[?_______P#_ M`/________________________\`________________________________ M____________________________________________________________ M_________________________________________P#_````_P#_________ M____________________`.W__________P#______________P#_________ M`/__________________________________________________________ M____________________________________________________________ M______________\`_P``````_____________________________P#M____ M_____P``______________\`__\```#__P#_________________________ M____________________________________________________________ M________________________________________________`/__________ M_________________P#_______\`[?______`/\``/______________`/__ M`/\`________________________________________________________ M____________________________________________________________ M_____________________P#___________________\`````````________ M`.W______P#_``#______________P#__P```/______________________ M____________________________________________________________ M______________________________________________________\`____ M________________`/__`/\`_________P#M______\`________________ M_________P#_________________________________________________ M____________________________________________________________ M____________________________`/______________________________ M______\`[?______`/\``/____________________\`__\`[>WM[>WM[>WM M[>WM[>WM[>WM[>WM[>WM[>WM[>WM[>WM[>W_________________________ M____________________________________________________________ M_P#___________________\`_P````#_________`.W_________``#_____ M_____________P``____```````````````````````````````````````` M``````#M____________________________[>WM[>WM[>WM[>WM[>WM[>WM M[>WM[>WM[>WM[>WM[>W_______________\`____________________```` M_____________P#M_________P``______________\`____``#__P#_____ M______________________________________\`[?__________________ M________``````````````````````````````````````````#M________ M________`/_______________________________P#_`/\`[?__________ M_P#_____________`/____\`__\`________________________________ M____________`.W__________________________P#_________________ M______________________\`[?_______________P#_________________ M__\```#_`/____\```#_`.W______P#_``#______________P#__P#_`/__ M`/___________________________________________P#M____________ M______________\`________________________________________`.W_ M______________\`____________________``````#___\```````#M____ M__\`____`/____________\`__\```#__P#_________________________ M__________________\`[?__________________________`/__________ M_____________________________P#M________________`/__________ M_____________________P``__\`[?______`/\``/__________________ M`/\`__\`____________________________________________`.W_____ M_____________________P#_____________________________________ M__\`[?_______________P`````````````````````````````````````` M`/_______P#___\`_________________P```/__`/__________________ M_________________________P#M__________________________\`____ M____________________________________`.W_____________________ M_____________________________P#_____________________________ M______\`_P#__P#___________________________________________\` M[?__________________________`/______________________________ M_________P#M________________________________________________ M____________________________________`/__````__\`____________ M________________________________`.W_________________________ M_P#_______________________________________\`[?______________ M____________________________________________________``#_____ M_________P#_________`/______________________________________ M_____P#M__________________________\`________________________ M________________`.W_________________________________________ M______________________\`__\`______________\`__\``/___P#_____ M______________________________________\`[?__________________ M________`/____\``/\``/\``/\`````_P```````/_______P#M________ M________________________________________________________`/\` M________________`/__`/\`__\`________________________________ M____________`.W__________________________P#_____``#__P#_`/__ M______\``/____________\`[?__________________________________ M_____________________________P#__P#__________________P```/__ M`/___________________________________________P#M____________ M______________\`________________________________________`.W_ M____________________________________________________________ M__\`_P``_________________________P#_________________________ M__________________\`[?__________________________`/____\```#_ M_P#_````_P````````#__________P#M____________________________ M______________________________________\``/__________________ M`/\`__\`__\``/\``/\`````_P```/\``````/\`____________`.W_____ M_____________________P#_____`````/\`_P``____________________ M__\`[?______________________________________________________ M____________`/_______________P#__P```/__`/__``#_``#_``#___\` M____````_________________P#M__________________________\`____ M____________________________________`.W_____________________ M_____________________________________________P```/__________ M__\`__\`_P#__P#___________________________________________\` M[?________________\`________`/______________________________ M_________P#M________________________________________________ M________________`/\``/______________`/________\`____________ M________________________________`.W_____`/\``/\`_P#_`/______ M_P#_______________________________________\`[?______________ M_________________________________________________P#_________ M_________P#_________`/______________________________________ M_____P#M_____P``____`/____________\`________________________ M________________`.W_________________________________________ M______________________\`_P``__________________\```#__P#_____ M______________________________________\`[?__________________ M________`/_______________________________________P#M________ M________________________________________________________`/\` M`/__________________`/\`__\`__\``````/\`_P```/\``````/______ M____________`.W__________________________P#_________________ M______________________\`[?__________________________________ M________________________________``#__________________P```/__ M`/_______________P#__P#______________________P#M____________ M______________\`________________________________________`.W_ M__________________________________\`________________________ M_____P``______________\`__\```#__P#_________________________ M__________________\`[?__________________________`/__________ M_____________________________P#M________________________`/\` M`/\`_P#_`/______________________________________________`/__ M`/\`__\`____________________________________________`.W_____ M_____________________P#_______________________________\`____ M__\`[?_______________________P``____`/______________________ M_________P#_````_____________P#_____`/__`/__````_P#_________ M_________________________P#M__________________________\`__\` M``#_``#_____________`````````/______`.W_____________________ M__________________________________________\`_P#_____________ M__\`__\`_____P#__P``````__________________________________\` M[?__________________________`/_______________________P#__P#_ M`/_______P#M________________________________________________ M________________`/__`/___________________P``__\`____________ M________________________________`.W_________________________ M_P#_______________________________________\`[?______________ M_________________________________________________P#_`/\`____ M_____________P``____`/______________________________________ M_____P#M__________________________\`__\``````/\```#_________ M`/\`````________`.W_________________________________________ M_____________________________________________________P#_____ M______________________________________\`[?__________________ M________`/_______________________P```/___________P#M________ M____________________________________________________________ M________________`/\```#___\`________________________________ M_P#___\`_P#_`.W__________________________P#__P#_`````/______ M_________________P#_`/\`[?__________________________________ M_________________________________________________P#_`/\`____ M`/________________________\`````````____````_P#M____________ M______________\`________________________````__\`__\```#_`.W_ M____________________________________________________________ M__\`__________________\`_P```/___P#_________________________ M`/__`/\`____````````[?__________________________`/__________ M_____________P````#_``````````#M____________________________ M____________________________________`/__________________`/__ M______\`______________________________________\``/__`.W_____ M_____________________P#___________________________________\` M__\`[?______________________________________________________ M_________P#_________________________`/__`/__________________ M_____________________P#__P#M__________________________\````` M`````````````````````````````````````/______________________ M__________________________________________\`________________ M_____P``+0``_P`````````````````````````````````````````````` M____________________________________________________________ M____________________________________________________________ M__________________________\`````____`````"T```````#___\````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````````````````````````````````````````````````````/__ M_________P```#(`,@#_`/______________________________________ M____________________________________________________________ M____________________________________________________________ M__________________________________________\`````-RP`_P#_____ M_________________P<'`/__````````````````__\`````____________ M______________\``/\```#_`````/___P````#__P```/\```#_`/____\` M``#_____________________________________________________`/__ M________________````,@`R`/________________________\'`/___P`` M^0$!`0$!^0#Y__\```#Y^?___________________________P#_`/___P#_ M_P```/\``/____\`_P#__P#__P#_``#_`/__________________________ M_____________________________P#__________________P#_`"P`+`#_ M________________________!P``__\``/D!`0$!`?D`^0#__P````#_____ M_____________________P``_P```/\``/\`_P#_`````/__````_P```/\` M`/\`_P``____________________________________________________ M__\`____________________````1S(`_________________________P`` M^0```/D``0$!`````````````/__________________________________ M____________________________________________________________ M____________________________________`/___________________P`` M*P`L`/\`______________________\``````````````/\``````/______ M____________________________________________________________ M____________________________________________________________ M____________________`````/___P``````````````____`````/___P`` M``#___\```````````````#__P````#___\`````____`````/___P````#_ M__\`````____`````/___P````#___\`````____`````/___P````#___\` M````____`````/___P````#___\`````____`````/___P````#_________ M__\`_________P#_____________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________`/________\`____________ M____________________________________________________________ M_________________________________________________________^WM M[>WM[>WM[>WM[>WM[>WM[>WM[>WM[>WM[>WM[>WM[>WM[>WM[0#_________ M_________P#_________________________________________________ M____________________________________________________________ M_____________________________P`````````````````````````````` M````````````````````````__________________\`________________ M____________________________________________________________ M____________________________________________________________ M__\``/\`______________________________________________\``/__ M____________________________________________________________ M____________________________________________________________ M____________________________________`````/__________`/______ M____________________________``#_____________________________ M`/__________________________________________________________ M____________________________________________________________ M_________P``E0#__P````````#_________________________________ M_P#M_____________________________P#_________________________ M____________________________________________________________ M__________________________________________\``````/\`__\`_P#_ M__________________________________\`[?__________________`/__ M______\`____________________________________________________ M____________``#_____________________________________________ M________________`/\`________________________________________ M________`.W__________________P#_________`/__________________ M_____________________________________________P``____________ M_________________________________________________P#_________ M____`````/\`````_P#_``#_``#______________P#M________________ M__\`________________________________________________________ M____________________________________________________________ M______________________\`____________________________________ M______________\`[?__________________`/______________________ M_____________________________________________________P#_____ M______________________________________\`________________`/__ M________________________________________________`.W_________ M____________________________________________________________ M_________________________P``________________________________ M`/\``/\`_P#_`/_______________P#_____________________________ M_____________________P#M_____________________________P#_____ M____________________________________________________________ M`/_______________________________P``____`/__________________ M__\`__________________________________________________\`[?__ M__________________________\`________________________________ M_________________________________P#_________________________ M____________________________________`/______________________ M____________________________`.W__________________P#_________ M`/__________________________________________________________ M______\`____________________________________________________ M_________P#_______\`_P``_P#_``````````#_````_P#_````________ M_P#M__________________\`_________P#_________________________ M________________________________________`/__________________ M__________________________________________\`________________ M__________________________________\`[?__________________`/__ M____________________________________________________________ M_____________P#_____________________________________________ M________________`/__________________________________________ M________`.W__________________P#_____________________________ M____________________________________________________________ M_________________________________________________P#_________ M_________________________________________P#M________________ M____________________________________________________________ M____________________________________________________________ M______________________\`____________________________________ M______________\`[?____________________________\`____________ M____________________________________________________________ M________________________________________________________```` M`````````````````````````````````````````````````/__________ M!0````0`N`#(` M,`"Z#RP```!-`&D`8P!R`&\`0`/ M`/(#)`$``"\`R`\,````,`#2#P0`````````#P#5!TP``````++````#P#Z`V<``````/X#`P`` M```!````_0,T````9````&0```!D````9````(S1$@`+WP,PA-$2``@```#R M%@``V`\``++___^.____`````'``^P,(`````````'`(``!P`/L#"`````$` M``!`"P``'P#_`Q0````"```$#````````````````@```#\`V0\,``````#: M#P0``````"4`#P#P#QP``````/,#%`````0````$```````````!```````` M``#J`P`````/`/@#30D```(`[P,8`````0````$"!PD(```````````````` M``4P8`#P!R````#___\``````):6E@```````,R9`#,SS`#,S/\`LK*R`&`` M\`<@``````#_`/___P``````__\``/^9````__\`_P`S`):6E@!@`/`'(``` M`/__S```````@(```)F9,P`SF3,`@``````SS`#_S&8`8`#P!R````#___\` M`````#DY.0``````R\O+`(:&A@!-34T`ZNKJ`&``\`<@````____``````"? MGY\``````/_,9@```/\`S`#,`,#`P`!@`/`'(````/___P``````AH:&```` M``#+R\L``&;_`/\`,P``F0``8`#P!R````#___\``````):6E@``````,YG_ M`)G_S`#,`,P`LK*R````HP\^`````0#__3\````B(```9````````0!D```` M````````0`(``````@```/__[P``````________+``````#```0`*,/?``` M``4`__T_``$`(B```&0`````````9``4````V````$`"``````(```#__^\` M`````/_______R```````0``@`4``!,@U`$@`0```@`<`(`%```B(-`"0`(` M``(`&`"`!0``$R#P`V`#```"`!0`@`4``"(@$`6`!``````@`*,/;@````4` M__T_````(B```&0`````````9``>`````````$`"``````(```#__^\````` M`/_______PP``````0````4``"`!(`$```````4``$`"0`(```````4``&`# M8`,```````4``(`$@`0`````4`"C#U(````%`````0D``````0`````````! M``$)``````$`(`$``````@`!"0`````!`$`"``````,``0D``````0!@`P`` M```$``$)``````$`@`0`````8`"C#PP````!``````````````!P`*,//@`` M``4````````````"`!P``0`````````"`!@``@`````````"`!0``P`````` M```"`!(`!``````````"`!(`@`"C#SX````%`````````````@`8``$````` M`````@`4``(``````````@`2``,``````````@`0``0``````````@`0``\` M#`2K!0``#P`"\*,%```0``CP"`````8````&!```#P`#\#L%```/``3P*``` M``$`"?`0``````````````````````````(`"O`(``````0```4````/``3P M]@```!(`"O`(`````@0````*``#S``OP6@```'\``0`!`(``%"AZ`($`JV@`/``WP5```````GP\$```````````` MJ`\@````0VQI8VL@=&\@961I="!-87-T97(@=&ET;&4@``````"?#P0````!``````"H#U(```!#;&EC:R!T;R!E9&ET($UA M6QE@`/``WP/0``````GP\$````!```````J`\! M````*@``H0\4`````@````````````(```````(`#@```/@/!``````````/ M``3PYP```!(`"O`(````!00````*```#`0OP8````'\``0`!`(``-"EZ`($` MJV@`/``WP/P``````GP\$ M````!```````J`\!````*@``H0\6`````@````````@```$``@```````@`. M````^@\$``````````\`!/#G````$@`*\`@````&!`````H```,!"_!@```` M?P`!``$`@`"4*7H`@0"K9P$`@@#6LP``@P"K9P$`A`#6LP``A0`"````AP`! M````OP`0`!\`@0$$```(@P$````(OP$!`!$`P`$!```(_P$!``D``0("```( M/P(```(````0\`@```!@#R`0T!2`$`\`$?`0``````##"P@````$````"`)Z M``\`#?`_``````"?#P0````$``````"H#P$````J``"A#Q8````"```````` M"````@`"```````"``X```#8#P0`````````#P`$\$@````2``KP"`````$$ M````#```@P`+\#````"!`0````B3`8Z?BP"4`=Z]:`"_`1(`$@#_`0``"``_ M`@```@`$`PD````_`P$``0`0`/`'(````/___P``````EI:6````````S)D` M,S/,`,S,_P"RLK(`#P#P`^`````!`/$#"````````(````HP#P`,!*`````/ M``+PF````"``"/`(`````0````$(```/``/P,`````\`!/`H`````0`)\!`` M`````````````````````````@`*\`@`````"```!0````\`!/!(````$@`* M\`@````!"`````P``(,`"_`P````@0$````(@P$%```(DP'>O6@`E`&.GXL` MOP$2`!(`_P$```@`!`,)````/P,!``$`$`#P!R````#___\``````("`@``` M`````,R9`#,SS`#,S/\`LK*R``\`[@,*&@```@#O`Q@````0```````````` M``````"```````<`!3`/`-D/#```````V@\$```````E``\`#`2F&0``#P`" M\)X9```P``CP"````"4````R#```#P`#\#89```/``3P*`````$`"?`0```` M``````````````````!8``(`"O`(``````P```4````/``3P<````!(`"O`( M`````@P````*``##``OP2````(4``@```(<``0```($!````"+\!$``0`,`! M`0``",L!G#$``/\!"``(``$"`@``"`4"J"D!``8"J"D!`#\"`@`"`+\"```( M````$/`(````\`,0`N@&R`@/``3PH@```!(`"O`(`````PP````*``#C``OP M5````(``]"EZ`($`JV@"!`*MG M`0""`-:S``"#`*MG`0"$`-:S``"%``(```"_`!(`'P"!`00```B#`0````B_ M`0``$`#``0$```C_`0``"``!`@(```@_`@```@```!#P"````&`)4!!;%+\, M#P`-\+```````)\/!`````0``````*@/2````$A4,PU%9'5C871I;VX@0VQA M0T` M`*$/)`````\````!```````!````````````#P`````````!```````````` MJ@\2````"`````$````#``@`````````#P`$\,,````2``KP"````!(,```` M"@``\P`+\%H````$````6P"``%0M>@"!`*MG`0""`-:S``"#`*MG`0"$`-:S M``"%``(```"_`!(`'P"!`00```B#`0````B_`0``$`#``0$```C_`0``"``! M`@(```@_`@```@```!#P"````&`,8!4@%E4.#P`-\#D``````)\/!`````0` M`````*@/!P```%!A````P@`*\`@````9 M#`````H``),`"_`V````A0`"````AP`!````@0$$```(OP$0`!``P`$!```( MRP&<,0``_P$(``@``0("```(/P(```(````0\`@```"P`<`/2!`\`@\`!/"" M````0@$*\`@````<#`````H``/,`"_!:````A0`"````AP`!````1`$$```` M?P$```$`OP$``!``P`$!```(RP&<,0``S@$&````T@$`````TP$`````U`$` M````U0$`````_P$8`!@``0("```(/P(```(````0\`@```#``P``@!;``P\` M!/""````0@$*\`@````=#`````H``/,`"_!:````A0`"````AP`!````1`$$ M````?P$```$`OP$``!``P`$!```(RP&<,0``S@$&````T@$`````TP$````` MU`$`````U0$`````_P$8`!@``0("```(/P(```(````0\`@```#0`@``@!;0 M`@\`!/""````0@$*\`@````>#`````H``/,`"_!:````A0`"````AP`!```` M1`$$````?P$```$`OP$``!``P`$!```(RP&<,0``S@$&````T@$`````TP$` M````U`$`````U0$`````_P$8`!@``0("```(/P(```(````0\`@```#``V`# M(!;``P\`!/""````0@$*\`@````?#```@`H``/,`"_!:````A0`"````AP`! M````1`$$````?P$```$`OP$``!``P`$!```(RP&<,0``S@$&````T@$````` MTP$`````U`$`````U0$`````_P$8`!@``0("```(/P(```(````0\`@````0 M`F`58!6`$`\`!/"(````0@$*\`@````@#`````H```,!"_!@````!````*;_ MA0`"````AP`!````1`$$````?P$```$`OP$``!``P`$!```(RP&<,0``S@$& M````T@$`````TP$`````U`$`````U0$`````_P$8`!@``0("```(/P(```(` M```0\`@````@_A`"$0+@$`\`!/"(````0@$*\`@````B#`````H```,!"_!@ M````!````*;_A0`"````AP`!````1`$$````?P$```$`OP$``!``P`$!```( MRP&<,0``S@$&````T@$`````TP$`````U`$`````U0$`````_P$8`!@``0(" M```(/P(```(````0\`@```#0__``\0"0$@\`!/!@````L@0*\`@````D#``` M$`H``&,`"_`D````!$$"````"P$"````/P$```$`OP$``!``_P$```@`/P(` M``(````0\`@```"@`B`![0$-!`\`$?`,``````#!"P0````"````#P`$\&`` M``"R!`KP"````"4,```0"@``8P`+\"0````$00,````+`0,````_`0```0"_ M`0``$`#_`0``"``_`@```@```!#P"````-`"L`3@!Z4##P`1\`P``````,$+ M!`````,````/``3P:@```$(!"O`(````)PP````*``"S``OP0@```(4``@`` M`(<``0```$0!!````'\!```!`+\!```0`,`!`0``",L!G#$``-$!`0```/\! M&``8``$"`@``"#\"```"````$/`(````8``P"3`)4`$/``3PQ@```*(,"O`( M````*`P````*``#C``OP5````(``="YZ`+\``@`"`($!!```"(,!````"+\! M```0`,`!`0``",L!G#$``-(!`````-,!`````-0!`````-4!`````/\!```( M``$"`@``"#\"```"````$/`(````4`'0")H)'0,/``WP0@``````GP\$```` M!```````J`\"````3DX``*$/)`````,````````````!`````0`"``$`#@`" M```````&`!P```````\`!/#<````H@P*\`@````I#`````H```,!"_!@```` M@``T+WH`A0`"````AP`&````OP`"``(`@0$$```(@P$````(OP$``!``P`$! M```(RP&<,0``T@$`````TP$`````U`$`````U0$`````_P$```@``0("```( M/P(```(````0\`@````@!&`,W@VS!0\`#?!,``````"?#P0````$``````"H M#Q````!(5"`R#4-L87-S#4QO8F)Y``"A#R`````1````````````$`````$` M`@`!``P``0```````@`<``\`!/#L````H@P*\`@````J#`````H```,!"_!@ M````@``$`BT!A0`"````AP`&````OP`"``(`@0$$```(@P$````(OP$``!`` MP`$!```(RP&<,0``T@$`````TP$`````U`$`````U0$`````_P$```@``0(" M```(/P(```(````0\`@```"0!H`*T`VP!P\`#?!<``````"?#P0````$```` M``"H#R````!(5"`R($-L87-S)SM6@U45546WOO0H] MT+(Z[9Y^[S][?_CL7J#C8K7KUIL`3<-48`1HHZ@C>5\RABQRC M*X!PW2LB5_];\UX_IHX_@MI/%/)@3#*)C.5QO,NKH4-#L".&+A887'7E$C>?QJDPX,P$1YKU=[&Z,Y5Z$I[/'WN2==5\+Y6 M2(88MCP9,F"@X\?ST0L$&C70L,G3_0W31:#S.[KV#^==HR&)/9`*,_G>TQ'8 M!OL-/V5K[OV=^:NY]&I-_E_/^9_^0/:BYNN,W:MSUPC1!U(GV=(RTJ9D!D=: M4],C;)G!]R99K!O)K M_>M'P,)M@V'XW9W[Z+KOZN*-9E\FAP`C/H1Z=^':;$ASUI%#4EZZ7>PS0LW! M\W7PA$-23]=<7\>EQ1?3%I#V1;(M)2YV>VD`U=6,S#WW`-\"Y?/5 M;N=][(YEV:Z/;->7;->-G=?8C]KAU7VU0)=J(3__%9[.!D>))@-IYQ=RW1A0 M&5X8))S=Y`Y3''W4;%F'D[6V\:JI*9Z=CC?)*U!]R>@'NG"@()S1'ECB37O'#->SNN/(1S7G-TD4"?OI3'4O-8ZB":+7W4#WV'5_FN49=CTBJ+ M562C+MEP61>+XUK+.C6O`[K6:="?KWVUGT&ALDI#I2CE&'9-CU5?2IN:J+&57.>IKM5CUH%7J M+EK+9&:1IU;>"W.:]%0\&KPP4V]H+LLL+2#0B)33&W-D`DLTJ(ZEEWFL9QRF MR3`QVM0;C2BW%!%NG=W>>)BE]A%ITD?,D#H^S=;.E36X0![%%V45+I?E6"C+ ML$C:L4268)E\`ZOD1JR6Z_$;N1"?45FX2\W$L\J*/6D\CJ`X)D^]X:GE/NH1 M:#K/'@$[36B"5X(%:H+F1HPK3#OBU^F]"5H>2\U32=H@*L'6Y-+K6*RR-3/O MM3Z2&G/I=30DU[-/0&U%7[4=`]1N#%8'L)_Z",/5<1RL3N-P58\C%8C[U`UB MC`H48U6HL*F=(DLID:/"M,5JK+9*/:FM96I?+C7MJ7C<@0;/S!NMCU^G-W9@ M`D[2$EAJ'4MO32YMP#`QS]0;;:]L#[/4/F(#^H@MJ./;;.U.K,'W\"A68!5^ MBN5X$LOP#-KQ`I:@)M[`;F(C!HGU^$NQ$-\568C:3+Q%LV*L-AZ?UN*8KGTN M+>.Z$X5-\>P4T22O0$6@&S'NT.VNA!&<1\NX-T7@(%I&K.[5(;E9,>/ MN0Y_3F_@OV@C2EJ/'6$AKH8LK(:9Z(M6'(3C\?<8Q]2>7/(4C2JZA<+!9GJ: MN)7HTGX8(B][+;VYN)WM0&(X;*([Y2:JTQ.9QM$Y/9K.ZJ/IM#Z"3NIWTA'] M=CJD#Z`#^JVTFZF4:3/?K]/OH#Q]."W1H^AY?B9'CZ.Y^J.4I6]Q4(2^E8;J MI31`MU.HOI=^KE>2OWZ8_/23U$$_2T)O8&V]^"3='5`/`F\]%#KI`\%?OPN" M]$@(U>^%`?K],%1_`$8Q_5%?R?0JS-6+($??"KGZ._"2OAM6Z.]#H5X.Q?I^ M>(MI%]_OY_F/F/^9O@UJ>/T9?074L0R#ADA/D;;3;'T$-.B7XR[_QVVFO/T.WB>FT>I%8V0]^)$9OOBCO(YU1&L_?JI&>M,GTI?>EUUI MN^Q%Q;(/%IL*C\BF8+'/!*I>!3;X"LV0Q9,M2>);/T2_( M2E@I#\,Z>0(VRU-0*K^!/;(6#K(51QV6>).OZ=G4')D9S2`SF>4UOJ-=F<>- ME:P1$8$32&9$_ M,")3&9$IC,AD1F0R(S*%$4EA1*R,2#HC,I,1FFJ_OFBO? M0J@",F1("_EFIH4%YE(@O&SJEQYL=1147*ZO9+>;5`1WQ#HUJ92C^*D>'N\_ M#-Z1B?"%=#[]I9S`]\/:U44\S^,:NA.B37G?JWET"B*QN5S5+D?D]RH(&E07 MD`I`H_/4B25WIZ,42!]07WJ/PFD[1=!FBJ.UE$)Y-(=>IB6TB#;00MI%.?0A MS:>O:1[O/8^ZP7RZ&?[$FCU'OX9%E`!+:!HLISFPAG+A-?HK;*0"V$9%L)/> MAKVTFSOD`3A.5?`5'88Z.@XZ?0[><`K\P;"@@4^#GB/R=9.(-*B7Z32,0[,< MU7Z4HPUJ(%Q4(:"4/UC(FVM%`_G3.;J)OJ1?T&&ZG0[22-I#XZB$4FD39=-K MC$D!%=%*VLUGUX]H*9WA&>3([`Y+J2_\C89`'OT&"F@\K*/I4,1-8"L]#]MI M*>RB-;"/BN$#*H$CM`=.T3\9B0\9B2/@!=70!;Z`&^$TA()AP445ZS$B`53( M",>:G@L;XZ"E$[$SMF-Q-Q120!MR5,!WU(M/E:;O$6SU$'!FGR-2R=[,R=6I MB09#^2D?C_?O#[44"P&NIWM"'-_W_Z_D:#F-@Z9ZK866XWGXG=9\/W5'I(4& M"2\*%1VII^A"OJ(G2>Q-YS&4OL*!]!G>S:?@!V@?)M%.S*2M^!P5X6I:BV]3 M`1ZD/#Q!*_$[WM$/EF,0K,0!L`HC80W&P5I,@0TX"[;@;A%&!9X4;SI>ZEY'WVD242\ M^+1>#X]IGO;1*.%-@X4OOVUTI4#1BSJ+/J2),&K`E.(Q M(B'\OE(!*8A0_ MU9H^:A&)'$_.IW\E)O#]M>^CK<_EQK]TP0`!$0O@D````J``!XG.U9"U`5UQG^_[.[(`]%C1,( M1H$!M^_U`NZ%O3=T.LYXF/\^ MSMGS_]__^LXN]\SI`==^OR_^,^@RTD$"+B(@K,,<>L4<_0&8]SL70OBFQ8-Q M7PTW"??*0Y0_A<3(>3A)'Y((DDB2*))HDKXD_4AB/"4``T@&>FN`_W]=>3!" M&#.@G/ZJ(!$F0AF].V!I5RKH=CQ,%>/39?#!<.(-8S1ZEB=UNC@Q^53FB;^B M>87LXY0)9+\4*N!9F`\+@[(-9NVQ3IQC=]\2[SLCNR50`%GD>0%4PG?,/_LC M#A@:'&CX9->^X7KJHY[/Z+7_&%F=#GF4@2)83-_MCO@0_#?R5"/Y['MZ5_+B M"J;_'_3[_3^0LBA%>FJW:^_&T\NTHGQ'>65Y857BA)*BBO&.JL2,O)*2`L=2 M,$Z+:3-SO=.Y/4RWC=N_J&,-IJEKQ2_5%:*6BE%]O.*R#3,?F!=[Y?9R?' MA>YD;PTC[[[>1^_W_MXU.0-@%1WN@QXUUH@)I,A^!CNL,E<-IHABF_GM=N-3 M-/NN/+B_H6FHR0_#PV*(FPUM'AZYW;Z9]^]SGD5ZUR+--69JBO7.I9AS,AAU M-VMZ5M:@#M6755Y=X,@J+RJKBO)>'6U>XV&S+.BLUU/'?AS&E;*)`[UWL%;H MQ]&G=O(RWKRBQI":&FAL;`3AB>.EQONAQOO%N*[QTT;8_N$M$/HMV+1I MJ[G?W"6,_9X/POO%T&=$?2SSG![?LXQ;E/.PV(]JT&LK^&%QCE:LUJ:+8Z(N MP-I:\9[()_:W6E/=S7P;_T089X.+F4%@GLKY-IV!QA4:4WQ5Y9UGWODP\YT& M\\Q+IH4420&W^S-N:"[@)\0&DN&\F7?.)G;)IA]1`N:*OY&-[FW)YOJM#C8S M<)'(Q#+Q)]3$S_$_PM!C9=,NCEVNL_S7++E'GSTX9'JZ,G`,@4,NSI]Q._D[ M)./Y+7Z2Y`5QB[>(-CX,W#P'(L0Z2*!,/B'>PFTBCET2V8S!4(9D\W6QQW5( MS&.#80U[""K9'9%)ZZUTW09<)CZ%(6(UZ'P,M/`R<987\K/\D*O5,K9V_6QR M[N3GI1'@JP#1H0)\4<8>HH!WL['*C,+3I'6+\)T''ZB+Q!UU@7A-$OWT9)&N#Q8OZH/$5CU27-*9B'!I/-7U+U[HNLA7N8[R8ZX&_HC[ M+_QG[OW\(_<>GLYW\=W\;1XK=O*72!K%/AX/1_D\.,/7P35^&=IX$D:*(DRF M2D@3R.:(+%8A7F6KQ+NL7G"V0Z1*#>)EZ;PX)=T4^R2$EZ5HF"O%0;(T%/[! M$J".#8%EE(V%[*;(8!>$CKO-Z$_!&>*?E+E:X#P-ON"Z:.8K*`N?\R;^+7Z! MKW=?H6Q\P7>ZWO]&E9>HQH'4IY3Y,@(=,N*O-WO]@?!],R./P`YE#)Y07B;Y M&/7PC_'OX1I^'3Z:?1T^B5T-G\/>")O#EH<5L$M*`7M7FK57BX@YLY:M!J\@0D]_3L8:6P?)*TEA,F@V6&\2"R5.4=XT?C1^U!\Q1I'!`BFBFT-\\23?=5XT?C1^U!DT<:IX2(YE=0YE1[*5/& M_4%\'Q6*G+\AS1I\Z'R,WNUBF#GEZ+M3KJ^&TW@BW M=<1^KB?Q8542\O`+)`WXE2FOHSM\+4D2W@B/P(+P]^%T MV!J(#YL)SRLIL%GFXHYT31PA62O]6UQE43"5Q<%,\:6X[OY(U+KVB6OZ-LL[ M&JNH5_/S=.<5S>S=-R/$F7&--/=5\W;<@S+;@_UA/"KP-NAB$+2)_>(K,4.T MB#/\LFT?'J+'(?*29>8FT MOH3-[C=Q(J:@793-[B1X!@_W8,O?O7Y;2239D(K[;$>DV;V8;%T,P:_%)+O) MUND@;)V$:1B&P?MUDH3#1/PR"%MAE,WG>[!EY5%?0/O M"V-Q@^7:=@B\-H08?(?29/ELU7WG0\#.;V([E'32''ROC9%;\0_R,LL3*OC. M]_TG9(R\D,TES8M)-LGEK$BN8G81C937P59YE&5-W!L!O&MSI+P%YL@IN(CD M=_)&6$!Z[-H\+F?B;.6]'FS>Z^<$)1./RTM(ZC%#:!K(8U)R.3@>V&8G('K MY49+-+[8*#V@4;IT9B-IS,!A/:#YICPT2EAS3;::#M=U:ZX)MKN5NUQSG>X= ML]7@XUNJM6*+9LTU@;,=Z*[-UP^EVD+V!FD^0')5*V=O:?:YIE!;!Y]K/7&- M_ZSSV2S4ML!:+07?(;FL;83-FGVN`3T3Z_6>^OY>/U?0/M"7D-3C:KT!7]7M M]_U!-1,G:W;YS>_G4=KWM+:$I!Z/J`UX4+5O"KHW)I=TK4D%)HUNX3:SRVD,0G3M>"K/U_+P(N:-;L$[D5KAE;NLLM% MTIK?`YK_W=V0_Q3U7.OK^-'H._WM0?CP7@P[N_Q7\B_*)H``'(7 M(`````$`0```````A@X``#$%``!N#P``!@`@`(`I``#:-`````#U#QP````` M`0``0!)`&X`9@!O`'(`;0!A`'0`:0!O`&X````` M`````````#@``@#_______________\````````````````````````````` M```````````````````O````G`(````````Q`%0`80!B`&P`90`````````` M```````````````````````````````````````````````````````````` M#@`"``$````#````_____P`````````````````````````````````````` M`````````*8!``!O%0````````4`4P!U`&T`;0!A`'(`>0!)`&X`9@!O`'(` M;0!A`'0`:0!O`&X````````````````````````````````````H``(!`@`` M`!\```#_____```````````````````````````````````````````````` M.@```,P!````````!0!$`&\`8P!U`&T`90!N`'0`4P!U`&T`;0!A`'(`>0!) M`&X`9@!O`'(`;0!A`'0`:0!O`&X``````````````#@``@'_____________ M__\```````````````````````````````````````````````!"````T`D` M```````$`@``P`$```\````!````@`````,```"(````!````*`````&```` MJ`````<```"P````"````+@````)````P`````H```#(````%P```-`````+ M````V````!````#@````$P```.@````6````\`````T```#X````#````#H! M```"````Y`0``!X````/````3VXM$````P```!````!4 M:6UE`````0````!O=F4>````#0`` M`$YA;F-Y($-O='1E<@`H0TT>`````0````!A;F,>`````0````!A;F,>```` M"P```$YO`0``GP$``/[___^A`0``H@$``*,!``"D M`0``I0$``/[___^G`0``J`$``*D!``"J`0``JP$``*P!``"M`0``K@$``*\! M``"P`0``_O____[_____________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________^X7N/X2_QW?1PC\[UU@;L1ILO]IM;?_@IC="77_U!RKY*" MI0.(163]V_&WEBY>O*A;@S6FNY\_HU^XQW2+.4KY40TQ1S023YC#>LY4:)(I MUQ1S2+/-02TV9?*8/5IK=BK/^*SUID#IIE`)IDC+3;&B,!?3,`G/4?XGZA^D M[9UFFP::OW'_D4:9CS46$S$5X5A$^7)X:)-IUFJ=6:-PTWBT!6L0QW,4];-H-]E\J#^;:&(NU0@S3V/,?#UK MWM++YFUR7$BN"_6NB52,>8?W>$-,P9OJS_4F9YI^@MY.B"Z:$'6:Z?0)(<<059AIVFNF:H>9HLWF3:69 MU[3$O,*<3F1N7R27%\CI>3UN)I"3=)6Y6>!KVEQM9N@&,Y.],$?]S?OZF7E7?4T4,:/4J2A]BL/8283- M>D^KM%CQ6LI_EVF^EFNR/M0X2O[`/ARN%*1IM)(UEN<7Y"&[1,U"I!*T`AYD M\IS+W5[:'"?++RBYVJPB=I:N-_FZ2,:=1&OE#>NU@?B?:+?6*Q]K$,?S(LK# MJ']5F_0L[1]CQ(=H<8>VZT;>MC<9BU[2'O55"66[=`ME=ZE8@U6DD7B2=L]S M?0.S*8^DWD.?CSW+^E^JU>3)WSK+WSVYI^4_N6$:Y'R" M=*1HH),,#[O2HU\[B1J`_DZ"=;L5CUB>`P9@",9@`E[$2U:<7G&\>M59A=76 MI*"7*7O)R=3SQ'S62=)X8HTESM-XDA@/<_TM'K(\&DZ;X>0VG/&&.]OT*$9A MM+-5CSM;](233[\\Y.HI)P<;&&L]UND9C,4X:SU\V$W,,JX!8YW]M"O[EE+Z M[F:LQK0 M&-1DC<+O,!AWHC]N[]:(!M137J]?XBX,P-W$N`<#B3F0V(/(89!3CGUV+2_M MD?]O5VSG.J27HP?8W?.<*D40(8)($42<3_2W\#86(!+OD&5`(YJL2"Q`.%Z_ M3",:K#?H.Q73,!VAC!]*G%#GA&8XQW``/FRG;!NVTFZ+0C"5%7_S,GG(10[U MV9KI;-8<9Y/FLA/F(:+;1F0CG_(B^W[3V5VA[+)0=ELHNV\&.WPFPMC!LS"; MW3R':SCF4CX/$;2+H/U\^LVG_WQ.300[-,))I3Z-=NFT]]+/2W\OXW@9S\NX MZ8R?1IQ4I"#9QN_9BLVPYWBPO+R-E]7R,HL9S&8&LYJ)E5B-+*QEY@,:T61E M8352$8T5W1K18$73-P:QB$,\XR<0)X&]E^`^7F;-_UX]FZ&FX)X>SU=[AU."O2C# M0?DX.06\01%[KIA(NYSC*N&M]K`/]S&;I=C/F_X=%=P?P5'JCJ&*MM7T.>%4 MJL8Y:M4&U5F5J**\FC:UM*^G7P/]&W68&2YWFAFWF?&;B=5,S&;B-Y%'DPII MXZ/M=F9Z*WVW$"^?>'GDF3EGJ@*'B1_@PS9LH2Z/-KF\;PZQLE6&4NQ! M"64[J2LB5B'Y%A#+1RP?8_K'[=GJ?VK/1XA:V9,!B6IA+_JULA_]3J$37P5] MC>O#7(3=5`-T7WN,G6W6Z2?N5Z="=N#[K-2D0" M^',SZ#<8B4>[)2`1'FLD'L9#>)!QAV$HL1X@YA`W'9D:[*[3_>1VOWL438S9 MW.T^]U-R;":_1MW!+_,;W5WZPEF)32A`!;\JJG$"-?J2W?4EN^PK?,T.E5LO M![UPA=N@*ZU&-%E7P,7G[-(VG$)KMX9NGS%6.\ZB@['/HY-8G<3L(GX7N_8" MN^,"OPDN\.VXP%GOXNO8P9?Q#%_%=M:J+;AF/=L!%^P.F*L)9/T$QF!TMT8T M6&-XX\?Q))[&6+=.XZQ:C7=K4(T*E&(#O$A#"FWXC=;9E,WFS:SV&EA;A'C%A*C@%@^8OKT.B9:QUG*L(]K)`9*&0FBIBE8NQD M9DJP%Z4HX\T#&M%DE6(OMN)CK$56MT8T6&OI_Q'68P,V,?YFJU;9Q,TF?C8S MG$,N.>243?[9Y+B97/TVD?L&K(27YS2DT,;#.R0P)W'LX@^9@P^8BVBLX-XO MFAT=63Z#<^S`#ISG&]#)BG2QDEWLQBY6J8O5 MZF+5.EG!\ZQ(!]^>C#9_Q?`JMU+?2KH7V)^EWDOXG&:>%\5H8MY7Q M3Q'G--J(ZX_?0IL6VK:R:UKI=XK^GS'.:;0Q9KN-E:"S/)^S\?UY^/-)1@I2 MD89TRKW49R"3]IGT6TE_?RQ_S$S&]S>BHX(Q>KSY$\1#1 M0V0/&219Y\CT+)D&I%(7<);HY\CF+,YPWVZEDJU?!F-EV/':Z->.,Y=)#DJR MVM%FI?S/MW&#?SOP7QQ@1E;3````1``````````````````````````````` M``````````````````````````````````````````````````````#0R>IY M^;K.$8R"`*H`2ZD+`@```!<````7````:`!T`'0`<``Z`"\`+P!W`'<`=P`N M`'<`>0!N`&0`:`!A`&T`+@!C`&\`;0```.#)ZGGYNLX1C((`J@!+J0LP```` M:`!T`'0`<``Z`"\`+P!W`'<`=P`N`'<`>0!N`&0`:`!A`&T`+@!C`&\`;0`O M````80$``$0````````````````````````````````````````````````` M````````````````````````````````````T,GJ>?FZSA&,@@"J`$NI"P(` M```7````.P```&@`=`!T`'``.@`O`"\`=P!W`'<`+@!D`&\`=0!B`&P`90!T M`'(`90!E`"X`8P!O`&T`+P!$`&\`=0!B`&P`90!4`"\`2`!O`'0`90!L`#$` M-@`Q`"\`,0`W`#D`+P`Q`#<`.0!-`&$`:0!N`"X`:`!T`&T```#@R>IY^;K. M$8R"`*H`2ZD+=@```&@`=`!T`'``.@`O`"\`=P!W`'<`+@!D`&\`=0!B`&P` M90!T`'(`90!E`"X`8P!O`&T`+P!$`&\`=0!B`&P`90!4`"\`2`!O`'0`90!L M`#$`-@`Q`"\`,0`W`#D`+P`Q`#<`.0!-`&$`:0!N`"X`:`!T`&T```#M```` M1``````````````````````````````````````````````````````````` M``````````````````````````#0R>IY^;K.$8R"`*H`2ZD+`@```!<````> M````:`!T`'0`<``Z`"\`+P!W`'<`=P`N`'$`=0!A`&P`:0!T`'D`?FZSA&,@@"J`$NI"SP```!H`'0`=`!P M`#H`+P`O`'<`=P!W`"X`<0!U`&$`;`!I`'0`>0!S`'4`:0!T`&4`.(1[?\`.0H```@```#I,`````!X`&`A&_`Q"@``1W`C M8L-DCB&*PWN`>.(1[2@4``````````````$````!````R!U]"-M,)+_2H&Y2KVX7N/X2_QW?1PC M\[UU@;L1ILO]IM;?_@IC="77_U!RKY*"I0.(163]V_&WEBY>O*A;@S6FNY\_ MHU^XQW2+.4KY40TQ1S023YC#>LY4:)(IUQ1S2+/-02TV9?*8/5IK=BK/^*SU MID#IIE`)IDC+3;&B,!?3,`G/4?XGZA^D[9UFFP::OW'_D4:9CS46$S$5X5A$ M^7)X:)-IUFJ=6:-PTWBT!6L0 MQW,4];-H-]E\J#^;:&(NU0@S3V/,?#UKWM++YFUR7$BN"_6NB52,>8?W>$-,P9OJS_4F9YI^@MY.B"Z: M$'6:Z?0)(<<059AIVFNF:H>9HLWF3:69U[3$O,*<3F1N7R27%\CI>3UN)I"3 M=)6Y6>!KVEQM9N@&,Y.] M,$?]S?OZF7E7?4T4,:/4J2A]BL/8283->D^KM%CQ6LI_EVF^EFNR/M0X2O[` M/ARN%*1IM)(UEN<7Y"&[1,U"I!*T`AYD\IS+W5[:'"?++RBYVJPB=I:N-_FZ M2,:=1&OE#>NU@?B?:+?6*Q]K$,?S(LK#J']5F_0L[1]CQ(=H<8>VZT;>MC<9 MBU[2'O55"66[=`ME=ZE8@U6DD7B2=L]S?0.S*8^DWD.?CSW+^E^JU>3)WSK+WSVYI^4_N6$:Y'R"=*1HH),,#[O2HU\[B1J`_DZ"=;L5 MCUB>`P9@",9@`E[$2U:<7G&\>M59A=76I*"7*7O)R=3SQ'S62=)X8HTESM-X MDA@/<_TM'K(\&DZ;X>0VG/&&.]OT*$9AM+-5CSM;](233[\\Y.HI)P<;&&L] MUND9C,4X:SU\V$W,,JX!8YW]M"O[EE+Z[F:LQK0&-1DC<+O,!AWHC]N[]:(!M137J]? MXBX,P-W$N`<#B3F0V(/(89!3CGUV+2_MD?]O5VSG.J27HP?8W?.<*D40(8)( M$42<3_2W\#86(!+OD&5`(YJL2"Q`.%Z_3",:K#?H.Q73,!VAC!]*G%#GA&8X MQW``/FRG;!NVTFZ+0C"5%7_S,GG(10[UV9KI;-8<9Y/FLA/F(:+;1F0CG_(B M^W[3V5VA[+)0=ELHNV\&.WPFPMC!LS";W3R':SCF4CX/$;2+H/U\^LVG_WQ. M300[-,))I3Z-=NFT]]+/2W\OXW@9S\NXZ8R?1IQ4I"#9QN_9BLVPYWBPO+R- ME]7R,HL9S&8&LYJ)E5B-+*QEY@,:T61E8352$8T5W1K18$73-P:QB$,\XR<0 M)X&]E^`^7F;-_UX]FZ&FX)X>SU=[AU."O2C#0?DX.06\01%[KIA(NYSC*N&M]K`/ M]S&;I=C/F_X=%=P?P5'JCJ&*MM7T.>%4JL8Y:M4&U5F5J**\FC:UM*^G7P/] M&W68&2YWFAFWF?&;B=5,S&;B-Y%'DPIIXZ/M=F9Z*WVW$"^?>'GDF3EG MJ@*'B1_@PS9LH2Z/-KF\;PZQLE6&4NQ!"64[J2LB5B'Y%A#+1RP?8_K'[=GJ M?VK/1XA:V9,!B6IA+_JULA_]3J$37P5]C>O#7( M3=5`-T7WN,G6W6Z2?N5Z="=N#[K-2D0"^',SZ#<8B4>[)2`1'FLD'L9#>)!Q MAV$HL1X@YA`W'9D:[*[3_>1VOWL438S9W.T^]U-R;":_1MW!+_,;W5WZPEF) M32A`!;\JJG$"-?J2W?4EN^PK?,T.E5LO![UPA=N@*ZU&-%E7P,7G[-(VG$)K MMX9NGS%6.\ZB@['/HY-8G<3L(GX7N_8"N^,"OPDN\.VXP%GOXNO8P9?Q#%_% M=M:J+;AF/=L!%^P.F*L)9/T$QF!TMT8T6&-XX\?Q))[&6+=.XZQ:C7=K4(T* ME&(#O$A#"FWXC=;9E,WFS:SV&EA;A'C%A*C M@%@^8OKT.B9:QUG*L(]K)`9*&0FBIBE8NQD9DJP%Z4HX\T#&M%DE6(OMN)CK$56 MMT8T6&OI_Q'68P,V,?YFJU;9Q,TF?C8SG$,N.>243?[9Y+B97/TVD?L&K(27 MYS2DT,;#.R0P)W'LX@^9@P^8BVBLX-XOFAT= M63Z#<^S`#ISG&]#)BG2QDEWLQBY6J8O5ZF+5.EG!\ZQ(!]^>C#9_Q M?`JMU+?2KH7V)^EWDOXG&:>%\5H8MY7Q3Q'G--J(ZX_?0IL6VK:R:UKI=XK^ MGS'.:;0Q9KN-E:"S/)^S\?UY^/-)1@I2D89TRKW49R"3]IGT6TE_?RQ_S$S& M]S>BHX(Q>KSY$\1#10V0/&219Y\CT+)D&I%(7<);HY\CF M+,YPWVZEDJU?!F-EV/':Z->.,Y=)#DJRVM%FI?S/MW&#?SOP7QQ@1E;G```` M1``````````````````````````````````````````````````````````` M``````````````````````````#0R>IY^;K.$8R"`*H`2ZD+`@```!<````< M````:`!T`'0`<``Z`"\`+P!W`'<`=P`N`'(`90!S`&D`9`!E`&X`8P!E`&D` M;@!N`"X`8P!O`&T```#@R>IY^;K.$8R"`*H`2ZD+.@```&@`=`!T`'``.@`O M`"\`=P!W`'<`+@!R`&4`IY^;K.$8R"`*H`2ZD+`@`` M`!<````<````:`!T`'0`<``Z`"\`+P!W`'<`=P`N`'(`90!S`&D`9`!E`&X` M8P!E`&D`;@!N`"X`8P!O`&T```#@R>IY^;K.$8R"`*H`2ZD+.@```&@`=`!T M`'``.@`O`"\`=P!W`'<`+@!R`&4`.(1[?\`.0H```@````8/@````!X`&`A&_`Q"@``1W`C M8L-DCB&*PWN`>.(1[2@4``````````````$````!````R!U]"-M,)+_2H&Y2KVX7N/X2_QW?1PC M\[UU@;L1ILO]IM;?_@IC="77_U!RKY*"I0.(163]V_&WEBY>O*A;@S6FNY\_ MHU^XQW2+.4KY40TQ1S023YC#>LY4:)(IUQ1S2+/-02TV9?*8/5IK=BK/^*SU MID#IIE`)IDC+3;&B,!?3,`G/4?XGZA^D[9UFFP::OW'_D4:9CS46$S$5X5A$ M^7)X:)-IUFJ=6:-PTWBT!6L0 MQW,4];-H-]E\J#^;:&(NU0@S3V/,?#UKWM++YFUR7$BN"_6NB52,>8?W>$-,P9OJS_4F9YI^@MY.B"Z: M$'6:Z?0)(<<059AIVFNF:H>9HLWF3:69U[3$O,*<3F1N7R27%\CI>3UN)I"3 M=)6Y6>!KVEQM9N@&,Y.] M,$?]S?OZF7E7?4T4,:/4J2A]BL/8283->D^KM%CQ6LI_EVF^EFNR/M0X2O[` M/ARN%*1IM)(UEN<7Y"&[1,U"I!*T`AYD\IS+W5[:'"?++RBYVJPB=I:N-_FZ M2,:=1&OE#>NU@?B?:+?6*Q]K$,?S(LK#J']5F_0L[1]CQ(=H<8>VZT;>MC<9 MBU[2'O55"66[=`ME=ZE8@U6DD7B2=L]S?0.S*8^DWD.?CSW+^E^JU>3)WSK+WSVYI^4_N6$:Y'R"=*1HH),,#[O2HU\[B1J`_DZ"=;L5 MCUB>`P9@",9@`E[$2U:<7G&\>M59A=76I*"7*7O)R=3SQ'S62=)X8HTESM-X MDA@/<_TM'K(\&DZ;X>0VG/&&.]OT*$9AM+-5CSM;](233[\\Y.HI)P<;&&L] MUND9C,4X:SU\V$W,,JX!8YW]M"O[EE+Z[F:LQK0&-1DC<+O,!AWHC]N[]:(!M137J]? MXBX,P-W$N`<#B3F0V(/(89!3CGUV+2_MD?]O5VSG.J27HP?8W?.<*D40(8)( M$42<3_2W\#86(!+OD&5`(YJL2"Q`.%Z_3",:K#?H.Q73,!VAC!]*G%#GA&8X MQW``/FRG;!NVTFZ+0C"5%7_S,GG(10[UV9KI;-8<9Y/FLA/F(:+;1F0CG_(B M^W[3V5VA[+)0=ELHNV\&.WPFPMC!LS";W3R':SCF4CX/$;2+H/U\^LVG_WQ. M300[-,))I3Z-=NFT]]+/2W\OXW@9S\NXZ8R?1IQ4I"#9QN_9BLVPYWBPO+R- ME]7R,HL9S&8&LYJ)E5B-+*QEY@,:T61E8352$8T5W1K18$73-P:QB$,\XR<0 M)X&]E^`^7F;-_UX]FZ&FX)X>SU=[AU."O2C#0?DX.06\01%[KIA(NYSC*N&M]K`/ M]S&;I=C/F_X=%=P?P5'JCJ&*MM7T.>%4JL8Y:M4&U5F5J**\FC:UM*^G7P/] M&W68&2YWFAFWF?&;B=5,S&;B-Y%'DPIIXZ/M=F9Z*WVW$"^?>'GDF3EG MJ@*'B1_@PS9LH2Z/-KF\;PZQLE6&4NQ!"64[J2LB5B'Y%A#+1RP?8_K'[=GJ M?VK/1XA:V9,!B6IA+_JULA_]3J$37P5]C>O#7( M3=5`-T7WN,G6W6Z2?N5Z="=N#[K-2D0"^',SZ#<8B4>[)2`1'FLD'L9#>)!Q MAV$HL1X@YA`W'9D:[*[3_>1VOWL438S9W.T^]U-R;":_1MW!+_,;W5WZPEF) M32A`!;\JJG$"-?J2W?4EN^PK?,T.E5LO![UPA=N@*ZU&-%E7P,7G[-(VG$)K MMX9NGS%6.\ZB@['/HY-8G<3L(GX7N_8"N^,"OPDN\.VXP%GOXNO8P9?Q#%_% M=M:J+;AF/=L!%^P.F*L)9/T$QF!TMT8T6&-XX\?Q))[&6+=.XZQ:C7=K4(T* ME&(#O$A#"FWXC=;9E,WFS:SV&EA;A'C%A*C M@%@^8OKT.B9:QUG*L(]K)`9*&0FBIBE8NQD9DJP%Z4HX\T#&M%DE6(OMN)CK$56 MMT8T6&OI_Q'68P,V,?YFJU;9Q,TF?C8SG$,N.>243?[9Y+B97/TVD?L&K(27 MYS2DT,;#.R0P)W'LX@^9@P^8BVBLX-XOFAT= M63Z#<^S`#ISG&]#)BG2QDEWLQBY6J8O5ZF+5.EG!\ZQ(!]^>C#9_Q M?`JMU+?2KH7V)^EWDOXG&:>%\5H8MY7Q3Q'G--J(ZX_?0IL6VK:R:UKI=XK^ MGS'.:;0Q9KN-E:"S/)^S\?UY^/-)1@I2D89TRKW49R"3]IGT6TE_?RQ_S$S& M]S>BHX(Q>KSY$\1#10V0/&219Y\CT+)D&I%(7<);HY\CF M+,YPWVZEDJU?!F-EV/':Z->.,Y=)#DJRVM%FI?S/MW&#?SOP7QQ@1E;O```` M1``````````````````````````````````````````````````````````` M``````````````````````````#0R>IY^;K.$8R"`*H`2ZD+`@```!<````> M````:`!T`'0`<``Z`"\`+P!W`'<`=P`N`&,`;P!U`&X`=`!R`'D`?FZSA&,@@"J`$NI"SX```!H`'0`=`!P M`#H`+P`O`'<`=P!W`"X`8P!O`'4`;@!T`'(`>0!S`&D`9`!E`&D`;@!N`"X` M8P!O`&T`+P```&$+``!$`&0````````````````````!``````#\$@D&[@+N M`@``````````````````````````````````````````#P`$\+````"R!`KP M"`````@$````"@``8P`+\(P````$00$````%P6@````&`0(```"!`1$``!"_ M`0``$`#_`0``"`!)`#H`7`!4`$4`30!0`$P`00!4`$4`7`!'`%(`00!0`$@` M20!#`%,`7`!&`&D`;`!E`$X`10!4`"``3`!O`&<`;P!<`$8`:0!L`&4`3@!% M`%0`7P!C`&\`;`!O`'(`+@!W`&T`9@``````$/`$````!P``@#(`!_!="@`` M`P1'<"-BPV2.(8K#>X!XXA'M_P`Y"@``"````&A*`````'@`8"$;\#$*``!' M<"-BPV2.(8K#>X!XXA'M*!0``````````````0````$```#(%R\`"/@.`/\) M````_GBL"6*>X M((I5@1`($`@*D:C``-&L+^M+6$(59,G&]K)`6!*@)$`((7OLM"1(`H2$T5JE MWW?>(XHSU9E&Y^.]]VS__SW+Y8E1;\GM=[7T(VTPDO]*@;E*O;A>X_A+_'=] M'"/SO76!NQ&FR_VFUM_^"F-T)=?_4'*ODH*E`XA%9/W;\;>6+EZ\J%N#-::[ MGS^C7[C'=(LY2OE1#3%'-!)/F,-ZSE1HDBG7%'-(L\U!+39E\I@]6FMV*L_X MK/6F0.FF4`FF2,M-L:(P%],P"<]1_B?J'Z3MG6:;!IJ_Q"%6K29>=29!E291![#3>+0% M:Q#'TLOF;7)<2*X+]:Z)5(QYA_=X M1Q\CC^=B'*#NF%F@1MJVT*?#1,AUPM7/"=.MSG3=XTS!F^K/]29GFGZ"WDZ( M+IH0=9KI]`DAQQ!5F&G::Z9JAYFBS>9-I9G7M,2\PIQ.9&Y?))<7R.EY/6XF MD)-TE;E9YS5>QHS3M>8NUN+G&FS^HMO0CS8.;3OT@OZA%W5,$[5/D[1#KVJC M7M,:O:X83=6[FJX(S428EF@&9:%*I2Q+(5=]310QH]2I*'V*P]A)A,UZ3ZNT6/%:RG^7:;Z6:[(^U#A* M_L`^'*X4I&FTDC66YQ?D(;M$S4*D$K0"'F3RG,O=7MH<)\LO*+G:K")VEJXW M^;I(QIU$:^4-Z[6!^)]HM]8K'VL0Q_,BRL.H?U6;]"SM'V/$AVAQA[;K1MZV M-QF+7M(>]54)9;MT"V5WJ5B#5:21>))VSW-]`[,ICZ3>0Y^-S/`>[5>M#NFD MREF;"G(ZK&LX)^=T$Z?BM(ZHDOR/$*U#G[/3_.<;QZU5F%U=:DH)\G)U//$?-9)TGABC27. MTWB2&`]S_2T>LCP:3IOAY#:<\88[V_0H1F&TLU6/.UOTA)-/OSSDZBDG!QL8 M:SW6Z1F,Q3AK/7S83B/V[OUH@&U%-> MKU_B+@S`W<2X!P.).9#8@\AAD%..?78M+^V1_V]7;.C!]C=\YPJ11`A M@D@11)Q/]+?P-A8@$N^094`CFJQ(+$`X7K],(QJL-^@[%=,P':&,'TJ<4.>$ M9CC'<``^;*=L&[;2;HM",)45?_,R>!G/R[CIC)]&G%2D(-G&[]F*S;#G>+"\ MO(V7U?(RBQG,9@:SFHF56(TLK&7F`QK19&5A-5(1C17=&M%@1=,W!K&(0SSC M)Q`G@;V7X!S!/F0B%9LW_7CV;H:;@GA[/5WN'4X*]*,-!^3@Y!;Q!$7NNF$B[G.,JX:WV ML`_W,9NEV,^;_AT5W!_!4>J.H8JVU?0YX52JQCEJU0;5696HHKR:-K6TKZ=? M`_T;=9@9+G>:&;>9\9N)U4S,9N(WD4>3"FGCH^UV9GHK?;<0+Y]X>>29R]@Y MSF$9R>?L[.5<[.-_;Z#,^+C?!2R_XLY'[LX M'[NQES-1B@,XQ',%=4=I4TG;*L[4J`H>)'^##-FRA+H\VN;QO#K&R5892[$$)93NI*R)6(?D6$,M'+!]C^L?M MV>I_:L]'B%K9DP&):F$O^K6R'_U.H1-?!7V-Z]R-NM4MU+UN!7RZS_V(ZRIX M-XR=;=;I)^Y7IT)VX/NLU*1`+X:R0>QD-X MD'&'82BQ'B#F$#<=F1KLKM/]Y':_>Q1-C-G<[3[W4W)L)K]&W<$O\QO=7?K" M68E-*$`%ORJJ<0(U^I+=]26[["M\S0Z56R\'O7"%VZ`KK48T65?`Q>?LTC:< M0FNWAFZ?,58[SJ*#L<^CDUB=Q.PB?A>[]@*[XP*_"2[P[;C`6>_BZ]C!E_$, M7\5VUJHMN&8]VP$7[`Z8JPED_03&8'2W1C188WCCQ_$DGL98MT[CK%J-=VM0 MC0J48@.\2$,*;?B-RDH]@Z=8N3$8;24B`?'6&#R-"9B.A5@4%$6[]]T,+7%7 M:[&[QGH?[P5%L?LBB1E!K'G$"<=L8H3A%>XG!;U,_40K#9G8IK]B"D+;-K/8:6%N$>,6 M$J.`6#YB^O0Z)EK'48-:X_V2]CARYCS96ZY MEF.%5:%H6U:MI:S;$M9P,6OI7]^>[93]=J=,4B6K487CJ';C5./&6K5N#&)5 MAWI6MI'SV.2N5#.KT^QF<9]%698:>*ZCO(;5JF85JM@AE:S($5:G'`=9L2(4 MSB#YF##YB+:*S@WB^:'1S+O,4RIW',84",XKDF()'R M).8\&2GPK\,/K>CE?V/QW16]P:YH;_4RPXQK#36]K6'F2FN$Z64-,SV+=+.- MU)?_JQMJ^N#'YA'S4Z[762-,/VN8N99K7_3AO@_7:ZRA/QC]^W?NTN!OG%OX MMYU9/H-S[,`.G.<;T,F*=+&27>S&+E:IB]7J8M4Z6<'SK$@'WYYS.,.,MZ,- MG_%\"JW4M]*NA?8GZ7>2_B<9IX7Q6ABWE?%/$>6]F9]Z2$)*0#VDV2R(AHB`@\4,M90-! MA)!`$O`+9@V3L&'9ACI_AK>Y#6#Z5^.!0.56K%OYX6CU2J4`$5 M/Z@5/")%H(+4F":][\WN)ME=-C-+J)OS]NW,WGWW_WGW33#2$"+5N0C9T!V( MOX;`*%8&HQS4#2^$TE#X-=&.4).*^"\$A"H@)+C*#MTI$GSVT/KL!`T$U`(2>@DZ;LF@:O!H3N9`HJB00C#'1Q:0X9AE\*? M!DE-ZD0[A4\4IP`G"'7"=X)\Q.^.Q@;5'9(L?LV_*0Q]@_M`Y"O#T7&T5)UL M1[U^VW>-B$`B:T@AG&'JC+LD@H%_FT>_Q>.TM3A-ZKNJ=`;HR62(6B"-)>:@ M[R?[M;%D$38'/9/>IGY)7,@<=*O\%/V6+H^!3H'YNU[2Z'D9$%3H1N,00NZ9 M4O@["7Z=%M)O5LC.AL'U#@X%YK$+]'^8_VJQ@;L++T&*\R98LYFNH$0'J8-YK"?/U M-`7=0'AX"J!KY/5#VIXH5S(6L"65J'REF,<>/6F^B M?*D-+8B)B/%B$J?].VDW3Q?P>C$M=@>"BE@`J`=J&01Y/!RH=$%DS+-*Y':6J/G21;:#H-*2X"578 MN!2O=@=\>F`,4)@!M%F7X@SI8J43?RR;RWNETCSV,1ZF#10O68*7'TB7:#S^ ME98ZIP5TOUDN.,,,P-8"%LDC5>Y[,H"GN:@WROLR+!X!U0+9GFZ!U3]+F`Y M!/-/+?.TFJV.X2DY#TX1/'TM;1!>5Z:[`T5"0V>VNFA.]L#B\V'M<<#)D]^C M=C($)S^3CLJ<@FEN3Z#5H[2JJ2.C"6D2/D649\E&\3*MR+=><4W0>I=PJN',)2S-I) M,VAH%V!800P_-F\GK:2-M)*WI63M9!Y@R891##\X(/6/&84DOTO*IB.E!M-X MX^OO7FD"O5S28_9YR>:-`J&/5NE6B?,YS>/5*_6@LS;@]O@\OD:NDU21LWF< M#><1/O/A,*TM7I\"&/HSS'72]Q=UC2SIP&UBEU`6\/L70V'2'.2YQ"&R/N>* M1ZTTBWYU'9U)*"TQI9=SX5=&S>6BY1*WQYH67X/7WP8QPRGX,G17+&H;:WS] MDVS0?D$:U(&R-R.Z[2"WJ3RZN5IUI[_!"?5A,S+R7PK0FP;O1I5H/AX\!B;U M"8\#P/Y=-,HK$4H0#S:HGY%OU"8:YCLL]7"GQWB%?\WMYCQ"T.?J,BIKJZBD MU?79)YN)(`T`4`0BXJJZ0#YS!%%B:/6HQ7*7.E+N&T,4TY@S`-55`)P'7*V5D'-8HYO31]016NE3\184WSH3OJVMH7>&E,C1W/5`:DD0(TZM33! M;K"'6F/]8J5!O8TRV]GQ=$)>K$Z57S&U*S$\_[U^]H**I9@V6'C4I M\;<$%X'?Y*!<\*+<&/\QO^+&T(I3_.[F($2/7)!W5IQ*V_R*^T,KSO:Z5[B! M1CNLEPG#6D3R*#]D>!-8R%0#-+07U6$7X-EM'33>2S`JL,$O[- MK\N@,I^AC++/A#%%,;['J+>MA+%S3?7G>?,!\%?`_*]7/DKO5391B]6-M/1RGJPW0>H0[F;9BJK*%-6TBZY!2S13P_*3?0= MN8&^+M?3;;*;;I#KZ)JH>$'/:.'15/^7:Q0$5@IA+R]!AZ>'ZG"\0#C;-HYE MV\QBCJ_KX;:'Y)W*1W3@LZIBP6Y56P?E,&50BP=">2I1)HV6XGT@MC+0^15@ MB<,22#$Z/MEMH^W5RN^TLXM/=3:WDFY+B^GNQ(<^IA39;U3>&N"^Q$/@KSQS MSO`O\CFO=B_WZ4:EQ>O(T:'J/[8O8;XWL`_6Y_2[/(&E_D`0=)0BNC@.4458 MBR]/J!DT2UUOJK=GAD*'H+!&?1ES:QKEG.6:[;RJQEE95>NLK0(J4U`)T.L4 ME;935#XCQ%[($6?7;-YF[P9\(A],<564P[I%8&4.F,W:+#\Q>!CJJ>TP/R]; MJ=A?[:=BMY;=C/WB\Z2-\OWB=%=U657U&&3\C8=A3;>%9(RR5_K(9(]NCOJ: M1M0U,9D]6E8OP/7O8?P%QD%+4?)E]#B,3TQ'R6C,QP`F%<:#H*DC"4Z7>E8T M./L0KR8.W(W-XHTOGW?P)C(-=YZ#/8^5Z'P[SB&BJ@AXZG6P\`S11T@NFAA= MN1=A17YGBK?EIB+AB?FF_:8"WHMA/`BC&8:Y6)]#_=T/=)_?7=5M-M9'XYT) MRXPB1@U<2,WGF`S:H$XDUY]E#7R$W*).(IN^YQJXF;P^P#7PHZ$5!Z(&-C+5 M'EB1RVR>Q^MU-^JB"K:+2C@G024U'NKJ[_P2J.0HS5[4YO\^AG>KAKF?4 M]5W)QAM>#SX=J@=?M%@/;H-Z\-FSK`=3U1;E6=MO8N+W_S?BG+(](W,8UT+W M$MZWX'VC40EZ%?%Y.4E':EOI2S%[X6B93X3KKR#Y;06*OC&QN^V1^8_0"66+ M].^HLTZKOGU062<]H+QEX:QS8'W;.%_XNW($)N.?8 MX_CXF3Q'Z>CNW@1?;H3YP@0=D&C/*9$?[]A"M8YD/8?7P5F`[P#,^2;P]F@Q M%^7*[\,X.\]ID-?#&D.1&2V:]X1*>;R`+O=Z/?" MJXW(_#G>(>BI=7MOTF$/X0AUNO,2[B&B]?PT7!\2L`AM3E"11>?AAW$!/H6V MH[Y:-I__WX#K#,C_LP"V,\%Y2#3>HV02+B+O)XWW$KA>`GB>0U;Q_@&ME*8E MC7E`_@E:3]^1-J'5TIOX^NEW?A2:1<>(KV%C^!DJ7X.8`J!RDDP3E@Z M!^$Q=;)]LGT@=U65TKOB^9'IR[UNW\)\$4FS(-[D6/3?('Y8RL=7FGSV<*YR M0GE/WF:AI_/D@'J[<0(Q0=DCSES7I^$&JB M$KX7@UDW99'A"-_.9N`[6?CD&D>XB=>I5"(G$&M9!6YG%^`VF/M*'$56Z,\> M/0#K!>`W8+[&TBY_QSG8Y=]%5PE[+&^I]WH6%H/$"B#/I(4D9T8'QT#H/I#] M8%!MJZGL?H>0I@M]K?GIU]I=])3V*/V/]@+MU/90B1VF*NNB:2Q=SF4CY$)6 M*H]F4^7+V!QY*KM!GL-T>0%;+'O94GD%6R;?"?,:MD1^C#7*3[$%\DNL5OX; MNU+>RRZ3#[`2^0N6)1]G1#[-OJ)=[%U*[*]2Q;Z!:O9[*+,'85Q'5;N+RO82 MBNUI]#O604ZR0^0H^PFUGB5ZL[-2;W-6^Y>X?6@X M2L9GC6ICOKR1<9C*JNK:Z6@^JH+/676T MZ%)5/'567E-[5>48Y(2_?/%D1S0WYN5S$M;D,-.K:LLK0GU$9X+>17SY;+7M M92U*TX"=^`X2M&U5VE7^Y'VUOE!TT&.?'3#?3?X7K,6C8(7'[W-.]P=UKR/4 MI4D57G?Y6/5`?\#_9OQB^ER:L M,IS[L205UBQO#NI+D"\ZCL3^3T?O5]__`>%^3,3]_P%`SW."80L``$0`9``` M``````````````````$``````/P2"0;N`NX"```````````````````````` M```````````````````/``3PL````+($"O`(````"@0````*``!C``OPC``` M``1!`0````7!:`````8!`@```($!$0``$+\!```0`/\!```(`$D`.@!<`%0` M10!-`%``3`!!`%0`10!<`$<`4@!!`%``2`!)`$,`4P!<`$8`:0!L`&4`3@!% M`%0`(`!,`&\`9P!O`%P`1@!I`&P`90!.`$4`5`!?`&,`;P!L`&\`<@`N`'<` M;0!F```````0\`0````)``"`,@`'\%T*```#!$=P(V+#9(XABL-[@'CB$>W_ M`#D*```(````I6,`````>`!@(1OP,0H``$=P(V+#9(XABL-[@'CB$>TH%``` M```````````!`````0```,@7+P`(^`X`_PD```#^>)REV`EP5=4=Q_'?N;>H M*$-M<1FGTQEUJE0M5=`*@E@%VU)!ZP)8I[@@BE6!$`@0"`J1J,``T:POZTM8 M0A5DR<;VLD!8$J`D0`@A>^RT)$@"A(316J7?=]XCBC/5F4;GX[WW;/__/UWM?0C;3"2_TJ!N4J]N%[C^$O\=WT<(_.]=8&[$:;+_:;6W_X*8W0E MU_]0%81/ER>&B3:=9JG5FC7+-:>TRF MJDR:_FF2=-[$(5:M)EYU)D&5)E$'L--XM`5K$,=S%/6S:#?9?*@_FVAB+M4( M,T]CS'P]:][2R^9M:?H+>3H@NFA!UFNGT"2''$%68:=IKIFJ' MF:+-YDVEF=>TQ+S"G$YD;E\DEQ?(Z7D];B:0DW25N5GG-5[&C-.UYB[6XN<: M;/ZBV]"/-@YM._2"_J$7=4P3M4^3M$.O:J->TQJ]KAA-U;N:K@C-1)B6:`9E MH4JE+$LARM8T%>(@3N!?E'7@:]I<;6;H!C.3O3!'_9/*VAPGRR\HN=JL(G:6KC?YNDC&G41KY0WKM8'XGVBWUBL? M:Q#'\R+*PZA_59OT+.T?8\2':'&'MNM&WK8W&8M>TA[U50EENW0+97>I6(-5 MI)%XDG;/Q$M6G%YQ MO'K56875UJ2@ERE[R&*-)<[3>)(8#W/]+1ZR/!I.F^'D-ISQ MACO;]"A&8;2S58\[6_2$DT^_/.3J*2<'&QAK/=;I&8S%.&L]?-A-S#*N`6.= M_;0K^Y92^NYFG)V,R=?'*21.`?%\Q/41WT<>?OM0C1KRK"7G.G*OTR-.O4;B M]_@C'K,:T!C49(W"[S`8=Z(_;N_6B`;44UZO7^(N#,#=Q+@'`XDYD-B#R&&0 M4XY]=BTO[9'_;U=LYSJDEZ,'V-WSG"I%$"&"2!%$G$_TM_`V%B`2[Y!E0".: MK$@L0#A>OTPC&JPWZ#L5TS`=H8P?2IQ0YX1F.,=P`#YLIVP;MM)NBT(PE15_ M\S)YR$4.]=F:Z6S6'&>3YK(3YB&BVT9D(Y_R(OM^T]E=H>RR4'9;*+MO!CM\ M)L+8P;,PF]T\AVLXYE(^#Q&TBZ#]?/K-I_]\3DT$.S3"2:4^C7;IM/?2STM_ M+^-X&<_+N.F,GT:<5*0@V<;OV8K-L.=XL+R\C9?5\C*+&8#&M%D96$U4A&-%=T:T6!%TS<&L8A#/.,G$">!O9?@',$^9"(5R=3SIR@S M%(L89NL#1%OQB.,YEG8Q2G8^4)H33<[?R*#,2YV7OEYFS?]>/9NAIN">'L]7 M>X=3@KTHPT'Y.#D%O$$1>ZZ82+N11Y,*:>.C[79F>BM]MQ`OGWAYY)G+V#G.81S"067S+CF\4P[OELM7*Y(6MF3`8EJ82_ZM;(? M_4ZA$U\%?8WKW(VZU2W4O6X%?+K/_8CK*G@UR$W50#=%][C)UMUNDG[E>G0G M;@^ZS4I$`OAS,^@W&(E'NR4@$1YK)![&0WB0<8=A*+$>(.80-QV9&NRNT_WD M=K][%$V,V=SM/O=3]<(7;H"NM1C195\#%Y^S2-IQ":[>&;I\Q5CO.HH.QSZ.36)W$ M[")^%[OV`KOC`K\)+O#MN,!9[^+KV,&7\0Q?Q7;6JBVX9CW;`1?L#IBK"63] M!,9@=+=&-%AC>./'\22>QEBW3N.L6HUW:U"-"I1B`[Q(0PIM^(W*2CV#IUBY M,1AM)2(!\=88/(T)F(Z%6!041;OWW0PM<5=KL;O&>A_O!46Q^R*)&4&L><0) MQVQBA.$5[B<%O4S]1"L-F=BFOV(*0MRM"L4,-U\SW3SZYFF6F\,XZ[%..H=N-4X\9:M6X,8E6'>E:VD?/8Y*Y4,ZO3[&9QGT59 MEAIXKJ.\AM6J9A6JV"&5K,@15J<T+F,T"WJR0&2AD M)HJ8I6+L9&9*L!>E*./-`QK19)5B+[;B8ZQ%5K=&-%AKZ?\1UF,#-C'^9JM6 MV<3-)GXV,YQ#+CGDE$W^V>2XF5S]-I'[!JR$E^+YH=',N\Q3*G<9*:X3I90TS/8MTLXW4E_^K&VKZX,?F$?-3KM=9(TP_ M:YBYEFM?].&^#]=KK*$_&/W[=^[2X&^<6_BWG5D^@W/LP`ZIBU3I9P?.L2`??GG,XPXRWHPV?\7P*K=2WTJZ%]B?I=Y+^)QFG MA?%:&+>5\4\1YS3:B.N/WT*;%MJVLFM:Z7>*_I\QSFFT,6:[C96@LSR?L_'] M>?CS248*4I&&=,J]U&<@D_:9]%M)?W\L?\Q,QO7']^?A13IQTVS\GLWHJ.", M7J\^1/$0T4-D#QDD6>?(]"R9!J12%W"6Z.?(YBS.<-]NI9*M7P9C9=CQVNC7 MCC.720Y*LMK19J7\S[=Q@W\[\%\<8$96!"L``$0`9``````````"```````` M`````````!$<"17H`^@#```````````````````````````````````````` M```/``3P/````+($"O`(````"P0````*``!#``OP&`````1!!````($!$0`` M$+\!```0`/\!```(````$/`$````"@``@#(`!_!T*@```P0*CXMG+@%I<7[] M?-/@$Q)+_P!0*@```0````9O`````'@`8"$;\$@J```*CXMG+@%I<7[]?-/@ M$Q)++(T`````````````.@L``&H(``#0GD4`^"TT`!8J````_GBHB3%IYA2Q8@M5JPD$L6$1DRH4L5* M?:FE2EOTQ8HI55)1,<%(*T9::46EBI4H*E5,:8J*-:E4J?*Q,^?]GYN/S1TS4?1=;A$A)(PCMFM12KM]PW^CX]W4/3I8C!ZQ$V'_XG&ASA\ON/ M_\&^S5\`+5=_M%F_UM4<79Z+*A&NWV_I%#51'4OJ^+G1N$9'L\X;>C13SVV\ M(O?<<\_$&KL/J*B;5]0JL(ZT%LO]OW.\ANXI*^V>J+![M!C6J`^C[S[.O<9] M@VM0^N1D\QQ]'38V[_VWOAGSZ+PZ7;\/.]]U6QB?EY['S*L1=D`UPE@U4JP4 M*]:*"-O_.ZV)D4Y5C;"):OCVJX9G;`TN<"_U1EJ#[LGF.?K:,^,Q%UB15HP[ MV?>?&/-W/4O]/G><[V!C/G`?+L#K=S#]*+#'/;U]>/0HJ\&[[W3=Z:J@W4&/ M(G/==6NN#ZQ:LSEPT8;KKEPOQH^R5RW_,>8H"QL;R^1'VZDR>F+?T#,_%ISN M_X/[`W0P(=*67W3>UR\*G)>^.O74E6*%2,'?E2`:G"VTB1Z;B]QO#S,IU#&A MV_!X%QBMJ"UE>)YLV&\O,)4,/7I3&?VG8OQ`F;0RZ#\1O/^,;[695>9U>468 MKLS%YZ]8=<'Y@=2++EB]XLRQ:@2H,KI*`;PZ^R"5.7#O.`F3GL*$-?CZ"]=, M.USH_G"EYS1_PP%[ZF3]8;2>'6/U;)[H[%/L:?,/94^+H'KN'K?#I<_B*W!NNNK)PW8;U@?/SK[S^^HT;-EQW?0!G M^X6H>33J?P3^/0[C.$$7.'UOJ/-A#66XT+?=>+%=?#BP-%.9MW'##U7F!I`W1F',D MUO486N-H5"#B$"M]/"TKPK/"IZ_`EIYQ1D+@XJO6K%]W52!UX[I-:VB-]-\( M6NI\+/'(L;4^AJI]S`R/CC/]H[WS:UBU[+"9]LX?^'_@/WCO1(GWX-TZ;KU:S9^[YN8 MJYY[`/_.K*:/H::G8D91J.F7O#.I:=M834>[Q$'.1PL.I4O,HS6^T/.R7R\E MX\J-UZY;?S6.V!CTXR58HR5(,UOK-ETZ:W2-K[;$@5=K@I^9])6!:+]WPGKH M&(MU^<6P)]+ZV/-%JPOL\YQCO>M9;0U[5EISO:LMK_<<*\;[1.EIHC1G&=ZU!&>[8KTCK=]44K&GS)=8YUDFNU=;9KI?5U?/TJ7F?# MG^Y MO?XONV/\)[HM,-/13KX_=TW[K(<><=3D/0)7IP?9G[](^_./Q`:?]FF9B>;< M$!\X?7UN8&7^A@T;E^"8CL)2%HDY^#H7=9Z'KU'HNG[\C4*]Y^/KL30U"M,F M[RD'']%H)_]`-(]U\B^?L7\GCQK[Z\^*2_^7MO#!1S2ZA7>)VO_0%@Y] M[2E=^>$U5L$,KCW;9G+M>>RAGU7>M7[B.UQGE0[,J`WN#.QXI\G9=C[+UR6& MO9]@#_U$_-OKDON\BZ7E.U(N\"V6O[1/C!H?9I&__JJZE4G/E[I=AO MRP4GJL^?U'AHK2-HG-KOUO>P,I+8+<=]#'(,7#QA?!)R$EP:87PF,3D!/@4@CCTY'3X;()X_.0\^"*".-+ MD4OA*@GC:Y!KX!H(XYN1F^':">.[D+O@^@CC!Y`'X-PNC?&1R)%P`<+X>.1X MN&3"^#3D-+@LPOA,;D!O@6@CCVY';X;H)X_N0^^`& M">/=GMW2[=DCHPCC`\@!N`3"^&3D9+ATPO@LY"RX/,+X0N1"N%+"^`KD"K@: MPOAZY'JX9L+X-N0VN"["^%[D7K@!PGCA1?_WHO<3K/\CQ\#%$ZS_(R?!I1&L M_R-GPN42K/\C%\"5$*S_(Y?#51.L_R/7P341K/\CM\)U$JS_(_?`]1.L_R,' MX2)\&M;_D:/AX@C6_Y$3X5()UO^1,^!R"-;_D?/AB@G6_Y'+X*H(UO^1:^$: M"=;_D5O@.@C6_Y&[X?82K/\C#\+YPC6L_R-'P<42K/\C)\"E$*S_(Z?#91.L M_R/GP141K/\CE\)5$JS_(]?`-1"L_R,WP[43K/\C=\'U$:S_(P_`N?T:UO^1 M(^$"!.O_R/%PR03K_\AI<%D$Z__(N7"%!.O_R"5P%03K_\C5%B"-;_D>/@DHC=( M:\:N$/-G=86X%N^Z!E>'FK7L"G$MKA"OP=6AQO@DY"2X-,+X3.1,N%S"^`+D M`K@2POARY'*X:L+X.N0ZN";"^%;D5KA.PO@>Y!ZX?L+X('(0+D)JC(]&CH:+ M(XQ/1$Z$2R6,ST#.@,LAC,]'SHS-,9'(4?!Q1+&)R`GP*40QJ?!%1'&ER*7 MPE42QM<@U\`U$,8W(S?#M1/&=R%WP?41Q@\@#\"Y71KC(Y$CX0*$\?'(\7#) MA/%IR&EP683QNPOB]R'OA@H3QOK"UN$*\!E>'&N-CD6/A$@GC4Y!3 MX#((X[.1L^'R">.+D(O@R@CC*Y$KX6H)XQN0&^!:"./;D=OAN@GC^Y#[X`8) MX]V>M;A"O`97AQKC`\@!N`3"^&3D9+ATPO@LY"RX/,+X0N1"N%+"^`KD"K@: MPOAZY'JX9L+X-N0VN"["^%[D7K@!PGCA1?_WHO<3K/\CQ\#%$ZS_(R?!I1&L M_R-GPN42K/\C%\"5$*S_(Y?#51.L_R/7P341K/\CM\)U$JS_(_?`]1.L_R,' MX2)\&M;_D:/AX@C6_Y$3X5()UO^1,^!R"-;_D?/AB@G6_Y'+X*H(UO^1:^$: M"=;_D5O@.@C6_Y&[X?82K/\C#\+YPC6L_R-'P<42K/\C)\"E$*S_(Z?#91.L M_R/GP141K/\CE\)5$JS_(]?`-1"L_R,WP[43K/\C=\'U$:S_(P_`N?T:UO^1 M(^$"!.O_R/%PR03K_\AI<%D$Z__(N7"%!.O_R"5P%03K_\C5%B"-;_D>/@DHBUA^$*\3$Y^HELU"R?(39( MW&/+/?0^@Y5A1[-A1`#L`E$.P> M&SD9+IU@]]C(67!Y!+O'1BZ$*R78/39R!5P-P>ZQD>OAF@EVCXW`44C M1\/%$>P>&SD1+I5@]]C(&7`Y!+O'1LZ'*R;8/39R&5P5P>ZQD6OA&@EVCXW< M`M=!L'MLY&ZXO02[QT8>A-//L7SL&5`4&[D&KH%@]]C(S7#M!+O'1NZ"ZR/8/3;R`)Q^CN5F MSX`BD2/A`@2[QT:.ATLFV#TVP>&[D3KI=@]]C(_7#Z.99@SX`B=(:+(=@]-G(<7!+!GK$BI\)E M$NP9*W(.7`'!GK$B%\.5$^P9*W(57!W!GK$B-\*U$NP9*W('7`_!GK$B[X4+ M$NP9JV^W]/GVT'.L:/9L*!8Y%BZ18,]8D5/@,@CVC!4Y&RZ?8,]8D8O@R@CV MC!6Y$JZ68,]8D1O@6@C6_Y';X;H)UO^1^^`&"=;_P]'_P_?0N@*LA6/]'KH=K)EC_1VZ#ZR)8 M_T?NA1L@6/_WH__[]]!SK$CV;"@&.08NGF#]'SD)+HU@_1\Y$RZ78/T?N0"N MA&#]'[D?8T4;<#X?L\.H@>^A_E..$TK?"OS37":.O@ZYJOA-.7PY0?2YMP'CN^$T[?#MS+?`:1K@&YBOA=-4PE%8\UE?`^ZT=1"=\)_-M<)HF^";FZ^$TU?#5S%?`:4K@2Y@OA-/D MPNKY_HA.]DO@U.TP3?Q'P]G*8:OIKY"CA-"7P)\X5PFESX7.:S MX#1I\&G,)\-IXN'CF0_`:2+A(YEWPVD&/!Y@?)_'3W3!=S'?#J=IAF]FO@%. M4P-?PWPEG*84OI3Y(CA-'GP>\]EPFG3X=.93X#0)\`G,Q\)IHN"CF/?!:0;# M/,#XO6%^HAN^F_D..$T+?`OSC7":6OA:YJO@-&7P93A,#'\-\))Q&P`OF!UQ^ MHM>%8\UE?!>3A,#'\-\ M))Q&P`OF!WPW$KV^3<#X+CA-&WP;\\UPFGKX>N9KX#05\!7,E\)I"N$+F<^# MTV3!9S&?#J=)AD]F/@%.$X`/,!\%IW'#NYD?]-Y(]'DW`>.[X33M\.W,M\!I M&N`;F*^%TU3"5S)?!J\-N)#KA.YEO@],TP37":+/@LYM/A-,GPR)6GIMQ_XLV?ZJTOZZ#IFGKO`]Z1(F7/UV._? M>63?DY_I%&&][+W";=+H$H\<&]>\\9^\Q>O7;'OD=.M%E_D=0.._0\C\%J'8 ML=\BM!"O1W^/T(7KKMJXX?H-:PL#&1LVK]F8L6'=^L(Y8]\=,?%;A`2VQO[S M==%\S3A&?Y.0'H<<^RU`9LS+!57,M9B\J!&B1)6(G@(A>GJ$4"DI`B^%JL'7 MEA;,O86^K63LGY*Q4#+VH@7?T]+=(G[]8K]0(_VBIJ86ND30#^0I_3.6HT&- MO1BO?*+EHNUU1LCJ^9QB^V.9ZYK=M!XUV;06]==)ISW@Q*J)GPQ-2;',S]B- M[R&C/YGG.>`G1+UL']';:J$O5FW!_+9@?HFJV/8Y^V\K><"V,J-XQ\ZWMSOG MFU&4B(E1^"9^0F_JT7C&OL\K3J7C[ABQUD7K.`]@FPOFM]#O-4,N=?XJSW3Z9+(S(,]SA)7F'&FE.PNM;S@G6QN=9ZR;'<>ZW3G% M5>%\P_5+I\CU$#BT8VGR+94E?R?UM%!;8^;[[^C6^)W,EE>YLC'7CS'WF1Q+ MC\E3K-M";HW9=[9+,=,1&9XNXV7E'W.YX986S5/[2R9(/@4,[EJHGW5)9H+:JG8&/)J(EZID7:19$]LM8*I]MMBJD2R>%Q]Q7Y!IL`.OZX)GJ"W!9'5W M,%7]!.^Y/7B)NC7X;75S\`EB>?"WZJS@T^JT8(LZ.=BF8H*[U-'!MU1$<(_R M!OD,%%PA,\6(1<'SQP#=SN+[*OE\U.>7:;;G\9_W\OSKJOE(OMN9^H1AAK-GU2!.DLTAYS6 M3M.Z0NZM82K='A`1*E1]/9\[KC-I;XW#N]ZS/:K+]JL_V9&JV8Y6V^TE:JM] MBKK/7JHJ[&7JA_8J=9/]'55@WZ"NMLO5%?:O5):]4UUL=ZBOVWO4*OLS+/D( MD6XO%JOL!)%AIXI,>[7(LM>);]LWBER[7.3;]XJ-=JWXGKU=E-A/BS)<1__4 MWB7NM]\2=?;?Q`[[??&TO5<\9_>+5[`6W;0F'N4/>6T:NC(W3%&97,S/W)WQ MX]AT,E,1&Q7I1T7^AHITHB(OH"*_0T6>0$7J4)'[49&?HR)EJ,@MJ,AF5*0` M%;D6%;D:%5F+BN2B(KFHR%I4)`\5R4=%"E"13:A(,2I2BHK<@8K\%!6I0D5J M4)&'49'?H"(MJ,B+J,AKJ,@[J,C[&/TGM`8>=<*T*W*"NM[NP+^3WY/J_6'J M_NX=.]Y.4!WB>ON$@QQOH4;A%K>JA>*>D-LE"FN=*CHF^JMJ:0G1$?CG0]'N M7?8*O"MJVLL_6_S>OD+TVJ/O?M?.P>NS#^DL,OWC^#WU%;$JY+1!YS;UOCA? M3G6L>B?VR$%GD1ARY@K;$<*E/E%S,.=YJELM5*^J6/6"6JJ:U7*U0UVB'E)Y M:HNZ1=VC[E9WJI9=;MZ7?U0_4/=AF7?IHX2/U0GBO^#D?U872#N4MGB M;G6=N$_=(AY4Y>)A]7]%@WI`/*FVB6?44Z)-M>(,^;+XJ^H4'ZBWQ,?JKR*H M_BX\XGUQM-!K,(2KP>E7Y!^35F3(N4?UB=4RU#'J_=PQ.N0DB&'G!.$X1PNW M\J!7#*FCU4?J./6N.DF]I4Y7KZCSU'-JM=JIUJG'58EZY0&U3]ZM67+N^ MH:K4AS`2>^8\4:5BQ2]4DMBB_D<\H"X7=6J]V(:3P&_53T2SJA+/J@?%BVJ[ M>%7M%&^KY\3[ZL^HQ.NHQ-LB3/2(N:)7'"OZQ,E"K\&PDSGMBLQ76U'AS)#7 MA68_.-@5\>B^G2E;Q58U?Q;'J"4^5=&XJ@QY'X&U3L)WF-]YUC+%E>OH2%SB M++S+-^WEGRKZ5::8/_;N!>(2O#[U?^48?4FM%I.=:]WJ/OF)^*9KZO/I^![I M5HE6F#K9"E<+K+G*;RU0MERL/I$GJP]D@MHMS\55\(7J17FE>D86JM_*'ZMM M\E?J(?F4>D"^HK;(OZG[Y:=88H2X3RX2]\O3Q"_E^>)!>8EX2.:)Q^3WQ!/R MQ^)I627^(!\4;7*;>$7N%&_*Y\1?98?X4/Y%?(HK:&&])\*M#\71UD=BD?6) M^(*EUR!,986\+PU]'KULTHJ$X6I]0%SCFNYY--7RJ#,M/^XV(M5"*UH=82U1 M+NL4-227JG_*9>KOD7>@'N#:-X5I:+E^2]8I>L%5URN]@MGQ;OR>?%1W*7 M&)%O"8_U-Q%IO2^.M?:*$ZU^\25K0)QMZ37PJ+QI5^0$W*]TB+PIGX-,]SR: MY^H0.^7LSJ-KQ$)Q8\AI45CK5#'?&A]AB2HYZ'ET@;4"[YK)>=1M78']:?3= M7[1R\/KPGT=G?BR;3RK&_X3Z?OX9S?AG-OT'7-N?(O5G*?O_QL!Q?[!/DBY% MO:_&]__+)<1K\G!_DG2M2)E3)4<_);BU?V7/Z&[>SU?GSQ!5\B3CPFFBJ)S1F M?]'SCG6%"=O^FZ/GN<9Y7MT/3G9V3_L9WA)Y!?JS=9"EAD\<6>/+_*K\KOJ: M7(\SWK#Z@?Q8Z?D=!K# M`-]6_=9X,?A"RMM-= MSUV#CSBONTXQUUULVX?OU[>F\\RTE*J0@KD^J,X=JE050[>JMJ'OJD^'H-<,KU2^'OZ)>&XY71XZN'HE2M2-^U35BJ?#@L),B#WA7"6M2U6&5:!^;)6J/UH_5X[UL$IV-:LRU^OJ9==' MZG&7I/_RY5NN:'&B:['XB[5$W&4M$L78&M=8'ZFO6F^H$?D85?\">1'N2):H M.W$W<*YXWQE1NYU;L17V.+N<..<-YQ?VV]@:[SN/!)\[I#TO,!0M7+[K)LZR M0GS^ZB=\FL>'5YQ)6^18\7#8:?+YL#+0+D>\[;+3.RS_Z3W5^J=WI?6.]U*K MRG.I=;-GC=45ML;Z8]@EEAR^Q+ICZ`,9/W2$%1CZ2(0-1XMK1P*BT1J6'UA_ MD`M);83737L,Y@[NFZ'UN<98T9C1CWV_];`'"^8Y6A^*M8/#AVF+37Z.<206#=X-^8\ M+%X<7(JOTQW+Q<[%V*.^'7*:'+Q3?CJX51[.;;@5<[Q3REE4[=//[I0+)QG- M[+9A-$:S4*_C9X?G"?;%SC=1RS63U'([UOR%D*.?[='Y`N:X?9:UW(XU#SV: MV6W9:(QFH5['PU;+=-3RTDEJ>2W6_+;#N">@TV&.U\ZREM=BS4./9G9;-AJC M6:C7<1:UG.ZHYPX^H#R^!=;AN;(I$?H\NDR\C;F>`N8.6N(*XG(9'!R62X;\ MUKE#<'0/+EVZ$U1/O2@>':H0+B&_T=&WXO\1)(\O$ ME2-7B)^/_%"\,M(B_CTBY9'!<^3\X/5@GXQPS;4B7/?*DUQI\CQ7N%SO^K-X MS/4+L<]5).+=N>(^\(:[0,P+NT.DA36)XK`!L27L'/D$SN]/A'5)Q_L&:)8? M$O=(VUL)CI?[O.%RC?_9+ZL[@XZIG9.NT/PW8[+R.*Z\(:WK7S=Z)WPNOW[?9^4QNDVYK MFXP4RW$?^J@845%B0.U0'ZJ+U+NJPWEKVN,X4>U2Z2)TUW][9(FZ-7CS%/<[ MDQU=)2'N0$;WYYLQQR7J[9&9'UV#(^>J!<%L-=7UWG3WT_&C*QMS/%<-SF(T M=V(7]M.5=F&N>W&UOD2MD[+2?9^^VCQ>I M\JF#+,LG,5Z;0*/85FOS&!9+X@+I4?.?+U> M`(Y8(?MFL"P/MN;J@RPKU'HMP/9:A>WE.>S_Y<1TQWZ_'G/9K,?FT M1>C@#X?M"GEO-?61+R8]\G=9#X?!`D(+C:B.UCBU*(5?&E$*D/A4"?]@XD/??.3&9_[KAW=T9HX.YF-YES MOGOG.]^9V9GEFV:?*SM4^97O?!*RE1TB'T/D8S"^8RDRR(:)+J(F=@G]P)J5 MG"A>@:KEG$WL"OJ0;<1'87S++J,^B*.;\RZ+X_W&+R5R%L_S72..[[(Q&%.X MP\C@A'%:6S_&:1RO8*5R%L_S)&Q'(2>%G,=I!H]3_9Q'Z"3J-$:)DTM\MKNT M[!-9R#YFLVN4=!J3L*UNECFT$S'\J?KZ&VO`=]@\5K'?6[_S<19>:9B'B`V8 ML/+9OXEUX&_8K!*-=RWFHRFLQ5F(V($WE4#C5WF:E]3J)ZKU>7YW1HIU-^I@"0_1"Y"Y.LPGO`4^8GKJ\L`OX3^ MXJ74Q>UN3LX!?@5]S3?B:S`>\ZZO+LB,XRFS5*47S_,$;(?,,1A3>,+, MX"]-_4J?R<9QC.LJFCO/GV&[W7P,QA2^F]%*70O:YZG+> MG(1M=;/\MK@3F8MJ=6GC#7B)J]6ETGJ>AX@-N(V7S_Y>WH$?<+6Z>->BER8[ MZO(`HO:60//_O`:9?Y[NYQKD*?C'%L$X>+Z*O'S`7*9)K:<$762M,,[FX7/Z M2.'W\=VCS3/L#&PUC:;A.1>I^_T[Z[Z57,2Y,W?=VB[@WR'.P2('9B]'-1V7 M->'IM^VE?]`$$Z_>0TU*3S7+^^V"=9E1S\YV5=KKOE+.,$$2$EUL7W2;<%;VZ_B[6D8] M#5'%>]+3,,?#V'_D63ORGE1/SSB*2J?B.FU_\?R]\Y`^"\7H;B-(-M=+E!.T MRUAEKZIK[.BLK\I+VK]SXVW(:3DWOAFPR[)Z]>;(@M%((EJKE^^?JE6]KWA7 MKRY7NDB+(=Z+C8C8KZ(U:(/TS_2SUFN1Y=[<8@B%^*!_*#62[NT?@I5]&;(* M?\Q5TAUS=0!4 M".7X;/:7X[.IGO-]8X]QQ'@_T&YE89TQDBQ8K-TTPQ"=I<%C;:=/:+!8#Y): M&B$?$7TNZ7J9$H?R6[L+B[*;;OC9[- M$J4?S;`ZSR+$%)WG[;[DX.'!H>%T]_!@ZO#K,/M&4*8ZJ4X1Z`&U\+A2KHN? MG!MDSJ-T%Q9'N-MWO+4C&NM.]Z32T7<^.];G]IW-LLNLEX\U,%/1=>J>L#V#:T2\VD)K*N+('VPA7,U:PR^H(M;YJ0B+:^TL$;:XMKW> M/]>L*CL.,5_,4=X-.W(0]=N*_Z[^$S5J.4R7AW(M;J^N%*5[AF7Q(2+1.GS` MA+RV=WQHN#^)1O]E`_>JT#DL.!!"PM'<^KV0\0*3.(-;8Y_CUJ#GUQTO0%` M`````"2P,?3`````0```"4````!0```)P````&````I````!$` M``"L````%P```+0````+````O````!````#$````$P```,P````6````U``` M``T```#<````#````/H````"````Y`0``!X````4````1FEL94YE="!#;W)P M;W)A=&EO;@`#`````/@;``,```!A`````P```!<````#````!#@```,```#H M$`@`"P`````````+``````````L`````````"P`````````>$````0```!(` M``!#;W9E0!S`'4`:0!T`&4`C<```0``%P`````_____P`````````````````````````````````````` M```````````````F````)@```"8````I``````0``,8D```V+P``Q#D``'H[ M```>````(P```"8````L``````0``)X*``#.'0``T20``.CL``!\````A````(@```"0````E````)P```"D````J```` M+0`````$```*,P``4CD``'H[```@````*````"L```"N(```QB```,@@```] M(@``82(``'@B``#G)```+R4``&HE``"[)P``YB<``/4G```.*P``-RL``%,K M``#,+```]2P``!$M``"A,@``S#(``.HR``"H-0``PS4``,4U```S-P``3C<` M`%`W``!Z-P``$SH4_Q6,$U@4_Q6`$U@4_Q6`$U@4_Q6,$U@4_Q6`$U@4_Q6` M$U@4_Q6`$SJ4_Y6`$SJ4_Y6```````<````0````$P```!H````C````*0`` M`!,?%/^5@!,@%/^5@/__`P````T`7P!(`&P`=``T`#,`,``P`#8`-@`X`#$` M,P`-`%\`2`!L`'0`-``S`#``,``V`#8`-P`S`#4`#0!?`$@`;`!T`#0`,P`P M`#``-@`V`#<`-@`R`&TB``!+)0``02L``'LW`````````0````(```!N(@`` M3"4``$(K``![-P```````%(W``!X-P``>S<```<`!P`"``````!2-P``>#<` M`'LW```'``<``@#__Q0````,`$X`80!N`&,`>0`@`$,`;P!T`'0`90!R`#L` M7`!<`&4`9`!U`&X`=`!<`'0`<@!A`&X`0`@`$,`;P!T`'0`90!R`"<`7`!<`&4`9`!U`&X`=`!<`'0` M<@!A`&X`0`@`$,`;P!T`'0`90!R`"<`7`!<`&4`9`!U`&X`=`!< M`'0`<@!A`&X`0`@`$,`;P!T`'0`90!R`"<`7`!<`&4`9`!U`&X` M=`!<`'0`<@!A`&X`4$)!``$``0`` M`````0```````@`"``$`(`,``,(!``````````!D`````````/__``#__P`` M__\``/__``#__P``__\``/__``#__P$`__\``/__``#__P$`__\!`/__`0#_ M_P$`__\``/__`P#__P``__\````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````````````````````````__]#=7-T;VT@<&%G92`Q M```````````````````````````````````````````````````````````` M``````````"00@``D$(```````!#=7-T;VT@<&%G92`R```````````````` M``````````````````````````````````````````````````````"00@`` MD$(```````!#=7-T;VT@<&%G92`S```````````````````````````````` M``````````````````````````````````````"00@``D$(````````````` M``````(0`````````'HW``!````(`$````@```!'%I`!```"`@8#!00%`@,$ M`P````````````````````$`````````5`!I`&T`90!S`"``3@!E`'<`(`!2 M`&\`;0!A`&X````U%I`!`@`%!0$"`0<&`@4'`````````!`````````````` M`(``````4P!Y`&T`8@!O`&P````S)I`!```""P8$`@("`@($`P`````````` M``````````$`````````00!R`&D`80!L````.P"0`0````````````````,` M```````````````````!`````````$$`1P!A`'(`80!M`&\`;@!D````,Q*0 M`0````````````````,````````````````````!`````````%0`:0!M`&4` MT`+0`@`!R M,```$``9`&0````9````!#@````````````````````````````````````` M```````````````````````````````````````````````````"``````#_ M_Q(`````````$0!#`&\`=@!E`'(`(`!,`&4`=`!T`&4`<@`@`"@`0P!-`"D` M````````#`!.`&$`;@!C`'D`(`!#`&\`=`!T`&4`<@`,`$X`80!N`&,`>0`@ M`$,`;P!T`'0`90!R```````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````````````````````````$` M0P!O`&T`<`!/`&(`:@`````````````````````````````````````````` M```````````````````````2``(`________________```````````````` M````````````````````````````````:@```&H````````````````````` M```````````````````````````````````````````````````````````` M``````````````````#_______________\````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`````````/_______________P`````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M________________```````````````````````````````````````````` /```````````````````` ` end begin 600 Bldg4.doc MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````! M````$0``````````$```$P````$```#^____`````!````#_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________LI<$`60`)!```"!*_````````$```````!``` M-P0```X`8FIB:O-7\U<````````````````````````)!!8`(0P``)$]`0"1 M/0$`'0`````````9``````````````````````````````#__P\````````` M``#__P\```````````#__P\``````````````````````%T``````%H;```` M````6AL``%H;````````6AL```````!:&P```````%H;````````6AL``!0` M`````````````&X;````````;AL```````!N&P```````&X;```X````IAL` M``P```"R&P``#````&X;````````,2```#P!``#*&P``%@```.`;```B```` M`AP````````"'`````````(<`````````AP````````"'`````````(<```` M````]A\```(```#X'P```````/@?````````^!\```````#X'P```````/@? M````````^!\``"0```!M(0``]`$``&$C``"J````'"```!4````````````` M````````````6AL````````"'``````````````````````````````"'``` M``````(<`````````AP````````"'````````!P@````````+AP```````!: M&P```````%H;`````````AP```````````````````(<````````RAL````` M```N'````````"X<````````+AP````````"'```%@```%H;`````````AP` M``````!:&P````````(<````````]A\````````````````````````````` M;AL```````!N&P```````%H;````````6AL```````!:&P```````%H;```` M`````AP```````#V'P```````"X<``!F````+AP```````"4'```.@```"X? M``"^````6AL```````!:&P`````````````````````````````````````` M````````````````````````````````````````````]A\````````"'``` M`````+X;```,````P"#IX[3=O0%N&P```````&X;````````&!P``!8```#L M'P``"@`````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````$R!%34)%1"!6:7-I;RY$!```)`0``"4$```F!```*`0``"D$```O!```,`0``#$$```R!```,P0` M`#<$``#Z`/#Z`.GFZ>8`Z>;IX>GF```````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````(,$I6`&U(``0`!#!*5@``#0-J```` M`#!*5@!5"`$3`VK+C:,Y"@@!50@!5@@!;4@`!`D#:@````!5"`$`$0`$```= M!```)@0``"<$```H!```,P0``#0$```U!```-@0``#<$``#]```````````` M````]````````````````/(```````````````#P````````````````]``` M`````````````/(```````````````#P````````````````\``````````` M`````/T````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````!`````2````@@`!LF8",D`AB$ M_/\9A`$```$2```)``0``!T$```H!```,P0``#0$```U!```-@0``#<$``#] M^_CX^_O]```````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````4"(``-`0(!`0`#`A(```8M\L/B M_P#8M\L/BEA@` M````````````_0\``-L+``"P+%\`&))&`*(%````_GBII)%:#%<[V;*UZ?,6J;90FJ(V)A(`A M,1ABXD<:(G](J`F-&*T&B))4C5$2C5%3C!#D#S10FW-F=^?=[=%K3^_.2UYF MYC>[\]Z^CYG=P\A!R%I=@9"+ZI#^424N,;T*X<3I:&:?ETC#L+G%[V6AE+RM$PQPE8V0H78/ZK#[K->/(:"R5 M;.U4G5\BVWJ#D2-O9K7JLM1D+_/NG!98=]M;$A,R-/[-Q4^()99T7 MHU>POH=E]?W[+:\5V(^RA'C[SZ1[=7A6T'.R/(*12A542RO0RM;4HT^FHLLZ MMVRHP_*@-.OF]R8NBVYD3ZX[XV?]N]3/L8BTLOVLQQD_V47:;(/-\?6)KN3Z MZ/)4-V5GN[IZ*[6CD2T,=&U*9'R#4#C]-V*J;W6GZ[/RJYL MKRW/\=KRD-=HD993+ZMK*49KT%)R?E)+_?5(T,O>FQ#25YHU&=2R%3R,SSF: MH=IYED!71R+HZXJUB$:T].%Z3]:BQY7HN>RJUGN#7]TL:'F9K+O,LXZB=CYD M;W:TK+/:N98A>RJ+\N3^7!/%IIPH-H6BR(J,(O/VQEK*47.R,[&FZ;[(1>M/ M;MBRS@UM==&;(G?:7)0BOCR/!P5XL-L>LKNL;EM+/@_RH!5E](2@84_< MK#PQFTZ]*^0[D_@$9VP[CU-]QH;/HXDS]=^OOIW%Z0@+^[!TJVO;:WBI5S>G MM;9[A#5;(VR,E,=^;7L-;[;*M7JS5<-+;7O&.V-DD:VEU+ESN:>!(VW[*J'E M!+8L+6,DAK646J-Y)KWR'DO+CC+%1'M+UT1Y5M=VQW!AMI=NSXSA`V20:#F% M8UC+@5#._9][9CWIP^$])TP),3N#R1'$"]K!KE?B64 M*Y)U7B2KT7/R-]HC?Z#;Y%>T7QZGN^5G=)_\E.Y7[2$U/J+XL)K_7%TW+,^K M<5IQP?;+"-LG*]ENU?:K\3;%>]2\7F^J3,C_9OEE>J9GY:7OX\TY[R3-H7<2 M7F16^7ZJI19*)3:@[^D9Z7ACBCJ3;>V;T$SV\Z1?$X7&0X3BD>$.5-8@62"& M;2W'V"#1LD!,[$\1M$[)*BMXLB#KLVLLHC,YX%<*0RN;[FV*UO9PQ@K+@$)K MQLE3,Q*^T*;11[C.BA;:S<]YLD+UM51S/3=Q_3A!*PO.GFR;PEZ:08;=TU+W MJLBNH#>#;`6V`MCUP"Y(PTY*PP:`O0KL86!W`*L$=LXQ[&/'L+>`;01V/[#Y MP#BP;X5A'PK#7@;6`>QV8#7`SG##3G##W@3V`K![@"T&9@'[E1EVD!GV.K`V M8*N`S08V1@T[3@W;#VQO5N]X,+M7G6^&/0]L';!%P*8#^\DQ[!/'L)W`-@-K M`G8=L+^$8=\)P]X#U@^L!=A28!%@9[EA'W'#]@%[&E@2& MK>:&/0ML#["CP$:!72$,NU48%LOJ'0MF8^(4L%G,L-N888\!ZP/V`;`18(0; M%N6&W0VL"]A>8(>!G08FA6%7BO!YY$R^@^I!S@Y*4?A_>>F=?//4R5$[N?;,?/OE,7_*YESDD5:;43,FO[;ZS]7AZ1_```````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````$````"`````P````0````%````!@````<` M``#^____"0````H````+````#`````T````.````#P```/[____]____$@`` M`!4```#^____,@```#$````7````&````!D````:````&P```!P````=```` M'@```!\````@````(0```"(````C````)````"4````F````)P```"@````I M````*@```"L````L````+0```"X````O````,````/[____^____,P```$<` M```U````-@```#<````X````.0```#H````[````/````#T````^````/P`` M`$````!!````0@```$,```!$````10```$8```#^_____O______________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M________________________________________________4@!O`&\`=``@ M`$4`;@!T`'(`>0`````````````````````````````````````````````` M`````````````!8`!0'__________PP````&"0(``````,````````!&```` M`!#1-8NSW;T!`,T0Y+3=O0$4````0`8```````!$`&$`=`!A```````````` M```````````````````````````````````````````````````````````` M````"@`"`?_______________P`````````````````````````````````` M``````````````@`````$````````%<`;P!R`&0`1`!O`&,`=0!M`&4`;@!T M```````````````````````````````````````````````````````:``(! M"P```/__________```````````````````````````````````````````` M```````````0````````3P!B`&H`90!C`'0`4`!O`&\`;``````````````` M`````````````````````````````````````````````!8``0$.````____ M_P0``````````````````````````````'""S>.TW;T!`,T0Y+3=O0$````` M``````````!?`#D`-@`W`#``,0`Y`#D`-P`Y```````````````````````` M````````````````````````````````````%@`!`?__________!@```!$: M`@``````P````````$8`````<(+-X[3=O0&PC]#CM-V]`0`````````````` M``$`3P!L`&4````````````````````````````````````````````````` M```````````````````````````*``(!________________```````````` M`````````````````````````````````````````!0``````````0!#`&\` M;0!P`$\`8@!J```````````````````````````````````````````````` M`````````````````!(``@$%````"````/____\````````````````````` M```````````````````````````!````:0`````````#`$\`8@!J`$D`;@!F M`&\````````````````````````````````````````````````````````` M````````$@`"`?_______________P`````````````````````````````` M``````````````````,````$`````````/[___\"````_O____[____^____ M!@````<```#^____"0````H````+````#`````T````.````_O___Q`````1 M````$@```!,````4````%0```!8```#^____&````/[_________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M________________________________________________________`0`` M`@`````````````````````````````````````````````````````````` M``````````````````````$`_O\#"@``_____Q$:`@``````P````````$80 M````5DE324\@-"!$S MV3````"$````!@````0````X````!@```$@````%````5`````,```!@```` M!P```&P````"````>````!X````(````86)A8FEC:``>`````0`````````> M`````0`````````>`````0`````````>`````0`````````>`````0`````` M``````````````````!6`&D`$``-U M!E8!!&)5`E4"!98$!I8$!Y8!H(`!T@-/"I<(3P`#E@0$!%,$NP(_YO4*'QP6 MT@&$`50<%J$!`38:`C8:`S87"/H-^O^``0!.`Y<#E0>7`U#U!Y<#NP^7`PB6 M!`F6!%4*E@0+E@0,E@0-E@15#I8$#Y8$$)8$$98$I1*6!!-V'XX0!U``8:L` M_D,@`4)@#]_Y8CI((;3P%@EQ2P M)`*P)`/^L"']`:,`3@*$_P`]`J0`[`&@_P`T`8<`Q`"&_P"*`(4`(0"3/C<` M"`"&`FF!`#X!?7#?_!`G`#!5#C*#Q3^.$)(?I!^6`80`!44AZ//PD`+#`H0` M!PTV]_X`E#<``0!G`(EJ4``^`:3E]AP?B38P'3.<,O._,),V)A8P']1"'Z@% M#Z,`(9PT/Q."H0$$I#9`,O8WP`)4`)6^9S*<`&L``ST"'%R@+T^-3Y]/L4_#3_YO,AS'<4=@K#]&;Z!89BX56&8+ M4G)J`G)J`Q1R9T9?N`T``[E?*0S:71F0ZU_]7P`9<6<6?V%O<'-OA6^7;N@C M`@"$#0`$:#"[5`'#7]EO/P!U!M8&H!XU!&6`)=0(EP"&=W8TKP#)``41``#C M(`!3`"*!`'QQ!A]`!^LB704[0`8`"D(@"_I@50P[0`T=@`XA@`\E@%40*8`1 M@P`2,8`3-8!5%$-`%3V`%D&`%_7P51A)@!E-@!I1@!M5@%4<$W`=[?`>88`? M)4!5(&F`(6V`(G&`(Q4`523G("4%@"8-``:%?T"7?ZE_NW_-?M(-[GE*0B"` ME(^FC[B/RH_.?6@QU@8$`OJ-"`N?'9\OGT&?S7ZX4`C5![4`_(L)@Y^5GZ>? MN9\HS7Z\8-4'`_J-"ON?#:^@'Z\QK\U^"I#5!P?ZC0N`OJ:_-?OQP MU0<%`OJ-#.NO_:\/OR&_S7Z2@`K5!P;ZC0UCOW6_A[^9OPK-?@[3"0[ZC33` MW;_OOR@!SQ//SWP/TPD/^HVLP`!5SV?/WU@_`(D5V`_3>&H&40%T!\9#_U4` MY28"2U"!2C6`S,_>SWC/BL_.?1$"TPD1^HVPT%G?:]_QSP/?E!7?;00"+]\" MM`%&W1*`S]_AWWO?C=_-?G*@U0<*`OJ-$UOO;>]_[Y'OS7[:L`K5!PWZC133 M[^7O]^\)_RC-?OJ0U0<)^HT52_]=_Z!O_X'_S7YBL-4'#/J-%H##_]7_Y__Y M_\U^@I#5!P@"^HT7.P]-#U\/<0_-?NJ@"N%W"_J-&+,/Q0_7#^D/*,U^TN#A M=Q/ZC1DK'ST?H$\?81_-?L+PX7<5^HT:@*,?M1_'']D?S7ZR`.%W%R+ZC1L; M+RTOW5I@`>\3[_X/84\;Z+2!3FN#/P`NW?Y![";8)DC75`*/(!R3+Z4OMR_) M+]LO$V8@]B\(,!-E$S\E,ATK/ST_^$\_83]S/[@>A>M1@[B>C#\&,AU%JS\E M,AX`PS_5/^<_^3\+3^TO_R\1/P*[-!];3VU/W5KF89!/HD^*M$<#,^\"8*'. M3^!+7"J/("#S0`.]4@/]3P]8`0.#3O1A6"MV-0QC*'_U7W+B=`3_879W5`!I M8U#JZF$\$58"\6(0)P!+,G+V4L$Y<#UQ!T-FZ`)QYY*MT)1CDC$`:I3\8.IA M4!%6/WIOQE4PG3.>8O._,)5FQEL&*@]RE6.21X\@(9-?I5]`MU_)7]M?]E\R M?F)4!.IQ`AQI:BED>&]U?YQOKF=C4PD&%4+$96EQ9#!O0FKDE01/:V5H2GV` MT&_B;_1O!G\`&'\S?SQ_3G\D;\Y_X'_R?T!L;WM_A'^6?[1OQF4C"X\`'8\O MCT&/4X]NC_]?$6^;CP(KD@RSC\6$*0#/C^&/_(\0!9\7GRF?PV@D1Y]9GVN? M`'V?CY^JGW>/B8_7G^F?^Y^`#:\?KSJO0Z]5KV>OQ68E`(.OE:^GK[FORZ_F MK^^O`;\`7W]VOW^_D;^G?[E_([\UOP1'OP&&)K^_T;_CO_6_!\^`(L^SG\6? M$[I,)K&(7M.\8$MFK-5M4OA!I+%`_E>T`3=?OV[/=\^)SZ>_R6#_#`$``%Q< M24[_1D]#25197$+?86YZ86G?_`$$_P$#G`!P``-S\P$`'`$,!``/`%CS`@(= M`"P!``!,90]T=&5RW/]/#V$/H!?`7].>OP"``1`",`_P$` M=VENV((SP()8B``G@'I!$X&G@$%[0<`D@"=!(L`WP!EBP`>`12N MY_0$`$CI\H,'$@H!`'7=Z?(@\_```,_I\O__``$`D#./_\^"\XZ["`\.`82[ M]P$[B0\`@[L"L/HE!0`E`H*[`[#P_C<$`@_PB3,'.__S\[NP__")`'T%3@$/ MBO\%\$X`2["+7@8&8`%;`0AP`C92`@B[3P"[#T`%/@4^,P:#NP&PB@\/M@M_ M,P'SC_\!\_TXZ_!$ M`-<&`";A^@'Y\`$`?6@3`50```P$Z/.]0>CS^#]!^/[R]]4_+`3P/07@1@[0 M/_]0&"U$5/LA"?M``10!`"$``@+_=0Q@=0I@!.3_8@(`!W4-8'7]"WH$`X`1 M0/X.]P`"`T<&_A8``OD&@01U!(`20/X1IP`"`'@`=0`#?`$&XK4!`80`@0#` M!!(``E\$=0)@($@%!=;U_IHF@!9`_@``_4___?_^9S`*"T'(`/]@.4-O<'ER:?]G:'0@J2`Q M.?\Y-2!6:7-I;_\@0V]R<&]R8?]T:6]N+B`@0?=L;""$,G,@W`&`/4VAA_W!E+FAL<"$CGSDP,C``83#X\`)1`1HF:P#\`@-($@I] M`/_^#0`""W1.8%\$`(!S0/0Q#/DV_P"D`*H#HP`Z_P.<`#P"H``:_P*$`/0! MA@#JOP&=`#0!FQ,0".\`YP-L"1%5``!=R!HE`0`'MP!AT#%D7!4K!=!_$,TK M``#=+\3O(BU""H]`Z!&.0`%!51!O*^!_$`NW`'(0$>'`=4RW(2D!G49P/0HO MUZ-PU:U+#W=#M$$'`<`$34=](-I'_`#0(?SN3G8G'X7K4;@>"<416+!``?9# M*E"=1C97`+!(2%G/2`X'L$]K2"D'5TJ*E%(!CT``1U/-4$<0`/\`BP!Q`8L` M/JKC4!/C4.O?4+[?4(VNWU!<`(J!$(D3$`E/`)X!9+<`(`'8ME6<55[?`X!& M0&M&,V\!XP`UMP#?!NX`!>1B_5J74@+`!(`40'^`*$`%(,W,=6'[W#_<``6! M`@I`GOL!`F(M`'5&-E/54.XF$!$$$!,0`H]`!/GP"K%A!K!B!X]`!!`U$+5@ MBC40!,QB!`\!`0",P4\?9CK\"4`+0`"Z?+_ M.>(+`!0`___>XOD!``4@W/\``/\&`$8`Q@",=W_T.*0(``";Z_#_(P!"``QZ M]#A?/PD``('K\`H[`%\\>?0XP$,`/D<"?T``/'7T./Y#`/4!Z_!(*P#<=O0X M??]#`*L#```K.P!]?$\`J@T``#L6``,`(P```"0``@`G``,`_T8`__\`U@(` MA2#K\`+O\/SSW/_X\6B^Z_`!5```Z.?T0;;H\PA`*@W`/SP%O^U)Z//P/TX& M!``(6/;Q9@]X#P`!ZO$.^?`J*@;^D0`!E0H"/`:>`?T#10;^"``"!F*[!`#( M`0=B`,\""'MB",\""6(@`)X!Z01.!IX!!>T'`)(`G02+`-\`98L`'@$4KN?T M!0!(Z?*#!Q(*`0!UWNGR(//P``#0Z?+__P`!`)"(C__O@OB.=P@+`7>,_X@$ MA_CX<(P`'AX"B_\%\"8/.`]*#^!<#VX/@`^2#YP#C``#^W?X"0Z.B`'XCP?_ M`?C]4>OP4F5C=&%N_V=L92X`('=I_W1H('1E>'0@_V%N9"!C;VYN_O/P:6]N M('!O:?]N=',N($-A;O\@8F4@CSG4#H\_@_0"4#,P`$JBX%`NGR\#T%Z$8%X'L_4`L*``X` M`BL')?YQ``$U!GX!`CX&?@']`T<&_A(``@1U=P)@(.CSX#\%J`&G!74#KPEQ M``9B!OY?"``"!V+8`PC?!'T)WP$H``,"!14`_P$$!0`$``<`J07Y\`$1`@`2 M`0`2`%0`$/,``_<"!?T"`0,2`"H0"Q`J$!$0*A`7$"4$#P;^VP`"@$Q`_@`` MG_W__?_^7Q`*"T'^@`!@.4-O<'ER_VEG:'0@J2`Q_SDY-2!6:7-I_V\@0V]R M<&]R_V%T:6]N+B`@[T%L;"!\$G,@OP"CL`)'[T./5; M0P!;1P)``.1T5_0XMD,``>OP*SL`7UQ_]#BW0P`WZ_!]2"L`-'?T..Y#``$? M$@#_1@#__P#6`@"%(.OP`N_P_//<__CQ:+[K\`%4``#HY_1!MNCS"$`J#<`_ M/`6_[4GH\_`_3@8$``A8]O%F#W@/``'J\0[Y\"HJ!OZ1``&5"@(\!IX!_0-% M!OX(``(&8KL$`,@!!V(`SP((>V((SP()8B``G@'I!$X&G@$%[0<`D@"=!(L` MWP!EBP`>`12NY_0%`$CI\H,'$@H!`.M/`>KQ(//P``!!_N_R_P`!`)"(C]__ M@OB.=P@'A7??`7B#B(43`H,`[P((B(0+`(1W!_\`?___<`B'@_X+`(-W`7"% M_P+[\(@U!`>%_PKW_PB'=W?X^'=WOW"'_PGPB%`#!_97`/<(4`,/B/\(_$X` M4@!P?XC_!W!^0"+ M"'!H!P=OP!P#W`0$1`BH`$@,`$@0& M%`KV`!T0X04/$1\1*1`F$`P``13V`#40`/,``_<")A#_``$!`Q).$`L03A`1 M$$X0%Q`"5!(*0A`C%D(0+Q9"$#40^&X`"PK;``*`3$#^5&@&"0P`F1$`WP0! MWP1U`M\$`]\$!&(!V0)%!=\$!M\$W@_Q$PKX%%4+^!0,^!0-^!0.^!2-#_@1 M0`92!3TF)0/U*DTE\DTEY4TEXF$-J0`I`JT!/P/LN`,#OP%1!2*Y`@"M`24# MMP0!OP&M)RD*]`(U$`2I`A^O"Q!X1#@:$]Z2^(QC$^>3P``D.\`#`&0&P"*`!S[ M`(D7``0`H@%Q!/GP(`$TBA0>3](]LRFF2`!1#GY?5$^N3[1?XC_84L-.P+9? M`&W^40Q/0D\`;P7^?YD`Y`"9`*R'8&5TAV`\AV"2,1P!?9CK\+L`+0`"Z?+_ M29\#``L`___RXOD!]?3>_08`1@#_Q@`\@O0XA1+W``";Z_`C`$(`_XR#]#@@ M$P``]=#K\`H[`'Q[]#CU\$,`/$<"0`#L=._T."P4#@$``"N^.P#DA/0X+6,` M+ZKK\$@K`+Q/`%QC`-H`$@#U+.GR`>OP`RA`/4LZ?(!Z_`#*%R/_\+U*!M`&NBT7X%.&Q1`Z_`D MZ?+W"P`<$0`8``(``QX`]2SI\@'K\`,H7(__PO4H&T`:Z+1?@4X;%$#K\"?I M\O<+`!P1`!@``@`#'@#]3.'Z!`!``$(`_YQT]#BM%P``^2S<__WR3'OT.-G\ M!P3^\=R!]#@%&``(`_EVW/_A^@,`!0`>_P!3`%1U]#CE[PT``'SK\,D`0/\` M3`;T.&$.`/D`*P`1`KQ^]#@-[Q(``'@O!%Q]]+\X-A<``'?K\#__`%(`3'3T M.#$O&```+.GR`@T`````````````````````````!``````````$`']0`0`` M@`)1[_#NX/L!`!7I\OS_Z?__A`)5`00`_VW_YO7H/^GS$T#I\L?('$#U_@," M!`$!`,=G``DV#T$(WOU#.M\"`!T`"`L"=``?M0"U`0)+`I@;^X0`!21N%!.X!Z0*,!NX!`Y4& M_@@`WP(&8@,`&!$'8MT`'Q((8@@?$@EB2R``[@$$G@;N`04]%^\`D@`$VP#? M`&6DVP!N`:S<`MH!2.GR`G)O$@IG`'`1$@`&;Q)W&@`';Q(B``AO$IB`!AO$JH`&6\2 MN;*+$'`1N@`;;Q+"NP`<;Q+*`!UO$M+K``5')!YO$MH`'W)O$N)%`'`1Z@`A M;Q*Y\I,0F\4$4!`>P,-0"$$T_P_(08A!.RD M-U`8?RU$5/LA^;_9`_TA_@!U#&!U"F#_!.1B`@`'=0UW8'4+V#0#@!'M`HT# M(0;^%AH0WS33-("/$D#^$4D`UC#3,`,*VC$&$T$!XC#?,!Y$?!"]`DXP``$$ M$CH0=;L"8+,$X#\%-4$#.CI"!4!`!74#1DDA&B(F$PDE$8HWBS,2CD61-D<& M0`$-(#A$.4,&.D*@JT&]0K1.54.U20&L0`&`W$_A`8HV[@*/1OP""%H#>T`I MHT3^``"=0`!]FU<0`@"V`6Q?$:]5``"4U04!C1`"[P!A`?Y=4`%A`$)C40)H M4*4]V@%`0`!$1X<```414_4VG#^$7?#<3T"86XL`4/L0'``=B5<0`P"$;Q!V M,%$_4&,_=3IR!8HT%Y(^`)L^'?"D->P_4-$+(%*G-0KO.?P)$@9>9NX!)V<1 M4P8S4PU`-4)V,3Y/4$.W8HA;3VU/?T0`0E%:$4I5V-A37V5?JCC\/X1?!?X" MO6`!W6?(47)?1G]8?911\#IM?'_(49)_BP",`'>+`%3=5@0`Q&\0X,1`[U\! M;Q-O)6I0N!Y/A>M1\J0VFS4"FS6"4V;R76]O;TN$B&^:;5(`.80U0L1"O&]1 M0L1"V&_J;P#\;PY_('\R?[1_CG^@>:TU`0*I0$Z?6G]`C[9_EI_:?P#LB';P90-:4"I&D) ML6-8$<&/4$/#HMZ/`/"/`I\4GR:?.)]*GY2?H'@`4V90O\R?=+\.`8J_SI_@ MGT+L&`V0?ZP MQJ]/1(#)PN2O]J\(OQJ_++\^O^``17^5GZ>?5=_1OWG?A;^=WQ35?^=X!D$` M!`/"%L%,`U`Z01;-6!%J!02#-1"115XX@_$_0/Q,`O5FQWI2Y.6D-<`_4"C" M,U`1`7S#/^>JB?$)$@)2Y@+O.="W@P3@S,]/1,'BZL_`FL-WY?S/#M70"QD0 M`H"O3$#^!.=0WQ72`@L`]AW64&<4VP`QTCW2`#O?1[]?WZ.[4^QX_]C?G/\` M;,&R_Z+?<)_H_XK_#`^N_Y0P#^C5_/'0Q/'0\-L&TP`T`U(NP15!.6%R_V)O M`'!>\7[RGOA3,!%I%%E#93[V7O=^\[%J1L0*'OL^?'[^/O]>\'_P`U0I#_ M`,3@V>$&(@4;_RWR```S_T7_5_])#UL/;0^?_['_`,/_F"\?#[PO0P_@+X(O M!#\`IB\H/W`)^S\-3X0?3RF(5#6`0$P^AEA& MX@!B3W1),G6(3X+%MH"E3_5@`+I/S$2R2G9ICP#P7XV/%&^QCSAOU8]WC_F/`)N/'9]L;WYOD&^B;[1OQF_W```: M#HA,86ME?R!#96YT97+L9F$*]F\(?QI_+'D60#%S*Y005,784$[(77]O?]$6 MD>0[I99)V)Y_`P(`]9"U?\Q$LJ+3?^5_]W\)CP`;CRV//X]1CT.?59^FODJF M`&F_ZX^-OP^?L;\SG]6_=[]`^;^;OQW/9Y]YGY4W"@ZXY4ZW-CP-NZ22.8[C MSSB.X\BPD1NQ8@&E`)+A![[&\0`+"O:6!**0"_3"`Z,/KRL5E3PYY1(S MJM1'X.;3Y`I03M1G&!QS%#G@L9.M&.8PKA%`B>,WIA040`D!=:^'I1&:%)#5 MJ1.9U2#SH`V]3=\[W^W?49:<:\'G`P(!.K5&PP&D`-\-`9P`QB2PM@#WG0!7 M*+(%`"$!JC&UT$/'!P'-P-JP0/$0^-L1P8GG<#T*U\>C<,6&X0#FI^\_0'\? MA>M1N!ZUANJHS^^9N77O`73`E'3`@*ITP&QTP%ATP$1TP##J=,`<@,`'CC() M`*@+`"B8-"SXQ$S_,\'`%;X#H___"P!DN31$.`/%VNXNPX!&0&;&H/]7``"> M'*(\_``,]I"5!?+&#"RP!0#?'J`%\AZHH`/%B7*H#$!`OWZQY!=+?CU``C[, M(NP_0*NJ(`%<<`H6`]P=!=)FKWU%"0"-$T%_#@2;$Q8%J1,?!?X:L*X-O80` M@2BTDC"VB`!J[T#*%0>]#QT'_^GE#T'))"'_,_,&,+`]]2[2\D_]Z/?!H$$6 M`_!J]O__#`L`<;DT@`/%*`8/M]L-"=)B\"<-XJ(1\`RA'\<3U9E^P)GLT)E$ M\)D`B1C@$%OA:+.0*["2D!C^#KA&:6QE3D54?PI";&1G+B#IP44-R/H-UO_H M__K]`@L/"!T/+P]!#P)4#V8/>`:7FP`ZL9,/I0H"'\0/U@_H#SX_B`P?'A\P M'`U`'U(?:_0-`&P??A^0'\H?M!_V/]@?ZA]4_!\.*C(<(`[VD`+ZDJ1N(0.C M`\Z0#:T"'JC$["IU.W*H#3EU!D!`)?YF$O&9M\5$X9FWD2S](1RP=0Q@=0I@ M_P3D8@(`!W4--V!U"P%4`X"\TZ.EX@&P%N>@"%3\1(`20%O^$=ZQ"F#\0`,# M404&/%$!"U`(4$=4KJ%W0("UK\=T8U+3K_.O!;2(=`EPNTB9TXW0O44!`!9@ M50)B4P9C4M11=D'<7WY3WEF!`=50C,`';4@'M5"#>0;0O=3"59^C0&8`5.`` M`4HIL[9@YI1`YD.S`4J_@#S/3LZ$$_@ MBD^<3_[YPT"]0P=`0'^H])>;=^/1S4CZ9'/!WTA$ONN2X0.V\6+Q]4\'7QE? M*U\]7P9/7P,"%7!F7\>D`8*$7X"67ZA;6';#0+!387"]0P@(TE0!@@"#!@&" MZE)WCP%A`(V.%F*CCRUH1F,^;6"%5FD!"&-O=6^';YEOWV^];V-_".%O\V\% M?1`6?RA_.G_^^?$(67]K?]](]DW.B@.*1NS2DW^E?[=_R7_;?P;M?P,"LY`$ MC\>DGZ(BCX`TCZA?6(OVEF^%GZ*>HP8`GZ+J4A6_`6$KOA9B0;\M;P#=C_V# M]8\'GQF?*Y\]GT^?(&&??"W<1M)_&GY+8G.C\^F6'"SK5"/;HA,U( M];/8D"_!T%JF;MCHPG`"!L/&L-&,QW:Y"T``FJ)1P**O>%03JX*W?0M%W(^HNP)_/R-_? MO=DMP8M0X#_)!``%N!P@$E+/9,_8GXC)]I71J&L@LN::W-0;J!@M'T14^R'Y MCW\_KU&O`&.O=:^'KUU32^`?WWA4-_(@/=]/W^2K!+B#_0W25#?R`C;S!C?R MZE*M_SVQP_X68@#9_VFXD+,^99"SB+^A\Z"_`+*_AM^8W^B_^K^:[AW/+\\" MHYT33.]>[W#O@N^W0XT#!<"PSK"S[\7OU^_I[_OO``W_'_]=4^D`.O]X5-42 M6/\0:O]\_Z#T@_T.TE35$M03`0;5$NI22R\]L6$N%F)W+Q`!#R\''0\O!`XW M#TD/6P^`;0^S#Y$/-Q^U#\M6Z(#X/]3&D+7E52-/R%<)V0P`%M.-4%5/%H18 M8G-/A4^73R)ST\A*=+=/!SH$U#47613WUV5550-RY3Q7XE877P#Q20-_XU>CM^#E]87_#@?T1?!(]H7FP!BP"5-&"`_#C@ MQ#C@>5L(#P"D`4AR((]?H5\/'R`A&,HV^Z#?/*;&X!NH`&L`:A]\'XX?H!^R M'XZN@X!;;^"TI&^2>6^+;^2E4K@>'X7K4?P_]*W[H/6E"$4C;Y)NDP9ODEPB MY9\]L0#[GE*R$:]ILKR5=K^^)8*S`"X%@K#7+^DOPV\ECS>/,3\0TXU7?V4_ M0?29];GP,!`B&P M6Z(P[EPK,7Y0[0.KQU`+K0@:1B`@"2K&89 MB`-H1=\!``WGM>\5YW"]X.YVW>]-V8L`6'I0541Z4#!Z4!QT@`=X@B4&K&`H M&-"S@2[*TCC]P,G1Z5$KL9G1+[,PL1@`"7$XL+.!@+PU(.8]M]/M"<5C$!_M MU9KQZ.R9_[_S=9E\4)GU<)D`+-CP%1C8\`30T&@'0!?0M(#^-_E&:6QE3D54 M_PI";&1G+B`S0H0P&2*_-+^R7WRSD$`@A#A`9;[0[%X^%OU?"4?00!1*)V^@ M(3\A6`%%;P(7```0S^H4X@(NST#/G6^I3S'?`$/?B=]'CP^!90UO'V=_DQ\@ MBW^W'YG3=U^)41H8#RH/`$:_3@_#@Y@>03^3OZ6_M[\`R;_;O^V_89L=(.4/ M9T0),O@#'Q4?M)5(X7H4KNM'T6$H@%DPX7J4$&$G?<,),@@S!@DRE,)_/P`- MH94^(J*K/SAB5C4_23U#!P)`>VDT`-D]0`_?(=\`31]?'W$?:=^9'^,?G]^Q MVQ4;'B`$Q-8;-"#1WX5!9*=AKX7LPE5I,A02QX4(W&9^!GX&L!I7B0_V1T:I M@013I'@%OBEC4'R`-RL(0P!`-2,B4(A64?.\F%65N)A5K)A5J"Q:7T.<')3@ MB^4#`-FL9O/5DL!%!T%-L.3G&5\B5L`L5Z"01OGO%V_SB#1HD'*`D!(<^`0( M("OY&SC^4?-/]47X6/@;9/\:;M-OL*[Z0/-N6&A[+_EAV?_K\TBRT$"]134A M*R.GP34MXTD$5K5*:3+4_D_8O75L!L@A;Q`U7I5P25^;!=BD"J,`:Y$`4W`, M/X24$((J/[,,/3\H%/YW70("@$Q`_@0JNM#?CN3VWE905K3O40`M03A"-D]( M3W@?PA^F>,>/`/$?ZX]J`0&?\Q_-%G^V-Y_@V8];G_V/?Y]A0XL`_/(*(,0* M(`DK!@`T`?5I+/0T>.P0)P`R)G#B5;4XD)P_0*NJI*&5XIA5W*&ETL1_V<;Y`DSDJI*D6^.:I;XCHZ5WX?\P3QOH MM(%.:Q$_G4A6L7>"`:H@=^R'XQ>F`(745K:6[ZCONN,`FJ9IOZ&GY>F1OP/_ M%?\G_1$=./]*_UGT'<1OK*9_^!*:K-+"\:RLXJ[Z1\]%R7`Y?^O__?\/`30` M:5R@XN_1+*!H)R$#H1S'<:+EP+P.H2&V(Z,C4'`>X!XO,"\\#V.3YW,+0$`5 M4(FB\G\%_'\%:29ZM@GRO*^:!ORD"NPSMPU`U02:0XBC\@J#`]`3C_<$SM(0 M,8]1CR_=#_S1\P_?[P#Q[RD?RP]-'^\/<1_)G]N=]#Q1'<$0'MAP87)K M%VEN9U!P(%1_6/]X?Q9\^*@&1]7^:]>J?:F@$+U_P?P](+O9_N#ZQ]#^?P#[ M$`4/'C2X(B,/-0]'#UD/`&L/?0^/#Z$/DQ^E'QV>3]8`;S\['Y,_;9^W/X,? MVS]]/T#_/Z$_(T^W'\D?VQUSC2T$KU7O\TJ0)2F_2%\V7PQO@U$H7%,R MR`V`,^`(6P\.43 M+'870:QG<#T*U^.C<-!!'F?*;S]`'P:+H+@>#:&L9_)O>[J9;RIZ0)1Z0(!Z M0&S"O]2T!PD`J-ZVT<'V06]_[S%<^-4.Q2$`9*]$1#;%G/UNX2.`1D!:1L-_ M`"L`GASB/$B@(@3?%M^J*-PH>OL,/R7U6=X%A&+53];U;"^&UIW3\_4%%)[? MR/8,SEKUR-/J<+LOX,TDM8+9+_DO$^4P>Q0_KD?A>H0_AM;R<70=X0K@!>V$ M!F($[X(I`B6Q(;>%+#8:@V8_-0`S[T7J8=9/3_$_?^@_B(2?`"M//4^ZGV%/ MWI\!P?2?!J<7DB1)2*#B%Z=/UBJO$.6!0*]W3XE'2/[`_1\/+W@A+PQ"J(/P M/T`H.2(A"6+5H_:S:-1DL%N/?B`(Y:7/4S@C" MSZ#/LL]4S];/-"\T4%\(`=WU@R^L=Y# M*0`!``````#]0.GR"``"``,H_UR/PO4H&T`:O^BT@4X;%.[S(_\`)``E`"8` M)Z\`*``IY_0"Z_`+:P`J)0`8]?`R`/T`D4`VQI;F4` M`/6#]?`SA0Q,;VYG'R!D87-H,0":`R($EV1A<@@%H$D%S0BM!#D&S0?`90C- M!RX##!E8!*[-"`$`-84,-X4,.1Z%##%P>&R9`Z(`;1B].6T82&%I&,T@56C-(%C-($?-(#3-(/4D MS2`.S2#Y`#,`5>4),-,),,`),*T),%6@"3"0"3"#"3!R"3!59`DP50DP1PDP M/`DPU2T),!T),`T),`0`#RH`K@+]=.GR(@`#``,H_UR/PO4H&T`:?^BT@4X; M%$#K\/'P`8 M!@T`:``%;.'Z!MS_#@\@#S(/Y?;_0`!"`+R%]#@?[S(``'@\````%0`````` M^/?_#@(```,``0#_!``I`/__D+R/]#@)!-S_$P_D]_\!_QX/0P]5#V0^+ M#YT/UQX`'?/P#O'P)P!_#P`&``D`$)X/\"T"V0\P#^KQ"@`<`!$%\`\8'P40 M`O7P,1]#'_\"`!H`#0`1`/T(Z_`D`"4`)@#W*``2]?`;`!\`]R``(2T0"P`3 M`-$'U0^.'^<&$P$0%P#?#``8`"/W\!0`?Q4`%@`9`"*O#QA_'^0?[!0+`(NT M`>KQ`NOP[_+W\`..__()`&?V]1`/WOTH_\E%&,`OFN%`SRCK7'DW`S0.]`GS M\SCO\0L(_-SS./[H\Q,`%@!2`&Q7W_,X;0%4Z_`7Y_35C.OP"(,(E(\$&`!_ MT@`$X/,XG.OP=4[K\";S\@``ZNOP]2'K\!JG`"3D\SC]"^_PY08``!L`_T(` M.$T5`/`'UP``@>OP'-<`P"I7%`!QD@`SZ_`==P#_[-[S.%T8``!56>OP).?T MMO\`#.OPA2#G],+_`)(!P@'J\0!)`&X`9@!O`'(`;0!A`'0`:0!O`&X````````````````` M```````````````````H``(!`@````T```#_____```````````````````` M````````````````````````````"````*@!````````!0!$`&\`8P!U`&T` M90!N`'0`4P!U`&T`;0!A`'(`>0!)`&X`9@!O`'(`;0!A`'0`:0!O`&X````` M`````````#@``@'_______________\````````````````````````````` M```````````````````/````Z`$````````!`$,`;P!M`'``3P!B`&H````` M```````````````````````````````````````````````````````````` M$@`"`/_______________P`````````````````````````````````````` M`````````!<```!J```````````````````````````````````````````` M````````````````````````````````````````````````````````____ M____________```````````````````````````````````````````````` M````````````````_O\```0``@```````````````````````0```."%G_+Y M3V@0JY$(`"LGL]DP````>`$``!$````!````D`````(```"8`````P```*P` M```$````N`````4```#,````!@```-@````'````Y`````@```#X````"0`` M``P!```2````&`$```H````T`0``#````$`!```-````3`$```X```!8`0`` M#P```&`!```0````:`$``!,```!P`0```@```.0$```>````"@```$AE861I M;F<@,0`@`!X````!`````&5A9!X````,````06QA;B!"86)I8V@`'@````$` M````;&%N'@````$`````;&%N'@````P```!!0E-014,R+F1O=``>````#``` M`$%L86X@0F%B:6-H`!X````"````,P!A;AX````3````36EC`!`)@$`%P`U"(%#2B``2T@< M`$]*`@!12@(`:TCD!`!4``,``0`B`50````)`$@`90!A`&0`:0!N`&<`(``S M````%P`#``8D`0HF`@M&`P`3I'@`%*10`$`F`@`7`#4(@4-*'`!+2!P`3TH" M`%%*`@!K2.0$`%0`!``!`"(!5`````D`2`!E`&$`9`!I`&X`9P`@`#0````7 M``0`!B0!"B8#"T8#`!.D>``4I%``0"8#`!<`-0B!0TH8`$M('`!/2@(`44H" M`&M(Y`0`5``%``$`(@%4````"0!(`&4`80!D`&D`;@!G`"``-0```!<`!0`& M)`$*)@0+1@,`$Z1X`!2D4`!`)@0`%P`U"(%#2A8`2T@<`$]*`@!12@(`:TCD M!`!0``8``0`B`5`````)`$@`90!A`&0`:0!N`&<`(``V````%P`&``8D`0HF M!0M&`P`3I'@`%*10`$`F!0`3`#4(@4M('`!/2@(`44H"`&M(Y`0`4``'``$` M(@%0````"0!(`&4`80!D`&D`;@!G`"``-P```!<`!P`&)`$*)@8+1@,`$Z10 M`!2D/`!`)@8`$P`U"(%+2!P`3TH"`%%*`@!K2.0$`%``"``!`"(!4`````D` M2`!E`&$`9`!I`&X`9P`@`#@````7``@`!B0!"B8'"T8#`!.D4``4I#P`0"8' M`!,`-0B!2T@<`$]*`@!12@(`:TCD!`!0``D``0`B`5`````)`$@`90!A`&0` M:0!N`&<`(``Y````%P`)``8D`0HF"`M&`P`3I%``%*0\`$`F"``3`#4(@4M( M'`!/2@(`44H"`&M(Y`0`/`!!0/+_H0`\````%@!$`&4`9@!A`'4`;`!T`"`` M4`!A`'(`80!G`'(`80!P`&@`(`!&`&\`;@!T`````````````````#8`)T#R M__$`-@```!$`0P!O`&T`;0!E`&X`=``@`%(`90!F`&4`<@!E`&X`8P!E```` M!`!#2A``1@`>``$``@%&````#`!#`&\`;0!M`&4`;@!T`"``5`!E`'@`=``` M`!P`$``/A+L`$81%_Q)D)/\``!2D>``-Q@4``;L`````0@#^#R$!$@%"```` M#P!"`&P`;P!C`&L`(`!1`'4`;P!T`&$`=`!I`&\`;@````T`$0`%)`$.A-`" M#X30`@`#`#8(@0`R`$)``0`B`3(````)`$(`;P!D`'D`(`!4`&4`>`!T```` M`@`2``P`3TH``%%*``!K2.0$0@#^#Q$!$@%"````%0!"`&P`;P!C`&L`(`!1 M`'4`;P!T`&$`=`!I`&\`;@`@`$8`:0!R`',`=`````8`$P`3I'@```!``/X/ M$0$B`4`````4`$(`;`!O`&,`:P`@`%$`=0!O`'0`80!T`&D`;P!N`"``3`!A M`',`=`````8`%``4I/`````X`$,`(0%2`3@````0`$(`;P!D`'D`(`!4`&4` M>`!T`"``20!N`&0`90!N`'0````&`!4`#X1H`0``-`#^#R$!8@$T````#@!" M`&\`9`!Y`"``5`!E`'@`=``@`$L`90!E`'`````%`!8`!B0!````,@`B``$` M(@$R````!P!#`&$`<`!T`&D`;P!N````"@`7`!.D>``4I*``!P`V"(%#2A(` M`%(`_@\!``(`4@````T`0P!H`&$`<`!T`&4`<@`@`$P`80!B`&4`;`````P` M&``#)`$&)`$3I&@!&@`U"($^*@%#2A@`2T@<`$]*`@!12@(`:TCD!%X`_@\! M`"(!7@```!``0P!H`&$`<`!T`&4`<@`@`%,`=0!B`'0`:0!T`&P`90```!,` M&0`#)`$%)`$&)`$3I&@!%*1H`0`7`#8(@4-*'`!+2!P`3TH"`%%*`@!K2.0$ M`%0`_@\!`)(!5`````T`0P!H`&$`<`!T`&4`<@`@`%0`:0!T`&P`90````\` M&@`#)`$%)`$&)`$3I%@"`!<`-0B!0TH@`$M('`!/2@(`44H"`&M(Y`0`*`!, M`"$!L@$H````!`!$`&$`=`!E````"0`;``,D`1.DX`$``P`U"($`2`#^#P$` MP@%(````#@!$`&\`8P!U`&T`90!N`'0`(`!,`&$`8@!E`&P````-`!P`!B0! M$Z3P`!2D:`$`"P`U"(%#2B0`2T@<```D`%A`\O_1`20````(`$4`;0!P`&@` M80!S`&D```- MQ@4``;L```0`0TH2`"X`($`!``("+@````8`1@!O`&\`=`!E`'(````0`"`` M!20!#<8(``+@$,`A`0(``"H`_@\!`A("*@````L`1@!O`&\`=`!E`'(`(`!% M`'8`90!N`````@`A````-@#^#P$"(@(V````#`!&`&\`;P!T`&4`<@`@`$8` M:0!R`',`=`````P`(@`#)`$-Q@0!P"$````T`/X/`0(R`C0````*`$8`;P!O M`'0`90!R`"``3P!D`&0````-`",``R0"#<8%``$```(```!(`/X/`0!"`D@` M```-`$8`;P!O`'0`;@!O`'0`90`@`$(`80!S`&4````8`"0`#X2[`!&$1?\2 M9"3_```-Q@4``;L```0`0TH2`#@`)D#R_P$`.````!(`1@!O`&\`=`!N`&\` M=`!E`"``4@!E`&8`90!R`&4`;@!C`&4````#`$@J`0`R`!T`00)B`C(````- M`$8`;P!O`'0`;@!O`'0`90`@`%0`90!X`'0````&`"8`%*1X````+@`?``$` M<@(N````!@!(`&4`80!D`&4`<@```!``)P`%)`$-Q@@``N`0P"$!`@``.`#^ M#P$`@@(X````"P!(`&4`80!D`&4`<@`@`$(`80!S`&4````0`"@`!20!#<8( M``+@$,`A`0(``"H`_@]Q`I("*@````L`2`!E`&$`9`!E`'(`(`!%`'8`90!N M`````@`I````-@#^#W$"H@(V````#`!(`&4`80!D`&4`<@`@`$8`:0!R`',` M=`````P`*@`#)`$-Q@0!P"$````T`/X/<0*R`C0````*`$@`90!A`&0`90!R M`"``3P!D`&0````-`"L``R0"#<8%``$```(```!0`/X/`0`B`5`````,`$@` M90!A`&0`:0!N`&<`(`!"`&$``\*```R``P``0#R`C(` M```'`$D`;@!D`&4`>``@`#,````2`"\`#X2@!1&$,/T-Q@4``7@/"@``,@`- M``$``@,R````!P!)`&X`9`!E`'@`(``T````$@`P``^$"`<1A##]#<8%``%X M#PH``#(`#@`!`!(#,@````<`20!N`&0`90!X`"``-0```!(`,0`/A'`($80P M_0W&!0`!>`\*```R``\``0`B`S(````'`$D`;@!D`&4`>``@`#8````2`#(` M#X0(!Q&$,/T-Q@4``7@/"@``,@`0``$`,@,R````!P!)`&X`9`!E`'@`(``W M````$@`S``^$<`@1A##]#<8%``%X#PH``#(`$0`!`$(#,@````<`20!N`&0` M90!X`"``.````!(`-``/A-@)$80P_0W&!0`!>`\*```R`!(``0!2`S(````' M`$D`;@!D`&4`>``@`#D````2`#4`#X1`"Q&$,/T-Q@4``7@/"@``.`#^#P$` M8@,X````"@!)`&X`9`!E`'@`(`!"`&$```7 M`#8(@4-*(`!+2!P`3TH"`%%*`@!K2.0$`#``_@_!`H(%,`````H`4`!A`'(` M=``@`%0`:0!T`&P`90````D`60`#)`$3I%@"````)@#^#R$!<@$F````!P!0 M`&D`8P!T`'4`<@!E````!0!:``8D`0```#X`_@_!`K(%/@````\`4P!E`&,` M=`!I`&\`;@`@`$@`90!A`&0`:0!N`&<````*`%L`$Z1X`!2DH``$`$-*'``X M`/X/P0(B`3@````-`%,`90!C`'0`:0!O`&X`(`!,`&$`8@!E`&P````,`%P` M`R0!!20!%*1H`0``-@!*`.$%(@$V````"`!3`'4`8@!T`&D`=`!L`&4````* M`%T`$Z0``!2D\``*`#4(@38(@4-*'``N`#X`P0+B!2X````%`%0`:0!T`&P` M90````T`7@`#)`$3I&@!%*2@```$`$-**`!6`/X/`0`B`58````.`%,`=0!B M`'0`:0!T`&P`90`@`$,`;P!V`&4`<@```!``7P`#)`$&)`$3I/``%*2@`!<` M-@B!0THD`$M('`!/2@(`44H"`&M(Y`0`+@#^3_+_`08N````"P!3`'4`<`!E M`'(```-Q@4``<`A2@\`-0B!3TH"`%%*`@!K2.0$`"H`%``!`&(&*@````4`5`!/ M`$,`(``R````#@!F``^$:`$-Q@4``<`A2@``*@`5``$`<@8J````!0!4`$\` M0P`@`#,````.`&<`#X30`@W&!0`!P"%*```N`!8``0""!BX````%`%0`3P!# M`"``-`````X`:``/A#@$#<8%``'`(4H#`#8(@0`J`!<``0"2!BH````%`%0` M3P!#`"``-0````X`:0`/A*`%#<8%``'`(4H``"H`&``!`*(&*@````4`5`!/ M`$,`(``V````#@!J``^$"`<-Q@4``<`A2@``*@`9``$`L@8J````!0!4`$\` M0P`@`#<````.`&L`#X1P"`W&!0`!P"%*```J`!H``0#"!BH````%`%0`3P!# M`"``.`````X`;``/A-@)#<8%``'`(4H``"H`&P`!`-(&*@````4`5`!/`$,` M(``Y````#@!M``^$0`L-Q@4``<`A2@``+`#^#P$`X@8L````"`!4`$\`0P`@ M`$(`80!S`&4````*`&X`#<8%``'`(4H`````+`#^#R$!`@0!L`&4`,0````(`<``,`$]*!`!12@0`:TCD!``````W````+@``#`````#_ M____````````````````````````````````````````````````"P```!@` M```8````&````!L`````!```-P0```,`````!```-P0```0`````!```-P0` M``4`````````&0```!L````W````$SJ4_Y6```````<````+````$@```!0` M```;````$R$5`!,A%/\5@``````=````-0```#@````'``<``@``````'0`` M`#4````X````!P`'``(`__\"````"P!!`&P`80!N`"``0@!A`&(`:0!C`&@` M(P!#`#H`7`!D`&\`8P!<`&8`:0!L`&4`;@!E`'0`7`!$`&D`<@!E`&,`=`!I M`&\`;@!S`%P`0@!L`&0`9P`T`"X`9`!O`&,``@#^__________\/_P__#_\/ M_P__#_\/_P__#P$`9&/^)*P.0"\!``(``P`$``4`!@`'``@`"0`````````` M```````````````````````````````!`"H``0```````0`````````````` M`````````!````^$L`$1A%#^%<8%``&P`08!`````0```````0,````````` M`````````````!````^$0`(1A,#]%<8%``%``@8#````+@`!``$```````$# M!0`````````````````````0```/A-`"$80P_17&!0`!T`(&!0```"X``0`N M``(``0```````0,%!P```````````````````!````^$8`,1A*#\%<8%``%@ M`P8'````+@`!`"X``@`N``,``0```````0,%!PD``````````````````!`` M``^$\`,1A!#\%<8%``'P`P8)````+@`!`"X``@`N``,`+@`$``$```````$# M!0<)"P`````````````````0```/A(`$$82`^Q7&!0`!@`0&"P```"X``0`N M``(`+@`#`"X`!``N``4``0```````0,%!PD+#0```````````````!````^$ M$`41A/#Z%<8%``$0!08-````+@`!`"X``@`N``,`+@`$`"X`!0`N``8``0`` M`````0,%!PD+#0\``````````````!````^$H`41A&#Z%<8%``&@!08/```` M+@`!`"X``@`N``,`+@`$`"X`!0`N``8`+@`'``$```````$#!0<)"PT/$0`` M```````````0```/A#`&$830^17&!0`!,`8&$0```"X``0`N``(`+@`#`"X` M!``N``4`+@`&`"X`!P`N``@``P```/[___\`````$%7=#`$```#^____```` M`'!5W0P!````9&/^)````````````````/____\<5=T,8`!V``$````70``` M````````````````(`$```\(```/A(@"$83@_D-*%`!/2@$`44H!`&\H``$` MM_#_____?%7=#*#___\!````%T```````````````````&@!```/"```#X0X M!!&$F/Y#2A``3TH!`%%*`0!O*``!`+?P________`@````````#_0`$0`0`` M````'````#PMW0P!``$```````$```````````````(0`````````#<```#@ M`@`(`$````4```!'%I`!```"`@8#!00%`@,$AP(``````````````````)\` M````````5`!I`&T`90!S`"``3@!E`'<`(`!2`&\`;0!A`&X````U%I`!`@`% M!0$"`0<&`@4'`````````!```````````````(``````4P!Y`&T`8@!O`&P` M```S)I`!```""P8$`@("`@($AP(``````````````````)\`````````00!R M`&D`80!L````/S60`0```@<#"0("!0($!(<"``````````````````"?```` M`````$,`;P!U`'(`:0!E`'(`(`!.`&4`=P```$4FD`$```(+!0("`@("`@0# M`````````````````````0````````!#`&4`;@!T`'4`<@!Y`"``1P!O`'0` M:`!I`&,````B``0`P0B(&```T`(``&@!`````.5:*:;Q6BFF``````,`!``` M``0````8`````0`!````!`"#$`$```````````````$``0````$````````` M)`,````$```````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````I0;`![0`M`"``'(P```````````````````=```````````````````` M```````````````````````````````````````````````````````````` M``````````(``````/__$@``````(0!#`#H`7`!-`%,`3P!F`&8`:0!C`&4` M7`!4`&4`;0!P`&P`80!T`&4`; Fri, 11 Sep 1998 18:06:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA28592; Fri, 11 Sep 1998 18:00:32 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 18:00:32 -0400 (EDT) Resent-Message-Id: <199809112200.SAA28592@www19.w3.org> Message-Id: <3.0.5.32.19980911150016.0080db30@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 11 Sep 1998 15:00:16 PDT To: w3c-dist-auth@w3.org From: Jim Davis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: three clarification questions on the If header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2035 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list For the following questions, assume a collection C contains resource R, and suppose C is locked at Depth 0. Assume that resource S does not exist. 1. Is it true that the lock on C has no effect on doing a PUT to R? (The protocol in 7.10.2 is clear that it affects ability to add or remove members, but says nothing about changing existing ones.) 2. In 8.4.1, which says "If a method, due to the presence of a Depth or Destination header, is applied to multiple resources then the No-tag-list production MUST be applied to each resource the method is applied to", what is the significance of "due to the presence of a Depth or Destination header"? Can a method be applied to multiple resources in any other way? It seems to me that it can. Consider a PUT to S (which does not yet exist). Certainly the PUT applies to S. Does it also "apply" to C? It seems to me that it does, or else why would the client have to pass the state token for the lock on C? Will someone please clarify 8.4.1? 3. In the case where the client has a lock on C, but no lock on R, and does not have the etag for R, is it possible for a client to use an _untagged_ production in the If header to pass the lock token on the C? If so, I don't see how to implement it. The production matches the state of C, but it will not match the state of R, so it will fail, and hence the PUT will fail. If this is right, it seems to me that the protocol document should say that a client SHOULD use tagged productions when the set of affected resources is known in advance and is small (as in this case) and it should explain the potential problem with using the no tagged production. Otherwise, clients will fail and programmers will be puzzled. If this is wrong, then a clarification in 8.4 is in order. From w3c-dist-auth-request@w3.org Fri Sep 11 18:33:19 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA00037 for ; Fri, 11 Sep 1998 18:33:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA28846; Fri, 11 Sep 1998 18:28:20 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 18:28:20 -0400 (EDT) Resent-Message-Id: <199809112228.SAA28846@www19.w3.org> Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792599@RED-MSG-59> From: Yaron Goland To: "'Babich, Alan'" , "'webdav'" Cc: "Fay, Chuck" , "Whelan, Dan" , "Green, Jim" , "Palmer, Ann" , "Johnson, Andrew" , "Tucker, Michael" , "Fink, Evangeline" Date: Fri, 11 Sep 1998 15:28:34 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Subject: RE: Versioning: The Next Versioning and Variants meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2036 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Is this an author's meeting or an open meeting? Yaron > -----Original Message----- > From: Babich, Alan [mailto:ABabich@filenet.com] > Sent: Friday, September 11, 1998 12:11 PM > To: 'webdav' > Cc: Fay, Chuck; Whelan, Dan; Green, Jim; Palmer, Ann; Johnson, Andrew; > Tucker, Michael; Fink, Evangeline > Subject: Versioning: The Next Versioning and Variants meeting > > > The next V&V meeting will be hosted by FileNET in > Costa Mesa California, on October 1 and 2 from > 9 am to 5 pm Pacific time. > > If you plan to attend, please e-mail me ASAP so I > can order the catered lunches. > There is a sandwich place called the Business Park Cafe > only a couple of minutes walk away. So you will have > the option of going there for lunch instead of eating > the catered lunch (unless we decide to work through > lunch). > > The following file has directions from three airports, > hotel information, and local maps. The closest airport > is John Wayne Orange County airport. Use that airport > if you can get a flight. The second closest (and > second choice) is Long Beach airport. Since the following > file has no directions from Long Beach airport, > get in touch with me if you want to use the Long > Beach airport. LAX and Ontario airport are a ways away. > > <> > The meeting will be held in "FileNET building 4" of the > Harbor Gateway business complex on the second floor > in room 2349: > > <> > Enter the lobby, and take the door on the left. > Both doors have a badge reader. I will prop the left > door open until 9 am on Monday and Tuesday. If you're > late, use the phone in the lobby, dial 5883, and ask > our sectary Nelsy to please come down and let you in > to the WEBDAV Versioning and Variants meeting. > There is no receptionist in building 4. We're not going > to issue badges. > > Enter the door on the left, turn left, go up the stairs, > go about half way down the corridor, and it's on > your right. It's a large room. > > The room has power for laptops, whiteboards, > an overhead projector, and an LCD screen to project > what's on your laptop screen using the overhead projector. > So, it will be possible to presentations without > printing them out. We can also have the secretaries > print things out and make copies. > > I am assuming Jim Whitehead will supply the agenda. > > If you have any questions, get in touch with me. > > Alan Babich > ABabich@filenet.com > 714-966-3403 > > > From w3c-dist-auth-request@w3.org Fri Sep 11 19:58:31 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01487 for ; Fri, 11 Sep 1998 19:58:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA00672; Fri, 11 Sep 1998 19:53:44 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 19:53:44 -0400 (EDT) Resent-Message-Id: <199809112353.TAA00672@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: Yaron Goland , "'Babich, Alan'" , "'webdav'" Cc: "Fay, Chuck" , "Whelan, Dan" , "Green, Jim" , "Palmer, Ann" , "Johnson, Andrew" , "Tucker, Michael" , "Fink, Evangeline" Date: Fri, 11 Sep 1998 16:51:22 -0700 Message-ID: <001001bddddf$14506320$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D08792599@RED-MSG-59> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: RE: Versioning: The Next Versioning and Variants meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2037 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a meeting of the Versioning and Variant Authoring Design Team and is closed to people who are not members of the Design Team, or invited guests with specific expertise. The intent of holding Design Team meetings like this is to gather a relatively small group of participants who have made long-term commitments to actively work on the protocol. This is in contrast to the open WebDAV meetings where there is typically a much larger set of attendees, and no long-term commitment to work on specific problems (though familiarity with drafts under discussion is expected). The advantage of having a Design Team is that various design alternatives can be expressed and evaluated more rapidly than in a large group setting. Furthermore, there is hope that a smaller group will reduce the problems associated with "design by committee", including lack of conceptual integrity in the design. The major drawback to a Design Team approach is that a small group of people has a disproportionately large impact on the design, and is more susceptible to making poor design decisions than a larger group. Since the work of the design team is performed in closed meetings, the development of the protocol is not as transparent as if it had totally been developed on a mailing list. As a result, the decisions of a Design Team are never final, but are subject to approval by the mailing list. In IETF working groups, the mailing list is always the final arbiter of consensus on any topic or proposal. At present, members of the Versioning and Variant Authoring Design Team are: John Stracke Chris Kaler Bradley Sergeant Alan Babich Sam Ruby Bruce Cragun David Durand Jim Whitehead Sridhar Iyengar These individuals replied to my public call for volunteers, posted on July 6, 1998: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0008.html. If there are individuals on the list who didn't see this earlier call for volunteers, and who are committed to working on the versioning and variant authoring protocol (as in, coming to all design team meetings, writing text for the protocol, and reading and commenting on existing drafts), then please let me know. There is, as yet, no official output of the Versioning and Variant Authoring Design Team. The team is currently working on two documents, a protocol draft, and an extended goals draft (listing versioning goals beyond those listed in RFC 2291). At present, the only versioning drafts are: draft-whitehead-webdav-versioning-00 draft-kaler-webdav-versioning-00 Both of these drafts are available off the WebDAV home page, at: http://www.ics.uci.edu/pub/ietf/webdav/ The Design Team welcomes any comments or criticisms you have on these proposals. Furthermore, I have instructed the design team to hold as much of their discussions on the WebDAV mailing list, in order to increase the ability for non-Design Team members to participate. Alan Babich's message was in this spirit, as was his call for making the meeting notes from the last meeting available. I fully support this. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Yaron Goland > Sent: Friday, September 11, 1998 3:29 PM > To: 'Babich, Alan'; 'webdav' > Cc: Fay, Chuck; Whelan, Dan; Green, Jim; Palmer, Ann; Johnson, Andrew; > Tucker, Michael; Fink, Evangeline > Subject: RE: Versioning: The Next Versioning and Variants meeting > > > Is this an author's meeting or an open meeting? > Yaron > > > -----Original Message----- > > From: Babich, Alan [mailto:ABabich@filenet.com] > > Sent: Friday, September 11, 1998 12:11 PM > > To: 'webdav' > > Cc: Fay, Chuck; Whelan, Dan; Green, Jim; Palmer, Ann; Johnson, Andrew; > > Tucker, Michael; Fink, Evangeline > > Subject: Versioning: The Next Versioning and Variants meeting > > > > > > The next V&V meeting will be hosted by FileNET in > > Costa Mesa California, on October 1 and 2 from > > 9 am to 5 pm Pacific time. > > > > If you plan to attend, please e-mail me ASAP so I > > can order the catered lunches. > > There is a sandwich place called the Business Park Cafe > > only a couple of minutes walk away. So you will have > > the option of going there for lunch instead of eating > > the catered lunch (unless we decide to work through > > lunch). *snip* From w3c-dist-auth-request@w3.org Fri Sep 11 20:10:22 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01571 for ; Fri, 11 Sep 1998 20:10:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA00885; Fri, 11 Sep 1998 20:05:30 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 20:05:30 -0400 (EDT) Resent-Message-Id: <199809120005.UAA00885@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: Howard Modell , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu Date: Fri, 11 Sep 1998 17:01:57 -0700 Message-ID: <001201bddde0$8e923040$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199809102028.NAA22829@warlok.ds.boeing.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2038 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Howard Modell writes: > So if I have a personal webspace, ... > > http://warlok.ds.boeing.com/~howie/ > > .. and I choose I create a "WebDAV collection" in my space, .. > > http://warlok.ds.boeing.com/~howie/a/b/c > > .. am I in violation of the rules above since the URL of my personal space > is NOT of and by itself the URL of a collection? Well, actually, the URL of http://warlok.ds.boeing.com/~howie/ is a correct URL for a collection, since it has a trailing slash. But, what you're probably asking is whether the resource identified by http://warlok.ds.boeing.com/~howie/ needs to be of type WebDAV collection. The implication of the requirement in section 4.3 (no namespace gaps) combined with the requirement in section 4.1 that namespaces must behave as DAV collections even if they weren't created with WebDAV, is that yes, the resource identified by http://warlok.ds.boeing.com/~howie/ needs to be of type WebDAV collection if http://warlok.ds.boeing.com/~howie/a/b/c is WebDAV-compliant. - Jim From w3c-dist-auth-request@w3.org Fri Sep 11 20:33:39 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01722 for ; Fri, 11 Sep 1998 20:33:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01447; Fri, 11 Sep 1998 20:28:53 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 20:28:53 -0400 (EDT) Resent-Message-Id: <199809120028.UAA01447@www19.w3.org> Message-Id: <3.0.5.32.19980911202807.03013100@localhost> X-Sender: frystyk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 11 Sep 1998 20:28:07 -0400 To: From: Henrik Frystyk Nielsen In-Reply-To: <001001bddddf$14506320$d115c380@galileo.ics.uci.edu> References: <3FF8121C9B6DD111812100805F31FC0D08792599@RED-MSG-59> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Solving the lost update problem using HTTP/1.1 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2039 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list If you are interested then you may want to have a look at my Web Commander [1] which is a Win32 app based on libwww [2]. I have just released a new version that shows how to avoid the lost update problem when saving documents based on HTTP/1.1 PUT with etags, HEAD, and persistent cache. It's available in both binary and source form. Hope this helps, Henrik [1] http://www.w3.org/WinCom/ [2] http://www.w3.org/Library/ -- Henrik Frystyk Nielsen, World Wide Web Consortium http://www.w3.org/People/Frystyk From w3c-dist-auth-request@w3.org Fri Sep 11 21:31:20 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA01992 for ; Fri, 11 Sep 1998 21:31:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA02157; Fri, 11 Sep 1998 21:26:28 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 21:26:28 -0400 (EDT) Resent-Message-Id: <199809120126.VAA02157@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: Henrik Frystyk Nielsen , WEBDAV WG Date: Fri, 11 Sep 1998 18:17:24 -0700 Message-ID: <000001bdddeb$19e47ea0$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3.0.5.32.19980911202807.03013100@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: RE: Solving the lost update problem using HTTP/1.1 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2040 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hi Henrik, So, when are you going to make a WebDAV-enabled version of Web Commander? - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Henrik Frystyk Nielsen > Sent: Friday, September 11, 1998 5:28 PM > To: w3c-dist-auth@w3.org > Subject: Solving the lost update problem using HTTP/1.1 > > > > If you are interested then you may want to have a look at my Web Commander > [1] which is a Win32 app based on libwww [2]. > > I have just released a new version that shows how to avoid the lost update > problem when saving documents based on HTTP/1.1 PUT with etags, HEAD, and > persistent cache. > > It's available in both binary and source form. > > Hope this helps, > > Henrik > > [1] http://www.w3.org/WinCom/ > [2] http://www.w3.org/Library/ > > -- > Henrik Frystyk Nielsen, > World Wide Web Consortium > http://www.w3.org/People/Frystyk > From w3c-dist-auth-request@w3.org Fri Sep 11 22:00:42 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA02071 for ; Fri, 11 Sep 1998 22:00:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA02267; Fri, 11 Sep 1998 21:52:10 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 21:52:10 -0400 (EDT) Resent-Message-Id: <199809120152.VAA02267@www19.w3.org> Message-Id: <3.0.5.32.19980911215222.00b22380@localhost> X-Sender: frystyk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 11 Sep 1998 21:52:22 -0400 To: ejw@ics.uci.edu, WEBDAV WG From: Henrik Frystyk Nielsen In-Reply-To: <000001bdddeb$19e47ea0$d115c380@galileo.ics.uci.edu> References: <3.0.5.32.19980911202807.03013100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Solving the lost update problem using HTTP/1.1 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2041 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 18:17 11/09/1998 -0700, Jim Whitehead wrote: >So, when are you going to make a WebDAV-enabled version of Web Commander? I have heard that grad students have plenty of spare time so maybe that's what I should head for ;) Seriously, I think it is a matter of taking one step at a time and see how it turns out. For example, handling collections is of high interest as well as handling metadata about a resource. Henrik -- Henrik Frystyk Nielsen, World Wide Web Consortium http://www.w3.org/People/Frystyk From w3c-dist-auth-request@w3.org Fri Sep 11 22:26:25 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA02871 for ; Fri, 11 Sep 1998 22:26:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA02385; Fri, 11 Sep 1998 22:19:10 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 22:19:10 -0400 (EDT) Resent-Message-Id: <199809120219.WAA02385@www19.w3.org> Message-ID: <3FF8121C9B6DD111812100805F31FC0D087925AA@RED-MSG-59> From: Yaron Goland To: "'ejw@ics.uci.edu'" , Howard Modell , w3c-dist-auth@w3.org Date: Fri, 11 Sep 1998 19:19:29 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2042 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Actually no, http://foo/bar does NOT have to be a collection just because http://foo/bar/blah is a collection. The requirement reads as: IF http://foo/bar is DAV compliant and IF http://foo/bar/blah/ exists and is DAV compliant THEN http://foo/bar must be a collection. However, IF http://foo/bar is NOT DAV compliant and IF http://foo/bar/blah/ exists and is DAV compliant THEN there is no requirement on http://foo/bar. The reason the requirement runs this way is that often what appears to be a single namespace is in fact a whole mishmash of mapped namespaces owned by separate servers. So even though http://foo/bar/blah may be on a DAV compliant server there is no guarantee that http://foo/bar is on a DAV compliant server. Thus our requirements for namespace consistency are predicated on the parent being DAV compliant. Yaron > -----Original Message----- > From: Jim Whitehead [mailto:ejw@ics.uci.edu] > Sent: Friday, September 11, 1998 5:02 PM > To: Howard Modell; w3c-dist-auth@w3.org > Subject: RE: Namespace consistency > > > Howard Modell writes: > > So if I have a personal webspace, ... > > > > http://warlok.ds.boeing.com/~howie/ > > > > .. and I choose I create a "WebDAV collection" in my space, .. > > > > http://warlok.ds.boeing.com/~howie/a/b/c > > > > .. am I in violation of the rules above since the URL of my > personal space > > is NOT of and by itself the URL of a collection? > > Well, actually, the URL of > http://warlok.ds.boeing.com/~howie/ is a > correct > URL for a > collection, since it has a trailing slash. But, what you're > probably asking is whether the resource identified by > http://warlok.ds.boeing.com/~howie/ needs to be of type > WebDAV collection. > The implication of the requirement in section 4.3 (no namespace gaps) > combined with the requirement in section 4.1 that namespaces > must behave as > DAV collections even if they weren't created with WebDAV, is > that yes, the > resource identified by http://warlok.ds.boeing.com/~howie/ > needs to be of > type WebDAV collection if http://warlok.ds.boeing.com/~howie/a/b/c is > WebDAV-compliant. > > - Jim > From w3c-dist-auth-request@w3.org Fri Sep 11 22:31:22 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA03179 for ; Fri, 11 Sep 1998 22:31:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA02432; Fri, 11 Sep 1998 22:26:36 -0400 (EDT) Resent-Date: Fri, 11 Sep 1998 22:26:36 -0400 (EDT) Resent-Message-Id: <199809120226.WAA02432@www19.w3.org> Message-ID: <3FF8121C9B6DD111812100805F31FC0D087925AB@RED-MSG-59> From: Yaron Goland To: "'Jim Davis'" , w3c-dist-auth@w3.org Date: Fri, 11 Sep 1998 19:26:55 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Subject: RE: three clarification questions on the If header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2043 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > -----Original Message----- > From: Jim Davis [mailto:jdavis@parc.xerox.com] > Sent: Friday, September 11, 1998 3:00 PM > To: w3c-dist-auth@w3.org > Subject: three clarification questions on the If header. > > > For the following questions, assume a collection C contains > resource R, and > suppose C is locked at Depth 0. Assume that resource S does > not exist. > > 1. Is it true that the lock on C has no effect on doing a PUT > to R? (The > protocol in 7.10.2 is clear that it affects ability to add or remove > members, but says nothing about changing existing ones.) > Yes, it is true. > 2. In 8.4.1, which says "If a method, due to the presence of > a Depth or > Destination header, is applied to multiple resources then the > No-tag-list > production MUST be applied to each resource the method is > applied to", what > is the significance of "due to the presence of a Depth or > Destination header"? > > Can a method be applied to multiple resources in any other > way? It seems > to me that it can. Consider a PUT to S (which does not yet exist). > Certainly the PUT applies to S. Does it also "apply" to C? > It seems to me > that it does, or else why would the client have to pass the > state token for > the lock on C? > > Will someone please clarify 8.4.1? > To apply a method is a very specific term in HTTP and means that the method directly effects the state of one or more resources. The lock token submitted on a request for S does NOT effect the state of C. Rather it allows S's state to be effected as a consequence of confirming knowledge of C's state. On the other hand, issuing a DELETE on C most certainly effect's S's state since the method can not succeed unless S gets nuked. Thus I believe the section is absolutely crystalline clear. > 3. In the case where the client has a lock on C, but no lock > on R, and > does not have the etag for R, is it possible for a client to use an > _untagged_ production in the If header to pass the lock token > on the C? > > If so, I don't see how to implement it. The production > matches the state > of C, but it will not match the state of R, so it will fail, > and hence the > PUT will fail. > > If this is right, it seems to me that the protocol document > should say that > a client SHOULD use tagged productions when the set of > affected resources > is known in advance and is small (as in this case) and it > should explain > the potential problem with using the no tagged production. Otherwise, > clients will fail and programmers will be puzzled. > > If this is wrong, then a clarification in 8.4 is in order. > This example is too vague to properly respond to. You need to specify what method you are executing, what sort of lock you have on C, what its depth is, etc. and why you need to refer to C's lock in order to execute your method on R. From w3c-dist-auth-request@w3.org Sat Sep 12 02:13:42 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA11595 for ; Sat, 12 Sep 1998 02:13:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA03264; Sat, 12 Sep 1998 02:07:43 -0400 (EDT) Resent-Date: Sat, 12 Sep 1998 02:07:43 -0400 (EDT) Resent-Message-Id: <199809120607.CAA03264@www19.w3.org> From: "Larry Masinter" To: "Yaron Goland" , , "Howard Modell" , Date: Fri, 11 Sep 1998 23:07:33 PDT Message-ID: <000301bdde13$a1d3d040$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D087925AA@RED-MSG-59> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2044 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Yaron and Jim seem to disagree on the nature of the requirement, so it sounds like this needs to get worked out. > Actually no, http://foo/bar does NOT have to be a collection just because > http://foo/bar/blah is a collection. The requirement reads as: > > IF http://foo/bar is DAV compliant and > IF http://foo/bar/blah/ exists and is DAV compliant > THEN http://foo/bar must be a collection. Must the intermediaries also be DAV compliant? Well, for one level it doesn't matter, but suppose: 1) http://foo/bar is DAV compliant 2) http://foo/bar/a/b/c/blah/ exists and is DAV compliant 3) then must http://foo/bar/a/b be a (DAV-compliant) collection? This would leave out the possibility that http://foo/bar/a might be some kind of mapping? Or is it that "exists" needs elaboration to except that case where it's a redirection? From w3c-dist-auth-request@w3.org Sat Sep 12 14:20:37 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA14501 for ; Sat, 12 Sep 1998 14:20:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05874; Sat, 12 Sep 1998 14:15:33 -0400 (EDT) Resent-Date: Sat, 12 Sep 1998 14:15:33 -0400 (EDT) Resent-Message-Id: <199809121815.OAA05874@www19.w3.org> Message-Id: <3.0.5.32.19980912111440.007d0a60@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 12 Sep 1998 11:14:40 PDT To: w3c-dist-auth@w3.org From: Jim Davis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: etag in untagged production of If header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2045 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The no-tagged production of an If header is to be applied to every resource to which the method is applied. This production can contain both state tokens and etags. I understand why the no-tagged production is useful when it contains a state token. Many distinct resources can be in the same state. I do not understand why this production can contain an etag. Unlike a state token, an etag can match at most one resource, and the only way a client could have an etag in the first place is by already knowing the resource. So it would always be possible for the client to use the tagged production. Can someone provide an example of when it would ever make sense to include an etag in such a production? The only reason I can think of is to allow the client to transmit slightly fewer bytes on the wire. I am not calling for any changes in the protocol or documentation, but would like to know whether I missed something. Jim ------------------------------------ http://www.parc.xerox.com/jdavis/ 650-812-4301 From w3c-dist-auth-request@w3.org Sat Sep 12 15:11:28 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA14751 for ; Sat, 12 Sep 1998 15:11:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06189; Sat, 12 Sep 1998 15:06:46 -0400 (EDT) Resent-Date: Sat, 12 Sep 1998 15:06:46 -0400 (EDT) Resent-Message-Id: <199809121906.PAA06189@www19.w3.org> Message-Id: <3.0.5.32.19980912115330.007f3af0@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 12 Sep 1998 11:53:30 PDT To: Yaron Goland , w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D087925AB@RED-MSG-59> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: three clarification questions on the If header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2047 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 07:26 PM 9/11/98 PDT, Yaron Goland wrote: >This example is too vague to properly respond to. You need to specify what >method you are executing, what sort of lock you have on C, what its depth >is, etc. and why you need to refer to C's lock in order to execute your >method on R. You're right, the question was too vague. Here is another try. A client has an exclusive write lock on collection C at depth 0. The client wishes to create a new resource C/R by doing a PUT. The state token for C is needed because C/R did not exist previously (7.10.2) Suppose the client uses the non-tagged production in the If header. It includes the state token for the lock on C. 8.4 says "If the state of the resource to which the header is applied does not match any of the specified state lists than the request MUST fail". Clearly the PUT method is applied to C/R, yet there is no possible state token that the client can include that will match C/R. It does not even exist yet, it has no state at all. Perhaps the protocol should be amended with the material below in brackets. "If the state of the resource to which the header is applied does not match any of the specified state lists [and the resource is not null] than the request MUST fail". and with something to the effect of A client SHOULD use tagged productions rather than the no-tag-list production when the set of affected resources is known in advance and is small. As for my second question, I am sure the language of 8.4.1 is crystal clear to you. But you wrote it. My claim is that it is not crystal clear to me, and hence not likely to be crystal clear to others. To summarize, the two points of unclarity are: 1. the restrictive qualifier "due to the presence of a Depth or Destination header". 2. what it means to "apply". adding a cite to RFC 2068 would be sufficient if there's a clear statement there. or we could use the definition from your reply, which (editted) reads: >To apply a method [to a resource] ... means that the method >directly affects the state of [the] resource. But the protocol language as is is sufficiently unclear that even reasonably competent readers can have doubts about its meaning. From w3c-dist-auth-request@w3.org Sat Sep 12 15:11:28 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA14753 for ; Sat, 12 Sep 1998 15:11:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06163; Sat, 12 Sep 1998 15:06:19 -0400 (EDT) Resent-Date: Sat, 12 Sep 1998 15:06:19 -0400 (EDT) Resent-Message-Id: <199809121906.PAA06163@www19.w3.org> Message-Id: <3.0.5.32.19980912120606.007f5410@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 12 Sep 1998 12:06:06 PDT To: w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <001201bddde0$8e923040$d115c380@galileo.ics.uci.edu> References: <199809102028.NAA22829@warlok.ds.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2046 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 05:01 PM 9/11/98 PDT, Jim Whitehead wrote: >The implication of the requirement in section 4.3 (no namespace gaps) >combined with the requirement in section 4.1 that namespaces must behave as >DAV collections even if they weren't created with WebDAV, is that yes, the >resource identified by http://warlok.ds.boeing.com/~howie/ needs to be of >type WebDAV collection if http://warlok.ds.boeing.com/~howie/a/b/c is >WebDAV-compliant. I agree that this is the implication of the protocol as it stands. I would like to raise an objection to it, as it would prohibit one from supporting DAV methods on anything smaller than the full namespace of a server. It is often useful for various subtrees of a server's namespace to support different sets of methods (sometimes via cgi scripts, without assistance from the server maintainer) and there is no benefit to this restriction (unlike the one requiring internal consistency). I have been meaning to complain about this for a while but didn't because it seems to be trivial. I was having a hard time imagining anyone being so picky as to insist on this point (and, perhaps, denying me the covetted "100 % Pure DAV" sticker for my server?) but perhaps it's better to face it now. In fact, this very issue has been raised in some discussions internal to Xerox. People have said to me "We would like to support DAV methods in this subtree but we don't want to support them on the root but the protocol says we MUST do it, so can we still use DAV?". So Howie isn't the only one worrying about it. I say, strike the restriction. From w3c-dist-auth-request@w3.org Mon Sep 14 13:37:53 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA27394 for ; Mon, 14 Sep 1998 13:37:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA25297; Mon, 14 Sep 1998 13:32:09 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 13:32:09 -0400 (EDT) Resent-Message-Id: <199809141732.NAA25297@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host inet-gw.indy.tce.com [157.254.232.6] claimed to be tcemail.indy.tce.com Message-ID: <2C396693FBDED111AEF60000F84104A721BFAF@indyexch_fddi.indy.tce.com> From: Fisher Mark To: w3c-dist-auth@w3.org Date: Mon, 14 Sep 1998 12:32:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2048 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >I have been meaning to complain about this for a while but didn't because >it seems to be trivial. I was having a hard time imagining anyone being so >picky as to insist on this point (and, perhaps, denying me the covetted >"100 % Pure DAV" sticker for my server?) but perhaps it's better to face it >now. In fact, this very issue has been raised in some discussions internal >to Xerox. People have said to me "We would like to support DAV methods in >this subtree but we don't want to support them on the root but the protocol >says we MUST do it, so can we still use DAV?". So Howie isn't the only one >worrying about it. > >I say, strike the restriction. Based on my experiences as a webmaster, I'd agree. I really don't see any prospect of webmasters wanting to have only root-based subtrees (like ) be DAV-compliant. DAV will work and play better with others if it can be restricted to non-root-based subtrees. Not that some servers won't want to be set up using DAV for all document management -- just that some (probably the majority) will not use DAV for all document management, for various political/social/technical reasons. > ========================================================== > Mark Leighton Fisher Thomson Consumer Electronics > fisherm@indy.tce.com Indianapolis, IN > "Browser Torture Specialist, First Class" > From w3c-dist-auth-request@w3.org Mon Sep 14 13:56:20 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA27890 for ; Mon, 14 Sep 1998 13:56:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA25637; Mon, 14 Sep 1998 13:51:14 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 13:51:14 -0400 (EDT) Resent-Message-Id: <199809141751.NAA25637@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <35FD579F.F5B16F00@netscape.com> Date: Mon, 14 Sep 1998 10:51:27 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <199809102028.NAA22829@warlok.ds.boeing.com> <3.0.5.32.19980912120606.007f5410@mailback.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2049 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Davis wrote: > I say, strike the restriction. I agree. If we do, then even someone with an ordinary ISP account could run DAV on their account, given a CGI implementation. Also, consider that DAV is a potential security risk (depending on the implementation, of course), so there will be people who want to have only some areas of their server run DAV extensions. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|Both candidates | |Software Retrophrenologist|=======================/are better than a| |Netscape Comm. Corp. |megalomaniac mutant lab mouse bent on | |francis@netscape.com |world domination...but it's pretty close.| \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Mon Sep 14 19:21:07 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA04024 for ; Mon, 14 Sep 1998 19:21:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA01110; Mon, 14 Sep 1998 19:15:58 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 19:15:58 -0400 (EDT) Resent-Message-Id: <199809142315.TAA01110@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022444674000002L042*@MHS> Date: Mon, 14 Sep 1998 19:19:49 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: etag in untagged production of If header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2050 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list My interpretation of the No-tag-list production in an If header is that is is used for those cases where the condition (a list of state tokens and/or e-tags) applies to the (single) target resource of the request method, no other resource is effected. The Tagged-list production is for methods that effect more than one resource and therefore need to provide matching conditions for each. From w3c-dist-auth-request@w3.org Mon Sep 14 19:21:23 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA04035 for ; Mon, 14 Sep 1998 19:21:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA01137; Mon, 14 Sep 1998 19:16:25 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 19:16:25 -0400 (EDT) Resent-Message-Id: <199809142316.TAA01137@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022444675000002L052*@MHS> Date: Mon, 14 Sep 1998 19:19:50 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2051 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >"We would like to support DAV methods in >this subtree but we don't want to support them on the root but the protocol >says we MUST do it, so can we still use DAV?" It should be possible to configure a DAV server to have a document root contained in "collection" that is not DAV compliant. For example, I use the Java Web Server's doc.root of c:\some-path\public-html and set the doc.root for my authoring web server to be c:\some-path\public-html\dav. This keeps the authoring server and the production server out of each other's way, but uses the same file system root for both. Other configurations are possible. The -08 spec does not prevent this, it only leaves it as a server option. From w3c-dist-auth-request@w3.org Mon Sep 14 19:41:38 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA04230 for ; Mon, 14 Sep 1998 19:41:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA01370; Mon, 14 Sep 1998 19:36:52 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 19:36:52 -0400 (EDT) Resent-Message-Id: <199809142336.TAA01370@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022445069000002L092*@MHS> Date: Mon, 14 Sep 1998 19:40:51 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Adv. Coll. items from the 42nd IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2052 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list 3. Issue: Should access control of references be distinct from those of target? Yes. SQL views are a good example of a similar concept. 4. Issue: Should the owner of a resource should be able to prevent creation of references to it via ACL? This would affect requirements for ACL, not ACR. No, creating a reference to a resource should only require read access to the resource. In general, the ACL scheme needs to be simplified from ACLs on every DAV method to ACLs on the effect the DAV method has on the state of the resource. Basically CRUD plus Execute like in most operating systems. From w3c-dist-auth-request@w3.org Mon Sep 14 20:29:48 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA04509 for ; Mon, 14 Sep 1998 20:29:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01651; Mon, 14 Sep 1998 20:25:11 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 20:25:11 -0400 (EDT) Resent-Message-Id: <199809150025.UAA01651@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-46.netscape.com [205.217.237.46] claimed to be netscape.com Message-ID: <35FDB3F6.B0A67651@netscape.com> Date: Mon, 14 Sep 1998 17:25:27 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG References: <5040100022445069000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Adv. Coll. items from the 42nd IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2053 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Amsden wrote: > 4. Issue: Should the owner of a resource should be able to prevent creation of > references to it via ACL? This would affect requirements for ACL, not ACR. > > No, creating a reference to a resource should only require read access to the > resource. Probably not even that--a reference presents no more risk to the resource than a link. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |Beware of wizards, for you are crunchy | |francis@netscape.com | and good with ketchup. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Mon Sep 14 20:31:24 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA04576 for ; Mon, 14 Sep 1998 20:31:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01728; Mon, 14 Sep 1998 20:26:38 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 20:26:38 -0400 (EDT) Resent-Message-Id: <199809150026.UAA01728@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-46.netscape.com [205.217.237.46] claimed to be netscape.com Message-ID: <35FDB44F.C6AC0458@netscape.com> Date: Mon, 14 Sep 1998 17:26:56 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG References: <5040100022444675000002L052*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2054 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Amsden wrote: > >"We would like to support DAV methods in > >this subtree but we don't want to support them on the root but the protocol > >says we MUST do it, so can we still use DAV?" > > It should be possible to configure a DAV server to have a document root > contained in "collection" that is not DAV compliant. For example, I use the > Java Web Server's doc.root of c:\some-path\public-html and set the doc.root for > my authoring web server to be c:\some-path\public-html\dav. Yeah, but then you can't use the same URI for authoring as for browsing, in which case you might as well author via FTP. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |Beware of wizards, for you are crunchy | |francis@netscape.com | and good with ketchup. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Mon Sep 14 22:05:20 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA05005 for ; Mon, 14 Sep 1998 22:05:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA02298; Mon, 14 Sep 1998 22:00:36 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 22:00:36 -0400 (EDT) Resent-Message-Id: <199809150200.WAA02298@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: WebDAV WG Date: Mon, 14 Sep 1998 18:59:14 -0700 Message-ID: <003e01bde04c$7062c760$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <35FDB44F.C6AC0458@netscape.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2055 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I wrote: > yes, the resource identified by http://warlok.ds.boeing.com/~howie/ > needs to be of type WebDAV collection if > http://warlok.ds.boeing.com/~howie/a/b/c is WebDAV-compliant. Jim Davis wrote: > I agree that this is the implication of the protocol as it stands. Yaron Goland wrote: > Actually no, http://foo/bar does NOT have to be a collection just because > http://foo/bar/blah is a collection. Jim Davis wrote: > I say, strike the restriction. Mark Fisher wrote: > Based on my experiences as a webmaster, I'd agree. John Stracke wrote: > I agree. I am quite happy to alter the language of the -08 spec. so that the correct meaning of these requirements is expressed, rather than the virus-like behavior that the spec. can be read to imply, which people object to. What I read from this rough consensus on the list is people would like the language to read that a parent of a resource does not have to be a WebDAV-collection. However, if the parent of a WebDAV resource is itself WebDAV compatible, then it has to be a WebDAV collection. A couple of questions: 1) Should there be a policy for whether the parent of a resource must exist? So, if http://foo/bar/blah exists, and is DAV-compliant, must resource http://foo/bar/ exist? My answer: Since we're not requiring the parent of a DAV resource to be a DAV collection, there is no guarantee that a client will be able to retrieve a listing of the other resources at a given level in the HTTP URL hierarchy. Due to this, there isn't much of a difference between getting a 501 Not Implemented for an existing resource that doesn't support PROPFIND, or getting a 404 Not Found for a non-existing resource -- either way the client won't be able to get an index. So, my answer is that we shouldn't require a DAV-compliant resource to have a parent resource. 2) Larry Masinter's question (intermediate collections): > Must the intermediaries also be DAV compliant? Well, for one level > it doesn't matter, but suppose: > > 1) http://foo/bar is DAV compliant > 2) http://foo/bar/a/b/c/blah/ exists and is DAV compliant > 3) then must http://foo/bar/a/b be a (DAV-compliant) collection? > > This would leave out the possibility that http://foo/bar/a might > be some kind of mapping? Or is it that "exists" needs elaboration > to except that case where it's a redirection? My answer: I think we should require all collections below a DAV-compliant resource to also be DAV-compliant. So, while it's OK to not be DAV-compliant looking up a hierarchy tree, looking down the tree from a DAV-compliant location should always be DAV-compliant. This way DAV clients will be able to get listings of the members of a collection once they're in a DAV compliant portion of the namespace while going down the namespace hierarchy, providing a less confusing user experience than if the behavior of the namespace changed from level to level. - Jim From w3c-dist-auth-request@w3.org Mon Sep 14 22:46:18 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA06145 for ; Mon, 14 Sep 1998 22:46:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA02828; Mon, 14 Sep 1998 22:41:26 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 22:41:26 -0400 (EDT) Resent-Message-Id: <199809150241.WAA02828@www19.w3.org> Message-Id: <3.0.3.32.19980914194132.009449b0@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 14 Sep 1998 19:41:32 PDT To: WebDAV WG From: Jim Davis In-Reply-To: <003e01bde04c$7062c760$d115c380@galileo.ics.uci.edu> References: <35FDB44F.C6AC0458@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2056 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 06:59 PM 9/14/98 PDT, Jim Whitehead wrote: >What I read from this rough consensus on the list is people would like the >language to read that a parent of a resource does not have to be a >WebDAV-collection. However, if the parent of a WebDAV resource is itself >WebDAV compatible, then it has to be a WebDAV collection. > >A couple of questions: > >1) Should there be a policy for whether the parent of a resource must exist? >So, if http://foo/bar/blah exists, and is DAV-compliant, must resource >http://foo/bar/ exist? >.. my answer is that we shouldn't require a DAV-compliant resource to have >a parent resource. Fine with me. (Don't care much either way.) > I think we should require all collections below a DAV-compliant >resource to also be DAV-compliant. So, while it's OK to not be >DAV-compliant looking up a hierarchy tree, looking down the tree from a >DAV-compliant location should always be DAV-compliant. Strongly agree. From w3c-dist-auth-request@w3.org Mon Sep 14 23:56:39 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA12742 for ; Mon, 14 Sep 1998 23:56:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA03256; Mon, 14 Sep 1998 23:44:56 -0400 (EDT) Resent-Date: Mon, 14 Sep 1998 23:44:56 -0400 (EDT) Resent-Message-Id: <199809150344.XAA03256@www19.w3.org> From: "Larry Masinter" To: "Jim Davis" , "WebDAV WG" Date: Mon, 14 Sep 1998 20:43:56 PDT Message-ID: <000701bde05b$10ad98e0$15d0000d@copper-208.parc.xerox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-to: <3.0.3.32.19980914194132.009449b0@mailback.parc.xerox.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2057 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > > I think we should require all collections below a DAV-compliant > >resource to also be DAV-compliant. So, while it's OK to not be > >DAV-compliant looking up a hierarchy tree, looking down the tree from a > >DAV-compliant location should always be DAV-compliant. > > Strongly agree. So a DAV-compliant resource can't be, say, a CGI script? Even in 'advanced DAV'? If I have http://a/b/c/ and I want to add a CGI such that http://a/b/c/d is indirectly http://a/b/c/d.cgi, where 'd.cgi' computes a query, you might have http://a/b/c/d?e . Now, is http://a/b/c/d.cgi a 'member' of http://a/b/c/ ? Larry -- http://www.parc.xerox.com/masinter > > From w3c-dist-auth-request@w3.org Tue Sep 15 03:06:56 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA15051 for ; Tue, 15 Sep 1998 03:06:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA04925; Tue, 15 Sep 1998 03:01:35 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 03:01:35 -0400 (EDT) Resent-Message-Id: <199809150701.DAA04925@www19.w3.org> Message-ID: <3FF8121C9B6DD111812100805F31FC0D087925C7@RED-MSG-59> From: Yaron Goland To: "Jim Whitehead (E-mail)" , "'Larry Masinter'" , Jim Davis , WebDAV WG Date: Tue, 15 Sep 1998 00:01:45 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2058 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list My reading of the DAV spec is that both Jim's statement (the parents of a DAV resource do not have to be a DAV resource) and Larry's language (the child of a DAV resource doesn't have to be a DAV resource) are BOTH correct and BOTH supported by the spec. The language in the spec is phrased as "If a resource is DAV compliant THEN ....." In the particular case Larry lists my understanding of the spec is that if http://a/b/c IS DAV compliant then http://a/b/c/d.cgi WOULD be listed as a member of http://a/b/c EVEN THOUGH it isn't itself DAV compliant. The requirement for listing is only on http://a/b/c because it is DAV compliant but this puts no onus on http://a/b/c/d.cgi to be DAV compliant. Yaron > -----Original Message----- > From: Larry Masinter [mailto:masinter@parc.xerox.com] > Sent: Monday, September 14, 1998 8:44 PM > To: Jim Davis; WebDAV WG > Subject: RE: Namespace consistency > > > > > > I think we should require all collections below a DAV-compliant > > >resource to also be DAV-compliant. So, while it's OK to not be > > >DAV-compliant looking up a hierarchy tree, looking down > the tree from a > > >DAV-compliant location should always be DAV-compliant. > > > > Strongly agree. > > So a DAV-compliant resource can't be, say, a CGI script? Even in > 'advanced DAV'? > > If I have http://a/b/c/ and I want to add a CGI such that > http://a/b/c/d is indirectly http://a/b/c/d.cgi, where > 'd.cgi' computes a query, you might have http://a/b/c/d?e . > Now, is http://a/b/c/d.cgi a 'member' of http://a/b/c/ ? > > Larry > -- > http://www.parc.xerox.com/masinter > > > > > > From w3c-dist-auth-request@w3.org Tue Sep 15 03:28:43 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA15117 for ; Tue, 15 Sep 1998 03:28:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA05047; Tue, 15 Sep 1998 03:23:46 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 03:23:46 -0400 (EDT) Resent-Message-Id: <199809150723.DAA05047@www19.w3.org> Message-ID: <3FF8121C9B6DD111812100805F31FC0D087925C8@RED-MSG-59> From: Yaron Goland To: "'Jim Davis'" , w3c-dist-auth@w3.org Date: Tue, 15 Sep 1998 00:24:02 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Subject: RE: three clarification questions on the If header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2059 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I believe the spec is clear on the effects of the Depth 0 lock but I do admit that the term "Depth 0" gives the connotation that somehow the children aren't covered under the lock token. However Depth 0 in this context is only meant to reference the scope of the original LOCK method. That is, the original LOCK was only on the collection and thus was Depth 0. However the effect of a depth 0 write lock extends to the children in that PUT and DELETE is restricted on them as an effect of the lock. Thus submitted the write lock token for C in an untagged production on C/R is completely correct because the locktoken DOES describe C/R's state (or potential to have state, depending on how you actually define what it means to have an undefined resource, after all, if the resource isn't defined how could it return an error? But that is a philosophical discussion I will leave for Roy Fielding and his ilk). I will definitely record this issue in my list of things that could be clearer in WebDAV. Yaron > -----Original Message----- > From: Jim Davis [mailto:jdavis@parc.xerox.com] > Sent: Saturday, September 12, 1998 11:54 AM > To: Yaron Goland; w3c-dist-auth@w3.org > Subject: RE: three clarification questions on the If header. > > > At 07:26 PM 9/11/98 PDT, Yaron Goland wrote: > > >This example is too vague to properly respond to. You need > to specify what > >method you are executing, what sort of lock you have on C, > what its depth > >is, etc. and why you need to refer to C's lock in order to > execute your > >method on R. > > You're right, the question was too vague. Here is another try. > > A client has an exclusive write lock on collection C at depth 0. The > client wishes to create a new resource C/R by doing a PUT. > The state token > for C is needed because C/R did not exist previously (7.10.2) > > Suppose the client uses the non-tagged production in the If > header. It > includes the state token for the lock on C. > > 8.4 says "If the state of the resource to which the header is > applied does > not match any of the specified state lists than the request > MUST fail". > > Clearly the PUT method is applied to C/R, yet there is no > possible state > token that the client can include that will match C/R. It > does not even > exist yet, it has no state at all. > > Perhaps the protocol should be amended with the material > below in brackets. > > "If the state of the resource to which the header is applied > does not match > any of the specified state lists [and the resource is not > null] than the > request MUST fail". > > and with something to the effect of > > A client SHOULD use tagged productions rather than the no-tag-list > production when the set of affected resources is known in > advance and is > small. > > As for my second question, I am sure the language of 8.4.1 is > crystal clear > to you. But you wrote it. My claim is that it is not > crystal clear to me, > and hence not likely to be crystal clear to others. > > To summarize, the two points of unclarity are: > > 1. the restrictive qualifier "due to the presence of a Depth > or Destination > header". > > 2. what it means to "apply". adding a cite to RFC 2068 would > be sufficient > if there's a clear statement there. or we could use the > definition from > your reply, which (editted) reads: > > >To apply a method [to a resource] ... means that the method > >directly affects the state of [the] resource. > > But the protocol language as is is sufficiently unclear that even > reasonably competent readers can have doubts about its meaning. > > > From w3c-dist-auth-request@w3.org Tue Sep 15 03:30:46 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA15132 for ; Tue, 15 Sep 1998 03:30:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA05121; Tue, 15 Sep 1998 03:26:10 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 03:26:10 -0400 (EDT) Resent-Message-Id: <199809150726.DAA05121@www19.w3.org> Message-ID: <3FF8121C9B6DD111812100805F31FC0D087925C9@RED-MSG-59> From: Yaron Goland To: "'Jim Amsden'" , w3c-dist-auth@w3.org Date: Tue, 15 Sep 1998 00:26:29 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Subject: RE: etag in untagged production of If header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2060 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I could also probably come up with some fairly convoluted example where you could use an untagged If header with an e-tag on a Depth Infinity method but that would be besides the point. The real point is that we generally don't ban something unless we have a reason to. Since we didn't have a compelling reason to keep e-tags out of untagged lists and there is occasion that they could actually be useful in an untagged list, we decided to just allow them. Yaron > -----Original Message----- > From: Jim Amsden [mailto:jamsden@us.ibm.com] > Sent: Monday, September 14, 1998 4:20 PM > To: w3c-dist-auth@w3.org > Subject: Re: etag in untagged production of If header > > > My interpretation of the No-tag-list production in an If > header is that is is > used for those cases where the condition (a list of state > tokens and/or e-tags) > applies to the (single) target resource of the request > method, no other > resource is effected. The Tagged-list production is for > methods that effect > more than one resource and therefore need to provide matching > conditions for > each. > From w3c-dist-auth-request@w3.org Tue Sep 15 13:59:33 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA01038 for ; Tue, 15 Sep 1998 13:59:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10992; Tue, 15 Sep 1998 13:52:57 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 13:52:57 -0400 (EDT) Resent-Message-Id: <199809151752.NAA10992@www19.w3.org> Message-Id: <3.0.5.32.19980915102901.007e5100@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 Sep 1998 10:29:01 PDT To: Yaron Goland , w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <3FF8121C9B6DD111812100805F31FC0D087925C8@RED-MSG-59> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: three clarification questions on the If header. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2061 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 12:24 AM 9/15/98 PDT, Yaron Goland wrote: >I believe the spec is clear on the effects of the Depth 0 lock but I do >admit that the term "Depth 0" gives the connotation that somehow the >children aren't covered under the lock token. Yes, the spec is quite clear on this point. As I understand it, since C is a collection, its state includes among other things the set of resources that it contains. Adding to or deleting from this set affects C's state, and hence one needs the locktoken. It is also clear that for (pre-existing) resource C/R, doing a PUT (overwriting it) does not affect C's state, so one does not need the lock token. >... the write lock token for C in an untagged production on C/R is >completely correct because the locktoken DOES describe C/R's state Sounds reasonable, but I would like this to be stated explicitly in the spec, perhaps as an example, because it certainly is not obvious even after careful study. If not in the protocol spec, then please collect it for the O'Rielly book (Please say you're planning to write one!. What animal goes on the cover? Maybe a dove? or maybe some colonial insect such as an ant or a bee, good examples of distributed cooperative authoring?) From w3c-dist-auth-request@w3.org Tue Sep 15 13:59:34 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA01041 for ; Tue, 15 Sep 1998 13:59:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11017; Tue, 15 Sep 1998 13:53:25 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 13:53:25 -0400 (EDT) Resent-Message-Id: <199809151753.NAA11017@www19.w3.org> Message-Id: <3.0.5.32.19980915104553.007d8b30@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 Sep 1998 10:45:53 PDT To: "WebDAV WG" From: Jim Davis In-Reply-To: <000701bde05b$10ad98e0$15d0000d@copper-208.parc.xerox.com> References: <3.0.3.32.19980914194132.009449b0@mailback.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2062 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 08:43 PM 9/14/98 PDT, Larry Masinter wrote: >> Jim Whitehead wrote: >> > I think we should require all collections below a DAV-compliant >> >resource to also be DAV-compliant. So, while it's OK to not be >> >DAV-compliant looking up a hierarchy tree, looking down the tree from a >> >DAV-compliant location should always be DAV-compliant. Hmm, I he did say all _collections_ below a DAV compliant resource, not all resources of any kind. But since 'collection' is a term defined by DAV, what would it mean to be a 'collection' that is not 'DAV'. Jim, did you mean 'resource', or did you mean 'namespace' (in the HTTP sense, not XML). I was assuming he meant 'namespace'. On the other hand, what about the stronger claim (that all resources within a collection must be DAV compliant). It's not unreasonable. What does it mean to do PROPFIND on collection a/b/c, discover that it includes resource a/b/c/d, but that one can't do PROPFIND on a/b/c/d? >So a DAV-compliant resource can't be, say, a CGI script? Of course it can be a CGI script. That's one reason that DAV has source links. What do you see that would prohibit this? >If I have http://a/b/c/ and I want to add a CGI such that > http://a/b/c/d is indirectly http://a/b/c/d.cgi, where >'d.cgi' computes a query, you might have http://a/b/c/d?e . >Now, is http://a/b/c/d.cgi a 'member' of http://a/b/c/ ? I don't understand what you mean by 'indirectly' enough to speak to that, but if a PROPFIND on http://a/b/c/d includes http://a/b/c/d.cgi, then d.cgi is a member of a/b/c. Otherwise, not, because there is no other DAV way to traverse the URL namespace except by issuing PROPFINDs. From w3c-dist-auth-request@w3.org Tue Sep 15 14:11:23 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01394 for ; Tue, 15 Sep 1998 14:11:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA11263; Tue, 15 Sep 1998 14:04:43 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 14:04:43 -0400 (EDT) Resent-Message-Id: <199809151804.OAA11263@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <35FEAC4E.487FB99C@netscape.com> Date: Tue, 15 Sep 1998 11:05:02 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG References: <3.0.3.32.19980914194132.009449b0@mailback.parc.xerox.com> <3.0.5.32.19980915104553.007d8b30@mailback.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2063 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Davis wrote: > >So a DAV-compliant resource can't be, say, a CGI script? > > Of course it can be a CGI script. That could be very difficult to implement, though. If http://foo/bar/baz.cgi is a CGI script, then http://foo/bar/baz.cgi/quux.html is a perfectly legal URI as far as the protocol's concerned. If descendants of DAV collections must be DAV, then baz.cgi must implement all DAV methods in order for quux.html to be compliant. Of course, the server's DAV implementation can provide helper code for baz.cgi to use, but it could still get pretty nasty. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |"The avalanche has already started. It is| |francis@netscape.com | too late for the pebbles to vote." -Kosh| \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 15 15:09:02 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA02633 for ; Tue, 15 Sep 1998 15:09:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12150; Tue, 15 Sep 1998 15:04:08 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 15:04:08 -0400 (EDT) Resent-Message-Id: <199809151904.PAA12150@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C5D@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Tue, 15 Sep 1998 15:05:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: Advanced Collections Requirement: Hiding the Location of a Target Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2064 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I would like to try to spark more discussion of the issues raised at IETF 42 on the Advanced Collections requirements and specification. Jim Davis provided a very useful summary of those issues in his mailnote of August 31, "Adv. Coll. items from the 42nd IETF". This is the first of a series of notes intended to push further on each of the issues Jim lists. There was a suggestion for a new requirement that the creator of a reference be able to hide the location of the target. This makes sense only for direct references. Indirect references cannot be used at all unless a client can retrieve the URI of the target in order to make requests directly of the target. In the context of direct references, what is the ratoinale for this requirement? If it's just wanting to prevent users from deleting / moving / copying the target, presumably that could be done through access control and would not need a requirement about referencing. I would appreciate hearing the rationale before considering adding this requirement. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 15:10:18 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA02669 for ; Tue, 15 Sep 1998 15:10:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12191; Tue, 15 Sep 1998 15:05:06 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 15:05:06 -0400 (EDT) Resent-Message-Id: <199809151905.PAA12191@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C5E@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'Jim Amsden'" , "'WebDAV'" Cc: slein@wrc.xerox.com Date: Tue, 15 Sep 1998 15:06:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: References and Access Control (was, RE: Adv. Coll. items from the 42nd IETF) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2065 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Jim Amsden wrote: > > 3. Issue: Should access control of references be distinct from those > of target? > > Yes. SQL views are a good example of a similar concept. This seems right to me. At least indirect references are resources, with their own URLs, to which HTTP and WebDAV can be applied, which bear properties, etc. So access control should certainly apply to them just as to any other resource. Direct references are less clear, but they get created independently of their targets, deleted independently of their targets, and some subset of HTTP / WebDAV methods affect them, so it seems as if they, too, should have access control separate from their targets. > > 4. Issue: Should the owner of a resource should be able to > prevent creation of > references to it via ACL? This would affect requirements for > ACL, not ACR. > > No, creating a reference to a resource should only require > read access to the > resource. In general, the ACL scheme needs to be simplified > from ACLs on every > DAV method to ACLs on the effect the DAV method has on the > state of the > resource. Basically CRUD plus Execute like in most operating systems. > This is not so clear. The discussion of Strong References at Redmond revealed some security risks that might lead us to conclude that we want access control on the creation of references. For example, one way for a server to preserve referential integrity for DELETE operations is to refuse to delete the target as long as there are any references to it. On a server that uses this approach, the owner of any resource who wanted to be sure he could always delete it might want to restrict permissions to create (strong) references to it. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 15:27:55 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA02941 for ; Tue, 15 Sep 1998 15:27:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12473; Tue, 15 Sep 1998 15:21:47 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 15:21:47 -0400 (EDT) Resent-Message-Id: <199809151921.PAA12473@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C5F@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Cc: "Slein, Judith A" Date: Tue, 15 Sep 1998 15:23:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: Direct References in the Advanced Collections Requirements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2066 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I would like to propose the following changes to the Advanced Collections Requirements. 1. The requirements will use the following terminology and definitions instead of the current indirect / direct references terminology: Client-Side Reference: A reference that must be resolved by the client. Any method applied to a Client-Side Reference affects the reference only, not its target. To affect the target of a Client-Side reference, the client must resolve the reference and operate directly on its target. Server-Side Reference: A reference whose existence is, in general, hidden from the client. For the most part, methods applied to a Server-Side Reference affect its target, not the reference itself. The server resolves the reference and applies the method to its target. Rationale: Roy Fielding has been requesting for some time that we change the terminology. This is in part an attempt to satisfy his request. In addition, the current requirements document defines a Server-Side Reference as one for which all operations are passed through to its target. It is clear from the discussion at IETF 42 that this definition is too strong. It was proposed there that DELETE, COPY, and MOVE are not passed through to the target. I would like *not* to make a commitment in the requirements about exactly which operations get passed through and which do not, but still express the general intent of Server-Side References. For most operations, they give a client the impression that it is operating directly on the target, hiding the existence of the reference from the client. 2. The requirements will give the following rationale for supporting both sorts of reference. Client-Side References provide the basic benefits desired from referencing: They allow multiple collections, on the same or different servers, to share a single resource, in such a way that any change to the resource will automatically be reflected in the collections that contain it by reference. They provide this benefit at very low cost to the server, and with no security implications. Server-Side References hide the existence of the reference from the client, thus simplifying for the client operations through the reference, and making them more efficient. Fewer round trips are required to accomplish the same task than with Client-Side References. Servers already support server-side references, generally through configuration files; exposing this capability through the protocol seems desirable. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 15:44:14 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03329 for ; Tue, 15 Sep 1998 15:44:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12743; Tue, 15 Sep 1998 15:39:15 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 15:39:15 -0400 (EDT) Resent-Message-Id: <199809151939.PAA12743@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C60@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Tue, 15 Sep 1998 15:41:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: Proposed Referential Integrity Requirement Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2067 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list A new requirement was suggested at IETF 42, that there should be a choice about whether deleting the target of a direct reference deletes all (direct) references. I do not know whether the intent was that the server should be able to decide whether to preserve referential integrity for deletions, or whether the intent was that a client should be able to ask that referential integrity be preserved (or not) for a DELETE request. In either case, I would prefer not to make a specific statement about deletion in the requirements unless we can make similar statements about all operations that can affect referential integrity. If the requirement is meant to be about server policies: I would be willing to make the more general statement that a server that provides references is not required to support strong references -- that is, it is not required to preserve referential integrity. I think there would be wide agreement to this requirement, particularly since we have already agreed that the first release of the protocol specification will not address strong references. If the suggestion was meant to be that the client deleting the target be able to specify whether referential integrity should be preserved, that's probably more contentious. At Redmond, the discussion of strong references made it clear that there was no consensus about who should get to decide policies about referential integrity -- the server, the owner of the affected resource, or the client making a request. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 15:50:37 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03502 for ; Tue, 15 Sep 1998 15:50:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12870; Tue, 15 Sep 1998 15:45:05 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 15:45:05 -0400 (EDT) Resent-Message-Id: <199809151945.PAA12870@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C61@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Tue, 15 Sep 1998 15:46:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: Server-Side References: Which Methods Get Passed Through? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2068 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Making the definition of Server-Side References (formerly Direct References) operational involves making a decision about which methods affect the target, and which affect the reference itself. Although it would be possible to support different flavors of Server-Side References that pass through different methods to their targets, for simplicity's sake it would be preferable to settle on one. The following proposal was well received at the IETF: These methods affect the target: GET, HEAD, PUT, POST, PROPFIND, PROPPATCH These methods affect the reference: DELETE, COPY, MOVE We will adopt this interpretation in the Advanced Collections protocol specification if there are no objections. It would be useful to know whether there are server vendors or DMS vendors whose products pass through a different set of methods to the target for Server-Side References. Or whether there are those who think that clients need to be able to request that a particular set of operations affect the target when they create a Server-Side Reference. (There was strong sentiment in Chicago against giving clients the freedom to define arbitrary lists of pass-through operations.) Since on this interpretation DELETE will affect the reference, and not its target, the DELREF method currently proposed in the protocol specification can be dropped. If we can agree on a single set of operations that affect the target, and a single list of operations that affect the reference, the current Pass-Through header and property can be replaced by a simpler Ref-Type header and property, whose values are just DAV:client-side or DAV:server-side. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 15:52:56 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA03553 for ; Tue, 15 Sep 1998 15:52:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13125; Tue, 15 Sep 1998 15:48:03 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 15:48:03 -0400 (EDT) Resent-Message-Id: <199809151948.PAA13125@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host [131.107.88.59] claimed to be dfssl.exchange.microsoft.com Message-ID: <2FBF98FC7852CF11912A000000000001090F5AD9@DINO> From: "Lisa Lippert (Dusseault) (Exchange)" To: "'Slein, Judith A'" , "'Jim Amsden'" , "'WebDAV'" Cc: slein@wrc.xerox.com Date: Tue, 15 Sep 1998 12:46:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: References and Access Control (was, RE: Adv. Coll. items from the 42nd IETF) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2069 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Even strong references require some kind of separate access control list. You need to be able to specify who can delete the strong reference, and it may not be the same list of principals that can delete the resource referred to. I'm not clear whether all possible operations on references, strong or weak, need their own access control. Lisa -----Original Message----- From: Slein, Judith A [mailto:JSlein@crt.xerox.com] Sent: Tuesday, September 15, 1998 12:07 PM To: 'Jim Amsden'; 'WebDAV' Cc: slein@wrc.xerox.com Subject: References and Access Control (was, RE: Adv. Coll. items from the 42nd IETF) >Jim Amsden wrote: > > 3. Issue: Should access control of references be distinct from those > of target? > > Yes. SQL views are a good example of a similar concept. This seems right to me. At least indirect references are resources, with their own URLs, to which HTTP and WebDAV can be applied, which bear properties, etc. So access control should certainly apply to them just as to any other resource. Direct references are less clear, but they get created independently of their targets, deleted independently of their targets, and some subset of HTTP / WebDAV methods affect them, so it seems as if they, too, should have access control separate from their targets. > > 4. Issue: Should the owner of a resource should be able to > prevent creation of > references to it via ACL? This would affect requirements for > ACL, not ACR. > > No, creating a reference to a resource should only require > read access to the > resource. In general, the ACL scheme needs to be simplified > from ACLs on every > DAV method to ACLs on the effect the DAV method has on the > state of the > resource. Basically CRUD plus Execute like in most operating systems. > This is not so clear. The discussion of Strong References at Redmond revealed some security risks that might lead us to conclude that we want access control on the creation of references. For example, one way for a server to preserve referential integrity for DELETE operations is to refuse to delete the target as long as there are any references to it. On a server that uses this approach, the owner of any resource who wanted to be sure he could always delete it might want to restrict permissions to create (strong) references to it. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 16:00:32 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA03713 for ; Tue, 15 Sep 1998 16:00:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13254; Tue, 15 Sep 1998 15:55:03 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 15:55:03 -0400 (EDT) Resent-Message-Id: <199809151955.PAA13254@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <35FEC62B.256997@netscape.com> Date: Tue, 15 Sep 1998 12:55:24 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: "'WebDAV'" References: <201BB34B3A73D1118C1F00805F1582E8B76C5D@x-wb-0128-nt8.wrc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Advanced Collections Requirement: Hiding the Location of a Target Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2070 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list "Slein, Judith A" wrote: > There was a suggestion for a new requirement that the creator of a > reference be able to hide the location of the target. [...] > In the context of direct references, what is the ratoinale for this > requirement? I think the answer is that the target URI itself might be sensitive data. For example, suppose I were running a startup out of my home while working for Netscape (I'm not :-), and wanted to keep it private. Say the startup's pages are under http://foo/myStartup/ (bit of a giveaway), and there's a single page in there that I want to show to a Netscape co-worker, so I create an indirect reference to it. I don't want them to be able to see the target URI. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | Whose cruel idea was it for the word | |francis@netscape.com | "Lisp" to have an "S" in it? | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 15 16:17:49 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04021 for ; Tue, 15 Sep 1998 16:17:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13411; Tue, 15 Sep 1998 16:09:37 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 16:09:37 -0400 (EDT) Resent-Message-Id: <199809152009.QAA13411@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C62@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Tue, 15 Sep 1998 16:11:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2071 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list There has been no discussion following Jim Davis's mailnote "Proposal: optional backpointers for ACR" of August 19. Unless there are objections, this proposal will be incorporated in the Advanced Collections protocol specification, and a corresponding requirement will be added to the Advanced Collections requirements. The requirement will state: There is an interoperable means of navigating from a resource that is the target of multiple references up the collection hierarchies from which it is referenced. The protocol specification will include: The definition of a new, optional property DAV:references, which provides backpointers from a target to all resources that refer to it. This property is live on servers that choose to support it. It may be present on resources on other servers, but in that case will be dead. Clients can use this property to discover which resources reference the target resource, and by parsing the URLs of the references, can discover the collections where those references reside and navigate up the collection hierarchy. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 16:24:13 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04141 for ; Tue, 15 Sep 1998 16:24:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13575; Tue, 15 Sep 1998 16:19:02 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 16:19:02 -0400 (EDT) Resent-Message-Id: <199809152019.QAA13575@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C63@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Tue, 15 Sep 1998 16:20:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: References and the Semantics of MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2072 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At IETF 42 it was suggested that the semantics of the DAV MOVE operation need to be modified for servers that support referencing. This change will be made to the Advanced Collections protocol specification unless objections are voiced. The change is as follows: Servers that support referencing MAY insert an additional step, called UPDATE, between the COPY and the DELETE of a MOVE operation. The UPDATE step updates the DAV:reftarget property of any references to the MOVED resource, if possible, to reflect its new location. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 17:42:33 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05508 for ; Tue, 15 Sep 1998 17:42:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14219; Tue, 15 Sep 1998 17:36:02 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 17:36:02 -0400 (EDT) Resent-Message-Id: <199809152136.RAA14219@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022486682000002L022*@MHS> Date: Tue, 15 Sep 1998 17:39:53 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2073 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This property may be impossible to support for a number of reasons. First its the same problem that makes maintaining referential integrity difficult and that has been deferred. Second, there may be significan performance consequences of trying to maintain the references. And third, creating a reference to a resource will require modification of the target resource to update its properties while that resource may not be updatable by the requesting principal. This is not a good reason for prohibiting a reference. I recommend that we keep things simple and not add the requirement. w3c-dist-auth-request@w3.org on 09/15/98 04:02:41 PM Please respond to w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Optional Backpointers from Targets to References There has been no discussion following Jim Davis's mailnote "Proposal: optional backpointers for ACR" of August 19. Unless there are objections, this proposal will be incorporated in the Advanced Collections protocol specification, and a corresponding requirement will be added to the Advanced Collections requirements. The requirement will state: There is an interoperable means of navigating from a resource that is the target of multiple references up the collection hierarchies from which it is referenced. The protocol specification will include: The definition of a new, optional property DAV:references, which provides backpointers from a target to all resources that refer to it. This property is live on servers that choose to support it. It may be present on resources on other servers, but in that case will be dead. Clients can use this property to discover which resources reference the target resource, and by parsing the URLs of the references, can discover the collections where those references reside and navigate up the collection hierarchy. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Sep 15 17:51:27 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA05630 for ; Tue, 15 Sep 1998 17:51:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14359; Tue, 15 Sep 1998 17:46:44 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 17:46:44 -0400 (EDT) Resent-Message-Id: <199809152146.RAA14359@www19.w3.org> Message-ID: <35FEDEA9.34803D9D@lyra.org> Date: Tue, 15 Sep 1998 14:39:53 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: Jim Amsden CC: w3c-dist-auth@w3.org References: <5040100022486682000002L022*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2074 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list However: 1) the property is optional. If it is tough for a particular implementation, then they can choose to not implement it 2) if the perf is too much, then a server can avoid it 3) if the property is implicit, then an real update may not be required. Given that some implementions can handle back-references without much problem, then it would be quite nice to be able to extract them. Especially if the server keeps telling you that you can't delete it because of other references. Without this, it would be quite a bear to find those other refs. -g Jim Amsden wrote: > > This property may be impossible to support for a number of reasons. First its > the same problem that makes maintaining referential integrity difficult and > that has been deferred. Second, there may be significan performance > consequences of trying to maintain the references. And third, creating a > reference to a resource will require modification of the target resource to > update its properties while that resource may not be updatable by the > requesting principal. This is not a good reason for prohibiting a reference. I > recommend that we keep things simple and not add the requirement. > > w3c-dist-auth-request@w3.org on 09/15/98 04:02:41 PM > Please respond to w3c-dist-auth-request@w3.org > To: w3c-dist-auth@w3.org > cc: > Subject: Optional Backpointers from Targets to References > > There has been no discussion following Jim Davis's mailnote "Proposal: > optional backpointers for ACR" of August 19. Unless there are > objections, this proposal will be incorporated in the Advanced > Collections protocol specification, and a corresponding requirement will > be added to the Advanced Collections requirements. > > The requirement will state: > > There is an interoperable means of navigating from a resource that is > the target of multiple references up the collection hierarchies from > which it is referenced. > > The protocol specification will include: > > The definition of a new, optional property DAV:references, which > provides backpointers from a target to all resources that refer to it. > > This property is live on servers that choose to support it. It may be > present on resources on other servers, but in that case will be dead. > > Clients can use this property to discover which resources reference the > target resource, and by parsing the URLs of the references, can discover > the collections where those references reside and navigate up the > collection hierarchy. > > Judith A. Slein > Xerox Corporation > jslein@crt.xerox.com > (716)422-5169 > 800 Phillips Road 105/50C > Webster, NY 14580 -- Greg Stein (gstein@lyra.org) From w3c-dist-auth-request@w3.org Tue Sep 15 18:02:48 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA05774 for ; Tue, 15 Sep 1998 18:02:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14552; Tue, 15 Sep 1998 17:57:56 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 17:57:56 -0400 (EDT) Resent-Message-Id: <199809152157.RAA14552@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <35FEE2F1.DC7FAF60@netscape.com> Date: Tue, 15 Sep 1998 14:58:10 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <5040100022486682000002L022*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2075 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Amsden wrote: > And third, creating a > reference to a resource will require modification of the target resource to > update its properties I don't believe that has to be a problem. The ACLs can be set up so that they specifically permit the backpointer property to be updated by the server. (Come to that, it's a live property, so write access may not mean very much in the first place.) -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |"But she calls her ship _Mercy of the | |francis@netscape.com | Goddess_!" "Kali." "Oh." | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 15 19:19:05 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA06352 for ; Tue, 15 Sep 1998 19:19:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15142; Tue, 15 Sep 1998 19:14:14 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 19:14:14 -0400 (EDT) Resent-Message-Id: <199809152314.TAA15142@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022493116000002L062*@MHS> Date: Tue, 15 Sep 1998 19:18:06 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2076 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list There are capabilities that can be optional, and others that if optional compromise the notion of a standard and render the protocol effectively server dependent. Providing optional back pointers (among many others in WebDAV) I think is going too far. This is too low-level and fundamental to be optional. Client applications will be impossible to write if not only do they have to deal with low-level protocols, methods with semantics hidden in control couples (headers), XML documents that must be parsed for results, etc., but they'll also have to adjust themselves to a myriad of server peculiarities. Too much of this will limit WebDAV's appeal due to the complexity of building servers to support it and clients to use it let alone a user's ability to understand those that are built. WebDAV should keep it simple and leave the complexity to the user's problem domain. My rule of thumb is when in doubt, leave it out. Another rule of thumb: if you have to describe the semantics of something in a series of special cases, there's something wrong with your abstraction. WebDAV is starting to reach this boundary. w3c-dist-auth-request@w3.org on 09/15/98 05:39:40 PM Please respond to w3c-dist-auth-request@w3.org To: Jim Amsden/Raleigh/IBM@ibmus cc: w3c-dist-auth@w3.org Subject: Re: Optional Backpointers from Targets to References However: 1) the property is optional. If it is tough for a particular implementation, then they can choose to not implement it 2) if the perf is too much, then a server can avoid it 3) if the property is implicit, then an real update may not be required. Given that some implementions can handle back-references without much problem, then it would be quite nice to be able to extract them. Especially if the server keeps telling you that you can't delete it because of other references. Without this, it would be quite a bear to find those other refs. -g Jim Amsden wrote: > > This property may be impossible to support for a number of reasons. First its > the same problem that makes maintaining referential integrity difficult and > that has been deferred. Second, there may be significan performance > consequences of trying to maintain the references. And third, creating a > reference to a resource will require modification of the target resource to > update its properties while that resource may not be updatable by the > requesting principal. This is not a good reason for prohibiting a reference. I > recommend that we keep things simple and not add the requirement. > > w3c-dist-auth-request@w3.org on 09/15/98 04:02:41 PM > Please respond to w3c-dist-auth-request@w3.org > To: w3c-dist-auth@w3.org > cc: > Subject: Optional Backpointers from Targets to References > > There has been no discussion following Jim Davis's mailnote "Proposal: > optional backpointers for ACR" of August 19. Unless there are > objections, this proposal will be incorporated in the Advanced > Collections protocol specification, and a corresponding requirement will > be added to the Advanced Collections requirements. > > The requirement will state: > > There is an interoperable means of navigating from a resource that is > the target of multiple references up the collection hierarchies from > which it is referenced. > > The protocol specification will include: > > The definition of a new, optional property DAV:references, which > provides backpointers from a target to all resources that refer to it. > > This property is live on servers that choose to support it. It may be > present on resources on other servers, but in that case will be dead. > > Clients can use this property to discover which resources reference the > target resource, and by parsing the URLs of the references, can discover > the collections where those references reside and navigate up the > collection hierarchy. > > Judith A. Slein > Xerox Corporation > jslein@crt.xerox.com > (716)422-5169 > 800 Phillips Road 105/50C > Webster, NY 14580 -- Greg Stein (gstein@lyra.org) From w3c-dist-auth-request@w3.org Tue Sep 15 19:21:13 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA06371 for ; Tue, 15 Sep 1998 19:21:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15204; Tue, 15 Sep 1998 19:16:38 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 19:16:38 -0400 (EDT) Resent-Message-Id: <199809152316.TAA15204@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022493270000002L002*@MHS> Date: Tue, 15 Sep 1998 19:20:30 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2077 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This will require ACLs on individual properties, something many servers may not do as it presents a significant administration burden compared to simple CRUD ACLs. ACLs for every user, on every resource, for each resource property, for every WebDAV method is not tractable. We are rapidly reaching a scaleability problem. w3c-dist-auth-request@w3.org on 09/15/98 05:51:01 PM Please respond to w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Optional Backpointers from Targets to References Jim Amsden wrote: > And third, creating a > reference to a resource will require modification of the target resource to > update its properties I don't believe that has to be a problem. The ACLs can be set up so that they specifically permit the backpointer property to be updated by the server. (Come to that, it's a live property, so write access may not mean very much in the first place.) -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |"But she calls her ship _Mercy of the | |francis@netscape.com | Goddess_!" "Kali." "Oh." | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 15 19:32:19 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA06483 for ; Tue, 15 Sep 1998 19:32:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15322; Tue, 15 Sep 1998 19:27:27 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 19:27:27 -0400 (EDT) Resent-Message-Id: <199809152327.TAA15322@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <35FEF7EF.B3C03E94@netscape.com> Date: Tue, 15 Sep 1998 16:27:43 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <5040100022493270000002L002*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2078 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Amsden wrote: > This will require ACLs on individual properties, Nope. The backpointer update doesn't have to pass through the same code path as PROPPATCH; it can call directly into the code that PROPPATCH calls, but bypass the ACL check. >> I don't believe that has to be a problem. The ACLs can be set up so that they >> specifically permit the backpointer property to be updated by the server. > -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |The good are innocent and create justice.| |francis@netscape.com |The bad are guilty, and invent mercy. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 15 20:09:20 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA06726 for ; Tue, 15 Sep 1998 20:09:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA15536; Tue, 15 Sep 1998 20:04:40 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 20:04:40 -0400 (EDT) Resent-Message-Id: <199809160004.UAA15536@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022496239000002L092*@MHS> Date: Tue, 15 Sep 1998 20:08:31 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2079 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Yet another special case. Pile all these up and you start getting problems. What if the target resource is versioned? Are you saying we can now add more special cases to let this property be changed on a versioned resource? Again, if the semantics have to be specified as a series of special cases, that's a good indication something is wrong, and usesr aren't likely to be able to remember all these cases. w3c-dist-auth-request@w3.org on 09/15/98 07:20:22 PM Please respond to w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Optional Backpointers from Targets to References Jim Amsden wrote: > This will require ACLs on individual properties, Nope. The backpointer update doesn't have to pass through the same code path as PROPPATCH; it can call directly into the code that PROPPATCH calls, but bypass the ACL check. >> I don't believe that has to be a problem. The ACLs can be set up so that they >> specifically permit the backpointer property to be updated by the server. > -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |The good are innocent and create justice.| |francis@netscape.com |The bad are guilty, and invent mercy. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 15 20:31:04 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA06975 for ; Tue, 15 Sep 1998 20:31:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA15654; Tue, 15 Sep 1998 20:26:24 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 20:26:24 -0400 (EDT) Resent-Message-Id: <199809160026.UAA15654@www19.w3.org> Message-Id: <3.0.5.32.19980915171836.0082a8b0@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 15 Sep 1998 17:18:36 PDT To: John Stracke , w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: <35FEF7EF.B3C03E94@netscape.com> References: <5040100022493270000002L002*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2080 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 04:27 PM 9/15/98 PDT, John Stracke wrote: >Jim Amsden wrote: > >> This will require ACLs on individual properties, I think there is some misunderstanding. First, the property will be server maintained, and hence exempt from access control. Second, no one was proposing to use ACLs on properties, except John, and I think he retracted that. Everyone agrees that backpointers have to be optional. Not all server implementors want this feature. But some server implementors want it very much. For some of them, it is both useful and cheap. It costs WebDAV nothing to define this property, so that all such servers can be interoperable. From w3c-dist-auth-request@w3.org Tue Sep 15 21:58:04 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA07574 for ; Tue, 15 Sep 1998 21:58:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA16344; Tue, 15 Sep 1998 21:46:02 -0400 (EDT) Resent-Date: Tue, 15 Sep 1998 21:46:02 -0400 (EDT) Resent-Message-Id: <199809160146.VAA16344@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022501123000002L032*@MHS> Date: Tue, 15 Sep 1998 21:49:50 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2081 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list But client applications relying on the option won't interoperate with servers that don't support it, so there isn't interoperability across WebDAV servers. I suggest a better solution is for those servers built on repository managers that can or need to support backpointers likely have specific client applications that choose to use them. These clients should use and maintain their own dead properties for this application specific function. That's what properties are for. This is really an issue of factoring out variability, separating it from the common protocol, and allowing client applications to implement and exploit it as necessary. Servers are also free to maintain whatever state they require in their persistent repositories in order to maintain their integrity. This does not need to, and often should not be exposed to client applications. Having said all this, I'm not all that opposed specifically to backpointers etc. I'm just concerned that WebDAV is rapidly reaching its complexity limit and we should make every effort to make sure we are only adding what is absolutely necessary. Servers are free to advertise their added value through additional live properties. But I don't think the protocol should attempt to standardize on a bunch of optional ones, especially based on speculation of how they might be used. Lets get some experience with DAV clients and servers before we add this stuff. w3c-dist-auth-request@w3.org on 09/15/98 08:19:24 PM Please respond to w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org, francis@netscape.com cc: Subject: Re: Optional Backpointers from Targets to References At 04:27 PM 9/15/98 PDT, John Stracke wrote: >Jim Amsden wrote: > >> This will require ACLs on individual properties, I think there is some misunderstanding. First, the property will be server maintained, and hence exempt from access control. Second, no one was proposing to use ACLs on properties, except John, and I think he retracted that. Everyone agrees that backpointers have to be optional. Not all server implementors want this feature. But some server implementors want it very much. For some of them, it is both useful and cheap. It costs WebDAV nothing to define this property, so that all such servers can be interoperable. From w3c-dist-auth-request@w3.org Wed Sep 16 09:26:55 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA20080 for ; Wed, 16 Sep 1998 09:26:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA21114; Wed, 16 Sep 1998 09:21:55 -0400 (EDT) Resent-Date: Wed, 16 Sep 1998 09:21:55 -0400 (EDT) Resent-Message-Id: <199809161321.JAA21114@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C65@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 16 Sep 1998 09:23:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: Ordered Collections: Position header in LOCK Requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2082 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It was pointed out at IETF 42 that LOCK can create a new resource in a collection. Consequently LOCK should have been in the list of methods that can have the Position header, to set the position of the new resource in the collection's ordering. This oversight will be corrected in the next revision of the Advanced Collections protocol spec. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Wed Sep 16 09:51:43 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA20572 for ; Wed, 16 Sep 1998 09:51:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA21354; Wed, 16 Sep 1998 09:46:42 -0400 (EDT) Resent-Date: Wed, 16 Sep 1998 09:46:42 -0400 (EDT) Resent-Message-Id: <199809161346.JAA21354@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C66@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 16 Sep 1998 09:48:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: DAV:orderingtype Property in the Advanced Collections Spec Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2083 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At IETF 42 it was suggested that the possible values of the DAV:orderingtype property (and so also of the Ordered request header) be changed to the following set: DAV:unordered -- this collection is not ordered DAV:custom -- this collection is ordered, but the semantics for its ordering is not being published href -- URI identifying the semantics of the ordering At IETF 42, it was proposed that an href value be treated primarily as an identifier of the semantics, rather than as a pointer to a location where a definition of the semantics can be found. It was suggested that the specification explicitly discourage clients from dereferencing the URI. The rationale for discouraging clients from dereferencing the URI is that a common practice of dereferencing these URIs could lead to unexpectedly heavy use of sites where ordering semantics are defined. My own feeling is that this consequence of dereferencing is unlikely. The only people likely to look up the semantics are people other than the owner of the collection who want to add members to it. The people who are allowed to do this are likely to be restricted, and are likely to know the semantics of the ordering anyway. But for the few cases where the person adding to the collection does not know the semantics of the ordering, being able to look up a definition can be extremely useful. I am willing to make the change, however, particularly since it only discourages clients from dereferencing the URI, and does not forbid doing so. Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Wed Sep 16 10:02:29 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20883 for ; Wed, 16 Sep 1998 10:02:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA21681; Wed, 16 Sep 1998 09:57:41 -0400 (EDT) Resent-Date: Wed, 16 Sep 1998 09:57:41 -0400 (EDT) Resent-Message-Id: <199809161357.JAA21681@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C67@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 16 Sep 1998 09:59:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Subject: ORDERPATCH in the Advanced Collections Specification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2084 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At IETF 42, the question was raised: What is the rationale for allowing only one change to an ordering per ORDERPATCH request? I believe that the rationale for this decision was that there may be existing DMSs that support only single changes per request, and that we should not require them to change in order to be compliant with the Ordering part of the Advanced Collections specification. We can certainly change this position if the consensus of the group is that it is too restrictive. An intermediate position might be that we define the ORDERPATCH request to support multiple changes per request, but don't require servers to accept requests with more than one change. Judith A. Slein CR&T/ADSTC jslein@crt.xerox.com 8*222-5169 From w3c-dist-auth-request@w3.org Wed Sep 16 12:58:19 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA25926 for ; Wed, 16 Sep 1998 12:58:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA24318; Wed, 16 Sep 1998 12:53:05 -0400 (EDT) Resent-Date: Wed, 16 Sep 1998 12:53:05 -0400 (EDT) Resent-Message-Id: <199809161653.MAA24318@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host [131.107.88.59] claimed to be dfssl.exchange.microsoft.com Message-ID: <2FBF98FC7852CF11912A000000000001090F5AEC@DINO> From: "Lisa Lippert (Dusseault) (Exchange)" To: "'Jim Amsden'" , w3c-dist-auth@w3.org Date: Wed, 16 Sep 1998 09:52:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2085 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list A couple possible solutions to the issue you present Jim... 1. Such granular properties can be tractable if good inheritance is defined and used. Most properties may have the same ACLs as the resource they are on. Most resources may have more or less the same ACLs as their parent collections. This cuts down a great deal on storage, at least. 2. Properties that are "read-only" need not be marked as such by ACLs. "read-only" means that nobody can write to the property, therefore no write ACLs are necessary. If the system calculates the property and changes it that's fine -- that's not covered by ACLs. So John invoking ACLs may have been just a short form for "the server can control write access to the property on all resources" not necessarily "create an access control entry on the property on this resource". I'm putting words into your mouth John, so correct me if I'm wrong. Lisa -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, September 15, 1998 4:21 PM To: w3c-dist-auth@w3.org Subject: Re: Optional Backpointers from Targets to References This will require ACLs on individual properties, something many servers may not do as it presents a significant administration burden compared to simple CRUD ACLs. ACLs for every user, on every resource, for each resource property, for every WebDAV method is not tractable. We are rapidly reaching a scaleability problem. w3c-dist-auth-request@w3.org on 09/15/98 05:51:01 PM Please respond to w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Optional Backpointers from Targets to References Jim Amsden wrote: > And third, creating a > reference to a resource will require modification of the target resource to > update its properties I don't believe that has to be a problem. The ACLs can be set up so that they specifically permit the backpointer property to be updated by the server. (Come to that, it's a live property, so write access may not mean very much in the first place.) -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |"But she calls her ship _Mercy of the | |francis@netscape.com | Goddess_!" "Kali." "Oh." | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Wed Sep 16 13:52:07 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA27229 for ; Wed, 16 Sep 1998 13:52:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA26160; Wed, 16 Sep 1998 13:46:57 -0400 (EDT) Resent-Date: Wed, 16 Sep 1998 13:46:57 -0400 (EDT) Resent-Message-Id: <199809161746.NAA26160@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: "'WebDAV'" Date: Wed, 16 Sep 1998 10:29:11 -0700 Message-ID: <000b01bde197$845de820$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <201BB34B3A73D1118C1F00805F1582E8B76C66@x-wb-0128-nt8.wrc.xerox.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: RE: orderingtype Property in the Advanced Collections Spec Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2086 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > My own feeling is that this consequence of dereferencing is unlikely. > The only people likely to look up the semantics are people other than > the owner of the collection who want to add members to it. The people > who are allowed to do this are likely to be restricted, and are likely > to know the semantics of the ordering anyway. I recommended this change. My concern was that people might want to express the ordering in a machine-readable format, and this would then lead to widespread downloading of the machine-readable ordering semantics from one URL, overloading this URL. - Jim From w3c-dist-auth-request@w3.org Wed Sep 16 14:09:42 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA27475 for ; Wed, 16 Sep 1998 14:09:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA26417; Wed, 16 Sep 1998 14:04:25 -0400 (EDT) Resent-Date: Wed, 16 Sep 1998 14:04:25 -0400 (EDT) Resent-Message-Id: <199809161804.OAA26417@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: WEBDAV WG Date: Wed, 16 Sep 1998 10:59:27 -0700 Message-ID: <001401bde19b$bf58f2e0$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <201BB34B3A73D1118C1F00805F1582E8B76C67@x-wb-0128-nt8.wrc.xerox.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: RE: ORDERPATCH in the Advanced Collections Specification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2087 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > At IETF 42, the question was raised: What is the rationale for allowing > only one change to an ordering per ORDERPATCH request? > > I believe that the rationale for this decision was that there may be > existing DMSs that support only single changes per request, and that we > should not require them to change in order to be compliant with the > Ordering part of the Advanced Collections specification. That these systems don't natively support multiple order changes per request isn't necessarily sufficient reason to prevent multiple requests from being submitted in an ORDERPATCH. Since the semantics of ORDERPATCH are being implemented by some DAV layer, rather than directly by the document management system, it is quite possible that the DAV layer could implement multiple order changes per ORDERPATCH even if the document management system can't perform this functionality in a single operation. In fact, since WebDAV servers support locking a collection (to implement LOCK), a DAV layer could lock the collection, then perform multiple individual order change operations, then unlock the collection. It might be difficult to implement all-or-nothing semantics with this approach (i.e., perform all these order changes or perform none of the order changes), which is why I suggest making the semantics best effort. - Jim From w3c-dist-auth-request@w3.org Thu Sep 17 15:41:03 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA18701 for ; Thu, 17 Sep 1998 15:41:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12503; Thu, 17 Sep 1998 15:35:15 -0400 (EDT) Resent-Date: Thu, 17 Sep 1998 15:35:15 -0400 (EDT) Resent-Message-Id: <199809171935.PAA12503@www19.w3.org> Message-ID: <918C79AB552BD211A2BD00805F15CE8512CC72@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: IETF-IPP Cc: IETF-FAX , IETF-HTTP , IETF-WebDAV , wg-chairs@apps.ietf.org Date: Thu, 17 Sep 1998 12:29:05 PDT MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: IPP DL, FTP and Web services back up Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2088 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list All, The IPP DL and partly also the FTP and Web services for the IPP WG has been down or only sporadically working for the last few weeks, due to a change of server and hosting organization. Everything is now back to full working order under the earlier names: IPP DL: mailto://ipp@pwg.org IPP Web: http://www.pwg.org/ipp FTP Arch: ftp://ftp.pwg.org/pub/pwg/ipp/ If you did send a message to the IPP DL during the last two weeks, it might have ended up in the bit bucket and never reached the IPP DL members, please resend. Apologies for any inconveniences this might have caused you. Carl-Uno Manros Chair of the IPP WG From w3c-dist-auth-request@w3.org Thu Sep 17 16:27:44 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA19991 for ; Thu, 17 Sep 1998 16:27:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13294; Thu, 17 Sep 1998 16:23:17 -0400 (EDT) Resent-Date: Thu, 17 Sep 1998 16:23:17 -0400 (EDT) Resent-Message-Id: <199809172023.QAA13294@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-46.netscape.com [205.217.237.46] claimed to be netscape.com Message-ID: <36016FAD.85DE47E6@netscape.com> Date: Thu, 17 Sep 1998 13:23:09 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: WEBDAV WG References: <001401bde19b$bf58f2e0$d115c380@galileo.ics.uci.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: ORDERPATCH in the Advanced Collections Specification Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2089 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Whitehead wrote: > Since the semantics of ORDERPATCH are being > implemented by some DAV layer, rather than directly by the document > management system, it is quite possible that the DAV layer could implement > multiple order changes per ORDERPATCH Right--and (IMHO) this would be much better than forcing the clients to do it instead. The server can fake it more efficiently than the client can (if the client has to issue one ORDERPATCH per change), and some servers won't have to fake it at all. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | Round up the usual disclaimers. | |francis@netscape.com | | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Thu Sep 17 16:40:47 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA20156 for ; Thu, 17 Sep 1998 16:40:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13518; Thu, 17 Sep 1998 16:36:16 -0400 (EDT) Resent-Date: Thu, 17 Sep 1998 16:36:16 -0400 (EDT) Resent-Message-Id: <199809172036.QAA13518@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <360172B7.E5CB6A66@netscape.com> Date: Thu, 17 Sep 1998 13:36:07 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <5040100022493270000002L002*@MHS> <3.0.5.32.19980915171836.0082a8b0@mailback.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2091 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Davis wrote: > Second, no one was > proposing to use ACLs on properties, except John, and I think he retracted > that. Yeah, that was just sloppy language on my part. -- /=====================================================================\ |John (Francis) Stracke |My opinions are my own. |"Hastur was para-| |Software Retrophrenologist|========================/ noid, which was | |Netscape Comm. Corp. |simply a sensible...well-adjusted reaction| |francis@netscape.com | to living in Hell." -- _Good Omens_ | \=====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Thu Sep 17 16:40:59 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA20168 for ; Thu, 17 Sep 1998 16:40:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13480; Thu, 17 Sep 1998 16:35:26 -0400 (EDT) Resent-Date: Thu, 17 Sep 1998 16:35:26 -0400 (EDT) Resent-Message-Id: <199809172035.QAA13480@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <36017281.D8331B45@netscape.com> Date: Thu, 17 Sep 1998 13:35:13 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <5040100022496239000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2090 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Amsden wrote: > Yet another special case. Pile all these up and you start getting problems. > What if the target resource is versioned? Are you saying we can now add more > special cases to let this property be changed on a versioned resource? It's a *live property*. That's the only special case here. It doesn't have the same semantics as a dead property; it doesn't even have to be *stored* like a dead property; it can be generated on the fly, like a CGI script. If the resource in question is a frozen revision, fine; the "preserve all properties on frozen revisions" requirement doesn't make sense for live properties, certainly not ones which are derived from the states of other resources. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | If you're omniscient, how do you know? | |francis@netscape.com | | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Thu Sep 17 16:41:57 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA20184 for ; Thu, 17 Sep 1998 16:41:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13562; Thu, 17 Sep 1998 16:37:12 -0400 (EDT) Resent-Date: Thu, 17 Sep 1998 16:37:12 -0400 (EDT) Resent-Message-Id: <199809172037.QAA13562@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <360172F0.15B88D11@netscape.com> Date: Thu, 17 Sep 1998 13:37:05 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <5040100022501123000002L032*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2092 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Amsden wrote: > But client applications relying on the option won't interoperate with servers > that don't support it, so there isn't interoperability across WebDAV servers. I > suggest a better solution is for those servers built on repository managers > that can or need to support backpointers likely have specific client > applications that choose to use them. Choke. And what happens when one of these clients tries to coexist with a client that doesn't support backpointers? -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |There are footprints on the moon. No | |francis@netscape.com | feet, just footprints. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Thu Sep 17 16:42:28 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA20195 for ; Thu, 17 Sep 1998 16:42:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA13603; Thu, 17 Sep 1998 16:37:52 -0400 (EDT) Resent-Date: Thu, 17 Sep 1998 16:37:52 -0400 (EDT) Resent-Message-Id: <199809172037.QAA13603@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <36017319.D237CC01@netscape.com> Date: Thu, 17 Sep 1998 13:37:45 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <2FBF98FC7852CF11912A000000000001090F5AEC@DINO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2093 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list "Lisa Lippert (Dusseault) (Exchange)" wrote: > So John invoking ACLs may have > been just a short form for "the server can control write access to the > property on all resources" not necessarily "create an access control entry > on the property on this resource". I'm putting words into your mouth John, > so correct me if I'm wrong. No, that is what I meant. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |There are footprints on the moon. No | |francis@netscape.com | feet, just footprints. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Fri Sep 18 11:06:28 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04611 for ; Fri, 18 Sep 1998 11:06:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27137; Fri, 18 Sep 1998 11:00:28 -0400 (EDT) Resent-Date: Fri, 18 Sep 1998 11:00:28 -0400 (EDT) Resent-Message-Id: <199809181500.LAA27137@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022612384000002L042*@MHS> Date: Fri, 18 Sep 1998 11:03:24 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2094 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The client applications using backpointers know what the property is and that it is a live property supported by the particular server. Clients that don't use backpointers would ignore or just not use the property even though that particular server was maintaining them. This is typical of any client application that uses some specific meta-data of its own. The only thing unique is that the server is maintaining it as a live property. w3c-dist-auth-request@w3.org on 09/17/98 04:29:50 PM Please respond to w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Optional Backpointers from Targets to References Jim Amsden wrote: > But client applications relying on the option won't interoperate with servers > that don't support it, so there isn't interoperability across WebDAV servers. I > suggest a better solution is for those servers built on repository managers > that can or need to support backpointers likely have specific client > applications that choose to use them. Choke. And what happens when one of these clients tries to coexist with a client that doesn't support backpointers? -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |There are footprints on the moon. No | |francis@netscape.com | feet, just footprints. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Fri Sep 18 16:31:45 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA07187 for ; Fri, 18 Sep 1998 16:31:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA03141; Fri, 18 Sep 1998 16:26:24 -0400 (EDT) Resent-Date: Fri, 18 Sep 1998 16:26:24 -0400 (EDT) Resent-Message-Id: <199809182026.QAA03141@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C6E@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'Lisa Lippert (Dusseault) (Exchange)'" , "'WebDAV'" Cc: slein@wrc.xerox.com Date: Fri, 18 Sep 1998 16:24:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: References and Access Control (was, RE: Adv. Coll. items from the 42nd IETF) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2095 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree if you meant to say *even direct* references need separate access control lists. As long as there are any operations that affect the reference itself (and we are proposing that DELETE, MOVE, and COPY do affect the reference itself, even for direct references), access control makes sense for the reference. We distinguished references along 2 axes: direct / indirect, strong / weak. Strong / weak has to do only with whether the server undertakes to insure referential integrity. I don't see how the strong / weak distinction has any implications for access control lists. --Judy Judith A. Slein CR&T/ADSTC jslein@crt.xerox.com 8*222-5169 > -----Original Message----- > From: Lisa Lippert (Dusseault) (Exchange) > [mailto:lisadu@exchange.microsoft.com] > Sent: Tuesday, September 15, 1998 3:47 PM > To: 'Slein, Judith A'; 'Jim Amsden'; 'WebDAV' > Cc: slein@wrc.xerox.com > Subject: RE: References and Access Control (was, RE: Adv. Coll. items > from the 42nd IETF) > > > Even strong references require some kind of separate access > control list. > You need to be able to specify who can delete the strong > reference, and it > may not be the same list of principals that can delete the > resource referred > to. > > I'm not clear whether all possible operations on references, > strong or weak, > need their own access control. > > Lisa > > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Tuesday, September 15, 1998 12:07 PM > To: 'Jim Amsden'; 'WebDAV' > Cc: slein@wrc.xerox.com > Subject: References and Access Control (was, RE: Adv. Coll. items from > the 42nd IETF) > > > >Jim Amsden wrote: > > > > 3. Issue: Should access control of references be distinct from those > > of target? > > > > Yes. SQL views are a good example of a similar concept. > > This seems right to me. At least indirect references are resources, > with their own URLs, to which HTTP and WebDAV can be applied, > which bear > properties, etc. So access control should certainly apply to > them just > as to any other resource. > > Direct references are less clear, but they get created > independently of > their targets, deleted independently of their targets, and some subset > of HTTP / WebDAV methods affect them, so it seems as if they, too, > should have access control separate from their targets. > > > > > 4. Issue: Should the owner of a resource should be able to > > prevent creation of > > references to it via ACL? This would affect requirements for > > ACL, not ACR. > > > > No, creating a reference to a resource should only require > > read access to the > > resource. In general, the ACL scheme needs to be simplified > > from ACLs on every > > DAV method to ACLs on the effect the DAV method has on the > > state of the > > resource. Basically CRUD plus Execute like in most > operating systems. > > > > This is not so clear. The discussion of Strong References at Redmond > revealed some security risks that might lead us to conclude > that we want > access control on the creation of references. For example, > one way for > a server to preserve referential integrity for DELETE operations is to > refuse to delete the target as long as there are any references to it. > On a server that uses this approach, the owner of any resource who > wanted to be sure he could always delete it might want to restrict > permissions to create (strong) references to it. > > Judith A. Slein > Xerox Corporation > jslein@crt.xerox.com > (716)422-5169 > 800 Phillips Road 105/50C > Webster, NY 14580 > > From w3c-dist-auth-request@w3.org Fri Sep 18 16:39:41 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA07242 for ; Fri, 18 Sep 1998 16:39:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA03238; Fri, 18 Sep 1998 16:34:45 -0400 (EDT) Resent-Date: Fri, 18 Sep 1998 16:34:45 -0400 (EDT) Resent-Message-Id: <199809182034.QAA03238@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C6F@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "Slein, Judith A" , "'WebDAV'" Date: Fri, 18 Sep 1998 16:34:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Direct References in the Advanced Collections Requirements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2096 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list We are still wrestling with the terminology for this distinction. I've had objections in private correspondence to Client-Side / Server-Side, because they seem to imply something about the location of the requester that irrelevant to the distinction we are trying to make. Here are a couple of other possible pairs of terms: Transparent Reference (one that the user agent can see) / Opaque Reference (one that is hidden from the user agent) Visible Reference / Hidden Reference Manual Reference (one that the user agent has to dereference) / Automatic Reference (one that is dereferenced automatically with no action by the user agent needed) Or stick with Indirect Reference / Direct Reference Any preferences among these, or other suggestions? Judith A. Slein CR&T/ADSTC jslein@crt.xerox.com 8*222-5169 > -----Original Message----- > From: Slein, Judith A > Sent: Tuesday, September 15, 1998 3:24 PM > To: 'WebDAV' > Cc: Slein, Judith A > Subject: Direct References in the Advanced Collections > Requirements > > I would like to propose the following changes to the Advanced > Collections Requirements. > > 1. The requirements will use the following terminology and > definitions instead of the current indirect / direct > references terminology: > > Client-Side Reference: A reference that must be resolved by > the client. Any method applied to a Client-Side Reference > affects the reference only, not its target. To affect the > target of a Client-Side reference, the client must resolve > the reference and operate directly on its target. > > Server-Side Reference: A reference whose existence is, in > general, hidden from the client. For the most part, methods > applied to a Server-Side Reference affect its target, not the > reference itself. The server resolves the reference and > applies the method to its target. > > Rationale: Roy Fielding has been requesting for some time > that we change the terminology. This is in part an attempt > to satisfy his request. In addition, the current > requirements document defines a Server-Side Reference as one > for which all operations are passed through to its target. > It is clear from the discussion at IETF 42 that this > definition is too strong. It was proposed there that DELETE, > COPY, and MOVE are not passed through to the target. I would > like *not* to make a commitment in the requirements about > exactly which operations get passed through and which do not, > but still express the general intent of Server-Side > References. For most operations, they give a client the > impression that it is operating directly on the target, > hiding the existence of the reference from the client. > > 2. The requirements will give the following rationale for > supporting both sorts of reference. > > Client-Side References provide the basic benefits desired > from referencing: They allow multiple collections, on the > same or different servers, to share a single resource, in > such a way that any change to the resource will automatically > be reflected in the collections that contain it by reference. > They provide this benefit at very low cost to the server, > and with no security implications. > > Server-Side References hide the existence of the reference > from the client, thus simplifying for the client operations > through the reference, and making them more efficient. Fewer > round trips are required to accomplish the same task than > with Client-Side References. Servers already support > server-side references, generally through configuration > files; exposing this capability through the protocol seems desirable. > > Judith A. Slein > Xerox Corporation > jslein@crt.xerox.com > (716)422-5169 > 800 Phillips Road 105/50C > Webster, NY 14580 > From w3c-dist-auth-request@w3.org Fri Sep 18 16:56:21 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA07395 for ; Fri, 18 Sep 1998 16:56:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA03487; Fri, 18 Sep 1998 16:51:40 -0400 (EDT) Resent-Date: Fri, 18 Sep 1998 16:51:40 -0400 (EDT) Resent-Message-Id: <199809182051.QAA03487@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-46.netscape.com [205.217.237.46] claimed to be netscape.com Message-ID: <3602C7D4.73D318A0@netscape.com> Date: Fri, 18 Sep 1998 13:51:33 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: "'WebDAV'" References: <201BB34B3A73D1118C1F00805F1582E8B76C6F@x-wb-0128-nt8.wrc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Direct References in the Advanced Collections Requirements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2097 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list "Slein, Judith A" wrote: > We are still wrestling with the terminology for this distinction. I've had > objections in private correspondence to Client-Side / Server-Side, because > they seem to imply something about the location of the requester that > irrelevant to the distinction we are trying to make. I disagree on this point, actually; in the HTTP conversation, the entity issuing the request is the client by definition, regardless of where that entity is running. > Or stick with Indirect Reference / Direct Reference I still prefer these two, myself; I'd go along with Client-Side/Server-Side, but the others seem too contrived. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | Organ transplants are best left to the | |francis@netscape.com | professionals. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Fri Sep 18 21:31:04 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA09920 for ; Fri, 18 Sep 1998 21:31:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA05877; Fri, 18 Sep 1998 21:26:29 -0400 (EDT) Resent-Date: Fri, 18 Sep 1998 21:26:29 -0400 (EDT) Resent-Message-Id: <199809190126.VAA05877@www19.w3.org> To: "Slein, Judith A" cc: "'WebDAV'" In-reply-to: Your message of "Fri, 18 Sep 1998 16:34:10 EDT." <201BB34B3A73D1118C1F00805F1582E8B76C6F@x-wb-0128-nt8.wrc.xerox.com> Date: Fri, 18 Sep 1998 18:16:29 -0700 From: "Roy T. Fielding" Message-ID: <9809181816.aa03999@paris.ics.uci.edu> Subject: Re: Direct References in the Advanced Collections Requirements Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2098 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list My problem with Indirect Reference / Direct Reference is that an indirect reference in the general terms of computer assembly languages means exactly what WebDAV-AC is calling a Direct Reference, thus reversing the definition of (what used to be) a commonly understood term. My preference would be to use terms that correspond to the nature of the resource being defined. Oddly enough, the best fit would be redirect reference / indirect reference but I wouldn't be surprised at the confusion that would result from swapping the association of indirect reference. That is why I suggested reference / alias since that at least uses two commonly understood names consistently. I am not concerned with the precise fit with Apache's config language, since we have many different configuration directives that allow the definition of the conceptual equivalent of aliases. Client-Side / Server-Side is a bit confusing since it has more to do with the effect of accessing the resource than the resource itself, though I do prefer it over the current definitions. >Transparent Reference (one that the user agent can see) / Opaque Reference >(one that is hidden from the user agent) > >Visible Reference / Hidden Reference > >Manual Reference (one that the user agent has to dereference) / Automatic >Reference (one that is dereferenced automatically with no action by the user >agent needed) All of these are moving in the wrong direction in terms of understanding the specification. I would prefer Reference / Alias over anything that overemphasized information hiding. BTW, thanks for organizing the discussion -- it really helps to clarify the issues. ....Roy From w3c-dist-auth-request@w3.org Fri Sep 18 21:45:44 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA10017 for ; Fri, 18 Sep 1998 21:45:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA06003; Fri, 18 Sep 1998 21:41:10 -0400 (EDT) Resent-Date: Fri, 18 Sep 1998 21:41:10 -0400 (EDT) Resent-Message-Id: <199809190141.VAA06003@www19.w3.org> To: "Slein, Judith A" cc: "'WebDAV'" In-reply-to: Your message of "Tue, 15 Sep 1998 16:11:28 EDT." <201BB34B3A73D1118C1F00805F1582E8B76C62@x-wb-0128-nt8.wrc.xerox.com> Date: Fri, 18 Sep 1998 18:31:31 -0700 From: "Roy T. Fielding" Message-ID: <9809181831.aa05711@paris.ics.uci.edu> Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2099 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I doubt that unrestricted backpointers to collection parents will be implementable on general web servers, but I have no objection to defining an optional backpointer property provided that it is also mentioned that such a property is not a very good way to implement scalable systems. I would expect any system that implemented such a thing would restrict the backpointers to references within the same object repository (whatever serves as the server backend). The same functionality can be accomplished via a DASL query, regardless of how the server backend works, which has the advantage of specifying the scope of the query. So, I don't think directly specifying a property to hold that information should imply that the property is maintained live. OTOH, I'm not sure how the response to such a DASL query would look like (i.e., if it would need DAV:references itself). ....Roy From w3c-dist-auth-request@w3.org Fri Sep 18 21:56:18 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA10112 for ; Fri, 18 Sep 1998 21:56:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA06110; Fri, 18 Sep 1998 21:51:52 -0400 (EDT) Resent-Date: Fri, 18 Sep 1998 21:51:52 -0400 (EDT) Resent-Message-Id: <199809190151.VAA06110@www19.w3.org> To: John Stracke cc: WebDAV WG In-reply-to: Your message of "Mon, 14 Sep 1998 17:26:56 PDT." <35FDB44F.C6AC0458@netscape.com> Date: Fri, 18 Sep 1998 18:47:25 -0700 From: "Roy T. Fielding" Message-ID: <9809181847.aa07536@paris.ics.uci.edu> Subject: Re: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2100 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Yeah, but then you can't use the same URI for authoring as for browsing, >in which case you might as well author via FTP. I've been meaning to get back to this comment all week. Using the same URI for authoring as for browsing should not be considered an "advantage" of WebDAV. In fact, it isn't an advantage at all. The real advantage of WebDAV is that it is able to respond accurately when a user attempts to modify a derived resource instead of the source, and is able to control access to its namespace via an authentication mechanism that is not based on login names. Assuming the URI would be the same for both authoring and retrieving of resources is contrary to good site design, wherein the name assigned to a resource is independent of its implementation. The Web is not a distributed file system, a fact that has a whole set of advantages and disadvantages. However, I'd hope that a WebDAV capable system would not puke and die if it was given a redirect to the source resource that happened to be an ftp URL. I'm not saying that clients should be required to support such authoring modes, but there are countless reasons why it would be a good idea. ....Roy From w3c-dist-auth-request@w3.org Mon Sep 21 12:54:57 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA20914 for ; Mon, 21 Sep 1998 12:54:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA00432; Mon, 21 Sep 1998 12:48:43 -0400 (EDT) Resent-Date: Mon, 21 Sep 1998 12:48:43 -0400 (EDT) Resent-Message-Id: <199809211648.MAA00432@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-46.netscape.com [205.217.237.46] claimed to be netscape.com Message-ID: <36068357.643B7B88@netscape.com> Date: Mon, 21 Sep 1998 09:48:24 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG References: <9809181847.aa07536@paris.ics.uci.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Namespace consistency Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2101 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list "Roy T. Fielding" wrote: > >Yeah, but then you can't use the same URI for authoring as for browsing, > >in which case you might as well author via FTP. > > I've been meaning to get back to this comment all week. Using the same > URI for authoring as for browsing should not be considered an "advantage" > of WebDAV. In fact, it isn't an advantage at all. Of *course* it is! If you have an authoring tool that's integrated with your browser (at least to the extent of being able to send it "go to this URI" commands), that's going to make it a *lot* easier to test the content you've developed. If the browser can't use the same URI as the authoring tool, then you're going to have to do the translation by hand (which is essentially what I have to do with Netscape Composer today, since my ISP doesn't support HTTP PUT), or else teach the authoring tool to remap URIs that it sends to the browser (possible, but messy). -- /======================================================================\ |John (Francis) Stracke |My opinions are my own.| S/MIME supported | |Software Retrophrenologist|===========================================| |Netscape Comm. Corp. |Id est fabula nostra, et non mutabimus eam!| |francis@netscape.com | --House Falconguard and Affiliated Scum | \======================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Mon Sep 21 16:10:17 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA24097 for ; Mon, 21 Sep 1998 16:10:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05273; Mon, 21 Sep 1998 16:04:29 -0400 (EDT) Resent-Date: Mon, 21 Sep 1998 16:04:29 -0400 (EDT) Resent-Message-Id: <199809212004.QAA05273@www19.w3.org> X-Authentication-Warning: sophia.inria.fr: Host pasiphae.xerox.com [208.140.33.23] claimed to be pasiphae.eastgw.xerox.com Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76C73@x-wb-0128-nt8.wrc.xerox.com> From: "Slein, Judith A" To: "'Roy T. Fielding'" Cc: "'WebDAV'" Date: Mon, 21 Sep 1998 15:48:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2102 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@kiwi.ics.uci.edu] > Sent: Friday, September 18, 1998 9:32 PM > To: Slein, Judith A > Cc: 'WebDAV' > Subject: Re: Optional Backpointers from Targets to References > > > I doubt that unrestricted backpointers to collection parents will be > implementable on general web servers, but I have no objection > to defining > an optional backpointer property provided that it is also > mentioned that > such a property is not a very good way to implement scalable systems. Could you be more specific about the kinds of scalability problems you envision? > The same functionality can be accomplished via a DASL query, > regardless > of how the server backend works, which has the advantage of specifying > the scope of the query. So, I don't think directly specifying > a property to hold that information should imply that the property is > maintained live. OTOH, I'm not sure how the response to such a DASL > query would look like (i.e., if it would need DAV:references itself). > You are thinking the query would be: Find the resources on server S that have DAV:reftarget = T? This is certainly possible in cases where the client has a certain list of servers that it cares about. This includes the case that motivated the suggestion about backpointers in the first place -- DMSs. It's less useful for more open-ended cases like the client just trying to find out who would be affected if it deletes a resource. It does seem to me that the property should be live if it exists at all. Otherwise the property value will just be unreliable, since some clients that create references may maintain it while others do not. --Judy From w3c-dist-auth-request@w3.org Tue Sep 22 11:10:18 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA11745 for ; Tue, 22 Sep 1998 11:10:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA17812; Tue, 22 Sep 1998 11:05:13 -0400 (EDT) Resent-Date: Tue, 22 Sep 1998 11:05:13 -0400 (EDT) Resent-Message-Id: <199809221505.LAA17812@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022664299000002L092*@MHS> Date: Tue, 22 Sep 1998 11:08:36 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Direct References in the Advanced Collections Requiremen Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2105 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Reading through a reference to the target or not has nothing to do with client and server or communication for that matter. Either party in the communication might want to do both at one time or another. w3c-dist-auth-request@w3.org on 09/18/98 04:44:11 PM Please respond to w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Direct References in the Advanced Collections Requiremen "Slein, Judith A" wrote: > We are still wrestling with the terminology for this distinction. I've had > objections in private correspondence to Client-Side / Server-Side, because > they seem to imply something about the location of the requester that > irrelevant to the distinction we are trying to make. I disagree on this point, actually; in the HTTP conversation, the entity issuing the request is the client by definition, regardless of where that entity is running. > Or stick with Indirect Reference / Direct Reference I still prefer these two, myself; I'd go along with Client-Side/Server-Side, but the others seem too contrived. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | Organ transplants are best left to the | |francis@netscape.com | professionals. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 22 13:54:25 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA18226 for ; Tue, 22 Sep 1998 13:54:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA21827; Tue, 22 Sep 1998 13:49:38 -0400 (EDT) Resent-Date: Tue, 22 Sep 1998 13:49:38 -0400 (EDT) Resent-Message-Id: <199809221749.NAA21827@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-46.netscape.com [205.217.237.46] claimed to be netscape.com Message-ID: <3607E322.41885B82@netscape.com> Date: Tue, 22 Sep 1998 10:49:23 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <5040100022664299000002L092*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Direct References in the Advanced Collections Requiremen Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2106 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Amsden wrote: > Reading through a reference to the target or not has nothing to do with client > and server or communication for that matter. How could that be? The HTTP client issues a request to the server (by definition: the client is the one that issues a request), and then either (a) the server applies that request to the reference's target, or (b) the server tells the client what the target is, and the client reissues the request for the new URI. Case (a), the reference is dereferenced on the server side; case (b), it's dereferenced on the client side. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | Life is like a metaphor. | |francis@netscape.com | | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 22 14:48:59 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA19808 for ; Tue, 22 Sep 1998 14:48:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA23591; Tue, 22 Sep 1998 14:44:26 -0400 (EDT) Resent-Date: Tue, 22 Sep 1998 14:44:26 -0400 (EDT) Resent-Message-Id: <199809221844.OAA23591@www19.w3.org> Message-Id: <3.0.3.32.19980922114318.00929700@mailback.parc.xerox.com> X-Sender: jdavis@mailback.parc.xerox.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 22 Sep 1998 11:43:18 PDT To: From: Jim Davis In-Reply-To: <5040100022486682000002L022*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2107 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim Amsden and other have asked me to explain the usefulness of the backpointer. Before I do, I want to emphasize that I am well aware that there are many reasons why a server couldn't or shouldn't provide backpointers from *all* targets to *all* references. I hope here only to show that there are *some* applications for which this is useful, and then to argue that it's worthwhile standardizing the protocol so that applications that *do* use this feature will have a standard way to access it on those servers that happen to provide it. Reasons it is useful: 1) Referential integrity. Some applications desire references that are guarenteed to remain valid, even when the target moves. The easiest way to do accomplish this is by storing back pointers from the target to the reference. While there is no requirement that the backpointer be exposed in the interface, there is no harm in doing so. 2) Multiple containment. Some document management systems have an abstract notion of a 'document' that can be in many 'folders'. For any such document, it is sometimes necessary to obtain the set of folders in which it appears. The most direct mapping of these abstractions to WebDAV (assuming Advanced Collection Resources) is: folder :: WebDAV collection document :: WebDAV resource containment :: WebDAV reference That is, if document D is in folder F, there is a reference resource in F whose target is D. Then, to find the set of all folders {F, G, H...} that contain document D, one first obtains the set of backpointers on D, then (trivially) obtains the set of collections that contain those references. 3) Generality/Extensibility: Backpointers are used in countless data structures (consult any textbook on data structured or algorithms). There will certainly be uses we can't anticipate now. The 'multiple containment' example above is just the first one. I hope to have demonstrated the usefulness of the dav:references property. It will be optional, and hence cost-free, but useful to those applications and servers who need it. From w3c-dist-auth-request@w3.org Tue Sep 22 15:04:53 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA20198 for ; Tue, 22 Sep 1998 15:04:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA24034; Tue, 22 Sep 1998 15:00:23 -0400 (EDT) Resent-Date: Tue, 22 Sep 1998 15:00:23 -0400 (EDT) Resent-Message-Id: <199809221900.PAA24034@www19.w3.org> From: Jim Amsden To: Message-ID: <5040100022685923000002L032*@MHS> Date: Tue, 22 Sep 1998 15:03:46 -0400 MIME-Version: 1.0 Content-Type: text/plain Subject: Re: Direct References in the Advanced Collections Requiremen Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2108 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I think we're agreeing here, its just a problem of perspective. In you description below, both the client and server might effectively "read through" the reference depending on the request. I'm only trying to suggest that the important issue is if the reference is read through or not, not what role a piece of code is playing in a client/server architecture. This is because some implementations of WebDAV may not be client/server. w3c-dist-auth-request@w3.org on 09/22/98 01:42:16 PM Please respond to w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Direct References in the Advanced Collections Requiremen Jim Amsden wrote: > Reading through a reference to the target or not has nothing to do with client > and server or communication for that matter. How could that be? The HTTP client issues a request to the server (by definition: the client is the one that issues a request), and then either (a) the server applies that request to the reference's target, or (b) the server tells the client what the target is, and the client reissues the request for the new URI. Case (a), the reference is dereferenced on the server side; case (b), it's dereferenced on the client side. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | Life is like a metaphor. | |francis@netscape.com | | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Tue Sep 22 17:18:54 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA21989 for ; Tue, 22 Sep 1998 17:18:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA26085; Tue, 22 Sep 1998 17:13:11 -0400 (EDT) Resent-Date: Tue, 22 Sep 1998 17:13:11 -0400 (EDT) Resent-Message-Id: <199809222113.RAA26085@www19.w3.org> Reply-To: ejw@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu From: Jim Whitehead To: WEBDAV WG Date: Tue, 22 Sep 1998 13:45:09 -0700 Message-ID: <001801bde669$e39fd7e0$d115c380@galileo.ics.uci.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: FW: BCP 25, RFC 2418 on Working Group Guidelines Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2109 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list FYI -- I occasionally get asked questions on how IETF working groups operate, and the roles of various positions within the working group. This document, along with RFC 2026, provides normative descriptions. - Jim -----Original Message----- From: RFC Editor [mailto:rfc-ed@isi.edu] Sent: Monday, September 21, 1998 10:51 AM To: IETF-Announce: ; Cc: rfc-ed@isi.edu Subject: BCP 25, RFC 2418 on Working Group Guidelines A new Request for Comments is now available in online RFC libraries. BCP 25: RFC 2418: Title: IETF Working Group Guidelines and Procedures Author(s): S. Bradner Status: Best Current Practice Date: September 1998 Mailbox: sob@harvard.edu Pages: 26 Characters: 62857 Obsoletes: 1603 URL: ftp://ftp.isi.edu/in-notes/rfc2418.txt The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document is a product of the Process for Organization of Internet Standards ONgoing Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute From w3c-dist-auth-request@w3.org Wed Sep 23 11:42:18 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA08272 for ; Wed, 23 Sep 1998 11:42:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09085; Wed, 23 Sep 1998 11:36:58 -0400 (EDT) Resent-Date: Wed, 23 Sep 1998 11:36:58 -0400 (EDT) Resent-Message-Id: <199809231536.LAA09085@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host ocnt3.orem.novell.com [151.155.134.195] claimed to be GW.NOVELL.COM Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 23 Sep 1998 09:36:20 -0600 From: "Bruce Cragun" To: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id LAA09065 Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2110 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list These points are valid and represent well what our experience has been here at Novell with our GroupWise document management. We allow users to create references to documents. The documents exist in the library database, while the references exist in a user's folders. A given document can have an unlimited number of references pointing to it and there are valid reasons for wanting those backpointers (yes, we do use backpointers in a real-world solution). Generally we have seen no business need for Jim's second statement, the ability to discover all folders containing a reference to a given document. In reality, we don't care what folders contain the references. More important for us the ability to discover those references (via the backlinks) regardless of where they exist. We use the discovery to "update" the references, which for us contain key data that gets displayed when a user sees a list of the document references. So, for example, we store the subject as part of the reference. That way, when the reference is displayed we don't have to hit the database to get the subject but have it already as part the reference's data. When a user changes the document's subject, we follow all of that document's backpointers and inform each of the new subject. In a URI-based system (as with WebDAV), Jim's case #1 also represents a completely valid use for backpointers. >>> Jim Davis 09/22 12:44 PM >>> Jim Amsden and other have asked me to explain the usefulness of the backpointer. Before I do, I want to emphasize that I am well aware that there are many reasons why a server couldn't or shouldn't provide backpointers from *all* targets to *all* references. I hope here only to show that there are *some* applications for which this is useful, and then to argue that it's worthwhile standardizing the protocol so that applications that *do* use this feature will have a standard way to access it on those servers that happen to provide it. Reasons it is useful: 1) Referential integrity. Some applications desire references that are guarenteed to remain valid, even when the target moves. The easiest way to do accomplish this is by storing back pointers from the target to the reference. While there is no requirement that the backpointer be exposed in the interface, there is no harm in doing so. 2) Multiple containment. Some document management systems have an abstract notion of a 'document' that can be in many 'folders'. For any such document, it is sometimes necessary to obtain the set of folders in which it appears. The most direct mapping of these abstractions to WebDAV (assuming Advanced Collection Resources) is: folder :: WebDAV collection document :: WebDAV resource containment :: WebDAV reference That is, if document D is in folder F, there is a reference resource in F whose target is D. Then, to find the set of all folders {F, G, H...} that contain document D, one first obtains the set of backpointers on D, then (trivially) obtains the set of collections that contain those references. 3) Generality/Extensibility: Backpointers are used in countless data structures (consult any textbook on data structured or algorithms). There will certainly be uses we can't anticipate now. The 'multiple containment' example above is just the first one. I hope to have demonstrated the usefulness of the dav:references property. It will be optional, and hence cost-free, but useful to those applications and servers who need it. From w3c-dist-auth-request@w3.org Wed Sep 23 11:55:14 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA08669 for ; Wed, 23 Sep 1998 11:55:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09364; Wed, 23 Sep 1998 11:48:25 -0400 (EDT) Resent-Date: Wed, 23 Sep 1998 11:48:25 -0400 (EDT) Resent-Message-Id: <199809231548.LAA09364@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host ocnt3.orem.novell.com [151.155.134.195] claimed to be GW.NOVELL.COM Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 23 Sep 1998 09:47:37 -0600 From: "Bruce Cragun" To: , Cc: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id LAA09345 Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2111 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Use DASL just to discover references to a resource? Depending on what you are using the backpointers for, that could put quite a load on your system. And I would think the performance would negate its value. The beauty of storing backpointers is that they are FAST, DIRECT, and EASY TO MAINTAIN. >>> "Roy T. Fielding" 09/18 7:41 PM >>> I doubt that unrestricted backpointers to collection parents will be implementable on general web servers, but I have no objection to defining an optional backpointer property provided that it is also mentioned that such a property is not a very good way to implement scalable systems. I would expect any system that implemented such a thing would restrict the backpointers to references within the same object repository (whatever serves as the server backend). The same functionality can be accomplished via a DASL query, regardless of how the server backend works, which has the advantage of specifying the scope of the query. So, I don't think directly specifying a property to hold that information should imply that the property is maintained live. OTOH, I'm not sure how the response to such a DASL query would look like (i.e., if it would need DAV:references itself). ....Roy From w3c-dist-auth-request@w3.org Wed Sep 23 15:25:02 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA14097 for ; Wed, 23 Sep 1998 15:25:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA14395; Wed, 23 Sep 1998 15:20:30 -0400 (EDT) Resent-Date: Wed, 23 Sep 1998 15:20:30 -0400 (EDT) Resent-Message-Id: <199809231920.PAA14395@www19.w3.org> To: Bruce Cragun cc: w3c-dist-auth@w3.org In-reply-to: Your message of "Wed, 23 Sep 1998 09:47:37 MDT." Date: Wed, 23 Sep 1998 12:13:25 -0700 From: "Roy T. Fielding" Message-ID: <9809231213.aa04238@paris.ics.uci.edu> Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2112 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >Use DASL just to discover references to a resource? Depending on what you are >using the backpointers for, that could put quite a load on your system. And >I would think the performance would negate its value. The beauty of storing >backpointers is that they are FAST, DIRECT, and EASY TO MAINTAIN. Depending on their usage. I don't use backpointers for anything, and thus a DASL search is always more efficient. Likewise, a WebDAV client has no direct need for backpointers other than as a means for information discovery, which is also more efficiently performed and scoped by a search query than via a PROPFIND request. How that is implemented on the server side is none of our business. The uses that you gave for backpointers in your system are only relevant for behind-the-server-curtains types of operations. That's all fine and good, but you don't need a DAV property to do that, nor do you need any extra client-to-server interoperability. I don't particularly care whether a backpointer property is defined or not, just so long as people understand that it isn't necessary. ....Roy From w3c-dist-auth-request@w3.org Wed Sep 23 20:10:46 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA17571 for ; Wed, 23 Sep 1998 20:10:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA18392; Wed, 23 Sep 1998 20:06:25 -0400 (EDT) Resent-Date: Wed, 23 Sep 1998 20:06:25 -0400 (EDT) Resent-Message-Id: <199809240006.UAA18392@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-46.netscape.com [205.217.237.46] claimed to be netscape.com Message-ID: <36098BB3.1656274F@netscape.com> Date: Thu, 24 Sep 1998 00:00:53 +0000 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b1 [en] (X11; U; Linux 2.0.35 i586) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Versioning goals doc Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2113 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I've been working on a versioning goals doc (with input from Jims Amsden & Whitehead); it's at . Note that it's not self-contained; it's more of a diff from the versioning sections of RFC-2291. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | Don't anthropomorphize computers. | |francis@netscape.com | They don't like it. | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Thu Sep 24 12:56:27 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA07813 for ; Thu, 24 Sep 1998 12:56:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA28752; Thu, 24 Sep 1998 12:51:19 -0400 (EDT) Resent-Date: Thu, 24 Sep 1998 12:51:19 -0400 (EDT) Resent-Message-Id: <199809241651.MAA28752@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525668A.002709A0.00@us.ibm.com> Date: Fri, 25 Sep 1998 03:26:47 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2114 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > Depending on their usage. I don't use backpointers for anything, and > thus a DASL search is always more efficient. Likewise, a WebDAV client > has no direct need for backpointers other than as a means for > information discovery, which is also more efficiently performed and > scoped by a search query than via a PROPFIND request. How that is > implemented on the server side is none of our business. Roy, perhaps I misunderstand the context of your statement, but I might disagree with your statement that "a WebDAV client has no direct need for backpointers..." I know that I, as a human client using WebDAV, might like to know what is referencing a resource. Perhaps that's what you meant by "information discovery". Feel free to clarify. I could imagine finding backpointers using a DASL like query might be very slow relative to an architected property/mechanism for maintaining backpointer info. Perhaps you could explain why you say DASL is always more efficient for you. > I don't particularly care whether a backpointer property is > defined or not, just so long as people understand that it > isn't necessary. I agree that it's not *necessary* to be REQUIRED and even mentioned in the protocol, but I think I agree with the person that said that it seems like it would be good to standardize how this info is accessed. Jason. From w3c-dist-auth-request@w3.org Thu Sep 24 13:17:21 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA08511 for ; Thu, 24 Sep 1998 13:17:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA29113; Thu, 24 Sep 1998 13:11:21 -0400 (EDT) Resent-Date: Thu, 24 Sep 1998 13:11:21 -0400 (EDT) Resent-Message-Id: <199809241711.NAA29113@www19.w3.org> X-Authentication-Warning: www10.w3.org: Host h-205-217-237-47.netscape.com [205.217.237.47] claimed to be netscape.com Message-ID: <360A7D30.CB614A51@netscape.com> Date: Thu, 24 Sep 1998 10:11:12 -0700 From: John Stracke Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.5b2 [en] (X11; U; IRIX 6.2 IP22) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <8525668A.002709A0.00@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Optional Backpointers from Targets to References Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/2115 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list ccjason@us.ibm.com wrote: > I could imagine finding backpointers using a DASL like query might be > very slow relative to an architected property/mechanism for > maintaining backpointer info. Not necessarily. It's up to the server implementer: if the customers want backpointer-like functionality, then the server can maintain backpointers under the covers and use them to respond to the DASL query. Other servers which don't expect this to be a common request can just calculate the response on the fly, and the client won't care which way it's working. Just like some servers will implement full-text search via an index, and others will just grep the files. I think I prefer the DASL approach; it's just as optional as the property approach, but it behaves better in the downlevel server case. > Perhaps you could explain why you say > DASL is always more efficient for you. He means that it's more efficient not to have a feature than to have a feature that never gets used. -- /====================================================================\ |John (Francis) Stracke |My opinions are my own.|S/MIME supported | |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | What do you mean, *you're* | |francis@netscape.com | a solipsist? | \====================================================================/ New area code for work number: 650 From w3c-dist-auth-request@w3.org Thu Sep 24 16:29:27 1998 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA13878 for ; Thu, 24 Sep 1998 16:29:27 -0400 (EDT) From: w3c-dist-auth-request@w3.org Received: by www19.w3.org (8.9.0/8.9.0) id QAA02386 for webdav-archive@lists.ietf.org; Thu, 24 Sep 1998 16:29:29 -0400 (EDT) Date: Thu, 24 Sep 1998 16:29:29 -0400 (EDT) Message-Id: <199809242029.QAA02386@www19.w3.org> To: webdav-archive@ietf.org Subject: You have been removed from the list X-Loop: w3c-dist-auth@w3.org (bounce) X-Loop: w3c-dist-auth@w3.org Precedence: junk Your mail address webdav-archive@lists.ietf.org has been removed from the w3c-dist-auth@w3.org mailinglist. It generated an excessive amount of bounced mails. Before sending in a subscription request to w3c-dist-auth-request@w3.org again, please ensure that this problem has been resolved. When in doubt, ask your system administrator or send mail to "postmaster". The last one of those bounced mails has been quoted below: >From MAILER-DAEMON@www19.w3.org Thu Sep 24 16:29:27 1998 >Received: from www10.w3.org (www10.w3.org [18.23.0.20]) > by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA02320 > for ; Thu, 24 Sep 1998 16:29:27 -0400 (EDT) >Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id QAA22399 for ; Thu, 24 Sep 1998 16:29:24 -0400 (EDT) >Received: from localhost (localhost) > by www19.w3.org (8.9.0/8.9.0) with internal id QAA01689; > Thu, 24 Sep 1998 16:29:26 -0400 (EDT) >Date: Thu, 24 Sep 1998 16:29:26 -0400 (EDT) >From: Mail Delivery Subsystem >Message-Id: <199809242029.QAA01689@www19.w3.org> >To: w3c-dist-auth-request@w3.org >Subject: Returned mail: Host unknown (Name server: lists.ietf.org: host not found) >Auto-Submitted: auto-generated (failure) > >The original message was received at Thu, 24 Sep 1998 16:09:10 -0400 (EDT) >from daemon@localhost > > ----- The following addresses had permanent fatal errors ----- >webdav-archive@lists.ietf.org > > ----- Transcript of session follows ----- >550 webdav-archive@lists.ietf.org... Host unknown (Name server: lists.ietf.org: host not found) >c.harding@opengroup.org... Deferred: Connection refused by postman.opengroup.org. > > ----- Message header follows ----- > >Return-Path: >Received: (from daemon@localhost) > by www19.w3.org (8.9.0/8.9.0) id QAA01678; > Thu, 24 Sep 1998 16:09:10 -0400 (EDT) >Resent-Date: Thu, 24 Sep 1998 16:09:10 -0400 (EDT) >Resent-Message-Id: <199809242009.QAA01678@www19.w3.org> >Message-ID: <4FD6422BE942D111908D00805F3158DF0A7574F2@RED-MSG-52> >From: Chris Kaler >To: "'John Stracke'" , > WebDAV WG > >Date: Thu, 24 Sep 1998 13:08:28 -0700 >X-Mailer: Internet Mail Service (5.5.2232.9) >Subject: RE: Versioning goals doc >Resent-From: w3c-dist-auth@w3.org >X-Mailing-List: archive/latest/2117 >X-Loop: w3c-dist-auth@w3.org >Sender: w3c-dist-auth-request@w3.org >Resent-Sender: w3c-dist-auth-request@w3.org >Precedence: list > > ----- Message body suppressed ----- >