<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
docName="draft-iab-escape-report-00" category="info">
number="8752"
category="info"
obsoletes=""
updates=""
submissionType="IAB"
consensus="true"
xml:lang="en"
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3">

  <front>
    <title abbrev="ESCAPE Workshop Report">Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)</title>
    <seriesInfo name="RFC" value="8752"/>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization></organization>
      <organization/>
      <address>
        <email>mt@lowentropy.net</email>
      </address>
    </author>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <organization/>
      <address>
        <email>mnot@mnot.net</email>
      </address>
    </author>
    <date year="2019" month="September" day="18"/> year="2020" month="March"/>

<keyword>web</keyword>
<keyword>security</keyword>
<keyword>origin</keyword>
<keyword>packaging</keyword>
<keyword>bundle</keyword>

    <abstract>
      <t>The Exploring Synergy between Content Aggregation and the Publisher Ecosystem
(ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in
July 2019. This report summarizes its significant points of discussion and
identifies topics that may warrant further consideration.</t>

<t>Note that this document is a report on the proceedings of the
workshop.  The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>

<t>The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet
architecture.  This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working
 groups of the Internet Engineering Task Force (IETF).</t>
      <t>The IAB convened this workshop the ESCAPE Workshop to examine some proposed changes to the Internet
and the Web, and their potential effects on the Internet publishing landscape.
Of particular interest was the Web Packaging proposal from Google, under
consideration in the IETF, the W3C’s W3C's Web Incubator Community Group (WICG), and
the Web Hypertext Application Technology Working Group (WHATWG).</t>
      <t>In considering these proposals, we heard about both positive effects of Web
Packaging,
Packaging and concerns that it could have significant effects on the
relationship between publishers (e.g., news Web web sites) and content aggregators
(e.g., search engines and social networks). As such, our focus was primarily on
this relationship, rather than being a technical discussion.</t>
      <t>Online publishers do not regularly participate in standards activities
directly. A Workshop workshop format was used to solicit input from them. The workshop
had 27 participants from a diverse set of backgrounds, including a small number
of attendees from publishers, one aggregator (Google), plus representatives from
browsers, the AMP Accelerated Mobile Pages (AMP) community, CDNs, Content Distribution Networks (CDNs),
network operators, academia, and standards
bodies. See the Workshop Call workshop call for Participation papers <xref target="CFP"/> target="CFP" format="default"/> for more information
and a complete listing of submissions.</t>
      <t>As intended, the Workshop workshop was primarily a forum for discussion, so it did not
reach definite conclusions. Instead, this report is the primary output of the
Workshop,
workshop, as a record of that discussion.</t>
      <t>This report documents the use cases discussed in <xref target="usecase"/> target="usecase" format="default"/> and explains the
interactions between publishers and aggregators that might be affected by it in
<xref target="tension"/>. target="tension" format="default"/>. <xref target="workshop-details"/> target="workshop-details" format="default"/> includes more details about the Workshop workshop
itself. For those unfamiliar with Web Packaging, <xref target="overview"/> target="overview" format="default"/> provides a summary
as background material.</t>
      <section anchor="mention-of-specific-entities" title="Mention numbered="true" toc="default">
        <name>Mention of Specific Entities"> Entities</name>
        <t>Participants agreed to conduct the Workshop workshop under the Chatham House Rule
<xref target="CHATHAM-HOUSE"/>, target="CHATHAM-HOUSE" format="default"/>, so this report does not attribute statements to individuals
or organizations without express permission. Submissions to the Workshop workshop were
public,
public and thus attributable; they are used here to provide substance and
context.</t>
      </section>
    </section>
    <section anchor="usecase" title="Use Cases"> numbered="true" toc="default">
      <name>Use Cases</name>
      <t>Much of the Workshop workshop concentrated on discussion of the validity and relative
merits of the use cases that might be enabled by Web Packaging. See
<xref target="overview"/> target="overview" format="default"/> for an overview of what Web Packaging is.</t> Packaging.</t>
      <section anchor="nav" title="Instant Navigation"> numbered="true" toc="default">
        <name>Instant Navigation</name>
        <t>The largest use of Web Packaging so far is in Google Search, where packages are
intended to improve the perceived performance of navigation to pages that are
linked from search results when “clicked”.</t> "clicked".</t>

        <t>To enable this, when a linking (or referring) web page includes links to pages
on another site, it also provides the browser with a packaged copy of the target
content, signed by the origin of the target content. In effect, the referring
page provides a cache for the target page’s page's content. If navigation to one of
those links occurs, having the Web Package gives a browser the assurance that
the cache didn’t didn't change the content, so it can treat that content as if it were
acquired directly from the server for the target page – -- even though it came from
a different server. In many cases, this results in significantly lower perceived
delay in displaying the target page.</t>
        <t>A vital characteristic of this technique is that the browser does not contact
the target site before navigation. The browser does not make any requests to
sites until after navigation occurs, and only then if the site requires
additional content or makes a request directly.</t>
        <t>Similar improvements could also be realized by downloading content (packaged or
otherwise) directly from the target site through a technique called
prefetching.
"prefetching". However, doing so would reveal information about the user’s user's
activity on the linking page to those sites – -- even when the user never actually
navigates to it.</t>

<t><list style="hanging">
  <t hangText='Note:'>

<aside>

<t>Note: This technique that uses Web Packaging is also referred to as
“privacy-preserving prefetch”.
"privacy-preserving prefetch". This document avoids that term as there was
some contention at the workshop about what which aspects of privacy might be
preserved by the technique.</t>
</list></t>
</aside>

        <t>Sites bundled with Web Packaging can additionally be constructed in a way that
ensures that they render without needing any additional network access. This
makes it possible to provide near-instantaneous navigation. The proposed changes
to web navigation in support of loading Web Packages is designed to support this
use case.</t>
        <t>Workshop participants recognized the value of web performance for usability, as
well as for business metrics like retention and bounce rates. Such improvements
were seen as a valuable goal, but publishers raised questions about whether they
justified the cost of supporting an additional format, while others raised
concerns about different aspects of the Web Packaging proposal.</t>
      </section>
      <section anchor="offline" title="Offline numbered="true" toc="default">
        <name>Offline Content Sharing"> Sharing</name>
        <t>Another primary use case discussed was the ability to share Web web content between
devices where neither has an active connection to the Internet. One of the
stated goals of Web Packaging is to enable sharing of content offline.</t>
        <t>Several participants reported that in areas where Internet access is expensive,
slow, or intermittent, the use of direct peer-to-peer file exchange (e.g.,
“saving
"saving a Web site website and sharing it on a USB stick”) stick") is commonplace. Most Web web
browsers already have some affordances for this, but these are recognized as in
need of improvements.</t>
        <t>In the discussion, several rejected an assumed requirement of this
	use case – -- that there be no difference between the treatment of a “normal” Web "normal" web page and
that of one loaded from an offline Web Package.</t>
        <t>The ability for a Web Package to provide clear attribution for content was seen
as valuable by some participants for a range of reasons. However, reservations
were expressed about the subtleties of the properties that signatures provide
and the effect of this on Web web security; see also Sections <xref target="web-sec"/> target="web-sec" format="counter"/> and <xref target="archive"/>.</t> target="archive" format="counter"/>.</t>
        <t>Many participants pointed out that using “unsigned bundles” – "unsigned bundles" -- that is, Web
Packages without Signed Exchanges – signed exchanges -- could be adequate for this use case, since
most users don’t don't need cryptographic proof of the site’s site's identity.  However, some
expressed concerns that this might worsen the propagation of falsehood.</t>
        <t>Some suggested that the value of Signed Exchanges signed exchanges was not realized in
small-scale interpersonal exchange of information, information but in the building of
systems for content delivery that might include capabilities like discovery and
automated distribution. The contention here was that effective use of digital
signatures in offline distribution of content implied considerably more
infrastructure than was described in current proposals.</t>
        <t>No definite conclusions about offline sharing were reached during the workshop.</t>
      </section>
      <section anchor="other-use-cases" title="Other numbered="true" toc="default">
        <name>Other Use Cases"> Cases</name>
        <t>A session on the second morning concentrated on two other significant potential
use cases for Web Packages: book publishing and Web archiving. These were not
seen as “primary” "primary" by the proponents of Web Packaging; the original intent was
not to spend significant time on these subjects, but there was considerable
interest from attendees.</t>
        <section anchor="book-publishing" title="Book Publishing"> numbered="true" toc="default">
          <name>Book Publishing</name>
          <t>The potential application of a packaging format to book publishing was
discussed, with particular reference to ways that books differ from web
content. Specialists from that industry pointed out that book delivery can vary
greatly from typical web content delivery.</t>
          <t>Workshop participants briefly explored existing solutions. PDF was seen as
particularly challenging for this use case, due to its limitations, and EPUB
has constraints that also make it challenging for publishers.</t>
          <t>Although Web Packaging might help to address this use case, the question of how
to identify book content was not resolved. The use of Signed Exchanges signed exchanges in this
context might offer means of tying content in books to a Web site, website, but several
limitations inherent in doing that were identified.</t>
          <t>In particular, book publication specialists represented that books don’t don't have
the same requirements for timeliness or currency as web pages. For instance,
Dave Cramer’s Cramer's submission <xref target="CRAMER"/> target="CRAMER" format="default"/> observed that Moby Dick was published
over 61,000 days ago, which is considerably longer than the proposed limit of 7
days for Signed Exchanges. signed exchanges. The limited length of time that a Web Package can be
considered valid was discussed at some length.</t>

          <t>Additionally, the risk of a publisher going out of business during the lifetime
of a book is significant, because books – -- at least successful ones – -- often span
generations in their applicability. To that end, having a means of attributing
content to a publisher was considered less practical, practical and potentially
undesirable (much like the discussion above regarding “unsigned bundles”).</t> "unsigned bundles").</t>
          <t>There were other aspects of book publication that participants saw as
challenging for packaging. For example, it is currently not understood what it
is
means to refer to distinct parts of a book. Participants saw this as an area where
providing stable references for bundles of content might offer possibilities,
but nothing concrete came from that discussion.</t>
          <t>The potential for active content in a bundle to use Web web APIs to enrich content
or enable new features was considered valuable. Models for enabling paywalls
were discussed at some length (see <xref target="paywalls"/>).</t> target="paywalls" format="default"/>).</t>
        </section>
        <section anchor="archive" title="Web Archiving"> numbered="true" toc="default">
          <name>Web Archiving</name>
          <t>Web archiving is a complicated discipline that is made more difficult by the
complex nature of the web Web itself.</t>
          <t>From an archival standpoint, the potential for Web web content to be provided in a
self-contained form was viewed positively. Several improvements to the
structure of Web Packaging were considered, such as providing complete sets of
content and the use of Memento <xref target="MEMENTO"/>.</t> target="RFC7089" format="default"/>.</t>
          <t>Though there were potential applications of a packaging scheme, many challenges
were recognized as requiring additional work on the part of content producers to
be fully effective. For example, JavaScript is needed to render some archived
content faithfully, but attributing that content to an origin in all scenarios
is challenging.</t>
          <t>If packaging were to be widely deployed deployed, it might improve the situation for
archival replay. In particular, the speculation is that there would be less “live
leakage” "live
leakage" as packaged content might be less likely to refer to live resources
that currently tend to “leak” "leak" into views of archives. It was also noted that
subresources might also be more likely to be packaged, especially those that are
needed for deferred representations (i.e., after JavaScript execution on the
page or some user interactions).  Other potential applications and enhancements
are discussed in <xref target="ALAM"/>.</t> target="ALAM" format="default"/>.</t>
          <t>Participants discussed the use of a signature for non-repudiation at some
length. In one case related to the Internet Archive, a public figure disputed the
accuracy of archived content, asserting that either the original content was
modified either at the source, source or in the archive.</t>
          <t>Some participants initially saw digital signatures as a way to address such
issues of provenance. As similar problems exist in other areas, such as in book
publication, medical research, and news, a solution to this problem was
considered to have broad applicability.</t>
          <t>However, the discussion ultimately concluded that providing non-repudiation in
retrospect is challenging. Signing keys are not expected to remain secure for
long periods. If keys are leaked afterwards, an attacker could retroactively
generate fraudulent signatures. Alternative solutions were discussed, such as
providing independent archives for the same data, using consensus protocols, or
using an append-only construct like a Haber-Stornetta log
<xref target="AOLOG"/>, target="AOLOG" format="default"/>, all of which can be used to increase the
difficulty of altering or misrepresenting established archives.</t>
        </section>
      </section>
    </section>
    <section anchor="tension" title="Interactions Between numbered="true" toc="default">
      <name>Interactions between Web Publishers and Aggregators"> Aggregators</name>
      <t>A significant motivation for holding the Workshop workshop was to provide a forum where
publishers could discuss the impact of Web Packaging on the online publishing
ecosystem. Of primary interest was whether Web Packages might effectively enable
a transfer of power from publishers to aggregators.</t>
      <t>Both publishers and aggregators at the workshop expressed the importance of
maintaining a positive relationship. Publishers in particular expressed the
need to be able to trust that aggregators won’t won't misrepresent their work, work or
de-emphasize it for reasons unrelated to quality and perceived value to the
user.</t>
      <t>One key question from <xref target="BERJON"/> target="BERJON" format="default"/> was discussed:</t>

<t><list style='empty'>
  <t>Web
      <blockquote>
      Web Packaging has other uses, but it is primarily seen by a large proportion
  of its stakeholders as a solution to problems that AMP created. Before we agree
  to solve those issues, should we not ask if AMP was a useful approach in the
  first place - -- and useful to whom?</t>
</list></t> whom?
      </blockquote>
      <t>In examining this issue, discussion focused on the current incentive model
offered by aggregators. The costs that publishers incur for participation in
that system were considered. Considerable time was spent on AMP, AMP; a summary of
that discussion can be found in <xref target="conflation"/>.</t> target="conflation" format="default"/>.</t>
      <t>We also considered the question of whether standardizing Web Packaging confers
credibility to aggregators exercising unwelcome control over publisher content, content
or whether the technical safeguards Web Packaging provides could allow
aggregators to relax their restrictions on the kinds of content they’re they're willing
to cache and serve. No conclusions were drawn.</t>
      <section anchor="incentives-for-web-packages" title="Incentives numbered="true" toc="default">
        <name>Incentives for Web Packages"> Packages</name>
        <t>Submissions to the Workshop workshop indicated that the use of inducements involving
better placement and formatting of links to publisher content had a significant
effect on the uptake of related technology. For example, in <xref target="DEPUYDT-NELSON"/>:</t>

<t><list style='empty'>
  <t>[…] target="DEPUYDT-NELSON" format="default"/>:</t>
        <blockquote>
        [...] The Washington Post has always placed a great deal of trust in Google to
  represent its content—and content--and their reward for doing so is more traffic, which
  positively impacts the business.</t>
</list></t> business.
        </blockquote>
        <t>During the Workshop, workshop, several online publishers indicated that if it weren’t weren't for
the privileged position in the Google Search carousel given to AMP content,
they would not publish in that format.</t>
        <t>Publishers that do produce AMP said they see a non-trivial increase in traffic
as a result of deploying AMP content. For example, Yahoo Japan reported a 60%
increase in traffic as a result of deploying AMP on Yahoo Travel <xref target="OTSU"/>. target="OTSU" format="default"/>.
There was no data presented as to whether this increase was due to better
placement in Google Search results, from the inherent benefits of the AMP cache, Cache,
or the use of the AMP format.</t>
        <t>Anecdotal evidence was offered by another large publisher that saw a 10% drop
in traffic as a result of accidentally disabling AMP content. However,
increases in traffic might not result in similarly proportioned increases in
revenue, as observed in <xref target="BREWSTER"/>.</t> target="BREWSTER" format="default"/>.</t>
      </section>
      <section anchor="operational-costs" title="Operational Costs"> numbered="true" toc="default">
        <name>Operational Costs</name>
        <t>Several participants pointed out that introducing a new, parallel
        format for Web content incurs operational costs. In particular,
        supporting any new format - -- such as Web Packaging, Apple News, or
        Facebook Instant Articles - -- requires not only initial development of
        tooling (some generic, generic and some specific to a site’s site's requirements) but
        also an ongoing investment in maintaining its operability. Some
        participants expressed concern about the impact upon small publishers
        with limited technical and financial resources, especially in the
        current publishing climate.</t>
        <t>Increased exposure from new formats might not always justify the added expense
of providing articles in that format <xref target="BREWSTER"/>. target="BREWSTER" format="default"/>.  However, a standardized
format might help publishers reduce the cost of maintaining multiple formats.</t>
      </section>
      <section anchor="content-regulation" title="Content Regulation"> numbered="true" toc="default">
        <name>Content Regulation</name>
        <t>The use of Web Packaging as a tool for avoiding censorship was not a
significant topic of discussion, except to note that publishers often have
regulatory requirements regarding removal or correction of content.</t>
        <t>Reference was made to the desire to remove videos of a recent shooting
<xref target="CHRISTCHURCH"/> target="CHRISTCHURCH" format="default"/> and the potential difficulty in doing so if content were
available as Web Packages. Legal requirements to remove content come from
multiple angles: copyright violations, illegal content, editorial corrections or
errors, and right to erasure provisions in the European Union General Data
Protection Regulation <xref target="GDPR"/> target="GDPR" format="default"/> were mentioned.  One participant speculated that
making it more difficult to remove material in this way might discourage
regulators from censoring content.</t>
        <t>In this context, participants observed that it would be difficult to create
mechanisms to track and control content served as a Web Package without compromising the stated
goal of censorship resistance.</t>
      </section>
      <section anchor="web-performance" title="Web Performance"> numbered="true" toc="default">
        <name>Web Performance</name>
        <t>Understanding the effect that Web Packaging might have on web performance was a
matter of some contention.</t>
        <t>Some informal analysis from the Google Search deployment was presented (later
published in <xref target="AMP-PERF"/>) target="AMP-PERF" format="default"/>) that showed significant performance improvements in
metrics related to navigation time resulting from the combination of prefetch,
prerendering, and the AMP format.  These results are suggestive of a possibility
that Web Packaging could provide some of that improvement on its own, but no
data was presented that apportioned the improvement among the three components.</t>
        <t>Though data was presented to demonstrate potential rather than be a definitive
result, discussions raised a number of questions that suggest the need for
further study. Attendees suggested that future measurements consider the effect
of signed bundles distinct from the enhancements derived from the AMP
format. Future research in this area might also consider the effectiveness of
different strategies on devices with varying capabilities, bandwidth, power
consumption requirements, or network conditions.</t>
        <t>Of particular interest is the additional work required to fetch and render
multiple web pages in prepation preparation for navigation.  This might ultimately use fewer
connections,
connections but comes with an increased network and CPU cost for clients. Some
participants pointed out that different clients or applications might require
different tuning; tuning -- for example, when users have limited (or expensive) bandwidth, bandwidth
or for sites with less clear knowledge about the use of outbound links.</t>
        <t>Workshop participants also expressed interest in learning about the effect of
Web Packages on subsequent navigations within the target site.</t>
        <t>In discussion, some participants suggested that their experience supported a
theory that operating a cache at the linking site was most effective and the
additional work done prior to navigation in terms of fetching and preparing
content was what provided the most gains; others suggested that the benefits
inherent in the AMP format was a dominant factor.</t>
        <t>Understanding the complete effect of Web Packaging on web performance will
require further work.</t>
      </section>
    </section>
    <section anchor="systemic-effects" title="Systemic Effects"> numbered="true" toc="default">
      <name>Systemic Effects</name>
      <t>It is not straightforward to estimate how a proposed technology change might
affect all of the parts of a system – -- including not only other components components, but
also things like end-user rights and the balance of power between parties – --
ahead of time. To date, when evaluating proposals, the IETF has generally
focused on more immediate concerns, such as interoperability and security.</t>
      <t>Moreover, people often find new uses for successful standards
<xref target="SUCCESS"/> target="RFC5218" format="default"/> after they are deployed. It is rarely possible to
accurately predict all applications of a protocol or format, whether they are
harmful or beneficial. Refusing standardization only impedes both outcomes.</t>
      <t>With the understanding that predictions are difficult to make, there was
considerable speculation at the Workshop workshop about the possible effect of Web
Packaging on the Web. Some of that speculation is informed by experience, but
that experience is necessarily limited in scope. This section attempts to
capture that discussion.</t>
      <section anchor="consolidation" title="Consolidation"> numbered="true" toc="default">
        <name>Consolidation</name>
        <t>Concerns about the consolidation of power on the Internet have significantly
increased lately, as a result of several factors. While the IAB, the Internet
Society, and others are examining this phenomenon to understand it better, it is
nevertheless prudent to consider whether proposals for changes to how the
Internet works favors or counters consolidation. Favoring entities with existing
advantages - -- like resources, size, or market share - -- is not necessarily a factor
that disqualifies a new proposal, but it needs to be considered as a cost of
enabling that technology.</t>

<t>While it isn’t clear what all of
        <t>Although the outcomes of adopting Web Packaging would
be, are unclear,
the Workshop workshop revealed several concerns for consolidation risks for all
involved parties: users, publisher sites, linking sites, and services they each
rely on.</t>
        <section anchor="consolidation-of-power-in-linking-sites" title="Consolidation numbered="true" toc="default">
          <name>Consolidation of Power in Linking Sites"> Sites</name>
          <t>Several participants noted that Web Packaging’s enablement Packaging's enabling of instant navigation
(<xref target="nav"/>) target="nav" format="default"/>) might advantage larger linking sites - -- such as social networks or
search engines - -- over smaller ones in the same industry because doing so
requires careful selections of which links to optimize, so as not to create
unneeded traffic.</t>
          <t>For example, a news article often has many links, but not all of them are
equally likely to be followed. Deciding which ones to pre-fetch prefetch requires
considerable data collection and engineering, so this technique might not be
feasible for smaller entities. Additionally, some participants noted that this
technique favors sites that have a linear set of ranked links, like search
results; it is more difficult to apply to a page of news (for example) because
predicting what link a user will follow is less obvious.</t>
          <t>This technique also requires access to a cache with terms of use compatible
with the requirements of the site. It was pointed out that the Google AMP Cache
has policies that might be acceptable to many, and there are other caches.
Sites operated by entities other than Google already use this cache, though it
was observed that a site that does not host its own cache suffers a minor
performance degradation.</t>
        </section>
        <section anchor="consolidation-of-power-in-publishers" title="Consolidation numbered="true" toc="default">
          <name>Consolidation of Power in Publishers"> Publishers</name>
          <t>Participants seemed to agree that if performance is a strong enough
differentiator, the effective use of Web Packaging might turn out to be a
condition for success for online publishers. Google Search’s Search's choice to
privilege content that is served using HTTPS was pointed out as showing that
this sort of influence can be effective. Equally, it is not necessarily the
case that standardization of new capabilities will affect such policies
materially, as noted in <xref target="YASSKIN"/>:</t>

<t><list style='empty'>
  <t>It target="YASSKIN" format="default"/>:</t>
          <blockquote>
          It seems unlikely that any decisions we make in a packaging or distribution
  system will affect the considerations aggregators use when deciding how to rank
  recommendations or the power this gives them over publishers.</t>
</list></t> publishers.
          </blockquote>
          <t>The most common concern raised in the discussion was the effect of this
technology on smaller publishers who might be less able to optimize the packages
they produce, where their primary differentiation in the market has previously
been the quality of their content.</t>
        </section>
        <section anchor="consolidation-of-user-preferences" title="Consolidation numbered="true" toc="default">
          <name>Consolidation of User Preferences"> Preferences</name>
          <t>In typical operation of the Web, servers have an opportunity to tailor content
to the needs of their users. In contrast, a static Web Package has few options
for individualization, as the content is generated once and used by many.</t>
          <t>As a result, publishers noted that AMP provides less opportunity to customize
content for their customers. Their concerns included not only personalizing
content based on what they know about the user but also optimizing the package
for specific browsers. Other participants observed in relation to this that Web
Packaging might also have a consolidating effect in the browser market.</t>
          <t>Some participants brought up the possibility of customization by providing
multiple packages, including multiple variants of resources in a single package,
or performing customization after the package was loaded.  However, other
participants pointed out that all of these options have negative side effects,
either in complexity or reduced performance arising from larger bundles or
delayed customization.</t>
        </section>
      </section>
      <section anchor="web-sec" title="Effect numbered="true" toc="default">
        <name>Effect on Web Security"> Security</name>
        <t>One session explored the impact of introducing a new security model for the
Web. Currently, sites rely on connection-oriented security (provided by TLS
<xref target="TLS"/>), target="RFC8446" format="default"/>), but Web Packaging adds a limited form of object security.
That is, the package protects the integrity of a message, rather than providing
integrity and confidentiality for its delivery. Object security is not a new
concept in the context of the Web; designs like SHTTP <xref target="SHTTP"/> target="RFC2660" format="default"/> are as
old as HTTPS. Though the intent is for Web Packaging to have a far more narrow
applicability, it provides fewer security guarantees than HTTPS, since it
provides only authentication, no confidentiality with respect to the cache, and
no assurance of liveness.</t>
        <t>Object-based security – -- such as proposed in Web Packaging – -- allows the use of
content regardless of how it is obtained; some participants noted that third
parties gain greater control over the distribution of content, reducing the
ability of publishers to retract or alter content over the validity period of
signed content.</t>
        <t>Another topic of discussion was composition attacks. In its proposed form, Web
Packaging only provides authentication of independent resources, not a web page
as a single unit, allowing an attacker to control the composition of resources.
This weakness was acknowledged as a known shortcoming of the current proposal
that would be addressed.</t>
        <t>The issue of managing the trade-off between control and performance in caches
arose. While participants recognized that problems with resource composition
already occur by accident - -- for example, when a cache stores different versions
of resources - -- Web Packaging allows an attacker more direct control over what
resources are available to clients.</t>
        <t>For example, an attacker might be able to cause content with a security flaw to
be used up to a week past the time that the defect was fixed.</t>
        <t>As an example of how Web Packaging might change the risk profile for sites,
participants discussed recovery from cross-site scripting attacks. It is already
the case that a brief exposure to this class of attack can result in an attacker
gaining persistent access, but mechanisms exist that can be used to avoid or
correct issues, like cache validation and Clear Site Data <xref target="CLEAR-DATA"/>. target="CLEAR-DATA" format="default"/>. These
measures are not available to clients unless they connect to the site.</t>
        <t>The discussion pointed out that these concerns are not new or uniquely enabled
by Web Packaging. However, it was pointed out that new features are routinely
subject to higher security and privacy expectations. In an example unrelated to
Web Packaging but with similar tradeoffs, trade-offs, shared compression of multiple
resources has significant performance benefits. The risk with shared compression
exposes
is the potential for exposing encrypted information through
side-channels.
side channels. Though sites can use shared compression without this exposure,
shared compression will likely only be enabled once it is clear that measures to
prevent accidental information exposure are understood to be effective in a
broad set of deployments.</t>

<!-- alternative: For instance, though fingerprinting of browsers might be
effective based on a range of existing features, the existence of an exposure
through other web features does not justify the creation of a further exposure
of the same information. -->

        <t>The discussion also addressed the question of whether concerns might equally
apply to the typical use of a Content Distribution Network (CDN) CDN as a
third-party provider of the content. Some participants concluded that CDNs are
typically in a contractual relationship with the sites they serve and so are
more likely to have their interests aligned.</t>
      </section>
      <section anchor="privacy-of-content" title="Privacy numbered="true" toc="default">
        <name>Privacy of Content"> Content</name>
        <t>Discussion and submissions raised concerns regarding how serving content using
Web Packages might adversely affect privacy of individuals. There are
challenges here, but the very narrow applicability of Web Packaging to what is
effectively static content limits the privacy risk. The conclusion was that that,
provided sufficient care is taken in implementation, the use of Web Packages does
not substantially increase the information that an aggregator gains about what
content is consumed.</t>
        <t>Concretely, an aggregator knows what content it serves in anticipation of
navigation. This is – -- at least in theory – -- substantially the same as the
content that the aggregator might receive if it performed the navigation
itself. Assuming that content is stripped of personalization, the aggregator
gains no new information.</t>
      </section>
    </section>
    <section anchor="conflation" title="AMP numbered="true" toc="default">
      <name>AMP Issues Unrelated to Web Packaging"> Packaging</name>
      <t>On multiple occasions, discussion at the Workshop workshop concentrated on problems that
arise as a result of constraints on the AMP format or details of its inclusion
in Google Search. For instance, the requirement to make metadata about pages to
be exposed by pages expose their
metadata is unlikely to be affected by any standardization of a
packaging format as that requirement is independent of the process of
delivering content.</t>
      <t>This section provides some detail on aspects of the discussion that touched on
AMP more generally in this way. Some treatment of these points is considered
relevant as some of the discussion at the workshop, even under the remit of
discussing Web Packaging, concentrated on the effect of AMP on the ecosystem.</t>

<t><list style="hanging">
  <t hangText='Note:'>

<aside>
        <t>Note: Of the four formats mentioned in the workshop call for papers
        <xref target="CFP"/>, target="CFP" format="default"/>, only AMP sent representatives
        to the workshop. The discussion was therefore concentrated around AMP;
        this section should not be read to imply anything about other
        formats.</t>
</list></t>
</aside>

      <t>Discussion and submissions referred to a commitment <xref target="AMP-LESSONS"/> target="AMP-LESSONS" format="default"/> to allow
publishers to use content that met specific criteria to access privileged
positions in search results, regardless of their adoption of AMP. Participants
felt that this approach might address some of these concerns if it were adopted
and durable. For instance, the use of Web Packaging might be sufficient to
remove some constraints on active content on the basis that the active content
would be attributed to the publisher and not the AMP cache.</t> Cache.</t>
      <section anchor="amp-governance" title="AMP Governance"> numbered="true" toc="default">
        <name>AMP Governance</name>
        <t>There was interest from workshop participants in the governance model used for
AMP. In particular, the question of how independent the AMP project would be of
Google and Google Search.</t> Search arose.</t>
        <t>Three of the seven members of the AMP Technical Steering Committee, the body
that governs AMP, are Google employees, which gives Google considerable
influence over the project. It was asserted that the governance structure was
intended to be more independent of Google over time. The understanding was that
any consumer of the format, such as Google Search, would make an independent
assessment about whether to use or require different aspects of the AMP project
products.</t>
      </section>
      <section anchor="constraints-on-the-amp-format" title="Constraints numbered="true" toc="default">
        <name>Constraints on the AMP Format"> Format</name>
        <t>Sites often implement AMP by creating a separate set of content in parallel to
their regular HTML content. Publishers noted this as a high cost, particularly
for smaller sites. It was pointed out that websites can serve AMP-compliant
content exclusively. However, several publishers referred to limitations in the
format that made it unsuitable for their needs.</t>
        <t>Many cited reasons for this duplication were related to the necessity of
running arbitrary active content (typically, JavaScript). For example:</t>

<t><list style="symbols">
  <t>AMP
        <ul spacing="normal">
          <li>AMP provides a framework for supporting user authentication, but publishers
asserted that using this framework was not considered practical.</t>
  <t>AMP practical.</li>
          <li>AMP content does not support rendering of certain content, which can affect
the ability of publishers to innovate in how they produce content.</t>
  <t>The content production.</li>
          <li>The AMP model for the implementation of paywalls (<xref target="paywalls"/>) target="paywalls" format="default"/>) was claimed
to be inimical to some publisher business models.</t>
</list></t> models.</li>
        </ul>
        <t>More broadly, they considered AMP’s AMP's constraints on the use of active content as
problematic, since they prevent the use of capabilities that are provided on
equivalent non-AMP pages. Reference was made to a proposed &lt;amp-script&gt;
element - -- which has since been made fully available - -- that seeks to provide
limited access to some dynamic content.</t>
      </section>
      <section anchor="performance" title="Performance"> numbered="true" toc="default">
        <name>Performance</name>
        <t>Publishers observed that using the AMP format does not provide any guarantee of
performance gains and and, in some cases cases, could contribute to performance
degradation. It was suggested that this was most problematic for sites that are
already well-tuned for performance.</t>
      </section>
      <section anchor="paywalls" title="Implementation numbered="true" toc="default">
        <name>Implementation of Paywalls"> Paywalls</name>
        <t>The use of “paywalls” paywalls by Web web publishers to control access to content in return
for payment is increasingly common. One popular approach is to offer a limited
number of articles without payment while insisting on a paid subscription to
access further articles.</t>
        <t>On several occasions, participants expressed dissatisfaction with the difficulty
of integrating paywall authorization when using AMP. In particular, they said
AMP encourages publishers to include an article’s article's full content, hidden by
default but easily accessible to motivated users.
The discussion extended to workarounds like cookie syncing <xref target="COOKIE-SYNC"/>
that target="COOKIE-SYNC" format="default"/>,
which is used as part of authorization, authorization and is a consequence of having cached content hosted on the
   linking site rather than the target site.</t>
        <t>The same topic came up concerning book publication, where publishers indicated
that having a means of enabling different methods of distribution without also
facilitating unconstrained copying of book content was necessary.</t>
        <t>This conflation of AMP issues with those addressed by Web Packaging was
recurrent in the discussion. As observed in <xref target="DAS"/>, target="DAS" format="default"/>, these concerns might be
addressed by linking to a signed bundle.</t>
      </section>
    </section>
    <section anchor="venues-for-future-discussion" title="Venues numbered="true" toc="default">
      <name>Venues for Future Discussion"> Discussion</name>
      <t>Web Packaging work continues in multiple forums. Questions about the
      core format and signatures is are being discussed on the <eref
      target="https://www.ietf.org/mailman/listinfo/wpack">wpack@ietf.org
      mailing list</eref>. Changes to web browsers as proposed in <xref target="LOADING"/>
      target="LOADING" format="default"/> will be discussed on the <eref
      target="https://github.com/whatwg/fetch/issues/784">Fetch specification
      repository</eref>.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Proposals discussed at the Workshop workshop might have a significant security impact,
and these topics were discussed in some depth; see <xref target="web-sec"/>.</t> target="web-sec" format="default"/>.</t>
    </section>
  </middle>
  <back>

    <references title='Informative References'>

<displayreference target="RFC7230" to="HTTP"/>
<displayreference target="RFC8446" to="TLS"/>
<displayreference target="RFC5218" to="SUCCESS"/>
<displayreference target="RFC2660" to="SHTTP"/>
<displayreference target="RFC7089" to="MEMENTO"/>
<displayreference target="RFC6454" to="ORIGIN"/>
<displayreference target="I-D.yasskin-http-origin-signed-responses" to="SXG"/>
<displayreference target="I-D.yasskin-wpack-bundled-exchanges" to="BUNDLE"/>

    <references>
      <name>Informative References</name>

      <reference anchor="CFP" target="https://www.iab.org/activities/workshops/escape-workshop/">
        <front>
          <title>Exploring Synergy between Content Aggregation and the Publisher Ecosystem Workshop 2019</title>
    <author initials="." surname="IAB">
          <author>
            <organization>Internet Architecture Board</organization>
          </author>
          <date year="2019" month="May" day="03"/>
        </front>
      </reference>

      <reference anchor="CHATHAM-HOUSE" target="https://www.chathamhouse.org/chatham-house-rule">
        <front>
          <title>Chatham House Rule</title>
    <author >
          <author>
            <organization>Chatham House</organization>
          </author>
    <date year="n.d."/>
        </front>
      </reference>

      <reference anchor="CRAMER" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/cramer-position-paper.pdf">
        <front>
          <title>Packaging Books</title>
          <author initials="D." surname="Cramer" fullname="Dave Cramer">
            <organization>Hachette Book Group</organization>
          </author>
          <date year="2019" month="June" day="02"/>
        </front>
      </reference>

      <reference anchor="ALAM" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf">
        <front>
          <title>Supporting Web Archiving via Web Packaging</title>
          <author initials="S." surname="Alam" fullname="Sawood Alam">
            <organization>Old Dominion University</organization>
          </author>
          <author initials="M." surname="Weigle" fullname="Michele C Weigle">
            <organization>Old Dominion University</organization>
          </author>
          <author initials="M." surname="Nelson" fullname="Michael L Nelson">
            <organization>Old Dominion University</organization>
          </author>
          <author initials="M." surname="Klein" fullname="Martin Klein">
            <organization>Los Alamos National Laboratory</organization>
          </author>
          <author initials="H." surname="Van de Sompel" fullname="Herbert Van de Sompel">
            <organization>Data Archiving and Networked Services</organization>
          </author>
          <date year="2019" month="June" day="06"/>
        </front>
      </reference>

      <reference anchor="BERJON" target="https://www.iab.org/wp-content/IAB-uploads/2019/07/NYT-ESCAPE.pdf">
        <front>
          <title>ESCAPE: The New York Times Position</title>
          <author initials="R." surname="Berjon" fullname="Robin Berjon">
            <organization>The New York Times</organization> Times Company</organization>
          </author>
          <date year="2019" month="July" day="09"/>
        </front>
      </reference>

      <reference anchor="DEPUYDT-NELSON" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/washpost.pdf">
        <front>
          <title>Signed Exchanges and The Importance of Trust in Aggregator/Publisher relationships</title>
          <author initials="M." surname="DePuydt" fullname="Melissa DePuydt">
            <organization>The Washington Post</organization>
          </author>
          <author initials="M." surname="Nelson" fullname="Matthew Nelson">
            <organization>The Washington Post</organization>
          </author>
          <date year="2019" month="June" day="04"/>
        </front>
      </reference>

      <reference anchor="OTSU" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/shigeki-ohtsu.pdf">
        <front>
          <title>Deployment Experience of Signed HTTP Exchanges with AMP as a Publisher</title>
          <author initials="S." surname="Ohtsu" fullname="Shigeki Ohtsu">
            <organization>Yahoo Japan Corporation</organization>
          </author>
          <date year="2019" month="June" day="04"/>
        </front>
      </reference>

      <reference anchor="BREWSTER" target="https://www.iab.org/wp-content/IAB-uploads/2019/07/NYT-ESCAPE.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2019/06/patch.pdf">
        <front>
          <title>ESCAPE Position / Patch.com</title>
          <author initials="A." surname="Brewster" fullname="Abraham Brewster">
            <organization>Patch.com</organization>
          </author>
          <date year="2019" month="June" day="06"/>
        </front>
      </reference>

      <reference anchor="CHRISTCHURCH" target="https://www.stuff.co.nz/business/111330323/facebook-working-around-the-clock-to-block-christchurch-shootings-video">
        <front>
          <title>'Thousands' of Christchurch shootings videos removed from YouTube, Google says</title>
          <author initials="R." surname="Stevenson" fullname="Rebecca Stevenson">
      <organization>Stuff.co.nz</organization>
            <organization>Stuff Limited</organization>
          </author>
          <author initials="J." surname="Anthony" fullname="John Anthony">
      <organization>Stuff.co.nz</organization>
            <organization>Stuff Limited</organization>
          </author>
          <date year="2019" month="March" day="16"/>
        </front>
      </reference>

      <reference anchor="GDPR" target="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&amp;from=EN#d1e2606-1-1">
        <front>
          <title>General Data Protection Regulation</title>
    <author >
          <author>
            <organization>European Union</organization>
          </author>
          <date year="2016" month="April" day="27"/>
        </front>
  <seriesInfo name="EU Regulation" value="2016/679"/>
          <refcontent>EU Regulation 2016/679</refcontent>
      </reference>

      <reference anchor="AMP-PERF" target="https://developers.googleblog.com/2019/08/the-speed-benefit-of-amp-prerendering.html">
        <front>
          <title>The Speed Benefit of AMP Prerendering</title>
          <author initials="E." surname="Steinlauf" fullname="Eric Steinlauf">
            <organization>Google</organization>
          </author>
          <date year="2019" month="August" day="14"/>
        </front>
      </reference>

      <reference anchor="YASSKIN" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/chrome.html">
        <front>
    <title>Chrome’s
          <title>Chrome's position on the ESCAPE workshop</title>
          <author initials="J." surname="Yasskin" fullname="Jeffrey Yasskin">
            <organization>Google</organization>
          </author>
          <date year="2019" month="June" day="06"/>
        </front>
      </reference>

      <reference anchor="CLEAR-DATA" target="https://www.w3.org/TR/clear-site-data/">
        <front>
          <title>Clear Site Data</title>
          <author initials="M." surname="West" fullname="Mike West">
            <organization>Google</organization>
          </author>
          <date year="2017" month="November" day="30"/>
        </front>
  <seriesInfo name="W3C" value="Working Draft"/>
          <refcontent>W3C Working Draft</refcontent>
      </reference>

      <reference anchor="AMP-LESSONS" target="https://blog.amp.dev/2018/03/08/standardizing-lessons-learned-from-amp/">
        <front>
          <title>Standardizing lessons learned from AMP</title>
          <author initials="M." surname="Ubl" fullname="Malte Ubl">
            <organization>Google</organization>
          </author>
          <date year="2018" month="March" day="08"/>
        </front>
      </reference>

      <reference anchor="DAS" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/IAB-Position-Paper_-Signed-Exchanges.pdf">
        <front>
          <title>The Implication of Signed Exchanges on E-Commerce</title>
          <author initials="S." surname="Das" fullname="Sumantro Das">
            <organization>1-800-Flowers.com</organization>
          </author>
          <date year="2019" month="June" day="07"/>
        </front>
      </reference>

      <reference anchor="TAG-DC" target="https://www.iab.org/wp-content/IAB-uploads/2019/06/IAB-Position-Paper_-Signed-Exchanges.pdf"> target="https://www.w3.org/2001/tag/doc/distributed-content/">
        <front>
          <title>Distributed and syndicated content</title>
          <author initials="A." surname="Betts" fullname="Andrew Betts">
      <organization></organization> Betts" role="editor">
            <organization/>
          </author>
          <date year="2017" month="July" day="27"/>
        </front>
        <refcontent>W3C TAG Finding</refcontent>
      </reference>

      <reference anchor="LOADING" target="https://wicg.github.io/webpackage/loading.html">
        <front>
          <title>Loading Signed Exchanges</title>
          <author initials="J." surname="Yasskin" fullname="Jeffrey Yasskin">
            <organization>Google</organization>
          </author>
          <date year="2019" month="September" day="04"/>
        </front>
      </reference>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7089.xml"/>

      <reference  anchor="MEMENTO" target='https://www.rfc-editor.org/info/rfc7089'>
<front>
<title>HTTP Framework for Time-Based Access to Resource States -- Memento</title>
<author initials='H.' surname='Van de Sompel' fullname='H. Van de Sompel'><organization /></author>
<author initials='M.' surname='Nelson' fullname='M. Nelson'><organization /></author>
<author initials='R.' surname='Sanderson' fullname='R. Sanderson'><organization /></author>
<date year='2013' month='December' />
<abstract><t>The HTTP-based Memento framework bridges the present and past Web.  It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps.  Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime.  TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource.  The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.</t></abstract>
</front>
<seriesInfo name='RFC' value='7089'/>
<seriesInfo name='DOI' value='10.17487/RFC7089'/>
</reference>

<reference anchor="AOLOG" > anchor="AOLOG">
        <front>
          <title>How to time-stamp a digital document</title>
    <author initials="S." surname="Haber" fullname="Stuart Haber">
      <organization></organization>
    </author>
    <author initials="W." surname="Stornetta" fullname="W.Scott Stornetta">
      <organization></organization>
    </author>
    <date year="1991"/>
  </front>
  <seriesInfo name="Journal of Cryptology" value="Vol. 3"/>
          <seriesInfo name="DOI" value="10.1007/bf00196791"/>
</reference>

<reference  anchor="SUCCESS" target='https://www.rfc-editor.org/info/rfc5218'>
<front>
<title>What Makes for a Successful Protocol?</title>
<author initials='D.' surname='Thaler' fullname='D. Thaler'><organization /></author>
<author initials='B.' surname='Aboba' fullname='B. Aboba'><organization /></author>
<date year='2008' month='July' />
<abstract><t>The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success.  It is hoped that these observations can serve as guidance for future protocol work.  This memo  provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='5218'/>
<seriesInfo name='DOI' value='10.17487/RFC5218'/>
</reference>

<reference  anchor="TLS" target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2018' month='August' />
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>

<reference  anchor="SHTTP" target='https://www.rfc-editor.org/info/rfc2660'>
<front>
<title>The Secure HyperText Transfer Protocol</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='A.' surname='Schiffman' fullname='A. Schiffman'><organization /></author>
<date year='1999' month='August' />
<abstract><t>This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web.  This memo defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2660'/>
<seriesInfo name='DOI' value='10.17487/RFC2660'/>
</reference>

<reference anchor="COOKIE-SYNC" >
  <front>
    <title>The Web Never Forgets</title>
    <author initials="G." surname="Acar" fullname="Gunes Acar">
      <organization></organization>
    </author>
    <author initials="C." surname="Eubank" fullname="Christian Eubank">
      <organization></organization>
    </author>
    <author initials="S." surname="Englehardt" fullname="Steven Englehardt">
      <organization></organization>
    </author>
    <author initials="M." surname="Juarez" fullname="Marc Juarez">
      <organization></organization>
    </author>
    <author initials="A." surname="Narayanan" fullname="Arvind Narayanan">
      <organization></organization>
    </author>
    <author initials="C." surname="Diaz" fullname="Claudia Diaz">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
  <seriesInfo name="Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security - CCS" value="'14"/>
  <seriesInfo name="DOI" value="10.1145/2660267.2660347"/>
</reference>

<reference anchor="BUNDLE">
<front>
<title>Web Packaging</title>

<author initials='J' surname='Yasskin' fullname='Jeffrey Yasskin'>
    <organization />
</author>

<date month='June' day='30' year='2017' />

<abstract><t>Web Packages provide a way to bundle up groups of web resources to transmit them together.  These bundles can then be signed to establish their authenticity.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-yasskin-dispatch-web-packaging-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-yasskin-dispatch-web-packaging-00.txt' />
</reference>

<reference anchor="SXG">
<front>
<title>Signed HTTP Exchanges</title>

<author initials='J' surname='Yasskin' fullname='Jeffrey Yasskin'>
    <organization />
</author>

<date month='July' day='8' year='2019' />

<abstract><t>This document specifies how a server can send an HTTP exchange--a request URL, content negotiation information, and a response--with signatures that vouch for that exchange's authenticity.  These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't.  The signatures can also be used in other ways described in the appendices.  These signatures contain countermeasures against downgrade and protocol-confusion attacks.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-yasskin-http-origin-signed-responses-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-yasskin-http-origin-signed-responses-06.txt' />
</reference>

<reference  anchor="HTTP" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
          <author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author> initials="S." surname="Haber" fullname="Stuart Haber">
            <organization>Bellcore</organization>
          </author>
          <author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author> initials="W." surname="Stornetta" fullname="W.Scott Stornetta">
	    <organization>Bellcore</organization>
          </author>
          <date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract> year="1991"/>
        </front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
          <refcontent>Journal of Cryptology, Vol. 3, Issue 2, pp. 99-111</refcontent>
      </reference>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5218.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2660.xml"/>

      <reference  anchor="ORIGIN" target='https://www.rfc-editor.org/info/rfc6454'> anchor="COOKIE-SYNC">
        <front>
          <title>The Web Origin Concept</title> Never Forgets</title>
          <seriesInfo name="DOI" value="10.1145/2660267.2660347"/>
          <author initials="G." surname="Acar" fullname="Gunes Acar">
            <organization/>
          </author>
          <author initials="C." surname="Eubank" fullname="Christian Eubank">
            <organization/>
          </author>
          <author initials="S." surname="Englehardt" fullname="Steven Englehardt">
            <organization/>
          </author>
          <author initials="M." surname="Juarez" fullname="Marc Juarez">
            <organization/>
          </author>
          <author initials="A." surname="Narayanan" fullname="Arvind Narayanan">
            <organization/>
          </author>
          <author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author> initials="C." surname="Diaz" fullname="Claudia Diaz">
            <organization/>
          </author>
          <date year='2011' month='December' />
<abstract><t>This document defines the concept of an &quot;origin&quot;, which is often used as the scope of authority or privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites.  In addition to outlining the principles that underlie the concept year="2014"/>
        </front>
          <refcontent>CSS '14: Proceedings of origin, this document details how to determine the origin of a URI 2014 ACM SIGSAC Conference on Computer and how to serialize an origin into a string.  It also defines an HTTP header field, named &quot;Origin&quot;, that indicates which origins are associated with an HTTP request.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6454'/>
<seriesInfo name='DOI' value='10.17487/RFC6454'/> Communications Security, pp. 674-689</refcontent>
      </reference>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.yasskin-wpack-bundled-exchanges.xml"/>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-yasskin-http-origin-signed-responses-08.xml"/>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml"/>
    </references>
    <section anchor="workshop-details" title="About numbered="true" toc="default">
      <name>About the Workshop"> Workshop</name>
      <t>The ESCAPE Workshop was held on 2019-07-18 and the morning of 2019-07-19 at
Cisco’s
Cisco's facility in Herndon, Virginia Virginia, USA.</t>

<t>Attendees to the Workshop
      <t>Workshop attendees were asked to submit position papers. These papers
are published on the IAB website <xref target="CFP"/>.</t> target="CFP" format="default"/>.</t>
      <t>The Workshop workshop was conducted under the Chatham House rule Rule <xref target="CHATHAM-HOUSE"/>,
      target="CHATHAM-HOUSE" format="default"/>, meaning that statements
      cannot be attributed to individuals or organizations without explicit
      authorization.</t>
      <section anchor="agenda" title="Agenda"> numbered="true" toc="default">
        <name>Agenda</name>
        <t>This section outlines the broad areas of discussion on each day.</t>
        <section anchor="thursday-2019-07-18" title="Thursday 2019-07-18">

<t><list style="hanging">
  <t hangText='Web numbered="true" toc="default">
          <name>Thursday 2019-07-18</name>
          <dl newline="false" spacing="normal">
            <dt>Web Packaging Overview:­­­­'> Overview:</dt>
            <dd>
  A technical summary of Web Packaging was provided, plus a longer discussion
of a range of use cases.</t>
  <t hangText='Web cases.</dd>
            <dt>Web Packaging and Aggregators:'> Aggregators:</dt>
            <dd>
  The use of web packaging Web Packaging from the perspective of a content aggregator was
given.</t>
  <t hangText='Web
given.</dd>
            <dt>Web Packaging and Publishers:'> Publishers:</dt>
            <dd>
  After a break, presentations from web publishers talked about the benefits
and costs of Web Packaging. This included some discussion of the effect of
developing AMP-conformant versions of content from a publisher perspective.</t>
  <t hangText='Web perspective.</dd>
            <dt>Web Packaging and Security:'> Security:</dt>
            <dd>
  This session concentrated on how the Web Packaging proposal might affect the
Web
web security model.</t>
  <t hangText='Alternatives model.</dd>
            <dt>Alternatives to Web Packaging:'> Packaging:</dt>
            <dd>
  This session looked at alternative technologies, including those that were
attempted in the past and some more recent ideas for addressing the use case of
making web navigations more performant.</t>
</list></t> performant.</dd>
          </dl>
        </section>
        <section anchor="friday-2019-07-19" title="Friday 2019-07-19">

<t><list style="hanging">
  <t hangText='Web Archival:'> numbered="true" toc="default">
          <name>Friday 2019-07-19</name>
          <dl newline="false" spacing="normal">
            <dt>Web Archival:</dt>
            <dd>
  This session talked about the potential application of a technology like Web
Packaging in addressing some of the myriad problems faced by web archival
systems.</t>
  <t hangText='Book Publishing:'>
  A discussion of the
systems.</dd>
            <dt>Book Publishing:</dt>
            <dd>
  The effect of technologies for bundling and distribution of
books.</t>
  <t hangText='Conclusions:'>
books was discussed.</dd>
            <dt>Conclusions:</dt>
            <dd>
  A wrap up wrap-up session attempted to capture key learnings takeaways from the Workshop.</t>
</list></t> workshop.</dd>
          </dl>
        </section>
      </section>
      <section anchor="workshop-attendees" title="Workshop Attendees"> numbered="true" toc="default">
        <name>Workshop Attendees</name>
        <t>Attendees to of the Workshop workshop are listed with their primary affiliation as it
appeared in submissions. Attendees from the program committee (PC), the
Internet Architecture Board (IAB), and the Internet Engineering Steering Group
(IESG) are also marked.</t>

<t><list style="symbols">
  <t>Sawood Alam,
        <ul spacing="compact">
          <li><t><contact fullname="Sawood Alam"/>, Old Dominion University</t>
  <t>Jari Arkko, University</t></li>
          <li><t><contact fullname="Jari Arkko"/>, Ericsson (IAB)</t>
  <t>Richard Barnes, Cisco</t>
  <t>Robin Berjon, (IAB)</t></li>
          <li><t><contact fullname="Richard Barnes"/>, Cisco</t></li>
          <li><t><contact fullname="Robin Berjon"/>, New York Times (PC)</t>
  <t>Zack Bloom, Cloudflare</t>
  <t>Abraham Brewster, Patch.com</t>
  <t>Alissa Cooper, (PC)</t></li>
          <li><t><contact fullname="Zack Bloom"/>, Cloudflare</t></li>
          <li><t><contact fullname="Abraham Brewster"/>, Patch.com</t></li>
          <li><t><contact fullname="Alissa Cooper"/>, Cisco (IESG, IAB)</t>
  <t>Dave Cramer, IAB)</t></li>
          <li><t><contact fullname="Dave Cramer"/>, Hachette Book Group</t>
  <t>Melissa DePuydt, Group</t></li>
          <li><t><contact fullname="Melissa DePuydt"/>, Washington Post</t>
  <t>Levi Durfee, Post</t></li>
          <li><t><contact fullname="Levi Durfee"/>, AMP Advisory Committee</t>
  <t>Rudy Galfi, Google</t>
  <t>Joseph Committee</t></li>
          <li><t><contact fullname="Rudy Galfi"/>, Google</t></li>
          <li><t><contact fullname="Joseph Lorenzo Hall, Hall"/>, Center for Democracy &amp; Technology (PC)</t>
  <t>Matthew Nelson, (PC)</t></li>
          <li><t><contact fullname="Matthew Nelson"/>, Washington Post</t>
  <t>Michael Nelson, Post</t></li>
          <li><t><contact fullname="Michael Nelson"/>, Old Dominion University</t>
  <t>Mark Nottingham, University</t></li>
          <li><t><contact fullname="Mark Nottingham"/>, Fastly (IAB, PC)</t>
  <t>Shigeki Ohtsu, Yahoo</t>
  <t>Eric Rescorla, Mozilla</t>
  <t>Adam Roach, PC)</t></li>
          <li><t><contact fullname="Shigeki Ohtsu"/>, Yahoo</t></li>
          <li><t><contact fullname="Eric Rescorla"/>, Mozilla</t></li>
          <li><t><contact fullname="Adam Roach"/>, Mozilla (IESG)</t>
  <t>Rich Salz, (IESG)</t></li>
          <li><t><contact fullname="Rich Salz"/>, Akamai Technologies</t>
  <t>Wendy Seltzer, W3C</t>
  <t>David Strauss, Technologies</t></li>
          <li><t><contact fullname="Wendy Seltzer"/>, W3C</t></li>
          <li><t><contact fullname="David Strauss"/>, Pantheon (PC)</t>
  <t>Chi-Jiun Su, Hughes</t>
  <t>Ralph Swick, W3C</t>
  <t>Martin Thomson, (PC)</t></li>
          <li><t><contact fullname="Chi-Jiun Su"/>, Hughes</t></li>
          <li><t><contact fullname="Ralph Swick"/>, W3C</t></li>
          <li><t><contact fullname="Martin Thomson"/>, Mozilla (IAB, PC)</t>
  <t>Jeffrey Yasskin, Google</t>
  <t>Dan York, PC)</t></li>
          <li><t><contact fullname="Jeffrey Yasskin"/>, Google</t></li>
          <li><t><contact fullname="Dan York"/>, Internet Society</t>
  <t>Benjamin Young, Society</t></li>
          <li><t><contact fullname="Benjamin Young"/>, John Wiley &amp; Sons</t>
</list></t> Sons</t></li>
        </ul>
      </section>
    </section>
    <section anchor="overview" title="Web numbered="true" toc="default">
      <name>Web Packaging Overview"> Overview</name>
      <t>Web Packaging is comprised of two separate technologies: resource bundling
<xref target="BUNDLE"/> target="I-D.yasskin-wpack-bundled-exchanges" format="default"/> and signed exchanges
<xref target="SXG"/>.</t> target="I-D.yasskin-http-origin-signed-responses" format="default"/>.</t>
      <t>In both the submissions and Workshop workshop discussion, the most controversial aspect
of the technology is the use of signed exchanges as an alternative means of
providing authority over a particular resource, for a few different reasons.</t>
      <t>This appendix explains how authority works on the Web and how Web Packaging
proposes to change that.</t>
      <section anchor="authority-in-https" title="Authority numbered="true" toc="default">
        <name>Authority in HTTPS"> HTTPS</name>
        <t>The web Web currently uses HTTPS <xref target="HTTP"/> target="RFC7230" format="default"/> to establish a server’s server's
authority – -- that is, to give an assurance that the content came from where the
URL implies. The combination of URI scheme (https), domain name (or host), and
port number are formed into a single identifier, the origin <xref target="ORIGIN"/> target="RFC6454" format="default"/>
to which content is attributed.</t>
        <t>Web browsers use the certificate offered as part of a TLS connection
<xref target="TLS"/> target="RFC8446" format="default"/> to servers in determining whether a server is authoritative
for that origin; see <xref target="ORIGIN"/> target="RFC6454" format="default"/> and Section 9.1 of
<xref target="HTTP"/>. target="RFC7230" section="9.1" sectionFormat="of" format="default"/>.
Content is attributed to a given URL only if it is received from a connection
to a server that is authoritative for the associated origin.</t>
        <t>As an example, a web browser seeking to load <spanx style="verb">https://example.com/index.html</spanx> <tt>https://example.com/index.html</tt>
makes a TLS connection to a server. As part of the TLS connection
establishment, the server offers a certificate for the name <spanx style="verb">example.com</spanx>. <tt>example.com</tt>. If
the browser accepts the certificate, it will then make requests for URLs on the
<spanx style="verb">https://example.com</spanx>
<tt>https://example.com</tt> origin on that connection and consider any answers from the
server to be authoritative.</t>
        <t>This notion of authority is a crucial property of web security: only content
that is attributed to the same web origin can access all information in that
origin, including the content of most resources as well as state associated
with the origin, such as cookies. This separation ensures that sites can keep
secrets from each other, even when they are both loaded in the same browser.</t>
      </section>
      <section anchor="authority-in-web-packaging" title="Authority numbered="true" toc="default">
        <name>Authority in Web Packaging"> Packaging</name>
        <t>Web Packaging, through the use of signed exchanges, aims to provide an
alternative means of establishing authority. A signed exchange is an expression
of an HTTP request and response (an exchange) with certain information stripped
and a digital signature applied.</t>
        <t>The signature is made with a similar certificate to the one a server might
offer in HTTPS - -- that certificate can also be used for HTTPS - -- but it includes
a special attribute that denotes its suitability for signed exchanges.</t>
        <t>A web browser that has been provided with a signed exchange can verify the
signature, and -
signature and, if the signature is valid and the certificate is acceptable - acceptable,
use the content from the signed exchange. Critically, the web browser does not
make an HTTPS connection to a server to get the content or to verify the
signature.</t>
        <t>In effect, Web Packaging moves from a model where authority is derived from the
delivery method (i.e., TLS) to an object security model, where authority is
derived from a signature on objects. In doing so, it aims to render the means
of delivery irrelevant to determinations of security.</t>
      </section>
      <section anchor="applicability" title="Applicability"> numbered="true" toc="default">
        <name>Applicability</name>
        <t>Web Packaging does not claim to supplant the authority model of the Web
completely, but to it does provide an alternative that might be used under certain
narrow conditions. In particular, Web Packaging is intended for use with
content that is not secret from an entity that is aware of the existence of
that content.</t>
   <t>In aid of this goal, web packaging Web Packaging does not include information
   from exchanges that is related either to the process of acquiring content as well as
   nor does it include any information that relates is related to individual requests.
For instance, use of the
Set-Cookie header field is expressly forbidden, as it often contains
information that is related to a particular user.</t>
      </section>
      <section anchor="the-amp-format-google-search-results-and-web-packaging" title="The numbered="true" toc="default">
        <name>The AMP Format, Google Search Results, and Web Packaging"> Packaging</name>
        <t>The relationship between the AMP Project <eref target="https://amp.dev/">https://amp.dev/</eref> target="https://amp.dev/" brackets="angle"/> and Web Packaging is
complicated. The AMP Project, sponsored by Google, establishes a profile of HTML
with a stated goal of providing support for the best practices for the format,
with a strong emphasis on performance. The format tightly constrains the use of
HTML features but also offers a library of components that provide sanitized
implementations of many commonly used capabilities.</t>
        <t>The connection to Web Packaging is bound up in the way that Google Search
treats AMP content specially. AMP content provides two properties that Google
Search exploits: metadata exposure and static analysis of active content.</t>
        <t>AMP content provides metadata in a form that can be reliably extracted, using
the microformats defined by the Schema.org project <eref target="https://schema.org/">https://schema.org/</eref>. target="https://schema.org/" brackets="angle"/>. This
aspect of AMP has no effect on the discussion, except to the extent that this
relates to Google Search and their use of this metadata in populating the
carousel.</t>
        <t>Constrained use of active content – -- such as JavaScript - -- in AMP makes it
possible to analyze content to verify that actions taken are narrowly limited.
This static analysis assures that AMP content can be served without affecting
other content on the same site. For Google Search, this is what enables the
loading of AMP content alongside search content and other AMP resources.</t>
        <t>To provide preloading, Google operates an the Google AMP Cache
<eref target="https://developers.google.com/amp/cache/">https://developers.google.com/amp/cache/</eref>, target="https://developers.google.com/amp/cache/" brackets="angle"/>, from which AMP content is served.
As a consequence, browsers attribute the content to the origin
<xref target="ORIGIN"/> target="RFC6454" format="default"/> of the AMP Cache and not the publisher, creating some
confusion about how content is attributed, as discussed in the W3C finding on
distributed content <xref target="TAG-DC"/>.</t> target="TAG-DC" format="default"/>.</t>
        <t>An important goal of Web Packaging is to attribute content loaded from a cache,
such as the Google AMP cache, Cache, to the publisher that created that content. For more on
this
this, see <xref target="nav"/>.</t> target="nav" format="default"/>.</t>
      </section>
    </section>
<section numbered="false" toc="default">
<name>IAB Members at the Time of Approval</name>
<t>Internet Architecture Board members at the time this document was approved
for publication were:</t>
      <ul empty="true" spacing="compact">
        <li><t><contact fullname="Jari Arkko"/></t></li>
        <li><t><contact fullname="Alissa Cooper"/></t></li>
        <li><t><contact fullname="Stephen Farrell"/></t></li>
        <li><t><contact fullname="Wes Hardaker"/></t></li>
        <li><t><contact fullname="Ted Hardie"/></t></li>
        <li><t><contact fullname="Christian Huitema"/></t></li>
        <li><t><contact fullname="Zhenbin Li"/></t></li>
        <li><t><contact fullname="Erik Nordmark"/></t></li>
        <li><t><contact fullname="Mark Nottingham"/></t></li>
        <li><t><contact fullname="Melinda Shore"/></t></li>
        <li><t><contact fullname="Jeff Tantsura"/></t></li>
        <li><t><contact fullname="Martin Thomson"/></t></li>
        <li><t><contact fullname="Brian Trammell"/></t></li>
      </ul>
</section>
  </back>

<!-- ##markdown-source:
H4sIAMs0gl0AA8V965IjR3be/3qK8jAkzkQA6B4Ol0MOtbvq6e65UHNpT/eI
omWFNwEkGrUNVEF1aQzYMRF6B/uPH8Iv4UfRk/h855KZVUCTtHYdliWTbABV
mSfP/Xzn5Hg8ztqiXfln+YMPflPVbb6oq3XeLn3++uR5/mNV3zTLapNXZX7+
abOq6qK8zi93pa+vd/nUt1vvy/y0KltftvnJ9XXtr11b0LddOeenXHTTVdEs
fZ2fz6pm17R+nT88vzw9uTh/9CBz02ntb+nl8pf4PlnMg2xezUq3puXNa7do
x4Wbjn0zcxs/rvkb4+PjbOZaf13Vu2d5US6qrNjUz/K27pr2q+Pj746/yrKm
pdX8N7eqSnrQzjfZpniW/3NbzUZ5Q8+o/aKhf9ut5V/olWu32dBG/yXLXNcu
q/pZludj+r+c3tA8y99O8qtltW6qkv8mC3zr6rYoex9U9fUz/he/dsXqWb5u
/35VbYlSdbXZTUrf7j32XdXSQ66Xbt1/8s3wk71Hl1X79/j/+LFZWdVrOodb
/yzLQJT4X3l++uJCfmoH/9c72HB8Xx0//u6BvMTV176ltyzbdtM8OzrabrcT
OsYJ7eDIzWhVRVv45mirP22O9HztD0fynDkd8jN+7vj4d+PjJ/zHeDr4n7H+
U8lJ/Bv+AHLlr2kzNZEnP6lny6L1s7arff68cvWc6fLq5OrVydvxq/cfL8/7
FDpdupYon7+qusbnH7qV/4XNzeTLS3yXd6l/GPNfxnX49X2r58X2XsnL+3Dy
9vxDf10XbnbjrnFyz6vqpvkNFN9uxjM51COiz7ijk3fz5gh0PTr+5mhWE8fV
403VFDjs8YZOop5s5ov9Q/hmTKL1q4dwNslP+Znhz8LTZ+7WDz/hfb9ys6Vv
W887yl/WVbfB7k/enLzt7/2y20ABYPM/+qmc6S3+67Zw/JdAnL+cLI3bVtV8
7FZ0il/dS45vfp0cl5P8ZKUiHIlxyY/vf8LEeL+a52fVuigheB9LkuCaDmZ3
+NmkPn70xfXKD57+tiCKrojaw4//Q69451em3vqvcH6Vvxl+/B96xT+sfLH3
BtGu/Y/46W+qhilH/3jHGsrROty0ql1LNuHwS15N8n90ZT73+WW13vjV4GWv
fD31ZAoPf4ffeuZal/AclOI7Upqks/w8v/T1bTEjO0O/eX7+4Yf37wYKl43d
M7IVnn61zX+in+VXxdo3+YVK3l/Ks0+P3v10NZYXHWbYp+Pj736dYT9M8ue+
/vPeiX+opnQcg4+YMvubAhnOzi8+/nR2NX53/uZySI7L4rokqp1/IiYqr4kI
oCYe83oNCXflzOfVIr+CSadVBWtU1UfRCNV+xaffLIvNX0ERbl2zJC3Y3ivs
X/867YiVz/xFt5u3Q2b2tOjG7X0a6PcjvZ3YqiV5IYZo/y+F0bVkn7cHRfHQ
w+kb768uP/bP5MwTQXZrGH9yD3xdeD0FPaxXV1cXyYlti3aZn7y9yB2dXnQN
/gqad1lc+5tiXC3bpvtLDoM073s8Y6h65fmDz5hWP7llVeU/uI2DI1RvoFGI
wVioP5z/eHk1tMbqw5oI50dkgtrZcjKr1v/vxfm32Z8TEufab8lZGxrkk2nt
4G/sfcy0CBsRR+nD68ur01cfP5y+6lPgyyv4OCS+zZfgldNlXTT0w470ZE6+
XAVr3ZCBnnvS1rVfV7fEShxw/FR1V93Uj/KXVUU2Km/c7pekuGm7xYLWMyl/
Ppp2TVH6pjl6/PjxkyfHT756crRwMz8l/4GdSHrn2JEfUc7HJBfj2aqa3Yzb
ajzlf5klaxyHNY55jftUfjJ+/BuoTErzsvW3vtwXzg9+6mczd+BzpvNl3Nfh
R/9ADkRJry53gwf/UC3LvY/2nkmfvDy7GPDtS09eP1lNtmkXdQXPGPz7wV93
olTvOQnf1eOV/zShf1YbR/84WpFeXgU+Pn93dPVPV0evrt6+OfpjVxe/Pz1/
c/5Pz54QLb/5cPzN0+/+1q033+P8f3/+7ov5Y//VN8THj8ePB4SHhI+/esp/
bKCLGsQ0Rvzzj8lK5ftH9Oxfd7HPsWzv2CcRuSYNNr44//CiTx8ozcuNJ1Z9
TpRaFC14G8ruova1L+e+vt/JnNMxr+gtdTO5Zs4mrruGIKlgf3sEnmzw9PFU
nj6uFmOiy3iTPH2ybNerfXb8dvz4N6i+c2bHoly5bjHgmvO6mB34kMkjkgiy
/HRyefkPr98NYyI6N//v//Y/m9zCBWQJEBqqIrQI7q8QlvC77iHCb9N8JDg/
uaa52fMsf/CLRe13e58OaHD65vzkw/js5OpkQIaVdzVZRYpYID+/sNftE97q
1YejGX4zJpr5MW3EDSPcp+PHj8dPju9h9x+fnD7jQBt+5xmyIr/JE/nRN3tu
SHHj+38f7Bni8Ob8khy2y4HHhoQKhc3Fz1jEipQvOV45dlWaQqff3kMLlgBi
8AnJBk7426PjJxCEJn3oWB861oeO8VCIxZBY30IpH3/7m2jwcTr09N+6FR1c
+vcBCc5OLveVAfmlq2Im6ZDoEkVvCMmy8Wm1puB29kuZgt/I/fibORXjC0Tk
/20s7xyHd97rFDz9Ta7RmWuGjlG3dkhU9T5i4jwef3t8PH6BTBZpNfUJrk5e
js9OBz4kGda6mHYtEQcufbMr5yAb/adu9/8bbZ4i/vnqN9AGDpNv2yF1Tso5
+Un6EX325v3J2et3L/v7f0Mr5azagD/u23Uxu55ckyPdTSdFdbT10w1nMPzR
Sh50j/777jf5v3+Z/svG43HupnSebkYRA4Tgr5Y1zCwdHNOHFH2BRchDIrpN
d5KOvj97lz8kNnhE+8x+6FY7JgsytAV8TM5pN9167eriZ5LNom3yhg6kWBAr
0iI3VVHSn0iM50Uz65pGV5uRA1i29C36TVttihn9Y+nafO12tLy6xm8XXd1i
K7TUhr4u8cFEqbUu5nOQ7gusvK7m3UyihytNrYf9tVio2Up6V+4/uTV5tHlD
Ni/fkI9SNRAZVS70hZQcmVH2Rz8dGZmLmvaFMyjIraPzJWI1ZpwDHTdyFKzB
4bIj6zrJ3i/yDXItM3KoaiIpfZksBJ+IviUm1nRx9A5W+cIso7yD05L1iIKw
nV9+fvViJA96cvplw497Xc66KaL5HCqzK4t2J3m//OGPr09fPuJdZfbyVzuS
8dZ/Ij7YRC185WfLsiLDsgum0R7x6uTqx5eP6FRel+Gg8Dk9sPFhB80o3/p8
6cFNblp1bT6tKKQVz+bWRyIusIoskEBITs+dEVGVRchBnFXdap4vkeRMma1/
FFmaswjSszEJafKHfnI9GeUlRWS8d3gMzSN7I8uYC7mQJtOvN7QJird8eY2w
SDRvNQMnlJKhah5REEFS0M2Wo7zq6nxREePzEW/qAoJCQkSs2ooExTWOcjpN
MDxts6QFc+Yrb0F72t8qkSAi9/tyBSZOtjOv8rJq6Ylw1mt6hzBasSFlBgYx
B4DWHOoC2byoiWSrHS056gcpaPCKO8gGyURTETMUyA9tuljEWk845WHSlS3d
PP/qaXwxRJ+/62jxyEvSeXn276d0wtccNRJrFOVs1c1lu83arYiU3XpKTE5f
dG0LL93rg+J+iba0/3hA+UMREGLozapj3USiRYfIpRn5eTatq23DPwbDI8iY
mVCM8tOzd83ITjFHVMEHTzw4c3O/LpxwY6BjNq3mRENy/70XoTMCnmIPREWS
ZTsCiNHd3emLi8+f+ZN1Vfs81I6IHfBoh+VsVp4OjHbJyXciQdNN1wWfe0MH
T6wFtUE0mY/6b+1zmMNrujW/LHIOSnKQoHkxB7eQjDhi5jkFRiV8bEgaEY9f
RZqD7Ifjt0RdX4iikvcQH3ctGIJWCYmzpYwkUUWsVZHA84eu7fNvaj/mJCDI
hcmjUQOauYaOTH9AHFiAePQB/k4EBK08GUhXsFLwGStSxyagOSTqTNwoy2pr
iuslKSJiItYbYguZx7O7O6IwVvr584TebAw+nvvWFauGliA8S4vkg9S/q25L
TyUji+hXi0n+ooJgk60hBb4gC7QqyABwYq+n9Ef0uuoWGW6/pdeQAkWuBNQU
K7vLiLRReshg0s5J+8AufvFF/hZWSf3mjZ9BM+bn9CcW9uwiFUxH5BDhplOH
/exzE5sZ/tN+eY7o0yvnff7MfNX2zpQWDX1EAixeKgSH/BE5Z2JC8lZpax0Z
h4xIQ/6QK4ufRRkyXUBJOmQSYmJrX6sIkLRFcTBrHUWAzGnG5z4za02qwJbg
piv/PX5A0lF70W3EHh6PUUJD2BrJicMssh341DJx84+0+1NmzLsvjBez7C3p
eeX/uA62WOSXsDdOx5E4P/rVW7cq5rDFWKVYgVufUUhTiBnsS0KfX32JnTC7
9niHNVHW4x9IPxkT+wuevMWz+o5G0Sj7QORhSd+520Jdy7svSnf7WRyrFZxq
clewMDHVyUOIARbwaaCfLM94ycaSjD+TWR3uBtTPTIkxL6xBflGiG0R1BTKX
9G+sHjU1XsY14bz4QUwXPI2M4Y3FxmqhiXG6FRGT3l3mD2bEEvSNB1A9lVKQ
GXYkX3A5HoF9PKxQ7lj4Gn7MI2KpKb8sSjy+2IQ1ZOzQVmy44UGMoEKIqaso
u9iWWh6ReGekgKex2dl5S8ySqfMxYt8meugUDRCd+981RwXKWt0fMQphAxmv
PVEjM1SAmS+Sx+BLXzbJ04bkhq2tFpkoMCFANZt1sI7khqnDlzCEz6/Z6rqw
cXxOMVBX83ni4NjplOWQOSq/bNUJ569GIrC9Iv8ub8lYtXLkwT8jZlvgcxZ8
N/vXjvyZeW5eTUTb0ApIBA5tO//3f/vvObLF0M7d9VLeRqEBOwxwXIisNV4m
z2BSE1PuRDSDdRRmg58VPVJaAcfxkamzOYn6Dl8jlUAGbGekS1YEI5+Tf0Yu
HxEEZs0jiU6anM8eFph9wn/tvJhj1/ZYLKheUAkBZfJ8cCipkAWMVjxhceP2
fr92N1CDO9odvathvZ2xl0zWoS1WZDhpaSmnGE9AqVXlihm3xBHxGeDdeBSd
TpO5+bzQerKdJtwieqW4DvzGcJJEk8uCjCYUjCgLMSQSCbC4TfFw0qo/i8jM
q22pkX14wcMgdhU5lxDZbdH4Rwf4JSVXu6yZMVxCd/LHSQNnG8hZO1uy8n1F
R00MAoiT6sMtr66mv9IuE2cv8RNIldZfEjXEJd9ZGGnKiDmUrRwET2gfGJYV
lz2EHFdwOD2ITOpql+mpSEhbwIS9o5j1WZY9k9g97oUZqIOZGVoFIazoEtHU
nK16QN7frZvtxuxh17cSqwolHmhqwHy63N1Wxdy4lMx4LqEu8d+WH8ZhuB4Q
k0boEiJ2IRUbLddsLErUFUSbqEuhM8lNYYYdMvOAElNyamA4990uVjCRJVdI
t3A829Ydu4YFTMTW7URzkXPY1T7KHkSE/SVzXEpyrQS5sEseG4ILN5uRWyOk
yoTnCyRLyEVguxT9kRK57ELMsis9uWB7cjvMYWT0c1itRC6hlgTQA+KZWCTq
usFpk4EQi4OAT78OfZOZI0KEDC5OL8iDp09a72c/N+emY5vNxjMx49C/XeOm
5P0i4iIG2HoKlYgl8ImVGvO1J4dtBkt7A6EOrEFahbgBD4JnhcgLzleqEDIY
AtLUsOjQI1gJm/rryq1G9IY2DQtqV4BurGrYnzRm8xqH+132567hPNVczVLT
SkwW4FE9xtHYGU5FQW9lHWPvyUIeQ14TLUvC2PdngdRFe79YcORvacBLMhH4
2t0XlXxCvtqJ+iMWpdn5JRGVZZz0LPjIl/CK8XLTlxpJkdFiwI26caUv+OlL
ULiUbAILS6mVzUEObZK/Z++BIzUOAuZ8HM2+D1mwtlLvrNGd0beChZAtQqCh
7YjeAzbEofBROcay0IacLTtk5kT48C4KLxDm3fpR1pChHsECcSi5LlrxPswN
5wQmjASxs69R38Y/8wUO2WvmWRNK2YNGPCIXskqSN9DtoMAJZfLx8nkOq37z
4BHWgkREVZJLMPOT/C3YDJkwS1iQJqatzHea9ILOpKiVomuIVaN+DZzZqdgV
WjIOM5FLuEplBr2EzaQyI8m7dun7eQIlcO3/LMExjpr8t7WfmxFfy5GITxJ4
jMxTZnqxhrNBvkTg9ZkP4TmraLh09hiXP2Bg7eoBE45Nn+QmHX8OHxSqy/x8
xDUqDIkmm0ioYnzNAVDPMU2UK1cKQ3gI1sXXjdkgItAkiLiDHiHbIonjXo6L
X1IzE9BCwXScQQkegRgnCW5FRWlk6+eJL0CxZ7vyCNVNE0D2fc1/YSpAP7uW
TY/uISSoxfsPx0F7Ye7z5JARHb7HTsSc392RVh7TB5pIubtzDLTznz8T7d7C
YvU2xyl8cE3XmqsANn7QlRafsFVtHrBjIpJHjBjzuD7G83u1PPxEfDjkYebE
V8hWGjsHpkIsRLyTrSuJPjndiYiB+XlW7zZtdV27zZKcZCIMmCX6nBTYSLWh
3U3yeCY4xiweQz/JzG8X54IMdqPsiuNw16EyuSB6+mVVzaGPwBRNd4342BRQ
zxTubR3sJQlbdVpJPDn7OW7Iu/SiiABtYLsSlAyEN3qSIvCa/p92xWouGjOT
4k/TY2iKPZCF3aXpBI1qicobEZnCq92FMqj46xBC17XVmlX33OqOwQFJvDdz
7OQVwpOwDkGHXiOuyRI+LqIUp09OtX6BgrAckdQ8puSfIe8G8H3txEdDuYoT
53g7eTIzepL4bSQBbGVDMYJ94YNJTxVGW5CpbJZYTpVi/50VOIKTaqaZzWJI
EyGMo380CXSDpK5C0q6qS41Lemkicg5zyySkNTStNWUxIYRjTd23ZzkAWWnR
CaKNbzhD0fJZ0QN4M8j9mpf0QN2EB+Y4M6FKX7b7Fvr7JBXBMY1pygysDCeC
LOq8t/y2IMmQ/Tes42BPoqVSfknOVtO5CP9Ez1sJQMj8hWDXL8JWReHHipzb
9PADlmwBUbSyQesckgtbCN7RSCKEpFLHMRCbLzjXbqcMjqc0atxksaRbs5BG
4RSsQyq/sdCS/ZI5+ZQkV3ualRcVpBQhyS0yvtewkiE63W24GrRN/DT7yb3+
+bQu/IKe4Lmq7JE91/pCU61Y3shaXZy9CDYPrnncPv2StA9FvKVRcaie552X
OBPKg7wnMXWSCDi/+Pg8W+oZE7MXkul3mibjLEPR7r0h+ulIiKw0O9P3F0WH
Lf2KK7vkhnO2eLA2cKy5+GCIZbVFiKQV6J1QPTX6opWJMhROioZT9bWnw1nx
UoCkeWJdT8XssPauFEO+S3MQ9BPhGiw4eIgiDupzZQkJ6ftLCRKQM6pE8zhJ
eOWhiD4XHy6e2ChhcBWFJmHGUBwzU6WMzDYVLibnjBqkwRJfT/1MkueVxGmw
LaxcKRKHn61eWyPVDolaZ+RcJ+0oXzZJPQsVMe67IVekmkr8Lut5W5EuOiPn
WKpaygrzDAYp/+bx6Pj4OJ9DDN11xcEW4sCmbyFWFZ2RVlPbNE5m8uJknmb8
DOxqeLRy7vxN/IL4spU0P7SZMG/Pq5xxyTaU5ek3nOEXaxSiLrhwcBTkeeDr
JOWgmduiuVG1FcAc13zuYplilJwYolWx8FgZV0zl6IseEIP4wc8c2FhOGn4X
LYb83wb4DY6IFt0KPrZ8WC2IW4lnXJldM4DVuFEBEKpkxcsmYlVq8ct5yAi7
KALBxSZtbYLA/B/3mBoBpjjKPlzTmyFyhyIJKn61y1Ceago2F/nDNdIA7LT0
oxiY81uw8DWAbwed1kcSL9RqF8X6JvH4nhjxNnvKtXFbqMs9/RXLMpAGwE42
KykPgFPFKSE2hbbhYlvTok1pKxiHTEJhtjv4lznr65m8WmjKa5vkF8O1sPrT
2Jwsh4S/mcQLrPK5EBZNmiVfmCCp35VqM8lNqYM4yqCtkGQwLwZJmpg2P1jv
TU00B0whb2B60ekisF+wKjeeXbzWnEANGddvo2KoWYLSb/OFV2dywEQWtSGg
JhspG+XfSW51t6Uj04DsPiHNHyJyuruzb3/+/Mj8kH5j3N0XFkeRFU4dL06k
SmVf8Xl4V7FhF1PjJbKC5IRLLZm8CSjxVt2xTDABn3LxmC2ygbLV2nKWvdB4
WN5JBGaQAvsXolX6pE9zPG0l6VOOJiXPmeGpjAskW41om7wmJi1KiCjMKWwH
sBHLw/Sy8pIAyqJjvpfoYZLHkxoxXCZ3FtYKWykUovHM8EFxWMSrRvktvxRx
7R/fnr89f3f1/vcfXpw+Pf72Ow5or8RvaKOMH/QUm6Gr2JCzvyZxlVKPyrZX
ZunnVcREssqLiUABkajlcZJ4tR1sGLCGKLatMqI+aV44ZxYtDRTGD+7WXVI4
s2FGQcQrKVpNOUsySFhvHoi0cOTB8nPFtUg0cL+EBjVcWnERp78i7qGohCKf
qoEWSvQavIxFQqOtFs9pC1s6SNrDnBubwEchwExqu8Q2nbM8SxaYlbyRldtx
YS31YPgXpIi19yCtdeEoLWvAluIBHOCMzBmM8QNmpFhhTbWZ/QDWYrXrqVg8
gv2+rkZ3oVApqGnEIPjWA7zkASKfiuVBGEfID9CMuJDs2ZKCVH8mI58nPFlX
YkUrFvq4nGmok5NUeHXauJKGClAoeCsbMLrH6jMp5Akc/bCY+MlIq3QJF/lP
RNSko0BqxJWyEheTUkDNo0muoe09ksNwnHIJX0+S8K6nTxm8gw5jlseeuYpf
SgTaxTQX76+sSowj6OaFswoR527UiQLbIDXIyUdGUoh47KNab0mY1OWY5Yvi
upNlbjo5JhSQ6bxRVopHGvgH1YrG11GANAvei4eTKCJbV3OpG2gmSE5fc8yS
e5dXWPao51QgNSEHD5OueZM0/8flDS5IxcAHSpREtum8FslI8EociyAStYBK
fyabuG4kCOQEjHg9yFtGTayBSpY4P6QN/ZyjT/CZQDtw+IBQgrQWTAr5i8Ze
xfRI7DJ9zHnsaV25+cCVzLKQoRs4c2QSC6SgEI1WkrbSaCEajSGvFGVGrkld
sUOXD7QZO/341Y3fMSiFfTEUBWatqdi1Q+0MWVRmxgxBBUpaRTVvGCcRfgu9
gNOGtG2BDxyxRW5bkmZGMUstmBYjng85sepZw2ly3bxbMcogHDGa2cG+DA2K
gXred1fCgSUeXkGGAXkYtpaqmgL2gaM6NMaMNJOLg0FBk4+rrWYV4Lq0VfkU
e9jgYWMu6IeaqPjbLn/lpr4eX7YV5Kx1FHVdZ2SKT96/ef/y92fvX08eH9P/
Hj89mi6Ojx9/983T7x4DLgYzw2Ak9uo4eApg0wL+pGNt57PgDolUgiIcDFGA
XTRB4+FPnh1bjhOjQs4UIh7hgc+1/sAOSR8ieJJABO++MAgg5/GShNa6ogMJ
ZixfVpJ03cNiJoUGA2OqKx7fKlyhh8mPIHvpJI/f95jUlah6uF/EU96Q/pP8
/SKU/HrQcito9gq+YoWC0wEHhD3qzOVtTXEbrCKUCANYBuBbVjqRWETl54zn
vh9xOSzrx8S7bjq2omeQObieEkQGkHiKlZ6kR1ekfkP/yVLwErPqtLTOw2vU
kiYr3HLyI2UqDXWxZhaIuR/79WbpGnL84OAsGCnGtR6K4BLT86+dWxm2L+LZ
pBSgvjGsLMO4PTRIzE8xoe/uZK7B58/9/MGzLPvDgC2QVxP13TEaicsBrOki
FJgTelNAghnAJ4mQmlHHOdcTEDi2pL3Aynx4zUCZB5PBVGPcNHKSSI89FzDR
1guglJ4ocHF2+eCyiD0aoUMZvL4VLeuaG+CC8Cj2l7B8JCBI10BBLtVG0uMW
BUXGORdG8zGTVL+KTOyyWv+RU1/S1SFyCAgiXjpKrQej8DXNjpqFFgUKzsCD
vdYIETOOdgVBlDK41jkay1xuUu6bdbVG/CnauyjFhdThPYOIZ4ICfsh4S1qJ
k68broaWoMwoon4FfNcLqk1rLhgHzE4WPX4hMsKu1o9a8Ust7yAXapqh1x04
hMbQU2mjGR35vIhwgVR2yKOsZwXbi67c+tXMQD11tWLwaZLoMX8KMXyCtEga
HRq38NcdtyrsQSEExmiwr1W1zXq47oq1xCeVXCjAulC9rwd/Q8axl+UAyuNL
cHCxQloAqWEBJXLRHjlJDI7qVYnEAtduWwbcrHLRfmWGnLtfACwXoWcvVAzV
C0aVQP1p+vdbEigsborhPbVIw9qCYalqWLtAhKcOSZ6jP8OltiyzqrHiyDbQ
AlLCVmUWOn+GWSzwW3/syOfPrJ/+6z9PJpN/OTQLQxAjKy6f8A6wGi5uUAzj
2B9obQqJAogpPs5jXMOaSjfz7//2P2I7Vu3hcUk0ZOC7QrH5ZMzgQWiWmB4X
0xdqbBWhq3lVOtKzmFmNLQ0GiKj2Om8GhxgRqTAocBol+1zcFit/HfInsW2r
B5Ym5qsBtF8xgpa1r/SpqNQw2kyCX+hRXYY8yrXKC4izEmPNiqOytAM/r3HF
XJBrDAxgx7nFErmqp/4XHirUy7ShAyhXLuRynA8iJYsbsEg64SMgc1z+zfHf
ZAfekP/iG4hY8rirmgKHFfEehqpAy12FEiJgJpixEEsb4oRFJcPYdH0zG9ZO
0xcQqiwK1RDAbvDeUQSIhrKMjhUIkA2mB/QHK7hEoO3DcEInpZ/NK4R1HloN
zg8WlVogxXGp2Q7yLHYFaef88fHfkCZCn8m9lKSolgtFHE2S/dD0Z+/gLOYK
J9OkRyOuopbF8FSGOXM0iT6z4E5wsB9/nwH5WsIOY1tW32HNYSNe2E5x7Xyj
NQYixyns7D0Qr72aaaHtn+IsUiQ6wg8Q5BkYz1RyFlPNQClrh5dBkOmVexmo
HspvJ6lmeeQ4szB50L2Dtkme0MQxVP5CR6WEzooTPB159nGAQnMxnoMrDfpz
HWsR8FVVxSf2kPMzHDQWMwGwSFUPZ8TlFIG7ZGnN7pGk/+AHIM9XSi2JLArZ
RmP21OEmVs6YMlba2c9N7IFmEgyThi/dBhVHoFnSaIer6lZTi/aebViBREUh
qQXJk/XSX+oOBixHrNzPVpwV4Aqo8B43h1UNh+yQ13huTcLKaogE3ynABzef
y48p8uNaWgypnZ1bX9H2WTlBF7nEpfLzTL+d1KtTGKpntZziS9MTWSPxAa7S
PajEGAA0TmeRKsvB5hxWCeAjKb0Ak820w5CcmhtkrfDtsh54A73Z/fbtEbBI
fsOZY2Q49xxiKR1yFVmaUTEprl9HjhU5HlMEqwovpa4VQRrdM9rsh4C9wBq5
UKJuFJcAvSZqkGTW2UecRKRncT5Fhw5xz1qcrKTgt35tJMk1hGo7PInoLEqf
ya0j1Qe3vSf/yNi8wYSe/l7j6uwh7B1ze0k4WleStWmecTtQzUxyW1QrQ1GQ
Z8rPDalIcsSJqAX/yYiGcnzm67qyBgx5DmpntWNhYG5ukjruYEZPno4qyg6O
KiJ+x4QjBKYwu2uBfSGcYZBvoiZC6t5S4Gt3o/DXQZkrEsiaGQ1XwflNkRlG
o3U1UTkylYJqhIkTjIUBWgt1Fj+1o74C62MN4KxZMaG3Kolxs7UHJqBo1uK+
13TYoUkc8Y0dqz6TRS2FBhj4EQUtWq+ESZyJYyx0Biw0c3wURtKBhYAnVNj5
eRFIn2UfpWJM67CnqSvf7rf3qdZBxpVOcIjJ5/A7QwAhCZ9BQ4ZlpxV0CG3t
VjtaXvSF+r7SPM62k45k88YeghnqYA+sMKBDoT5/fqR+zbJCkbGHgEuW2ys0
ko9hvQJJ+iVtXSsYwgKnhevytmQ6i2lRBoyYda+MsnQsVBj4kPptucLorOML
qV/FfSKLIFXEUCzfZQfOQ6LX0HEK6lqPdLI7nBX7lVtFeZZVxv5tn6qSx9pE
D0ytcHiMW1fWY7asPW9d0X2xOnrouUBIrgWx1aZKsj+kAK39AqQsWN+DKGne
JTRZOG3qx1Zjw4WcuJCP18j5OsRMNv2jabs5xhOEOQADkO2i40LR2rOOs64w
SXgkcgFr3od+REhF4Iq0iJWDB8IAPWWCzJjghbzVyiBBYTHgIqnvHVgJojoG
Ty2ypLeQqXxdyHij0G8BfwkQQOlQighdYghizW0xb5cjydByeaVbb5ijU/vD
bqj1HQF9WrQ6SeCeWSTa4T8sZeszmTFYVrRzmaeRBDsWIGCclKWoL+bJ07Yl
6RETOiVlHbguC6+70W4SzWnCZipBXBmijHnsqKLFnF58FAeKQc+rgnmc/dfs
l2OIeA76K9CsV+KUpSoNknNru5JRsYs08OW+PEGps9I1j/chf0lbTh4lR4hI
EU+Q/j7xksEi0p9wU1bblZ+jGyJtG+SWiK6dcvqPkz73wj+ZFaPXHo+6lKli
7CGGZ4dOgqxXL4BD35HhJOGljcfTlAWrQ5H0TYoV7o+eGEYS+4D5QkikE1E1
AIP6QOKjMuy6hm4c8mmyrlUgnPRNctcNu4vgh4hDV4WeDbl7jgrypi6qemBA
sC9fr9mntFZPyeuDuesU0CaVllCOVFXMC7jGpIrvrR3sQJuAZRGyFO7Ztzya
J59j1DOPR6I4q0INYd8VCNCZ2BSyV0zacwPIybTAMYxeAm2khHbJWWxMk5Ah
O3S4AkepRHlBPuhZnIaDy9mIUANsC4No0MuYT7Rmb5asTEZwWFXQMDPqyWsG
HbDEOCoGL+agWVIk0apBXWTM8QxP024GFDAZ2cBecRMs+9StbMCAVLrC9BAn
fTdoZ3JL7+aG/mSwIyaEqaB7Rpm1aauezpfBOCbOeUqdF7DFpAohE2DWqKg7
7UJA/0lagCfOS0JxTUhLQw9adegBFQebG19B+UrgRcaYK/LS0stqJeI74/Ca
u7s/Xn48PT2/vARc6ndfPf4WIRFDRVqbkGFoHoa1oMud/oiET+xTVcgEa+8N
6gN6iAeQVVpbzkXXaZNkbLRkVMvS1WuGodYqEYj+JxR/LKQYHWNqdd1KSeJ6
FAV4pBQpMTYV0IXQo6wsBwLCIsprFfjKMBoBIn1kMKMEuSBdiQkiyQ1mpkQd
GkjUk8Bsr5xLf9QMi3mAA8STuN2SDoyKkW2iuJaJtmR0GE5ayn5mdpCso7jS
a2d2o0EdHH7yFxiDRr6FNdAMcJuaacD8p7kmGU77bayicJJvRFkazkQbTuwi
gYiWfMVcNBpmLy3tLuqO7PmP3FnLzz15Puq9gCKVWeG5sxgDCETbOu6261UH
NyS3RPNSipuRPRAKSjJYYboZN9W3GPDPcORurpC54NcZCwfRF+cjTpODAoTF
CUTgEjht5xYBLKc9OnzU9IlILia+wbgGnd8jjoF1bpAJu0VP+DXnErVTOmTO
UKIeyUCF+gYGmXt7x6axUzZxStpQX+TqNU/m43xq2FooLsNHb7SontQWncBc
OYGVBZStNv6HMhLJJR8g05eHfrCTIw3+Uf2bHLPymFebcBNFgiFFGJVN/WAM
loxbQASpnBM6+7QXLuFUgO21fZOsn5TZUKAR3f9MnLhRknlnD23UczM029Lo
rQSizNArlrGyNCkaiBH2dcFCQuL5Rh/HUwruSXxHMGGfDF82ituwbLEOC0ic
mOzh3R2G+FCEraGJsY5UFur+fohNzAQNJtshwzSYfzeW8i6nelnifUguMdAo
NDtZ/4Fl1bKQ/p4Ra7JtIimbBYshyKBQzAQHrJmpkcgWLo4pmq40WKxULACJ
Tj1yJ1P+NIkbMpSNoHv5JRZjp1y4ZqOEptQV69MEo7moUHyGaTzzM0mmyoqZ
AgyZ8GOJk8LIk54d4ZCb7OHK1DGDKEFUzT3YQK04qCPmrqc+W5DWZAvDFl7J
b6qC4uVeY8m+552wE3cwxbeoZhJW4C+w2uYBSZBUneBXO564pLRj/SOsoUkA
cncFh7Kf7YNzsNP+DyctrXw8D5Mo6pExTGammimMnhV6o+BFanZa9SjwKtbS
1fS2qLrGZszFjekwE+U6nQLAq5AQgtVrcPa5f4ycSpIggKK25kz0crtJl3GA
/u5Fl0mKDN78KV7G/XAbHqq4N94LK9u0hlYCh4ZEVC1t/ery4kG0T5ltIiGR
OgpmMaqYqtEV2ByBrvGaIeVaZR6GH2VbN0yQOpuD45K5bksoes1PKQGbDmEx
rAAZW1IVaXgx99e1m4cRrr+sD2PteoAXbrxfSwqCwUah3t5LEALMVFdsOLGn
GK0XSBqP+qmYw+USOQtyiUo5RsGPZSF9krrV/O97oIBJPyuK4VrLquD+0SxA
ARIMinSBKNXF2cUlIJd7LAWtTD6FmVYZI9roZBfyFlcd+4IKDkp6Cs5FjVkD
0tAN4OqaM4j5nqPNItrvEmfh08CNDYbxc2Z5fHXnRNdwtldn3StU5HXLJwr0
nClX5rcSjQSzwsA22iJa9vozZKxl6BfHJCEFWiXLMt80TMpterAlnD3HcHPT
4eytVazcGHiCqRwUOlogU6tzvzU4gUw5Y1PRhzk12vPE4b/M9gjVUs2IFsOh
G2EoS3+WQ5YEzVZV7b0KMLhBe4NpDzObGlIrJIldFEWD2HA+yb0YfDSVmQSp
ot7kUjLFrGfJh5/aOA/DPYpaLOqkIHNY4j9CiV/ETjQp3GiHc6jPJ3NxRjqF
TTNrqGhzhkjmGqM844pVHHmQaaFQPNawLHbruNrPNRzXtFqwxZC1tHSDjS4w
NnEjozsWDN63wZUqHCMdaRVb2Szil7Z+mSUp6GZSzlDoMsfVwpxRepaJYYa1
CJA3sW39zRLftBWON7b9CIuC9PyZV+yinIW4wYVh50MKxaZMMPovPGvqNFOx
DVOukIocDC+L8ALlNUtCKbcxzQJKwebZTKyj5GBZrigD2De0Epjnmw21NL9b
XZTEu4f+FzGy6Rg63k54+GDTxZQHvQG9kATxhbG0UVvWNd1FdEDMf5uIpUON
w4e3pGmdug2xG4j1GhR+/DknhNWmceq/9+aQpLGvs96QyTgpBIGN/69kvqOv
CzMoXC7ELHm2PMfr8zCge5Rp1wvGakhbIhOnVgxDf2gnbbcJVTeNNEKbaS2j
EAEiSXenKYfzgEuEOF5q0iu/+8Jm1wh02sZrhLkGCQSFzeEAGxTSZ4L2NXHJ
OA1zar1eI3V+NX5LRluNK6RaWh/zcPnDkO0ljrh6c4nEGv0DSbVvv/76Gwq6
JLIY4DHmmMMdUjTcYYl8Pg/HSJJ8VzZOJz3ujVTmtV+AlnNdK4ui5ZoMOnFQ
r0wXGTV+WyvYC5kh4MKwpIJLXzpPIn/fX5A5DkxMmWe2CQJmQxCitv5eR8pp
DvaSrzVD4hH/Agp99c03x0g7wq9tsmrFSQT2e/gOWG3ctDEjxRBdy6omCD+m
z65lsGVdAxic9hWx2xOUKReZ4q4ANib58OKKl7ICnTkElzj8jrUlLoIAzawn
qqz2CMnRQu2l60htkDraGKZTVskoVIbsSk0QRTkm+Fh0b1ggUt9Jh6zk0oty
QApu6kcsFAdpJ22zgrkRM8JDMNQRrKbS5vv9r0aJ9TyzrDgKGgLdVXhxAHqr
S3NokM9ItIQaiMxF1drvLEGTFEtwLf0+cfybvSBMT5ZOLB54JMXd6HHYELwD
ECbtE18HIK50aYlLAAEINIZgjvZSt6tdZKU+NyhyO3RfJSk5kRsrkAqgVtU+
DPpIjs5arqxtTHKNTF6r7ITroBIrMpFgd+vdDReXuVY0C5VDTc7hv0uEDzWS
a4oXb5NuCEv1SS5wGwdzzaV0qE4td1cITK1UKVwy0Hrux9ViEWootnLtg4kh
mkaM6BQlMltO9/6RklJUkxYUky3eeEqQzGJbnkLL+FlFvubjAwVaC/vJ+NS+
SWrAfIEqvL2emR4PNbgIWnpWmungMYE9mYADlcVHsboLGDKcsNaqh1mr9Nkh
O2C/cZKh0NqjjJUOCmOxwiAIbi5nv7OTATnEIP6G6KxgizjMRNB0bHPBOovi
Ex/2CW9QF2Rq41ConExu5gEmdFo8GzFUtUd9RyQ2/uKcedyRYLmIHxq+uytv
uFmZSR2ks5WhtHzMOj46NEXLkKMI/TTHcbZyjQ0hAXRrxnB0gzEnNM6uFXAJ
d5g0GINnOMQXC57gwKRzVjrE+72LDK2Ed6PAvND+xBZQOI61V7y4Z3DHGYbi
hNvQACplvFGmAJfYp3qIgxBIywQkvzO3xeyP1uSv+iHnoWxVE6uR4W1wnjC8
lVNpoVdwnu3PoA/+Z3FPPqw3sYOnVFaYS4CGWJ0Oxkad+Cq10VJzl6m/0qLr
dG7V6zJl0rQRL+uzKg6RBcU6oVljkcLi7jRXs/lYM0pC9au57onwIiS8D5tm
VXxpF2NBkPftPTxjNpWxu30Mqigq6DTOYPFsQzb2cXq0DqTO4JmPwZNEuyY4
TOK7gi2hIA7sy/CILB0mLqPs4DcpPNDMDFu95PKBSnwj7qlmBpYkpnEpp7kA
/2+T/oPeLoKg8l0McQCOJNtigo4nkkinuKaeI8IQKvPv/hMuz4qd0s/6w6cs
s7koMA2KOKi0RqkwW9V0axZfGmLfZKxnmJlmzKupxE+sK8STc3Ffmc0NFzcE
hj9wfciipuhzrmWEoXUGwQiPs1yzW/cujpnk4/Ef9sRa8P5mtjU5s9/2F8Rc
m4ElRZiFBD0bCU3HhOkMBjw/S708vZ47f3h69u4RexsZe4xjqP3gLtXB4Qgj
8vZ8zkFvP27l4TKMrkN6AZxmbnjaea8zOA+ZeqtgcI9TreAfkKXGINHe0A2O
ICRvYuAo2Bl2KTUivVDdQxtQAmTZWe9Os/SiHsvxBQJHxDtMqE1NN/PNCd8+
3CpU6nBtEqIOiYg3cRnJDSqscESUsjirhqdxhkGLOVtZiY36Mxf289/cNcWR
Z5Y2iGuGzFbN0Wu4D4iXBZ0XhoJqv2SYB5qFUBmVAqSKgbiD+EMLuhvPeUZM
++TyioZXewl6lR+eOKnXtbTWJBIHBww0JqeV0+uiGJKVTJfPkuydYCn56E91
uBWnsnsPgDOtgK/wUwWBS1KnTJqBKUDpj23nHuX+GDYJo4Fxk3Av3VmQfEk1
xiFq5rwlCzOsIredazeiWilVBUlp2K4nOsFo573hQFJLKTYbz/CnmCfUs+m/
OROaUnQLE5/qKIaQIZ35WoaTfEy75fusd/dF0sWMLE/Mn5Ff7xqBhKaqbgDC
GQ5V7fWuZ8hJ+SHGJB1MWe3h7njEjtzvpM3yhbF2NuwUnOwZn17F0NBFmHDv
uAIsDKi32bC/Lp4Bp5M2Npk/1keq4YVVKJYcqNa4bG/qqU3lTdfDCKMYrlZh
7PTMIMqSCup3V/RwRCES5vSBUIotZ3+ofXJiwrRVx+N0iYigNSvkgJNLG0DU
RvRGhYuTqpdLFunMN4AuPNANAl9Y+wPvH8yiGMltGvHCK6INz4e0gbB70JPR
/uTeXtVGO1b5j2E6R3IBx3tZ0kJuB9TGNGulsXRaGJUxs9vkNriAtbFr5Ebs
kmXSzSu5hv6Nd2q/w5DifOAjbO0mDgxwyPpbkhvd8ezv5SDstHWKg4AQMP3C
LnBaMSsy5DKzMcrsY8SutV8yl+kdI1wvK+SwpUFEr0n+/Jk/57b/fsoojYXV
EW1j1YEiSS5I8q+laBvbsTPLH8jtPYOG337WTFwEwSOJnNHq+iMYs4VfBb2M
aNUGWphB11FNkTXTcCv2jstbaHkg1byrZY7hvnb5hfr11KeGtgXkhtusrMMn
1XmDaYzKveQGpzcM9b+UxfxQG24iVqaLiCmeD1W1QalyCKw+Ff77JaL/Upqa
rkIvd38C9PYgql3l5Do8QJP6nSbuMj6bA0PlBsOAexrQlkmHxpFo2COpA4NQ
0I76Sh8rBxzBXHTWJ2uPdpdeX/hVaHm9bAXmw5ey4rIJPc1pNdeWIdlWo3NA
6gAh8WvG5PrGxt5KCVo/TSFGWUQDhMSpbivOqeOZZikSPSFnnN8IFGx6YZuN
rRvYDl2EvE2g0nvw2+AM8lxFcbRCWGDAYMt1D6+R48PQa6nSl2fYR9NIv1P/
DhfRDVyhEmz7vdeuJMeeSXE87bU95CC84OXa7UKCKgvuK3+DDLSEdVyBatAy
4NpwC2oy+zT0rJOYtjrTgi9yzV9dvX0T46WL/UqxTnvljAnjL0cJxzPmPALE
OCa6H6pEQWpMH0jQBPUrs0sxL8RW7D+xByQzQOOVCgZcTHubo2Lvj7VmP9YG
ssvdz3POKHTEE4Xgn2I5myv4dj/FjItmNnopjCOfd3Hwu47p7E0DFLiLBDxZ
3ZXS91JPCzpaXHPQV4EPQ8CZjuB81BtyQdZ83C/TO8xyW3uOhQUkFEYIcLV8
WDzq30iU5QOJ7JoAWo7PtVbtBHsbJiVPbEW2jZBqsBudQnuj9JzWqP7ECk0c
yCZOJuY5LeN1Knu1mqIsq1u9YVihzgFakniMY9YE4uglhddBsMeP1zm7+cPe
zF0p2awcaZW5zJia4p3EUVCnPHJqnZqdeJcUT/7VdgmZOKijtncpAWlpXzaH
AgFLe/SZQ8btIa5ARGylQt28pL2SH/dgUzbCM7YJIR1IuunW8QBATGJhlpKO
8sPd70lLzd+u2u+JGceSL/9D5lX9jPUsJWEp6UmYJTxBBs7GDPJYVtV4f5PO
rcusPh3BkuLk70q3jokAy5Ck/cmJnuqDCbvQ/pyEWIFJw8C8MqnKQlzTNKuG
7jL1SpwZnjgifbWcGJIbZ7GTZFEpBtFU4F4vVtHEvrHkiJP+vDCD1epNuMNs
3HY6Kjl9pY2H2uPyC+Pyuy8Ck/fGNzywPz+wa177chdKa+FkEmNSe0AXM4kZ
djHQ4+wISo47haTJ1VybasOWJs5eE8g1D/4OIIUs9u+GYRiWSra3yK1ndDp2
e7Vg9gp29rWgw5ieTNdtWU57Io/Ei6OWYsB/zwASCmcaImqzkOmOMfkXRzlk
AgTB2UuTlhCWNXFVW8isPZs6GOeQ27jjmUkcrJI4yiyCZk8bym06PIqbd/Rl
w8IWFeyymM95HB+x48LxmG9cdEz7XO30NO0OQB00yYBQA3KlAZz/FDyyDIZB
gjYFW8yq6qYgT2NXcsH97u6Pp+/f/8Pr8/HlT+9Ow2DOx1//7gggjK++eTrB
P598/fTz58zgqOxJ8yxlgZf2SDZSvBU3hEr2Wwf/z+SiHAsTgBSOUXKvQzMF
qbR77aNXlvSSEj6Pl+82FixxRWcwnT/cNHxgOFdmWHbxxcLdBKFTJTqGFDwu
KwEM9qAMxu7IrmfEclDpwlRdGUyHl0t9rciwd7mIYm53lkeJ6S5LHegEX+Vl
zFCMmfxhvY1d89rHcYaDZAdP/u3PXjo7uUT2YBB5hiJI7112WjpdKOmfl5ze
P2K+k7hg2hIfg/wsG/brSAc6EayTFGk62aZbE4P/58FNjFIqqC0w4Fg4vTsK
l73L0Vk5Wbnsn7dIf/194dvFpKqvMU+Hh/vh+pN/ebhs203z7Ohou91O7CtH
+Aop7aMV665FdcSPIH/vNDZzoYgTr+RjHyBgce7u3rw/OXv97iWGo6BwNvUH
1vWCW0IsMyE5WAxHazDQZReXdk2H300npKaPkGLeXh9xM8mR8MbR02+/fqSN
uVYgPe3hnDPMb9GOtN7VBr1caTIZpDcXMAF8MZhuZNfMNSqMwynEwRJTSNYu
5ba55KI5LHU8HvPF9ZwKDqcblnL3hUX5Y822qkE8vzw9uTjvj9Zd+hWT9Kvj
x9+Nj5+OH38bGnrtbi2SpfDpd7Tx7BQTZKCORW45x/iKWH8OtfGPRU08WuBW
xhPgHsK0ieHARknNNDdeb0mdruXiVoHkSIbObtqS/+Jp6HHoifVEnjy3aMsS
eqrxehtFx4FcQCvpSeJFUmNrCrngJ9Tdin/96uTq1cnb8av3Hy/PIdrQbeB2
g/K3NhfDlZq462dskkoSImWSBvr9z0l3P50WKtaA97d9K2CZnGug5AeZYfoV
XxQkmQ2Z9c0XcvbBWLBk8DrmbmdA8atlVzf038kBD7XJe73S/tn//l/y/5BY
PUmniIbJqfsaM/je5FhQHAsnRy4LisuS0bhJ+TdcvjYZLmUwOlrvWA6unEC+
QjLexomANzZabuY3hdgilnLkimQeBHnwrdHL5peeMDIYSBjvbkZ5/zYAu56s
57K4Fc8sD+IY5hDkChBtDlwCZ/Urq9OK4CcHuujnw+lhOtFO3SvcLSIuckRb
pfkQufYtieYSWh2kgynBeL21IYOHiXqNUe+5Y9eStKF7hJaeXqMp0aTcR2Z4
g2avhrW/ihV5AaJ+E6BC7Iot+oDx5KoHnjeWW692LA4whEvq2WvNxem8M+Jq
vU5ZDbmFW+GCVj4QncbVvydam/VCABMaN17URU8av5NDONEbPPY3vMdYv3A9
X9Lewp4r0JZ5eilwmW4lremsd3Xh5rHCt+CZstMdb8uuFwmdQTKmvHd1oEjN
L/Fu75DiRUnGeAOkKy4fx/1aWjjWecH6lm3tNvBfjUbxUBnOJx34GAZuM1mS
EVtmFGwcmNmIYKh+yWbx7QQFO+EWHyWtPmiYXdnVGriHHPAPz1ggvjY8FGnS
IUxRi9W4eHWtJRsE6w8vTh+xdxlb3plPAFnHDp9XmBHykAzgI+lrDF87j+2v
MUH+koKaTfbw9fnly0eCnJRLA+sbrs+P80u3BWzoZOXWo/w9+QVngLZiNx/L
grULxYDj/AdXF7SQm5tqlJ9jYlhD3+BV0IcfitkSq3pOhIcssq+Av1dTosFz
X/8ZTsI7v81/ghN7VaAzHRul7/wXgAqfk4TT609XVTcnb56EdkxOTu1gq5/X
ftvwTIELRy4cfDp8ukLoSl4b2pz0jTlvc5TrqpJr80b5KwRVRGC5/VKoMs7f
ennMmb/odnMKLwcjl+krb/xtkZ919QI1BoQXJ/PbogHMINQesNNuvstfutWi
GGnWHTQjPbRZ5m9IKZQ/V7SE1YpWigYImVd05tfVjC9M+Vu33nwv9Q2RZCXO
W2LyJZHtnadTKw8t7y1I71fhG/ef4Fs68/xdxYOulzjsF6QEKWh+yHMg5H2X
y+La3xT5+2XbdDqCmP6MA88/eCJxvXKj/G31MznoDqcwpwP6gKRH+KscgnEF
sdfqZ6LbjaP4IG4QXY5ABJdEtUu/an/GEf345FROrSCLRCanA3L0gtTo0oPX
ZIWny2L8Q9GV+SWt71V3veQnfXArIvTltpjd2HPeIoNQAtW3ZsLE5cXt/kB6
qiaN8ZNrGtLnydGdUUT9E19cEMRLh2PQh899+WcMxKBvdKhm/1Aty/zHYuXt
IC85gsi+yA/7XLhsXv/189Acy1Xmm5rhT9Cf2yrWPVJl+iyCuE2lonfm+cd3
Z2/Of/96fDbZya7GuKMHkjNGPBE8KZ3gqUGp3Y8sg23+6WXvAQiqxnJJz1i+
P0ZzBpIXDfvdr0uZHsPVu6QszZfomhpNR1m1sbUTeThmUtg29lIMqpcYtiJt
ydhbs93Wl/gGlp5IbnVRvxtZ+Ft283r309r1Qmz5uWkx5jPsQnL1z+U+l+IT
t01xLpWnNIXH66yHMKGGybCH/LbgV5KPhv92lg0+CY8rtKFGwhu+tzbcqsUz
iqTRmc7N2oKefvXkWGr94U4Xrp6h8/PLJosr7d04Tl+/lhlfSXdNqGuG4avh
ksLQ95p9/PBGL5kONz30xkN+/PBa74PLJUAnyzWv+GqgEo97yNfANK0YtIzL
LJotdZq8kLFrVez5CHe3alFab2AjKrz/8Prl63egwzdf/+5rpOMqK8tEWFYM
4NQhDmmJTvFvKO1IjsHnNlM8zeWhWS1pbdvrW+P4VpttMQ3XYzSCAOStuGpn
wgvSQ2H2zaS+w+ApbMsSAnt7M++dKf3d5DFWtscIk+z00MYlKSVT8nGCMgxq
oaBkxb/NLZhIdirHICu3VGdv+aE8RXyECSgcO/BGhj0RI23pseZSVFA0X4aG
zPxPls/R73NCB4XrT5Nlu179CVNxuWrYP4w8WSJn8OzUsKjBuQURWXu77VH3
Vtk4hpQVbGvMuH9KlvUnXGeVtUmnrAyiaIbcJMh+ZLhQypRyPIrrDJrF4+kw
TH1khwjwJ2N2w4IlG9e2RBmuhCoQqcGtXGLgMzszAcGlJ2aqraxCXBH1D5Og
7niUzYYnqkklc5tEds9yu95K+saNLfaQLZyQxi91D1wqlWIGqgop6lRHhWfy
zX6El0BtFmJJkv6ghktKjGBD8iZhwziHxB5qUAnJ9zdhyBdbXK4SlIrI52RQ
qO7feL8hggLcqu48J2EYs6WIOK6JtDYMjg2kdBn3JvwotxxS+3170XcUwKl1
6PC8xzCSeBXr/k1aaPPaN5PRUPQsJcnO8Jl8qqWVkCBAAtvn3lRlYx1tKh5C
/pC/Lr9+JBGUlc3T0zagLKdK3f6VfRL4hh66+He7/dV6uLQ5JRVa5T0MqQya
SwYnSpHOTKwVctPfMoPqXZMGjQrftuuiJJVDptWuCY+cL08ka1WBdfiuKIZn
FKFleHhqUJI9raiVl0Yq0KHuHTbcPyC+956CP2mLyAKhJFocQ8W3QwLKZduW
A063XzTpQJ1xFsxjmmuy5yXLmFDkVbQGAGnVc7EdWcE6MzCSEPSwBmfPxPfd
EBk0emib4o5KAmI0xPVVtxZ8O0VSiBfT03bDycUG4t1pYcsuBiVD8ojXWQ4b
z+XZowMPz3oPT6/qrOwp0pJlc77YWpgU65W17D1DcjPu5tHFFXXA7vLwafE3
4gzJZPQla5q0hWEYhQRAAUNGJFVP33eKy4g7EiLGlvXMZqfaxbk93dNP3/Wm
NkmbJW9PtUOmvRbJ0OVhWXkvdAogO8gVj6chGemj/W3oKqtuPYZSRj7tojuz
dfGq6LRDKUvx/cJqKM/rqJkcs+hHg4x1oKVVt1OtJ5YjBF/2fkNeJZekRlA5
CaRdmBzxNMHkkdHP9no35HlNv1gRvI4hLjbeuJNd+nZ8KqVwDHFF4qJA8agI
KIIVK7Epl+VHkgFTKN9MbsBu9pdT9ObN9yKxLtpCgzy9UFRjf07+B4MYc5DZ
t5RXy/51h6Gj2nAzFwpP/Ttzr8i5msz97dEf9h8HqU1uH5+EdelDyIeAoav0
0iFZ5Si5TrMRuBE39BJZAUjMTHfzFQa5XWGQXDKvaDNzN6ee8TSMUksuI1XA
Z3ycDO6SWxbZiUzRNLxygwxC8MKFpBzFRkciY9BkaLeLI2rMI14V01qLQ8nk
4OQyWTg3GGqPy1v6ILVGG98NQyNR7LwH8lIb3zcHe8Iuo7u7TUD8OxXgHqNk
3PnQ9EB94V6cSe/PAYWIpIt6ugFypqkh5T6emELG/FlsRYkNmUirSKtXuOxh
DwIHI3/o1eFx3KXHg03SPmni6oLYCj283L6HEpx0v7FRKGbEZ9oRwfcKCE/i
s0sE4I6r+Zsh9zfhs6M/iAecSSrGIBVLuR+sf93d4TttRGOm3VUFEBZB//Sl
ON5BF5RO0SeCoKtam3ph17tJiSBARg7DDNO5H8kF3mM8l8GUHD1iQkkcySxn
9nPSD5H4GahA6YxNabhzYV5KnBiswySGLMBJFeOm9Oz1aBVjEkAy0jhIJ2sT
unutBRw7yOBEKO8B0lsv8ZT2Omk5lhAQAYiW99MlONRveVKRNnCED2wQMH89
mZeRXUXDTnZAnxuUtI5T5FghTm0MDKf1TBT7r/kHHNiTEj5i8NPRH0aWY0Le
Jl1pmPI3kRFgCYRqlGBLEu+7d5Ix9MsOpVMSKPtpuMTS2i9CPXUUQel8kzrK
sdKqKQW7pXgt+ykXto890Ae7TU9Oeeq4IP6yUBOLGLD87u7q5OX47JSzrSdl
uPC3DaZjTzuCkwMVQsupxJ+W05F79kxCbOc20nLYiiJ6SC6uzXt+ELMg1z6R
HpIAGvkqnpo7yf4P3H/Lx8i/AAA=

-->
</rfc>