From owner-ietf-openproxy Fri Jul 21 15:38:15 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA21677 for ietf-openproxy-bks; Fri, 21 Jul 2000 15:38:15 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA21673 for ; Fri, 21 Jul 2000 15:38:14 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 21 Jul 2000 16:40:15 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 21 Jul 2000 16:40:08 -0600 From: "Hilarie Orman" To: Subject: Welcome to the openproxy mailing list Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_A7FFEB5F.D3B2D891" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_A7FFEB5F.D3B2D891 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable This discussion group is the evolution of the "cache" group that led to the Internet draft on Extensible Proxy Services Framework in July, 2000. Contributors from Novell, Sun, and Digisle developed the draft for public discussion. This is the place public commentary on the draft, the issues, the platform, the services, the language, etc. At this time the names being considered for the DNS domain devoted to the topic are extproxy.org, opencache.org, and epsfw.org. Watch here for announcement of the permanent home of the website, which is temporarily at http://www.cs.utah.edu/~horman/openproxy.html. Hilarie Orman Novell --=_A7FFEB5F.D3B2D891 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This discussion group is the evolution of the "cache" group
that led to the Internet draft on Extensible Proxy Services
Framework in July, 2000.  Contributors from Novell, Sun,=20 and
Digisle developed the draft for public discussion.
 
This is the place public commentary on the draft, the issues,
the platform, the services, the language, etc.
 
At this time the names being considered for the DNS domain
devoted to the topic are extproxy.org, opencache.org, and
epsfw.org.  Watch here for announcement of the permanent
home of the website, which is temporarily at
http://www.cs.utah.e= du/~horman/openproxy.html.
 
Hilarie Orman
Novell
 
--=_A7FFEB5F.D3B2D891-- From owner-ietf-openproxy Fri Jul 21 15:47:01 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA21845 for ietf-openproxy-bks; Fri, 21 Jul 2000 15:47:01 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA21841 for ; Fri, 21 Jul 2000 15:46:59 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 21 Jul 2000 16:49:04 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 21 Jul 2000 16:48:55 -0600 From: "Hilarie Orman" To: Subject: Workshop announcement Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8AD2C670.DDBCD69E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_8AD2C670.DDBCD69E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable CFP: Open Proxy Workshop, September 13, 2000 Call for Participation: Workshop on Sophisticated Content Services for the Network: Extensible Proxies September 13, 2000 San Jose Convention Center San Jose, California This workshop will help to define a new platform for the Internet, one = that is essential for engineering the delivery of sophisticated content forms and is also = essential for bringing a new level of sophistication to content delivery. We are seeking participant= s who can bring to bear architectural innovations, new services ideas, and to either inspire = or be inspired by a new direction in the evolution of the Internet.=20 In today's Internet, the infrastructure creating the "the net" is pointing = towards a new network service model. The Web is becoming clients or user agents that consume = information, content servers that provide the basic information and units of Web = infrastructure which are the Proxies (or Proxy-Cache). These critical infrastructure devices = provide the opportunity for enhanced services that expand the value of content on the Internet. = Examples of such services are:=20 content adjustment - adjusting and/or assembling the content = ultimately being delivered to the user. Today we see this in content assembly for = advertising.=20 presentation adjustment - modifying the content presentation to be = more suitable for the client. Today we have WAP and other gateways to adjust content.=20= semantic management - evaluate content against classification = criteria such as virus detection, topic, legality, etc.=20 Extending the notion of content services leads us to operations such = as:=20 Data dependent cache functioning - cache management strategy is a = function of the nature of the cached data. Content providers are already acting on = the requirements for caching streaming multimedia data.=20 Web accounting - tracking Web usage independently of the content = server or user client.=20 Multiple network sharing - objects obtained from a data network can, = for example, feed a broadcast system.=20 A recent Internet-Draft (EPSFW, http://www.ietf.org/internet-drafts/draft-t= omlinson-epsfw-00.txt) proposed an architectural framework for standardizing the components and = APIs that can be used to build these services. This is the Extensible Proxy Services = Framework.=20 We are holding a working to present and discuss concepts needed for = standardizing=20 components in the Proxy system.=20 Suggested areas for papers or panels are=20 High-performance architecture requirements and engineering criteria=20 Innovative services on proxy platforms (e.g. messaging, geographic = positioning, etc.)=20 Languages for extensible services=20 Dynamic service extensions: delivery, loading, etc.=20 New communication protocols=20 Other new platform architectures for Internet infrastructure=20 Papers and panels must be submitted by August 31, 2000. Please send a = title and abstract for papers to Michael Condry (condry@eng.sun.com); panel proposals should = include title, abstract, and names of committed panelists and should be = sent to Hilarie Orman (horman@novell.com). Responses will be sent by = September 3, 2000.=20 Registration information will be available at the Extensible Proxy = website, http://www.cs.utah.edu/~horman/opencache.html. --=_8AD2C670.DDBCD69E Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
CFP: Open Proxy Workshop, September 13, 2000
 
           &nbs= p;         =20 Call for Participation: Workshop=20 on
           &nb= sp;    =20 Sophisticated Content Services for the=20 Network:
          &nb= sp;            =     =20 Extensible=20 Proxies
          &nbs= p;            &= nbsp;  =20 September 13,=20 2000
           &= nbsp;           =20 San Jose Convention=20 Center
           = ;            &n= bsp;   =20 San Jose, California
 
This workshop will help to define a new platform for the Internet, = one that=20 is essential for
engineering the delivery of sophisticated content = forms and=20 is also essential for bringing a
new level of sophistication to = content=20 delivery. We are seeking participants who can bring to
bear architectura= l=20 innovations, new services ideas, and to either inspire or be inspired = by=20 a
new direction in the evolution of the Internet.
 
In today's Internet, the infrastructure creating the "the net" is = pointing=20 towards a new network
service model. The Web is becoming clients or = user=20 agents that consume information,
content servers that provide the = basic=20 information and units of Web infrastructure which are
the Proxies = (or=20 Proxy-Cache). These critical infrastructure devices provide the=20 opportunity
for enhanced services that expand the value of content on = the=20 Internet. Examples of such
services are:
 
     content adjustment - adjusting and/or = assembling=20 the content ultimately being
     delivered to the = user.=20 Today we see this in content assembly for advertising.=20
     presentation adjustment - modifying the = content=20 presentation to be more suitable for
     the = client.=20 Today we have WAP and other gateways to adjust content.=20
     semantic management - evaluate content = against=20 classification criteria such as virus
     = detection,=20 topic, legality, etc.
 
Extending the notion of content services leads us to operations such = as:=20
 
     Data dependent cache functioning - cache=20 management strategy is a function of the
     = nature of=20 the cached data. Content providers are already acting on the=20 requirements
     for caching streaming multimedia = data.=20
     Web accounting - tracking Web usage independen= tly=20 of the content server or user
     client.=20
     Multiple network sharing - objects obtained = from a=20 data network can, for example,
     feed a = broadcast=20 system.
 
A recent Internet-Draft (EPSFW, h= ttp://www.ietf.org/internet-drafts/draft-tomlinson-epsfw-00.txt)
proposed an architectural framework for standardizing the components = and=20 APIs that can be
used to build these services. This is the Extensible Proxy Services=20= Framework.
We are holding a working to present and discuss concepts needed = for=20 standardizing
components in the Proxy system.
 
Suggested areas for papers or panels are
 
High-performance architecture requirements and engineering criteria=20=
Innovative services on proxy platforms (e.g. messaging, geographic=20 positioning, etc.)
Languages for extensible services
Dynamic = service=20 extensions: delivery, loading, etc.
New communication protocols =
Other=20 new platform architectures for Internet infrastructure
 
Papers and panels must be submitted by August 31, 2000. Please send a = title=20 and abstract
for papers to Michael Condry (condry@eng.sun.com); panel = proposals should=20 include title, abstract, and names of committed panelists and should be = sent to=20 Hilarie Orman (horman@novell.com).= =20 Responses will be sent by September 3, 2000.
 
Registration information will be available at the Extensible Proxy=20 website,
http://www.cs.utah.e= du/~horman/opencache.html.
 
--=_8AD2C670.DDBCD69E-- From owner-ietf-openproxy Fri Jul 21 17:14:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA23192 for ietf-openproxy-bks; Fri, 21 Jul 2000 17:14:09 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA23188 for ; Fri, 21 Jul 2000 17:14:08 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07921 for ; Fri, 21 Jul 2000 17:16:51 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id RAA07646 for ; Fri, 21 Jul 2000 17:16:51 -0700 (PDT) Received: from condry.org (remote02.PRC.Sun.COM [129.158.166.202]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M0GmI568408 for ; Fri, 21 Jul 2000 17:16:48 -0700 (PDT) Message-ID: <3978E6CB.81EADAD4@condry.org> Date: Fri, 21 Jul 2000 17:11:55 -0700 From: "Michael W> Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: Welcome to ietf-openproxy References: <200007211239.FAA26289@ns.secondary.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Great thanks to Hilarie for getting this together! Majordomo@imc.org wrote: > -- > > Welcome to the ietf-openproxy mailing list! > > Please save this message for future reference. Thank you. > > If you ever want to remove yourself from this mailing list, > you can send mail to with the following > command in the body of your email message: > > unsubscribe ietf-openproxy "Michael W> Condry" > > Here's the general information for the list you've subscribed to, > in case you don't already have it: > > The ietf-openproxy mailing list is for discussion of the issues delineated > in http://www.ietf.org/internet-drafts/draft-tomlinson-epsfw-00.txt. That > document introduces the problem and solution requirements for a > standardized, open and extensible service environment on caching proxies > which enables them to provide general services that mediate, modify, and > monitor object requests and responses. > > To see what has gone on before you subscribed, please see the mailing > list archive at > http://www.imc.org/ietf-openproxy/ > > To unsubscribe from the ietf-openproxy mailing list, send a message to: > ietf-openproxy-request@imc.org > with the message: > unsubscribe > > If you need to contact a human about this mailing list, please > send a message to: > phoffman@imc.org From owner-ietf-openproxy Wed Jul 26 06:53:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA04325 for ietf-openproxy-bks; Wed, 26 Jul 2000 06:53:20 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04319 for ; Wed, 26 Jul 2000 06:53:18 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA09265 for ; Wed, 26 Jul 2000 06:56:24 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id GAA21611 for ; Wed, 26 Jul 2000 06:56:24 -0700 (PDT) Received: from condry.org (remote01.PRC.Sun.COM [129.158.166.201]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QDuII181070 for ; Wed, 26 Jul 2000 06:56:19 -0700 (PDT) Message-ID: <397EECE3.3F3EF426@condry.org> Date: Wed, 26 Jul 2000 06:51:32 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: [Fwd: ITL Bulletin for July 2000] Content-Type: multipart/mixed; boundary="------------F05E6B544C0527A23C3AF851" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------F05E6B544C0527A23C3AF851 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------F05E6B544C0527A23C3AF851 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from engmail2.Eng.Sun.COM (engmail2.Eng.Sun.COM [129.146.1.25]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6Q02bI119214; Tue, 25 Jul 2000 17:02:43 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA29643 for ; Tue, 25 Jul 2000 17:02:36 -0700 (PDT) Received: from rjmartin.sun.com (d-cam02-152-202.Corp.Sun.COM [129.145.152.202]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6Q02OI119149 for ; Tue, 25 Jul 2000 17:02:24 -0700 (PDT) Message-Id: <4.3.2.7.2.20000725170035.00bbfc60@jurassic.eng.sun.com> X-Sender: rjmartin@jurassic.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jul 2000 17:00:42 -0700 To: stds-dept@eng.sun.com From: Elizabeth Lennon (by way of Roger Martin ) Subject: ITL Bulletin for July 2000 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed To view the bulletin complete with graphics, go to http://www.nist.gov/itl/lab/bulletns/cslbull1.htm. IDENTIFYING CRITICAL PATCHES WITH ICAT By Peter Mell Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Introduction to ICAT Recent attacks on computer systems have intensified the need for relevant, timely information about the attacks and how to prevent them. The Computer Security Division at NIST's Information Technology Laboratory has created a searchable index containing 700 of the most important publicly known computer security vulnerabilities. This index, called ICAT (pronounced eye-cat), helps the user to search for specific vulnerabilities and identify those vulnerabilities that are applicable to their organizations. ICAT provides a summary of selected vulnerabilities and links to patch information specific to each vulnerability. ICAT is available at: http://csrc.nist.gov/icat. Organizations are advised to use a tool such as ICAT to find and fix the vulnerabilities in their networks. ICAT enables systems administrators to find patches for a particular system, but it does not provide a general methodology for applying patches in an organization. This ITL Bulletin presents such guidance. ICAT will be most effective when applied using the suggested methodology. The Common Vulnerabilities and Exposures List The vulnerability information indexed by ICAT pertains to those vulnerabilities included in a standard vulnerability-naming scheme called CVE (Common Vulnerabilities and Exposures). The CVE standard defines a unique name for every widely applicable vulnerability. The list of vulnerability names and information on CVE is maintained by MITRE and can be viewed at: http://cve.mitre.org. The vulnerabilities in the CVE list are chosen by a prominent board of industry, government, and academia members (http://cve.mitre.org/Board_Sponsors/board.html) from the set of vulnerabilities publicly announced on the Internet. While this board's mission is to uniquely name all publicly known vulnerabilities, they are currently targeting recently discovered vulnerabilities and older vulnerabilities that are important enough to be included in commercial intrusion detection and vulnerability scanning products. By leveraging the knowledge and experience of the CVE board, ICAT contains a set of vulnerabilities that are among the most significant. It is important that organizations defend themselves against each one of these vulnerabilities. Since the current list of 700 vulnerabilities is too large for system administrators to manually review, we created ICAT to allow one to search for vulnerabilities applicable to a particular organization's hosts. Uses of ICAT ICAT can help secure a network in a variety of ways, such as the following: Securing a Host with ICAT System administrators can use ICAT to find the vulnerabilities in their systems and to find relevant patches that will secure their systems. There are four steps in using ICAT: * Identify the names and version numbers of any software running on the host (e.g., Solaris 2.5). Of particular importance is the operating system and server software. * Search ICAT for the vulnerabilities that are applicable to the identified set of software. (See below for instructions on searching ICAT.) * Use the ICAT search filters to identify the most dangerous vulnerabilities that exist in the system. These problems should be fixed immediately. * Use the ICAT vulnerability summary pages to find links to relevant patch and vulnerability information. Evaluating a Penetrated System with ICAT When a host is penetrated and the penetration discovered, ICAT can aid system administrators and incident response teams by identifying methods by which a hacker could have entered the host. The related vulnerability entries in ICAT reveal what type of control the attacker could have gained over the machine. Such information can be very useful in restoring a penetrated host. As with any crime, whenever a computer is penetrated, contact the appropriate legal and investigatory authorities. Also, government-sponsored incident response teams are available to assist in recovering from an attack. Government civilian agencies should contact the Federal Incident Response Capability (FedCIRC) at http://www.fedcirc.gov. Commercial organizations may contact the Carnegie Mellon Computer Emergency Response Team/Coordination Center (CERT/CC) at http://www.cert.org. Understanding the Output of Security Products An increasing number of security products identify vulnerabilities and attacks using CVE standard names. Since it uses CVE names, ICAT can be used to research the vulnerabilities and attacks reported by intrusion detection systems and vulnerability scanners. A list of over 25 vendors and computer security organizations using the CVE vulnerability-naming scheme is available at: http://cve.mitre.org/About_CVE/About/othersites.html. Searching ICAT ICAT's Web-based interface is easy to use and is well documented on the Web site. In this section, we present a short introduction to and an example of the ICAT search capability. We suggest that you follow this example on the ICAT Web site. At the ICAT search page, type in a keyword associated with the type of vulnerabilities that you wish to view. Type in the names of software products, operating systems, or devices. For example, type "solaris." To see only entries containing a particular keyword, type "+" before the word. For example, to see only vulnerabilities pertaining to Solaris systems, enter "+solaris." Include software version numbers to further refine a search. Enter "+solaris 2.5" (note the necessary space between keywords). The resulting search will list all Solaris vulnerabilities with those pertaining to version 2.5 at the top of the list. Avoid upper-case letters when searching ICAT, as that will result in a case-sensitive search. At this point, type "+solaris 2.5" into the search text string box and press the "Seek" button. ICAT will return at least 98 vulnerabilities that are applicable to version 2.5 of the Solaris operating system. Before we discuss the search-results page, press the browser back button and we will refine our search using the drop-down menus. At this point, you should have "+solaris 2.5" typed into the search text box and all drop-down menus should be set to "Any." Figure 1: ICAT search page (not available in e-mail version) Use the drop-down menus to refine your search. Each menu permits the user to choose a particular vulnerability attribute. The search engine returns only vulnerabilities that meet the criteria specified in ALL drop-down menu selections. Most of the available drop-down menus and associated choices are shown in Table 1. (See the ICAT documentation for an explanation of the terms in Table 1.) Table 1: Search filters available in the ICAT drop-down search menus (not available in e-mail version) Besides the drop-down menus listed in Table 1, there is also a menu to search the vulnerability entries by vendor names. There are currently 77 vendors represented in the ICAT vulnerability set. At this point, we will refine our current query using the drop-down menus. Using the "Related exploit range" menu, select "Remote" to specify that we want to view only remotely exploitable vulnerabilities. Also, using the "Severity" menu, select "High severity" to specify that we want to look only at vulnerabilities that meet ICAT's definition of high severity (see the documentation for details). A Sample ICAT Entry After creating a search query, press the "Seek" button and ICAT will state the number of search results and a list of vulnerabilities that meet the search criteria. Each vulnerability is identified by a CVE number, a one-line description, and the date on which the vulnerability was first published. Browse through the vulnerabilities and click on "CVE 1999-0210." You are now presented with an ICAT entry that summarizes the vulnerability. The entry is not a complete description of the vulnerability because ICAT is not a vulnerability database. Instead, ICAT summarizes the most important features of the vulnerability. This will enable you to quickly determine whether the vulnerability is applicable to your environment. Several fields will be particularly useful: * the "Summary" line gives a one-line description of the vulnerability, * the "Vulnerable software and versions" line lists the name and version numbers of the vulnerable software, * the "Applicable vendors" line lists the vendors whose software is vulnerable to this problem, * the "Exploitable Range" line tells whether or not a vulnerability can be remotely exploitable, and * the "Loss type" line describes what kind of privilege the vulnerability can give a hacker. If the vulnerability is applicable, one will need to find patch information and a more thorough description of the vulnerability. To fulfill this need, ICAT provides one or more references to patch sites or vulnerability database entries that contain more information. Continuing with our example, click on the hyperlink in the row labeled "Reference 2." This link takes one to the CERT/CC advisory Web site and looks up the particular vulnerability. The CERT/CC advisory thoroughly describes the vulnerability and provides patch information. When you are done browsing the CERT advisory, press the search button on the top menu bar to return to the ICAT search screen. Figure 2: Typical ICAT vulnerability entry (not available in e-mail version) The Importance of Security Advisories While ICAT will aid system administrators by identifying recent vulnerabilities, it is not an early warning system. However, it is important that every organization subscribe to an early warning service. To understand why this is necessary, consider what happens when a hacker publishes a widely applicable attack script on the Internet. Overnight, millions of systems can become completely vulnerable to anyone running the script. In such cases, organizations must be notified very quickly. Several incident response teams send out early warning advisories along with advisories about high-impact vulnerabilities. The advisories describe the vulnerability and how to mitigate or patch the problem. Every organization should monitor these advisories and have a program in place to take appropriate action. Most incident response teams have a mailing list so that new advisories are automatically sent to the appropriate person. Two of the best sources for such advisories are FedCIRC and the CERT/CC. While important, advisories cover only the most critical vulnerabilities. Consequently, monitoring these advisories is not sufficient. Advisories must be used in conjunction with another tool, such as ICAT, that covers a broader range of known vulnerabilities. Guidance on Patching Systems Updating software is one of the most important aspects of maintaining a secure network. It is often overlooked because it seems like a monumental task. For example, how can a single system administrator spend several hours updating each computer at a site with 500 computers? While updating the computers in your network seems overwhelming, this section provides guidance on updating software efficiently. We assume that organizations will be manually installing patches, as this is the most common method today. However, new software is coming to market that allows one to automatically distribute patches throughout an enterprise. Types of Patches Patches are small programs that replace error-ridden code with corrected code. The term "patching" is used to refer to fixing security flaws in software. There are three ways to fix security flaws or to "patch a system": work-arounds, patches, and upgrades. Work-arounds are procedures that a system administrator can use to fix a vulnerability. However, applying work-arounds may limit the functionality of the system being protected. While people generally talk about patching a system to secure it, upgrading to the newest software version is often, but not always, a simple way to ensure that all relevant patches are installed. Three Steps to Patching a Network Step 1: Identify Critical Resources Identify those computers in your network that are critical and update those first. Critical hosts are typically those that are most visible to the outside world, those that store mission-critical data, and those that provide the most critical resources. A typical network's list of critical resources includes external Web sites, routers, firewalls, e-mail servers, DNS servers, and database servers. Step 2: Updating Critical Resources Each critical host should be examined regularly (at least monthly) to determine if any software needs to be updated. All software that an attacker could exploit must be updated regularly. Software in this category includes the operating system, servers or any software that receives network packets, software running as root or administrator, and security software (especially virus checkers). Make a list of such software per host and write down the associated version numbers. Then, find and install the available patches that are to be applied to your version of the software by using ICAT or by visiting the patch site of each vendor for every software package on a host. Each software vendor will have unique instructions on how to install their patches. Be careful to follow their instructions, as patches sometimes must be installed in a strict sequence for the process to work. Step 3: Updating Non-Critical Resources Non-critical hosts are obviously less important to protect than critical hosts. However, an attacker may break into a non-critical host and then use that host to attack critical resources. Thus, the level of security of non-critical hosts is important. Since it is a daunting task to update the software on all non-critical hosts in a network, many systems administrators do not regularly update non-critical hosts that are shielded with external and internal firewalls. The firewalls prevent outside network traffic from being routed to non-critical hosts, which helps protect them from attack. This technique works well but it does not protect against all attacks. Specifically, viruses and Trojan horses (especially those transmitted through e-mail that are typically passed through the firewall) can still attack non-critical hosts. In order to secure non-critical hosts cost-effectively, install firewalls inside your organization to protect groups of non-critical hosts from other parts of the network. This way, if an attacker breaks into a host in your organization, the attacker cannot easily spread their influence to other hosts. Install virus checkers on all non-critical hosts that receive e-mail and configure them to automatically update weekly, if not daily. Lastly, once every year update each non-critical host as defined in step 2. If possible, use a standard configuration for non-critical systems, as this will simplify patching efforts. Life for systems administrators will be made easier if users are trained to perform simple updates on their own machine. For example, users can be trained to periodically use the Microsoft(r) "Windows(r) Update" page to automatically fix security holes in the majority of non-critical host operating systems. Also, systems administrators can advertise that new versions of popular software are available for download. More advanced users will download the new version to get better features and will, as a result, install the latest security patches. Maintaining Patch Records We recommend that every organization maintain a Web server containing all patches they want applied to their software. This enables systems administrators to determine which patches have been approved by their organization. Records should be kept on the software and version numbers on all critical systems as well as which patches have been applied. Automated Patch Dissemination Technology Enterprise management systems are now becoming available that will automatically patch a set of hosts given commands from a single console. Such technology greatly reduces the time involved in installing patches and will greatly enhance the security of organizations using it. However, some organizations may prefer to wait before using this technology as the available solutions are still emerging technologies. Conclusion The ICAT Metabase is a tool that enables one to quickly identify the vulnerabilities that may exist in their systems. ICAT also provides links to relevant patch information. It provides a fine granularity of searching while covering a much larger set of vulnerabilities than is covered by most security advisories. ICAT informs administrators of the most serious threats and enables them to focus patching efforts on those patches that provide the greatest increases in security. ICAT can be an effective tool for improving the security of hosts on a network. (r) Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States and/or other countries. Disclaimer: Any mention of commercial products or reference to commercial organizations is for information only; it does not imply recommendation or endorsement by the National Institute of Standards and Technology nor does it imply that the products mentioned are necessarily the best available for the purpose. ****************************************************** Elizabeth B. Lennon Writer/Editor Information Technology Laboratory National Institute of Standards and Technology 100 Bureau Drive, Stop 8900 Gaithersburg, MD 20899-8900 Telephone (301) 975-2832 Fax (301) 840-1357 ****************************************************** --------------F05E6B544C0527A23C3AF851-- From owner-ietf-openproxy Wed Jul 26 07:06:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA04899 for ietf-openproxy-bks; Wed, 26 Jul 2000 07:06:59 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04891 for ; Wed, 26 Jul 2000 07:06:57 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16078 for ; Wed, 26 Jul 2000 07:10:04 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id HAA24130; Wed, 26 Jul 2000 07:10:03 -0700 (PDT) Received: from condry.org (remote01.PRC.Sun.COM [129.158.166.201]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QE9xI184890; Wed, 26 Jul 2000 07:10:00 -0700 (PDT) Message-ID: <397EF018.EECF37D7@condry.org> Date: Wed, 26 Jul 2000 07:05:12 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: cache@sun.com, ietf-openproxy@imc.org Subject: [Fwd: Few comments about draft-tomlinson-epsfw-0040.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Some feedback -------- Original Message -------- Subject: Few comments about draft-tomlinson-epsfw-0040.txt Date: Wed, 26 Jul 2000 12:53:07 +0200 From: Sylvain DULOUTRE Reply-To: sylvain.duloutre@france.sun.com Organization: Sun Microsystems To: Michael.Condry@eng.sun.com CC: sylvain.duloutre@france.sun.com Hi Michael, Thanks for the update on draft-tomlinson-epsfw-0040.txt. I've not yet "assimilated" all the implications of this framework on the proxy architecture. However, I'm coming back to you with a few comments: About Rule Base Requirements ---------------------- I would add a mechanism to control the order in which rules are evaluated and thus the order of the action execution. Overall results may be unpredictable if there is no way to control when actions are evaluated. I would also add a mechanism to define what rules are evaluated. Different models could be implemented, like "execute all actions whose rules match", or "execute only the action associated with the first rule that matches" (according to the ordering mechanism defined above). About Proxylet requirements -------------------- I don't see any reference to a possible cooperation between proxylets to perform more complex processing. This would probably require some additional mechanisms to name,register, discover and invoke a proxylet from another proxylet. >> The service environment caching proxy SHOULD define a method to allow any external domain that it may proxy to >> dynamically load or update a proxylet library. "dynamically load" probably also implies a mechanism to make the proxylet persistent on the proxy. ICAP ---- In the document, the proxylet functionality and ICAP are clearly distinguished. I think ICAP could be implemented as a proxylet, so I was wondering if we could have also a more general section covering the problems (like trust) with invocation of "remote" services, like ICAP, but no exclusively. That's it for now. -Sylvain From owner-ietf-openproxy Mon Jul 31 14:26:38 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA22204 for ietf-openproxy-bks; Mon, 31 Jul 2000 14:26:38 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22200 for ; Mon, 31 Jul 2000 14:26:37 -0700 (PDT) From: aminil@us.ibm.com Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA05916 for ; Mon, 31 Jul 2000 17:30:07 -0400 Received: from d01ml233.pok.ibm.com (d01ml233.pok.ibm.com [9.117.200.63]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.92) with ESMTP id RAA16884 for ; Mon, 31 Jul 2000 17:30:08 -0400 Importance: Normal Subject: IETF meeting dinner To: ietf-openproxy@imc.org Date: Mon, 31 Jul 2000 17:30:05 -0400 Message-ID: X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.4a |July 24, 2000) at 07/31/2000 05:30:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Extensible Proxy website mentions a dinner (Thursday) at the IETF meeting for interested parties. Has the time and place been decided upon? Thanks, Lisa From owner-ietf-openproxy Mon Jul 31 16:38:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA24480 for ietf-openproxy-bks; Mon, 31 Jul 2000 16:38:10 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA24476 for ; Mon, 31 Jul 2000 16:38:09 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02711; Mon, 31 Jul 2000 16:41:38 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id QAA14008; Mon, 31 Jul 2000 16:41:37 -0700 (PDT) Received: from condry.org (hobo128.Eng.Sun.COM [129.146.31.128]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6VNfX8277860; Mon, 31 Jul 2000 16:41:34 -0700 (PDT) Message-ID: <39860D96.D59265D9@condry.org> Date: Mon, 31 Jul 2000 16:36:54 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: aminil@us.ibm.com CC: ietf-openproxy@imc.org, cache@sun.com Subject: Re: IETF meeting dinner References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Have a reservation at 5:45 on Thursday. Directions to Tambellini's Restaurant: (139 7th St., PGH, PA 15222) >From Convention Center start going West on Penn Ave. towards 9th Street by turning Right. Turn Right onto 7th Street. You can't miss it. Total Distance: 0.3 miles. aminil@us.ibm.com wrote: > The Extensible Proxy website mentions a dinner (Thursday) at the IETF > meeting for interested parties. > > Has the time and place been decided upon? > > Thanks, > Lisa From owner-ietf-openproxy Mon Jul 31 18:04:16 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA26649 for ietf-openproxy-bks; Mon, 31 Jul 2000 18:04:16 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26642 for ; Mon, 31 Jul 2000 18:04:15 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25615 for ; Mon, 31 Jul 2000 18:07:49 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id SAA00219 for ; Mon, 31 Jul 2000 18:07:49 -0700 (PDT) Received: from condry.org (hobo142.Eng.Sun.COM [129.146.31.142]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7117h8290083 for ; Mon, 31 Jul 2000 18:07:43 -0700 (PDT) Message-ID: <398621C8.DCCB24A4@condry.org> Date: Mon, 31 Jul 2000 18:03:04 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: openproxy Subject: [Fwd: BOF, not final] Content-Type: multipart/mixed; boundary="------------7B84F9A05466B18C79FAC499" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------7B84F9A05466B18C79FAC499 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------7B84F9A05466B18C79FAC499 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from engmail3.Eng.Sun.COM (engmail3.Eng.Sun.COM [129.144.170.5]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e710Fm8284488 for ; Mon, 31 Jul 2000 17:15:48 -0700 (PDT) Received: from sunmail1.Sun.COM (sunmail1 [129.145.1.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA24691 for ; Mon, 31 Jul 2000 17:15:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id RAA21062 for ; Mon, 31 Jul 2000 17:15:47 -0700 (PDT) Received: from zealous.cnchost.com (zealous.concentric.net [207.155.252.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19160 for ; Mon, 31 Jul 2000 18:15:46 -0600 (MDT) Received: from whalers.digisle.com (whalers.digisle.com [167.216.128.32]) by zealous.cnchost.com id UAA22761; Mon, 31 Jul 2000 20:15:44 -0400 (EDT) [ConcentricHost SMTP MX 1.15] Errors-To: Received: from guinness.digisle.net (guinness.digisle.net [167.216.152.33]) by whalers.digisle.com (8.9.3/8.9.3/mx) with ESMTP id AAA20807; Tue, 1 Aug 2000 00:15:40 GMT Received: from digisle.net (dhcp-15-to.digisle.com [206.220.224.91]) by guinness.digisle.net (8.9.3/8.9.3/digisle) with ESMTP id AAA02953; Tue, 1 Aug 2000 00:15:38 GMT Message-ID: <398617D8.CD7CE556@digisle.net> Date: Mon, 31 Jul 2000 17:20:40 -0700 From: Dave Farber Organization: Digital Island X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael W. Condry" CC: cache@Sun.COM Subject: Re: BOF, not final References: <39741D00.C51B9324@condry.org> <39748668.1E7A07C7@digisle.net> <3985A2EA.658C8A6C@condry.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael, I sent the note you are responding to a few weeks ago, when you said there would be no BOF. I am now planning to come to the dinner. Also, I was contacted today by Matt Haines of Inktomi. He plans to come to the BOF dinner and the wrec meeting. I'll forward the info to him. Dave "Michael W. Condry" wrote: > > We are going to have then official BOF dinner on Thursday, I thought > you were coming. On Friday, we have time at WREC. > > Now, I have been invited to the private session on working > group futures for applications and will go. > > If not enough folks are interested in the dinner I will just cancel > it > > Dave Farber wrote: > > > If we don't have an official BOF, should we have an unofficial one? > > Wrec is not scheduled either, from what I can see, nor is there an iCAP BOF. > > I'm wondering whether I should even plan to go.... > > > > Dave > > > > "Michael W> Condry" wrote: > > > > > > There is not a final word on the BOF. However, I talked to Patrick, and he said > > > there was significant problem with slots at IETF48. He did not know about > > > our BOF status but he had to turn down 4 BOFs and several extra working > > > group requests because of slot space. > > > > > > Sooooo, its likely that we will not get a BOF this time. However, regardless > > > we may be shooting for a Working group in IETF49! > > > > > > There is a lot of interest here! --------------7B84F9A05466B18C79FAC499-- From owner-ietf-openproxy Wed Aug 2 13:50:09 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA23273 for ietf-openproxy-bks; Wed, 2 Aug 2000 13:50:09 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23269 for ; Wed, 2 Aug 2000 13:50:08 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09643; Wed, 2 Aug 2000 13:53:51 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA19666; Wed, 2 Aug 2000 13:53:50 -0700 (PDT) Received: from condry.org (hobo112.Eng.Sun.COM [129.146.31.112]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e72KrhH208297; Wed, 2 Aug 2000 13:53:44 -0700 (PDT) Message-ID: <39888942.168D40DA@condry.org> Date: Wed, 02 Aug 2000 13:49:06 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: Sumanth CC: openproxy Subject: Re: IETF meeting dinner References: <39860D96.D59265D9@condry.org> <398843C2.7B33B3DF@bigfoot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: No, just come. Do you know the info? For a BOF discussion group, Have a reservation for dinner at 5:45 on Thursday. I hope you can attend. Directions to Tambellini's Restaurant: (139 7th St., PGH, PA 15222) >From Convention Center start going West on Penn Ave. towards 9th Street by turning Right. Turn Right onto 7th Street. Total Distance: 0.3 miles. Sumanth wrote: > Hi Michael, > We are a couple of developers working on an IBM caching proxy product. > We're not attending the > IETF but we're interested in coming to the meeting dinner. Do we need to > register or RSVP for it? > > Thanks, > Sumanth > > Michael W. Condry wrote: > > > Have a reservation at 5:45 on Thursday. > > Directions to Tambellini's Restaurant: (139 7th St., PGH, PA 15222) > > > > >From Convention Center start going West on Penn Ave. towards 9th Street > > by turning Right. Turn Right > > onto 7th Street. You can't miss it. Total Distance: 0.3 miles. > > aminil@us.ibm.com wrote: > > > > > The Extensible Proxy website mentions a dinner (Thursday) at the IETF > > > meeting for interested parties. > > > > > > Has the time and place been decided upon? > > > > > > Thanks, > > > Lisa From owner-ietf-openproxy Thu Aug 3 13:37:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24371 for ietf-openproxy-bks; Thu, 3 Aug 2000 13:37:41 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24367 for ; Thu, 3 Aug 2000 13:37:40 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 4D1541E002 for ; Thu, 3 Aug 2000 16:41:28 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA20558 for ; Thu, 3 Aug 2000 16:41:27 -0400 (EDT) Received: from windsor.research.att.com (localhost [127.0.0.1]) by windsor.research.att.com (8.8.8+Sun/8.8.5) with ESMTP id QAA23444 for ; Thu, 3 Aug 2000 16:41:27 -0400 (EDT) Message-Id: <200008032041.QAA23444@windsor.research.att.com> From: Fred Douglis To: openproxy Subject: Re: IETF meeting dinner In-reply-to: Your message of "Wed, 02 Aug 2000 13:49:06 PDT." <39888942.168D40DA@condry.org> X-URI: http://www.research.att.com/~douglis/ Date: Thu, 03 Aug 2000 16:41:27 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >No, just come. Do you know the info? > >For a BOF discussion group, Have a reservation for dinner at 5:45 on >Thursday. >I hope you can attend. > >Directions to Tambellini's Restaurant: (139 7th St., PGH, PA 15222) >From Convention Center start going West on Penn Ave. towards 9th Street >by turning Right. Turn Right >onto 7th Street. Total Distance: 0.3 miles. Whose name is this under? I called the restaurant to confirm that shorts would be acceptible, but first I tried to identify the group I was joining, and we couldn't figure out what reservation it was. Fred From owner-ietf-openproxy Thu Aug 3 13:55:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24751 for ietf-openproxy-bks; Thu, 3 Aug 2000 13:55:54 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24747 for ; Thu, 3 Aug 2000 13:55:53 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16728; Thu, 3 Aug 2000 13:59:35 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA18075; Thu, 3 Aug 2000 13:59:35 -0700 (PDT) Received: from condry.org (hobo133.Eng.Sun.COM [129.146.31.133]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73KxXH119562; Thu, 3 Aug 2000 13:59:33 -0700 (PDT) Message-ID: <3989DC22.8CB719AC@condry.org> Date: Thu, 03 Aug 2000 13:54:58 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: Fred Douglis CC: openproxy Subject: Re: IETF meeting dinner References: <200008032041.QAA23444@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Its probably under my name (Michael Condry) or the local Sun Admin's name (Mary Ann Willard). Fred Douglis wrote: > >No, just come. Do you know the info? > > > >For a BOF discussion group, Have a reservation for dinner at 5:45 on > >Thursday. > >I hope you can attend. > > > >Directions to Tambellini's Restaurant: (139 7th St., PGH, PA 15222) > >From Convention Center start going West on Penn Ave. towards 9th Street > >by turning Right. Turn Right > >onto 7th Street. Total Distance: 0.3 miles. > > Whose name is this under? I called the restaurant to confirm that shorts > would be acceptible, but first I tried to identify the group I was joining, > and we couldn't figure out what reservation it was. > > Fred From owner-ietf-openproxy Tue Aug 15 15:40:47 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16903 for ietf-openproxy-bks; Tue, 15 Aug 2000 15:40:47 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16899 for ; Tue, 15 Aug 2000 15:40:46 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22348; Tue, 15 Aug 2000 15:40:33 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA06521; Tue, 15 Aug 2000 15:40:32 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.0+Sun/8.11.0) with SMTP id e7FMeSo942823; Tue, 15 Aug 2000 15:40:29 -0700 (PDT) Message-Id: <200008152240.e7FMeSo942823@jurassic.eng.sun.com> Date: Tue, 15 Aug 2000 15:41:08 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Re: What's up? To: cache@Sun.COM, dave@digisle.net Cc: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CaYphFQjtS+Ol7LUMG80/A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just a reminder, ietf-openproxy@imc.org is really the official mailing list. Will the original cache@sun.com team please move there. Send mail to: ietf-openproxy-request@imc.org with subsribe in the body. Or mail Majordomo@imc.org with subsribe ietf-openproxy NAME where NAME is your email. Workshop 1. One paper is in. 2. I am doing a paper on architecture/examples. 3. Dave, can you help to start a panel of "real users" on want are the requirements? 4. Can someone look at the rules? What about following the same model as XML Schemas? Can we use XML Schemas? Others? From owner-ietf-openproxy Fri Aug 25 15:33:41 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA00172 for ietf-openproxy-bks; Fri, 25 Aug 2000 15:33:41 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00167 for ; Fri, 25 Aug 2000 15:33:39 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01708 for ; Fri, 25 Aug 2000 15:34:17 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA28657 for ; Fri, 25 Aug 2000 15:34:17 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.0+Sun/8.11.0) with SMTP id e7PMY9K673624; Fri, 25 Aug 2000 15:34:11 -0700 (PDT) Message-Id: <200008252234.e7PMY9K673624@jurassic.eng.sun.com> Date: Fri, 25 Aug 2000 15:34:53 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Workshop, details. To: ietf-openproxy@imc.org Cc: Cherie.Bibich@Eng.Sun.COM, Juanita.Tapia@Eng.Sun.COM MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Hover_of_Trout_302_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Hover_of_Trout_302_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: e9lpsFNLu+xh62APYJuGBQ== Workshop on Sophisticated Content Services for the Network: Extensible Proxies This is an informal workshop to define a new platform for the Internet, one that is essential for engineering the delivery of sophisticated content forms and is also essential for bringing a new level of sophistication to content delivery. We are seeking participants who can bring to bear architectural innovations, new services ideas, and to either inspire or be inspired by a new direction in the evolution of the Internet. * Where and When * Hotel Accomodations * Registration * September 12, 2000 Dinner * Papers, Panels, and Discussions Where and When: September 13, 2000 Silicon Valley Conference Center 2161 N. First Street San Jose, California Map Hotel Accomodations No formal hotel, some local ones are: Doubletree Hotel 2050 Gateway Place Hanford Hotel San Jose, CA 1755 N 1st St 95110-1047 San Jose, CA 95112 Phone: (408) Phone: (408) 453-3133 453-4000 Registration Process Please confirm with an email to condry@condry.org by Sept 7th. There is no resistration costs. All confirmed attendees will be provided a complementary lunch during the conference. September 12, 2000 Dinner Many attendees will be arriving on September 12. I have a reservation at 7:30 pm at Il Fornaio Cucina Italiana 302 S Market St San Jose, CA 95113 (408) 271-3366 Map Papers, Panels, and Discussions The discussions will focus on issues surrounding the concepts of adding sophistacted services in the network through extensible proxies, the basic requements being defined in the Internet-Draft http://www.ietf.org/internet-drafts/draft-tomlinson-epsfw-00.txt Here are some presentations and panels: We are seeing volenteers for being on the following panels * Security * Common services and operating environment for proxylets and cachelets * Specification methods for dynamic services * Architectural viewpoint: minimalist vs. rich Other Presetations * Active net security * Architecure and Use Cases * Active Names for caching proxies * funnelWeb - Application Layer Active Networking * A Platform for Content Delivery and Enhanced Services --Hover_of_Trout_302_000 Content-Type: APPLICATION/octet-stream; name="workshop.html"; x-unix-mode=0644 Content-Transfer-Encoding: BASE64 Content-Description: workshop.html Content-MD5: RP8taYpGAuEcvsu2IPb+Iw== PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0 cmFuc2l0aW9uYWwvL2VuIj4KPGh0bWw+CjxoZWFkPgogICA8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1pc28tODg1OS0xIj4KICAgPG1ldGEgbmFtZT0iQXV0aG9yIiBjb250 ZW50PSJtaWNoYWVsIGNvbmRyeSI+CiAgIDxtZXRhIG5hbWU9IkdFTkVSQVRP UiIgY29udGVudD0iTW96aWxsYS80LjUxIFtlbl0gKFgxMTsgVTsgU3VuT1Mg NS44IHN1bjR1KSBbTmV0c2NhcGVdIj4KPC9oZWFkPgo8Ym9keSB0ZXh0PSIj MDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBsaW5rPSIjMDAwMEZGIiB2bGlu az0iIzk5MDA2NiIgYWxpbms9IiNGRjAwMDAiPgombmJzcDsKPGNlbnRlcj4K PGR0Pgo8Zm9udCBzaXplPSszPldvcmtzaG9wIG9uPC9mb250PjwvZHQ+PC9j ZW50ZXI+Cgo8Y2VudGVyPgo8ZHQ+Cjxmb250IHNpemU9KzQ+U29waGlzdGlj YXRlZCBDb250ZW50IFNlcnZpY2VzIGZvciB0aGUgTmV0d29yazo8L2ZvbnQ+ PC9kdD48L2NlbnRlcj4KCjxjZW50ZXI+CjxkdD4KPGZvbnQgc2l6ZT0rND5F eHRlbnNpYmxlIFByb3hpZXM8L2ZvbnQ+PC9kdD48L2NlbnRlcj4KCjxwPjxi cj4KPHA+VGhpcyBpcyBhbiBpbmZvcm1hbCB3b3Jrc2hvcCB0byBkZWZpbmUg YSBuZXcgcGxhdGZvcm0gZm9yIHRoZSBJbnRlcm5ldCwKb25lIHRoYXQgaXMg ZXNzZW50aWFsIGZvciBlbmdpbmVlcmluZyB0aGUgZGVsaXZlcnkgb2Ygc29w aGlzdGljYXRlZCBjb250ZW50CmZvcm1zIGFuZCBpcyBhbHNvIGVzc2VudGlh bCBmb3IgYnJpbmdpbmcgYSBuZXcgbGV2ZWwgb2Ygc29waGlzdGljYXRpb24K dG8gY29udGVudCBkZWxpdmVyeS4mbmJzcDsgV2UgYXJlIHNlZWtpbmcgcGFy dGljaXBhbnRzIHdobyBjYW4gYnJpbmcgdG8KYmVhciBhcmNoaXRlY3R1cmFs IGlubm92YXRpb25zLCBuZXcgc2VydmljZXMgaWRlYXMsIGFuZCB0byBlaXRo ZXIgaW5zcGlyZQpvciBiZSBpbnNwaXJlZCBieSBhIG5ldyBkaXJlY3Rpb24g aW4gdGhlIGV2b2x1dGlvbiBvZiB0aGUgSW50ZXJuZXQuCjxicj4mbmJzcDsK PHVsPgo8bGk+CjxhIGhyZWY9IiNXaGVyZSBhbmQgV2hlbiI+V2hlcmUgYW5k IFdoZW48L2E+PC9saT4KCjxsaT4KPGEgaHJlZj0iI0hvdGVsIEFjY29tb2Rh dGlvbnMiPkhvdGVsIEFjY29tb2RhdGlvbnM8L2E+PC9saT4KCjxsaT4KPGEg aHJlZj0iI1JlZ2lzdHJhdGlvbiI+UmVnaXN0cmF0aW9uPC9hPjwvbGk+Cgo8 bGk+CjxhIGhyZWY9IiNTZXB0ZW1iZXIgMTIsIDIwMDAgRGlubmVyIj5TZXB0 ZW1iZXIgMTIsIDIwMDAgRGlubmVyPC9hPjwvbGk+Cgo8bGk+CjxhIGhyZWY9 IiNQYXBlcnMsIFBhbmVscywgYW5kIERpc2N1c3Npb25zIj5QYXBlcnMsIFBh bmVscywgYW5kIERpc2N1c3Npb25zPC9hPjwvbGk+CjwvdWw+Cgo8YnI+Jm5i c3A7CjxwPjxhIE5BTUU9IldoZXJlIGFuZCBXaGVuIj48L2E+PGZvbnQgc2l6 ZT0rMj5XaGVyZSBhbmQgV2hlbjo8L2ZvbnQ+CjxibG9ja3F1b3RlPjxmb250 IHNpemU9KzE+U2VwdGVtYmVyIDEzLCAyMDAwPC9mb250Pgo8YnI+PGZvbnQg c2l6ZT0rMT5TaWxpY29uIFZhbGxleSBDb25mZXJlbmNlIENlbnRlcjwvZm9u dD4KPGJyPjxmb250IHNpemU9KzE+MjE2MSBOLiBGaXJzdCBTdHJlZXQ8L2Zv bnQ+Cjxicj48Zm9udCBzaXplPSsxPlNhbiBKb3NlLCBDYWxpZm9ybmlhPC9m b250Pgo8cD48Zm9udCBzaXplPSsxPjxhIGhyZWY9Imh0dHA6Ly93d3cubWFw cXVlc3QuY29tL2NnaS1iaW4vaWFfZmluZD9saW5rPWJ0d24lMkZ0d24tbWFw X3Jlc3VsdHMmcmFuZG9tPTk3NSZldmVudD1maW5kX3NlYXJjaCZ1aWQ9dWJl YWlhazJsZXpjeTZoZSUzQXJsMXkxMDF6dCZTTlZEYXRhPTNtYWQzLTkuZnkl MjUyOGF0MnU2N18lMjUyOWY4MnU2NyUyNTNiYWg3LSUyNTNkJTI1M2ElMjUy OF8lMjUzZCUyNTNhYmFkNjcyJTI1M2QlMjUzZDFzdTY3MiUyNTNkMCUyQ3Ji JTI1M2I3JmNvdW50cnk9VW5pdGVkK1N0YXRlcyZhZGRyZXNzPTIxNjErTi4r Rmlyc3QrU3RyZWV0JmNpdHk9U2FuK0pvc2UlMkMrQ0EmU3RhdGU9Q0EmWmlw PSZGaW5kK01hcD1HZXQrTWFwIj5NYXA8L2E+PC9mb250PjwvYmxvY2txdW90 ZT4KCjxwPjxicj48YSBOQU1FPSJIb3RlbCBBY2NvbW9kYXRpb25zIj48L2E+ PGZvbnQgc2l6ZT0rMj5Ib3RlbCBBY2NvbW9kYXRpb25zPC9mb250Pgo8YnI+ PGZvbnQgc2l6ZT0rMT5ObyBmb3JtYWwgaG90ZWwsIHNvbWUgbG9jYWwgb25l cyBhcmU6PC9mb250Pgo8YnI+Jm5ic3A7CjxjZW50ZXI+PHRhYmxlIEJPUkRF UiBDT0xTPTIgV0lEVEg9IjYwJSIgTk9TQVZFID4KPHRyIE5PU0FWRT4KPHRk IE5PU0FWRT48Zm9udCBzaXplPSsxPkRvdWJsZXRyZWUgSG90ZWwmbmJzcDs8 L2ZvbnQ+Cjxicj48Zm9udCBzaXplPSsxPjIwNTAgR2F0ZXdheSBQbGFjZTwv Zm9udD4KPGJyPjxmb250IHNpemU9KzE+U2FuIEpvc2UsIENBIDk1MTEwLTEw NDc8L2ZvbnQ+Cjxicj48Zm9udCBzaXplPSsxPlBob25lOiAoNDA4KSA0NTMt NDAwMCZuYnNwOzwvZm9udD48L3RkPgoKPHRkPjxmb250IHNpemU9KzE+SGFu Zm9yZCBIb3RlbDwvZm9udD4KPGJyPjxmb250IHNpemU9KzE+MTc1NSBOIDFz dCBTdDwvZm9udD4KPGJyPjxmb250IHNpemU9KzE+U2FuIEpvc2UsIENBIDk1 MTEyPC9mb250Pgo8YnI+PGZvbnQgc2l6ZT0rMT5QaG9uZTogKDQwOCkgNDUz LTMxMzM8L2ZvbnQ+PC90ZD4KPC90cj4KPC90YWJsZT48L2NlbnRlcj4KCjxi cj4mbmJzcDsKPHA+PGEgTkFNRT0iUmVnaXN0cmF0aW9uIj48L2E+PGZvbnQg c2l6ZT0rMj5SZWdpc3RyYXRpb24gUHJvY2VzczwvZm9udD4KPGJyPlBsZWFz ZSBjb25maXJtIHdpdGggYW4mbmJzcDsgZW1haWwgdG8gY29uZHJ5QGNvbmRy eS5vcmcgYnkgU2VwdCA3dGguClRoZXJlIGlzIG5vIHJlc2lzdHJhdGlvbiBj b3N0cy4gQWxsIGNvbmZpcm1lZCBhdHRlbmRlZXMgd2lsbCBiZSBwcm92aWRl ZAphIGNvbXBsZW1lbnRhcnkgbHVuY2ggZHVyaW5nIHRoZSBjb25mZXJlbmNl Lgo8cD48YSBOQU1FPSJTZXB0ZW1iZXIgMTIsIDIwMDAgRGlubmVyIj48L2E+ PGZvbnQgc2l6ZT0rMj5TZXB0ZW1iZXIgMTIsCjIwMDAgRGlubmVyPC9mb250 Pgo8YnI+TWFueSBhdHRlbmRlZXMgd2lsbCBiZSBhcnJpdmluZyBvbiBTZXB0 ZW1iZXIgMTIuCjxwPkkgaGF2ZSBhIHJlc2VydmF0aW9uIGF0IDc6MzAgcG0g YXQKPGJsb2NrcXVvdGU+CjxibG9ja3F1b3RlPklsIEZvcm5haW8gQ3VjaW5h IEl0YWxpYW5hCjxicj4zMDIgUyBNYXJrZXQgU3QKPGJyPlNhbiBKb3NlLCBD QSA5NTExMwo8YnI+KDQwOCkgMjcxLTMzNjYKPHA+PGEgaHJlZj0iaHR0cDov L3lwLnlhaG9vLmNvbS9weS95cE1hcC5weT9QeXQ9VHlwJnR1aWQ9MTAwMzY2 MzImY2l0eT1TYW4rSm9zZSZzdGF0ZT1DQSZzbHQ9MzcuMzM1MzAwJnNsbj0t MTIxLjg5Mzg5OCZjcz00Ij5NYXA8L2E+PC9ibG9ja3F1b3RlPgo8L2Jsb2Nr cXVvdGU+Cgo8cD48YSBOQU1FPSJQYXBlcnMsIFBhbmVscywgYW5kIERpc2N1 c3Npb25zIj48L2E+PGZvbnQgc2l6ZT0rMj5QYXBlcnMsClBhbmVscywgYW5k IERpc2N1c3Npb25zPC9mb250Pgo8YnI+VGhlIGRpc2N1c3Npb25zIHdpbGwg Zm9jdXMgb24gaXNzdWVzIHN1cnJvdW5kaW5nIHRoZSBjb25jZXB0cyBvZiBh ZGRpbmcKc29waGlzdGFjdGVkIHNlcnZpY2VzIGluIHRoZSBuZXR3b3JrIHRo cm91Z2ggZXh0ZW5zaWJsZSBwcm94aWVzLCB0aGUgYmFzaWMKcmVxdWVtZW50 cyBiZWluZyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldC1EcmFmdCZuYnNwOyA8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC10b21saW5zb24tZXBzZnctMDAudHh0Ij5odHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10b21saW5zb24tZXBzZnctMDAu dHh0PC9hPgo8cD5IZXJlIGFyZSBzb21lIHByZXNlbnRhdGlvbnMgYW5kIHBh bmVsczoKPHA+PGI+V2UgYXJlIHNlZWluZyB2b2xlbnRlZXJzIGZvciBiZWlu ZyBvbiB0aGUgZm9sbG93aW5nIHBhbmVsczwvYj4KPHVsPgo8bGk+ClNlY3Vy aXR5PC9saT4KCjxsaT4KQ29tbW9uIHNlcnZpY2VzIGFuZCBvcGVyYXRpbmcg ZW52aXJvbm1lbnQgZm9yIHByb3h5bGV0cyBhbmQgY2FjaGVsZXRzPC9saT4K CjxsaT4KU3BlY2lmaWNhdGlvbiBtZXRob2RzIGZvciBkeW5hbWljIHNlcnZp Y2VzPC9saT4KCjxsaT4KQXJjaGl0ZWN0dXJhbCB2aWV3cG9pbnQ6IG1pbmlt YWxpc3QgdnMuIHJpY2g8L2xpPgo8L3VsPgo8Yj5PdGhlciBQcmVzZXRhdGlv bnM8L2I+Cjx1bD4KPGxpPgpBY3RpdmUgbmV0IHNlY3VyaXR5PC9saT4KCjxs aT4KQXJjaGl0ZWN1cmUgYW5kIFVzZSBDYXNlczwvbGk+Cgo8bGk+CkFjdGl2 ZSBOYW1lcyBmb3IgY2FjaGluZyBwcm94aWVzPC9saT4KCjxsaT4KZnVubmVs V2ViIC0gQXBwbGljYXRpb24gTGF5ZXIgQWN0aXZlIE5ldHdvcmtpbmc8L2xp PgoKPGxpPgpBIFBsYXRmb3JtIGZvciBDb250ZW50IERlbGl2ZXJ5IGFuZCBF bmhhbmNlZCBTZXJ2aWNlczwvbGk+CjwvdWw+Cgo8L2JvZHk+CjwvaHRtbD4K --Hover_of_Trout_302_000-- From owner-ietf-openproxy Tue Sep 5 15:32:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13745 for ietf-openproxy-bks; Tue, 5 Sep 2000 15:32:57 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13738 for ; Tue, 5 Sep 2000 15:32:56 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25125 for ; Tue, 5 Sep 2000 15:34:29 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA21477 for ; Tue, 5 Sep 2000 15:34:29 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with SMTP id e85MYPk942921 for ; Tue, 5 Sep 2000 15:34:26 -0700 (PDT) Message-Id: <200009052234.e85MYPk942921@jurassic.eng.sun.com> Date: Tue, 5 Sep 2000 15:35:11 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Workshop To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YJ/TNhjNPUxWkX2OUGQxJg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have lots of positive replies for the workshop. Make sure you get to me. I understand there have been some hotel problem. Try Day's inn or other Web based ones. Michael http://www.extproxy.org From owner-ietf-openproxy Thu Sep 7 15:46:18 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA28676 for ietf-openproxy-bks; Thu, 7 Sep 2000 15:46:18 -0700 (PDT) Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28672 for ; Thu, 7 Sep 2000 15:46:18 -0700 (PDT) Received: from exchange.entera.com ([206.165.109.233]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with ESMTP id com for ; Thu, 7 Sep 2000 15:48:32 -0700 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Sep 2000 15:46:09 -0700 Message-ID: <733880CDF866D3118C69005004D1701EDD554C@exchange.entera.com> From: garyt@entera.com (Gary Tomlinson) To: ietf-openproxy@imc.org Subject: IEST Interest in our draft Date: Thu, 7 Sep 2000 15:45:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA28673 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is message posted by Patrik Faltsrom to the WREC list. It looks like there interest brewing around our work. Gary -----Original Message----- From: Patrik Fältström [mailto:paf@cisco.com] Sent: Thursday, September 07, 2000 12:20 PM To: wrec@cs.utk.edu Subject: Middlebox Features The IESG is worried about "middlebox features" which comes up all over the place. Just all over. The way people think about early TCP termination, "front-ending SSL connections so the SSL is not all the way to the server", ...etc might not all the time work well in todays design of the Internet. Is this trend driven by customers to companies asking for features without knowing what they are asking for? Because, companies only make products which customers buy, right? ;-) We ask if not the WREC wg is the closest group we have on looking into these issues, and hope that the WREC wg will try to design functionality which is needed without jumping through too many loops and bending themselves backwards, violating the ground principles of end-to-end-communication which the IESG and IAB belive is needed for fundamental architectual things to work (like IPSEC etc). One document we have found is draft-tomlinson-epsfw-00.txt, which we think is interesting because it is discussing some of these issues (yes, I know it was on the agenda at the last IETF... :-) Can you please in the work you do on rechartering think about these "middleware feature" thing, and whether you should not include some wording about that in your charter? We also would like you to have a look at draft-tomlinson-epsfw-00.txt and deside if you should have that document as part of what you work items (so it gets proper review at least)? Regards, Patrik Area Director, Applications Area From owner-ietf-openproxy Fri Sep 8 13:45:04 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA00569 for ietf-openproxy-bks; Fri, 8 Sep 2000 13:45:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00555 for ; Fri, 8 Sep 2000 13:44:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22507; Fri, 8 Sep 2000 14:46:29 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA21346; Fri, 8 Sep 2000 13:46:20 -0700 (PDT) Received: from gaelic (gaelic [129.146.122.130]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA06014; Fri, 8 Sep 2000 13:45:08 -0700 (PDT) Message-Id: <200009082045.NAA06014@nasnfs.eng.sun.com> Date: Fri, 8 Sep 2000 13:45:08 -0700 (PDT) From: Juanita Tapia Reply-To: Juanita Tapia Subject: Re: list of attendees - please review asap To: ietf-openproxy@imc.org Cc: condry@condry.org, geoffrey.baehr@Eng.Sun.COM, juanita.tapia@Eng.Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WBRcDdWfFxp2WDBEhr6TeA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, Here is a list of folks who signed up for the conference, please let me (juanita.tapia@sun.com) know if you are missing or if you will be attending dinner. Thanks! Name Company Dinner ----- ------- ------ 1. Atanu Ggosh 2. M. O'Doherty 3. Sandeep Sibal AT&T Labs Research 4. Steve Moyer Fringent Technologies 5. Markus Hofmann Bell-Labs 6. John Scharber 7. Ned Freed Innosoft.com 8. Micah Beck Lokomo Systems 9. Daye McManus Catchpole 10. Lisa Amini IBM TJ Watson Research Center Yes 11. Kurt Kovach Novell Not coming 12. Ian Cooper Equinix Yes 13. Dave Farber Digisle 14. Oskar Batuner Mirror Image Internet, Inc. Not sure 15. Steve Schwab Tislabs No 16. Mark Nottingham Akamai Technologies 17. Alex Shah Velocigen 18. Atanu Socs 19. D. Grossman 20. Sylvain Duloutre 21. Jussi Kangasharju AT&T Labs Research 22. Mike Dahlin University of Texas 23. Don Gillies Network Appliance, Inc. 24. John Chung-I Chuang University of California at Berkeley 25. Katherine Guo Dnrc.bell-labs Yes 26. Nick Okasinski No 27. Gary Tomlinson Entera, Inc. 28. Don Gilletti Entera, Inc. 29. Mark Green Entera, Inc. 30. John Scharber Entera, Inc. 31. Senthil Kumar Sun 32. Michael Condry Sun Yes 33. Hilarie Orman Novell Yes Thanks, Juanita _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Juanita Tapia Sun Microsystems - Sun Labs 15 Network Circle Menlo Park, CA. 94025 (650) 786-3382 Phone (650) 786-6445 Fax From owner-ietf-openproxy Sat Sep 9 21:28:15 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA03535 for ietf-openproxy-bks; Sat, 9 Sep 2000 21:28:15 -0700 (PDT) Received: from ruby.digisle.com (ruby.digisle.net [167.216.192.43] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA03531 for ; Sat, 9 Sep 2000 21:28:10 -0700 (PDT) Received: from guinness.digisle.net (guinness.digisle.net [167.216.152.33]) by ruby.digisle.com (8.9.3/8.9.3/mx) with ESMTP id EAA16790; Sun, 10 Sep 2000 04:29:34 GMT Received: from digitalisland.net (dhcp-172-16-66-204-vpn-sj.digisle.com [172.16.66.204]) by guinness.digisle.net (8.9.3/8.9.3/digisle) with ESMTP id EAA17572; Sun, 10 Sep 2000 04:29:24 GMT Message-ID: <39BB0E71.F9957557@digitalisland.net> Date: Sat, 09 Sep 2000 21:30:41 -0700 From: Dave Farber Organization: Digital Island X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Gary Tomlinson CC: ietf-openproxy@imc.org Subject: Re: IEST Interest in our draft References: <733880CDF866D3118C69005004D1701EDD554C@exchange.entera.com> Content-Type: multipart/mixed; boundary="------------3235AEE33F19F4AEF39AE11B" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------3235AEE33F19F4AEF39AE11B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary Tomlinson wrote: > > Here is message posted by Patrik Faltsrom to the WREC list. It looks like > there interest brewing around our work. The following ad for iBAND arrived in my mailbox within hours of your message, and seems to be making a similar point: -----Original Message----- From: Jason Utz Sent: Thu, Sept 7, 2000 2:33 PM Subject: ADV: Intelligent Network Infrastructure - The New Application Service A new virtual network layer is emerging that embraces IP and every other layer upwards. This virtual layer is being seen as the intelligent infrastructure platform for applications and services. It enables better control and prioritization of existing network resources and applications. It provides critical network functionality that supports the roll-out of next generation IP applications. And it is supported by new smarter, more dynamic network management capabilities. "Content Distribution/Delivery", "Application Acceleration", "Intelligent Network Services", "Application Infrastructure", "Dynamic Resource Allocation" and "Smart Bandwidth" are just some of the new concepts being developed in response to new requirements from IP network managers. And they are driving new classes of product features and service capabilities. Perhaps most importantly, this new smart infrastructure platform is being driven by commercial pressures and opportunities confronting managers of IP networks and services. As network planners look to maximize their investments in network infrastructure, increase their efficiencies and design/extend network platforms for new services, the imperatives behind their planning-to-implementation cycles increase. In turn, this puts new pressures on but creates new opportunities for providers of products and services. There's growing evidence that the dynamics of this vortex are bringing into question the way in which Internet standards get created - and whether they get created at all. Intelligent Network Infrastructure, Dynamic Network Management, Multi-layer solutions and challenges to the standards process are key topics being addressed by Judy Estrin of Packet Design and Charles Muirhead of Orchestream and iGabriel.Net in their keynotes at the upcoming iBAND conference. "Internet Infrastructure: Why We Can't Just Paint Over the Cracks" Judy Estrin, CEO , Packet Design, Inc. "Creating, provisioning and managing IP services under massive commercial pressures" Charles Muirhead, founder, Orchestream and iGabriel.Net To learn more about the conference, the multi-vendor network showcase, Birds of a Feather sessions and participants, visit: http://www.stardust.com/iband --------------3235AEE33F19F4AEF39AE11B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from ruby.digisle.com (ruby.digisle.net [167.216.192.43] (may be forged)) by chef.digisle.com (8.9.3/8.9.3/digisle) with ESMTP id WAA03652 for ; Thu, 7 Sep 2000 22:30:21 GMT Received: from ziggy.stardust.com (ns.stardust.com [205.184.205.34]) by ruby.digisle.com (8.9.3/8.9.3/mx) with ESMTP id WAA01791 for ; Thu, 7 Sep 2000 22:30:20 GMT Received: from terra (dhcp204-94.stardust.com [205.184.204.94]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA29219 for ; Thu, 7 Sep 2000 14:33:05 -0700 Message-Id: <200009072133.OAA29219@ziggy.stardust.com> Date: Thu, 7 Sep 2000 14:33:04 -0700 From: Jason Utz Subject: ADV: Intelligent Network Infrastructure - The New Application Service To: Dave Farber Organization: Stardust.com X-Mailer: GoldMine [4.00.9922] ** Removal Instructions ** If you do not wish to receive future updates, please reply to this message with REMOVE in the subject header. Your e-mail address will be promptly removed. A new virtual network layer is emerging that embraces IP and every other layer upwards. This virtual layer is being seen as the intelligent infrastructure platform for applications and services. It enables better control and prioritization of existing network resources and applications. It provides critical network functionality that supports the roll-out of next generation IP applications. And it is supported by new smarter, more dynamic network management capabilities. "Content Distribution/Delivery", "Application Acceleration", "Intelligent Network Services", "Application Infrastructure", "Dynamic Resource Allocation" and "Smart Bandwidth" are just some of the new concepts being developed in response to new requirements from IP network managers. And they are driving new classes of product features and service capabilities. Perhaps most importantly, this new smart infrastructure platform is being driven by commercial pressures and opportunities confronting managers of IP networks and services. As network planners look to maximize their investments in network infrastructure, increase their efficiencies and design/extend network platforms for new services, the imperatives behind their planning-to-implementation cycles increase. In turn, this puts new pressures on but creates new opportunities for providers of products and services. There's growing evidence that the dynamics of this vortex are bringing into question the way in which Internet standards get created - and whether they get created at all. Intelligent Network Infrastructure, Dynamic Network Management, Multi-layer solutions and challenges to the standards process are key topics being addressed by Judy Estrin of Packet Design and Charles Muirhead of Orchestream and iGabriel.Net in their keynotes at the upcoming iBAND conference. "Internet Infrastructure: Why We Can't Just Paint Over the Cracks" Judy Estrin, CEO , Packet Design, Inc. "Creating, provisioning and managing IP services under massive commercial pressures" Charles Muirhead, founder, Orchestream and iGabriel.Net This move towards more intelligent networks as the platform for new application services creates challenges and opportunities for network planners and business managers. How do you best manage and prioritize IP and application traffic? How do you scale your network and services? How do you measure performance and apply the results dynamically to the allocation of network resources. And how do you take advantage of new sophisticated content routing and management capabilities? The technologies, the trends, the twists and turns and the real business implications of these changes are all the focus of the iBAND conference and showcase, co-located with ISPCON, November 8-10. To learn more about the conference, the multi-vendor network showcase, Birds of a Feather sessions and participants, visit: http://www.stardust.com/iband Pioneers in this area include Agilent, Telseon and Orchestream. You can learn about theirs and other innovative vendor approaches on the exhibit floor at iBAND. If you'd like to sign up to attend the conference, please use code "IB01" We've also gatherered together a collection of resources and perspectives from industry experts for you. You can hear educational sessions given by experts from Cisco, Nortel, InterNAP, IXIA Communications, Deterministic Networks and Aventail. Interviews with pioneers offer even more perspective on these trends. Please note that this information will be available for a limited time only. http://events.stardust.com/iband/resources.htm Best regards, Jason Utz, iBAND at ISPCON & Stardust.com ** Removal Instructions ** If you do not wish to receive future updates from us, please reply to this message with REMOVE in the subject header. Your e-mail address will be promptly removed. --------------3235AEE33F19F4AEF39AE11B-- From owner-ietf-openproxy Mon Sep 11 22:47:58 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA03585 for ietf-openproxy-bks; Mon, 11 Sep 2000 22:47:58 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA03581 for ; Mon, 11 Sep 2000 22:47:55 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Sep 12 01:49:56 EDT 2000 Received: from bell-labs.com (dhcp9170.cs.bell-labs.com [135.104.9.170]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id BAA01805; Tue, 12 Sep 2000 01:49:54 -0400 (EDT) Message-ID: <39BDC3D3.4C3273C2@bell-labs.com> Date: Tue, 12 Sep 2000 01:49:07 -0400 From: Markus Hofmann X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,de MIME-Version: 1.0 To: ietf-openproxy@imc.org CC: Markus Hofmann , Andre Beck Subject: Write up on Example Services Content-Type: multipart/mixed; boundary="------------331384117FC67BB6BEFF115C" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------331384117FC67BB6BEFF115C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, when we mentioned our internal notes on service examples in a proxy framework similar to EPSF during Michael's visit at Bell Labs last week, he suggested to forward the notes to the EPSF group for some discussion. So, please find attached a preliminary write-up describing some service examples. Please be aware that the document is NOT an official Internet draft. We put the document together in quite a hurry, just out of the heads - no extensive proofreading, nor checking of correct taxonomy. But it might be useful to have the write up at the workshop in San Jose. If the document is of interest to the group and we get some feedback, we will consider submitting an improved version as Internet draft. -Markus --------------331384117FC67BB6BEFF115C Content-Type: text/plain; charset=iso-8859-1; name="draft-hofmann-isfnep-00.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="draft-hofmann-isfnep-00.txt" Network Working Group M. Hofmann Internet Draft A. Beck Expires: February 11, 2001 Bell Laboratories Lucent Technologies Document: draft-hofmann-esfnep-00.txt September 11, 2000 Category: Informational Example Services for Network Edge Proxies draft-hofmann-esfnep-00.txt Status of this Memo This document is not an official Internet-Draft and is not (yet) in full conformance with all provisions of Section 10 of RFC2026 [1]. This document is a preliminary draft, prepared for informal discussion within the EPFSW group. Its purpose is solicitation for comments and feedback that will be helpful in preparing a final version for possible submission as Internet Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Table of Contents 1 Introduction...................................................2 2 Content Adaptation for Alternate Web Access Devices............3 2.1 Abstract.....................................................3 2.2 Business model...............................................4 2.3 Technical Challenges.........................................4 3 Insertion of Ad Banners........................................4 3.1 Abstract.....................................................4 3.2 Business model...............................................5 3.3 Technical Challenges.........................................5 4 Insertion of Regional Data.....................................5 4.1 Abstract.....................................................5 4.2 Business model...............................................6 4.3 Technical Challenges.........................................6 Hofmann, Beck Expires February 11, 2001 1 Example Services for Network Edge Proxies September 2000 5 Language Translation...........................................6 5.1 Abstract.....................................................6 5.2 Business model...............................................7 5.3 Technical Challenges.........................................7 6 Bandwidth Adaptation...........................................7 6.1 Abstract.....................................................7 6.2 Business model...............................................8 6.3 Technical Challenges.........................................8 7 Virus Scanning.................................................8 7.1 Abstract.....................................................8 7.2 Business model...............................................8 7.3 Technical Challenges.........................................9 8 Content Adaptation for Alternate Browser Types.................9 8.1 Abstract.....................................................9 8.2 Business model..............................................10 8.3 Technical Challenges........................................10 9 Adaptation of Streaming Media.................................10 9.1 Abstract....................................................10 9.2 Business model..............................................10 9.3 Technical Challenges........................................10 10 Caching of Personalized/Customized Web Pages..................10 10.1 Abstract...................................................11 10.2 Business Model.............................................11 10.3 Technical Challenges.......................................11 11 Search Engine Index on Cached Web Pages.......................11 11.1 Abstract...................................................11 11.2 Business model.............................................12 11.3 Technical Challenges.......................................12 12 Request Filtering.............................................12 12.1 Abstract...................................................12 12.2 Business model.............................................12 12.3 Technical Challenges.......................................13 13 Request Filtering through Content Analysis....................13 13.1 Abstract...................................................13 13.2 Business model.............................................13 13.3 Technical Challenges.......................................13 14 Creation of Anonymous User Profiles...........................14 14.1 Abstract...................................................14 14.2 Business model.............................................14 14.3 Technical Challenges.......................................14 15 Author's Addresses............................................14 16 References....................................................16 1 Introduction The rapid growth of the Internet and the increasing number of Internet users have led to a wide deployment of network edge caching proxies. These systems have been very successful in accelerating Web content delivery and reducing the load on origin Web servers. Hofmann, Beck Expires February 11, 2001 2 Example Services for Network Edge Proxies September 2000 However, the specific role of these network edge caching proxies as a gateway between Web users and content providers suggests utilizing them for intelligent services beyond simple caching. There are already a variety of existing or proposed approaches that implement particular services on top of a proxy platform. ICAP [3] extends the basic idea of implementing value-added services on proxies by handling transport of web objects between proxies and content modification servers, thus, enabling remote call out mechanisms. EPSF [2] describes an extended framework to provide general services on top of an open proxy platform. This document discusses several service examples possibly being implemented on top of an open proxy platform as described in [2]. Each of the following service description consists of three subsections: a short abstract that describes the service idea, a description of the underlying business model, and finally a section that mentions technical challenges to be addressed when implementing these services. 2 Content Adaptation for Alternate Web Access Devices 2.1 Abstract Recently there has been an increasing diversity and heterogeneity in terms of the types of client devices and network connections that people use to access the Web. Especially cell phones and PDAs are being used more and more often to access the Internet. However, these appliances are characterized by relatively limited display capabilities, storage, processing power, as well as slow network access. As a result, Internet access is still constrained on these devices and users are limited to only a small fraction of the total number of Web pages available in the Internet today. Users of non- desktop access devices can only view those pages that have been adapted to the specific limitations of the access device the user holds. Since the number of different access devices is growing constantly content providers cannot be expected to provide different versions of their Web pages for each and every Web access device that is available in the market. Therefore it seems reasonable to adapt the general full-fledged Web pages at some point on their way from the origin server to the user so that they are optimized for (or at least adapted to) the end users’ specific requirements. Possible adaptations to meet the special requirements of different Web access devices are: - Conversion of HTML pages to WML (Wireless Markup Language) pages - Conversion of JPEG images to black and white GIF images - Conversion of HTML tables to plain text - Reduction of image quality Hofmann, Beck Expires February 11, 2001 3 Example Services for Network Edge Proxies September 2000 - Removal of redundant information - Stripping of Java applets / JavaScript - Audio to text conversion - Video to key frame or video to text conversion - Content extraction 2.2 Business model With the above-mentioned service in place, Web content providers could reach a much wider audience and the manufactures of novel Web access devices could offer potential customers access to a bigger part of the Internet content, which should make a very good selling point. It would encourage more people to buy non-desktop Web access devices like cell phones and PDAs. Once installed this service can be offered as an additional feature to ISP customers who want to access the Web through different Web- enabled devices. Also, content providers might be willing to pay for this service if that meant that they could serve their existing content to more users. 2.3 Technical Challenges We have to ensure that the automatic adaptation process will not make changes to a Web page that are unwanted by either the content provider or the recipient. One approach to achieve this would be to allow the content provider as well as the client to define their preferences as to how they want Web pages to be adapted. The actual adaptation decisions would then be made based on the given preferences and a set of transformation rules. If neither the content provider nor the client has expressed his preferences, it would probably be best to not adapt the requested Web page. If we wanted to allow the Web users and content providers to express their preferences, we would have to find a way of doing this. ISP customers could set their preferences through a Web interface on the ISP Web site. Content providers could express their preferences by adding meta tags to their Web pages. The content provider could for instance offer the content adaptation server a number of alternatives and the content adaptation server could then pick the most appropriate one. The drawback would be the increase in size of Web pages. Another possibility for the content provider would be to provide an adaptation policy to all ISPs that want to adapt Web pages for alternate Web access devices. This policy could consist of general transformation rules or actual code modules that perform the adaptation. 3 Insertion of Ad Banners 3.1 Abstract Hofmann, Beck Expires February 11, 2001 4 Example Services for Network Edge Proxies September 2000 Many Internet companies rely heavily on revenue made by selling advertisement space on their Web pages. In fact, nearly all commercial Web sites have one or more ad banners on their Web pages. Whenever advertisement banners are inserted dynamically depending on who requests the page, they cannot be cached, even when the content of the page itself is static. This behavior prevents Web pages from being cached, although their static content would allow for it. Therefore it seems reasonable to cache the static part of those Web pages at a caching proxy near the client and to insert ad banners into the cached Web pages before serving them to the client. 3.2 Business model This service could be sold to Internet advertising networks. They could profit from less traffic on their own Web servers by distributing the banner images to caching proxies. Also, content providers who do not want to outsource their ad space management and sales might be interested in providing banner images and insertion rules to proxies/content adaptation servers to accelerate the delivery of their Web pages. Recently there have also been a number of ISPs that offer free Internet access to customers. These so-called Free ISPs usually provide Internet access through a special kind of software that displays ad banners on the customers’ desktops whenever they are online. An ad insertion module at the caching proxy of the Free ISP could insert ad banners (in addition to any ad banners from the content provider) into every Web page requested by a customer. That way the customers of the Free ISP will not have to install any special software in order to use its service. 3.3 Technical Challenges The caching proxy would have to recognize when and where to insert ad banners into a Web page before serving it to the client. The proxy could for instance scan the Web page for a specific marking (e.g. a special tag). In the case of a Free ISP ad banners would probably always be inserted at the same position (e.g. in a frame at the top of each page) or in a separate pop-up window. If we wanted to insert advertisements based on the user and his interests, we would have to identify the user (by using cookies for example) and create user profiles. The user profiles could also be provided by the content provider. 4 Insertion of Regional Data 4.1 Abstract If a content provider wants to add user-specific regional information (weather forecasts for certain areas for example) to his Hofmann, Beck Expires February 11, 2001 5 Example Services for Network Edge Proxies September 2000 Web pages, he has little choice but to have the user select his location from a list of regions. Usually it is not possible for origin servers to reliably detect from where Web users connect to Web sites because user requests can get routed through a number of proxy servers on their way from the client to the origin server. In a network edge caching proxy environment user requests are usually redirected to the nearest proxy that is available to respond to the request. Regional information that is relevant to all users who are likely to connect to a certain proxy could be stored at the corresponding caching proxy. Whenever the proxy receives a user request, a module on the caching proxy could insert the regional information into the requested Web page. If the Web page does not contain any user-specific non-cacheable content other than the inserted regional information, the Web page content can now be cached for future requests. 4.2 Business model This service could be sold to content providers who want to offer regional information on their Web sites and want to accelerate the delivery of their Web content. There are many cases in which a content provider could profit from knowing the location of the user. Users could be targeted with regional advertisement banners (see also ad insertion scenario). Regional distinctions (e.g. sales taxes, differing laws etc.) could be taken into consideration when the Web pages are prepared for the client. It would not be necessary any more to ask the user for his location prior to presenting him relevant information. 4.3 Technical Challenges The regional content that is to be inserted into the Web pages would have to be distributed to the corresponding caching proxies. Since the regional content represents only a component of a whole Web page, it cannot be cached in the same way a complete Web page can be cached (unless it is an image). We have to find a mechanism to determine when a regional text component needs to be updated (or if the content provider should be responsible for this). 5 Language Translation 5.1 Abstract Soon the majority of all Internet users will be non-English speaking. As most of the current Web content is written in English, it becomes desirable to be able to translate the English content to the Web user’s local language, even if the content provider does not offer translations of his Web content. An automatic translation service for all Web pages could be implemented with an IPWorX content adaptation server. Hofmann, Beck Expires February 11, 2001 6 Example Services for Network Edge Proxies September 2000 The proxy server will recognize the Web user's native language and ask whether the foreign content requested should be translated into the user's native language. If the content is to be translated, the proxy will forward the Web content to a translation server where the page then is automatically translated. The proxy could also locally store translated content eliminating the need to repeat translations for different users. 5.2 Business model The automatic language service will help break language barriers and open new markets for e-commerce. The average non-English speaking Web user will have access to more Web content. ISPs, especially those with customers in non-English speaking countries, could offer this service to their customers. 5.3 Technical Challenges The automatic translation of text found on Web pages is not a trivial task. It will not be possible to translate a Web page automatically without running the risk of rendering parts of it incomprehensible. Worse yet, the original meaning could be changed and it is not said the reader of the translated page will notice the change in meaning. It is questionable whether content providers would even tolerate this kind of translation service. Therefore it is very important that the client authorizes this translation service and is fully aware of its potentially faulty behavior. It should also be considered to mark translated pages in a specific way to remind the user of the machine translation. Other technical challenges include the automatic detection of the language used in the original document and the client’s local language. 6 Bandwidth Adaptation 6.1 Abstract Today, Internet users can choose from a wide variety of Internet connection speeds. Therefore it seems desirable to adapt the requested Web content to the user’s bandwidth. Possible adaptations to reduce the size of Web objects are: - Reduction of image quality - Replacement of images by their ALT text - Removal of redundant information - Removal of HTML comments - Stripping of Java applets / JavaScript - Audio to text conversion - Video to key frame or video to text conversion Hofmann, Beck Expires February 11, 2001 7 Example Services for Network Edge Proxies September 2000 - Text summarizing - Content extraction 6.2 Business model One of the main benefits is to decrease the Web access time for users. If a Web site loads too slowly, users tend to leave the site even before it has completed loading the home page. The improved perceived quality of service by adaptive content delivery means that users are more likely to stay and return, thus resulting in a greater profit for e-commerce sites. This can also result in higher hit rates and return rates, which can lead to higher sales for e- commerce sites and higher advertising revenues. 6.3 Technical Challenges We would have to find a reliable way of measuring the bandwidth between the client and the proxy cache. One way of doing this would be to measure the round trip time (RTT) to determine the connection speed. It is crucial that this bandwidth detection method works more or less exact or otherwise the client will either experience very slow Web browsing or be cut off of some (or all) of the rich Web content. This service requires authorization by the user like any other adaptation service that changes the content and or format of Web pages. The mapping of a user’s connection speed to appropriate page adaptations requires defining a set of adaptation rules. 7 Virus Scanning 7.1 Abstract Viruses, Trojan Horses, and worms have always posed a threat to Internet users. Just recently we have seen a number of e-mail based worms that have hit millions of Internet users worldwide within a few hours. With the help of a content scanning and filtering system at the caching proxy level, Web pages and also file transfers could be scanned for malicious content prior to sending them to the user. In Web pages active content like ActiveX, Java and JavaScript could be scanned for harmful code (e.g. code exploiting security holes). File transfers could be scanned for known viruses. If a virus is found, the adaptation server could try to remove it or deny the delivery of the infected content. A general rule could be that the caching proxy may store and/or deliver content only, if it has been scanned by the content adaptation server and no viruses are found. 7.2 Business model Hofmann, Beck Expires February 11, 2001 8 Example Services for Network Edge Proxies September 2000 This service could be offered as an additional feature to ISP customers who are concerned about security issues. Likewise enterprises could be interested in this solution to prevent any malicious content from entering the company network. 7.3 Technical Challenges Web pages/files should be scanned for viruses by sending them to a separate server where virus-scanning software would analyze them. That way the virus scanning operations will not affect the performance of the caching proxy. If HTTP file transfers are to be scanned for viruses and the requested file cannot be found in the cache, we have to use a different approach than for Web pages. It would not be feasible, if the proxy waited for the requested file to be received completely before sending it over to the content adaptation server for the virus scan. This approach would lead to a long delay at the user’s end, which is not acceptable. Instead, we would have to scan the file transfer continuously, as it is being sent to the user (similar to streaming media). 8 Content Adaptation for Alternate Browser Types 8.1 Abstract The two commonly used Web browsers – Microsoft Internet Explorer and Netscape Navigator – both have proprietary extensions that are not part of any Web standard, but are yet widely used and considered essential by many Web page authors. As these proprietary extensions differ between the Internet Explorer and the Navigator (and even between different browser versions), Web pages have to be adapted in order to work well with both browsers. In the past this has been achieved by either writing two or more versions of the same page or by adding JavaScript to the Web page to alter the page at the client depending on what browser type and version the user is running. Although the Internet Explorer is used by far more users than any other browser type, there is still a substantial number of people who want to or must (UNIX) use alternative browser types. Yet, not all service providers write their Web pages so that they can be viewed with different browser types. A content adaptation module at the caching proxy could provide a remedy for this problem. Prior to serving a page (from the cache or the origin server) to the client, the proxy would send it to the adaptation module along with some client information (browser type and OS) received with the request. The content adaptation module would then make the necessary changes to the page to adapt it to the user’s browser type and send it back to the proxy from where it is served to the client. Hofmann, Beck Expires February 11, 2001 9 Example Services for Network Edge Proxies September 2000 8.2 Business model This service could be offered to ISPs who in turn could offer their customers a browser adaptation service. They could be sure to always receive pages that are optimized for their browser types. The customer should have the option to turn this service off at any time. This approach has the potential of leading to objections by content providers as they lose control over the final layout of their pages. Allowing for a mechanism to mark pages that are not to be touched by the content adaptation server could reduce these concerns. 8.3 Technical Challenges We would have to find general rules of how to convert pages. In order to do this we would have to identify all incompatibilities between the supported browser types and different versions thereof. These rules would have to be fail-safe, especially when they are applied to all requested pages without the page owner’s approval. We would have to recognize if a page contains JavaScript to adapt it to different browser types. If that should be the case, we could either remove the JavaScript and optimize the page for the client’s browser type or leave the page unchanged. 9 Adaptation of Streaming Media 9.1 Abstract Some of the above-mentioned services could not only be applied to Web pages but also to streaming media like audio and video streams. In particular, media streams could be adapted to meet the bandwidth of the user’s connection. It would also be possible to insert pre- recorded advertisements into audio or video streams. Even content analysis and content filtering could be applied to streaming media. 9.2 Business model The business models for streaming media adaptation are similar to those for Web page adaptation services. 9.3 Technical Challenges The adaptation of streaming media will add more complexity to the caching proxy platform and the technical challenges of these kind of services have yet to be explored. 10 Caching of Personalized/Customized Web Pages Hofmann, Beck Expires February 11, 2001 10 Example Services for Network Edge Proxies September 2000 10.1 Abstract Many Web sites (e.g. Yahoo) offer a service where users can create their own personalized version of the Web site (e.g. MyYahoo). It basically means that a user can choose from a number of components (e.g. stock information, weather forecasts, news etc.) and create a personalized Web page with them. This leads to dynamic Web pages that usually cannot be cached. If, however, the components of the personalized Web page could be cached, then it would be possible to have a service module on the server create the user-specific Web pages by assembling the cached Web site components. In that case the origin server would not have to be contacted again and the page could be served to the client directly from the network edge caching proxy. 10.2 Business Model This service would be another method of accelerating the delivery of Web content to the user, particularly the delivery of personalized/customized Web pages that would not be cacheable otherwise. Content providers who offer their customers the possibility of personalizing their Web pages are likely to be willing to pay for this kind of service. 10.3 Technical Challenges We would have to find a caching mechanism for the separate components of the personalized Web pages (unless a component consists of an image only). These components could be stored at the caching proxy. The page components would have to be refreshed just like complete Web page whenever they become stale. 11 Search Engine Index on Cached Web Pages 11.1 Abstract A proxy usually contains the most frequently requested Web pages of the Web users whose Web requests are routed through it. If we indexed the content of all Web pages currently contained in one or more proxies, we would have an index of Web pages that Web users are very likely to request (since they have been the most popular in the past). A search engine based on this index could therefore yield a high hit rate when used by a group of users who have similar interests and usually connect to the same caching proxies. The benefit of this approach would be that the index could be created very fast (there is no Web crawling to do) and that the search results could be returned to the user directly from the network edge caching proxy. The drawback, however, is that this search engine Hofmann, Beck Expires February 11, 2001 11 Example Services for Network Edge Proxies September 2000 would index only a small fraction of the existing Web pages. Web users have to be aware of this fact when they use the cache-based search index service. Another approach would be to display the proxy search results first while a global search engine prepares the results of a global search in the meantime. As soon as the global search results become available, they will be sent to the user. 11.2 Business model The search engine service described above could be sold to big companies who have users with similar interests and want to provide a fast search engine. Companies offering traditional search engines could be interested in combining their services with a cache-based search engine service to accelerate the delivery of their search results. 11.3 Technical Challenges If the cached Web pages of more than one caching proxy were to be indexed, we would have to find a way of replicating the search index to all affected caching proxy servers. 12 Request Filtering 12.1 Abstract The success of Web filtering/blocking systems like NetNanny (http://www.netnanny.com) and WebSense (http://www.websense.com) shows that there is a great need for solutions that let the owner of a Web access device control what kind of Web content can be accessed with his device. Parents, for instance, often demand a means of blocking off offending material when their children browse the Web. Also, companies might want to have control over what kind of Web pages their employees can have access to. Companies might also want to prevent their employees from using the available bandwidth excessively for non-work related activities. A request filtering service could provide a solution for all of the above. If all Web page requests of a specific user are routed through a caching proxy server, the content adaptation server could analyze the requests prior to fulfilling them. The service module would have to identify the user and determine the user’s access level. The next step would be to look up the classification of the requested Web page in a database. 12.2 Business model This service could be offered to enterprises and to ISPs. A database of Web pages that contain offending material could be obtained from companies that have specialized in Web blocking systems. Hofmann, Beck Expires February 11, 2001 12 Example Services for Network Edge Proxies September 2000 12.3 Technical Challenges The database on the proxy caching platform that contains the Web page classifications needs to be updated on a regular basis. If the database is provided by third parties, we have to provide them with a secure way of updating the database. If a Web access device is shared among different users who have different access levels, it is not sufficient to identify the Web access device. Therefore it will probably be necessary that different users of a Web access device use different user accounts. The owner of a Web access device must be able to define and change the access rights of the user(s) of his device. This could be done through a Web interface provided by the ISP/company. 13 Request Filtering through Content Analysis 13.1 Abstract While this service is very similar to the one previously described, it works more dynamically in that the content adaptation server analyzes the Web content once it has been retrieved from either the proxy cache or the origin server prior to sending it to the client. Through the use of sophisticated content analysis algorithms it should be possible to classify the analyzed Web content. If the classification of the Web page matches the user’s access level, the page will be delivered to the client. Otherwise, the client will be denied the page. The analyzed page along with its classification should be stored in the proxy cache so that future requests for the same page do not require the cached Web to be analyzed again. This will result in a better Web page delivery performance for popular Web pages. The main benefit of this approach is that there is no need to provide or maintain lists of forbidden Web sites, a process that per definition must always lag behind the creation of new Web sites. If common characteristics of a category of unwanted Web pages can be defined, it should be possible to automatically detect whether a requested Web page falls in a forbidden category. 13.2 Business model This service could be offered to enterprises and ISPs. The content analysis software could be obtained from software companies that have specialized in this field. 13.3 Technical Challenges In addition to the technical challenges described in the previous service scenario, we would have to find a way of storing the classification information of Web pages once they have been analyzed. One way to do this would be to add a meta tag (possibly using the Resource Description Framework (RDF, Hofmann, Beck Expires February 11, 2001 13 Example Services for Network Edge Proxies September 2000 http://www.w3.org/RDF) specification) with content rating information to a Web page before it is cached. Subsequent requests of the same Web page would then require the request filtering service module to scan the cached Web page for this metadata in order to determine the content rating of the requested page. 14 Creation of Anonymous User Profiles 14.1 Abstract If all Web requests of a certain Web user were routed through a certain caching proxy platform, it would be easy to log them in order to create a profile of the user’s Web browsing behavior. These user profiles could be created anonymously with no personal data (e.g. name or e-mail address) stored in the access log files. Once a sufficient number of requests has been logged by the content adaptation server, we could start analyzing the log files. In most cases it should be possible to derive the user’s interests by analyzing what kind of Web sites the user visits and how often he goes there. 14.2 Business model Companies that want to advertise on Web pages are very interested in knowing more about the recipients of their advertisement campaigns so that they can target their advertisements at people who are interested in the kind of products/services that the company wants to sell. These companies are also willing to pay for information that can help them targeting their campaigns at interested users. As explained above, we could derive the user’s interests from his Web browsing behavior and use this information to send the user only those advertisements that match his interests/needs. This will most likely result in a higher ad banner click-rate per user. This service could be sold separately or in combination with the ad insertion service. 14.3 Technical Challenges The creation of anonymous user profiles requires a mechanism to identify Web users. The ISP could provide a mapping from the user’s (possibly dynamic) IP number to some unique user ID. Another alternative would be to use cookies, provided that the user has not disabled them in his Web browser. 15 Author's Addresses Markus Hofmann Hofmann, Beck Expires February 11, 2001 14 Example Services for Network Edge Proxies September 2000 Bell Labs/Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 Phone: (732) 332-5983 Email: hofmann@bell-labs.com Andre Beck Bell Labs/Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 Phone: (732) 949-1241 Email: abeck@bell-labs.com Hofmann, Beck Expires February 11, 2001 15 Example Services for Network Edge Proxies September 2000 Full Copyright Statement Copyright (C) Lucent Technologies 2000. All Rights Reserved. Copyright will be adjusted when document is submitted as Internet Draft. 16 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Tomlinson G., Orman H., Condry M., Kempf J. and Farber D., "Extensible Proxy services Framework”, Internet-Draft draft- tomlinson-epsfw-00.txt, work in progress, July 2000. 3 Elson J., Martin J., Sharp E., Schuster J. Cerpa A., Danzig P., Neerdaels C. and Tomlinson G., "ICAP, the Internet Content Adaptation Protocol", external Reference http://www.i- cap.org/icap_v1-25.txt, work in progress, January 2000. Hofmann, Beck Expires February 11, 2001 16 --------------331384117FC67BB6BEFF115C-- From owner-ietf-openproxy Tue Sep 12 09:39:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA25338 for ietf-openproxy-bks; Tue, 12 Sep 2000 09:39:32 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25334 for ; Tue, 12 Sep 2000 09:39:31 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29890 for ; Tue, 12 Sep 2000 09:41:36 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA09368 for ; Tue, 12 Sep 2000 09:41:35 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with SMTP id e8CGfYJ902764 for ; Tue, 12 Sep 2000 09:41:34 -0700 (PDT) Message-Id: <200009121641.e8CGfYJ902764@jurassic.eng.sun.com> Date: Tue, 12 Sep 2000 09:42:21 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Workshop To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GunVpc3pxdm/C/sHNl7vqQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It will start at 9am Be sure and tell Juanita if you are comming to dinner (if you have not already) I will get an agenda out this afternoon. From owner-ietf-openproxy Tue Sep 12 12:27:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA29559 for ietf-openproxy-bks; Tue, 12 Sep 2000 12:27:28 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29554 for ; Tue, 12 Sep 2000 12:27:26 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16185 for ; Tue, 12 Sep 2000 12:29:33 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA01462 for ; Tue, 12 Sep 2000 12:29:31 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with SMTP id e8CJTSJ939655 for ; Tue, 12 Sep 2000 12:29:29 -0700 (PDT) Message-Id: <200009121929.e8CJTSJ939655@jurassic.eng.sun.com> Date: Tue, 12 Sep 2000 12:30:15 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Extended Proxy Workshop Agenda, September 13th To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4oSgZ2dDLaP2V+eqx0wwSA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 8:00-9:00 am Continental Breakfast 9:00 Introduction - Michael Condry and Hilarie Orman 9:30 Use Cases Extenisble Proxy Use Case - Michael Condry Example Services for Network Edge Proxies - Markus Hofmann Active Names - Michael Dahlin 10:30 Break 11:00 Security Administration Security - Jim Kempf Active Net Security Model - Steve Schwab 12:00 Lunch 1:15 Content Panel - Alex Shah, Michael Speer, Sunil Cherian, Jeff Suttor 2:15 Architecture funnelWeb - Application Layer Active Networking - Atanu Ghosh Architecture - Sandeep Sibal 3:00 Break 3:35 Architecture - continued Rule Evaluation Model - Dave Farber Specification Methods for Dynamic Services - Micah Beck 4:30 Plans and Discussions 5:15 Adjourn From owner-ietf-openproxy Tue Sep 12 14:45:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA02474 for ietf-openproxy-bks; Tue, 12 Sep 2000 14:45:25 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02470 for ; Tue, 12 Sep 2000 14:45:24 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11010 for ; Tue, 12 Sep 2000 14:47:31 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id OAA12047 for ; Tue, 12 Sep 2000 14:47:30 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with SMTP id e8CLlSJ960376 for ; Tue, 12 Sep 2000 14:47:28 -0700 (PDT) Message-Id: <200009122147.e8CLlSJ960376@jurassic.eng.sun.com> Date: Tue, 12 Sep 2000 14:48:14 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Corrected Agenda To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8oLl0j9ccsbi6InVI4GmyA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Workshop Agenda 8:00-9:00 am Continental Breakfast 9:00 Introduction - Michael Condry and Hilarie Orman 9:30 Use Cases Extenisble Proxy Use Case - Michael Condry Example Services for Network Edge Proxies - Markus Hofmann Active Names - Michael Dahlin 10:30 Break 11:00 Security Administration Security - Jim Kempf Active Net Security Model - Steve Schwab 12:00 Lunch 1:15 Content Panel - Alex Shah, Michael Speer, Sunil Cherian, Jeff Suttor 2:15 Architecture funnelWeb - Application Layer Active Networking - Atanu Ghosh Specification Methods for Dynamic Services - Micah Beck 3:00 Break 3:35 Architecture - continued Rule Evaluation Disussion - Dave Farber 4:30 Plans and Discussions 5:15 Adjourn From owner-ietf-openproxy Tue Sep 12 14:54:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA02622 for ietf-openproxy-bks; Tue, 12 Sep 2000 14:54:31 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02618 for ; Tue, 12 Sep 2000 14:54:30 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14572 for ; Tue, 12 Sep 2000 14:56:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id OAA14908 for ; Tue, 12 Sep 2000 14:56:38 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with SMTP id e8CLuaJ962320 for ; Tue, 12 Sep 2000 14:56:36 -0700 (PDT) Message-Id: <200009122156.e8CLuaJ962320@jurassic.eng.sun.com> Date: Tue, 12 Sep 2000 14:57:22 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Agenda - a few more corrections To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yKmvjX6knSGw9gSFpnUZuA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Workshop Agenda 8:00-9:00 am Continental Breakfast 9:00 Introduction - Michael Condry and Hilarie Orman 9:30 Use Cases Extenisble Proxy Use Case - Michael Condry mminet++ - A Platform for Content Delivery and Enhanced Services- Markus Hofmann, A. Beck Active Names - Michael Dahlin 10:30 Break 11:00 Security Administration Security - Jim Kempf Active Net Security Model - Steve Schwab 12:00 Lunch 1:15 Content Panel - Alex Shah, Michael Speer, Sunil Cherian, Jeff Suttor 2:15 Architecture funnelWeb - Application Layer Active Networking - Atanu Ghosh Specification Methods for Dynamic Services - Micah Beck 3:00 Break 3:35 Architecture - continued Rule Evaluation Disussion - Dave Farber 4:30 Plans and Discussions 5:15 Adjourn From owner-ietf-openproxy Tue Sep 12 15:04:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02977 for ietf-openproxy-bks; Tue, 12 Sep 2000 15:04:30 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02973 for ; Tue, 12 Sep 2000 15:04:29 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18375 for ; Tue, 12 Sep 2000 15:06:37 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA17760 for ; Tue, 12 Sep 2000 15:06:37 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with SMTP id e8CM6aJ964355 for ; Tue, 12 Sep 2000 15:06:36 -0700 (PDT) Message-Id: <200009122206.e8CM6aJ964355@jurassic.eng.sun.com> Date: Tue, 12 Sep 2000 15:07:23 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Sorry about agenda corrections.... To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: THqgiiTDf3ODvwxWcKucSw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I hope this is the last Workshop Agenda 8:00-9:00 am Continental Breakfast 9:00 Introduction - Michael Condry and Hilarie Orman 9:30 Use Cases Extenisble Proxy Use Case - Michael Condry mminet++ - A Platform for Content Delivery and Enhanced Services- Markus Hofmann, A. Beck Active Names - Michael Dahlin 10:30 Break 11:00 Security Network AAA for Proxy Mediated Services - Jim Kempf Active Net Security Model - Steve Schwab 12:00 Lunch 1:15 Content Panel - Alex Shah, Michael Speer, Sunil Cherian, Jeff Suttor 2:15 Architecture funnelWeb - Application Layer Active Networking - Atanu Ghosh Specification Methods for Dynamic Services - Micah Beck 3:00 Break 3:35 Architecture - continued Rule Evaluation Disussion - Dave Farber 4:30 Plans and Discussions 5:15 Adjourn From owner-ietf-openproxy Fri Sep 15 08:35:42 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25089 for ietf-openproxy-bks; Fri, 15 Sep 2000 08:35:42 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA25084 for ; Fri, 15 Sep 2000 08:35:40 -0700 (PDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Sep 15 11:37:57 EDT 2000 Received: from bell-labs.com (apache [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA14890; Fri, 15 Sep 2000 11:37:55 -0400 (EDT) Message-ID: <39C24255.25CE4F59@bell-labs.com> Date: Fri, 15 Sep 2000 11:37:57 -0400 From: Markus Hofmann Organization: Bell Labs Research, USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,de-DE MIME-Version: 1.0 To: ietf-openproxy@imc.org CC: Markus Hofmann Subject: Rules and rule sets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Michael asked me to send the thoughts on rules and rule sets to the mailing list for further discussion. So, here they are: (1) As written in the draft, wildcards are essential to specify rules. (2) Possible actions for a rule are not only "call proxylet" and "remote call-out", but also an action like "do NOT do that", thus overwriting a possible wildcard rule. We refer to such rules as "negative rules". Example: An ISP has installed a wildcard rule that forwards all client requests to a remote call-out server (e.g. for filtering). Now, if one specific client keeps complaining about the new service, the ISP might not want to shut down the new service for all clients, but only for this specific one => use a negative rule. Other examples include scenarios in which you want to execute a service for all URLs except for some specific ones (e.g. do adaptation for all URLs except for the URLs from content providers that threat with suing you :) (3) If multiple rules fire on a single message, the ordering of rules becomes very important. Example: two rules fire on a single message, e.g. a rule for language translation and a rule for ad insertion. In which order should the rules fire? You might want to do the ad insertion first, followed by the translation (or vice versa). (4) Given that ordering of rules is important - who is reponsible for the ordering of rules? According to the draft, rules can be installed by different parties. Imagine that the above mentioned rule for language translation and for ad insertion are from different parties. Which party defines the ordering of rules? There might be conflicts!!! A single instance for receiving, installing and defining the order of rules might be a good idea (e.g. the administrator of the proxy/cache). Of course, one might also think about mechanisms to specify dependencies of rules..., but... (5) My feeling is that rules should NOT be too complex. Simple rules looking at basic message properties that are common to most rules should be sufficient. More enhanced "filtering" and "rule matching" should be done in the proxylets. For example, we've implemented a simple rule set only looking at the source address and the destination URL of a request. If there's a match, the associated action will be executed, for example calling a proxylet. The proxylet itself can now do more enhanced filtering, for example, checking the language preferences of the user in order to determine whether the response has to be translated. (6) Somehow related to the above item: Message properties to be extracted by the message parser do NOT only depend on the protocol, but also on the rules that have been installed. Potentially, every single line of an HTTP header can be of interest for a rule. So, do you want to extract all HTTP header fields in the parser? According to (5), one could define some HTTP header fields that are of interest to most rules, extract them in the message parser, match rules (i.e. rules are also restricted to these fields) and than forward the message to a proxylet, for example. The proxylet can now further examine the message and check the header fields that are of specific interest. The cost, however, is more parsing overhead... We will keep working on our rule set implementation to see whether it can meet the requirements of the services we have in mind. We would be very interested in more detailed discussion, your comments, thougts, feedback, so that we together can come up with a common and open solution that works for all of us. Please let us know if you're interested in that issue so that we can work together on that. -Markus From owner-ietf-openproxy Sun Sep 17 21:23:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA25352 for ietf-openproxy-bks; Sun, 17 Sep 2000 21:23:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA25348 for ; Sun, 17 Sep 2000 21:23:11 -0700 (PDT) Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA21441; Sun, 17 Sep 2000 22:25:45 -0600 (MDT) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id WAA26895; Sun, 17 Sep 2000 22:25:45 -0600 (MDT) Received: from condry.org by esun1as-mm. (SMI-8.6/SMI-SVR4) id WAA11173; Sun, 17 Sep 2000 22:32:37 -0600 Message-ID: <39C5981A.1DD72DB6@condry.org> Date: Sun, 17 Sep 2000 21:20:42 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN MIME-Version: 1.0 To: epsfw@sun.com, condry@condry.org, ietf-openproxy@imc.org Subject: EPSFW Workshop Followup Content-Type: multipart/mixed; boundary="------------4B5B067EF54F4264A20F43F1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------4B5B067EF54F4264A20F43F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After our EPSFW workshop I have some notes on some of the work that might be done between now and San Diego. We wish to expand the specifications associated with our model and enhance the requirements to evolve the EPSFW draft. The details will be in clarification of how things could work, needed protocols, APIs, etc. all of which will define pieces that eventually evolve the overall architecture. I will be posting the slides and notes later. Let me try and spell out some things to do, and I would like some volenteers and additions. Please make suggestions!!! 1. Services/Proxylet requirements: Here a particular service is examined in detail, with a use case or implementation or both. Results will exhibit the specifications either at the detailed level (APIs and protocols) or at the requirements level. Alex Shah gave us a detailed Use Case for his MyWebBook. Markus Hoffman and Katy Guo gave us some implementations that could be mapped into the framework. Senthil Kumar and I tried to enhance the "University Accounting" USE-CASE. Things we need to do (as much as possible) a. Explain what needs to be done including examples of required protocols, functions, rule expectations and library expectations. b. Propose a design that is consistent with the requirements in EPSFW. Suggest requirement changes if necessary. c. Implement code for the service or show how thing need to work with a detailed Use Case. d. Describe enhancements or details to the EPSFW framework. Senthil Kumar and I tried to enhance the "University Accounting" USE-CASE. Kumar's group may be able to implement this by San Diego. This is quite simple and no example protocols or APIs are shown thus far. Example Service Projects that I can think of: * Steaming Media with Caching changes * Content Assembly - improving Yahoo a. Ad insertion b. Tickertape c. MyWebBook d. Localization * PBX control * Transcoding * University Accounting * ICAP examples Look the list over, pick one or insert more in the list. 2. Rule Model Dave Farber started with some rule issues and Markus has sent out some additional requirements. We need to collect these requirements and update the draft. We could also build a small rule engine. Just a simple case could be used to expand things: * HTTP/HTML only - certainly not the framework requirements. * Schema to represent rules * Simple conflict model Now we need * tools to analyze rule specifications * engine for executing rules and firing proxylets lots more. 3. Security/Accounting What is the AAA model for our EPSFW environement. Understanding the scope of rulets and proxylets is critical. There is lots to be done here. I am certainly open to suggestions. Michael condry@condry.org --------------4B5B067EF54F4264A20F43F1 Content-Type: text/plain; charset=us-ascii; name="UAUseCase.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="UAUseCase.txt" As one example, let us expand the "Univeristy Accounting" use case. Here the objective was to create a log of the class URLs used by the students along with some indication of usage time. Using EPSFW was ideal because the professor designing the accounting for his classes does not necessary have the right to modify the web pages used for his class and the Client/User Agent is certainly not a suitable place to do this. This is a simple use case but it does call on all the key components. The key componets are shown in the diagram below: +----------------+ | Accounting | | Callout | | Server | +----------------+ A | | | | | | V +----------------+ | | +----------+ | PROXY SERVER | +-----------+ |Client |<-------|4 3|<-----------| Content | |User agent|------->|1 ------------ 2|----------->| Server(s) | +----------+ | | +-----------+ | proxylets | | | +----------------+ A | | | | V +----------------+ | Adminsitraion | | Server | +----------------+ PROXYLETS The proxy server executes the proxylets that we use to do the accounting. There are three proxylets: a. The login proxylet that essentially "starts" the proxy based accounting session. There are several ways we might stimulate this but we are assuming that the student is required to login into a "class URL" in order to access the class web pages. This creates data kept in the proxy server for accounting; it is the process that identifies the student. b. The logout proxylet is used to "clear out" the user information being kept by Proxy Server. This can be executed explicitally or by a timeout. So an "inactive use" timer is in the system and when fired can cause this proxylet to execute as well as going to an explicit logout URL. This "inactive use" timer is determined by the value set in the "student active time" set by the log proxylet. c. The log proxylet creates a log entry when the student accesses a content server. This data is passed to the accounting callout server for further processing. The record looks something like The proxylet would also set a "student active time" variable each time its fired for this student. RULES The rule mechanism is based only the URLs of requests and timer data. There are some choices in rules. Three primary mechanisms could be used to elect when a class URL proxylet should be fired: i. Fire for all URLs ii. Fire with URLS matching a regular expression (like "149.146.22.*") ii. Fire with URLs found in a list Establishing which is the most suitable set of rules and analying each is a good project. For now, lets just assume that all the appropriate URLs will be specificable by a simple regular expression. PROCESS Now the operation of the system will go as follows. First we have an administration set up procedure: 1) Verify correctness and security of the rules and proxylets. 2) Administrator installs the proxylets and rules to the proxy. This would install the i) login proxylet ii) logout proxylet iii) log proxylet(s) It would also install the rulets (URLs) that specify the login and logout URLs and the regular expression that describes the class web page URLs. Now, once installed the system can be used: 0) User (the student) sets his browser proxy to point to the main PROXY required to be use for classwork. This will direct the students agent to go through our example proxy server. 1) Now student's "login" to the class system by going to the class login webpage. Student submitting the login web page triggers login proxylet. Since Login proxylet knows about login form, it picks up student info from it. It sets up internal information to associate activity from this client to be identified as this student. 2) After the login, the student accesses the class URLs through their browser. The rule system matches this URL and fires the log proxylet. The proxylet looks up the student id (knowing the ip connection of the client) then logs the class access record which looks like: This is passed on ot the Accounting Callout Server. An XML format for the data would be likely. Callout server logs all these info. This proxylet also sets the "student active" timer to indicate that a page was accessed at this time. 3) At some point the student will quit accessing pages. A "logout" URL will be provided. If the student accesses the logout URL or if too much time passes and the timer fires because the student is not active, this will trigger the logout proxylet. The logout proxylet removes the student information from the within the proxy. This should also remove access to the class web pages until a "login" procedure is executed again. External to this process, the professor takes the data logs on the callout accounting processor and does whatever analysis desired on the data. This could re-set the logs. The professor must also set up the login/logout URLs. --------------4B5B067EF54F4264A20F43F1-- From owner-ietf-openproxy Mon Sep 18 20:11:44 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA03836 for ietf-openproxy-bks; Mon, 18 Sep 2000 20:11:44 -0700 (PDT) Received: from 1-132.mnot.net (adsl-63-201-242-106.dsl.snfc21.pacbell.net [63.201.242.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA03832 for ; Mon, 18 Sep 2000 20:11:41 -0700 (PDT) Received: by 1-132.mnot.net (Postfix, from userid 500) id A58256601; Mon, 18 Sep 2000 20:14:08 -0700 (PDT) Date: Mon, 18 Sep 2000 20:14:08 -0700 From: Mark Nottingham To: WREC Working Group Cc: ietf-openproxy@imc.org Subject: End to End thoughts [long] Message-ID: <20000918201408.D2609@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There's been a lot of talk in various places about end-to-end problems, and their relation to intermediates (e.g., HTTP caching proxies, surrogates, etc.). Things have gotten somewhat religious. Rather than go down that road, I'd like to examine the issues and separate them into distinct problems. * Network Layer The end-to-end principle applies to *network* layer functions; it is not meant to preclude an application-level gateway. I _think_ that most everyone will agree that functions that break end-to-end transparency at the network layer cause problems. In other words, Interception Proxies are Evil. While it's nice to think that we can convince the world of this, it's more realistic to find out why people use them, and give them a better alternative. To my knowledge, most people use them because they need an easy way to assure that Web traffic (or at least port 80) goes through a proxy. While browser have proxy auto-configuration, it hasn't changed in quite a few years, there's no standard to implement, and it relies on JavaScript. WPAD was a good start; unfortunately, it never really went to far beyond Microsoft. Additionally, a more sensible, standard format for the configuration file would help. Over all of this, we need participation from the browser vendors, or we won't get anywhere. * Application Layer All of this being said, HTTP intermediates *do* raise issues at the application layer, which aren't end-to-end problems, but do get confused with them, as the causes are similar. Proxies and surrogates can do a number of things to requests and responses as they flow through. I've been roughly classifying them as; - access control (e.g., blocking, filtering) - request modification (URI rewriting) - response modification (transcoding) These operations are often performed in the interest of one of different parties: - content provider - access provider - user There have been numerous papers and discussions about the interesting things that can be done by intermediates. However, I don't think there's enough attention being paid to the problems that enabling these functions on intermediates can cause. * HTTP The HTTP makes a primary assumption of semantic transparency - that an entity body will not be changed 'in flight' - that, discounting transfer-encodings and so forth, what the server sends in the response is what the client gets. Jeff Mogul brought up issues with entity identity, as expressed in the ETag, in Lisbon. There was also general concern (it may have been Jeff in particular, my memory isn't that good) that an operation performed in one portion of the network may not be performed in another, causing unpredicatable behaviours. There are lots of other little examples here that should be covered, but I'll leave it for now. * URI One of the premises of URIs is that they refer to a specific, identifyable resource, and that the authority for that resource has control over it. Many applications have dependencies on this. PICS, Robots Exclusion, P3P, and other kinds of metadata systems break, sometimes disasterously, when intermediates change the semantics and/or payload of a message. The privacy implications are especially of concern. Overall, content providers have a reasonable expectation that the object which they deliver will be the one that the user gets, unless the user doesn't want it. These effects are largely social and legal; however, they're enabled by the technology that's being pushed out there. We need to reconcile the capabilities of the products and frameworks that we're building with the expectations that have been set by our base protocols. It's interesting that Web caching seems to be losing ground to CDNs so rapidly; to me, this illustrates the point perfectly. Web caching was always performed in the interest of the access provider, not the content provider (or arguably even the user). As a result, content providers don't trust Web caches. What's it going to be like out there when access providers can slip a transcoding, rewriting module into a proxy on the fly? One person who I've talked about this with pointed out the issues we had a while back in caches vs. copyright, legally. There's much more direct potential for problems here. -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy Tue Sep 19 08:10:13 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25915 for ietf-openproxy-bks; Tue, 19 Sep 2000 08:10:13 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25909 for ; Tue, 19 Sep 2000 08:10:11 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21235; Tue, 19 Sep 2000 08:12:51 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id IAA15998; Tue, 19 Sep 2000 08:12:50 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8JFCna913711; Tue, 19 Sep 2000 08:12:49 -0700 (PDT) Message-Id: <200009191512.e8JFCna913711@jurassic.eng.sun.com> Date: Tue, 19 Sep 2000 08:13:38 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Re: EPSFW Workshop Followup To: JPretorius@novell.com Cc: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HCU7Qv3C2wtaf3qJjxfFBw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jessie- Yes, negative states should be considered. What if the rulet language allowed at a not in the pattern expression, would that work? Also, do you have some good examples were a negative expression is key to making it work? Michael > To: > Subject: Re: EPSFW Workshop Followup > Mime-Version: 1.0 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by jurassic.eng.sun.com id e8JAN2a895281 > > Just to comment, in addition to the rules listed in UAUseCase.txt, it may be a good idea to provide a reverse set of rules: > > i. Fire (or do not fire) for all URLs > ii. Fire (or do not fire) with URLS matching a regular expression (like "149.146.22.*") > ii. Fire (or do not fire) with URLs found in a list > > This provides the customer with the flexibility to manage by exception. > > Cheers > > Jesse > > *** > Jesse Pretorius > Systems Engineer > e-mail: JPretorius@Novell.Com > AIM/InstantMe: preycor > ICQ# 4620796 > Tel: +27 21 418 3805 > Fax: +27 21 418 3931 > > Novell, Inc., the leading provider of Net services software > www.novell.com > > > >>> "Michael W. Condry" 09/18/00 06:20AM >>> > After our EPSFW workshop I have some notes on some of the work > that might be done between now and San Diego. We wish to > expand the specifications associated with our model and enhance the > requirements to evolve the EPSFW draft. The details will be in > clarification > of how things could work, needed protocols, APIs, etc. all of which will > > define pieces that eventually evolve the overall architecture. > > I will be posting the slides and notes later. > > Let me try and spell out some things to do, and I would like some > volenteers > and additions. Please make suggestions!!! > > 1. Services/Proxylet requirements: > Here a particular service is examined in detail, with a > use case or implementation or both. Results will exhibit the > specifications either at the detailed level (APIs and protocols) > or at the requirements level. > > Alex Shah gave us a detailed Use Case for his > MyWebBook. Markus Hoffman and Katy Guo gave us some > implementations that could be mapped into the > framework. Senthil Kumar and I tried to > enhance the "University Accounting" USE-CASE. > > Things we need to do (as much as possible) > > a. Explain what needs to be done including examples of required > protocols, functions, rule expectations and library > expectations. > b. Propose a design that is consistent with the requirements in EPSFW. > Suggest requirement changes if necessary. > c. Implement code for the service or show how thing need to work > with a detailed Use Case. > d. Describe enhancements or details to the EPSFW framework. > > Senthil Kumar and I tried to > enhance the "University Accounting" USE-CASE. Kumar's > group may be able to implement this by San Diego. This is > quite simple and no example protocols or APIs are shown > thus far. > > Example Service Projects that I can think of: > * Steaming Media with Caching changes > * Content Assembly - improving Yahoo > a. Ad insertion > b. Tickertape > c. MyWebBook > d. Localization > * PBX control > * Transcoding > * University Accounting > * ICAP examples > > Look the list over, pick one or insert more in the list. > > 2. Rule Model > Dave Farber started with some rule issues and Markus has sent > out some additional requirements. We need to collect > these requirements and update the draft. > > We could also build a small rule engine. Just a simple case could > be used to expand things: > * HTTP/HTML only - certainly not the framework requirements. > * Schema to represent rules > * Simple conflict model > > Now we need > * tools to analyze rule specifications > * engine for executing rules and firing proxylets > lots more. > > 3. Security/Accounting > What is the AAA model for our EPSFW environement. > Understanding the scope of rulets and proxylets > is critical. There is lots to be done here. > > I am certainly open to suggestions. > > Michael > condry@condry.org > > From owner-ietf-openproxy Tue Sep 19 17:09:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA14830 for ietf-openproxy-bks; Tue, 19 Sep 2000 17:09:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14826 for ; Tue, 19 Sep 2000 17:09:26 -0700 (PDT) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA24751; Tue, 19 Sep 2000 17:11:47 -0700 (PDT) Message-ID: <39C800B3.66965AA4@isi.edu> Date: Tue, 19 Sep 2000 17:11:31 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Nottingham CC: WREC Working Group , ietf-openproxy@imc.org, touch@ISI.EDU Subject: Re: End to End thoughts [long] References: <20000918201408.D2609@mnot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark Nottingham wrote: > > There's been a lot of talk in various places about end-to-end > problems, and their relation to intermediates (e.g., HTTP caching > proxies, surrogates, etc.). > > Things have gotten somewhat religious. Rather than go down that road, > I'd like to examine the issues and separate them into distinct > problems. > > * Network Layer > > The end-to-end principle applies to *network* layer functions; it is > not meant to preclude an application-level gateway. The E2E principle applies to all services implemented at the endpoints, not just transport. This includes reliable transfer, security, etc. It does not preclude anything, per se. It merely says that E2E services (e.g., reliable transport, app security, etc.) cannot be composed _merely_ out of equivalent hop-by-hop services. > I _think_ that most everyone will agree that functions that break > end-to-end transparency at the network layer cause problems. In other > words, > > Interception Proxies are Evil. The problem with interception proxies isn't breakage of E2E; it's breakage of standard protocols. See http://www.isi.edu/touch/pubs/hazards-outline.txt for further info. > Proxies and surrogates can do a number of things to requests and > responses as they flow through. I've been roughly classifying them > as; > > - access control (e.g., blocking, filtering) > - request modification (URI rewriting) > - response modification (transcoding) Yes - and these are actually discussed in the original E2E paper. This is basically value-added services. There are plenty of them. The E2E principle doesn't prohibit HBH services; it just says HBH alone do not compose to yield E2E. It specifically allows (if not encourages) HBH for performance enhancement, with the caveat that it is also possible to degrade performance if not done carefully. > It's interesting that Web caching seems to be losing ground to CDNs > so rapidly; to me, this illustrates the point perfectly. Web caching > was always performed in the interest of the access provider, not the > content provider (or arguably even the user). As a result, content > providers don't trust Web caches. What's it going to be like out > there when access providers can slip a transcoding, rewriting module > into a proxy on the fly? CDNs use web caches, don't they? or at least what do you call the rented Akamai server? I call it a cache... (CDN is just an economic model for charging the provider for space on the cache) Joe From owner-ietf-openproxy Tue Sep 19 17:38:57 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA15434 for ietf-openproxy-bks; Tue, 19 Sep 2000 17:38:57 -0700 (PDT) Received: from mail.mnot.net (adsl-63-201-242-106.dsl.snfc21.pacbell.net [63.201.242.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA15430 for ; Tue, 19 Sep 2000 17:38:56 -0700 (PDT) Received: by mail.mnot.net (Postfix, from userid 500) id 6A2DF976E; Tue, 19 Sep 2000 17:41:26 -0700 (PDT) Date: Tue, 19 Sep 2000 17:41:26 -0700 From: Mark Nottingham To: Joe Touch Cc: WREC Working Group , ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] Message-ID: <20000919174124.A1719@mnot.net> References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39C800B3.66965AA4@isi.edu>; from touch@ISI.EDU on Tue, Sep 19, 2000 at 05:11:31PM -0700 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 19, 2000 at 05:11:31PM -0700, Joe Touch wrote: > > The end-to-end principle applies to *network* layer functions; it is > > not meant to preclude an application-level gateway. > > The E2E principle applies to all services implemented at the endpoints, > not just transport. This includes reliable transfer, security, etc. > It does not preclude anything, per se. It merely says that > E2E services (e.g., reliable transport, app security, etc.) > cannot be composed _merely_ out of equivalent hop-by-hop services. Thanks; that makes it somewhat clearer to me. Although I've read the original paper, there's been a lot of bandying the term about, somewhat blurring its meaning in usage. > > Interception Proxies are Evil. > > The problem with interception proxies isn't breakage of E2E; > it's breakage of standard protocols. See > http://www.isi.edu/touch/pubs/hazards-outline.txt for further info. Many have been explaining the Evils of interceptions proxies in this way, which is why I started from this angle. That having been said, I'm more interested in the effects below than these. Interception problems seem to have enough people concerned about them (although we still need to *do* something about them). In this respect, it was a poorly chosen subject line, but my perception was that these points were previously articulated as end-to-end problems. > > Proxies and surrogates can do a number of things to requests and > > responses as they flow through. I've been roughly classifying them > > as; > > > > - access control (e.g., blocking, filtering) > > - request modification (URI rewriting) > > - response modification (transcoding) > > Yes - and these are actually discussed in the original E2E paper. > This is basically value-added services. There are plenty of them. > > The E2E principle doesn't prohibit HBH services; it just > says HBH alone do not compose to yield E2E. It specifically > allows (if not encourages) HBH for performance enhancement, > with the caveat that it is also possible to degrade performance > if not done carefully. Of course; I wasn't suggesting that E2E prohibited application level gateways, etc., but that if current work goes forward without considering the social and legal effects of what they do, there will be trouble. > > It's interesting that Web caching seems to be losing ground to CDNs > > so rapidly; to me, this illustrates the point perfectly. Web caching > > was always performed in the interest of the access provider, not the > > content provider (or arguably even the user). As a result, content > > providers don't trust Web caches. What's it going to be like out > > there when access providers can slip a transcoding, rewriting module > > into a proxy on the fly? > > CDNs use web caches, don't they? or at least what do you call the > rented Akamai server? I call it a cache... > (CDN is just an economic model for charging the provider for space > on the cache) It's a surrogate which implements a cache. You've made my point well - Web caching isn't a good economic model, and even risked legal problems at one point, because it isn't done on behalf of the content provider. Rather, it is done by the access provider, who isn't concerned with cache correctness, etc. nearly as much as the content provider. Value-added services are a good thing, but there needs to be a framework to address these issues. While some content providers may not care that their content is transcoded by a proxy in front of the user, others may. For example, if a legal document is changed in any way (translated, summarized, etc.) it becomes invalid. The most oft-cited example that makes me shudder is the dynamic insertion/replacement of ads by the access provider, without permission of the content provider. While I'm sure there's a market for this out there, it brings up significant issues. I'm not sure that IETF is the best place to address this; W3C seems (to me) to have a more active view on social/legal issues. However, this is where these capabilities are being talked about, so it seemed a good starting point. -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy Wed Sep 20 03:44:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA19523 for ietf-openproxy-bks; Wed, 20 Sep 2000 03:44:48 -0700 (PDT) Received: from cpl-emea-mail1.cpl.novell.com (cpl-emea-mail1.cpl.novell.com [147.2.71.56]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA19518 for ; Wed, 20 Sep 2000 03:44:46 -0700 (PDT) Received: from EMEA-Message_Server by cpl-emea-mail1.cpl.novell.com with Novell_GroupWise; Wed, 20 Sep 2000 12:46:56 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 20 Sep 2000 12:46:24 +0200 From: "Jesse Pretorius" To: Cc: Subject: Re: EPSFW Workshop Followup Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA19519 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The simplest case would be where a university, or any corporate has internal (or extranet) web servers - but has all users going through the proxy. They would want to charge for all traffic going through the proxy that does not match a particular expression: Rules applied in top-down order: * Do not fire for *.foo.com * Do not fire for URLs found in list * Fire for all URLs With this kind of negative state rule set, the accounting applies to the websites that the company feels is chargable, and the administration load in maintaining the rule list is minimised. Jesse *** Jesse Pretorius Systems Engineer e-mail: JPretorius@Novell.Com AIM/InstantMe: preycor ICQ# 4620796 Tel: +27 21 418 3805 Fax: +27 21 418 3931 Novell, Inc., the leading provider of Net services software www.novell.com >>> Michael Condry 09/19/00 05:13PM >>> Jessie- Yes, negative states should be considered. What if the rulet language allowed at a not in the pattern expression, would that work? Also, do you have some good examples were a negative expression is key to making it work? Michael From owner-ietf-openproxy Wed Sep 20 09:48:30 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA02332 for ietf-openproxy-bks; Wed, 20 Sep 2000 09:48:30 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02328 for ; Wed, 20 Sep 2000 09:48:29 -0700 (PDT) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA19704; Wed, 20 Sep 2000 09:51:12 -0700 (PDT) Message-ID: <39C8EAEE.4BBA120D@isi.edu> Date: Wed, 20 Sep 2000 09:50:54 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Nottingham CC: WREC Working Group , ietf-openproxy@imc.org, touch@ISI.EDU Subject: Re: End to End thoughts [long] References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> <20000919174124.A1719@mnot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark Nottingham wrote: > > On Tue, Sep 19, 2000 at 05:11:31PM -0700, Joe Touch wrote: > > > > Interception Proxies are Evil. > > > > The problem with interception proxies isn't breakage of E2E; > > it's breakage of standard protocols. See > > http://www.isi.edu/touch/pubs/hazards-outline.txt for further info. > > Many have been explaining the Evils of interceptions proxies in this way, > which is why I started from this angle. > > That having been said, I'm more interested in the effects below than these. > Interception problems seem to have enough people concerned about them > (although we still need to *do* something about them). In this respect, it > was a poorly chosen subject line, but my perception was that these points > were previously articulated as end-to-end problems. There certainly is room for work here. > Of course; I wasn't suggesting that E2E prohibited application level > gateways, etc., but that if current work goes forward without considering > the social and legal effects of what they do, there will be trouble. The IETF, far as I can tell, doesn't consider these issues, unless: 1. there are technical solutions somewhere underlying the social and/or legal AND 2. the legal issues constrain technical solutions i.e., solutions which are obviously not viable from the legal aspect are probably not worth spending time on technically > > > It's interesting that Web caching seems to be losing ground to CDNs > > > so rapidly; to me, this illustrates the point perfectly. Web caching > > > was always performed in the interest of the access provider, not the > > > content provider (or arguably even the user). As a result, content > > > providers don't trust Web caches. What's it going to be like out > > > there when access providers can slip a transcoding, rewriting module > > > into a proxy on the fly? > > > > CDNs use web caches, don't they? or at least what do you call the > > rented Akamai server? I call it a cache... > > (CDN is just an economic model for charging the provider for space > > on the cache) > > It's a surrogate which implements a cache. That's marketing doublespeak. It's a cache. > You've made my point well - Web > caching isn't a good economic model, and even risked legal problems at one > point, because it isn't done on behalf of the content provider. Rather, it > is done by the access provider, who isn't concerned with cache correctness, > etc. nearly as much as the content provider. > > Value-added services are a good thing, but there needs to be a framework to > address these issues. While some content providers may not care that their > content is transcoded by a proxy in front of the user, others may. > > For example, if a legal document is changed in any way (translated, > summarized, etc.) it becomes invalid. The primary problems with caching, in that sense, are: 1. content providers do not _want_ to provide expiration dates these dates must be determined in advance, and limit when changes will propagate. the CP's would like to 'recall' old items; this doesn't work with our current caching model, regardless of who runs the cache. the reason the CDNs are useful is that the CP's can push updated info out to the caches, in that sense 2. authentication is lacking CP's could sign their pages (e.g., PGP sign) again, there is disincentive, because it would inhibit user access (slow it down, stall it while waiting for key retrieval, etc) There is certainly a model for client-directed caching; several have worked just fine. Local premesis caching works if the organization is large (e.g., a school, a company, or a large ISP). Egress/ingress caching works on national scales, esp. where bandwidth is limited (e.g., Australia). The model is the same as TV and radio. People can decide what they want to see (e.g., PBS, request radio shows), but there is more money to be made by being advertiser-driven. E.g., I doubt people _want_ to watch infomercials all day long on the weekend, but there's money there. But you can buy pay-per-view or HBO and not have infomercials. People want to direct their cost (free); advertisers want to direct the content (and will pay). (but I digress - this may be an interesting coffeehouse chat at an upcoming IETF, though). > The most oft-cited example that makes me shudder is the dynamic > insertion/replacement of ads by the access provider, without permission of > the content provider. While I'm sure there's a market for this out there, it > brings up significant issues. Happens with local TV too. Without monitoring, it happens. > I'm not sure that IETF is the best place to address this; W3C seems (to > me) to have a more active view on social/legal issues. However, this is > where these capabilities are being talked about, so it seemed a good > starting point. These issues are addressed in the open court of public opinion, or in classes in business schools :-) Joe From owner-ietf-openproxy Wed Sep 20 10:28:33 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03115 for ietf-openproxy-bks; Wed, 20 Sep 2000 10:28:33 -0700 (PDT) Received: from 1-132.mnot.net (adsl-63-201-242-106.dsl.snfc21.pacbell.net [63.201.242.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03111 for ; Wed, 20 Sep 2000 10:28:32 -0700 (PDT) Received: by 1-132.mnot.net (Postfix, from userid 500) id B66216601; Wed, 20 Sep 2000 13:34:03 -0700 (PDT) Date: Wed, 20 Sep 2000 13:34:03 -0700 From: Mark Nottingham To: Joe Touch Cc: WREC Working Group , ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] Message-ID: <20000920133401.A890@mnot.net> References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> <20000919174124.A1719@mnot.net> <39C8EAEE.4BBA120D@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39C8EAEE.4BBA120D@isi.edu>; from touch@ISI.EDU on Wed, Sep 20, 2000 at 09:50:54AM -0700 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 20, 2000 at 09:50:54AM -0700, Joe Touch wrote: > The IETF, far as I can tell, doesn't consider these issues, unless: > > 1. there are technical solutions somewhere underlying > the social and/or legal > > AND > > 2. the legal issues constrain technical solutions > i.e., solutions which are obviously not viable > from the legal aspect are probably not worth > spending time on technically IMHO both conditions may be met; since there is a group actively discussing a framework to enable these functions, and there clearly are legal issues, even if the extent of those issues are unclear. I believe that there can be technical solutions to these problems, as it seems that there is other work in the IETF about trust models, etc. > > It's a surrogate which implements a cache. > > That's marketing doublespeak. It's a cache. Err, no, it's the terminology defined in the WREC Taxonomy. There can be significant differences in the cache implemented by a proxy and that implemented by a surrogate. > There is certainly a model for client-directed caching; several > have worked just fine. Local premesis caching works if the > organization is large (e.g., a school, a company, or a large ISP). > Egress/ingress caching works on national scales, esp. where > bandwidth is limited (e.g., Australia). There is a model, yes, but I'd debate that it's worked "just fine". Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy Wed Sep 20 10:30:14 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA03142 for ietf-openproxy-bks; Wed, 20 Sep 2000 10:30:14 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA03138 for ; Wed, 20 Sep 2000 10:30:13 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 20 Sep 2000 11:04:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Wed, 20 Sep 2000 11:03:51 -0600 From: "Hilarie Orman" To: , Cc: Subject: Re: End to End thoughts [long] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA03139 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If you've already bought into NAT, then pointing to an interception proxy as "evil" is simply pot-kettle calling. I'd be quite happy to have application headers contain directives to intermediaries describing the semantics (esp. "stateless; copyrighted; cacheable", "multipart; modifiable by insertion", "opaque") and authorizations ("customizable by enduser", "insertions by brokers"). However, it's more realistic right now to accomplish this by context, environment, and what amount to service level agreements about content between publishers and distributors. I agree that there are problems associated with modifiable content, but there are also huge advantages. Some things really should look different depending on where they are in the network. It all depends on what you mean by content and what the intent of the publisher is. To take a minor example, in traditional publishing the consumer doesn't get to specify the color or size of the paper and the text fonts; with browsers and HTML, the user can override the publisher's specification. In the physical world, such tricks may well be illegal. We need to assure that publishers and consumers can specify and resolve their rights and preferences in protocols so that intermediaries can exercise their capabilities in accordance with their expectations. Hilarie >>> Mark Nottingham 09/18/00 09:14PM >>> There's been a lot of talk in various places about end-to-end problems, and their relation to intermediates (e.g., HTTP caching proxies, surrogates, etc.). Things have gotten somewhat religious. Rather than go down that road, I'd like to examine the issues and separate them into distinct problems. * Network Layer The end-to-end principle applies to *network* layer functions; it is not meant to preclude an application-level gateway. I _think_ that most everyone will agree that functions that break end-to-end transparency at the network layer cause problems. In other words, Interception Proxies are Evil. While it's nice to think that we can convince the world of this, it's more realistic to find out why people use them, and give them a better alternative. To my knowledge, most people use them because they need an easy way to assure that Web traffic (or at least port 80) goes through a proxy. While browser have proxy auto-configuration, it hasn't changed in quite a few years, there's no standard to implement, and it relies on JavaScript. WPAD was a good start; unfortunately, it never really went to far beyond Microsoft. Additionally, a more sensible, standard format for the configuration file would help. Over all of this, we need participation from the browser vendors, or we won't get anywhere. * Application Layer All of this being said, HTTP intermediates *do* raise issues at the application layer, which aren't end-to-end problems, but do get confused with them, as the causes are similar. Proxies and surrogates can do a number of things to requests and responses as they flow through. I've been roughly classifying them as; - access control (e.g., blocking, filtering) - request modification (URI rewriting) - response modification (transcoding) These operations are often performed in the interest of one of different parties: - content provider - access provider - user There have been numerous papers and discussions about the interesting things that can be done by intermediates. However, I don't think there's enough attention being paid to the problems that enabling these functions on intermediates can cause. * HTTP The HTTP makes a primary assumption of semantic transparency - that an entity body will not be changed 'in flight' - that, discounting transfer-encodings and so forth, what the server sends in the response is what the client gets. Jeff Mogul brought up issues with entity identity, as expressed in the ETag, in Lisbon. There was also general concern (it may have been Jeff in particular, my memory isn't that good) that an operation performed in one portion of the network may not be performed in another, causing unpredicatable behaviours. There are lots of other little examples here that should be covered, but I'll leave it for now. * URI One of the premises of URIs is that they refer to a specific, identifyable resource, and that the authority for that resource has control over it. Many applications have dependencies on this. PICS, Robots Exclusion, P3P, and other kinds of metadata systems break, sometimes disasterously, when intermediates change the semantics and/or payload of a message. The privacy implications are especially of concern. Overall, content providers have a reasonable expectation that the object which they deliver will be the one that the user gets, unless the user doesn't want it. These effects are largely social and legal; however, they're enabled by the technology that's being pushed out there. We need to reconcile the capabilities of the products and frameworks that we're building with the expectations that have been set by our base protocols. It's interesting that Web caching seems to be losing ground to CDNs so rapidly; to me, this illustrates the point perfectly. Web caching was always performed in the interest of the access provider, not the content provider (or arguably even the user). As a result, content providers don't trust Web caches. What's it going to be like out there when access providers can slip a transcoding, rewriting module into a proxy on the fly? One person who I've talked about this with pointed out the issues we had a while back in caches vs. copyright, legally. There's much more direct potential for problems here. -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy Wed Sep 20 10:47:39 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03375 for ietf-openproxy-bks; Wed, 20 Sep 2000 10:47:39 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03371 for ; Wed, 20 Sep 2000 10:47:38 -0700 (PDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8KHoOe06392 env-from ; Wed, 20 Sep 2000 11:50:24 -0600 (MDT) Date: Wed, 20 Sep 2000 11:50:24 -0600 (MDT) From: Vernon Schryver Message-Id: <200009201750.e8KHoOe06392@calcite.rhyolite.com> To: wrec@cs.utk.edu Subject: Re: End to End thoughts [long] Cc: ietf-openproxy@imc.org Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: "Hilarie Orman" > To: , > Cc: > If you've already bought into NAT, then pointing to an interception > proxy as "evil" is simply pot-kettle calling. No, interception proxies are far worse than NAT. NAT merely breaks technical stuff. Interception proxies break all of the technical things that NAT boxes break and significantly more. E.g. AOL's SMTP redirection proxies probably break some addresses. Then interception proxies do really nasty non-technical things. They are open invitations for nasty non-technical things, from censorship to much easier snooping. For example, if some of the reports about the FBI's Carnivore are accurate, then AOL's SMTP interception proxies would far more easily and reliably do that job. > ... > To my knowledge, most people use them because they need an easy way (interception proxies) > to assure that Web traffic (or at least port 80) goes through a > proxy. ... A lot of people use various HTTP proxies, presumably including redirection proxies, to filter content. I know people who use them to "protect" their own children. (Never mind that I strongly disagree with them.) AOL's SMTP interception proxies are against spam. AOL adds header lines to SMTP messages and may filter objectionable content. Current rumors suggest that if AOL does filter SMTP on content with their SMTP redirection proxies, then they do it only by rate limiting. However, if they only rate limit, more than the censorship camel's nose is in the tent. Vernon Schryver vjs@rhyolite.com From owner-ietf-openproxy Wed Sep 20 10:52:02 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA03408 for ietf-openproxy-bks; Wed, 20 Sep 2000 10:52:02 -0700 (PDT) Received: from 1-132.mnot.net (adsl-63-201-242-106.dsl.snfc21.pacbell.net [63.201.242.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03404 for ; Wed, 20 Sep 2000 10:52:01 -0700 (PDT) Received: by 1-132.mnot.net (Postfix, from userid 500) id BEE3B6601; Wed, 20 Sep 2000 13:57:33 -0700 (PDT) Date: Wed, 20 Sep 2000 13:57:33 -0700 From: Mark Nottingham To: Hilarie Orman Cc: wrec@cs.utk.edu, ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] Message-ID: <20000920135732.B890@mnot.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from HORMAN@novell.com on Wed, Sep 20, 2000 at 11:03:51AM -0600 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 20, 2000 at 11:03:51AM -0600, Hilarie Orman wrote: [...] > I'd be quite happy to have application headers contain directives > to intermediaries describing the semantics (esp. "stateless; copyrighted; > cacheable", "multipart; modifiable by insertion", "opaque") and authorizations > ("customizable by enduser", "insertions by brokers"). However, it's more > realistic right now to accomplish this by context, environment, and what > amount to service level agreements about content between > publishers and distributors. I very much agree. Right now, I think we're at a point where we can try to get a handle on what's acceptable without some form of negotiation. > I agree that there are problems associated with modifiable content, > but there are also huge advantages. Some things really should look > different depending on where they are in the network. It all depends > on what you mean by content and what the intent of the publisher > is. To take a minor example, in traditional publishing the consumer > doesn't get to specify the color or size of the paper and the text fonts; > with browsers and HTML, the user can override the publisher's > specification. In the physical world, such tricks may well be illegal. I won't dispute the benefits, but this does break some assumptions in the HTTP and URI specifications. We need to deal with that. > We need to assure that publishers and consumers can specify and > resolve their rights and preferences in protocols so that intermediaries can > exercise their capabilities in accordance with their expectations. Here's a more concrete example of the kind of problem I'm talking about: The W3C's P3P working group is putting together a platform which allows specification of an XML privacy policy based on a URI. The major mechanism for this is a metadata file in a well-known location at the origin server which dictates how policies are applied to resources. If a proxy inserts ads, rewrites URIs, or does something else to change the privacy attributes of the resource, the privacy policy is invalid. If the content provider doesn't know about this, they're making privacy guarantees for resources that are beyond their control. P3P is unaware of the potential for modification of an object in the network, because a URI points to an identifiable resource, and semantic transparency is assumed in the HTTP. While the HTTP doesn't specifically forbid lack of transparency, it does put limitations on how it may happen; Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and might be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed * only by an explicit protocol-level request when relaxed by client or origin server * only with an explicit warning to the end user when relaxed by cache or client There are many assumptions in efforts like P3P that will break when you break semantic transparency. I haven't brought this up in the WG yet, because I wanted to get comments from this group. -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy Wed Sep 20 12:06:54 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA04762 for ietf-openproxy-bks; Wed, 20 Sep 2000 12:06:54 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04758 for ; Wed, 20 Sep 2000 12:06:53 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA03083; Wed, 20 Sep 2000 15:09:36 -0400 (EDT) Message-Id: <200009201909.PAA03083@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vernon Schryver cc: wrec@cs.utk.edu, ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] In-reply-to: Your message of "Wed, 20 Sep 2000 11:50:24 MDT." <200009201750.e8KHoOe06392@calcite.rhyolite.com> Date: Wed, 20 Sep 2000 15:09:36 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: good summary. interception proxies should really be illegal except when provided by the content-provider or by the end user. Keith From owner-ietf-openproxy Wed Sep 20 15:35:17 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA09271 for ietf-openproxy-bks; Wed, 20 Sep 2000 15:35:17 -0700 (PDT) Received: from nemo.corp.equinix.com (somehost-5.equinix.net [207.20.85.157] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09267 for ; Wed, 20 Sep 2000 15:35:16 -0700 (PDT) From: hardie@equinix.com Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id PAA06084; Wed, 20 Sep 2000 15:37:17 -0700 (PDT) Message-Id: <200009202237.PAA06084@nemo.corp.equinix.com> Subject: Re: End to End thoughts [long] To: mnot@mnot.net (Mark Nottingham) Date: Wed, 20 Sep 2000 15:37:17 -0700 (PDT) Cc: HORMAN@novell.com (Hilarie Orman), wrec@cs.utk.edu, ietf-openproxy@imc.org In-Reply-To: <20000920135732.B890@mnot.net> from "Mark Nottingham" at Sep 20, 2000 01:57:33 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've been trying to get a handle on how to express the problems I have with the framing of the end2end principal in this context. In the discussion below, Hilarie and Mark have obliquely pointed out where the problem lies: the distinction between service and protocol. The end2end principal derives from one of the most fundamental aspects of datagram networking, and it boils down to the notion that the end points of a network connection should be the only ones who need to care about the connection itself. The intermediate devices should be able to examine the datagram and know what to do (forward it somewhere, almost always), but they should not have to care about the connection between the two end points. The problem arises with the conflation of that network connection with a particular service provided on top of the network. It's an easy problem to have, because services have been historically provided at specific network nodes. Many URL schemes (and DNS names in general) resolve to specific nodes and specific ports, and the reason that so many people insert their service between the DNS request and the resolution is that that step is the closest one we have historically had to a service layer addressing scheme (yes, yes, SRVLOC exists--don't jump ahead). Once that resolution has taken place, though, most things boil down to a service layered on a end-to-end network connection. HTTP is a classic example of this: a unicast request/response protocol designed to make a local copy of a network-addressable resource. Making a local copy of a network-addressable resource is a pretty easy-to-describe service. The scaling problems with using that same unicast request/response protocol for every potential service on the network, though, have meant that more and more has been added to the protocol to support new service requirements or better support the scale of the existing service. As those got added in, that service ceased to be quite so easily layered on an end-to-end network connection. One early result of this was that the network addressable resource named in the HTTP URL might be provided by a node other than the node to which the address resolved; this was only the case, though, when a requestor had designated another node (a caching proxy) as a potential intermediate. Now service providers using HTTP also designate other nodes as potential agents (via surrogates and CDNs). With the service now being potentially provided through a chain that looks like: client--->caching proxy--->surrogate---->origin origin--->surrogate---->caching proxy--->client it's easy to see that the end2end connection between client and resource is not a necessary part of the service provision, even if the service provided is the same old making a local copy of a network addressable resource. There were, however, things you got for free when the client and the origin were the only parties to the service: freshness guarantees, some weak authentication, etc. Now they all those have to be made explicit. As Joe Touch has said, you can't substitute the aggregate of the hop-by-hop equivalents for an end2end connection. TLS between a client and a proxy, between the proxy and the surrogate and the surrogate and the origin does not add up to TLS between the client and the origin. As Vladis, Keith, and others have pointed out, one of the results of this is that modification can take place without the principal parties to the service being aware of that modification. That's bad, and we all know it. What we don't have a clear handle on is how to fix the problem without ripping out what we have now. I hope we can agree that we must substitute a service-based view of the applications for a connection-based view if we are to meet the current need. On a related note, I believe that one barrier to this at the moment is the continued use by the W3C of URLs as stand alone identifiers. As noted above, in some applications the resource named by a URL may be supplied by some other agent in the service; knowing that, the W3C has concluded that it is appropriate to use URLs as identifiers without reference to whether the resource is or is not available at that URL. Continuing to conflate a location and a resource once we have reached this point creates many more problems, in my view, than it can possibly solve. Working to create service addressing mechanisms that do not derive from network location seems to me a critical step to moving beyond application designs which presume the wrong things about service delivery. regards, Ted Hardie PS: If anyone reads the above as being a purist preaching, please understand that I am as big a sinner here as there is among us, and I am not trying to disavow the cruft for which I am personally responsible. > > On Wed, Sep 20, 2000 at 11:03:51AM -0600, Hilarie Orman wrote: > [...] > > I'd be quite happy to have application headers contain directives > > to intermediaries describing the semantics (esp. "stateless; copyrighted; > > cacheable", "multipart; modifiable by insertion", "opaque") and authorizations > > ("customizable by enduser", "insertions by brokers"). However, it's more > > realistic right now to accomplish this by context, environment, and what > > amount to service level agreements about content between > > publishers and distributors. > > I very much agree. Right now, I think we're at a point where we can try to > get a handle on what's acceptable without some form of negotiation. > > > > I agree that there are problems associated with modifiable content, > > but there are also huge advantages. Some things really should look > > different depending on where they are in the network. It all depends > > on what you mean by content and what the intent of the publisher > > is. To take a minor example, in traditional publishing the consumer > > doesn't get to specify the color or size of the paper and the text fonts; > > with browsers and HTML, the user can override the publisher's > > specification. In the physical world, such tricks may well be illegal. > > I won't dispute the benefits, but this does break some assumptions in > the HTTP and URI specifications. We need to deal with that. > > > > We need to assure that publishers and consumers can specify and > > resolve their rights and preferences in protocols so that intermediaries can > > exercise their capabilities in accordance with their expectations. > > > Here's a more concrete example of the kind of problem I'm talking about: > > The W3C's P3P working group is putting together a platform which allows > specification of an XML privacy policy based on a URI. The major mechanism > for this is a metadata file in a well-known location at the origin server > which dictates how policies are applied to resources. > > If a proxy inserts ads, rewrites URIs, or does something else to change the > privacy attributes of the resource, the privacy policy is invalid. If the > content provider doesn't know about this, they're making privacy guarantees > for resources that are beyond their control. > > P3P is unaware of the potential for modification of an object in the > network, because a URI points to an identifiable resource, and semantic > transparency is assumed in the HTTP. > > While the HTTP doesn't specifically forbid lack of transparency, it does put > limitations on how it may happen; > > Requirements for performance, availability, and disconnected operation > require us to be able to relax the goal of semantic transparency. The > HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly > reduce transparency when necessary. However, because non-transparent > operation may confuse non-expert users, and might be incompatible with > certain server applications (such as those for ordering merchandise), the > protocol requires that transparency be relaxed > > * only by an explicit protocol-level request when relaxed by client or > origin server > > * only with an explicit warning to the end user when relaxed by cache or > client > > There are many assumptions in efforts like P3P that will break when you > break semantic transparency. > > I haven't brought this up in the WG yet, because I wanted to get comments > from this group. > > -- > Mark Nottingham > http://www.mnot.net/ > From owner-ietf-openproxy Wed Sep 20 18:29:24 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12196 for ietf-openproxy-bks; Wed, 20 Sep 2000 18:29:24 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA12191 for ; Wed, 20 Sep 2000 18:29:22 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 20 Sep 2000 19:29:43 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Wed, 20 Sep 2000 19:29:47 -0600 From: "Hilarie Orman" To: Subject: Workshop presentations on website Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id SAA12192 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The presentations from the September 13 workshop are available via http://www.extproxy.org. Hilarie From owner-ietf-openproxy Fri Sep 22 05:55:43 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA02094 for ietf-openproxy-bks; Fri, 22 Sep 2000 05:55:43 -0700 (PDT) Received: from localhost.localdomain ([216.73.149.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02090 for ; Fri, 22 Sep 2000 05:55:41 -0700 (PDT) Received: (from mcmanus@localhost) by localhost.localdomain (8.9.3/8.8.7) id TAA00798; Thu, 21 Sep 2000 19:40:31 -0400 Date: Thu, 21 Sep 2000 19:39:16 -0400 From: Patrick McManus To: Mark Nottingham Cc: WREC Working Group , ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] Message-ID: <20000921193916.A791@appliedtheory.com> Reply-To: mcmanus@appliedtheory.com References: <20000918201408.D2609@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000918201408.D2609@mnot.net>; from mnot@mnot.net on Mon, Sep 18, 2000 at 08:14:08PM -0700 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [Mark Nottingham: Mon, Sep 18, 2000 at 08:14:08PM -0700] > It's interesting that Web caching seems to be losing ground to CDNs > so rapidly; to me, this illustrates the point perfectly. Web caching > was always performed in the interest of the access provider, not the > content provider (or arguably even the user). As a result, content > providers don't trust Web caches. I think your conclusion doesn't go far enough. I completely agree that caching is moving from a information consumer to information provider driven model, but I think this is because of both a lack of trust on the part of the information provider (as you assert) and a desire to see more thorough deployments. Information consumers, in many situations, didn't have sufficient motivation to deploy the infrastructure that the providers do and this limited the breadth of installations. CDN as an extension of hosting has really come, and I suspect will be with us for a while.. it makes interesting economic models available as choices.. (can I go with a bargain basement origin hosting facility if I have a decent CDN? Probably depends on your content..) -P From owner-ietf-openproxy Fri Sep 22 11:06:33 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA12878 for ietf-openproxy-bks; Fri, 22 Sep 2000 11:06:33 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA12874 for ; Fri, 22 Sep 2000 11:06:32 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 22 Sep 2000 12:08:57 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 22 Sep 2000 12:08:53 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: End to End thoughts [long] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id LAA12875 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Choosing a deployment method depends on the cost of the bandwidth. It comes down to a minimization problem. That's the original motivation for caching/replication and will always be a critical part of Internet scalability. It's interesting to compare this to the evolution of distribution of other forms of content, historically. New technology rolls through the same set of economic forces as the old. An important question that Andrew Odlyzko of ATT Research has been noting for some time, is that historically there is a greater economic incentive for person-person communication that for content distribution, and therefore, it may be more important to engineer infrastructure for the former rather than the latter. Hilarie >>> Patrick McManus 09/21/00 05:39PM >>> [Mark Nottingham: Mon, Sep 18, 2000 at 08:14:08PM -0700] > It's interesting that Web caching seems to be losing ground to CDNs > so rapidly; to me, this illustrates the point perfectly. Web caching > was always performed in the interest of the access provider, not the > content provider (or arguably even the user). As a result, content > providers don't trust Web caches. I think your conclusion doesn't go far enough. I completely agree that caching is moving from a information consumer to information provider driven model, but I think this is because of both a lack of trust on the part of the information provider (as you assert) and a desire to see more thorough deployments. Information consumers, in many situations, didn't have sufficient motivation to deploy the infrastructure that the providers do and this limited the breadth of installations. CDN as an extension of hosting has really come, and I suspect will be with us for a while.. it makes interesting economic models available as choices.. (can I go with a bargain basement origin hosting facility if I have a decent CDN? Probably depends on your content..) -P From owner-ietf-openproxy Mon Sep 25 15:51:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA26107 for ietf-openproxy-bks; Mon, 25 Sep 2000 15:51:30 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA26102 for ; Mon, 25 Sep 2000 15:51:28 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06819 for ; Mon, 25 Sep 2000 15:54:42 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA24773 for ; Mon, 25 Sep 2000 15:54:42 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8PMsfe938374 for ; Mon, 25 Sep 2000 15:54:41 -0700 (PDT) Message-Id: <200009252254.e8PMsfe938374@jurassic.eng.sun.com> Date: Mon, 25 Sep 2000 15:55:30 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: EPSFW Web site updates To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /SpYpSY9VE/6SEq7S7Y8bg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ALL- Hilarie has updated the web site. If your presentation is missing then get it to me. Others, comments? Michael From owner-ietf-openproxy Wed Sep 27 09:45:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01510 for ietf-openproxy-bks; Wed, 27 Sep 2000 09:45:31 -0700 (PDT) Received: from 1-132.mnot.net (adsl-63-201-242-106.dsl.snfc21.pacbell.net [63.201.242.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01506 for ; Wed, 27 Sep 2000 09:45:30 -0700 (PDT) Received: by 1-132.mnot.net (Postfix, from userid 500) id 616EB6601; Wed, 27 Sep 2000 09:48:39 -0700 (PDT) Date: Wed, 27 Sep 2000 09:48:39 -0700 From: Mark Nottingham To: WREC Working Group , ietf-openproxy@imc.org Subject: [Internet-Drafts@ietf.org: I-D ACTION:draft-nottingham-cache-extensions-00.txt] Message-ID: <20000927094837.A1064@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a draft of something I helped cook up at my previous job, with a cache vendor. Some people have been asking for this type of functionality recently, so here it is (much delayed). Cheers, ----- Forwarded message from Internet-Drafts@ietf.org ----- Date: Wed, 27 Sep 2000 06:31:15 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-nottingham-cache-extensions-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : HTTP Cache Control Extensions for Direct Cache Manipulation Author(s) : M. Nottingham Filename : draft-nottingham-cache-extensions-00.txt Pages : 5 Date : 25-Sep-00 HTTP/1.1 provides for extensions to Cache-Control headers, which provide new methods of controlling caches. This document specifies extensions which allow content providers more precise control over shared caches. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nottingham-cache-extensions-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nottingham-cache-extensions-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nottingham-cache-extensions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- -- Mark Nottingham http://www.mnot.net/ From owner-ietf-openproxy Thu Oct 5 12:30:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA09287 for ietf-openproxy-bks; Thu, 5 Oct 2000 12:30:57 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA09283 for ; Thu, 5 Oct 2000 12:30:55 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 05 Oct 2000 13:34:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 05 Oct 2000 13:34:13 -0600 From: "Hilarie Orman" To: Subject: Agenda for IETF San Diego EPSFW meeting Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA09284 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We need to assemble an agenda for our meeting at the next IETF. Please send me your presentation title and the amount of time you'll need. We'd like to hear about prototyping efforts, use cases, proxylet languages, ICAP implementations, authentication and authorization, identity definitions, etc. Hilarie From owner-ietf-openproxy Thu Oct 19 11:34:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA07365 for ietf-openproxy-bks; Thu, 19 Oct 2000 11:34:56 -0700 (PDT) Received: from akamai.com (akafire-exodus.akamai.com [64.14.77.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07361 for ; Thu, 19 Oct 2000 11:34:54 -0700 (PDT) Received: from akamai.com (vwall1.kendall.akamai.com [172.24.40.125]) by akamai.com (8.10.1/8.10.1) with ESMTP id e9JIdjC11585 for ; Thu, 19 Oct 2000 14:39:45 -0400 (EDT) Received: from ssh-gw.sanmateo.akamai.com (IDENT:root@ssh-gw.sanmateo.akamai.com [172.23.1.53]) by akamai.com (8.10.1/8.10.1) with ESMTP id e9JIdGb11408 for ; Thu, 19 Oct 2000 14:39:26 -0400 (EDT) Received: (from mnot@localhost) by ssh-gw.sanmateo.akamai.com (8.9.3/8.9.3) id LAA25691 for ietf-openproxy@imc.org; Thu, 19 Oct 2000 11:37:16 -0700 Date: Thu, 19 Oct 2000 11:37:16 -0700 From: Mark Nottingham To: ietf-openproxy@imc.org Subject: Charter? Message-ID: <20001019113715.C25550@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've seen a new name for this group floating around, but no references to how that came about... just curious, what's the story? Also, does (whatever this effort is now ;) have a proposed charter for the BOF? Cheers, -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-ietf-openproxy Thu Oct 19 12:02:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08392 for ietf-openproxy-bks; Thu, 19 Oct 2000 12:02:25 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA08388 for ; Thu, 19 Oct 2000 12:02:24 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 19 Oct 2000 13:07:06 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 19 Oct 2000 13:06:54 -0600 From: "Hilarie Orman" To: , Subject: Re: Charter? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA08389 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am acronym facile; the IETF call for working groups required an acronym, and Open Extensible Proxy Services has an acceptable acronym that is the weighted average of all names that have been used for this group. So, I used it; consistency, you know, is the hobgoblin of little minds. Of course, the charter should be a product of the first BOF or WG meeting, but this is what I've submitted as a placeholder: The proxy services area defines protocols and API's that enable proxies extend their services beyond protocol relays and caching. The working group will develop documents defining the architecture, policy model and elements, and terminology. Protocols for delivering new services and policies related to their execution will be defined and developed. Other protocols, allowing the services to communicate information about the protocol elements of the proxied protocol, will be developed. A security architecture for the administration of proxies with third party services will be defined. The API to core services, such as protocol control and use, will be defined. Hilarie From owner-ietf-openproxy Mon Oct 23 12:59:42 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA22840 for ietf-openproxy-bks; Mon, 23 Oct 2000 12:59:42 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22836 for ; Mon, 23 Oct 2000 12:59:41 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03485; Mon, 23 Oct 2000 13:04:54 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA17201; Mon, 23 Oct 2000 13:04:53 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9NK4qf903332; Mon, 23 Oct 2000 13:04:52 -0700 (PDT) Message-Id: <200010232004.e9NK4qf903332@jurassic.eng.sun.com> Date: Mon, 23 Oct 2000 13:05:45 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: update for a 49th IETF WG/BOF Scheduling request To: paf@cisco.com, Ned.Freed@west.sun.com, agenda@ietf.org Cc: ietf-openproxy@imc.org, dinaras@ietf.org, marcia@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: oDoXxMMSCB0Ceeu+z7OiMw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an update of an Working Group request sent earlier on October 8th: This is an updated request for a new working group meeting at the 49th IETF. The group is Open and Extensible Proxy Services, OEPS, in the applications area. There is a draft, draft-tomlinson-epsfw-00.txt, describing the architecture of the proxy services environment, an open mailing list, ietf-openproxy@imc.org, a website, www.extproxy.org, and the presentations at a technology workshop for this sort of architecture that was held on September 13 are at the website. The proposed agenda is Introduction: Hilarie Orman Use Cases: Marcus Hofmann and Michael Condry Workshop Summary: Michael Condry Revelant ICAP Progress: TBD Relationship to CDN Peering: Mark Day Document Roadmap: Hilarie Orman Architecture Discussion Discussion of other documents Assignments and Administrivia The proxy services area defines protocols and API's that enable proxies extend their services beyond protocol relays and caching. The working group will develop documents defining the architecture, policy model and elements, and terminology. The working group will also work with other working groups where that can apply this architecture to resolve problems in under their charter. The kinds of services where the architecture can be applied include: - Proxy functions such as URL accounting, and transcoding from a general HTML or XML description into one suitable for the user agent. - Callout services such as iCAP. - Content driven caching services such as for streaming. - Content driven network management. - Embedded systems director. Protocols for delivering new services and policies related to their execution will be defined and developed. Other protocols, allowing the services to communicate information about the protocol elements of the proxied protocol, will be developed. Cross working group problem areas, such as caching, will focus on the proxy architecture cooperating with the appropriate working group - such as WREC for caching. A security architecture for the administration of proxies with third party services will be defined. The API to core services, such as protocol control and use, will be defined. This group may also be a suitable home for starting organization of callout services. Our proxy architecture will be consistent the needs of the CDN Peering effort. We will have formal liaisons with WREC, CDN, or other appropriate working groups. We expect attendance of 50 people; we would like to avoid conflict with any WREC or CDN Peering WG's or the IPSP WG. Hilarie Orman and Michael Condry, Chairs From owner-ietf-openproxy Tue Oct 24 13:50:48 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA14153 for ietf-openproxy-bks; Tue, 24 Oct 2000 13:50:48 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14148 for ; Tue, 24 Oct 2000 13:50:47 -0700 (PDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09745; Tue, 24 Oct 2000 13:56:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA20585; Tue, 24 Oct 2000 13:55:35 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9OKtXf178060; Tue, 24 Oct 2000 13:55:34 -0700 (PDT) Message-Id: <200010242055.e9OKtXf178060@jurassic.eng.sun.com> Date: Tue, 24 Oct 2000 13:56:27 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: BCD Forum meeting To: ietf-openproxy@imc.org Cc: wrec@cs.utk.edu, cdn@ops.ietf.org, paf@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SN8nOtNspTNOvuKo+HUcVw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The BCDF (Broadband Content Delivery Forum) charter is to determine the requirements needed for broadband content delivery. Examining the issues concerning content delivery is coming up a critical area of interest for the Internet folks because of the heading "merger" of network technologies: IP, Cable, Voice, etc. The big content owners, CNN, CBS, NBC, ABC, Time-Warner, etc. are highly concerned with this area including - finding content - how to locate it - delivery of content - receiving "well presented" content - billing - assuring that the content taker is billed (both billing and security). The BCDF was created by Nortel but has since the start restructured itself as an industry consortium focused on broadband issues. The membership is strongly represented by the Telco areas. Projects are partitioned into three areas, called working groups: 1. Market Development - focused on BCDF (broadband) market development issues. 2. Content and Applications - working with the Content groups to assure requirements are met. 3. Infrastructure - defining the requirements for the infrastructure. There are many similarities with the Content Alliance and Content Bridge. All groups seem to be strongly represented by the infrastructure guys and weekly represented by the actual content owners. The Content Alliance is creating the CDN working group at the IETF. My experience and BCDF was with the general forums and infrastructure groups. Although some members were in the "lets invent it here" mode most agreed that listing the requirements and submitting them to the IETF would be the most productive. They also agreed that having the BCDF spend most of its energy working with the content providers to obtain requirements would be the most productive (certainly more than trying to create a different but similar set of specifications to the IETF CNF group). We agreed to get the Content and Applications folks focused on that and attempt to enumerate the broadband requirements for the concerns listed above (location, delivery, billing). I presented the open proxy services architecture and how it might be employed in solving some of their broadband issues. The infrastructure folks felt that the open proxy services model was exactly the kind of infrastructure needed for services in a merged networked technologies environment. They plan to support this for the upcoming IETF. I also gave them a brief overview of the IETF and suggested a plan for submitting requirements there (rather than any self invention). In my opinion they are still too technology focused and not sufficiently strong in understanding the operational rules of the "content "owners. This group has the benefit of beliving that it would be better to let the IETF sort out the technical issues. From owner-ietf-openproxy Wed Nov 1 12:30:09 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA09720 for ietf-openproxy-bks; Wed, 1 Nov 2000 12:30:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09709 for ; Wed, 1 Nov 2000 12:30:04 -0800 (PST) Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02314 for ; Wed, 1 Nov 2000 13:36:19 -0700 (MST) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id NAA05023 for ; Wed, 1 Nov 2000 13:36:18 -0700 (MST) Received: from condry.org by esun1as-mm. (SMI-8.6/SMI-SVR4) id NAA08757; Wed, 1 Nov 2000 13:46:54 -0700 Message-ID: <3A007DA5.FAABCA51@condry.org> Date: Wed, 01 Nov 2000 12:31:33 -0800 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN MIME-Version: 1.0 To: openproxy Subject: Updated OPES charter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Open Proxy Extended Services architecture (opes) Co-chairs: Michael Condry Hilarie Orman Mailing Lists: [TENTATIVE] General Discussion: ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Web: http://www.extproxy.org Archive: ftp://ftp.ietf.org/ietf-mail-archive/opes Description of Working Group: The Open Proxy Extensible Services architecture (OPES) enables construction of services "inside the network"; these can be used by content providers for efficient caching, content administration, communication, and network control functions. Other users of the services include third-party content-related services such as transcoders, regional affiliates, etc. The open proxy extensible services architecture focuses on situations with intermediate network elements providing the locus of control and execution of the service function. The proxy services are content directed: thus, the proxy understands at least some of the content semantics and provides a service platform that operates within the content flow. For example, it provides an opportunity to instruct the cache that certain types of data are cacheable. The OPES WG will work with WEBI/WREC group to define or follow specifications for communication between the web cache sub-system and proxies to take advantage of this information in creating a strategy for caching and proxying that is more efficient than being "content ignorant". The OPES WG will develop protocols for the proxy server to provide "callout" services (e.g. iCAP, the content adaptation protocol) and provide a forum for iCAP to submit and discuss its specifications. The callout server may create copies of web pages, possibly in a different form, e.g. a different natural language. Open Proxy protocols will have the ability to communicate cache and proxy specific information with surrogates and/or origin servers, for example, in order to inform the origin that it has two representations of the same content. There are points of interoperation required with Content Distribution Networks, for example, in exchanging accounting related information. Content Distribution Networks are the primary subject of the CDNP group. After the initial protocols have been specified, the open proxy extensible services group also will develop protocols to facilitate routing traffic within cache system (specified by WEBI/WREC) along alternate paths to minimize time or cost. Goals and Milestones: Feb 01: Requirements and roadmap documents for WG Feb 01: First draft callout protocol; first draft information model Mar 01: Meet at Minneapolis IETF Mar 01: Update of OPES architecture document, draft-tomlinson-epsfw-00.txt. Jun 01: Submission of security and authentication architecture Aug 01: Meet at London IETF Aug 01: Final submission of callout protocol; final submission of information model Oct 01: Submission of data model for service description, invocation, results Dec 01: Salt Lake City IETF, final submission of architecture document Agenda for December, San Diego Meeting Introduction: Hilarie Orman Use Cases: Marcus Hofmann Workshop Summary: Michael Condry ICAP Progress: Mark Nottingham Relationship to CDN Peering: Mark Day Document Roadmap: Hilarie Orman Charter Bashing: Michael Condry Architecture Requirements Discussion: Hilarie Orman Discussion of other documents Assignments and Administrivia From owner-ietf-openproxy Wed Nov 1 12:35:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA09949 for ietf-openproxy-bks; Wed, 1 Nov 2000 12:35:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09945 for ; Wed, 1 Nov 2000 12:35:58 -0800 (PST) Received: from centralmail1.Central.Sun.COM ([129.147.62.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05953; Wed, 1 Nov 2000 13:42:14 -0700 (MST) Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id NAA06615; Wed, 1 Nov 2000 13:41:42 -0700 (MST) Received: from condry.org by esun1as-mm. (SMI-8.6/SMI-SVR4) id NAA08822; Wed, 1 Nov 2000 13:52:17 -0700 Message-ID: <3A007EE9.CE9316EA@condry.org> Date: Wed, 01 Nov 2000 12:36:57 -0800 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN MIME-Version: 1.0 To: openproxy , iCAP , CDNP Subject: Changes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As of Monday (Nov 6th) my contact information changes. However, my focus of attention with these groups continues. My new data is: Michael Condry Director of Internet Strategy Intel Labs Intel Corporation 2111 NE 25th Avenue M/S JF3-206 Hillsboro, OR 97124 503-264-9019 condry@intel.com condry@condry.org From owner-ietf-openproxy Wed Nov 1 13:29:46 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA10977 for ietf-openproxy-bks; Wed, 1 Nov 2000 13:29:46 -0800 (PST) Received: from web1502.mail.yahoo.com (web1502.mail.yahoo.com [128.11.23.180]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA10973 for ; Wed, 1 Nov 2000 13:29:44 -0800 (PST) Received: (qmail 18590 invoked by uid 60001); 1 Nov 2000 21:36:06 -0000 Message-ID: <20001101213606.18589.qmail@web1502.mail.yahoo.com> Received: from [192.32.225.117] by web1502.mail.yahoo.com; Wed, 01 Nov 2000 13:36:06 PST Date: Wed, 1 Nov 2000 13:36:06 -0800 (PST) From: Thomas Hardjono Subject: IETF49 Multicast Security (MSEC) BOF details To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, This might be of some interest to open-proxy, as some of the technology may be applicable. Yours, Thomas Hardjono --------------- --------------------------------------------------------------------------- Multicast Security BOF (msec) Tuesday, December 12 at 1415-1515 Tuesday, December 12 at 1700-1800 ================================= CHAIR: Ran Canetti Thomas Hardjono DESCRIPTION: There is significant interest in the networking industry and content delivery network industry to use IP multicast a vehicle for data delivery to a large audience. One major hindrance to the successful deployment of IP multicast and other group-oriented communication protocols has been the lack of security for both the content and the content-delivery infrastructure. In particular, there has been increasing demand for secure solutions for the 1-to-Many type of group communications, as exemplified by the interest of the cable television sector in using the Internet for content distribution and by the recent emergence of the single-source paradigm in IP multicasting. To this end, the Secure Multicast (SMuG) research group was formed in 1998 under the umbrella of the IRTF. That group has characterized the security concerns and problem areas, has come up with a framework for an overall solution, and has developed protocols for solving much of the problem space in a satisfactory manner. Several of these protocols have reached the needed maturity to be considered for standardization at the IETF. The proposed WG will further develop and standardize the protocols developed at the SMuG RG. The focus will be on mature protocols that are deployable in short term in today's internet. The SMuG RG will continue to examine issues that need further research, delivering protocols to MSEC when they are mature. In the immediate future MSEC will focus on the 1-to-Many group communication, and will address at least the following issues: - Developing the transformations to be applied to the multicasted data. These transformations will provide at least the following functionalities: + Encryption of data using a group key available to all members. + Source and Data Authentications even when the data receivers do not trust each other. Both functionalities are required for content-authors and content-distributors. They represent an important element in the larger digital rights management area. - Group Security Association and Key Management. Secure protocols are needed for management of cryptographic keys and Security Associations for groups. These include techniques for initial key dissemination, key updates and refreshments, and Group Security Association (Group SA) management. Depending on the acceptance and stability of the above two issues, the following issues will be addressed by the WG in the immediate future: - Group Security Policies. Different levels of policies exist for a group, covering a range from member behavior to cryptographic policies. - Secure group announcements. Information regarding the existence of a group, its policies, base security mechanisms and methods for joining needs to be announced in a suitable manner. Secure multicast touches upon the work of several other working groups. The proposed WG will take care to coordinate its activities with the relevant directorates (security, routing, transport) and especially with the IPSec and RMT working groups. The WG will not work on: - Security issues at firewalls and NATs relating to multicast traffic. - Protection against illegal re-distribution of multicasted data. AGENDA: 10 mins - Agenda bashing 10 mins - Charter presentation 80 mins - Internet draft presentations: 10 mins - Taxonomy of multicast security concerns (draft-irtf-smug-taxonomy-01.txt) 10 mins - Framework overview (draft-irtf-smug-framework-01.txt) - Data transforms: 10 mins - Overall design (draft-irtf-smug-data-transforms-00.txt) 10 mins - Source authentication (draft-irtf-smug-tesla-00.txt) - Group key and SA management 10 mins - GKM Building Block (draft-irtf-smug-gkmbb-gsadef-00.txt) 10 mins - GSAKMP (draft-harney-sparta-gsakmp-sec-02.txt) 10 mins - Group DOI for ISAKMP (draft-irtf-smug-gdoi-00.txt) 10 mins - Group policy management (draft-mcast-pol-req00.txt) 20 mins - Open Discussion (work descriptions, objectives, goals/milestones) MAILING LIST The mailing list is at msec-request@securemulticast.org (or email the chairs). The website is at www.securemulticast.org READING MATERIAL draft-irtf-smug-taxonomy-02.txt draft-irtf-smug-framework-01.txt draft-irtf-smug-data-transforms-01.txt draft-irtf-smug-tesla-00.txt draft-irtf-smug-gkmbb-gsadef-00.txt draft-harney-sparta-gsakmp-sec-02.txt draft-irtf-smug-gdoi-00.txt draft-irtf-smug-pol-req00.txt --------------------------------------------------------------------------- __________________________________________________ Do You Yahoo!? >From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ From owner-ietf-openproxy Fri Nov 3 12:04:20 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA15828 for ietf-openproxy-bks; Fri, 3 Nov 2000 12:04:20 -0800 (PST) Received: from kiwi.equinix.com (kiwi.equinix.com [207.20.85.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15821 for ; Fri, 3 Nov 2000 12:04:18 -0800 (PST) Received: from icooper.equinix.com (tunnel2-9.corp.equinix.com [172.16.252.9]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id MAA05222; Fri, 3 Nov 2000 12:10:28 -0800 (PST) Message-Id: <5.0.0.25.2.20001103194204.00a8ddd0@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 03 Nov 2000 20:10:26 +0000 To: wrec@cs.utk.edu From: Ian Cooper Subject: Candidate re-charter/new WG Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Ned Freed , cdn@ops.ietf.org, ietf-openproxy@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Now that we appear to have gotten to the end of the WREC work items (there will be a new version of the Known Problems document - just changing the order of things as an outcome of the Pittsburgh meeting - submitted in the next few days), we need to decide how to move on. Below is a candidate (re)charter to take WREC forward as the "Web Infrastructure" group (thanks to those who have given input of their varying types). As you'll see, the idea is to take on two work items that we believe are essential for web infrastructure going forward. There is some cross over with the invalidation protocol with the CDNP folks. Since such a protocol is applicable to both areas, and since the CDNP folks look to have plenty of other interesting things to work on, WREC/WEBI appears to be a good place to work on this essential issue. Likewise, there is some degree of cross over with the intermediary discovery protocol. In order to have some hope of moving away from interception proxy environments, we need to help user agents find intermediates (proxies, extensible proxies, surrogates). Given that this is an area where two proposed WGs (CDNP, OPES) would also have an interest, and since it doesn't appear to be directly in scope for either, we feel that WREC/WEBI is the best place for this. Why the name change? As (caching) proxies and surrogates become essential components in the web infrastructure we need to examine interactions between these systems. "Web Replication and Caching" doesn't seem a sufficiently descriptive group name. There also appears to be a general feeling of WREC=bad (and the name when spoken doesn't help any) that we'd like to try and move away from. At present it's not totally clear whether we should be going direct to a working group in San Diego, or whether we should go through a BoF stage to discuss the area and determine whether the group is necessary (and if not where the work items should be handled). Apologies for the short notice, but obviously we need to get an idea of what we're doing in time to request a meeting in San Diego. Truncating the distribution to the WREC list (the "webi" list has *not* been set up yet) would probably be a good idea. (I'd set a Reply-To but I don't know how to drive that part of my mail agent ;-) ) Comments please! --------------------------->8------------------------------------------- Web Infrastructure (webi) Co-chairs: Mark Nottingham Ian Cooper Mailing Lists: [TENTATIVE] General Discussion: webi@equinix.com To Subscribe: webi-request@equinix.com Archive: ftp://ftp.ietf.org/ietf-mail-archive/webi Description of Working Group: This working group will address specific issues identified by the WREC working group in the world wide web infrastructure, providing generic mechanisms which are useful in several application domains (proxies, content delivery surrogates). Work items for this group will be: 1) An invalidation protocol to provide a strong cache coherence mechanism while avoiding the latency penalty of validation, usable in proxy as well as surrogate configurations. 2) An intermediate service discovery mechanism, consisting of: a) An intermediary service description format, which describes what services an intermediary or arbitrary group of intermediaries is willing to provide, and b) A discovery protocol for locating relevant service descriptions within a single administrative domain. Both components will take into consideration current practice, related work in the IETF, and a reasoned set of requirements, which will include the need to provide a reasonable alternative to interception proxies. Service discovery, and other issues pertaining to coordination between multiple administrative domains are explicitly out of scope of this group. Protocols associated with the provisioning of value added services, including the vectoring of adaptation requests to other devices, is also out of scope for this group. Goals and Milestones: Feb 01: Requirements document for intermediary discovery and description Feb 01: First draft invalidation protocol Mar 01: Meet at Minneapolis IETF Apr 01: First draft intermediary discovery protocol Jul 01: First draft intermediary description mechanism Aug 01: Meet at London IETF Dec 01: Invalidation protocol finalized Dec 01: Salt Lake City Jan 02: Intermediary discovery protocol finalized Mar 02: Intermediary description mechanism finalized Apr 02: Re-charter From owner-ietf-openproxy Sun Nov 5 00:58:04 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA04859 for ietf-openproxy-bks; Sun, 5 Nov 2000 00:58:04 -0800 (PST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04849 for ; Sun, 5 Nov 2000 00:58:02 -0800 (PST) Received: from lgregoir-nt2 (richvill-dsl3.cisco.com [10.19.134.124]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA20976; Sun, 5 Nov 2000 01:03:11 -0800 (PST) Message-Id: <4.2.0.58.20001105000719.02331460@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 05 Nov 2000 01:06:23 -0700 To: Ian Cooper , wrec@cs.utk.edu From: Dan Li Subject: Re: Candidate re-charter/new WG Cc: Patrik =?iso-8859-1?Q?Fältström?= , Ned Freed , cdn@ops.ietf.org, ietf-openproxy@imc.org In-Reply-To: <5.0.0.25.2.20001103194204.00a8ddd0@nemo.corp.equinix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think it's a good idea to have a focused forum to get something done. A web cache invalidation protocol will bring much value to reverse proxies (surrogates), forward proxies, and CDNs alike. Having WEBI devoted to it is a good thing. Whatever WREC is bad for, I hope the execution of WEBI would remove any residue of that. At 08:10 PM 11/3/00 +0000, Ian Cooper wrote: >Now that we appear to have gotten to the end of the WREC work items (there >will be a new version of the Known Problems document - just changing the >order of things as an outcome of the Pittsburgh meeting - submitted in the >next few days), we need to decide how to move on. > >Below is a candidate (re)charter to take WREC forward as the "Web >Infrastructure" group (thanks to those who have given input of their >varying types). As you'll see, the idea is to take on two work items that >we believe are essential for web infrastructure going forward. > >There is some cross over with the invalidation protocol with the CDNP >folks. Since such a protocol is applicable to both areas, and since the >CDNP folks look to have plenty of other interesting things to work on, >WREC/WEBI appears to be a good place to work on this essential issue. > >Likewise, there is some degree of cross over with the intermediary >discovery protocol. In order to have some hope of moving away from >interception proxy environments, we need to help user agents find >intermediates (proxies, extensible proxies, surrogates). Given that this >is an area where two proposed WGs (CDNP, OPES) would also have an >interest, and since it doesn't appear to be directly in scope for either, >we feel that WREC/WEBI is the best place for this. > >Why the name change? As (caching) proxies and surrogates become essential >components in the web infrastructure we need to examine interactions >between these systems. "Web Replication and Caching" doesn't seem a >sufficiently descriptive group name. There also appears to be a general >feeling of WREC=bad (and the name when spoken doesn't help any) that we'd >like to try and move away from. > >At present it's not totally clear whether we should be going direct to a >working group in San Diego, or whether we should go through a BoF stage to >discuss the area and determine whether the group is necessary (and if not >where the work items should be handled). > >Apologies for the short notice, but obviously we need to get an idea of >what we're doing in time to request a meeting in San Diego. Truncating >the distribution to the WREC list (the "webi" list has *not* been set up >yet) would probably be a good idea. (I'd set a Reply-To but I don't know >how to drive that part of my mail agent ;-) ) > >Comments please! > > >--------------------------->8------------------------------------------- > >Web Infrastructure (webi) > >Co-chairs: > Mark Nottingham > Ian Cooper > >Mailing Lists: [TENTATIVE] > General Discussion: webi@equinix.com > To Subscribe: webi-request@equinix.com > Archive: ftp://ftp.ietf.org/ietf-mail-archive/webi > >Description of Working Group: > >This working group will address specific issues identified by the WREC >working group in the world wide web infrastructure, providing generic >mechanisms which are useful in several application domains (proxies, >content delivery surrogates). > >Work items for this group will be: > >1) An invalidation protocol to provide a strong cache coherence mechanism > while avoiding the latency penalty of validation, usable in proxy as well > as surrogate configurations. > >2) An intermediate service discovery mechanism, consisting of: > > a) An intermediary service description format, which describes what > services an intermediary or arbitrary group of intermediaries is > willing to provide, and > > b) A discovery protocol for locating relevant service descriptions within > a single administrative domain. > > Both components will take into consideration current practice, related > work in the IETF, and a reasoned set of requirements, which will include > the need to provide a reasonable alternative to interception proxies. > >Service discovery, and other issues pertaining to coordination between >multiple administrative domains are explicitly out of scope of this group. > >Protocols associated with the provisioning of value added services, >including the vectoring of adaptation requests to other devices, is also >out of scope for this group. > > >Goals and Milestones: > >Feb 01: Requirements document for intermediary discovery and description >Feb 01: First draft invalidation protocol >Mar 01: Meet at Minneapolis IETF >Apr 01: First draft intermediary discovery protocol >Jul 01: First draft intermediary description mechanism >Aug 01: Meet at London IETF >Dec 01: Invalidation protocol finalized >Dec 01: Salt Lake City >Jan 02: Intermediary discovery protocol finalized >Mar 02: Intermediary description mechanism finalized >Apr 02: Re-charter > > From owner-ietf-openproxy Mon Nov 6 12:43:02 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA00483 for ietf-openproxy-bks; Mon, 6 Nov 2000 12:43:02 -0800 (PST) Received: from glatton.cnchost.com (glatton.cnchost.com [207.155.248.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00477 for ; Mon, 6 Nov 2000 12:42:57 -0800 (PST) Received: from fringent.com (fringent.dsl.telerama.com [205.201.10.94]) by glatton.cnchost.com id PAA25466; Mon, 6 Nov 2000 15:49:35 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A071944.184C1E12@fringent.com> Date: Mon, 06 Nov 2000 15:49:08 -0500 From: Steve Moyer Reply-To: moyer@fringent.com X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: EPSFW processing models Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've been meaning since the September workshop to start a discussion on the high-level processing model proposed in the EPSFW draft, as well as some alternatives. This note is intended to get the ball rolling, but it is certainly far from complete. Below I briefly examine three processing models: the Rule Model, the Script Model, and the Streams Model. The Rule Model, which is the processing model proposed in the draft, is given the most attention. Regards, Steve ----------------------------------------------------------------------------- Rule Model ---------- The Rule Model is the processing model defined in the draft. To save some typing in the following discussion, I use these acronyms for terms defined in that document: PSEE = proxy service execution environment PL = proxylet library (language bindings for the PSEE API) RM = rule module A RM defines a set of patterns that, when matched, cause actions to be fired. The actions can be calls to proxylets, the PL, or remote callouts, all of which can modify the PSEE state in general, and the relevant message in particular. Below are various thoughts/observations/questions regarding this processing model and/or its definition in the draft. 1) Clearly a RM is essentially an application. What is less clear in the draft is whether a proxylet is bound to a particular RM (that is, it is part of a specific application) or if a proxylet is instead accessible from any RM. There are both useability and security implications here. >From a useability standpoint, it would be convenient if proxylets were independent of RMs. This would allow proxylets to be called from multiple RMs and to implement utility functions that can be called from other proxylets. Viewing proxylets as a shared resource, rather than as part of an application, allows them to generically extend the PL. >From a security standpoint, binding proxylets to RMs results in a simpler security model. The draft states that "there must be a way to associate a [RM] with a single owner", so there is already a defined security context for RMs. If an RM and a set of proxylets are all part of the same application, then a proxylet always executes in the same security context as the RM to which it is bound. Otherwise, if proxylets are independent of RMs, then a proxylet executes in the security context of the calling RM. In this case there also needs to be a security model to determine which RMs can call which proxylets (directly or via other proxylets). Another security/resource/management issue with shared proxylets is that if the PSEE decides that a proxylet is hung, malicious, or otherwise bad, then ejecting/restarting the proxylet will effect multiple applications (RMs). 2) The draft defines a coarse-grained message flow lifecycle that contains four points at which rules can be triggered. I would argue that a more fine-grained lifecycle model will be needed to support multiple applications concurrently and to provide a basis for resolving rule conflicts. While I'll leave the details of this for a later discussion, I will note that at a high-level this lifecycle model will have to be reflected in the RM syntax. Either patterns or actions will need to specify the lifecycle phase in which they operate. For several reasons, associating a pattern with a lifecycle phase makes the most sense, not the least of which is that it seems a more natural way to code RMs. 3) The processing model should support the ability for applications (RMs) to introduce requests into the system to be processed as if generated by a user agent, but not require that the message pass through the full lifecycle. This supports the ability to implement such operations as prefetch at the application level. 4) The processing model must make clear which operations are the domain of the base caching proxy and which are the domain of the PSEE. Section 5.2.2 of the draft indirectly defines some of this, but a more definitive statement is required. For example, it is not clear to me if actions called from a RM can satisfy a request; e.g., via RMI, database query, conjuring, etc. I think that perhaps section 5.2.2.2 bullet 4 addresses this, but I'm not sure. 5) There is a general need to better define the processing model and the embodied data flow. For example, the draft isn't clear on the relationship between the message parsers and the rule processor. Script Model ------------ The Script Model is an extension of the Rule Model. In this case, a (possibly special purpose) scripting language replaces the simple rule language, and each application is an executable script rather than the simple awk-like rules in a RM. Other high-level concepts remain the same. I have not yet given this processing model sufficient thought, but here are some random observations. 1) The requirement for a full interpreter will impact performance. 2) The scripting language is likely to increase the difficulty of integrating multiple applications. 3) It is not immediately obvious how difficult it will be to map this on to a well-defined message flow lifecycle, which I believe is important as discussed above. 4) This may actually be isomorphic to the Rule Model with script code embedded in proxylets. Streams Model ------------- The Streams Model is conceptually similar to the UNIX SVR4 STREAMS facility. To facilitate the description, I'll make the following definitions: transform module (TM) - an executable module that sits in the message data flow and performs transformations of messages. utility module (UM) - an executable module that provides utility functions callable from TMs and UMs. This processing model works as follows. Messages representing user agent requests only or user agent requests and content server replies flow through TMs. The TMs can modify the request data, generate reply data, or modify reply data, as appropriate. Each TM operates in exactly one phase of the message flow lifecycle. TMs can call functions in UMs. TMs can register interest in only seeing messages that meet certain criteria, in a manner similar to, but perhaps less fine-grained than, the pattern matching in the Rule Model. We'll define an application to be a collection of TMs and optionally UMs that implement a logical service. We'll define an extension library to be a collection of UMs that provide utility functions to applications. In the Streams Model, an application executes in a given security context, modifying messages and calling utility library functions. The security issues here are completely analogous to those discussed for the Rule Model with shared proxylets. Here are a few random observations on this processing model. 1) All interesting system behavior can be defined in terms of TMs and UMs. There is no meaningful separation of base caching proxy and PSEE, in contrast to the the Rule and Script Models. 2) The use of a fine-grained message lifecycle is very natural in this model. It may be less so in the Rule and Script Models. 3) Introducing requests into the system to implement prefetching applications, etc., as discussed earlier, can be done in a very natural fashion with this model. It may be less so in the Rule and Script Models. From owner-ietf-openproxy Mon Nov 6 19:21:12 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA07532 for ietf-openproxy-bks; Mon, 6 Nov 2000 19:21:12 -0800 (PST) Received: from raptor.ebuilt.net ([209.216.46.38]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA07528 for ; Mon, 6 Nov 2000 19:21:11 -0800 (PST) Received: FROM raptor.ebuilt.net BY raptor.ebuilt.net ; Mon Nov 06 19:27:16 2000 -0800 Received: by raptor with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 19:27:14 -0800 Message-ID: From: "Fielding, Roy" To: "'Ian Cooper'" , wrec@cs.utk.edu Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Ned Freed , cdn@ops.ietf.org, ietf-openproxy@imc.org Subject: RE: Candidate re-charter/new WG Date: Mon, 6 Nov 2000 19:27:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Below is a candidate (re)charter to take WREC forward as the "Web > Infrastructure" group (thanks to those who have given input of their > varying types). As you'll see, the idea is to take on two > work items that > we believe are essential for web infrastructure going forward. > > There is some cross over with the invalidation protocol with the CDNP > folks. ... > > Likewise, there is some degree of cross over with the intermediary > discovery protocol. ... If that is what you will be working on, please use a name that is specific to the work. Web infrastructure includes IP+TCP+HTTP+URI+DNS and a bunch of other things that are out of scope. I suggest you call it the "Web Intermediary" working group, since you are going to be talking about interoperability at the application level. And you can still call it WEBI. ....Roy From owner-ietf-openproxy Mon Nov 6 21:13:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA09211 for ietf-openproxy-bks; Mon, 6 Nov 2000 21:13:14 -0800 (PST) Received: from akamai.com (akafire-exodus.akamai.com [64.14.77.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09207 for ; Mon, 6 Nov 2000 21:13:13 -0800 (PST) Received: from akamai.com (vwall3.kendall.akamai.com [172.24.40.127]) by akamai.com (8.10.1/8.10.1) with ESMTP id eA75Jk618214 for ; Tue, 7 Nov 2000 00:19:46 -0500 (EST) Received: from ssh-gw.sanmateo.akamai.com ([172.23.1.53]) by akamai.com (8.10.1/8.10.1) with ESMTP id eA75JQY18076; Tue, 7 Nov 2000 00:19:26 -0500 (EST) Received: (from mnot@localhost) by ssh-gw.sanmateo.akamai.com (8.9.3/8.9.3) id WAA01433; Mon, 6 Nov 2000 22:17:26 -0800 Date: Mon, 6 Nov 2000 22:17:26 -0800 From: Mark Nottingham To: "Fielding, Roy" Cc: "'Ian Cooper'" , wrec@cs.utk.edu, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Ned Freed , cdn@ops.ietf.org, ietf-openproxy@imc.org Subject: Re: Candidate re-charter/new WG Message-ID: <20001106221721.A1420@akamai.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fielding@eBuilt.com on Mon, Nov 06, 2000 at 07:27:01PM -0800 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Interesting point. We were thinking application-level web infrastructure, which is confined to HTTP/URI; this is in the applications area, after all. That having been said, I don't have a particular objection to the meaning you propose, as I think it still encompasses what we intended. Ian? On Mon, Nov 06, 2000 at 07:27:01PM -0800, Fielding, Roy wrote: > > Below is a candidate (re)charter to take WREC forward as the "Web > > Infrastructure" group (thanks to those who have given input of their > > varying types). As you'll see, the idea is to take on two > > work items that > > we believe are essential for web infrastructure going forward. > > > > There is some cross over with the invalidation protocol with the CDNP > > folks. ... > > > > Likewise, there is some degree of cross over with the intermediary > > discovery protocol. ... > > If that is what you will be working on, please use a name that is > specific to the work. Web infrastructure includes IP+TCP+HTTP+URI+DNS > and a bunch of other things that are out of scope. I suggest you > call it the "Web Intermediary" working group, since you are going to > be talking about interoperability at the application level. And you > can still call it WEBI. > > ....Roy -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-ietf-openproxy Tue Nov 7 03:02:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA14443 for ietf-openproxy-bks; Tue, 7 Nov 2000 03:02:36 -0800 (PST) Received: from hplb.hpl.hp.com (hplb-temp.hpl.hp.com [192.6.10.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14433 for ; Tue, 7 Nov 2000 03:02:28 -0800 (PST) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id LAA08567; Tue, 7 Nov 2000 11:08:54 GMT Received: from hplb.hpl.hp.com (reynolds-d-2.hpl.hp.com [15.144.90.130]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id LAA26374; Tue, 7 Nov 2000 11:08:52 GMT Message-ID: <3A07E2CC.611D4F03@hplb.hpl.hp.com> Date: Tue, 07 Nov 2000 11:09:00 +0000 From: Dave Reynolds Organization: Hewlett-Packard Laboratories X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: moyer@fringent.com CC: ietf-openproxy@imc.org Subject: Re: EPSFW processing models References: <3A071944.184C1E12@fringent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Excellent discussion document. The stream and rule models can potentially be merged. One can use declarative rules to configure an assembly of streamed proxylets. There are two sorts of configuration possible - ordering and conditional execution. The ordering rules are used at configuration time to create an ordered pipeline of streamed proxylet Transform Modules (TM). They express dependencies between different proxylets, leading to a partial ordering that the host proxy can then resolve into a final ordering. This ordering is dependent upon the required proxy functions but largely independent of specific request/response messages. This ordering can also be achieved by attaching modules to specific processing phases as you suggest. However, a rule-based approach is more general and more openly extendible that a phased processing model. In the case of the modular proxy I am currently working on I want the set of proxylets to be (partially) under the control of individual users so the added flexibility of ordering constraints, even simple "must run before" type rules, are useful. Having created a TM pipeline then the actual proxylet actions are still going to depend on the details of each individual request/response. This could simply be buried in the Proxylet code (or script) by it choosing to do a no-op transform if it decides it is not needed. However, using declarative trigger rules to pre-screen the proxy to decide whether it should run on this request/response is useful. It allows the host proxy (and a user or administrator inspecting the proxy configuration) to reason about what actions are performed in what circumstances. This may allow optimizations or consistency checks which are not possible if the behaviour is only buried in the TM code. Regards, Dave Reynolds ------------------------------------------------------------------ Hewlett-Packard Laboratories | Phone: +44-117-3128165 Filton Road, Stoke Gifford | FAX: +44-117-3128925 Bristol BS34 8QZ, UK | dave_reynolds@hpl.hp.com From owner-ietf-openproxy Tue Nov 7 06:17:34 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id GAA29278 for ietf-openproxy-bks; Tue, 7 Nov 2000 06:17:34 -0800 (PST) Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29273 for ; Tue, 7 Nov 2000 06:17:33 -0800 (PST) Received: from fringent.com (fringent.dsl.telerama.com [205.201.10.94]) by tonnant.cnchost.com id JAA11255; Tue, 7 Nov 2000 09:20:55 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A080FC6.D3005DDC@fringent.com> Date: Tue, 07 Nov 2000 09:20:54 -0500 From: Steve Moyer Reply-To: moyer@fringent.com X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Dave Reynolds CC: ietf-openproxy@imc.org Subject: Re: EPSFW processing models References: <3A071944.184C1E12@fringent.com> <3A07E2CC.611D4F03@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The stream and rule models can potentially be merged. I suspect the Rule Model and Streams Model are isomorphic, though I haven't actually tried to develop a proof. > This ordering can also be achieved by attaching modules to specific processing phases > as you suggest. However, a rule-based approach is more general and more openly > extendible that a phased processing model. The phase-based approach may make it easier for applications developed independently to be integrated automatically. For example, the ordering of actions from different applications within a given phase may be irrelevant due to the nature of the processing defined for that phase. I have concerns that if the model is too flexible then automatic integration will not be possible at all. Of course, application integration is a non-computable problem in the general case, but an appropriate model may make it possible to do for many/most common cases. > However, using declarative trigger rules to > pre-screen the proxy to decide whether it should run on this request/response is > useful. Agreed. I defined the Streams Model to do this, but presumed it would be less fine-grained in the screening than in the Rule Model. As I said, I suspect the Rule Model and Streams Model are isomorphic, and the use of one or the other processing model will mean more to the underlying proxy architecture and the exposed programming model than to the actual functionality of the system. Regards, Steve Moyer From owner-ietf-openproxy Thu Nov 9 13:25:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA01970 for ietf-openproxy-bks; Thu, 9 Nov 2000 13:25:57 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA01966 for ; Thu, 9 Nov 2000 13:25:56 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Nov 2000 14:31:55 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 09 Nov 2000 14:31:50 -0700 From: "Hilarie Orman" To: , , , Cc: Subject: Re: regarding new working groups Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA01967 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think this is more of an issue for Extensible Proxies than the others. I'm in complete agreement on the fault isolation issue. For other things, while roles and responsibilities are ultimately important, binding agreements on paper are perfectly acceptable (i.e., they do not have to have an on-the-wire format). That being said, I'd like to see the IETF standardize on protocol representations of references to SLA's, contracts, etc., so that accounting systems could refer to the billing basis, the authorization agreeement, etc. It's not a perfect solution, but it's a start. Hilarie >>> Keith Moore 11/09/00 02:04PM >>> one thing that I think is essential in any new content-distribution work is to explicitly define roles and responsibilities - when an intermediary is introduced between the content-provider and the content-user, to which party is the intermediary responsible? (the same device might be used in either case, but intermediaries should be clear about whose instructions they are following) under no circumstances should content be altered, nor should stale content be delivered, except with explicit consent from at least one of the end parties. for example, we don't want to standardize a way to allow an ISP to alter or cache content except as intended by one of the end parties. finally, there need to be provisions for fault isolation and diagnosis, which probably requires (among other things) the ability to bypass intermediaries. Keith From owner-ietf-openproxy Thu Nov 9 13:30:36 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02070 for ietf-openproxy-bks; Thu, 9 Nov 2000 13:30:36 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02066 for ; Thu, 9 Nov 2000 13:30:35 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA04944; Thu, 9 Nov 2000 16:37:18 -0500 (EST) Message-Id: <200011092137.QAA04944@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hilarie Orman" cc: moore@cs.utk.edu, wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Thu, 09 Nov 2000 14:31:50 MST." Date: Thu, 09 Nov 2000 16:37:18 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I think this is more of an issue for Extensible Proxies than the > others. > > I'm in complete agreement on the fault isolation issue. For other > things, while roles and responsibilities are ultimately important, binding > agreements on paper are perfectly acceptable (i.e., they do not > have to have an on-the-wire format). I agree with this sentiment. I'm not trying to insist that the details of such agreements be made a part of the protocol (though it would be nice if we could do it, I suspect it would take a long time before we could find a good way to encode the needs of real users into a protocol) Keith From owner-ietf-openproxy Thu Nov 9 13:45:03 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA02304 for ietf-openproxy-bks; Thu, 9 Nov 2000 13:45:03 -0800 (PST) Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02300 for ; Thu, 9 Nov 2000 13:45:02 -0800 (PST) Received: from havoc.entera.com ([206.165.109.130]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with SMTP id com for ; Thu, 9 Nov 2000 13:54:42 -0800 Received: FROM exchange.entera.com BY havoc.entera.com ; Thu Nov 09 13:54:40 2000 -0800 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 13:49:50 -0800 Message-ID: <733880CDF866D3118C69005004D1701E0121EAD9@exchange.entera.com> From: Gary Tomlinson To: Keith Moore , Hilarie Orman Cc: wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: RE: regarding new working groups Date: Thu, 9 Nov 2000 13:49:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>At 11/9/00 1:32PM Hilarie Orman wrote: >> I think this is more of an issue for Extensible Proxies than the >> others. >> >> I'm in complete agreement on the fault isolation issue. For other >> things, while roles and responsibilities are ultimately important, binding >> agreements on paper are perfectly acceptable (i.e., they do not >> have to have an on-the-wire format). >At November 9, 2000 1:37PM Keith Moore wrote: >I agree with this sentiment. I'm not trying to insist that the details >of such agreements be made a part of the protocol (though it would be >nice if we could do it, I suspect it would take a long time before we >could find a good way to encode the needs of real users into a protocol) I think there still exists a need for the content distribution & delivery providers to divulge their vested interests as well (paper is fine). Traditionally, the CDNs we know today represent the content provider's interests, while ISP's are likely to represent the consumer's interests. Gary From owner-ietf-openproxy Thu Nov 9 14:31:47 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA03562 for ietf-openproxy-bks; Thu, 9 Nov 2000 14:31:47 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03558 for ; Thu, 9 Nov 2000 14:31:46 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 34AEF4CE15; Thu, 9 Nov 2000 17:38:48 -0500 (EST) Received: from douglux.research.att.com (root@douglux.research.att.com [135.207.26.106]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA22457; Thu, 9 Nov 2000 17:38:47 -0500 (EST) Received: from douglux.research.att.com (IDENT:douglis@localhost.localdomain [127.0.0.1]) by douglux.research.att.com (8.9.3/8.9.3) with ESMTP id RAA23582; Thu, 9 Nov 2000 17:38:47 -0500 Message-Id: <200011092238.RAA23582@douglux.research.att.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Fred Douglis To: wrec@cs.utk.edu, cdn@ops.ietf.org, ietf-openproxy@imc.org Subject: BOF scheduling X-URI: http://www.research.att.com/~douglis/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Nov 2000 17:38:47 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I noticed the latest IETF agenda scheduled CDNP for Tuesday afternoon. Since so many of us are likely to be interested in CDNP, WEBI, and the openproxy work (I forget their acronym), I wondered if anyone has any insight into how closely these three will be scheduled? I have visions of having to go to SD for a whole week to attend, primarily, these 3 meetings. I know there are a zillion constraints and everyone has their pet groups, but it seems this intersection must be so common that I hope it will ultimately result in close proximity. The fact that one appeared in the schedule while the others didn't have me worried a bit. (See http://www.ietf.cnri.reston.va.us/meetings/agenda.html for details.) With fingers crossed, Fred From owner-ietf-openproxy Thu Nov 9 14:42:43 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA03792 for ietf-openproxy-bks; Thu, 9 Nov 2000 14:42:43 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA03788 for ; Thu, 9 Nov 2000 14:42:42 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Nov 2000 15:49:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 09 Nov 2000 15:49:06 -0700 From: "Hilarie Orman" To: , , , Subject: Re: BOF scheduling Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA03789 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Has me worried too, but CDNP has different Area Directors than the others, and those AD's are taking a less aggressive approach to putting approved things into actual agenda spots. Hilarie >>> Fred Douglis 11/09/00 03:38PM >>> I noticed the latest IETF agenda scheduled CDNP for Tuesday afternoon. Since so many of us are likely to be interested in CDNP, WEBI, and the openproxy work (I forget their acronym), I wondered if anyone has any insight into how closely these three will be scheduled? I have visions of having to go to SD for a whole week to attend, primarily, these 3 meetings. I know there are a zillion constraints and everyone has their pet groups, but it seems this intersection must be so common that I hope it will ultimately result in close proximity. The fact that one appeared in the schedule while the others didn't have me worried a bit. (See http://www.ietf.cnri.reston.va.us/meetings/agenda.html for details.) With fingers crossed, Fred From owner-ietf-openproxy Thu Nov 9 14:47:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA03955 for ietf-openproxy-bks; Thu, 9 Nov 2000 14:47:52 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03950 for ; Thu, 9 Nov 2000 14:47:47 -0800 (PST) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id WAA10088; Thu, 9 Nov 2000 22:51:56 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 09 Nov 2000 22:50:39 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 14:50:37 -0800 Message-ID: From: "Condry, Michael W" To: "'Fred Douglis'" , wrec@cs.utk.edu, cdn@ops.ietf.org, ietf-openproxy@imc.org Cc: "'paf@cisco.com'" Subject: RE: BOF scheduling Date: Thu, 9 Nov 2000 14:50:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I do not have the time for OPES yet. I suspect that Patrik will be careful in no conflicts with these groups. -----Original Message----- From: Fred Douglis [mailto:douglis@research.att.com] Sent: Thursday, November 09, 2000 2:39 PM To: wrec@cs.utk.edu; cdn@ops.ietf.org; ietf-openproxy@imc.org Subject: BOF scheduling I noticed the latest IETF agenda scheduled CDNP for Tuesday afternoon. Since so many of us are likely to be interested in CDNP, WEBI, and the openproxy work (I forget their acronym), I wondered if anyone has any insight into how closely these three will be scheduled? I have visions of having to go to SD for a whole week to attend, primarily, these 3 meetings. I know there are a zillion constraints and everyone has their pet groups, but it seems this intersection must be so common that I hope it will ultimately result in close proximity. The fact that one appeared in the schedule while the others didn't have me worried a bit. (See http://www.ietf.cnri.reston.va.us/meetings/agenda.html for details.) With fingers crossed, Fred From owner-ietf-openproxy Thu Nov 9 14:54:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04413 for ietf-openproxy-bks; Thu, 9 Nov 2000 14:54:35 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04409 for ; Thu, 9 Nov 2000 14:54:34 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id BC5F0D7; Fri, 10 Nov 2000 00:01:05 +0100 (MET) Received: from [171.70.85.33] (dhcp-2sjc13-85-33.cisco.com [171.70.85.33]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA11683; Fri, 10 Nov 2000 00:01:00 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 9 Nov 2000 15:00:25 -0800 To: "Hilarie Orman" , , , , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: BOF scheduling Cc: Ned Freed Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 15.49 -0700 00-11-09, Hilarie Orman wrote: >Has me worried too, but CDNP has different Area Directors than the >others, and those AD's are taking a less aggressive approach to >putting approved things into actual agenda spots. Different Area Directors? BOF's end up on the agenda as soon as: 1 People have sent requests to agenda@ietf.org and responsible AD 2 AD has said ok to the BOF 3 Agenda people have managed to sync (1) and (2) above The IETF conference is one week long. From monday morning to friday lunch. The idea with having all wg's the same week is that people working normally with one topic _SHOULD_ participate in other meetings aswell. For example, people interested in what happens in the area of these mailing lists probably should look very closely what happens in the space of the IDN working group, aswell as CNRP and other URI/HTTP related wg's. Saying "I only want to be there for my meeting and then go home, so please let me know exactly when the meeting will be" is not an argument which works. Patrik Faltstrom Co-Area Director, Applications Area From owner-ietf-openproxy Thu Nov 9 14:54:27 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04399 for ietf-openproxy-bks; Thu, 9 Nov 2000 14:54:27 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04393 for ; Thu, 9 Nov 2000 14:54:26 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 86B0995; Fri, 10 Nov 2000 00:00:57 +0100 (MET) Received: from [171.70.85.33] (dhcp-2sjc13-85-33.cisco.com [171.70.85.33]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA11678; Fri, 10 Nov 2000 00:00:55 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <200011092238.RAA23582@douglux.research.att.com> References: <200011092238.RAA23582@douglux.research.att.com> Date: Thu, 9 Nov 2000 14:54:54 -0800 To: Fred Douglis , wrec@cs.utk.edu, cdn@ops.ietf.org, ietf-openproxy@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: BOF scheduling Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 17.38 -0500 00-11-09, Fred Douglis wrote: >I noticed the latest IETF agenda scheduled CDNP for Tuesday afternoon. Since >so many of us are likely to be interested in CDNP, WEBI, and the openproxy >work (I forget their acronym), I wondered if anyone has any insight into how >closely these three will be scheduled? Very close -- if possible. paf From owner-ietf-openproxy Thu Nov 9 15:05:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA04678 for ietf-openproxy-bks; Thu, 9 Nov 2000 15:05:16 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04674 for ; Thu, 9 Nov 2000 15:05:15 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 55116119; Fri, 10 Nov 2000 00:11:46 +0100 (MET) Received: from [171.70.85.33] (dhcp-2sjc13-85-33.cisco.com [171.70.85.33]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA12597; Fri, 10 Nov 2000 00:11:41 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 9 Nov 2000 15:11:33 -0800 To: "Hilarie Orman" , , , , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: BOF scheduling Cc: Ned Freed Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA04675 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 15.00 -0800 00-11-09, Patrik Fältström wrote: >The IETF conference is one week long. From monday morning to friday >lunch. The idea with having all wg's the same week is that people >working normally with one topic _SHOULD_ participate in other >meetings aswell. And, if it is the case that you have an hour or a day or so when there is no interesting meeting, I am sure (based on the discussion on these mailing lists) that you together can find some corner in the hotel and discuss more things face 2 face which you don't have time to talk about during the meeting itself. paf From owner-ietf-openproxy Thu Nov 9 16:10:05 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA06680 for ietf-openproxy-bks; Thu, 9 Nov 2000 16:10:05 -0800 (PST) Received: from akamai.com (fw-west.west.akamai.com [63.102.156.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06676 for ; Thu, 9 Nov 2000 16:10:04 -0800 (PST) Received: from akamai.com (vwall1.sanmateo.akamai.com [172.23.1.71]) by akamai.com (8.10.1/8.10.1) with ESMTP id eAA0E1i12775 for ; Thu, 9 Nov 2000 16:14:01 -0800 (PST) Received: from marjorie.sanmateo.akamai.com (IDENT:root@marjorie.sanmateo.akamai.com [172.23.1.15]) by akamai.com (8.10.1/8.10.1) with ESMTP id eAA0AF512711; Thu, 9 Nov 2000 16:10:15 -0800 (PST) Received: (from mnot@localhost) by marjorie.sanmateo.akamai.com (8.9.3/8.9.3) id QAA16293; Thu, 9 Nov 2000 16:16:49 -0800 Date: Thu, 9 Nov 2000 16:16:49 -0800 From: Mark Nottingham To: Gary Tomlinson Cc: Keith Moore , Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups Message-ID: <20001109161648.A16140@akamai.com> References: <733880CDF866D3118C69005004D1701E0121EAD9@exchange.entera.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <733880CDF866D3118C69005004D1701E0121EAD9@exchange.entera.com>; from garyt@entera.com on Thu, Nov 09, 2000 at 01:49:50PM -0800 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with the sentiment, but not that ISPs represent consumers' interests; generally, I find that they represent their own, with consumers' as a distant second. Especially regarding caching. I'm glad that people are talking about these issues; HTTP is AFAIK unique as a transport protocol, in that it allows relaxation of semantic transparency without explicit permission of the client or server. This will cause problems if we just jump in (although some already are!) Also, may be good to try and involve the W3C, as relaxing semantic transparency potentially affects many things there (P3P, semantic web, etc) On Thu, Nov 09, 2000 at 01:49:50PM -0800, Gary Tomlinson wrote: > > >>At 11/9/00 1:32PM Hilarie Orman wrote: > >> I think this is more of an issue for Extensible Proxies than the > >> others. > >> > >> I'm in complete agreement on the fault isolation issue. For other > >> things, while roles and responsibilities are ultimately important, > binding > >> agreements on paper are perfectly acceptable (i.e., they do not > >> have to have an on-the-wire format). > > >At November 9, 2000 1:37PM Keith Moore wrote: > >I agree with this sentiment. I'm not trying to insist that the details > >of such agreements be made a part of the protocol (though it would be > >nice if we could do it, I suspect it would take a long time before we > >could find a good way to encode the needs of real users into a protocol) > > I think there still exists a need for the content distribution & delivery > providers to divulge their vested interests as well (paper is fine). > Traditionally, the CDNs we know today represent the content provider's > interests, while ISP's are likely to represent the consumer's interests. > > Gary -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-ietf-openproxy Thu Nov 9 16:26:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA07171 for ietf-openproxy-bks; Thu, 9 Nov 2000 16:26:35 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA07167 for ; Thu, 9 Nov 2000 16:26:33 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Nov 2000 17:32:58 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 09 Nov 2000 17:32:56 -0700 From: "Hilarie Orman" To: , Cc: , , Subject: Re: regarding new working groups Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA07168 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Agreed. It's nice when service providers find that their own economic interests don't conflict with their customers', but that's nothing to bank on. For this forum, what we can do is to have requirements for API's that allow user/publisher configuration of policy options (and to define the embodiment of those options). Hilarie >>> Mark Nottingham 11/09/00 05:16PM >>> I agree with the sentiment, but not that ISPs represent consumers' interests; generally, I find that they represent their own, with consumers' as a distant second. Especially regarding caching. From owner-ietf-openproxy Thu Nov 9 17:37:56 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA08740 for ietf-openproxy-bks; Thu, 9 Nov 2000 17:37:56 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08736 for ; Thu, 9 Nov 2000 17:37:55 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA05957; Thu, 9 Nov 2000 20:44:18 -0500 (EST) Message-Id: <200011100144.UAA05957@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Nottingham cc: Gary Tomlinson , Keith Moore , Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Thu, 09 Nov 2000 16:16:49 PST." <20001109161648.A16140@akamai.com> Date: Thu, 09 Nov 2000 20:44:18 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I agree with the sentiment, but not that ISPs represent consumers' > interests; generally, I find that they represent their own, with consumers' > as a distant second. Especially regarding caching. I see the same thing, and I find it extremely disquieting. This is why I say that intermediaries must act on explicit instructions (whether or not part of the on-the-wire protocol) from at least one of the end parties > I'm glad that people are talking about these issues; HTTP is AFAIK unique as > a transport protocol, in that it allows relaxation of semantic transparency > without explicit permission of the client or server. I don't immediately see how HTTP permits this by itself; it's the idea that the network can interpose intermediaries in the HTTP conversation (whether via interception proxies or via auto-discovery mechanisms that find intermediaries without authorization of either the content provider or the content user) that seems to cause the problems. at any rate, it needs to be stopped. Keith From owner-ietf-openproxy Thu Nov 9 17:58:48 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA09474 for ietf-openproxy-bks; Thu, 9 Nov 2000 17:58:48 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09470 for ; Thu, 9 Nov 2000 17:58:47 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA06202; Thu, 9 Nov 2000 21:05:39 -0500 (EST) Message-Id: <200011100205.VAA06202@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Gary Tomlinson cc: Keith Moore , Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Thu, 09 Nov 2000 13:49:50 PST." <733880CDF866D3118C69005004D1701E0121EAD9@exchange.entera.com> Date: Thu, 09 Nov 2000 21:05:39 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I think there still exists a need for the content distribution & delivery > providers to divulge their vested interests as well (paper is fine). > Traditionally, the CDNs we know today represent the content provider's > interests, while ISP's are likely to represent the consumer's interests. I beg to differ; the ISPs generally represent their own interests when they interfere with the communications between a content provider and the content user. (e.g. by imposing non-voluntary caches, adding advertising, changing data formats) IETF should not sanction such practices. Keith From owner-ietf-openproxy Thu Nov 9 21:06:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA12536 for ietf-openproxy-bks; Thu, 9 Nov 2000 21:06:07 -0800 (PST) Received: from havoc.entera.com (havoc.entera.com [206.165.109.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA12532 for ; Thu, 9 Nov 2000 21:06:05 -0800 (PST) Received: from havoc.entera.com ([206.165.109.130]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with SMTP id com for ; Thu, 9 Nov 2000 21:15:46 -0800 Received: FROM exchange.entera.com BY havoc.entera.com ; Thu Nov 09 21:15:40 2000 -0800 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 21:10:49 -0800 Message-ID: <733880CDF866D3118C69005004D1701E0121EAEA@exchange.entera.com> From: Gary Tomlinson To: moore@cs.utk.edu, Gary Tomlinson Cc: Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: RE: regarding new working groups Date: Thu, 9 Nov 2000 21:10:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> I think there still exists a need for the content distribution & delivery >> providers to divulge their vested interests as well (paper is fine). >> Traditionally, the CDNs we know today represent the content provider's >> interests, while ISP's are likely to represent the consumer's interests. > >I beg to differ; the ISPs generally represent their own interests >when they interfere with the communications between a content >provider and the content user. (e.g. by imposing non-voluntary >caches, adding advertising, changing data formats) > >IETF should not sanction such practices. > Fair enough assessment on current ISP practices. Nonetheless, CDNs as we know them do represent provider interests, and somebody may emerge to represent consumer interests (I know of some infomediary startups that would like to). My main point is, there are multiple entities representing various interests involved with intermediary infrastructure. Gary From owner-ietf-openproxy Fri Nov 10 01:54:40 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA13445 for ietf-openproxy-bks; Fri, 10 Nov 2000 01:54:40 -0800 (PST) Received: from frampton.cisco.com (frampton.cisco.com [161.44.253.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13436 for ; Fri, 10 Nov 2000 01:54:38 -0800 (PST) Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id FAA18801; Fri, 10 Nov 2000 05:00:39 -0500 (EST) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id ABI01103; Fri, 10 Nov 2000 05:00:34 -0500 (EST) From: "Mark Day" To: , "Mark Nottingham" Cc: "Gary Tomlinson" , "Hilarie Orman" , , , Subject: RE: regarding new working groups Date: Fri, 10 Nov 2000 05:00:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200011100144.UAA05957@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I'm glad that people are talking about these issues; HTTP is > AFAIK unique as > > a transport protocol, in that it allows relaxation of semantic > transparency > > without explicit permission of the client or server. > > I don't immediately see how HTTP permits this by itself; it's the idea > that the network can interpose intermediaries in the HTTP conversation > (whether via interception proxies or via auto-discovery mechanisms > that find intermediaries without authorization of either the > content provider or the content user) that seems to cause the problems. > > at any rate, it needs to be stopped. I confess that I am now confused as to whether we are talking about (a) an issue to keep in mind as we define the tasks of the BOFs/WGs, or (b) a problem and associated technical solution to be discussed in one or more of those groups, or (c) a problem and associated political/legal solution If it's (a), we can all agree that this is a good issue to keep in mind, and then keep it in mind. If it's (b), I need a little more explanation of what the proposed technical approach is because I don't understand it yet. It it's (c), then I need a little more explanation of the relationship between what the IETF can do and the political/legal changes required, because I don't understand that yet. Thanks, --Mark From owner-ietf-openproxy Fri Nov 10 05:58:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA29858 for ietf-openproxy-bks; Fri, 10 Nov 2000 05:58:05 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29854 for ; Fri, 10 Nov 2000 05:58:04 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA01877; Fri, 10 Nov 2000 09:04:59 -0500 (EST) Message-Id: <200011101404.JAA01877@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Mark Day" cc: moore@cs.utk.edu, "Mark Nottingham" , "Gary Tomlinson" , "Hilarie Orman" , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Fri, 10 Nov 2000 05:00:44 EST." Date: Fri, 10 Nov 2000 09:04:58 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I confess that I am now confused as to whether we are talking about > (a) an issue to keep in mind as we define the tasks of the BOFs/WGs, or > (b) a problem and associated technical solution to be discussed in one or > more of those groups, or > (c) a problem and associated political/legal solution it could be any of these. but for the purpose of the current discussion, I mentioned it because I thought it might be useful input to the drafting of WG charters. sorry for not being clearer about that. Keith From owner-ietf-openproxy Fri Nov 10 10:17:28 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA25333 for ietf-openproxy-bks; Fri, 10 Nov 2000 10:17:28 -0800 (PST) Received: from frampton.cisco.com (frampton.cisco.com [161.44.253.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25325 for ; Fri, 10 Nov 2000 10:17:26 -0800 (PST) Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA20837; Fri, 10 Nov 2000 13:24:01 -0500 (EST) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id ABL00419; Fri, 10 Nov 2000 13:24:00 -0500 (EST) From: "Mark Day" To: Cc: , Subject: Proposed charter for CDNP working group Date: Fri, 10 Nov 2000 13:24:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a heavily revised version of what I sent to the IESG as a placeholder almost 2 months ago. Comments and suggested edits are welcome. I have suggested an unorthodox and rather aggressive schedule, involving parallel development of requirements and protocols. This is partly because of my experience that many important requirements issues don't get raised until people are thinking the protocols through. I think a parallel approach is challenging but doable, but others may well disagree. The current proposed agenda for the CDNP BOF includes an allocation of roughly half our time for discussing the charter. --Mark Content Distribution Network Peering (cdnp) Chair: Mark Day Applications Area Directors: Ned Freed Patrik Faltstrom Applications Area Advisor: Patrik Faltstrom Mailing lists: General discussion: cdn@ops.ietf.org To subscribe: cdn-request@ops.ietf.org Archive: ftp://ops.ietf.org/pub/lists/cdn.* Description of Working Group: The goal of this working group is to define protocols to allow the interoperation of separately-administered content distribution networks (CDNs). A CDN is an architecture of Web-based network elements, arranged for efficient delivery of digital content. The first important use of CDNs was for the distribution of heavily-requested graphic files (such as GIF files on the home pages of popular servers). However, both in principle and increasingly in practice, a CDN can support the delivery of any digital content -- including various forms of streaming media. A number of CDN services have been built and offered commercially. In addition, a number of hardware and software vendors have developed products that enable the construction of a CDN with "off-the-shelf" parts. The proliferation of CDNs and CDN capabilities gives rise to interest in interconnecting CDNs and finding ways for distinct CDNs to cooperate for better overall service A CDN has some combination of a mapping system, a content-delivery system, a distribution system, and an accounting system. In some cases, the "system" may be implemented by very simple components or techniques. The content-delivery system consists of a set of "surrogate" servers that deliver copies of content to sets of users. The mapping system consists of mechanisms that move a client request toward a rendezvous with a surrogate. The distribution system consists of mechanisms that move content from the origin server to the surrogates. An effective CDN arranges the request/content rendezvous to take place at a surrogate that is "well suited" to a given client. Finally, the accounting system records and aggregates information necessary for allocating costs to customers of the CDN. The working group will define requirements and protocol specifications for three kinds of peering: 1. Mapping peering (the interoperation of mapping systems) 2. Distribution peering (the interoperation of distribution systems) and 3. Accounting peering (the interoperation of accounting systems) As preparation for that task, various internet-drafts have been submitted, describing: -- a proposed vocabulary for the problem domain -- a description of some CDN interoperation scenarios -- a proposed set of requirements for accounting -- a proposed architecture for CDN interoperation -- a summary description of known mechanisms for mapping in use today Goals and Milestones December 2000: BOF meets, discusses existing drafts. Editors chosen for requirement documents, protocol documents. February 1, 2001: First drafts of requirements, protocols due on mailing list. March 1, 2001: Last call for vocabulary, scenarios, architecture documents (incorporating changes from requirements process) April 2001: WG meets at IETF meeting to discuss requirements issues, protocol experience June 1, 2001: New requirements, protocol docs incorporating discussions from meeting July 1, 2001: Last call for requirements. August 2001: WG meets at IETF to discuss protocol issues. October 1, 2001: Last call for protocols. December 2001: WG meets at IETF to close. Internet Drafts: http://www.ietf.org/internet-drafts/draft-day-cdnp-model-02.txt http://www.ietf.org/internet-drafts/draft-day-cdnp-scenarios-02.txt http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-aaa-reqs-00.txt http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-01.txt [Plus "known-mechanisms" draft coming soon] From owner-ietf-openproxy Fri Nov 10 11:04:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27709 for ietf-openproxy-bks; Fri, 10 Nov 2000 11:04:07 -0800 (PST) Received: from sundns.transnexus.com ([216.162.34.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27705 for ; Fri, 10 Nov 2000 11:04:06 -0800 (PST) Received: from stephen.transnexus.com ([192.168.1.198]) by sundns.transnexus.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29214; Fri, 10 Nov 2000 19:09:43 GMT Message-Id: <5.0.0.25.2.20001110140433.00a84be0@mail.transnexus.com> X-Sender: sthomas@mail.transnexus.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 10 Nov 2000 14:09:27 -0500 To: From: Stephen Thomas Subject: Re: Proposed charter for CDNP working group Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:24 PM 2000-11-10 -0500, Mark Day wrote: >This is a heavily revised version of what I sent to the IESG as a >placeholder almost 2 months ago. Comments and suggested edits are welcome. Just a minor tweak below >[...] Finally, the accounting system records and >aggregates information necessary for allocating costs to customers of the >CDN. I'd suggest that accounting metrics ought to be useful for a lot of reasons other than allocating costs. Depending on what ends up being accounted, content providers, for example, may want to use these metrics to gauge audience size, end user demographics, page "stickiness," etc.. Stephen ____________________________________________________________________ Stephen Thomas +1 404 872 4887 TransNexus, Chief Technical Officer stephen.thomas@transnexus.com From owner-ietf-openproxy Mon Nov 13 07:30:35 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA01030 for ietf-openproxy-bks; Mon, 13 Nov 2000 07:30:35 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01022 for ; Mon, 13 Nov 2000 07:30:33 -0800 (PST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id PAA27845; Mon, 13 Nov 2000 15:38:30 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 13 Nov 2000 15:37:13 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 07:37:10 -0800 Message-ID: From: "Condry, Michael W" To: "'Keith Moore'" , Gary Tomlinson Cc: Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: RE: regarding new working groups Date: Mon, 13 Nov 2000 07:37:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Defining the IETF's role is a tough call. Some folks live with the Advertising to get service they could not otherwise have... -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Thursday, November 09, 2000 6:06 PM To: Gary Tomlinson Cc: Keith Moore; Hilarie Orman; wrec@cs.utk.edu; ietf-openproxy@imc.org; cdn@ops.ietf.org Subject: Re: regarding new working groups > I think there still exists a need for the content distribution & delivery > providers to divulge their vested interests as well (paper is fine). > Traditionally, the CDNs we know today represent the content provider's > interests, while ISP's are likely to represent the consumer's interests. I beg to differ; the ISPs generally represent their own interests when they interfere with the communications between a content provider and the content user. (e.g. by imposing non-voluntary caches, adding advertising, changing data formats) IETF should not sanction such practices. Keith From owner-ietf-openproxy Mon Nov 13 09:30:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA09916 for ietf-openproxy-bks; Mon, 13 Nov 2000 09:30:56 -0800 (PST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09912 for ; Mon, 13 Nov 2000 09:30:55 -0800 (PST) Received: from condrysony.intel.com (sonylaptop.jf.intel.com [134.134.159.198]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with ESMTP id JAA13383; Mon, 13 Nov 2000 09:38:04 -0800 (PST) Message-Id: <5.0.0.25.2.20001113093509.009f2540@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 13 Nov 2000 09:35:31 -0800 To: "Mark Day" , From: "Michael W. Condry" Subject: Re: Proposed charter for CDNP working group Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is this an Applications or Ops? At 01:24 PM 11/10/00 -0500, Mark Day wrote: >This is a heavily revised version of what I sent to the IESG as a >placeholder almost 2 months ago. Comments and suggested edits are welcome. > >I have suggested an unorthodox and rather aggressive schedule, involving >parallel development of requirements and protocols. This is partly because >of my experience that many important requirements issues don't get raised >until people are thinking the protocols through. I think a parallel >approach is challenging but doable, but others may well disagree. > >The current proposed agenda for the CDNP BOF includes an allocation of >roughly half our time for discussing the charter. > >--Mark > >Content Distribution Network Peering (cdnp) > >Chair: >Mark Day > >Applications Area Directors: >Ned Freed >Patrik Faltstrom > >Applications Area Advisor: >Patrik Faltstrom > >Mailing lists: >General discussion: cdn@ops.ietf.org >To subscribe: cdn-request@ops.ietf.org >Archive: ftp://ops.ietf.org/pub/lists/cdn.* > >Description of Working Group: > >The goal of this working group is to define protocols to allow the >interoperation of separately-administered content distribution networks >(CDNs). > >A CDN is an architecture of Web-based network elements, arranged for >efficient delivery of digital content. The first important use of CDNs was >for the distribution of heavily-requested graphic files (such as GIF files >on the home pages of popular servers). However, both in principle and >increasingly in practice, a CDN can support the delivery of any digital >content -- including various forms of streaming media. > >A number of CDN services have been built and offered commercially. In >addition, a number of hardware and software vendors have developed products >that enable the construction of a CDN with "off-the-shelf" parts. The >proliferation of CDNs and CDN capabilities gives rise to interest in >interconnecting CDNs >and finding ways for distinct CDNs to cooperate for better overall service > >A CDN has some combination of a mapping system, a content-delivery >system, a distribution system, and an accounting system. In some cases, the >"system" may be implemented by very simple components or techniques. The >content-delivery system consists of a set of "surrogate" >servers that deliver copies of content to sets of users. The mapping system >consists of mechanisms that move a client request toward a rendezvous with a >surrogate. The distribution system consists of mechanisms that move content >from the origin server to the surrogates. An effective CDN arranges the >request/content rendezvous to take place at a surrogate that is "well >suited" to a given client. Finally, the accounting system records and >aggregates information necessary for allocating costs to customers of the >CDN. > >The working group will define requirements and protocol specifications for >three kinds of peering: > >1. Mapping peering (the interoperation of mapping systems) >2. Distribution peering (the interoperation of distribution systems) and >3. Accounting peering (the interoperation of accounting systems) > >As preparation for that task, various internet-drafts have been submitted, >describing: > >-- a proposed vocabulary for the problem domain >-- a description of some CDN interoperation scenarios >-- a proposed set of requirements for accounting >-- a proposed architecture for CDN interoperation >-- a summary description of known mechanisms for mapping in use today > >Goals and Milestones > >December 2000: BOF meets, discusses existing drafts. Editors chosen for >requirement documents, protocol documents. >February 1, 2001: First drafts of requirements, protocols due on mailing >list. >March 1, 2001: Last call for vocabulary, scenarios, architecture documents >(incorporating changes from requirements process) >April 2001: WG meets at IETF meeting to discuss requirements issues, >protocol experience >June 1, 2001: New requirements, protocol docs incorporating discussions from >meeting >July 1, 2001: Last call for requirements. >August 2001: WG meets at IETF to discuss protocol issues. >October 1, 2001: Last call for protocols. >December 2001: WG meets at IETF to close. > >Internet Drafts: > >http://www.ietf.org/internet-drafts/draft-day-cdnp-model-02.txt >http://www.ietf.org/internet-drafts/draft-day-cdnp-scenarios-02.txt >http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-aaa-reqs-00.txt >http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-01.txt >[Plus "known-mechanisms" draft coming soon] From owner-ietf-openproxy Mon Nov 13 09:39:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA10403 for ietf-openproxy-bks; Mon, 13 Nov 2000 09:39:32 -0800 (PST) Received: from frampton.cisco.com (frampton.cisco.com [161.44.253.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10397 for ; Mon, 13 Nov 2000 09:39:30 -0800 (PST) Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA03023; Mon, 13 Nov 2000 12:46:20 -0500 (EST) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAA01088; Mon, 13 Nov 2000 12:46:20 -0500 (EST) From: "Mark Day" To: "Michael W. Condry" , Cc: , Subject: RE: Proposed charter for CDNP working group Date: Mon, 13 Nov 2000 12:46:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.0.25.2.20001113093509.009f2540@FMSMSX63.fm.intel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Is this [CDNP] an Applications or Ops? IESG appears to have decided that it's Applications. Sorry for not making that clear. --Mark From owner-ietf-openproxy Mon Nov 13 09:42:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA10586 for ietf-openproxy-bks; Mon, 13 Nov 2000 09:42:44 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10582 for ; Mon, 13 Nov 2000 09:42:44 -0800 (PST) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id RAA18665; Mon, 13 Nov 2000 17:51:10 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 13 Nov 2000 17:49:53 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 09:49:50 -0800 Message-ID: From: "Condry, Michael W" To: "'Mark Day'" , "Condry, Michael W" , cdn@ops.ietf.org Cc: wrec@cs.utk.edu, ietf-openproxy@imc.org Subject: RE: Proposed charter for CDNP working group Date: Mon, 13 Nov 2000 09:49:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I should have picked that up. -----Original Message----- From: Mark Day [mailto:markday@cisco.com] Sent: Monday, November 13, 2000 9:47 AM To: Michael W. Condry; cdn@ops.ietf.org Cc: wrec@cs.utk.edu; ietf-openproxy@imc.org Subject: RE: Proposed charter for CDNP working group > Is this [CDNP] an Applications or Ops? IESG appears to have decided that it's Applications. Sorry for not making that clear. --Mark From owner-ietf-openproxy Mon Nov 13 10:18:28 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12322 for ietf-openproxy-bks; Mon, 13 Nov 2000 10:18:28 -0800 (PST) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12318 for ; Mon, 13 Nov 2000 10:18:26 -0800 (PST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA26411; Mon, 13 Nov 2000 13:25:18 -0500 (EST) Message-Id: <200011131825.NAA26411@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Condry, Michael W" cc: "'Keith Moore'" , Gary Tomlinson , Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Mon, 13 Nov 2000 07:37:10 PST." Date: Mon, 13 Nov 2000 13:25:18 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Defining the IETF's role is a tough call. I don't think it's tough at all. IETF has no power to stop ISPs from doing abusive things. But IETF should not offer its support to practices that harm the integrity of communications. Keith From owner-ietf-openproxy Mon Nov 13 10:34:51 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13139 for ietf-openproxy-bks; Mon, 13 Nov 2000 10:34:51 -0800 (PST) Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13133 for ; Mon, 13 Nov 2000 10:34:49 -0800 (PST) Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 1752CE6; Mon, 13 Nov 2000 19:41:39 +0100 (MET) Received: from [10.10.0.106] (dhcp-2sjc13-85-86.cisco.com [171.70.85.86]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA03653; Mon, 13 Nov 2000 19:41:37 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Mon, 13 Nov 2000 10:39:32 -0800 To: "Mark Day" , "Michael W. Condry" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: Proposed charter for CDNP working group Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12.46 -0500 00-11-13, Mark Day wrote: > > Is this [CDNP] an Applications or Ops? > >IESG appears to have decided that it's Applications. Sorry for not making >that clear. The decision is not made until the wg is formally created. Apps has taken the token of hosting the BOF. Ops people will be present. I.e. this might be one of the issues which will be discussed in San Diego. We'll see. paf From owner-ietf-openproxy Tue Nov 14 02:31:44 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA05689 for ietf-openproxy-bks; Tue, 14 Nov 2000 02:31:44 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA05681 for ; Tue, 14 Nov 2000 02:31:43 -0800 (PST) Received: from divyaroot.India.Sun.COM ([129.158.226.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11049 for ; Tue, 14 Nov 2000 02:39:05 -0800 (PST) Received: from uttarakuru (uttarakuru [129.158.226.94]) by divyaroot.India.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id QAA11034 for ; Tue, 14 Nov 2000 16:09:03 +0530 (IST) Message-Id: <200011141039.QAA11034@divyaroot.India.Sun.COM> Date: Tue, 14 Nov 2000 10:39:02 +0000 (Asia/Calcutta) From: Pradeep Pulappatta Reply-To: Pradeep Pulappatta Subject: HTTP traffic dumper To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: xW+CDzTCJpqxeex4F3g3lg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is anyone in this list familiar with a tool to dump HTTP traffic going in and out of a caching proxy?. Thanks Pradeep From owner-ietf-openproxy Thu Nov 16 14:54:53 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14971 for ietf-openproxy-bks; Thu, 16 Nov 2000 14:54:53 -0800 (PST) Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14963 for ; Thu, 16 Nov 2000 14:54:51 -0800 (PST) Received: from condrysony.intel.com (sonylaptop.jf.intel.com [134.134.159.198]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with ESMTP id PAA11200; Thu, 16 Nov 2000 15:13:03 -0800 (PST) Message-Id: <5.0.0.25.2.20001116130026.00a02e10@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 16 Nov 2000 14:58:11 -0800 To: pwg@catarina.usc.edu From: "Michael W. Condry" Subject: iCAP open mailing list Cc: ietf-openproxy@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For now, we are going to move open discussions of the iCAP draft to the OPES mailing list, ietf-openproxy@imc.org. In time we may split the lists if necessary. Michael W. Condry Director, Internet Strategy Intel Corporation 2111 NE 25th Avenue M/S JF3-206 Hillsboro, OR 97124 503-264-9019 condry@intel.com From owner-ietf-openproxy Thu Nov 16 15:18:30 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15380 for ietf-openproxy-bks; Thu, 16 Nov 2000 15:18:30 -0800 (PST) Received: from lecs.cs.ucla.edu (IDENT:root@Lecs.CS.UCLA.EDU [131.179.144.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15376 for ; Thu, 16 Nov 2000 15:18:29 -0800 (PST) Received: from concorde.cs.ucla.edu (concorde.cs.ucla.edu [131.179.144.102]) by lecs.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id PAA28798; Thu, 16 Nov 2000 15:25:53 -0800 Received: from concorde.cs.ucla.edu (localhost [127.0.0.1]) by concorde.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id PAA20017; Thu, 16 Nov 2000 15:25:53 -0800 Message-Id: <200011162325.PAA20017@concorde.cs.ucla.edu> From: Jeremy Elson To: "Michael W. Condry" cc: pwg@catarina.usc.edu, ietf-openproxy@imc.org Subject: Re: iCAP open mailing list In-Reply-To: Message from "Michael W. Condry" of "Thu, 16 Nov 2000 14:58:11 PST." <5.0.0.25.2.20001116130026.00a02e10@FMSMSX63.fm.intel.com> Date: Thu, 16 Nov 2000 15:25:53 -0800 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've added a note to this effect in the current draft of ICAP. "Michael W. Condry" writes: >For now, we are going to move open discussions of the iCAP draft to the >OPES mailing list, ietf-openproxy@imc.org. In time we may split the lists >if necessary. > > >Michael W. Condry >Director, Internet Strategy >Intel Corporation >2111 NE 25th Avenue >M/S JF3-206 >Hillsboro, OR 97124 >503-264-9019 >condry@intel.com From owner-ietf-openproxy Fri Nov 24 13:48:32 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA18568 for ietf-openproxy-bks; Fri, 24 Nov 2000 13:48:32 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18564 for ; Fri, 24 Nov 2000 13:48:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05142; Fri, 24 Nov 2000 16:49:35 -0500 (EST) Message-Id: <200011242149.QAA05142@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-beck-opes-esfnep-00.txt Date: Fri, 24 Nov 2000 16:49:34 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Example Services for Network Edge Proxies Author(s) : A. Beck, M. Hofmann Filename : draft-beck-opes-esfnep-00.txt Pages : 15 Date : 22-Nov-00 The rapid growth of the Internet and the increasing number of Internet users have led to a wide deployment of network edge caching proxies. These systems have been very successful in accelerating Web content delivery and reducing the load on origin Web servers. However, the specific role of these network edge caching proxies as a gateway between Web users and content providers suggests utilizing them for intelligent services beyond simple caching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-beck-opes-esfnep-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-beck-opes-esfnep-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-beck-opes-esfnep-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001122145621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-beck-opes-esfnep-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-beck-opes-esfnep-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001122145621.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy Fri Nov 24 19:06:56 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA23864 for ietf-openproxy-bks; Fri, 24 Nov 2000 19:06:56 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA23858 for ; Fri, 24 Nov 2000 19:06:54 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Nov 24 22:06:54 EST 2000 Received: from gemini (dhcp9145.cs.bell-labs.com [135.104.9.145]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id WAA01888 for ; Fri, 24 Nov 2000 22:06:52 -0500 (EST) From: "Markus Hofmann" To: Subject: FW: I-D ACTION:draft-beck-opes-psrl-00.txt Date: Fri, 24 Nov 2000 22:06:53 -0500 Message-ID: <007301c0568c$c304b650$44510d18@gemini> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0074_01C05662.DA2EAE50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0074_01C05662.DA2EAE50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, attached announcement is for an I-D that (hopefully) is of interest to the OPES group. -Markus ------=_NextPart_000_0074_01C05662.DA2EAE50 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Reply-To: From: Sender: To: Subject: I-D ACTION:draft-beck-opes-psrl-00.txt Date: Fri, 24 Nov 2000 18:00:42 -0500 Message-ID: <200011242300.SAA18874@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0070_01C05662.DA1C5ED0" X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 This is a multi-part message in MIME format. ------=_NextPart_000_0070_01C05662.DA1C5ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PSRL: A Rule Specification Language for Proxy Services Author(s) : A. Beck, M. Hofmann Filename : draft-beck-opes-psrl-00.txt Pages : 13 Date : 22-Nov-00 Proxy services are a new class of applications running on caching proxies or dedicated application servers, preferably at the network edge. They are described in [2] and [3]. Execution of proxy services is triggered by certain conditions. These conditions are service specific and have to be provided by the party on behalf of which the affected service modules are executed. The Proxy Service Rule Specification Language (PSRL) is an XML-based language that can be used to describe service specific execution rules. It allows a service provider to tell a proxy caching provider when and how the services should be executed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-beck-opes-psrl-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-beck-opes-psrl-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-beck-opes-psrl-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0070_01C05662.DA1C5ED0 Content-Type: Message/External-body; name="ATT00010.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00010.dat" Content-Type: text/plain Content-ID: <20001122145843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-beck-opes-psrl-00.txt ------=_NextPart_000_0070_01C05662.DA1C5ED0 Content-Type: Message/External-body; name="draft-beck-opes-psrl-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-beck-opes-psrl-00.txt" Content-Type: text/plain Content-ID: <20001122145843.I-D@ietf.org> ------=_NextPart_000_0070_01C05662.DA1C5ED0-- ------=_NextPart_000_0074_01C05662.DA2EAE50-- From owner-ietf-openproxy Sun Nov 26 23:34:52 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA20652 for ietf-openproxy-bks; Sun, 26 Nov 2000 23:34:52 -0800 (PST) Received: from web8002.mail.in.yahoo.com (web8002.in.yahoo.com [203.199.70.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA20637 for ; Sun, 26 Nov 2000 23:34:50 -0800 (PST) Message-ID: <20001127073754.6055.qmail@web8002.mail.in.yahoo.com> Received: from [192.18.17.3] by web8002.mail.in.yahoo.com; Mon, 27 Nov 2000 07:37:54 GMT Date: Mon, 27 Nov 2000 07:37:54 +0000 (GMT) From: =?iso-8859-1?q?Shuvendu=20Dang?= Subject: Re:PSRL: A Rule Specification Language for Proxy Services To: extproxy MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Can we have a "Pre-Requisite" element also. This element is basically for matching rules only if a previous rule has(has not) been matched for that particular message transaction (consisting of a request and response message). Means for a rule to be triggered say at the Proxy Response point, a previous rule must have been(or must have not been) triggered at say the Client Request point. This will make way for rules getting triggered on whether a previous rule has been triggered or not at any "processing-point"(or "filter-point"), and not just on nested "property" elements at that "processing-point"(only for one message transaction and the pre-reqisites are only valid for rules within one rule module). (Does this make sense???). Comments awaited. ===== SHUVENDU DANG Student Intern Sun Microsystems India Pvt. Ltd. ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.in address at http://mail.yahoo.co.in From owner-ietf-openproxy Mon Nov 27 00:37:05 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id AAA28897 for ietf-openproxy-bks; Mon, 27 Nov 2000 00:37:05 -0800 (PST) Received: from web8003.mail.in.yahoo.com (web8003.in.yahoo.com [203.199.70.21]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA28871 for ; Mon, 27 Nov 2000 00:36:55 -0800 (PST) Message-ID: <20001127083450.7894.qmail@web8003.mail.in.yahoo.com> Received: from [192.18.17.3] by web8003.mail.in.yahoo.com; Mon, 27 Nov 2000 08:34:50 GMT Date: Mon, 27 Nov 2000 08:34:50 +0000 (GMT) From: =?iso-8859-1?q?Shuvendu=20Dang?= Subject: Multiple Proxy::PSRL: A Rule Specification Language for Proxy Services To: extproxy MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi everybody, In case of multiple proxy configuration, should some other elements be included or do we add another party which can load rule-modules. Consider the case of a content provider. It adds some rule modules at several proxy servers. When an actual message goes it goes through several proxy servers. If more than one proxy servers have that rule-module installed, at what proxy server should the rules be triggered?? If we have another party in addition to Client, Access Provider and Content Provider;"Proxy Server". This also can add some rules at other Proxy Servers which will decide at which Proxy the rules are triggered, ie; rules for triggering rules. Does anybody have any idea how this can be done, if it should be done? Awaiting suggestions. Shuvendu.. **ref:PSRL: A Rule Specification Language for Proxy Services ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.in address at http://mail.yahoo.co.in From owner-ietf-openproxy Mon Nov 27 09:06:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16080 for ietf-openproxy-bks; Mon, 27 Nov 2000 09:06:07 -0800 (PST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16074 for ; Mon, 27 Nov 2000 09:06:06 -0800 (PST) Received: from condry.intel.com ([134.134.159.163]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with ESMTP id JAA22138; Mon, 27 Nov 2000 09:07:23 -0800 (PST) Message-Id: <5.0.0.25.2.20001127090434.00a44a80@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 27 Nov 2000 09:05:05 -0800 To: Shuvendu Dang , extproxy From: "Michael W. Condry" Subject: Re:PSRL: A Rule Specification Language for Proxy Services Cc: Markus Hofmann In-Reply-To: <20001127073754.6055.qmail@web8002.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Have you seen the I-D by Beck and Hofmann? At 07:37 AM 11/27/00 +0000, Shuvendu Dang wrote: >Hi, > Can we have a "Pre-Requisite" element also. This >element is basically for matching rules only if a >previous rule has(has not) been matched for that >particular message transaction (consisting of a >request and response message). > Means for a rule to be triggered say at the Proxy >Response point, a previous rule must have been(or must >have not been) triggered at say the Client Request >point. > This will make way for rules getting triggered on >whether a previous rule has been triggered or not at >any "processing-point"(or "filter-point"), and not >just on nested "property" elements at that >"processing-point"(only for one message transaction >and the pre-reqisites are only valid for rules within >one rule module). > (Does this make sense???). Comments awaited. > > >===== >SHUVENDU DANG >Student Intern >Sun Microsystems India Pvt. Ltd. > >____________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.co.in address at http://mail.yahoo.co.in Michael W. Condry Director, Internet Strategy Intel Corporation 2111 NE 25th Avenue M/S JF3-206 Hillsboro, OR 97124 503-264-9019 condry@intel.com From owner-ietf-openproxy Mon Nov 27 10:18:44 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA19821 for ietf-openproxy-bks; Mon, 27 Nov 2000 10:18:44 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19816 for ; Mon, 27 Nov 2000 10:18:41 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Nov 27 13:18:55 EST 2000 Received: from CC998558A (dhcp9169.cs.bell-labs.com [135.104.9.169]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id NAA13398 for ; Mon, 27 Nov 2000 13:18:51 -0500 (EST) From: "Markus Hofmann" To: Subject: Modified Example Services Draft Date: Mon, 27 Nov 2000 13:18:54 -0500 Message-ID: <000f01c0589e$8036dc90$44510d18@CC998558A> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_01C05874.9760D490" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C05874.9760D490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, attached a slightly modified version of the Example Services draft. We've submitted the modified version, but it will probably not be published in time for San Diego. As usual - comments welcome! -Markus ------=_NextPart_000_0010_01C05874.9760D490 Content-Type: text/plain; name="draft-beck-opes-esfnep-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-beck-opes-esfnep-01.txt" Internet Draft A. Beck=20 M. Hofmann=20 Lucent Technologies=20 M. Condry=20 Expires: May 2001 Intel Corporation=20 Document: draft-beck-opes-esfnep-01.txt November 21, 2000=20 Category: Informational =20 =20 =20 =20 Example Services for Network Edge Proxies=20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1].=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents=20 at any time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Table of Contents=20 =20 1 Introduction...................................................2=20 2 Virus Scanning.................................................3=20 2.1 Abstract.....................................................3=20 2.2 Business model...............................................3=20 2.3 Technical Challenges.........................................4=20 3 Insertion of Ad Banners........................................4=20 3.1 Abstract.....................................................4=20 3.2 Business model...............................................4=20 3.3 Technical Challenges.........................................4=20 4 Insertion of Regional Data.....................................5=20 4.1 Abstract.....................................................5=20 4.2 Business model...............................................5=20 4.3 Technical Challenges.........................................6=20 5 Caching of Personalized/Customized Web Pages...................6=20 5.1 Abstract.....................................................6=20 5.2 Business Model...............................................6=20 5.3 Technical Challenges.........................................6=20 6 Content Adaptation for Alternate Web Access Devices............6=20 =20 Beck et al. Expires May 2001 1=20 =0C Example Services for Network Edge Proxies November 2000 = 6.1 Abstract.....................................................7=20 6.2 Business model...............................................7=20 6.3 Technical Challenges.........................................7=20 7 Limited Client Bandwidth Adaptation............................8=20 7.1 Abstract.....................................................8=20 7.2 Business model...............................................8=20 7.3 Technical Challenges.........................................9=20 8 Adaptation of Streaming Media..................................9=20 8.1 Abstract.....................................................9=20 8.2 Business model...............................................9=20 8.3 Technical Challenges.........................................9=20 9 Request Filtering..............................................9=20 9.1 Abstract....................................................10=20 9.2 Business model..............................................10=20 9.3 Technical Challenges........................................10=20 10 Request Filtering through Content Analysis....................10=20 10.1 Abstract...................................................10=20 10.2 Business model.............................................11=20 10.3 Technical Challenges.......................................11=20 11 Creation of User Profiles.....................................11=20 11.1 Abstract...................................................11=20 11.2 Business model.............................................11=20 11.3 Technical Challenges.......................................12=20 12 Search Engine Index on Cached Web Pages.......................12=20 12.1 Abstract...................................................12=20 12.2 Business model.............................................12=20 12.3 Technical Challenges.......................................13=20 13 Language Translation..........................................13=20 13.1 Abstract...................................................13=20 13.2 Business model.............................................13=20 13.3 Technical Challenges.......................................13=20 14 Author's Addresses............................................14=20 15 References....................................................15=20 =20 =20 =20 =20 1 Introduction=20 =20 The rapid growth of the Internet and the increasing number of=20 Internet users have resulted in many scaling and growth problems=20 with application designs focused on operations at the ends (i.e. the=20 client or the server). This has led to a wide deployment of network=20 edge caching proxies as a key strategy to address these problems.=20 These systems have been very successful in accelerating Web content=20 delivery and reducing the load on origin Web servers. =20 =20 However, the specific role of these network edge caching proxies as=20 a gateway between Web users and content providers suggests utilizing=20 them for intelligent services beyond simple caching.=20 =20 There are already a variety of existing or proposed approaches that=20 implement particular services on top of a proxy platform. ICAP [5]=20 =20 Beck et al. Expires May 2001 2=20 =0C Example Services for Network Edge Proxies November 2000 = extends the basic idea of implementing value-added services on=20 proxies by handling transport of web objects between proxies and=20 content modification servers, thus, enabling remote call out=20 mechanisms. EPSFW [2, 7] describes an extended framework to provide=20 general services on top of an open proxy platform.=20 =20 This document discusses several service examples possibly being=20 implemented on top of an open proxy platform as described in [2, 7].=20 Each of the following service description consists of three=20 subsections: a short abstract that describes the service idea, a=20 description of the underlying business model, and finally a section=20 that mentions technical challenges to be addressed when implementing=20 these services.=20 =20 Section 2 describes virus scanning as an example service, which=20 currently is one of the most frequently cited service ideas. Section=20 3, 4, and 5 describe services that dynamically assemble personalized=20 content. These services exhibit the use of the proxy device managing=20 information about the client. Sections 6 and 7 present services that=20 adapt content to the capability of client devices and client access=20 bandwidth. Some of the previous service ideas can also be applied to=20 streaming media, which is discussed in Section 8. The services given=20 in Section 9, 10, and 11 operate on client requests rather than on=20 the content itself. More service examples are given in Sections 12=20 and 13.=20 =20 2 Virus Scanning=20 =20 2.1 Abstract=20 =20 Viruses, Trojan Horses, and worms have always posed a threat to=20 Internet users. Just recently we have seen a number of e-mail based=20 worms that have hit millions of Internet users worldwide within a=20 few hours. =20 =20 With the help of a content scanning and filtering system at the=20 caching proxy level, Web pages and also file transfers could be=20 scanned for malicious content prior to sending them to the user. In=20 Web pages active content like ActiveX, Java and JavaScript could be=20 scanned for harmful code (e.g. code exploiting security holes). File=20 transfers could be scanned for known viruses. If a virus is found,=20 the adaptation server could try to remove it or deny the delivery of=20 the infected content. A general rule could be that the caching proxy=20 may store and/or deliver content only, if it has been scanned by the=20 content adaptation server and no viruses are found. =20 =20 2.2 Business model=20 =20 This service could be offered as an additional feature to ISP=20 customers who are concerned about security issues. Likewise=20 enterprises could be interested in this solution to prevent any=20 malicious content from entering the company network.=20 =20 =20 Beck et al. Expires May 2001 3=20 =0C Example Services for Network Edge Proxies November 2000 = 2.3 Technical Challenges=20 =20 Web pages/files should be scanned for viruses by sending them to a=20 separate server where virus-scanning software would analyze them.=20 ICAP [5] is an example protocol for this purpose. The virus scanning=20 operations should not be performed on the caching proxy as they will=20 probably affect the performance of the caching proxy.=20 =20 If HTTP file transfers are to be scanned for viruses and the=20 requested file cannot be found in the cache, we have to use a=20 different approach than for Web pages. It would not be feasible if=20 the proxy waited for the requested file to be received completely=20 before sending it over to the content adaptation server for the=20 virus scan. This approach would lead to a long delay at the user=92s=20 end, which is not acceptable. Instead, we would have to scan the=20 file transfer continuously, as it is being sent to the user (similar=20 to streaming media).=20 =20 =20 3 Insertion of Ad Banners =20 =20 3.1 Abstract=20 =20 Many Internet companies rely heavily on revenue made by selling=20 advertisement space on their Web pages. Whenever advertisement=20 banners are inserted dynamically depending on who requests the page,=20 they cannot be cached, even when the content of the page itself is=20 static. This behavior prevents Web pages from being cached, although=20 their static content would allow for it.=20 =20 Therefore it seems reasonable to cache the static part of those Web=20 pages at a caching proxy near the client and to insert ad banners=20 into the cached Web pages before serving them to the client. =20 =20 3.2 Business model=20 =20 This service is a sales item to Internet advertising networks. They=20 obtain a market from customers wishing a low cost network access in=20 return for advertising. This is the free ISP market. Also, content=20 providers who do not want to outsource their ad space management and=20 sales might be interested in providing banner images and insertion=20 rules to proxies/content adaptation servers to accelerate the=20 delivery of their Web pages.=20 =20 An ad insertion module at the caching proxy of the Free ISP could=20 insert ad banners (in addition to any ad banners from the content=20 provider) into every Web page requested by a customer. That way the=20 customers of the Free ISP will not have to install any special=20 software in order to use its service.=20 =20 3.3 Technical Challenges=20 =20 =20 Beck et al. Expires May 2001 4=20 =0C Example Services for Network Edge Proxies November 2000 = The caching proxy would have to recognize when and where to insert=20 ad banners into a Web page before serving it to the client. The=20 proxy could for instance scan the Web page for a specific marking=20 (e.g. a special tag). In the case of a Free ISP ad banners would=20 probably always be inserted at the same position (e.g. in a frame at=20 the top of each page) or in a separate pop-up window.=20 =20 If we wanted to insert advertisements based on the user and his=20 interests, we would have to identify the user (by using cookies for=20 example) and create user profiles. The user profiles could also be=20 provided by the content provider.=20 =20 A standard model for identifying space where the content providers=20 allow for advertising insertion is critical. This will have to be=20 coordinated with groups defining content structure, such as XML with=20 W3C [4].=20 =20 4 Insertion of Regional Data=20 =20 4.1 Abstract=20 =20 If a content provider wants to add user-specific regional=20 information (weather forecasts for certain areas for example) to his=20 Web pages, he has little choice but to have the user select his=20 location from a list of regions. Usually it is not possible for=20 origin servers to reliably detect from where Web users connect to=20 Web sites because user requests can get routed through a number of=20 proxy servers on their way from the client to the origin server. =20 =20 In a network edge caching proxy environment user requests are=20 usually redirected to the nearest proxy that is available to respond=20 to the request. Regional information that is relevant to all users=20 who are likely to connect to a certain proxy could be stored at the=20 corresponding caching proxy. Whenever the proxy receives a user=20 request, a module on the caching proxy could insert the regional=20 information into the requested Web page. If the Web page does not=20 contain any user-specific non-cacheable content other than the=20 inserted regional information, the Web page content can now be=20 cached for future requests.=20 =20 4.2 Business model=20 =20 This service could be sold to content providers who want to offer=20 regional information on their Web sites and want to accelerate the=20 delivery of their Web content. There are many cases in which a=20 content provider could profit from knowing the location of the user.=20 Users could be targeted with regional advertisement banners (see=20 also ad insertion scenario). Regional distinctions (e.g. sales=20 taxes, differing laws etc.) could be taken into consideration when=20 the Web pages are prepared for the client. It would not be necessary=20 any more to ask the user for his location prior to presenting him=20 relevant information.=20 =20 =20 Beck et al. Expires May 2001 5=20 =0C Example Services for Network Edge Proxies November 2000 = 4.3 Technical Challenges=20 =20 The regional content that is to be inserted into the Web pages would=20 have to be distributed to the corresponding caching proxies. Since=20 the regional content represents only a component of a whole Web=20 page, it cannot be cached in the same way a complete Web page can be=20 cached (unless it is an image). We have to find a mechanism to=20 determine when a regional text component needs to be updated (or if=20 the content provider should be responsible for this).=20 =20 =20 5 Caching of Personalized/Customized Web Pages=20 =20 5.1 Abstract=20 =20 Many Web sites (e.g. Yahoo) offer a service where users can create=20 their own personalized version of the Web site (e.g. MyYahoo). It=20 basically means that a user can choose from a number of components=20 (e.g. stock information, weather forecasts, news etc.) and create a=20 personalized Web page with them. This leads to dynamic Web pages=20 that usually cannot be cached. However, the components of the=20 personalized Web page can be cached. Therefore, it is possible to=20 have a service module on the server create the user-specific Web=20 pages by assembling the cached Web site components. In that case the=20 origin server would not have to be contacted again and the page=20 could be served to the client directly from the network edge caching=20 proxy.=20 =20 5.2 Business Model=20 =20 This service would be another method of accelerating the delivery of=20 Web content to the user, particularly the delivery of=20 personalized/customized Web pages that would not be cacheable=20 otherwise. It also saves bandwidth between the origin server and the=20 proxy cache.=20 =20 Content providers who offer their customers the possibility of=20 personalizing their Web pages are likely to be willing to pay for=20 this kind of service. =20 =20 5.3 Technical Challenges=20 =20 We would have to find a caching mechanism for the separate=20 components of the personalized Web pages (unless a component=20 consists of an image only). These components could be stored at the=20 caching proxy.=20 =20 The page components would have to be refreshed just like complete=20 Web page whenever they become stale.=20 =20 =20 6 Content Adaptation for Alternate Web Access Devices=20 =20 =20 Beck et al. Expires May 2001 6=20 =0C Example Services for Network Edge Proxies November 2000 = 6.1 Abstract=20 =20 There is a growing diversity and heterogeneity in types and=20 capabilities of client devices as well as the forms of network=20 connections that people use to access the Web. Clients include cell=20 phones and PDAs as well as PCs, TVs (with SetTop boxes), etc.=20 However, these appliances have quite diverse display capabilities,=20 storage, processing power, as well as slow network access. As a=20 result, Internet access is still constrained on these devices and=20 users are limited to only a small fraction of the total number of=20 Web pages available in the Internet today. Organizations such as the=20 WAP forum [4] have suggested custom Web page design but this results=20 in special code frequently required on the content server.=20 =20 Since the number of different access devices is growing constantly=20 content providers cannot be expected to provide different versions=20 of their Web pages for each and every Web access device that is=20 available in the market.=20 =20 Therefore, if it is possible to transcode the general full-fledged=20 Web pages at some point on their way from the origin server to the=20 user so that they are optimized for (or at least adapted to) the end=20 users' specific requirements, it would provide a valuable service=20 for the end customer, the service provider, and the content=20 provider.=20 =20 6.2 Business model=20 =20 With the above-mentioned service in place, Web content providers=20 could reach a much wider audience and the manufactures of diverse=20 Web access devices could offer potential customers access to a=20 bigger part of the Internet content, which should make a very good=20 selling point. It would encourage more people to buy non-desktop Web=20 access devices like cell phones and PDAs expanding the market.=20 =20 We would expect this service would be offered as an additional=20 feature to ISP customers who want to access the Web through=20 different Web-enabled devices. Also, the service might be paid by=20 content providers because they could serve their existing content to=20 more users; likewise, the non-desktop device makers may contribute=20 to this service cost making their client devices more effective at=20 the Web.=20 =20 6.3 Technical Challenges=20 =20 Possible adaptations to meet the special requirements of different=20 Web access devices are:=20 =20 - Conversion of HTML pages to WML (Wireless Markup Language) pages =20 - Conversion of JPEG images to black and white GIF images=20 - Conversion of HTML tables to plain text =20 - Reduction of image quality=20 - Removal of redundant information=20 =20 Beck et al. Expires May 2001 7=20 =0C Example Services for Network Edge Proxies November 2000 = - Stripping of Java applets / JavaScript=20 - Audio to text conversion=20 - Video to key frame or video to text conversion=20 - Content extraction=20 =20 We have to ensure that the automatic adaptation process will not=20 make changes to a Web page that are unwanted by either the content=20 provider or the recipient. Our suggested strategy to achieve this=20 would be to allow the content provider as well as the client to=20 define their preferences as to how they want Web pages to be=20 adapted. The actual adaptation decisions would then be made based on=20 the given preferences and a set of transformation rules. There would=20 have to be a mechanism of resolving potential conflicts between the=20 content provider's and the user's adaptation preferences. If neither=20 the content provider nor the client has expressed his preferences, a=20 default adaptation of the requested Web page may be possible but=20 investigation is needed.=20 =20 A way for preferences to be specified representing the content=20 provider and client customer must be provided. For example, client=20 customers could set their preferences through a Web interface on the=20 ISP Web site. Content providers could express their preferences by=20 adding meta tags to their Web pages. This meta data offers the=20 content provider the ability to specify a number of alternatives and=20 the content adaptation server could then pick the most appropriate=20 one. This meta data should be independent of specific Web content=20 but is likely to depend on the types of content in the pages.=20 Another possibility in the ESPWF [2, 7] framework would be for the=20 content provider would be to provide an adaptation policy to all=20 ISPs that want to adapt Web pages for alternate Web access devices.=20 This policy could consist of general transformation rules or actual=20 code modules that perform the adaptation.=20 =20 =20 7 Limited Client Bandwidth Adaptation=20 =20 7.1 Abstract=20 =20 Different Internet clients can handle different Internet connection=20 speeds. Therefore it seems desirable to adapt the requested Web=20 content to the user=92s bandwidth. =20 =20 7.2 Business model=20 =20 One of the main benefits is to decrease the Web access time for=20 users. If a Web site loads too slowly, users tend to leave the site=20 even before it has completed loading the home page. The improved=20 perceived quality of service by adaptive content delivery means that=20 users are more likely to stay and return, thus resulting in a=20 greater profit for e-commerce sites. This can also result in higher=20 hit rates and return rates, which can lead to higher sales for e- commerce sites and higher advertising revenues.=20 =20 =20 Beck et al. Expires May 2001 8=20 =0C Example Services for Network Edge Proxies November 2000 = 7.3 Technical Challenges=20 =20 Possible adaptations to reduce the size of Web objects are:=20 =20 - Reduction of image quality=20 - Replacement of images by their ALT text=20 - Removal of redundant information=20 - Removal of HTML comments=20 - Stripping of Java applets / JavaScript=20 - Audio to text conversion=20 - Video to key frame or video to text conversion=20 - Text summarizing=20 - Content extraction=20 =20 We would have to find a reliable way of determining the bandwidth=20 between the client and the proxy cache. One way of measuring this=20 would be to measure the round trip time (RTT) to determine the=20 connection speed. It is crucial that this bandwidth detection method=20 works more or less exact or otherwise the client will either=20 experience very slow Web browsing or be cut off of some (or all) of=20 the rich Web content. This service requires authorization by the=20 user like any other adaptation service that changes the content and=20 or format of Web pages.=20 =20 The mapping of a user=92s connection speed to appropriate page=20 adaptations requires defining a set of adaptation rules.=20 =20 =20 8 Adaptation of Streaming Media=20 =20 8.1 Abstract=20 =20 Some of the above-mentioned services could not only be applied to=20 Web pages but also to streaming media like audio and video streams.=20 In particular, media streams could be adapted to meet the bandwidth=20 of the user=92s connection. It would also be possible to insert pre- recorded advertisements into audio or video streams. Even content=20 analysis and content filtering could be applied to streaming media. =20 =20 8.2 Business model=20 =20 The business models for streaming media adaptation are similar to=20 those for Web page adaptation services. =20 =20 8.3 Technical Challenges=20 =20 The adaptation of streaming media will add more complexity to the=20 caching proxy platform and the technical challenges of these kind of=20 services have yet to be explored.=20 =20 =20 9 Request Filtering=20 =20 =20 Beck et al. Expires May 2001 9=20 =0C Example Services for Network Edge Proxies November 2000 = 9.1 Abstract=20 =20 The success of Web filtering/blocking systems like NetNanny=20 (http://www.netnanny.com) and WebSense (http://www.websense.com)=20 shows that there is a great need for solutions that let the owner of=20 a Web access device control what kind of Web content can be accessed=20 with his device. Parents, for instance, often demand a means of=20 blocking off offending material when their children browse the Web.=20 Also, companies might want to have control over what kind of Web=20 pages their employees can have access to. Companies might also want=20 to prevent their employees from using the available bandwidth=20 excessively for non-work related activities. =20 =20 A request filtering service could provide a solution for all of the=20 above. If all Web page requests of a specific user are routed=20 through a caching proxy server, the content adaptation server could=20 analyze the requests prior to fulfilling them. The service module=20 would have to identify the user and determine the user=92s access=20 level. The next step would be to look up the classification of the=20 requested Web page in a database.=20 =20 =20 9.2 Business model=20 =20 This service could be offered to enterprises and to ISPs. A database=20 of Web pages that contain offending material could be obtained from=20 companies that have specialized in Web blocking systems.=20 =20 9.3 Technical Challenges=20 =20 The database on the proxy caching platform that contains the Web=20 page classifications needs to be updated on a regular basis. If the=20 database is provided by third parties, we have to provide them with=20 a secure way of updating the database.=20 =20 If a Web access device is shared among different users who have=20 different access levels, it is not sufficient to identify the Web=20 access device. Therefore it will probably be necessary that=20 different users of a Web access device use different user accounts.=20 =20 The owner of a Web access device must be able to define and change=20 the access rights of the user(s) of his device. This could be done=20 through a Web interface provided by the ISP/company.=20 =20 =20 10 Request Filtering through Content Analysis=20 =20 10.1 Abstract=20 =20 While this service is very similar to the one previously described,=20 it works more dynamically in that the content adaptation server=20 analyzes the Web content once it has been retrieved from either the=20 proxy cache or the origin server prior to sending it to the client. =20 =20 Beck et al. Expires May 2001 10=20 =0C Example Services for Network Edge Proxies November 2000 = Through the use of sophisticated content analysis algorithms it=20 should be possible to classify the analyzed Web content. If the=20 classification of the Web page matches the user=92s access level, the = page will be delivered to the client. Otherwise, the client will be=20 denied the page. The analyzed page along with its classification=20 should be stored in the proxy cache so that future requests for the=20 same page do not require the cached Web to be analyzed again. This=20 will result in a better Web page delivery performance for popular=20 Web pages. The main benefit of this approach is that there is no=20 need to provide or maintain lists of forbidden Web sites, a process=20 that per definition must always lag behind the creation of new Web=20 sites. If common characteristics of a category of unwanted Web pages=20 can be defined, it should be possible to automatically detect=20 whether a requested Web page falls in a forbidden category. =20 =20 10.2 Business model=20 =20 This service could be offered to enterprises and ISPs. The content=20 analysis software could be obtained from software companies that=20 have specialized in this field.=20 =20 10.3 Technical Challenges=20 =20 In addition to the technical challenges described in the previous=20 service scenario, we would have to find a way of storing the=20 classification information of Web pages once they have been=20 analyzed. One way to do this would be to add a meta tag (possibly=20 using the Resource Description Framework [6] specification) with=20 content rating information to a Web page before it is cached.=20 Subsequent requests of the same Web page would then require the=20 request filtering service module to scan the cached Web page for=20 this metadata in order to determine the content rating of the=20 requested page. =20 =20 =20 11 Creation of User Profiles=20 =20 11.1 Abstract=20 =20 If all Web requests of a certain Web user were routed through a=20 certain caching proxy platform, it would be easy to log them in=20 order to create a profile of the user=92s Web browsing behavior. = These=20 user profiles could be created anonymously with no personal data=20 (e.g. name or e-mail address) stored in the access log files.=20 =20 Once a sufficient number of requests has been logged by the content=20 adaptation server, the marketing group could start analyzing the log=20 files. In most cases it should be possible to derive the user=92s=20 interests by analyzing what kind of Web sites the user visits and=20 how often he goes there.=20 =20 11.2 Business model=20 =20 =20 Beck et al. Expires May 2001 11=20 =0C Example Services for Network Edge Proxies November 2000 = Companies that want to advertise on Web pages are very interested in=20 knowing more about the recipients of their advertisement campaigns=20 so that they can target their advertisements at people who are=20 interested in the kind of products/services that the company wants=20 to sell. These companies will pay for information that helps them to=20 target their campaigns at interested users. This money could be=20 offered to users (e.g. in the form of reduced Internet access fees)=20 to give them an incentive to agree to the profiling.=20 =20 As explained above, we could derive the user=92s interests from his=20 Web browsing behavior and use this information to send the user only=20 those advertisements that match his interests/needs. This will most=20 likely result in a higher ad banner click-rate per user. =20 =20 This service could be sold separately or in combination with the ad=20 insertion service.=20 =20 11.3 Technical Challenges=20 =20 The creation of user profiles requires a mechanism to identify Web=20 users. The ISP could provide a mapping from the user=92s (possibly=20 dynamic) IP number to some unique user ID. Another alternative would=20 be to use cookies, provided that the user has not disabled them in=20 his Web browser.=20 =20 =20 12 Search Engine Index on Cached Web Pages =20 =20 12.1 Abstract=20 =20 A proxy usually contains the most frequently requested Web pages of=20 the Web users whose Web requests are routed through it. If we=20 indexed the content of all Web pages currently contained in one or=20 more proxies, we would have an index of Web pages that Web users are=20 very likely to request (since they have been the most popular in the=20 past). A search engine based on this index could therefore yield a=20 high hit rate when used by a group of users who have similar=20 interests and usually connect to the same caching proxies. The=20 benefit of this approach would be that the index could be created=20 very fast (there is no Web crawling to do) and that the search=20 results could be returned to the user directly from the network edge=20 caching proxy. The drawback, however, is that this search engine=20 would index only a small fraction of the existing Web pages. Web=20 users have to be aware of this fact when they use the cache-based=20 search index service. Another approach would be to display the proxy=20 search results first while a global search engine prepares the=20 results of a global search in the meantime. As soon as the global=20 search results become available, they will be sent to the user.=20 =20 12.2 Business model=20 =20 The search engine service described above could be sold to big=20 companies who have users with similar interests and want to provide=20 =20 Beck et al. Expires May 2001 12=20 =0C Example Services for Network Edge Proxies November 2000 = a fast search engine. Companies offering traditional search engines=20 could be interested in combining their services with a cache-based=20 search engine service to accelerate the delivery of their search=20 results.=20 =20 12.3 Technical Challenges=20 =20 If the cached Web pages of more than one caching proxy were to be=20 indexed, we would have to find a way of replicating the search index=20 to all affected caching proxy servers. =20 =20 =20 13 Language Translation=20 =20 13.1 Abstract=20 =20 Soon the majority of all Internet users will be non-English=20 speaking. As most of the current Web content is written in English,=20 it becomes desirable to be able to translate the English content to=20 the Web user=92s local language, even if the content provider does = not=20 offer translations of his Web content. An automatic translation=20 service for all Web pages could be implemented with a content=20 adaptation server.=20 =20 The proxy server will determine the Web user's preferred language(s)=20 and ask whether the content requested should be translated to the=20 user's preferred language. If the content is to be translated, the=20 proxy cache will forward the Web content to a translation server=20 where the page then is automatically translated. The proxy could=20 also locally store translated content eliminating the need to repeat=20 translations for different users.=20 =20 13.2 Business model=20 =20 The automatic language translation service will help break language=20 barriers and open new markets for e-commerce. The average non- English speaking Web user will have access to more Web content.=20 ISPs, especially those with customers in non-English speaking=20 countries, could offer this service to their customers. =20 =20 13.3 Technical Challenges=20 =20 The automatic translation of text found on Web pages is not a=20 trivial task. It will not be possible to translate a Web page=20 automatically without running the risk of rendering parts of it=20 incomprehensible. Worse yet, the original meaning could be changed=20 and it is not said the reader of the translated page will notice the=20 change in meaning. It is questionable whether content providers=20 would even tolerate this kind of translation service. =20 =20 Therefore it is very important that the client authorizes this=20 translation service and is fully aware of its potentially faulty=20 =20 Beck et al. Expires May 2001 13=20 =0C Example Services for Network Edge Proxies November 2000 = behavior. It should also be considered to mark translated pages in a=20 specific way to remind the user of the machine translation. =20 =20 Other technical challenges include the automatic detection of the=20 language used in the original document and the client=92s local=20 language.=20 =20 =20 14 Author's Addresses=20 =20 Andre Beck=20 Markus Hofmann=20 Bell Labs Research=20 Lucent Technologies=20 101 Crawfords Corner Rd.=20 Holmdel, NJ 07733=20 Phone: (732) 332-5983=20 Email: {abeck, hofmann}@bell-labs.com=20 =20 Michael W. Condry=20 Intel Corporation=20 2111 NE 25th Avenue=20 M/S JF3-206=20 Hillsboro, OR 97124=20 Phone: 503-264-9019=20 Email: condry@intel.com=20 =20 =20 Beck et al. Expires May 2001 14=20 =0C Example Services for Network Edge Proxies November 2000 = =20 15 References=20 =20 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP=20 9, RFC 2026, October 1996.=20 =20 2 Tomlinson, G., et al., "Extensible Proxy Services Framework",=20 Work in Progress, Internet Draft draft-tomlinson-epsfw-00.txt,=20 July 2000.=20 =20 3 World Wide Web Consortium (W3C), http://www.w3.org.=20 =20 4 The Wireless Application Protocol (WAP) Forum,=20 http://www.wapforum.org/.=20 =20 5 ICAP Protocol Group, "ICAP - the Internet Content Adaptation=20 Protocol", submitted as Internet Draft draft-elson-opes-icap- 00.txt, (previous version available at http://www.i-cap.org/),=20 November 17, 2000.=20 =20 6 Resource Description Framework (RDF), http://www.w3.org/RDF.=20 =20 7 Open Proxy Extensible Services (OPES), http://www.extproxy.org.=20 =20 =20 =20 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2000). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 =20 =20 Beck et al. Expires May 2001 15=20 =0C Example Services for Network Edge Proxies November 2000 = =20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 Acknowledgement=20 =20 Funding for the RFC editor function is currently provided by the=20 Internet Society.=20 =20 =20 =20 Beck et al. Expires May 2001 16=20 =0C ------=_NextPart_000_0010_01C05874.9760D490-- From owner-ietf-openproxy Mon Nov 27 11:18:42 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA24698 for ietf-openproxy-bks; Mon, 27 Nov 2000 11:18:42 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA24689 for ; Mon, 27 Nov 2000 11:18:40 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Nov 27 14:19:01 EST 2000 Received: from bell-labs.com (abeck-pcho [135.180.144.207]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA18032; Mon, 27 Nov 2000 14:18:54 -0500 (EST) Message-ID: <3A22B31B.98A49224@bell-labs.com> Date: Mon, 27 Nov 2000 14:16:43 -0500 From: Andre Beck Organization: Bell Labs Research X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en-US,de,fr MIME-Version: 1.0 To: Shuvendu Dang CC: extproxy , Markus Hofmann Subject: Re: PSRL: A Rule Specification Language for Proxy Services References: <20001127073754.6055.qmail@web8002.mail.in.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Can we have a "Pre-Requisite" element also. This > element is basically for matching rules only if a > previous rule has(has not) been matched for that > particular message transaction (consisting of a > request and response message). Do we really need a new element to do this? We thought that all existing transaction properties (both request and response) could be matched at any of the four processing points. So you could write a rule that gets processed at processing point 4 and matches request properties as well as response properties. Instead of writing two separate rules with two different processing points you could combine them into one rule. The property values, however, may be modified by other rules at earlier processing point. All rules are matched against the current property value. We thought about introducing a attribute that allows for a comparision against the original property value, but decided that in almost all cases it makes more sense to work with the current (and possibly modified) property value. -Andre From owner-ietf-openproxy Mon Nov 27 11:51:31 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27629 for ietf-openproxy-bks; Mon, 27 Nov 2000 11:51:31 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27624 for ; Mon, 27 Nov 2000 11:51:30 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Nov 27 14:50:09 EST 2000 Received: from bell-labs.com (abeck-pcho [135.180.144.207]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA21504; Mon, 27 Nov 2000 14:50:58 -0500 (EST) Message-ID: <3A22BA9B.B121CD49@bell-labs.com> Date: Mon, 27 Nov 2000 14:48:43 -0500 From: Andre Beck Organization: Bell Labs Research X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en-US,de,fr MIME-Version: 1.0 To: Shuvendu Dang CC: extproxy , Markus Hofmann Subject: Re: Multiple Proxy::PSRL: A Rule Specification Language for Proxy Services References: <20001127083450.7894.qmail@web8003.mail.in.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Consider the case of a content provider. It adds some > rule modules at several proxy servers. When an actual > message goes it goes through several proxy servers. If > more than one proxy servers have that rule-module > installed, at what proxy server should the rules be > triggered?? I don't think there is really a problem. First of all I think it's the content provider's responsibility to install his rule modules at the right proxies. But even if a client request goes through several proxies with the same rule modules installed, the rule modules should be processed at each proxy. This doesn't mean that the rule action will be executed more than once, as the same rules may not match any more once the message has been modified by a service module on the first proxy. -Andre From owner-ietf-openproxy Tue Nov 28 09:46:55 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA26205 for ietf-openproxy-bks; Tue, 28 Nov 2000 09:46:55 -0800 (PST) Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26199 for ; Tue, 28 Nov 2000 09:46:54 -0800 (PST) Received: from condry.intel.com (sonylaptop.jf.intel.com [134.134.159.163]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with ESMTP id JAA08538; Tue, 28 Nov 2000 09:59:23 -0800 (PST) Message-Id: <5.0.0.25.2.20001128094035.00a71890@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 28 Nov 2000 09:44:48 -0800 To: pwg@catarina.usc.edu From: "Michael W. Condry" Subject: Fwd: I-D ACTION:draft-elson-opes-icap-00.txt Cc: ietf-openproxy@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Draft made it! >To: IETF-Announce: ;;IETF-Announce:;@loki.ietf.org; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-elson-opes-icap-00.txt >Date: Tue, 28 Nov 2000 05:58:45 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : ICAP the Internet Content Adaptation Protocol > Author(s) : J. Elson et al. > Filename : draft-elson-opes-icap-00.txt > Pages : 29 > Date : 27-Nov-00 > >ICAP, the Internet Content Adaptation Protocol, is part of an >evolving architecture that facilitates better distribution and >caching for the web. ICAP is, in essence, a lightweight protocol for >executing a 'remote procedure call' on HTTP messages. That is, it >allows ICAP clients to pass HTTP messages to ICAP servers for >'adaptation' -- some sort of transformation or other processing. The >server executes its transformation service on messages and sends back >responses to the client, usually with modified messages. The adapted >messages may be either HTTP requests or HTTP responses. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-elson-opes-icap-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-elson-opes-icap-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-elson-opes-icap-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <20001127132810.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-elson-opes-icap-00.txt > > Michael W. Condry Director, Internet Strategy Intel Corporation 2111 NE 25th Avenue M/S JF3-206 Hillsboro, OR 97124 503-264-9019 condry@intel.com From owner-ietf-openproxy Tue Nov 28 10:10:34 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA28213 for ietf-openproxy-bks; Tue, 28 Nov 2000 10:10:34 -0800 (PST) Received: from lecs.cs.ucla.edu (IDENT:root@Lecs.CS.UCLA.EDU [131.179.144.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28209 for ; Tue, 28 Nov 2000 10:10:33 -0800 (PST) Received: from concorde.cs.ucla.edu (concorde.cs.ucla.edu [131.179.144.102]) by lecs.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id KAA12933; Tue, 28 Nov 2000 10:11:46 -0800 Received: from concorde.cs.ucla.edu (localhost [127.0.0.1]) by concorde.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id KAA15920; Tue, 28 Nov 2000 10:11:46 -0800 Message-Id: <200011281811.KAA15920@concorde.cs.ucla.edu> From: Jeremy Elson To: "Michael W. Condry" cc: pwg@catarina.usc.edu, ietf-openproxy@imc.org Subject: Re: Fwd: I-D ACTION:draft-elson-opes-icap-00.txt In-Reply-To: Message from "Michael W. Condry" of "Tue, 28 Nov 2000 09:44:48 PST." <5.0.0.25.2.20001128094035.00a71890@FMSMSX63.fm.intel.com> Date: Tue, 28 Nov 2000 10:11:46 -0800 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Whoohoo! What an enormous load off my mind :-) "Michael W. Condry" writes: >The Draft made it! >>To: IETF-Announce: ;;IETF-Announce:;@loki.ietf.org; >>From: Internet-Drafts@ietf.org >>Reply-to: Internet-Drafts@ietf.org >>Subject: I-D ACTION:draft-elson-opes-icap-00.txt >>Date: Tue, 28 Nov 2000 05:58:45 -0500 >>Sender: nsyracus@cnri.reston.va.us >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : ICAP the Internet Content Adaptation Protocol >> Author(s) : J. Elson et al. >> Filename : draft-elson-opes-icap-00.txt >> Pages : 29 >> Date : 27-Nov-00 >> >>ICAP, the Internet Content Adaptation Protocol, is part of an >>evolving architecture that facilitates better distribution and >>caching for the web. ICAP is, in essence, a lightweight protocol for >>executing a 'remote procedure call' on HTTP messages. That is, it >>allows ICAP clients to pass HTTP messages to ICAP servers for >>'adaptation' -- some sort of transformation or other processing. The >>server executes its transformation service on messages and sends back >>responses to the client, usually with modified messages. The adapted >>messages may be either HTTP requests or HTTP responses. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-elson-opes-icap-00.txt >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-elson-opes-icap-00.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-elson-opes-icap-00.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >>Content-Type: text/plain >>Content-ID: <20001127132810.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-elson-opes-icap-00.txt >> >> > >Michael W. Condry >Director, Internet Strategy >Intel Corporation >2111 NE 25th Avenue >M/S JF3-206 >Hillsboro, OR 97124 >503-264-9019 >condry@intel.com From owner-ietf-openproxy Tue Nov 28 23:25:57 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id XAA02586 for ietf-openproxy-bks; Tue, 28 Nov 2000 23:25:57 -0800 (PST) Received: from web8003.mail.in.yahoo.com (web8003.in.yahoo.com [203.199.70.21]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA02570 for ; Tue, 28 Nov 2000 23:25:52 -0800 (PST) Message-ID: <20001129072354.6914.qmail@web8003.mail.in.yahoo.com> Received: from [192.18.17.3] by web8003.mail.in.yahoo.com; Wed, 29 Nov 2000 07:23:54 GMT Date: Wed, 29 Nov 2000 07:23:54 +0000 (GMT) From: =?iso-8859-1?q?Shuvendu=20Dang?= Subject: questions on PSRL I-D To: Andre Beck , Markus Hofmann Cc: OPENPROXY IETF MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, According to the PSRL draft, the "action" element contains the name of the service module (proxylet) that is to be executed on the caching proxy (name of the built-in proxy library function) or a dedicated server(ICAP server). So, there are 2 possibilities, either the proxylet is on a dedicated server or in a built-in proxylet library. But the person who sets the rule may want that, the proxy download a proxylet from another server(a server where he puts his own proxylets or a server which is providing proxylets to be downloaded) specified in the rule, store it in the proxy itself and execute the cached proxylet when the corresponding rule is triggered. The proxylet can have a expiry time-period to tell the proxy when to download the proxylet from the server. eg: ftp:/freeproxylets.com/proxylet1 Thu, 01 Dec 2001 16:00:00 GMT That means now we can use downloaded proxylets, or built-in library functions or use a dedicated server for proxylet execution. Any comments. Thanks Shuvendu ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.in address at http://mail.yahoo.co.in From owner-ietf-openproxy Wed Nov 29 01:02:34 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA15868 for ietf-openproxy-bks; Wed, 29 Nov 2000 01:02:34 -0800 (PST) Received: from web8001.mail.in.yahoo.com (web8001.in.yahoo.com [203.199.70.19]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA15864 for ; Wed, 29 Nov 2000 01:02:31 -0800 (PST) Message-ID: <20001129090455.7884.qmail@web8001.mail.in.yahoo.com> Received: from [192.18.17.3] by web8001.mail.in.yahoo.com; Wed, 29 Nov 2000 09:04:55 GMT Date: Wed, 29 Nov 2000 09:04:55 +0000 (GMT) From: =?iso-8859-1?q?Shuvendu=20Dang?= Subject: Re: PSRL: A Rule Specification Language for Proxy Services To: Andre Beck Cc: extproxy , Markus Hofmann MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --- Andre Beck wrote: > > We > thought that all existing > transaction properties (both request and response) > could be matched at > any of the four processing points. So you could > write a rule that gets > processed at processing point 4 and matches request > properties as well > as response properties. Instead of writing two > separate rules with two > different processing points you could combine them > into one rule. The > property values, however, may be modified by other > rules at earlier > processing point. All rules are matched against the > current property > value. We thought about introducing a attribute that > allows for a > comparision against the original property value, but > decided that in > almost all cases it makes more sense to work with > the current (and > possibly modified) property value. > > -Andre > Consider this case: based on some property values, some rules are matching, say the first of such rules is triggered. Now suppose the proxylet associated with the triggered rule changes some of the property values, which now match some other rules, so they may be triggered. And this may go on. To check which new rules are triggered the message (body and header) may have to be parsed again.Isn't there a chance of cyclic rule triggerring? Means after a series of rule triggering and property value modification, the first rule may be triggered again. If there is some content modification (modification in the message body itself), then in that case, the complete message body has to be parsed again, to find out what new rules can match based on the current property values. Is this feasible? The original EPSF Internet Draft (draft-tomlinson-epsfw-00.txt), it says that the message parser SHOULD parse a message in a single parse.(Page 14). So, should we allow multiple passes of message parsing or is there any other way to do it in a single parse? A suggestion is that to have a field( or element) "Could Modify" in the rule which will tell which property values it MAY change. This may atleast tell which rules are mutually exclusive and won't need separate parsing of the message for those rules atleast. Does anybody have any suggestion for preventing cycles in rule triggering? Comments awaited. Thanks Shuvendu.. ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.in address at http://mail.yahoo.co.in From owner-ietf-openproxy Wed Nov 29 16:44:29 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20847 for ietf-openproxy-bks; Wed, 29 Nov 2000 16:44:29 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA20843 for ; Wed, 29 Nov 2000 16:44:28 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Nov 29 19:45:14 EST 2000 Received: from bell-labs.com (abeck-pcho [135.180.144.207]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA18457; Wed, 29 Nov 2000 19:45:13 -0500 (EST) Message-ID: <3A25A2B6.A1BE271E@bell-labs.com> Date: Wed, 29 Nov 2000 19:43:34 -0500 From: Andre Beck Organization: Bell Labs Research X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en-US,de,fr MIME-Version: 1.0 To: Shuvendu Dang CC: extproxy , Markus Hofmann Subject: Re: PSRL: A Rule Specification Language for Proxy Services References: <20001129090455.7884.qmail@web8001.mail.in.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Consider this case: based on some property values, > some rules are matching, say the first of such rules > is triggered. Now suppose the proxylet associated with > the triggered rule changes some of the property > values, which now match some other rules, so they may > be triggered. And this may go on. To check which new > rules are triggered the message (body and header) may > have to be parsed again.Isn't there a chance of cyclic > rule triggerring? Means after a series of rule > triggering and property value modification, the first > rule may be triggered again. All the rules in a rule module are processed in the order they are specified in the rule module. Each rule gets processed only once regardless of whether it matches or not. If a rule matches, the appropriate action is executed, but this particular rule or any other rules that have already been processed will not be processed again. This is why the rule ordering is so important. Cyclic rule triggering should therefore not be possible. > If there is some content modification (modification > in the message body itself), then in that case, the > complete message body has to be parsed again, to find > out what new rules can match based on the current > property values. Is this feasible? I agree that the approach to match rule properties against current property values is less efficient than to always match against the original value, but I don't think it's necessary to parse the message more than once, at least not for local proxylets that can use proxy library functions to modify certain property values. In the case of ICAP services, however, it will be necessary, to parse the ICAP response every time an ICAP transaction is performed. > A suggestion is that to have a field( or element) > "Could Modify" in the rule which will tell which > property values it MAY change. This may atleast tell > which rules are mutually exclusive and won't need > separate parsing of the message for those rules > atleast. This could improve the performance of the rule processing engine on the caching proxy, but on the other hand since rule authors may not be the identical with the authors of service code modules it may be difficult to always keep the rules consistent with the service modules. -Andre From owner-ietf-openproxy Wed Nov 29 22:24:31 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA01534 for ietf-openproxy-bks; Wed, 29 Nov 2000 22:24:31 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01530 for ; Wed, 29 Nov 2000 22:24:30 -0800 (PST) Received: from divyaroot.India.Sun.COM ([129.158.226.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA11399; Wed, 29 Nov 2000 22:25:58 -0800 (PST) Received: from peak (peak [129.158.226.240]) by divyaroot.India.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.0) with SMTP id LAA02139; Thu, 30 Nov 2000 11:55:56 +0530 (IST) Message-Id: <200011300625.LAA02139@divyaroot.India.Sun.COM> Date: Thu, 30 Nov 2000 11:54:00 +0800 (SGT) From: Sherif Kottapurath Reply-To: Sherif Kottapurath Subject: Re: PSRL: A Rule Specification Language for Proxy Services To: shuvendudang@yahoo.co.in, abeck@bell-labs.com Cc: ietf-openproxy@imc.org, hofmann@bell-labs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iFZdIf2B7Dms2jeAMmsbsA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Date: Wed, 29 Nov 2000 19:43:34 -0500 >From: Andre Beck >> Consider this case: based on some property values, >> some rules are matching, say the first of such rules >> is triggered. Now suppose the proxylet associated with >> the triggered rule changes some of the property >> values, which now match some other rules, so they may >> be triggered. And this may go on. To check which new >> rules are triggered the message (body and header) may >> have to be parsed again.Isn't there a chance of cyclic >> rule triggerring? Means after a series of rule >> triggering and property value modification, the first >> rule may be triggered again. > >All the rules in a rule module are processed in the order they are >specified in the rule module. Each rule gets processed only once >regardless of whether it matches or not. If a rule matches, the >appropriate action is executed, but this particular rule or any other >rules that have already been processed will not be processed again. This >is why the rule ordering is so important. Cyclic rule triggering should >therefore not be possible. > >> If there is some content modification (modification >> in the message body itself), then in that case, the >> complete message body has to be parsed again, to find >> out what new rules can match based on the current >> property values. Is this feasible? > >I agree that the approach to match rule properties against current >property values is less efficient than to always match against the >original value, but I don't think it's necessary to parse the message >more than once, at least not for local proxylets that can use proxy >library functions to modify certain property values. It may not be possible (or advisable) to avoid parsing the message more than once if we allow rule match against current property values. It can be cumbersome when content modification is allowed, but no doubt can be done more efficiently if we allow local proxylets to modify contents only through library calls. > In the case of ICAP >services, however, it will be necessary, to parse the ICAP response >every time an ICAP transaction is performed. > >> A suggestion is that to have a field( or element) >> "Could Modify" in the rule which will tell which >> property values it MAY change. This may atleast tell >> which rules are mutually exclusive and won't need >> separate parsing of the message for those rules >> atleast. > >This could improve the performance of the rule processing engine on the >caching proxy, but on the other hand since rule authors may not be the >identical with the authors of service code modules it may be difficult >to always keep the rules consistent with the service modules. > We could have the "could-modify", "could-add" kind of properties be associated with the service module. This would help the rule authors understand better what they may be getting into and will also help the performance of the rule processing engine. If we can have ICAP services return (optionally) a "have-modified" header as the first header, that would also improve the rule processing tremendously. (This header would need to be stripped off by the proxy and hence should be sent only if the proxy has indicated that it can handle it) Sherif >-Andre > From owner-ietf-openproxy Fri Dec 1 07:28:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA01903 for ietf-openproxy-bks; Fri, 1 Dec 2000 07:28:25 -0800 (PST) Received: from hplb.hpl.hp.com (hplb-temp.hpl.hp.com [192.6.10.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01896 for ; Fri, 1 Dec 2000 07:28:23 -0800 (PST) Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id PAA16017; Fri, 1 Dec 2000 15:29:53 GMT Received: from hplb.hpl.hp.com (dhcp-91-6.hpl.hp.com [15.144.91.6]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA15081; Fri, 1 Dec 2000 15:29:51 GMT Message-ID: <3A27C3EF.312206BD@hplb.hpl.hp.com> Date: Fri, 01 Dec 2000 15:29:51 +0000 From: Dave Reynolds Organization: Hewlett-Packard Laboratories X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Markus Hofmann CC: ietf-openproxy@imc.org Subject: Re: FW: I-D ACTION:draft-beck-opes-psrl-00.txt References: <007301c0568c$c304b650$44510d18@gemini> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > attached announcement is for an I-D that (hopefully) is of interest to > the OPES group. Very interesting. Some questions (which probably just reflect my lack of understanding): 1. What is the motivation for the ordering rules in section 4? It seems to me that there may be different business arrangements which lead to different choices of which rule module owner takes precedence. For example, ad insertion on behalf of access providers, ad insertion on behalf of content providers and ad removal on behalf of clients all conflict and the resolution depends on local context like funding models, not on a globally fixed order. I can also imagine cases where interleaving the rules between different (cooperating) module owners might be useful but perhaps the complexity rules this out. [BTW there may be a trivial typo here, I suspect the request points are mis-numbered in either para2 or para4 of this section.]. 2. A possible extension to the property naming rules (section 3.5.2) would be to allow inter-proxylet communication by allowing one proxylet to add property annotations to the message which can trigger later proxylets. For example, I may have a proxylet which checks the P3P policy of the site to generate an "acceptable-privacy-policy" annotation which in turn might trigger later proxylets. This could be achieved by lifting the restriction that property names be limited to actual protocol headers (plus the six extension properties). 3. For the property value matching would it be appropriate to add an additional attribute to the "property" element to control case-sensitivity of the matching? 4. Is there a proposed namespace URI for this element set? Dave Reynolds ------------------------------------------------------------------ Hewlett-Packard Laboratories | Phone: +44-117-3128165 Filton Road, Stoke Gifford | FAX: +44-117-3128925 Bristol BS34 8QZ, UK | dave_reynolds@hpl.hp.com From owner-ietf-openproxy Fri Dec 1 08:50:21 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA09706 for ietf-openproxy-bks; Fri, 1 Dec 2000 08:50:21 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA09701 for ; Fri, 1 Dec 2000 08:50:20 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Fri Dec 1 11:51:15 EST 2000 Received: from bell-labs.com (apache [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA20143; Fri, 1 Dec 2000 11:51:15 -0500 (EST) Message-ID: <3A27D703.C31FCC8B@bell-labs.com> Date: Fri, 01 Dec 2000 11:51:15 -0500 From: Markus Hofmann Organization: Bell Labs Research, USA X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,de-DE MIME-Version: 1.0 To: Dave Reynolds CC: ietf-openproxy@imc.org, Markus Hofmann Subject: Re: FW: I-D ACTION:draft-beck-opes-psrl-00.txt References: <007301c0568c$c304b650$44510d18@gemini> <3A27C3EF.312206BD@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave, > 1. What is the motivation for the ordering rules in section 4? It > seems to me that there may be different business arrangements which > lead to different choices of which rule module owner takes > precedence. For example, ad insertion on behalf of access providers, > ad insertion on behalf of content providers and ad removal on > behalf of clients all conflict and the resolution depends on local > context like funding models, not on a globally fixed order. I basically agree with you that the order might depend on business arrangements - we also discussed this a lot when writing the draft. Imagine, for example, that a content provider defines a rule module to insert ads into its pages and that a client defines a rule module to remove all ads from all pages. One might argue, now, that the execution order of the rules depends on the business arrangements (basically, who pays more - the content provider or the client :). However, even if the ad insertion for the content provider is executed last and, therefore, ads are inserted despite the client rule, the client could still remove the ads on its local machine by using a local tool. In this case, there's no motivation for the client to use the edge service provided by its service provider. Basically, the client always has "the last word", because it could run all the services also on its local machine, without giving the content provider any chance to have impact. Similar for content provider/service provider relationship. This, in some sense, was the motivation for the ordering we outlined in section 4 - following the "natural" message flow. Certainly an issue to discuss... > I can also imagine cases where interleaving the rules between > different (cooperating) module owners might be useful but perhaps > the complexity rules this out. Interleaving rules might be used for optimization, but our feeling is that the benefits we could get out of it would not justify the added complexity. > [BTW there may be a trivial typo here, I suspect the request points > are mis-numbered in either para2 or para4 of this section.]. You're right, the error is in para4. We'll fix that in the next version. Thanks! > 2. A possible extension to the property naming rules (section 3.5.2) > would be to allow inter-proxylet communication by allowing one > proxylet to add property annotations to the message which can > trigger later proxylets. For example, I may have a proxylet which > checks the P3P policy of the site to generate an > "acceptable-privacy-policy" annotation which in turn might > trigger later proxylets. This could be achieved by lifting the > restriction that property names be limited to actual protocol > headers (plus the six extension properties). Agreed. We probably should relax the restriction and should allow additional property names. This can probably be included without major changes to the draft. > 3. For the property value matching would it be appropriate to add an > additional attribute to the "property" element to control > case-sensitivity of the matching? Hm, I'd rather prefer to stay case-insensitive per default. Just for simplicity. > 4. Is there a proposed namespace URI for this element set? No, not yet, but his should probably be done later. -Markus From owner-ietf-openproxy Fri Dec 1 08:59:11 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA10116 for ietf-openproxy-bks; Fri, 1 Dec 2000 08:59:11 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA10110 for ; Fri, 1 Dec 2000 08:59:10 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Dec 1 11:59:29 EST 2000 Received: from bell-labs.com (abeck-pcho [135.180.144.207]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA20857; Fri, 1 Dec 2000 12:00:19 -0500 (EST) Message-ID: <3A27D8B0.36E024E0@bell-labs.com> Date: Fri, 01 Dec 2000 11:58:24 -0500 From: Andre Beck Organization: Bell Labs Research X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en-US,de,fr MIME-Version: 1.0 To: Dave Reynolds CC: Markus Hofmann , ietf-openproxy@imc.org Subject: Re: FW: I-D ACTION:draft-beck-opes-psrl-00.txt References: <007301c0568c$c304b650$44510d18@gemini> <3A27C3EF.312206BD@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dave Reynolds wrote: > 1. What is the motivation for the ordering rules in section 4? It seems to > me that there may be different business arrangements which lead to different > choices of which rule module owner takes precedence. For example, ad > insertion on behalf of access providers, ad insertion on behalf of content > providers and ad removal on behalf of clients all conflict and the > resolution depends on local context like funding models, not on a globally > fixed order. Well, I think I have to disagree here. The client should always be able to have the last word on any modifications he would like to make to the requested page. In fact, the order we suggested in our draft merely reflects the order of the traditional approach (no service-enabled caching proxy involved): A content provider inserts ads at the origin server and the client uses a program like WebWasher on his local machine to remove the ads. The proxylet approach simply moves these two services to a single point in the middle, namely the caching proxy, but the order in which the different parties can modify messages at this point should be the same as in the traditional approach. > I can also imagine cases where interleaving the rules between different > (cooperating) module owners might be useful but perhaps the complexity rules > this out. Can you give an example where this would make sense? > [BTW there may be a trivial typo here, I suspect the request points are > mis-numbered in either para2 or para4 of this section.]. You are right. For processing points 1 and 2 the rule module order should be Client/Access Provider/Content Provider and for processing points 3 and 4 the order should be Content Provider/Access Provider/Client. > 2. A possible extension to the property naming rules (section 3.5.2) would > be to allow inter-proxylet communication by allowing one proxylet to add > property annotations to the message which can trigger later proxylets. For > example, I may have a proxylet which checks the P3P policy of the site to > generate an "acceptable-privacy-policy" annotation which in turn might > trigger later proxylets. This could be achieved by lifting the restriction > that property names be limited to actual protocol headers (plus the six > extension properties). I agree. We should not restrict properties to actual protocol headers, but instead allow both protocol and user-defined headers plus the six extension headers (as long as there is no conflict). Since proxylets may also add (or delete) headers to a message (for instance at point 1), this should also allow for some sort of inter-proxylet communication. > 3. For the property value matching would it be appropriate to add an > additional attribute to the "property" element to control case-sensitivity > of the matching? That's a good idea. > 4. Is there a proposed namespace URI for this element set? Not yet, but there probably will be some time in the future. -Andre From owner-ietf-openproxy Fri Dec 1 15:14:59 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA04061 for ietf-openproxy-bks; Fri, 1 Dec 2000 15:14:59 -0800 (PST) Received: from lecs.cs.ucla.edu (IDENT:root@Lecs.CS.UCLA.EDU [131.179.144.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04055 for ; Fri, 1 Dec 2000 15:14:55 -0800 (PST) Received: from concorde.cs.ucla.edu (concorde.cs.ucla.edu [131.179.144.102]) by lecs.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id PAA05105 for ; Fri, 1 Dec 2000 15:16:20 -0800 Received: from concorde.cs.ucla.edu (localhost [127.0.0.1]) by concorde.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id PAA22012 for ; Fri, 1 Dec 2000 15:16:20 -0800 Message-Id: <200012012316.PAA22012@concorde.cs.ucla.edu> From: Jeremy Elson To: ietf-openproxy@imc.org Subject: ICAP's new port number is... Date: Fri, 01 Dec 2000 15:16:20 -0800 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 1344 -Jer ------- Forwarded Message Return-Path: iana@ISI.EDU Delivery-Date: Fri Dec 1 14:40:42 2000 Return-Path: Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lecs.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id OAA04762 for ; Fri, 1 Dec 2000 14:40:42 -0800 Received: from icann1 (icann1.isi.edu [128.9.160.34]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id OAA02314 for ; Fri, 1 Dec 2000 14:40:41 -0800 (PST) Reply-To: From: "IANA" To: Subject: RE: Application for port-number (1344) Date: Fri, 1 Dec 2000 14:46:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200011130703.XAA07353@smo-www-01.icann.org> Importance: Normal Dear Jeremy, We have assigned the following user port number with you as the point of contact: icap 1344/tcp ICAP icap 1344/udp ICAP # Jeremy Elson Please notify the IANA if there is a change in contact information. Thank you, Michelle Schipper IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 x12 FAX: (310) 823-8649 email: iana@iana.org *************************************************************** ------- End of Forwarded Message From owner-ietf-openproxy Sat Dec 2 19:03:08 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA04226 for ietf-openproxy-bks; Sat, 2 Dec 2000 19:03:08 -0800 (PST) Received: from deborah.paradise.net.nz (deborah.paradise.net.nz [203.96.152.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA04222 for ; Sat, 2 Dec 2000 19:03:02 -0800 (PST) From: Nick.Taptiklis@gregory.co.nz Received: from gregory-gmr1u7w (203-79-82-85.adsl-wns.paradise.net.nz [203.79.82.85]) by deborah.paradise.net.nz (8.10.1/8.10.1) with ESMTP id eB334ZS02489 for ; Sun, 3 Dec 2000 16:04:37 +1300 (NZDT) To: Cc: Subject: Re: Modified Example Services Draft X-Mailer: Lotus Notes Release 5.0 (Intl) 30 March 1999 Message-ID: Date: Sun, 03 Dec 2000 03:07:34 GMT X-Priority: 3 (Normal) X-MIMETrack: Serialize by Notes Client on Nick Taptiklis/RHE(Release 5.0 (Intl)|30 March 1999) at 03/12/2000 16:07:34 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_mixed 00112A5FCC2569AA_=" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=_mixed 00112A5FCC2569AA_= Content-Type: text/plain; charset="us-ascii" Hi, How about disability-related services such as web-page color substitution for the color-blind, and perhaps even html to streaming audio translation for the blind? Cheers, Nick Taptiklis "Markus Hofmann" Sent by: owner-ietf-openproxy@mail.imc.org 28/11/2000 07:18 To: cc: Subject: Modified Example Services Draft Hi, attached a slightly modified version of the Example Services draft. We've submitted the modified version, but it will probably not be published in time for San Diego. As usual - comments welcome! -Markus --=_mixed 00112A5FCC2569AA_= Content-Type: text/plain; name="draft-beck-opes-esfnep-01.txt" Content-Disposition: attachment; filename="draft-beck-opes-esfnep-01.txt" Content-Transfer-Encoding: base64 DQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQS4gQmVjayANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBNLiBIb2ZtYW5uIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEx1Y2VudCBUZWNobm9sb2dpZXMgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE0uIENvbmRyeSANCkV4cGlyZXM6IE1heSAyMDAxICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEludGVsIENvcnBvcmF0aW9uIA0KRG9jdW1lbnQ6IGRyYWZ0LWJlY2stb3Blcy1l c2ZuZXAtMDEudHh0ICAgICAgICAgICAgICAgTm92ZW1iZXIgMjEsIDIwMDAgDQpDYXRlZ29yeTog SW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiANCiANCiAgICANCiAgICAgICAgICAgICAgIEV4YW1wbGUgU2VydmljZXMgZm9yIE5l dHdvcmsgRWRnZSBQcm94aWVzIA0KICAgIA0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCiANCiAgIFRo aXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFu Y2Ugd2l0aCANCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNiBbMV0u IA0KICAgIA0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmcgDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBh bmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgDQogICBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4g DQogICAgDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCANCiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIA0KICAgYXQgYW55IHRpbWUuIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgDQogICBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i IA0KICAgIA0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0IA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0 IA0KICAgIA0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVz IGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwu IA0KIA0KICAgIA0KVGFibGUgb2YgQ29udGVudHMgDQogICAgDQogICAxICBJbnRyb2R1Y3Rpb24u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAg MiAgVmlydXMgU2Nhbm5pbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMyANCiAgIDIuMSAgQWJzdHJhY3QuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMgDQogICAyLjIgIEJ1c2luZXNzIG1vZGVsLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIA0KICAgMi4zICBUZWNo bmljYWwgQ2hhbGxlbmdlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u NCANCiAgIDMgIEluc2VydGlvbiBvZiBBZCBCYW5uZXJzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjQgDQogICAzLjEgIEFic3RyYWN0Li4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0KICAgMy4yICBCdXNpbmVzcyBtb2Rl bC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNCANCiAgIDMu MyAgVGVjaG5pY2FsIENoYWxsZW5nZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjQgDQogICA0ICBJbnNlcnRpb24gb2YgUmVnaW9uYWwgRGF0YS4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi41IA0KICAgNC4xICBBYnN0cmFjdC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgIDQuMiAgQnVzaW5l c3MgbW9kZWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUg DQogICA0LjMgIFRlY2huaWNhbCBDaGFsbGVuZ2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi42IA0KICAgNSAgQ2FjaGluZyBvZiBQZXJzb25hbGl6ZWQvQ3VzdG9taXpl ZCBXZWIgUGFnZXMuLi4uLi4uLi4uLi4uLi4uLi4uNiANCiAgIDUuMSAgQWJzdHJhY3QuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA1LjIg IEJ1c2luZXNzIE1vZGVsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi42IA0KICAgNS4zICBUZWNobmljYWwgQ2hhbGxlbmdlcy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uNiANCiAgIDYgIENvbnRlbnQgQWRhcHRhdGlvbiBmb3IgQWx0 ZXJuYXRlIFdlYiBBY2Nlc3MgRGV2aWNlcy4uLi4uLi4uLi4uLjYgDQogIA0KQmVjayBldCBhbC4g ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjAwMSAgICAgICAgICAgICAgICAgICAgICAgICAg MSANCgwNCiAgICAgICAgICAgRXhhbXBsZSBTZXJ2aWNlcyBmb3IgTmV0d29yayBFZGdlIFByb3hp ZXMgICAgICAgTm92ZW1iZXIgMjAwMCANCg0KICAgNi4xICBBYnN0cmFjdC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAgIDYuMiAgQnVzaW5l c3MgbW9kZWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcg DQogICA2LjMgIFRlY2huaWNhbCBDaGFsbGVuZ2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi43IA0KICAgNyAgTGltaXRlZCBDbGllbnQgQmFuZHdpZHRoIEFkYXB0YXRp b24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOCANCiAgIDcuMSAgQWJzdHJhY3QuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICA3LjIg IEJ1c2luZXNzIG1vZGVsLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi44IA0KICAgNy4zICBUZWNobmljYWwgQ2hhbGxlbmdlcy4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgIDggIEFkYXB0YXRpb24gb2YgU3RyZWFtaW5nIE1l ZGlhLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkgDQogICA4LjEgIEFic3RyYWN0 Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0K ICAgOC4yICBCdXNpbmVzcyBtb2RlbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uOSANCiAgIDguMyAgVGVjaG5pY2FsIENoYWxsZW5nZXMuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkgDQogICA5ICBSZXF1ZXN0IEZpbHRlcmluZy4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgOS4xICBB YnN0cmFjdC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4xMCANCiAgIDkuMiAgQnVzaW5lc3MgbW9kZWwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTAgDQogICA5LjMgIFRlY2huaWNhbCBDaGFsbGVuZ2VzLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0KICAgMTAgUmVxdWVzdCBGaWx0 ZXJpbmcgdGhyb3VnaCBDb250ZW50IEFuYWx5c2lzLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCANCiAg IDEwLjEgIEFic3RyYWN0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTAgDQogICAxMC4yICBCdXNpbmVzcyBtb2RlbC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjExIA0KICAgMTAuMyAgVGVjaG5pY2FsIENoYWxsZW5n ZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgIDExIENyZWF0 aW9uIG9mIFVzZXIgUHJvZmlsZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTEgDQogICAxMS4xICBBYnN0cmFjdC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjExIA0KICAgMTEuMiAgQnVzaW5lc3MgbW9kZWwuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgIDExLjMgIFRlY2huaWNhbCBD aGFsbGVuZ2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTIgDQogICAx MiBTZWFyY2ggRW5naW5lIEluZGV4IG9uIENhY2hlZCBXZWIgUGFnZXMuLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjEyIA0KICAgMTIuMSAgQWJzdHJhY3QuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMiANCiAgIDEyLjIgIEJ1c2luZXNzIG1vZGVsLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTIgDQogICAxMi4zICBUZWNo bmljYWwgQ2hhbGxlbmdlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEz IA0KICAgMTMgTGFuZ3VhZ2UgVHJhbnNsYXRpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4xMyANCiAgIDEzLjEgIEFic3RyYWN0Li4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMgDQogICAxMy4yICBCdXNpbmVzcyBtb2Rl bC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEzIA0KICAgMTMu MyAgVGVjaG5pY2FsIENoYWxsZW5nZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4xMyANCiAgIDE0IEF1dGhvcidzIEFkZHJlc3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDQogICAxNSBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE1IA0KICAgIA0KIA0KIA0KIA0K DQoxICBJbnRyb2R1Y3Rpb24gDQoNCiAgICANCiAgIFRoZSByYXBpZCBncm93dGggb2YgdGhlIElu dGVybmV0IGFuZCB0aGUgaW5jcmVhc2luZyBudW1iZXIgb2YgDQogICBJbnRlcm5ldCB1c2VycyBo YXZlIHJlc3VsdGVkIGluIG1hbnkgc2NhbGluZyBhbmQgZ3Jvd3RoIHByb2JsZW1zIA0KICAgd2l0 aCBhcHBsaWNhdGlvbiBkZXNpZ25zIGZvY3VzZWQgb24gb3BlcmF0aW9ucyBhdCB0aGUgZW5kcyAo aS5lLiB0aGUgDQogICBjbGllbnQgb3IgdGhlIHNlcnZlcikuIFRoaXMgaGFzIGxlZCB0byBhIHdp ZGUgZGVwbG95bWVudCBvZiBuZXR3b3JrIA0KICAgZWRnZSBjYWNoaW5nIHByb3hpZXMgYXMgYSBr ZXkgc3RyYXRlZ3kgdG8gYWRkcmVzcyB0aGVzZSBwcm9ibGVtcy4gDQogICBUaGVzZSBzeXN0ZW1z IGhhdmUgYmVlbiB2ZXJ5IHN1Y2Nlc3NmdWwgaW4gYWNjZWxlcmF0aW5nIFdlYiBjb250ZW50IA0K ICAgZGVsaXZlcnkgYW5kIHJlZHVjaW5nIHRoZSBsb2FkIG9uIG9yaWdpbiBXZWIgc2VydmVycy4g IA0KICAgIA0KICAgSG93ZXZlciwgdGhlIHNwZWNpZmljIHJvbGUgb2YgdGhlc2UgbmV0d29yayBl ZGdlIGNhY2hpbmcgcHJveGllcyBhcyANCiAgIGEgZ2F0ZXdheSBiZXR3ZWVuIFdlYiB1c2VycyBh bmQgY29udGVudCBwcm92aWRlcnMgc3VnZ2VzdHMgdXRpbGl6aW5nIA0KICAgdGhlbSBmb3IgaW50 ZWxsaWdlbnQgc2VydmljZXMgYmV5b25kIHNpbXBsZSBjYWNoaW5nLiANCiAgICANCiAgIFRoZXJl IGFyZSBhbHJlYWR5IGEgdmFyaWV0eSBvZiBleGlzdGluZyBvciBwcm9wb3NlZCBhcHByb2FjaGVz IHRoYXQgDQogICBpbXBsZW1lbnQgcGFydGljdWxhciBzZXJ2aWNlcyBvbiB0b3Agb2YgYSBwcm94 eSBwbGF0Zm9ybS4gSUNBUCBbNV0gDQoNCiAgDQpCZWNrIGV0IGFsLiAgICAgICAgICAgICAgICBF eHBpcmVzIE1heSAyMDAxICAgICAgICAgICAgICAgICAgICAgICAgICAyIA0KDA0KICAgICAgICAg ICBFeGFtcGxlIFNlcnZpY2VzIGZvciBOZXR3b3JrIEVkZ2UgUHJveGllcyAgICAgICBOb3ZlbWJl ciAyMDAwIA0KDQogICBleHRlbmRzIHRoZSBiYXNpYyBpZGVhIG9mIGltcGxlbWVudGluZyB2YWx1 ZS1hZGRlZCBzZXJ2aWNlcyBvbiANCiAgIHByb3hpZXMgYnkgaGFuZGxpbmcgdHJhbnNwb3J0IG9m IHdlYiBvYmplY3RzIGJldHdlZW4gcHJveGllcyBhbmQgDQogICBjb250ZW50IG1vZGlmaWNhdGlv biBzZXJ2ZXJzLCB0aHVzLCBlbmFibGluZyByZW1vdGUgY2FsbCBvdXQgDQogICBtZWNoYW5pc21z LiBFUFNGVyBbMiwgN10gZGVzY3JpYmVzIGFuIGV4dGVuZGVkIGZyYW1ld29yayB0byBwcm92aWRl IA0KICAgZ2VuZXJhbCBzZXJ2aWNlcyBvbiB0b3Agb2YgYW4gb3BlbiBwcm94eSBwbGF0Zm9ybS4g DQogICAgDQogICBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBzZXZlcmFsIHNlcnZpY2UgZXhhbXBs ZXMgcG9zc2libHkgYmVpbmcgDQogICBpbXBsZW1lbnRlZCBvbiB0b3Agb2YgYW4gb3BlbiBwcm94 eSBwbGF0Zm9ybSBhcyBkZXNjcmliZWQgaW4gWzIsIDddLiANCiAgIEVhY2ggb2YgdGhlIGZvbGxv d2luZyBzZXJ2aWNlIGRlc2NyaXB0aW9uIGNvbnNpc3RzIG9mIHRocmVlIA0KICAgc3Vic2VjdGlv bnM6IGEgc2hvcnQgYWJzdHJhY3QgdGhhdCBkZXNjcmliZXMgdGhlIHNlcnZpY2UgaWRlYSwgYSAN CiAgIGRlc2NyaXB0aW9uIG9mIHRoZSB1bmRlcmx5aW5nIGJ1c2luZXNzIG1vZGVsLCBhbmQgZmlu YWxseSBhIHNlY3Rpb24gDQogICB0aGF0IG1lbnRpb25zIHRlY2huaWNhbCBjaGFsbGVuZ2VzIHRv IGJlIGFkZHJlc3NlZCB3aGVuIGltcGxlbWVudGluZyANCiAgIHRoZXNlIHNlcnZpY2VzLiANCiAg ICANCiAgIFNlY3Rpb24gMiBkZXNjcmliZXMgdmlydXMgc2Nhbm5pbmcgYXMgYW4gZXhhbXBsZSBz ZXJ2aWNlLCB3aGljaCANCiAgIGN1cnJlbnRseSBpcyBvbmUgb2YgdGhlIG1vc3QgZnJlcXVlbnRs eSBjaXRlZCBzZXJ2aWNlIGlkZWFzLiBTZWN0aW9uIA0KICAgMywgNCwgYW5kIDUgZGVzY3JpYmUg c2VydmljZXMgdGhhdCBkeW5hbWljYWxseSBhc3NlbWJsZSBwZXJzb25hbGl6ZWQgDQogICBjb250 ZW50LiBUaGVzZSBzZXJ2aWNlcyBleGhpYml0IHRoZSB1c2Ugb2YgdGhlIHByb3h5IGRldmljZSBt YW5hZ2luZyANCiAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjbGllbnQuIFNlY3Rpb25zIDYgYW5k IDcgcHJlc2VudCBzZXJ2aWNlcyB0aGF0IA0KICAgYWRhcHQgY29udGVudCB0byB0aGUgY2FwYWJp bGl0eSBvZiBjbGllbnQgZGV2aWNlcyBhbmQgY2xpZW50IGFjY2VzcyANCiAgIGJhbmR3aWR0aC4g U29tZSBvZiB0aGUgcHJldmlvdXMgc2VydmljZSBpZGVhcyBjYW4gYWxzbyBiZSBhcHBsaWVkIHRv IA0KICAgc3RyZWFtaW5nIG1lZGlhLCB3aGljaCBpcyBkaXNjdXNzZWQgaW4gU2VjdGlvbiA4LiBU aGUgc2VydmljZXMgZ2l2ZW4gDQogICBpbiBTZWN0aW9uIDksIDEwLCBhbmQgMTEgb3BlcmF0ZSBv biBjbGllbnQgcmVxdWVzdHMgcmF0aGVyIHRoYW4gb24gDQogICB0aGUgY29udGVudCBpdHNlbGYu IE1vcmUgc2VydmljZSBleGFtcGxlcyBhcmUgZ2l2ZW4gaW4gU2VjdGlvbnMgMTIgDQogICBhbmQg MTMuIA0KICAgIA0KDQoyICBWaXJ1cyBTY2FubmluZyANCg0KICAgIA0KDQogICAyLjEgQWJzdHJh Y3QgDQoNCiAgICANCiAgIFZpcnVzZXMsIFRyb2phbiBIb3JzZXMsIGFuZCB3b3JtcyBoYXZlIGFs d2F5cyBwb3NlZCBhIHRocmVhdCB0byANCiAgIEludGVybmV0IHVzZXJzLiBKdXN0IHJlY2VudGx5 IHdlIGhhdmUgc2VlbiBhIG51bWJlciBvZiBlLW1haWwgYmFzZWQgDQogICB3b3JtcyB0aGF0IGhh dmUgaGl0IG1pbGxpb25zIG9mIEludGVybmV0IHVzZXJzIHdvcmxkd2lkZSB3aXRoaW4gYSANCiAg IGZldyBob3Vycy4gIA0KICAgIA0KICAgV2l0aCB0aGUgaGVscCBvZiBhIGNvbnRlbnQgc2Nhbm5p bmcgYW5kIGZpbHRlcmluZyBzeXN0ZW0gYXQgdGhlIA0KICAgY2FjaGluZyBwcm94eSBsZXZlbCwg V2ViIHBhZ2VzIGFuZCBhbHNvIGZpbGUgdHJhbnNmZXJzIGNvdWxkIGJlIA0KICAgc2Nhbm5lZCBm b3IgbWFsaWNpb3VzIGNvbnRlbnQgcHJpb3IgdG8gc2VuZGluZyB0aGVtIHRvIHRoZSB1c2VyLiBJ biANCiAgIFdlYiBwYWdlcyBhY3RpdmUgY29udGVudCBsaWtlIEFjdGl2ZVgsIEphdmEgYW5kIEph dmFTY3JpcHQgY291bGQgYmUgDQogICBzY2FubmVkIGZvciBoYXJtZnVsIGNvZGUgKGUuZy4gY29k ZSBleHBsb2l0aW5nIHNlY3VyaXR5IGhvbGVzKS4gRmlsZSANCiAgIHRyYW5zZmVycyBjb3VsZCBi ZSBzY2FubmVkIGZvciBrbm93biB2aXJ1c2VzLiBJZiBhIHZpcnVzIGlzIGZvdW5kLCANCiAgIHRo ZSBhZGFwdGF0aW9uIHNlcnZlciBjb3VsZCB0cnkgdG8gcmVtb3ZlIGl0IG9yIGRlbnkgdGhlIGRl bGl2ZXJ5IG9mIA0KICAgdGhlIGluZmVjdGVkIGNvbnRlbnQuIEEgZ2VuZXJhbCBydWxlIGNvdWxk IGJlIHRoYXQgdGhlIGNhY2hpbmcgcHJveHkgDQogICBtYXkgc3RvcmUgYW5kL29yIGRlbGl2ZXIg Y29udGVudCBvbmx5LCBpZiBpdCBoYXMgYmVlbiBzY2FubmVkIGJ5IHRoZSANCiAgIGNvbnRlbnQg YWRhcHRhdGlvbiBzZXJ2ZXIgYW5kIG5vIHZpcnVzZXMgYXJlIGZvdW5kLiAgDQogICAgDQoNCiAg IDIuMiBCdXNpbmVzcyBtb2RlbCANCg0KICAgIA0KICAgVGhpcyBzZXJ2aWNlIGNvdWxkIGJlIG9m ZmVyZWQgYXMgYW4gYWRkaXRpb25hbCBmZWF0dXJlIHRvIElTUCANCiAgIGN1c3RvbWVycyB3aG8g YXJlIGNvbmNlcm5lZCBhYm91dCBzZWN1cml0eSBpc3N1ZXMuIExpa2V3aXNlIA0KICAgZW50ZXJw cmlzZXMgY291bGQgYmUgaW50ZXJlc3RlZCBpbiB0aGlzIHNvbHV0aW9uIHRvIHByZXZlbnQgYW55 IA0KICAgbWFsaWNpb3VzIGNvbnRlbnQgZnJvbSBlbnRlcmluZyB0aGUgY29tcGFueSBuZXR3b3Jr LiANCiAgICANCg0KICANCkJlY2sgZXQgYWwuICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIw MDEgICAgICAgICAgICAgICAgICAgICAgICAgIDMgDQoMDQogICAgICAgICAgIEV4YW1wbGUgU2Vy dmljZXMgZm9yIE5ldHdvcmsgRWRnZSBQcm94aWVzICAgICAgIE5vdmVtYmVyIDIwMDAgDQoNCg0K ICAgMi4zIFRlY2huaWNhbCBDaGFsbGVuZ2VzIA0KDQogICAgDQogICBXZWIgcGFnZXMvZmlsZXMg c2hvdWxkIGJlIHNjYW5uZWQgZm9yIHZpcnVzZXMgYnkgc2VuZGluZyB0aGVtIHRvIGEgDQogICBz ZXBhcmF0ZSBzZXJ2ZXIgd2hlcmUgdmlydXMtc2Nhbm5pbmcgc29mdHdhcmUgd291bGQgYW5hbHl6 ZSB0aGVtLiANCiAgIElDQVAgWzVdIGlzIGFuIGV4YW1wbGUgcHJvdG9jb2wgZm9yIHRoaXMgcHVy cG9zZS4gVGhlIHZpcnVzIHNjYW5uaW5nIA0KICAgb3BlcmF0aW9ucyBzaG91bGQgbm90IGJlIHBl cmZvcm1lZCBvbiB0aGUgY2FjaGluZyBwcm94eSBhcyB0aGV5IHdpbGwgDQogICBwcm9iYWJseSBh ZmZlY3QgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBjYWNoaW5nIHByb3h5LiANCiAgICANCiAgIElm IEhUVFAgZmlsZSB0cmFuc2ZlcnMgYXJlIHRvIGJlIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIHRo ZSANCiAgIHJlcXVlc3RlZCBmaWxlIGNhbm5vdCBiZSBmb3VuZCBpbiB0aGUgY2FjaGUsIHdlIGhh dmUgdG8gdXNlIGEgDQogICBkaWZmZXJlbnQgYXBwcm9hY2ggdGhhbiBmb3IgV2ViIHBhZ2VzLiBJ dCB3b3VsZCBub3QgYmUgZmVhc2libGUgaWYgDQogICB0aGUgcHJveHkgd2FpdGVkIGZvciB0aGUg cmVxdWVzdGVkIGZpbGUgdG8gYmUgcmVjZWl2ZWQgY29tcGxldGVseSANCiAgIGJlZm9yZSBzZW5k aW5nIGl0IG92ZXIgdG8gdGhlIGNvbnRlbnQgYWRhcHRhdGlvbiBzZXJ2ZXIgZm9yIHRoZSANCiAg IHZpcnVzIHNjYW4uIFRoaXMgYXBwcm9hY2ggd291bGQgbGVhZCB0byBhIGxvbmcgZGVsYXkgYXQg dGhlIHVzZXKScyANCiAgIGVuZCwgd2hpY2ggaXMgbm90IGFjY2VwdGFibGUuIEluc3RlYWQsIHdl IHdvdWxkIGhhdmUgdG8gc2NhbiB0aGUgDQogICBmaWxlIHRyYW5zZmVyIGNvbnRpbnVvdXNseSwg YXMgaXQgaXMgYmVpbmcgc2VudCB0byB0aGUgdXNlciAoc2ltaWxhciANCiAgIHRvIHN0cmVhbWlu ZyBtZWRpYSkuIA0KICAgIA0KICAgIA0KDQozICBJbnNlcnRpb24gb2YgQWQgQmFubmVycyAgDQoN CiAgICANCg0KICAgMy4xIEFic3RyYWN0IA0KDQogICAgDQogICBNYW55IEludGVybmV0IGNvbXBh bmllcyByZWx5IGhlYXZpbHkgb24gcmV2ZW51ZSBtYWRlIGJ5IHNlbGxpbmcgDQogICBhZHZlcnRp c2VtZW50IHNwYWNlIG9uIHRoZWlyIFdlYiBwYWdlcy4gV2hlbmV2ZXIgYWR2ZXJ0aXNlbWVudCAN CiAgIGJhbm5lcnMgYXJlIGluc2VydGVkIGR5bmFtaWNhbGx5IGRlcGVuZGluZyBvbiB3aG8gcmVx dWVzdHMgdGhlIHBhZ2UsIA0KICAgdGhleSBjYW5ub3QgYmUgY2FjaGVkLCBldmVuIHdoZW4gdGhl IGNvbnRlbnQgb2YgdGhlIHBhZ2UgaXRzZWxmIGlzIA0KICAgc3RhdGljLiBUaGlzIGJlaGF2aW9y IHByZXZlbnRzIFdlYiBwYWdlcyBmcm9tIGJlaW5nIGNhY2hlZCwgYWx0aG91Z2ggDQogICB0aGVp ciBzdGF0aWMgY29udGVudCB3b3VsZCBhbGxvdyBmb3IgaXQuIA0KICAgIA0KICAgVGhlcmVmb3Jl IGl0IHNlZW1zIHJlYXNvbmFibGUgdG8gY2FjaGUgdGhlIHN0YXRpYyBwYXJ0IG9mIHRob3NlIFdl YiANCiAgIHBhZ2VzIGF0IGEgY2FjaGluZyBwcm94eSBuZWFyIHRoZSBjbGllbnQgYW5kIHRvIGlu c2VydCBhZCBiYW5uZXJzIA0KICAgaW50byB0aGUgY2FjaGVkIFdlYiBwYWdlcyBiZWZvcmUgc2Vy dmluZyB0aGVtIHRvIHRoZSBjbGllbnQuICANCiAgICANCg0KICAgMy4yIEJ1c2luZXNzIG1vZGVs IA0KDQogICAgDQogICBUaGlzIHNlcnZpY2UgaXMgYSBzYWxlcyBpdGVtIHRvIEludGVybmV0IGFk dmVydGlzaW5nIG5ldHdvcmtzLiBUaGV5IA0KICAgb2J0YWluIGEgbWFya2V0IGZyb20gY3VzdG9t ZXJzIHdpc2hpbmcgYSBsb3cgY29zdCBuZXR3b3JrIGFjY2VzcyBpbiANCiAgIHJldHVybiBmb3Ig YWR2ZXJ0aXNpbmcuIFRoaXMgaXMgdGhlIGZyZWUgSVNQIG1hcmtldC4gQWxzbywgY29udGVudCAN CiAgIHByb3ZpZGVycyB3aG8gZG8gbm90IHdhbnQgdG8gb3V0c291cmNlIHRoZWlyIGFkIHNwYWNl IG1hbmFnZW1lbnQgYW5kIA0KICAgc2FsZXMgbWlnaHQgYmUgaW50ZXJlc3RlZCBpbiBwcm92aWRp bmcgYmFubmVyIGltYWdlcyBhbmQgaW5zZXJ0aW9uIA0KICAgcnVsZXMgdG8gcHJveGllcy9jb250 ZW50IGFkYXB0YXRpb24gc2VydmVycyB0byBhY2NlbGVyYXRlIHRoZSANCiAgIGRlbGl2ZXJ5IG9m IHRoZWlyIFdlYiBwYWdlcy4gDQogICAgDQogICBBbiBhZCBpbnNlcnRpb24gbW9kdWxlIGF0IHRo ZSBjYWNoaW5nIHByb3h5IG9mIHRoZSBGcmVlIElTUCBjb3VsZCANCiAgIGluc2VydCBhZCBiYW5u ZXJzIChpbiBhZGRpdGlvbiB0byBhbnkgYWQgYmFubmVycyBmcm9tIHRoZSBjb250ZW50IA0KICAg cHJvdmlkZXIpIGludG8gZXZlcnkgV2ViIHBhZ2UgcmVxdWVzdGVkIGJ5IGEgY3VzdG9tZXIuIFRo YXQgd2F5IHRoZSANCiAgIGN1c3RvbWVycyBvZiB0aGUgRnJlZSBJU1Agd2lsbCBub3QgaGF2ZSB0 byBpbnN0YWxsIGFueSBzcGVjaWFsIA0KICAgc29mdHdhcmUgaW4gb3JkZXIgdG8gdXNlIGl0cyBz ZXJ2aWNlLiANCiAgICANCg0KICAgMy4zIFRlY2huaWNhbCBDaGFsbGVuZ2VzIA0KDQogICAgDQoN Cg0KICANCkJlY2sgZXQgYWwuICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwMDEgICAgICAg ICAgICAgICAgICAgICAgICAgIDQgDQoMDQogICAgICAgICAgIEV4YW1wbGUgU2VydmljZXMgZm9y IE5ldHdvcmsgRWRnZSBQcm94aWVzICAgICAgIE5vdmVtYmVyIDIwMDAgDQoNCiAgIFRoZSBjYWNo aW5nIHByb3h5IHdvdWxkIGhhdmUgdG8gcmVjb2duaXplIHdoZW4gYW5kIHdoZXJlIHRvIGluc2Vy dCANCiAgIGFkIGJhbm5lcnMgaW50byBhIFdlYiBwYWdlIGJlZm9yZSBzZXJ2aW5nIGl0IHRvIHRo ZSBjbGllbnQuIFRoZSANCiAgIHByb3h5IGNvdWxkIGZvciBpbnN0YW5jZSBzY2FuIHRoZSBXZWIg cGFnZSBmb3IgYSBzcGVjaWZpYyBtYXJraW5nIA0KICAgKGUuZy4gYSBzcGVjaWFsIHRhZykuIElu IHRoZSBjYXNlIG9mIGEgRnJlZSBJU1AgYWQgYmFubmVycyB3b3VsZCANCiAgIHByb2JhYmx5IGFs d2F5cyBiZSBpbnNlcnRlZCBhdCB0aGUgc2FtZSBwb3NpdGlvbiAoZS5nLiBpbiBhIGZyYW1lIGF0 IA0KICAgdGhlIHRvcCBvZiBlYWNoIHBhZ2UpIG9yIGluIGEgc2VwYXJhdGUgcG9wLXVwIHdpbmRv dy4gDQogICAgDQogICBJZiB3ZSB3YW50ZWQgdG8gaW5zZXJ0IGFkdmVydGlzZW1lbnRzIGJhc2Vk IG9uIHRoZSB1c2VyIGFuZCBoaXMgDQogICBpbnRlcmVzdHMsIHdlIHdvdWxkIGhhdmUgdG8gaWRl bnRpZnkgdGhlIHVzZXIgKGJ5IHVzaW5nIGNvb2tpZXMgZm9yIA0KICAgZXhhbXBsZSkgYW5kIGNy ZWF0ZSB1c2VyIHByb2ZpbGVzLiBUaGUgdXNlciBwcm9maWxlcyBjb3VsZCBhbHNvIGJlIA0KICAg cHJvdmlkZWQgYnkgdGhlIGNvbnRlbnQgcHJvdmlkZXIuIA0KICAgIA0KICAgQSBzdGFuZGFyZCBt b2RlbCBmb3IgaWRlbnRpZnlpbmcgc3BhY2Ugd2hlcmUgdGhlIGNvbnRlbnQgcHJvdmlkZXJzIA0K ICAgYWxsb3cgZm9yIGFkdmVydGlzaW5nIGluc2VydGlvbiBpcyBjcml0aWNhbC4gVGhpcyB3aWxs IGhhdmUgdG8gYmUgDQogICBjb29yZGluYXRlZCB3aXRoIGdyb3VwcyBkZWZpbmluZyBjb250ZW50 IHN0cnVjdHVyZSwgc3VjaCBhcyBYTUwgd2l0aCANCiAgIFczQyBbNF0uIA0KICAgIA0KDQo0ICBJ bnNlcnRpb24gb2YgUmVnaW9uYWwgRGF0YSANCg0KICAgIA0KDQogICA0LjEgQWJzdHJhY3QgDQoN CiAgICANCiAgIElmIGEgY29udGVudCBwcm92aWRlciB3YW50cyB0byBhZGQgdXNlci1zcGVjaWZp YyByZWdpb25hbCANCiAgIGluZm9ybWF0aW9uICh3ZWF0aGVyIGZvcmVjYXN0cyBmb3IgY2VydGFp biBhcmVhcyBmb3IgZXhhbXBsZSkgdG8gaGlzIA0KICAgV2ViIHBhZ2VzLCBoZSBoYXMgbGl0dGxl IGNob2ljZSBidXQgdG8gaGF2ZSB0aGUgdXNlciBzZWxlY3QgaGlzIA0KICAgbG9jYXRpb24gZnJv bSBhIGxpc3Qgb2YgcmVnaW9ucy4gVXN1YWxseSBpdCBpcyBub3QgcG9zc2libGUgZm9yIA0KICAg b3JpZ2luIHNlcnZlcnMgdG8gcmVsaWFibHkgZGV0ZWN0IGZyb20gd2hlcmUgV2ViIHVzZXJzIGNv bm5lY3QgdG8gDQogICBXZWIgc2l0ZXMgYmVjYXVzZSB1c2VyIHJlcXVlc3RzIGNhbiBnZXQgcm91 dGVkIHRocm91Z2ggYSBudW1iZXIgb2YgDQogICBwcm94eSBzZXJ2ZXJzIG9uIHRoZWlyIHdheSBm cm9tIHRoZSBjbGllbnQgdG8gdGhlIG9yaWdpbiBzZXJ2ZXIuICANCiAgICANCiAgIEluIGEgbmV0 d29yayBlZGdlIGNhY2hpbmcgcHJveHkgZW52aXJvbm1lbnQgdXNlciByZXF1ZXN0cyBhcmUgDQog ICB1c3VhbGx5IHJlZGlyZWN0ZWQgdG8gdGhlIG5lYXJlc3QgcHJveHkgdGhhdCBpcyBhdmFpbGFi bGUgdG8gcmVzcG9uZCANCiAgIHRvIHRoZSByZXF1ZXN0LiAgUmVnaW9uYWwgaW5mb3JtYXRpb24g dGhhdCBpcyByZWxldmFudCB0byBhbGwgdXNlcnMgDQogICB3aG8gYXJlIGxpa2VseSB0byBjb25u ZWN0IHRvIGEgY2VydGFpbiBwcm94eSBjb3VsZCBiZSBzdG9yZWQgYXQgdGhlIA0KICAgY29ycmVz cG9uZGluZyBjYWNoaW5nIHByb3h5LiBXaGVuZXZlciB0aGUgcHJveHkgcmVjZWl2ZXMgYSB1c2Vy IA0KICAgcmVxdWVzdCwgYSBtb2R1bGUgb24gdGhlIGNhY2hpbmcgcHJveHkgY291bGQgaW5zZXJ0 IHRoZSByZWdpb25hbCANCiAgIGluZm9ybWF0aW9uIGludG8gdGhlIHJlcXVlc3RlZCBXZWIgcGFn ZS4gSWYgdGhlIFdlYiBwYWdlIGRvZXMgbm90IA0KICAgY29udGFpbiBhbnkgdXNlci1zcGVjaWZp YyBub24tY2FjaGVhYmxlIGNvbnRlbnQgb3RoZXIgdGhhbiB0aGUgDQogICBpbnNlcnRlZCByZWdp b25hbCBpbmZvcm1hdGlvbiwgdGhlIFdlYiBwYWdlIGNvbnRlbnQgY2FuIG5vdyBiZSANCiAgIGNh Y2hlZCBmb3IgZnV0dXJlIHJlcXVlc3RzLiANCiAgICANCg0KICAgNC4yIEJ1c2luZXNzIG1vZGVs IA0KDQogICAgDQogICBUaGlzIHNlcnZpY2UgY291bGQgYmUgc29sZCB0byBjb250ZW50IHByb3Zp ZGVycyB3aG8gd2FudCB0byBvZmZlciANCiAgIHJlZ2lvbmFsIGluZm9ybWF0aW9uIG9uIHRoZWly IFdlYiBzaXRlcyBhbmQgd2FudCB0byBhY2NlbGVyYXRlIHRoZSANCiAgIGRlbGl2ZXJ5IG9mIHRo ZWlyIFdlYiBjb250ZW50LiBUaGVyZSBhcmUgbWFueSBjYXNlcyBpbiB3aGljaCBhIA0KICAgY29u dGVudCBwcm92aWRlciBjb3VsZCBwcm9maXQgZnJvbSBrbm93aW5nIHRoZSBsb2NhdGlvbiBvZiB0 aGUgdXNlci4gDQogICBVc2VycyBjb3VsZCBiZSB0YXJnZXRlZCB3aXRoIHJlZ2lvbmFsIGFkdmVy dGlzZW1lbnQgYmFubmVycyAoc2VlIA0KICAgYWxzbyBhZCBpbnNlcnRpb24gc2NlbmFyaW8pLiBS ZWdpb25hbCBkaXN0aW5jdGlvbnMgKGUuZy4gc2FsZXMgDQogICB0YXhlcywgZGlmZmVyaW5nIGxh d3MgZXRjLikgY291bGQgYmUgdGFrZW4gaW50byBjb25zaWRlcmF0aW9uIHdoZW4gDQogICB0aGUg V2ViIHBhZ2VzIGFyZSBwcmVwYXJlZCBmb3IgdGhlIGNsaWVudC4gSXQgd291bGQgbm90IGJlIG5l Y2Vzc2FyeSANCiAgIGFueSBtb3JlIHRvIGFzayB0aGUgdXNlciBmb3IgaGlzIGxvY2F0aW9uIHBy aW9yIHRvIHByZXNlbnRpbmcgaGltIA0KICAgcmVsZXZhbnQgaW5mb3JtYXRpb24uIA0KICAgIA0K DQogIA0KQmVjayBldCBhbC4gICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjAwMSAgICAgICAg ICAgICAgICAgICAgICAgICAgNSANCgwNCiAgICAgICAgICAgRXhhbXBsZSBTZXJ2aWNlcyBmb3Ig TmV0d29yayBFZGdlIFByb3hpZXMgICAgICAgTm92ZW1iZXIgMjAwMCANCg0KDQogICA0LjMgVGVj aG5pY2FsIENoYWxsZW5nZXMgDQoNCiAgICANCiAgIFRoZSByZWdpb25hbCBjb250ZW50IHRoYXQg aXMgdG8gYmUgaW5zZXJ0ZWQgaW50byB0aGUgV2ViIHBhZ2VzIHdvdWxkIA0KICAgaGF2ZSB0byBi ZSBkaXN0cmlidXRlZCB0byB0aGUgY29ycmVzcG9uZGluZyBjYWNoaW5nIHByb3hpZXMuIFNpbmNl IA0KICAgdGhlIHJlZ2lvbmFsIGNvbnRlbnQgcmVwcmVzZW50cyBvbmx5IGEgY29tcG9uZW50IG9m IGEgd2hvbGUgV2ViIA0KICAgcGFnZSwgaXQgY2Fubm90IGJlIGNhY2hlZCBpbiB0aGUgc2FtZSB3 YXkgYSBjb21wbGV0ZSBXZWIgcGFnZSBjYW4gYmUgDQogICBjYWNoZWQgKHVubGVzcyBpdCBpcyBh biBpbWFnZSkuIFdlIGhhdmUgdG8gZmluZCBhIG1lY2hhbmlzbSB0byANCiAgIGRldGVybWluZSB3 aGVuIGEgcmVnaW9uYWwgdGV4dCBjb21wb25lbnQgbmVlZHMgdG8gYmUgdXBkYXRlZCAob3IgaWYg DQogICB0aGUgY29udGVudCBwcm92aWRlciBzaG91bGQgYmUgcmVzcG9uc2libGUgZm9yIHRoaXMp LiANCiAgICANCiAgICANCg0KNSAgQ2FjaGluZyBvZiBQZXJzb25hbGl6ZWQvQ3VzdG9taXplZCBX ZWIgUGFnZXMgDQoNCiAgICANCg0KICAgNS4xIEFic3RyYWN0IA0KDQogICAgDQogICBNYW55IFdl YiBzaXRlcyAoZS5nLiBZYWhvbykgb2ZmZXIgYSBzZXJ2aWNlIHdoZXJlIHVzZXJzIGNhbiBjcmVh dGUgDQogICB0aGVpciBvd24gcGVyc29uYWxpemVkIHZlcnNpb24gb2YgdGhlIFdlYiBzaXRlIChl LmcuIE15WWFob28pLiBJdCANCiAgIGJhc2ljYWxseSBtZWFucyB0aGF0IGEgdXNlciBjYW4gY2hv b3NlIGZyb20gYSBudW1iZXIgb2YgY29tcG9uZW50cyANCiAgIChlLmcuIHN0b2NrIGluZm9ybWF0 aW9uLCB3ZWF0aGVyIGZvcmVjYXN0cywgbmV3cyBldGMuKSBhbmQgY3JlYXRlIGEgDQogICBwZXJz b25hbGl6ZWQgV2ViIHBhZ2Ugd2l0aCB0aGVtLiBUaGlzIGxlYWRzIHRvIGR5bmFtaWMgV2ViIHBh Z2VzIA0KICAgdGhhdCB1c3VhbGx5IGNhbm5vdCBiZSBjYWNoZWQuIEhvd2V2ZXIsIHRoZSBjb21w b25lbnRzIG9mIHRoZSANCiAgIHBlcnNvbmFsaXplZCBXZWIgcGFnZSBjYW4gYmUgY2FjaGVkLiBU aGVyZWZvcmUsIGl0IGlzIHBvc3NpYmxlIHRvIA0KICAgaGF2ZSBhIHNlcnZpY2UgbW9kdWxlIG9u IHRoZSBzZXJ2ZXIgY3JlYXRlIHRoZSB1c2VyLXNwZWNpZmljIFdlYiANCiAgIHBhZ2VzIGJ5IGFz c2VtYmxpbmcgdGhlIGNhY2hlZCBXZWIgc2l0ZSBjb21wb25lbnRzLiBJbiB0aGF0IGNhc2UgdGhl IA0KICAgb3JpZ2luIHNlcnZlciB3b3VsZCBub3QgaGF2ZSB0byBiZSBjb250YWN0ZWQgYWdhaW4g YW5kIHRoZSBwYWdlIA0KICAgY291bGQgYmUgc2VydmVkIHRvIHRoZSBjbGllbnQgZGlyZWN0bHkg ZnJvbSB0aGUgbmV0d29yayBlZGdlIGNhY2hpbmcgDQogICBwcm94eS4gDQogICAgDQoNCiAgIDUu MiBCdXNpbmVzcyBNb2RlbCANCg0KICAgIA0KICAgVGhpcyBzZXJ2aWNlIHdvdWxkIGJlIGFub3Ro ZXIgbWV0aG9kIG9mIGFjY2VsZXJhdGluZyB0aGUgZGVsaXZlcnkgb2YgDQogICBXZWIgY29udGVu dCB0byB0aGUgdXNlciwgcGFydGljdWxhcmx5IHRoZSBkZWxpdmVyeSBvZiANCiAgIHBlcnNvbmFs aXplZC9jdXN0b21pemVkIFdlYiBwYWdlcyB0aGF0IHdvdWxkIG5vdCBiZSBjYWNoZWFibGUgDQog ICBvdGhlcndpc2UuIEl0IGFsc28gc2F2ZXMgYmFuZHdpZHRoIGJldHdlZW4gdGhlIG9yaWdpbiBz ZXJ2ZXIgYW5kIHRoZSANCiAgIHByb3h5IGNhY2hlLiANCiAgICANCiAgIENvbnRlbnQgcHJvdmlk ZXJzIHdobyBvZmZlciB0aGVpciBjdXN0b21lcnMgdGhlIHBvc3NpYmlsaXR5IG9mIA0KICAgcGVy c29uYWxpemluZyB0aGVpciBXZWIgcGFnZXMgYXJlIGxpa2VseSB0byBiZSB3aWxsaW5nIHRvIHBh eSBmb3IgDQogICB0aGlzIGtpbmQgb2Ygc2VydmljZS4gIA0KICAgIA0KDQogICA1LjMgVGVjaG5p Y2FsIENoYWxsZW5nZXMgDQoNCiAgICANCiAgIFdlIHdvdWxkIGhhdmUgdG8gZmluZCBhIGNhY2hp bmcgbWVjaGFuaXNtIGZvciB0aGUgc2VwYXJhdGUgDQogICBjb21wb25lbnRzIG9mIHRoZSBwZXJz b25hbGl6ZWQgV2ViIHBhZ2VzICh1bmxlc3MgYSBjb21wb25lbnQgDQogICBjb25zaXN0cyBvZiBh biBpbWFnZSBvbmx5KS4gVGhlc2UgY29tcG9uZW50cyBjb3VsZCBiZSBzdG9yZWQgYXQgdGhlIA0K ICAgY2FjaGluZyBwcm94eS4gDQogICAgDQogICBUaGUgcGFnZSBjb21wb25lbnRzIHdvdWxkIGhh dmUgdG8gYmUgcmVmcmVzaGVkIGp1c3QgbGlrZSBjb21wbGV0ZSANCiAgIFdlYiBwYWdlIHdoZW5l dmVyIHRoZXkgYmVjb21lIHN0YWxlLiANCiAgICANCiAgICANCg0KNiAgQ29udGVudCBBZGFwdGF0 aW9uIGZvciBBbHRlcm5hdGUgV2ViIEFjY2VzcyBEZXZpY2VzIA0KDQogICAgDQoNCiAgDQpCZWNr IGV0IGFsLiAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAyMDAxICAgICAgICAgICAgICAgICAg ICAgICAgICA2IA0KDA0KICAgICAgICAgICBFeGFtcGxlIFNlcnZpY2VzIGZvciBOZXR3b3JrIEVk Z2UgUHJveGllcyAgICAgICBOb3ZlbWJlciAyMDAwIA0KDQoNCiAgIDYuMSBBYnN0cmFjdCANCg0K ICAgIA0KICAgVGhlcmUgaXMgYSBncm93aW5nIGRpdmVyc2l0eSBhbmQgaGV0ZXJvZ2VuZWl0eSBp biB0eXBlcyBhbmQgDQogICBjYXBhYmlsaXRpZXMgb2YgY2xpZW50IGRldmljZXMgYXMgd2VsbCBh cyB0aGUgZm9ybXMgb2YgbmV0d29yayANCiAgIGNvbm5lY3Rpb25zIHRoYXQgcGVvcGxlIHVzZSB0 byBhY2Nlc3MgdGhlIFdlYi4gQ2xpZW50cyBpbmNsdWRlIGNlbGwgDQogICBwaG9uZXMgYW5kIFBE QXMgYXMgd2VsbCBhcyBQQ3MsIFRWcyAod2l0aCBTZXRUb3AgYm94ZXMpLCBldGMuIA0KICAgSG93 ZXZlciwgdGhlc2UgYXBwbGlhbmNlcyBoYXZlIHF1aXRlIGRpdmVyc2UgZGlzcGxheSBjYXBhYmls aXRpZXMsIA0KICAgc3RvcmFnZSwgcHJvY2Vzc2luZyBwb3dlciwgYXMgd2VsbCBhcyBzbG93IG5l dHdvcmsgYWNjZXNzLiBBcyBhIA0KICAgcmVzdWx0LCBJbnRlcm5ldCBhY2Nlc3MgaXMgc3RpbGwg Y29uc3RyYWluZWQgb24gdGhlc2UgZGV2aWNlcyBhbmQgDQogICB1c2VycyBhcmUgbGltaXRlZCB0 byBvbmx5IGEgc21hbGwgZnJhY3Rpb24gb2YgdGhlIHRvdGFsIG51bWJlciBvZiANCiAgIFdlYiBw YWdlcyBhdmFpbGFibGUgaW4gdGhlIEludGVybmV0IHRvZGF5LiBPcmdhbml6YXRpb25zIHN1Y2gg YXMgdGhlIA0KICAgV0FQIGZvcnVtIFs0XSBoYXZlIHN1Z2dlc3RlZCBjdXN0b20gV2ViIHBhZ2Ug ZGVzaWduIGJ1dCB0aGlzIHJlc3VsdHMgDQogICBpbiBzcGVjaWFsIGNvZGUgZnJlcXVlbnRseSBy ZXF1aXJlZCBvbiB0aGUgY29udGVudCBzZXJ2ZXIuIA0KICAgIA0KICAgU2luY2UgdGhlIG51bWJl ciBvZiBkaWZmZXJlbnQgYWNjZXNzIGRldmljZXMgaXMgZ3Jvd2luZyBjb25zdGFudGx5IA0KICAg Y29udGVudCBwcm92aWRlcnMgY2Fubm90IGJlIGV4cGVjdGVkIHRvIHByb3ZpZGUgZGlmZmVyZW50 IHZlcnNpb25zIA0KICAgb2YgdGhlaXIgV2ViIHBhZ2VzIGZvciBlYWNoIGFuZCBldmVyeSBXZWIg YWNjZXNzIGRldmljZSB0aGF0IGlzIA0KICAgYXZhaWxhYmxlIGluIHRoZSBtYXJrZXQuIA0KICAg IA0KICAgVGhlcmVmb3JlLCBpZiBpdCBpcyBwb3NzaWJsZSB0byB0cmFuc2NvZGUgdGhlIGdlbmVy YWwgZnVsbC1mbGVkZ2VkIA0KICAgV2ViIHBhZ2VzIGF0IHNvbWUgcG9pbnQgb24gdGhlaXIgd2F5 IGZyb20gdGhlIG9yaWdpbiBzZXJ2ZXIgdG8gdGhlIA0KICAgdXNlciBzbyB0aGF0IHRoZXkgYXJl IG9wdGltaXplZCBmb3IgKG9yIGF0IGxlYXN0IGFkYXB0ZWQgdG8pIHRoZSBlbmQgDQogICB1c2Vy cycgc3BlY2lmaWMgcmVxdWlyZW1lbnRzLCBpdCB3b3VsZCBwcm92aWRlIGEgdmFsdWFibGUgc2Vy dmljZSANCiAgIGZvciB0aGUgZW5kIGN1c3RvbWVyLCB0aGUgc2VydmljZSBwcm92aWRlciwgYW5k IHRoZSBjb250ZW50IA0KICAgcHJvdmlkZXIuIA0KICAgIA0KDQogICA2LjIgQnVzaW5lc3MgbW9k ZWwgDQoNCiAgICANCiAgIFdpdGggdGhlIGFib3ZlLW1lbnRpb25lZCBzZXJ2aWNlIGluIHBsYWNl LCBXZWIgY29udGVudCBwcm92aWRlcnMgDQogICBjb3VsZCByZWFjaCBhIG11Y2ggd2lkZXIgYXVk aWVuY2UgYW5kIHRoZSBtYW51ZmFjdHVyZXMgb2YgZGl2ZXJzZSANCiAgIFdlYiBhY2Nlc3MgZGV2 aWNlcyBjb3VsZCBvZmZlciBwb3RlbnRpYWwgY3VzdG9tZXJzIGFjY2VzcyB0byBhIA0KICAgYmln Z2VyIHBhcnQgb2YgdGhlIEludGVybmV0IGNvbnRlbnQsIHdoaWNoIHNob3VsZCBtYWtlIGEgdmVy eSBnb29kIA0KICAgc2VsbGluZyBwb2ludC4gSXQgd291bGQgZW5jb3VyYWdlIG1vcmUgcGVvcGxl IHRvIGJ1eSBub24tZGVza3RvcCBXZWIgDQogICBhY2Nlc3MgZGV2aWNlcyBsaWtlIGNlbGwgcGhv bmVzIGFuZCBQREFzIGV4cGFuZGluZyB0aGUgbWFya2V0LiANCiAgICANCiAgIFdlIHdvdWxkIGV4 cGVjdCB0aGlzIHNlcnZpY2Ugd291bGQgYmUgb2ZmZXJlZCBhcyBhbiBhZGRpdGlvbmFsIA0KICAg ZmVhdHVyZSB0byBJU1AgY3VzdG9tZXJzIHdobyB3YW50IHRvIGFjY2VzcyB0aGUgV2ViIHRocm91 Z2ggDQogICBkaWZmZXJlbnQgV2ViLWVuYWJsZWQgZGV2aWNlcy4gQWxzbywgdGhlIHNlcnZpY2Ug bWlnaHQgYmUgcGFpZCBieSANCiAgIGNvbnRlbnQgcHJvdmlkZXJzIGJlY2F1c2UgdGhleSBjb3Vs ZCBzZXJ2ZSB0aGVpciBleGlzdGluZyBjb250ZW50IHRvIA0KICAgbW9yZSB1c2VyczsgbGlrZXdp c2UsIHRoZSBub24tZGVza3RvcCBkZXZpY2UgbWFrZXJzIG1heSBjb250cmlidXRlIA0KICAgdG8g dGhpcyBzZXJ2aWNlIGNvc3QgbWFraW5nIHRoZWlyIGNsaWVudCBkZXZpY2VzIG1vcmUgZWZmZWN0 aXZlIGF0IA0KICAgdGhlIFdlYi4gDQogICAgDQoNCiAgIDYuMyBUZWNobmljYWwgQ2hhbGxlbmdl cyANCg0KICAgIA0KICAgUG9zc2libGUgYWRhcHRhdGlvbnMgdG8gbWVldCB0aGUgc3BlY2lhbCBy ZXF1aXJlbWVudHMgb2YgZGlmZmVyZW50IA0KICAgV2ViIGFjY2VzcyBkZXZpY2VzIGFyZTogDQog ICAgDQogICAtIENvbnZlcnNpb24gb2YgSFRNTCBwYWdlcyB0byBXTUwgKFdpcmVsZXNzIE1hcmt1 cCBMYW5ndWFnZSkgcGFnZXMgIA0KICAgLSBDb252ZXJzaW9uIG9mIEpQRUcgaW1hZ2VzIHRvIGJs YWNrIGFuZCB3aGl0ZSBHSUYgaW1hZ2VzIA0KICAgLSBDb252ZXJzaW9uIG9mIEhUTUwgdGFibGVz IHRvIHBsYWluIHRleHQgIA0KICAgLSBSZWR1Y3Rpb24gb2YgaW1hZ2UgcXVhbGl0eSANCiAgIC0g UmVtb3ZhbCBvZiByZWR1bmRhbnQgaW5mb3JtYXRpb24gDQoNCiAgDQpCZWNrIGV0IGFsLiAgICAg ICAgICAgICAgICBFeHBpcmVzIE1heSAyMDAxICAgICAgICAgICAgICAgICAgICAgICAgICA3IA0K DA0KICAgICAgICAgICBFeGFtcGxlIFNlcnZpY2VzIGZvciBOZXR3b3JrIEVkZ2UgUHJveGllcyAg ICAgICBOb3ZlbWJlciAyMDAwIA0KDQogICAtIFN0cmlwcGluZyBvZiBKYXZhIGFwcGxldHMgLyBK YXZhU2NyaXB0IA0KICAgLSBBdWRpbyB0byB0ZXh0IGNvbnZlcnNpb24gDQogICAtIFZpZGVvIHRv IGtleSBmcmFtZSBvciB2aWRlbyB0byB0ZXh0IGNvbnZlcnNpb24gDQogICAtIENvbnRlbnQgZXh0 cmFjdGlvbiANCiAgICANCiAgIFdlIGhhdmUgdG8gZW5zdXJlIHRoYXQgdGhlIGF1dG9tYXRpYyBh ZGFwdGF0aW9uIHByb2Nlc3Mgd2lsbCBub3QgDQogICBtYWtlIGNoYW5nZXMgdG8gYSBXZWIgcGFn ZSB0aGF0IGFyZSB1bndhbnRlZCBieSBlaXRoZXIgdGhlIGNvbnRlbnQgDQogICBwcm92aWRlciBv ciB0aGUgcmVjaXBpZW50LiBPdXIgc3VnZ2VzdGVkIHN0cmF0ZWd5IHRvIGFjaGlldmUgdGhpcyAN CiAgIHdvdWxkIGJlIHRvIGFsbG93IHRoZSBjb250ZW50IHByb3ZpZGVyIGFzIHdlbGwgYXMgdGhl IGNsaWVudCB0byANCiAgIGRlZmluZSB0aGVpciBwcmVmZXJlbmNlcyBhcyB0byBob3cgdGhleSB3 YW50IFdlYiBwYWdlcyB0byBiZSANCiAgIGFkYXB0ZWQuIFRoZSBhY3R1YWwgYWRhcHRhdGlvbiBk ZWNpc2lvbnMgd291bGQgdGhlbiBiZSBtYWRlIGJhc2VkIG9uIA0KICAgdGhlIGdpdmVuIHByZWZl cmVuY2VzIGFuZCBhIHNldCBvZiB0cmFuc2Zvcm1hdGlvbiBydWxlcy4gVGhlcmUgd291bGQgDQog ICBoYXZlIHRvIGJlIGEgbWVjaGFuaXNtIG9mIHJlc29sdmluZyBwb3RlbnRpYWwgY29uZmxpY3Rz IGJldHdlZW4gdGhlIA0KICAgY29udGVudCBwcm92aWRlcidzIGFuZCB0aGUgdXNlcidzIGFkYXB0 YXRpb24gcHJlZmVyZW5jZXMuIElmIG5laXRoZXIgDQogICB0aGUgY29udGVudCBwcm92aWRlciBu b3IgdGhlIGNsaWVudCBoYXMgZXhwcmVzc2VkIGhpcyBwcmVmZXJlbmNlcywgYSANCiAgIGRlZmF1 bHQgYWRhcHRhdGlvbiBvZiB0aGUgcmVxdWVzdGVkIFdlYiBwYWdlIG1heSBiZSBwb3NzaWJsZSBi dXQgDQogICBpbnZlc3RpZ2F0aW9uIGlzIG5lZWRlZC4gDQogICAgDQogICBBIHdheSBmb3IgcHJl ZmVyZW5jZXMgdG8gYmUgc3BlY2lmaWVkIHJlcHJlc2VudGluZyB0aGUgY29udGVudCANCiAgIHBy b3ZpZGVyIGFuZCBjbGllbnQgY3VzdG9tZXIgbXVzdCBiZSBwcm92aWRlZC4gRm9yIGV4YW1wbGUs IGNsaWVudCANCiAgIGN1c3RvbWVycyBjb3VsZCBzZXQgdGhlaXIgcHJlZmVyZW5jZXMgdGhyb3Vn aCBhIFdlYiBpbnRlcmZhY2Ugb24gdGhlIA0KICAgSVNQIFdlYiBzaXRlLiBDb250ZW50IHByb3Zp ZGVycyBjb3VsZCBleHByZXNzIHRoZWlyIHByZWZlcmVuY2VzIGJ5IA0KICAgYWRkaW5nIG1ldGEg dGFncyB0byB0aGVpciBXZWIgcGFnZXMuIFRoaXMgbWV0YSBkYXRhIG9mZmVycyB0aGUgDQogICBj b250ZW50IHByb3ZpZGVyIHRoZSBhYmlsaXR5IHRvIHNwZWNpZnkgYSBudW1iZXIgb2YgYWx0ZXJu YXRpdmVzIGFuZCANCiAgIHRoZSBjb250ZW50IGFkYXB0YXRpb24gc2VydmVyIGNvdWxkIHRoZW4g cGljayB0aGUgbW9zdCBhcHByb3ByaWF0ZSANCiAgIG9uZS4gVGhpcyBtZXRhIGRhdGEgc2hvdWxk IGJlIGluZGVwZW5kZW50IG9mIHNwZWNpZmljIFdlYiBjb250ZW50IA0KICAgYnV0IGlzIGxpa2Vs eSB0byBkZXBlbmQgb24gdGhlIHR5cGVzIG9mIGNvbnRlbnQgaW4gdGhlIHBhZ2VzLiANCiAgIEFu b3RoZXIgcG9zc2liaWxpdHkgaW4gdGhlIEVTUFdGIFsyLCA3XSBmcmFtZXdvcmsgd291bGQgYmUg Zm9yIHRoZSANCiAgIGNvbnRlbnQgcHJvdmlkZXIgd291bGQgYmUgdG8gcHJvdmlkZSBhbiBhZGFw dGF0aW9uIHBvbGljeSB0byBhbGwgDQogICBJU1BzIHRoYXQgd2FudCB0byBhZGFwdCBXZWIgcGFn ZXMgZm9yIGFsdGVybmF0ZSBXZWIgYWNjZXNzIGRldmljZXMuIA0KICAgVGhpcyBwb2xpY3kgY291 bGQgY29uc2lzdCBvZiBnZW5lcmFsIHRyYW5zZm9ybWF0aW9uIHJ1bGVzIG9yIGFjdHVhbCANCiAg IGNvZGUgbW9kdWxlcyB0aGF0IHBlcmZvcm0gdGhlIGFkYXB0YXRpb24uIA0KICAgIA0KICAgIA0K DQo3ICBMaW1pdGVkIENsaWVudCBCYW5kd2lkdGggQWRhcHRhdGlvbiANCg0KICAgIA0KDQogICA3 LjEgQWJzdHJhY3QgDQoNCiAgICANCiAgIERpZmZlcmVudCBJbnRlcm5ldCBjbGllbnRzIGNhbiBo YW5kbGUgZGlmZmVyZW50IEludGVybmV0IGNvbm5lY3Rpb24gDQogICBzcGVlZHMuIFRoZXJlZm9y ZSBpdCBzZWVtcyBkZXNpcmFibGUgdG8gYWRhcHQgdGhlIHJlcXVlc3RlZCBXZWIgDQogICBjb250 ZW50IHRvIHRoZSB1c2VyknMgYmFuZHdpZHRoLiAgDQogICAgDQoNCiAgIDcuMiBCdXNpbmVzcyBt b2RlbCANCg0KICAgIA0KICAgT25lIG9mIHRoZSBtYWluIGJlbmVmaXRzIGlzIHRvIGRlY3JlYXNl IHRoZSBXZWIgYWNjZXNzIHRpbWUgZm9yIA0KICAgdXNlcnMuIElmIGEgV2ViIHNpdGUgbG9hZHMg dG9vIHNsb3dseSwgdXNlcnMgdGVuZCB0byBsZWF2ZSB0aGUgc2l0ZSANCiAgIGV2ZW4gYmVmb3Jl IGl0IGhhcyBjb21wbGV0ZWQgbG9hZGluZyB0aGUgaG9tZSBwYWdlLiBUaGUgaW1wcm92ZWQgDQog ICBwZXJjZWl2ZWQgcXVhbGl0eSBvZiBzZXJ2aWNlIGJ5IGFkYXB0aXZlIGNvbnRlbnQgZGVsaXZl cnkgbWVhbnMgdGhhdCANCiAgIHVzZXJzIGFyZSBtb3JlIGxpa2VseSB0byBzdGF5IGFuZCByZXR1 cm4sIHRodXMgcmVzdWx0aW5nIGluIGEgDQogICBncmVhdGVyIHByb2ZpdCBmb3IgZS1jb21tZXJj ZSBzaXRlcy4gVGhpcyBjYW4gYWxzbyByZXN1bHQgaW4gaGlnaGVyIA0KICAgaGl0IHJhdGVzIGFu ZCByZXR1cm4gcmF0ZXMsIHdoaWNoIGNhbiBsZWFkIHRvIGhpZ2hlciBzYWxlcyBmb3IgZS0NCiAg IGNvbW1lcmNlIHNpdGVzIGFuZCBoaWdoZXIgYWR2ZXJ0aXNpbmcgcmV2ZW51ZXMuIA0KICAgIA0K DQogIA0KQmVjayBldCBhbC4gICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjAwMSAgICAgICAg ICAgICAgICAgICAgICAgICAgOCANCgwNCiAgICAgICAgICAgRXhhbXBsZSBTZXJ2aWNlcyBmb3Ig TmV0d29yayBFZGdlIFByb3hpZXMgICAgICAgTm92ZW1iZXIgMjAwMCANCg0KDQogICA3LjMgVGVj aG5pY2FsIENoYWxsZW5nZXMgDQoNCiAgICANCiAgIFBvc3NpYmxlIGFkYXB0YXRpb25zIHRvIHJl ZHVjZSB0aGUgc2l6ZSBvZiBXZWIgb2JqZWN0cyBhcmU6IA0KICAgIA0KICAgLSBSZWR1Y3Rpb24g b2YgaW1hZ2UgcXVhbGl0eSANCiAgIC0gUmVwbGFjZW1lbnQgb2YgaW1hZ2VzIGJ5IHRoZWlyIEFM VCB0ZXh0IA0KICAgLSBSZW1vdmFsIG9mIHJlZHVuZGFudCBpbmZvcm1hdGlvbiANCiAgIC0gUmVt b3ZhbCBvZiBIVE1MIGNvbW1lbnRzIA0KICAgLSBTdHJpcHBpbmcgb2YgSmF2YSBhcHBsZXRzIC8g SmF2YVNjcmlwdCANCiAgIC0gQXVkaW8gdG8gdGV4dCBjb252ZXJzaW9uIA0KICAgLSBWaWRlbyB0 byBrZXkgZnJhbWUgb3IgdmlkZW8gdG8gdGV4dCBjb252ZXJzaW9uIA0KICAgLSBUZXh0IHN1bW1h cml6aW5nIA0KICAgLSBDb250ZW50IGV4dHJhY3Rpb24gDQogICAgDQogICBXZSB3b3VsZCBoYXZl IHRvIGZpbmQgYSByZWxpYWJsZSB3YXkgb2YgZGV0ZXJtaW5pbmcgdGhlIGJhbmR3aWR0aCANCiAg IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHByb3h5IGNhY2hlLiBPbmUgd2F5IG9mIG1lYXN1 cmluZyB0aGlzIA0KICAgd291bGQgYmUgdG8gbWVhc3VyZSB0aGUgcm91bmQgdHJpcCB0aW1lIChS VFQpIHRvIGRldGVybWluZSB0aGUgDQogICBjb25uZWN0aW9uIHNwZWVkLiBJdCBpcyBjcnVjaWFs IHRoYXQgdGhpcyBiYW5kd2lkdGggZGV0ZWN0aW9uIG1ldGhvZCANCiAgIHdvcmtzIG1vcmUgb3Ig bGVzcyBleGFjdCBvciBvdGhlcndpc2UgdGhlIGNsaWVudCB3aWxsIGVpdGhlciANCiAgIGV4cGVy aWVuY2UgdmVyeSBzbG93IFdlYiBicm93c2luZyBvciBiZSBjdXQgb2ZmIG9mIHNvbWUgKG9yIGFs bCkgb2YgDQogICB0aGUgcmljaCBXZWIgY29udGVudC4gVGhpcyBzZXJ2aWNlIHJlcXVpcmVzIGF1 dGhvcml6YXRpb24gYnkgdGhlIA0KICAgdXNlciBsaWtlIGFueSBvdGhlciBhZGFwdGF0aW9uIHNl cnZpY2UgdGhhdCBjaGFuZ2VzIHRoZSBjb250ZW50IGFuZCANCiAgIG9yIGZvcm1hdCBvZiBXZWIg cGFnZXMuIA0KICAgIA0KICAgVGhlIG1hcHBpbmcgb2YgYSB1c2VyknMgY29ubmVjdGlvbiBzcGVl ZCB0byBhcHByb3ByaWF0ZSBwYWdlIA0KICAgYWRhcHRhdGlvbnMgcmVxdWlyZXMgZGVmaW5pbmcg YSBzZXQgb2YgYWRhcHRhdGlvbiBydWxlcy4gDQogICAgDQogICAgDQoNCjggIEFkYXB0YXRpb24g b2YgU3RyZWFtaW5nIE1lZGlhIA0KDQogICAgDQoNCiAgIDguMSBBYnN0cmFjdCANCg0KICAgIA0K ICAgU29tZSBvZiB0aGUgYWJvdmUtbWVudGlvbmVkIHNlcnZpY2VzIGNvdWxkIG5vdCBvbmx5IGJl IGFwcGxpZWQgdG8gDQogICBXZWIgcGFnZXMgYnV0IGFsc28gdG8gc3RyZWFtaW5nIG1lZGlhIGxp a2UgYXVkaW8gYW5kIHZpZGVvIHN0cmVhbXMuIA0KICAgSW4gcGFydGljdWxhciwgbWVkaWEgc3Ry ZWFtcyBjb3VsZCBiZSBhZGFwdGVkIHRvIG1lZXQgdGhlIGJhbmR3aWR0aCANCiAgIG9mIHRoZSB1 c2VyknMgY29ubmVjdGlvbi4gSXQgd291bGQgYWxzbyBiZSBwb3NzaWJsZSB0byBpbnNlcnQgcHJl LQ0KICAgcmVjb3JkZWQgYWR2ZXJ0aXNlbWVudHMgaW50byBhdWRpbyBvciB2aWRlbyBzdHJlYW1z LiBFdmVuIGNvbnRlbnQgDQogICBhbmFseXNpcyBhbmQgY29udGVudCBmaWx0ZXJpbmcgY291bGQg YmUgYXBwbGllZCB0byBzdHJlYW1pbmcgbWVkaWEuICANCiAgICANCg0KICAgOC4yIEJ1c2luZXNz IG1vZGVsIA0KDQogICAgDQogICBUaGUgYnVzaW5lc3MgbW9kZWxzIGZvciBzdHJlYW1pbmcgbWVk aWEgYWRhcHRhdGlvbiBhcmUgc2ltaWxhciB0byANCiAgIHRob3NlIGZvciBXZWIgcGFnZSBhZGFw dGF0aW9uIHNlcnZpY2VzLiAgDQogICAgDQoNCiAgIDguMyBUZWNobmljYWwgQ2hhbGxlbmdlcyAN Cg0KICAgIA0KICAgVGhlIGFkYXB0YXRpb24gb2Ygc3RyZWFtaW5nIG1lZGlhIHdpbGwgYWRkIG1v cmUgY29tcGxleGl0eSB0byB0aGUgDQogICBjYWNoaW5nIHByb3h5IHBsYXRmb3JtIGFuZCB0aGUg dGVjaG5pY2FsIGNoYWxsZW5nZXMgb2YgdGhlc2Uga2luZCBvZiANCiAgIHNlcnZpY2VzIGhhdmUg eWV0IHRvIGJlIGV4cGxvcmVkLiANCiAgICANCiAgICANCg0KOSAgUmVxdWVzdCBGaWx0ZXJpbmcg DQoNCiAgICANCg0KICANCkJlY2sgZXQgYWwuICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIw MDEgICAgICAgICAgICAgICAgICAgICAgICAgIDkgDQoMDQogICAgICAgICAgIEV4YW1wbGUgU2Vy dmljZXMgZm9yIE5ldHdvcmsgRWRnZSBQcm94aWVzICAgICAgIE5vdmVtYmVyIDIwMDAgDQoNCg0K ICAgOS4xIEFic3RyYWN0IA0KDQogICAgDQogICBUaGUgc3VjY2VzcyBvZiBXZWIgZmlsdGVyaW5n L2Jsb2NraW5nIHN5c3RlbXMgbGlrZSBOZXROYW5ueSANCiAgIChodHRwOi8vd3d3Lm5ldG5hbm55 LmNvbSkgYW5kIFdlYlNlbnNlIChodHRwOi8vd3d3LndlYnNlbnNlLmNvbSkgDQogICBzaG93cyB0 aGF0IHRoZXJlIGlzIGEgZ3JlYXQgbmVlZCBmb3Igc29sdXRpb25zIHRoYXQgbGV0IHRoZSBvd25l ciBvZiANCiAgIGEgV2ViIGFjY2VzcyBkZXZpY2UgY29udHJvbCB3aGF0IGtpbmQgb2YgV2ViIGNv bnRlbnQgY2FuIGJlIGFjY2Vzc2VkIA0KICAgd2l0aCBoaXMgZGV2aWNlLiBQYXJlbnRzLCBmb3Ig aW5zdGFuY2UsIG9mdGVuIGRlbWFuZCBhIG1lYW5zIG9mIA0KICAgYmxvY2tpbmcgb2ZmIG9mZmVu ZGluZyBtYXRlcmlhbCB3aGVuIHRoZWlyIGNoaWxkcmVuIGJyb3dzZSB0aGUgV2ViLiANCiAgIEFs c28sIGNvbXBhbmllcyBtaWdodCB3YW50IHRvIGhhdmUgY29udHJvbCBvdmVyIHdoYXQga2luZCBv ZiBXZWIgDQogICBwYWdlcyB0aGVpciBlbXBsb3llZXMgY2FuIGhhdmUgYWNjZXNzIHRvLiBDb21w YW5pZXMgbWlnaHQgYWxzbyB3YW50IA0KICAgdG8gcHJldmVudCB0aGVpciBlbXBsb3llZXMgZnJv bSB1c2luZyB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCANCiAgIGV4Y2Vzc2l2ZWx5IGZvciBub24t d29yayByZWxhdGVkIGFjdGl2aXRpZXMuICANCiAgICANCiAgIEEgcmVxdWVzdCBmaWx0ZXJpbmcg c2VydmljZSBjb3VsZCBwcm92aWRlIGEgc29sdXRpb24gZm9yIGFsbCBvZiB0aGUgDQogICBhYm92 ZS4gSWYgYWxsIFdlYiBwYWdlIHJlcXVlc3RzIG9mIGEgc3BlY2lmaWMgdXNlciBhcmUgcm91dGVk IA0KICAgdGhyb3VnaCBhIGNhY2hpbmcgcHJveHkgc2VydmVyLCB0aGUgY29udGVudCBhZGFwdGF0 aW9uIHNlcnZlciBjb3VsZCANCiAgIGFuYWx5emUgdGhlIHJlcXVlc3RzIHByaW9yIHRvIGZ1bGZp bGxpbmcgdGhlbS4gVGhlIHNlcnZpY2UgbW9kdWxlIA0KICAgd291bGQgaGF2ZSB0byBpZGVudGlm eSB0aGUgdXNlciBhbmQgZGV0ZXJtaW5lIHRoZSB1c2VyknMgYWNjZXNzIA0KICAgbGV2ZWwuIFRo ZSBuZXh0IHN0ZXAgd291bGQgYmUgdG8gbG9vayB1cCB0aGUgY2xhc3NpZmljYXRpb24gb2YgdGhl IA0KICAgcmVxdWVzdGVkIFdlYiBwYWdlIGluIGEgZGF0YWJhc2UuIA0KICAgIA0KICAgIA0KDQog ICA5LjIgQnVzaW5lc3MgbW9kZWwgDQoNCiAgICANCiAgIFRoaXMgc2VydmljZSBjb3VsZCBiZSBv ZmZlcmVkIHRvIGVudGVycHJpc2VzIGFuZCB0byBJU1BzLiBBIGRhdGFiYXNlIA0KICAgb2YgV2Vi IHBhZ2VzIHRoYXQgY29udGFpbiBvZmZlbmRpbmcgbWF0ZXJpYWwgY291bGQgYmUgb2J0YWluZWQg ZnJvbSANCiAgIGNvbXBhbmllcyB0aGF0IGhhdmUgc3BlY2lhbGl6ZWQgaW4gV2ViIGJsb2NraW5n IHN5c3RlbXMuIA0KICAgIA0KDQogICA5LjMgVGVjaG5pY2FsIENoYWxsZW5nZXMgDQoNCiAgICAN CiAgIFRoZSBkYXRhYmFzZSBvbiB0aGUgcHJveHkgY2FjaGluZyBwbGF0Zm9ybSB0aGF0IGNvbnRh aW5zIHRoZSBXZWIgDQogICBwYWdlIGNsYXNzaWZpY2F0aW9ucyBuZWVkcyB0byBiZSB1cGRhdGVk IG9uIGEgcmVndWxhciBiYXNpcy4gSWYgdGhlIA0KICAgZGF0YWJhc2UgaXMgcHJvdmlkZWQgYnkg dGhpcmQgcGFydGllcywgd2UgaGF2ZSB0byBwcm92aWRlIHRoZW0gd2l0aCANCiAgIGEgc2VjdXJl IHdheSBvZiB1cGRhdGluZyB0aGUgZGF0YWJhc2UuIA0KICAgIA0KICAgSWYgYSBXZWIgYWNjZXNz IGRldmljZSBpcyBzaGFyZWQgYW1vbmcgZGlmZmVyZW50IHVzZXJzIHdobyBoYXZlIA0KICAgZGlm ZmVyZW50IGFjY2VzcyBsZXZlbHMsIGl0IGlzIG5vdCBzdWZmaWNpZW50IHRvIGlkZW50aWZ5IHRo ZSBXZWIgDQogICBhY2Nlc3MgZGV2aWNlLiBUaGVyZWZvcmUgaXQgd2lsbCBwcm9iYWJseSBiZSBu ZWNlc3NhcnkgdGhhdCANCiAgIGRpZmZlcmVudCB1c2VycyBvZiBhIFdlYiBhY2Nlc3MgZGV2aWNl IHVzZSBkaWZmZXJlbnQgdXNlciBhY2NvdW50cy4gDQogICAgDQogICBUaGUgb3duZXIgb2YgYSBX ZWIgYWNjZXNzIGRldmljZSBtdXN0IGJlIGFibGUgdG8gZGVmaW5lIGFuZCBjaGFuZ2UgDQogICB0 aGUgYWNjZXNzIHJpZ2h0cyBvZiB0aGUgdXNlcihzKSBvZiBoaXMgZGV2aWNlLiBUaGlzIGNvdWxk IGJlIGRvbmUgDQogICB0aHJvdWdoIGEgV2ViIGludGVyZmFjZSBwcm92aWRlZCBieSB0aGUgSVNQ L2NvbXBhbnkuIA0KICAgIA0KICAgIA0KDQoxMCBSZXF1ZXN0IEZpbHRlcmluZyB0aHJvdWdoIENv bnRlbnQgQW5hbHlzaXMgDQoNCiAgICANCg0KICAgMTAuMSBBYnN0cmFjdCANCg0KICAgIA0KICAg V2hpbGUgdGhpcyBzZXJ2aWNlIGlzIHZlcnkgc2ltaWxhciB0byB0aGUgb25lIHByZXZpb3VzbHkg ZGVzY3JpYmVkLCANCiAgIGl0IHdvcmtzIG1vcmUgZHluYW1pY2FsbHkgaW4gdGhhdCB0aGUgY29u dGVudCBhZGFwdGF0aW9uIHNlcnZlciANCiAgIGFuYWx5emVzIHRoZSBXZWIgY29udGVudCBvbmNl IGl0IGhhcyBiZWVuIHJldHJpZXZlZCBmcm9tIGVpdGhlciB0aGUgDQogICBwcm94eSBjYWNoZSBv ciB0aGUgb3JpZ2luIHNlcnZlciBwcmlvciB0byBzZW5kaW5nIGl0IHRvIHRoZSBjbGllbnQuICAN Cg0KICANCkJlY2sgZXQgYWwuICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwMDEgICAgICAg ICAgICAgICAgICAgICAgICAgMTAgDQoMDQogICAgICAgICAgIEV4YW1wbGUgU2VydmljZXMgZm9y IE5ldHdvcmsgRWRnZSBQcm94aWVzICAgICAgIE5vdmVtYmVyIDIwMDAgDQoNCiAgIFRocm91Z2gg dGhlIHVzZSBvZiBzb3BoaXN0aWNhdGVkIGNvbnRlbnQgYW5hbHlzaXMgYWxnb3JpdGhtcyBpdCAN CiAgIHNob3VsZCBiZSBwb3NzaWJsZSB0byBjbGFzc2lmeSB0aGUgYW5hbHl6ZWQgV2ViIGNvbnRl bnQuIElmIHRoZSANCiAgIGNsYXNzaWZpY2F0aW9uIG9mIHRoZSBXZWIgcGFnZSBtYXRjaGVzIHRo ZSB1c2VyknMgYWNjZXNzIGxldmVsLCB0aGUgDQogICBwYWdlIHdpbGwgYmUgZGVsaXZlcmVkIHRv IHRoZSBjbGllbnQuIE90aGVyd2lzZSwgdGhlIGNsaWVudCB3aWxsIGJlIA0KICAgZGVuaWVkIHRo ZSBwYWdlLiBUaGUgYW5hbHl6ZWQgcGFnZSBhbG9uZyB3aXRoIGl0cyBjbGFzc2lmaWNhdGlvbiAN CiAgIHNob3VsZCBiZSBzdG9yZWQgaW4gdGhlIHByb3h5IGNhY2hlIHNvIHRoYXQgZnV0dXJlIHJl cXVlc3RzIGZvciB0aGUgDQogICBzYW1lIHBhZ2UgZG8gbm90IHJlcXVpcmUgdGhlIGNhY2hlZCBX ZWIgdG8gYmUgYW5hbHl6ZWQgYWdhaW4uIFRoaXMgDQogICB3aWxsIHJlc3VsdCBpbiBhIGJldHRl ciBXZWIgcGFnZSBkZWxpdmVyeSBwZXJmb3JtYW5jZSBmb3IgcG9wdWxhciANCiAgIFdlYiBwYWdl cy4gVGhlIG1haW4gYmVuZWZpdCBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgdGhlcmUgaXMgbm8g DQogICBuZWVkIHRvIHByb3ZpZGUgb3IgbWFpbnRhaW4gbGlzdHMgb2YgZm9yYmlkZGVuIFdlYiBz aXRlcywgYSBwcm9jZXNzIA0KICAgdGhhdCBwZXIgZGVmaW5pdGlvbiBtdXN0IGFsd2F5cyBsYWcg YmVoaW5kIHRoZSBjcmVhdGlvbiBvZiBuZXcgV2ViIA0KICAgc2l0ZXMuIElmIGNvbW1vbiBjaGFy YWN0ZXJpc3RpY3Mgb2YgYSBjYXRlZ29yeSBvZiB1bndhbnRlZCBXZWIgcGFnZXMgDQogICBjYW4g YmUgZGVmaW5lZCwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGF1dG9tYXRpY2FsbHkgZGV0ZWN0 IA0KICAgd2hldGhlciBhIHJlcXVlc3RlZCBXZWIgcGFnZSBmYWxscyBpbiBhIGZvcmJpZGRlbiBj YXRlZ29yeS4gIA0KICAgIA0KDQogICAxMC4yIEJ1c2luZXNzIG1vZGVsIA0KDQogICAgDQogICBU aGlzIHNlcnZpY2UgY291bGQgYmUgb2ZmZXJlZCB0byBlbnRlcnByaXNlcyBhbmQgSVNQcy4gVGhl IGNvbnRlbnQgDQogICBhbmFseXNpcyBzb2Z0d2FyZSBjb3VsZCBiZSBvYnRhaW5lZCBmcm9tIHNv ZnR3YXJlIGNvbXBhbmllcyB0aGF0IA0KICAgaGF2ZSBzcGVjaWFsaXplZCBpbiB0aGlzIGZpZWxk LiANCiAgICANCg0KICAgMTAuMyBUZWNobmljYWwgQ2hhbGxlbmdlcyANCg0KICAgIA0KICAgSW4g YWRkaXRpb24gdG8gdGhlIHRlY2huaWNhbCBjaGFsbGVuZ2VzIGRlc2NyaWJlZCBpbiB0aGUgcHJl dmlvdXMgDQogICBzZXJ2aWNlIHNjZW5hcmlvLCB3ZSB3b3VsZCBoYXZlIHRvIGZpbmQgYSB3YXkg b2Ygc3RvcmluZyB0aGUgDQogICBjbGFzc2lmaWNhdGlvbiBpbmZvcm1hdGlvbiBvZiBXZWIgcGFn ZXMgb25jZSB0aGV5IGhhdmUgYmVlbiANCiAgIGFuYWx5emVkLiBPbmUgd2F5IHRvIGRvIHRoaXMg d291bGQgYmUgdG8gYWRkIGEgbWV0YSB0YWcgKHBvc3NpYmx5IA0KICAgdXNpbmcgdGhlIFJlc291 cmNlIERlc2NyaXB0aW9uIEZyYW1ld29yayBbNl0gc3BlY2lmaWNhdGlvbikgd2l0aCANCiAgIGNv bnRlbnQgcmF0aW5nIGluZm9ybWF0aW9uIHRvIGEgV2ViIHBhZ2UgYmVmb3JlIGl0IGlzIGNhY2hl ZC4gDQogICBTdWJzZXF1ZW50IHJlcXVlc3RzIG9mIHRoZSBzYW1lIFdlYiBwYWdlIHdvdWxkIHRo ZW4gcmVxdWlyZSB0aGUgDQogICByZXF1ZXN0IGZpbHRlcmluZyBzZXJ2aWNlIG1vZHVsZSB0byBz Y2FuIHRoZSBjYWNoZWQgV2ViIHBhZ2UgZm9yIA0KICAgdGhpcyBtZXRhZGF0YSBpbiBvcmRlciB0 byBkZXRlcm1pbmUgdGhlIGNvbnRlbnQgcmF0aW5nIG9mIHRoZSANCiAgIHJlcXVlc3RlZCBwYWdl LiAgDQogICAgDQogICAgDQoNCjExIENyZWF0aW9uIG9mIFVzZXIgUHJvZmlsZXMgDQoNCiAgICAN Cg0KICAgMTEuMSBBYnN0cmFjdCANCg0KICAgIA0KICAgSWYgYWxsIFdlYiByZXF1ZXN0cyBvZiBh IGNlcnRhaW4gV2ViIHVzZXIgd2VyZSByb3V0ZWQgdGhyb3VnaCBhIA0KICAgY2VydGFpbiBjYWNo aW5nIHByb3h5IHBsYXRmb3JtLCBpdCB3b3VsZCBiZSBlYXN5IHRvIGxvZyB0aGVtIGluIA0KICAg b3JkZXIgdG8gY3JlYXRlIGEgcHJvZmlsZSBvZiB0aGUgdXNlcpJzIFdlYiBicm93c2luZyBiZWhh dmlvci4gVGhlc2UgDQogICB1c2VyIHByb2ZpbGVzIGNvdWxkIGJlIGNyZWF0ZWQgYW5vbnltb3Vz bHkgd2l0aCBubyBwZXJzb25hbCBkYXRhIA0KICAgKGUuZy4gbmFtZSBvciBlLW1haWwgYWRkcmVz cykgc3RvcmVkIGluIHRoZSBhY2Nlc3MgbG9nIGZpbGVzLiANCiAgICANCiAgIE9uY2UgYSBzdWZm aWNpZW50IG51bWJlciBvZiByZXF1ZXN0cyBoYXMgYmVlbiBsb2dnZWQgYnkgdGhlIGNvbnRlbnQg DQogICBhZGFwdGF0aW9uIHNlcnZlciwgdGhlIG1hcmtldGluZyBncm91cCBjb3VsZCBzdGFydCBh bmFseXppbmcgdGhlIGxvZyANCiAgIGZpbGVzLiBJbiBtb3N0IGNhc2VzIGl0IHNob3VsZCBiZSBw b3NzaWJsZSB0byBkZXJpdmUgdGhlIHVzZXKScyANCiAgIGludGVyZXN0cyBieSBhbmFseXppbmcg d2hhdCBraW5kIG9mIFdlYiBzaXRlcyB0aGUgdXNlciB2aXNpdHMgYW5kIA0KICAgaG93IG9mdGVu IGhlIGdvZXMgdGhlcmUuIA0KICAgIA0KDQogICAxMS4yIEJ1c2luZXNzIG1vZGVsIA0KDQogICAg DQoNCiAgDQpCZWNrIGV0IGFsLiAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSAyMDAxICAgICAg ICAgICAgICAgICAgICAgICAgIDExIA0KDA0KICAgICAgICAgICBFeGFtcGxlIFNlcnZpY2VzIGZv ciBOZXR3b3JrIEVkZ2UgUHJveGllcyAgICAgICBOb3ZlbWJlciAyMDAwIA0KDQogICBDb21wYW5p ZXMgdGhhdCB3YW50IHRvIGFkdmVydGlzZSBvbiBXZWIgcGFnZXMgYXJlIHZlcnkgaW50ZXJlc3Rl ZCBpbiANCiAgIGtub3dpbmcgbW9yZSBhYm91dCB0aGUgcmVjaXBpZW50cyBvZiB0aGVpciBhZHZl cnRpc2VtZW50IGNhbXBhaWducyANCiAgIHNvIHRoYXQgdGhleSBjYW4gdGFyZ2V0IHRoZWlyIGFk dmVydGlzZW1lbnRzIGF0IHBlb3BsZSB3aG8gYXJlIA0KICAgaW50ZXJlc3RlZCBpbiB0aGUga2lu ZCBvZiBwcm9kdWN0cy9zZXJ2aWNlcyB0aGF0IHRoZSBjb21wYW55IHdhbnRzIA0KICAgdG8gc2Vs bC4gVGhlc2UgY29tcGFuaWVzIHdpbGwgcGF5IGZvciBpbmZvcm1hdGlvbiB0aGF0IGhlbHBzIHRo ZW0gdG8gDQogICB0YXJnZXQgdGhlaXIgY2FtcGFpZ25zIGF0IGludGVyZXN0ZWQgdXNlcnMuIFRo aXMgbW9uZXkgY291bGQgYmUgDQogICBvZmZlcmVkIHRvIHVzZXJzIChlLmcuIGluIHRoZSBmb3Jt IG9mIHJlZHVjZWQgSW50ZXJuZXQgYWNjZXNzIGZlZXMpIA0KICAgdG8gZ2l2ZSB0aGVtIGFuIGlu Y2VudGl2ZSB0byBhZ3JlZSB0byB0aGUgcHJvZmlsaW5nLiANCiAgICANCiAgIEFzIGV4cGxhaW5l ZCBhYm92ZSwgd2UgY291bGQgZGVyaXZlIHRoZSB1c2VyknMgaW50ZXJlc3RzIGZyb20gaGlzIA0K ICAgV2ViIGJyb3dzaW5nIGJlaGF2aW9yIGFuZCB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byBzZW5k IHRoZSB1c2VyIG9ubHkgDQogICB0aG9zZSBhZHZlcnRpc2VtZW50cyB0aGF0IG1hdGNoIGhpcyBp bnRlcmVzdHMvbmVlZHMuIFRoaXMgd2lsbCBtb3N0IA0KICAgbGlrZWx5IHJlc3VsdCBpbiBhIGhp Z2hlciBhZCBiYW5uZXIgY2xpY2stcmF0ZSBwZXIgdXNlci4gIA0KICAgIA0KICAgVGhpcyBzZXJ2 aWNlIGNvdWxkIGJlIHNvbGQgc2VwYXJhdGVseSBvciBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZSBh ZCANCiAgIGluc2VydGlvbiBzZXJ2aWNlLiANCiAgICANCg0KICAgMTEuMyBUZWNobmljYWwgQ2hh bGxlbmdlcyANCg0KICAgIA0KICAgVGhlIGNyZWF0aW9uIG9mIHVzZXIgcHJvZmlsZXMgcmVxdWly ZXMgYSBtZWNoYW5pc20gdG8gaWRlbnRpZnkgV2ViIA0KICAgdXNlcnMuIFRoZSBJU1AgY291bGQg cHJvdmlkZSBhIG1hcHBpbmcgZnJvbSB0aGUgdXNlcpJzIChwb3NzaWJseSANCiAgIGR5bmFtaWMp IElQIG51bWJlciB0byBzb21lIHVuaXF1ZSB1c2VyIElELiBBbm90aGVyIGFsdGVybmF0aXZlIHdv dWxkIA0KICAgYmUgdG8gdXNlIGNvb2tpZXMsIHByb3ZpZGVkIHRoYXQgdGhlIHVzZXIgaGFzIG5v dCBkaXNhYmxlZCB0aGVtIGluIA0KICAgaGlzIFdlYiBicm93c2VyLiANCiAgICANCiAgICANCg0K MTIgU2VhcmNoIEVuZ2luZSBJbmRleCBvbiBDYWNoZWQgV2ViIFBhZ2VzICANCg0KICAgIA0KDQog ICAxMi4xIEFic3RyYWN0IA0KDQogICAgDQogICBBIHByb3h5IHVzdWFsbHkgY29udGFpbnMgdGhl IG1vc3QgZnJlcXVlbnRseSByZXF1ZXN0ZWQgV2ViIHBhZ2VzIG9mIA0KICAgdGhlIFdlYiB1c2Vy cyB3aG9zZSBXZWIgcmVxdWVzdHMgYXJlIHJvdXRlZCB0aHJvdWdoIGl0LiBJZiB3ZSANCiAgIGlu ZGV4ZWQgdGhlIGNvbnRlbnQgb2YgYWxsIFdlYiBwYWdlcyBjdXJyZW50bHkgY29udGFpbmVkIGlu IG9uZSBvciANCiAgIG1vcmUgcHJveGllcywgd2Ugd291bGQgaGF2ZSBhbiBpbmRleCBvZiBXZWIg cGFnZXMgdGhhdCBXZWIgdXNlcnMgYXJlIA0KICAgdmVyeSBsaWtlbHkgdG8gcmVxdWVzdCAoc2lu Y2UgdGhleSBoYXZlIGJlZW4gdGhlIG1vc3QgcG9wdWxhciBpbiB0aGUgDQogICBwYXN0KS4gQSBz ZWFyY2ggZW5naW5lIGJhc2VkIG9uIHRoaXMgaW5kZXggY291bGQgdGhlcmVmb3JlIHlpZWxkIGEg DQogICBoaWdoIGhpdCByYXRlIHdoZW4gdXNlZCBieSBhIGdyb3VwIG9mIHVzZXJzIHdobyBoYXZl IHNpbWlsYXIgDQogICBpbnRlcmVzdHMgYW5kIHVzdWFsbHkgY29ubmVjdCB0byB0aGUgc2FtZSBj YWNoaW5nIHByb3hpZXMuIFRoZSANCiAgIGJlbmVmaXQgb2YgdGhpcyBhcHByb2FjaCB3b3VsZCBi ZSB0aGF0IHRoZSBpbmRleCBjb3VsZCBiZSBjcmVhdGVkIA0KICAgdmVyeSBmYXN0ICh0aGVyZSBp cyBubyBXZWIgY3Jhd2xpbmcgdG8gZG8pIGFuZCB0aGF0IHRoZSBzZWFyY2ggDQogICByZXN1bHRz IGNvdWxkIGJlIHJldHVybmVkIHRvIHRoZSB1c2VyIGRpcmVjdGx5IGZyb20gdGhlIG5ldHdvcmsg ZWRnZSANCiAgIGNhY2hpbmcgcHJveHkuIFRoZSBkcmF3YmFjaywgaG93ZXZlciwgaXMgdGhhdCB0 aGlzIHNlYXJjaCBlbmdpbmUgDQogICB3b3VsZCBpbmRleCBvbmx5IGEgc21hbGwgZnJhY3Rpb24g b2YgdGhlIGV4aXN0aW5nIFdlYiBwYWdlcy4gV2ViIA0KICAgdXNlcnMgaGF2ZSB0byBiZSBhd2Fy ZSBvZiB0aGlzIGZhY3Qgd2hlbiB0aGV5IHVzZSB0aGUgY2FjaGUtYmFzZWQgDQogICBzZWFyY2gg aW5kZXggc2VydmljZS4gQW5vdGhlciBhcHByb2FjaCB3b3VsZCBiZSB0byBkaXNwbGF5IHRoZSBw cm94eSANCiAgIHNlYXJjaCByZXN1bHRzIGZpcnN0IHdoaWxlIGEgZ2xvYmFsIHNlYXJjaCBlbmdp bmUgcHJlcGFyZXMgdGhlIA0KICAgcmVzdWx0cyBvZiBhIGdsb2JhbCBzZWFyY2ggaW4gdGhlIG1l YW50aW1lLiBBcyBzb29uIGFzIHRoZSBnbG9iYWwgDQogICBzZWFyY2ggcmVzdWx0cyBiZWNvbWUg YXZhaWxhYmxlLCB0aGV5IHdpbGwgYmUgc2VudCB0byB0aGUgdXNlci4gDQogICAgDQoNCiAgIDEy LjIgQnVzaW5lc3MgbW9kZWwgDQoNCiAgICANCiAgIFRoZSBzZWFyY2ggZW5naW5lIHNlcnZpY2Ug ZGVzY3JpYmVkIGFib3ZlIGNvdWxkIGJlIHNvbGQgdG8gYmlnIA0KICAgY29tcGFuaWVzIHdobyBo YXZlIHVzZXJzIHdpdGggc2ltaWxhciBpbnRlcmVzdHMgYW5kIHdhbnQgdG8gcHJvdmlkZSANCg0K ICANCkJlY2sgZXQgYWwuICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwMDEgICAgICAgICAg ICAgICAgICAgICAgICAgMTIgDQoMDQogICAgICAgICAgIEV4YW1wbGUgU2VydmljZXMgZm9yIE5l dHdvcmsgRWRnZSBQcm94aWVzICAgICAgIE5vdmVtYmVyIDIwMDAgDQoNCiAgIGEgZmFzdCBzZWFy Y2ggZW5naW5lLiBDb21wYW5pZXMgb2ZmZXJpbmcgdHJhZGl0aW9uYWwgc2VhcmNoIGVuZ2luZXMg DQogICBjb3VsZCBiZSBpbnRlcmVzdGVkIGluIGNvbWJpbmluZyB0aGVpciBzZXJ2aWNlcyB3aXRo IGEgY2FjaGUtYmFzZWQgDQogICBzZWFyY2ggZW5naW5lIHNlcnZpY2UgdG8gYWNjZWxlcmF0ZSB0 aGUgZGVsaXZlcnkgb2YgdGhlaXIgc2VhcmNoIA0KICAgcmVzdWx0cy4gDQogICAgDQoNCiAgIDEy LjMgVGVjaG5pY2FsIENoYWxsZW5nZXMgDQoNCiAgICANCiAgIElmIHRoZSBjYWNoZWQgV2ViIHBh Z2VzIG9mIG1vcmUgdGhhbiBvbmUgY2FjaGluZyBwcm94eSB3ZXJlIHRvIGJlIA0KICAgaW5kZXhl ZCwgd2Ugd291bGQgaGF2ZSB0byBmaW5kIGEgd2F5IG9mIHJlcGxpY2F0aW5nIHRoZSBzZWFyY2gg aW5kZXggDQogICB0byBhbGwgYWZmZWN0ZWQgY2FjaGluZyBwcm94eSBzZXJ2ZXJzLiAgDQogICAg DQogICAgDQoNCjEzIExhbmd1YWdlIFRyYW5zbGF0aW9uIA0KDQogICAgDQoNCiAgIDEzLjEgQWJz dHJhY3QgDQoNCiAgICANCiAgIFNvb24gdGhlIG1ham9yaXR5IG9mIGFsbCBJbnRlcm5ldCB1c2Vy cyB3aWxsIGJlIG5vbi1FbmdsaXNoIA0KICAgc3BlYWtpbmcuIEFzIG1vc3Qgb2YgdGhlIGN1cnJl bnQgV2ViIGNvbnRlbnQgaXMgd3JpdHRlbiBpbiBFbmdsaXNoLCANCiAgIGl0IGJlY29tZXMgZGVz aXJhYmxlIHRvIGJlIGFibGUgdG8gdHJhbnNsYXRlIHRoZSBFbmdsaXNoIGNvbnRlbnQgdG8gDQog ICB0aGUgV2ViIHVzZXKScyBsb2NhbCBsYW5ndWFnZSwgZXZlbiBpZiB0aGUgY29udGVudCBwcm92 aWRlciBkb2VzIG5vdCANCiAgIG9mZmVyIHRyYW5zbGF0aW9ucyBvZiBoaXMgV2ViIGNvbnRlbnQu IEFuIGF1dG9tYXRpYyB0cmFuc2xhdGlvbiANCiAgIHNlcnZpY2UgZm9yIGFsbCBXZWIgcGFnZXMg Y291bGQgYmUgaW1wbGVtZW50ZWQgd2l0aCBhIGNvbnRlbnQgDQogICBhZGFwdGF0aW9uIHNlcnZl ci4gDQogICAgDQogICBUaGUgcHJveHkgc2VydmVyIHdpbGwgZGV0ZXJtaW5lIHRoZSBXZWIgdXNl cidzIHByZWZlcnJlZCBsYW5ndWFnZShzKSANCiAgIGFuZCBhc2sgd2hldGhlciB0aGUgY29udGVu dCByZXF1ZXN0ZWQgc2hvdWxkIGJlIHRyYW5zbGF0ZWQgdG8gdGhlIA0KICAgdXNlcidzIHByZWZl cnJlZCBsYW5ndWFnZS4gSWYgdGhlIGNvbnRlbnQgaXMgdG8gYmUgdHJhbnNsYXRlZCwgdGhlIA0K ICAgcHJveHkgY2FjaGUgd2lsbCBmb3J3YXJkIHRoZSBXZWIgY29udGVudCB0byBhIHRyYW5zbGF0 aW9uIHNlcnZlciANCiAgIHdoZXJlIHRoZSBwYWdlIHRoZW4gaXMgYXV0b21hdGljYWxseSB0cmFu c2xhdGVkLiBUaGUgcHJveHkgY291bGQgDQogICBhbHNvIGxvY2FsbHkgc3RvcmUgdHJhbnNsYXRl ZCBjb250ZW50IGVsaW1pbmF0aW5nIHRoZSBuZWVkIHRvIHJlcGVhdCANCiAgIHRyYW5zbGF0aW9u cyBmb3IgZGlmZmVyZW50IHVzZXJzLiANCiAgICANCg0KICAgMTMuMiBCdXNpbmVzcyBtb2RlbCAN Cg0KICAgIA0KICAgVGhlIGF1dG9tYXRpYyBsYW5ndWFnZSB0cmFuc2xhdGlvbiBzZXJ2aWNlIHdp bGwgaGVscCBicmVhayBsYW5ndWFnZSANCiAgIGJhcnJpZXJzIGFuZCBvcGVuIG5ldyBtYXJrZXRz IGZvciBlLWNvbW1lcmNlLiBUaGUgYXZlcmFnZSBub24tDQogICBFbmdsaXNoIHNwZWFraW5nIFdl YiB1c2VyIHdpbGwgaGF2ZSBhY2Nlc3MgdG8gbW9yZSBXZWIgY29udGVudC4gDQogICBJU1BzLCBl c3BlY2lhbGx5IHRob3NlIHdpdGggY3VzdG9tZXJzIGluIG5vbi1FbmdsaXNoIHNwZWFraW5nIA0K ICAgY291bnRyaWVzLCBjb3VsZCBvZmZlciB0aGlzIHNlcnZpY2UgdG8gdGhlaXIgY3VzdG9tZXJz LiAgDQogICAgDQoNCiAgIDEzLjMgVGVjaG5pY2FsIENoYWxsZW5nZXMgDQoNCiAgICANCiAgIFRo ZSBhdXRvbWF0aWMgdHJhbnNsYXRpb24gb2YgdGV4dCBmb3VuZCBvbiBXZWIgcGFnZXMgaXMgbm90 IGEgDQogICB0cml2aWFsIHRhc2suIEl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRvIHRyYW5zbGF0 ZSBhIFdlYiBwYWdlIA0KICAgYXV0b21hdGljYWxseSB3aXRob3V0IHJ1bm5pbmcgdGhlIHJpc2sg b2YgcmVuZGVyaW5nIHBhcnRzIG9mIGl0IA0KICAgaW5jb21wcmVoZW5zaWJsZS4gV29yc2UgeWV0 LCB0aGUgb3JpZ2luYWwgbWVhbmluZyBjb3VsZCBiZSBjaGFuZ2VkIA0KICAgYW5kIGl0IGlzIG5v dCBzYWlkIHRoZSByZWFkZXIgb2YgdGhlIHRyYW5zbGF0ZWQgcGFnZSB3aWxsIG5vdGljZSB0aGUg DQogICBjaGFuZ2UgaW4gbWVhbmluZy4gSXQgaXMgcXVlc3Rpb25hYmxlIHdoZXRoZXIgY29udGVu dCBwcm92aWRlcnMgDQogICB3b3VsZCBldmVuIHRvbGVyYXRlIHRoaXMga2luZCBvZiB0cmFuc2xh dGlvbiBzZXJ2aWNlLiAgDQogICAgDQogICBUaGVyZWZvcmUgaXQgaXMgdmVyeSBpbXBvcnRhbnQg dGhhdCB0aGUgY2xpZW50IGF1dGhvcml6ZXMgdGhpcyANCiAgIHRyYW5zbGF0aW9uIHNlcnZpY2Ug YW5kIGlzIGZ1bGx5IGF3YXJlIG9mIGl0cyBwb3RlbnRpYWxseSBmYXVsdHkgDQoNCg0KICANCkJl Y2sgZXQgYWwuICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwMDEgICAgICAgICAgICAgICAg ICAgICAgICAgMTMgDQoMDQogICAgICAgICAgIEV4YW1wbGUgU2VydmljZXMgZm9yIE5ldHdvcmsg RWRnZSBQcm94aWVzICAgICAgIE5vdmVtYmVyIDIwMDAgDQoNCiAgIGJlaGF2aW9yLiBJdCBzaG91 bGQgYWxzbyBiZSBjb25zaWRlcmVkIHRvIG1hcmsgdHJhbnNsYXRlZCBwYWdlcyBpbiBhIA0KICAg c3BlY2lmaWMgd2F5IHRvIHJlbWluZCB0aGUgdXNlciBvZiB0aGUgbWFjaGluZSB0cmFuc2xhdGlv bi4gIA0KICAgIA0KICAgT3RoZXIgdGVjaG5pY2FsIGNoYWxsZW5nZXMgaW5jbHVkZSB0aGUgYXV0 b21hdGljIGRldGVjdGlvbiBvZiB0aGUgDQogICBsYW5ndWFnZSB1c2VkIGluIHRoZSBvcmlnaW5h bCBkb2N1bWVudCBhbmQgdGhlIGNsaWVudJJzIGxvY2FsIA0KICAgbGFuZ3VhZ2UuIA0KICAgIA0K ICAgIA0KDQoxNCBBdXRob3IncyBBZGRyZXNzZXMgDQoNCiAgICANCiAgIEFuZHJlIEJlY2sgDQog ICBNYXJrdXMgSG9mbWFubiANCiAgIEJlbGwgTGFicyBSZXNlYXJjaCANCiAgIEx1Y2VudCBUZWNo bm9sb2dpZXMgDQogICAxMDEgQ3Jhd2ZvcmRzIENvcm5lciBSZC4gDQogICBIb2xtZGVsLCBOSiAw NzczMyANCiAgIFBob25lOiAoNzMyKSAzMzItNTk4MyANCiAgIEVtYWlsOiB7YWJlY2ssIGhvZm1h bm59QGJlbGwtbGFicy5jb20gDQogICAgDQogICBNaWNoYWVsIFcuIENvbmRyeSANCiAgIEludGVs IENvcnBvcmF0aW9uIA0KICAgMjExMSBORSAyNXRoIEF2ZW51ZSANCiAgIE0vUyBKRjMtMjA2IA0K ICAgSGlsbHNib3JvLCBPUiA5NzEyNCANCiAgIFBob25lOiA1MDMtMjY0LTkwMTkgDQogICBFbWFp bDogY29uZHJ5QGludGVsLmNvbSANCiAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgDQpCZWNrIGV0IGFsLiAgICAgICAgICAgICAgICBF eHBpcmVzIE1heSAyMDAxICAgICAgICAgICAgICAgICAgICAgICAgIDE0IA0KDA0KICAgICAgICAg ICBFeGFtcGxlIFNlcnZpY2VzIGZvciBOZXR3b3JrIEVkZ2UgUHJveGllcyAgICAgICBOb3ZlbWJl ciAyMDAwIA0KDQogICAgDQoNCjE1IFJlZmVyZW5jZXMgDQoNCiANCiAgIDEgIEJyYWRuZXIsIFMu LCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0tIFJldmlzaW9uIDMiLCBCQ1AgDQog ICAgICA5LCBSRkMgMjAyNiwgT2N0b2JlciAxOTk2LiANCiAgICANCiAgIDIgIFRvbWxpbnNvbiwg Ry4sIGV0IGFsLiwgIkV4dGVuc2libGUgUHJveHkgU2VydmljZXMgRnJhbWV3b3JrIiwgDQogICAg ICBXb3JrIGluIFByb2dyZXNzLCBJbnRlcm5ldCBEcmFmdCBkcmFmdC10b21saW5zb24tZXBzZnct MDAudHh0LCANCiAgICAgIEp1bHkgMjAwMC4gDQogICAgICAgDQogICAzICBXb3JsZCBXaWRlIFdl YiBDb25zb3J0aXVtIChXM0MpLCBodHRwOi8vd3d3LnczLm9yZy4gDQogICAgICAgDQogICA0ICBU aGUgV2lyZWxlc3MgQXBwbGljYXRpb24gUHJvdG9jb2wgKFdBUCkgRm9ydW0sIA0KICAgICAgaHR0 cDovL3d3dy53YXBmb3J1bS5vcmcvLiANCiAgICAgICANCiAgIDUgIElDQVAgUHJvdG9jb2wgR3Jv dXAsICJJQ0FQIC0gdGhlIEludGVybmV0IENvbnRlbnQgQWRhcHRhdGlvbiANCiAgICAgIFByb3Rv Y29sIiwgc3VibWl0dGVkIGFzIEludGVybmV0IERyYWZ0IGRyYWZ0LWVsc29uLW9wZXMtaWNhcC0N CiAgICAgIDAwLnR4dCwgKHByZXZpb3VzIHZlcnNpb24gYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cu aS1jYXAub3JnLyksIA0KICAgICAgTm92ZW1iZXIgMTcsIDIwMDAuIA0KICAgICAgIA0KICAgNiAg UmVzb3VyY2UgRGVzY3JpcHRpb24gRnJhbWV3b3JrIChSREYpLCBodHRwOi8vd3d3LnczLm9yZy9S REYuIA0KICAgICAgIA0KICAgNyAgT3BlbiBQcm94eSBFeHRlbnNpYmxlIFNlcnZpY2VzIChPUEVT KSwgaHR0cDovL3d3dy5leHRwcm94eS5vcmcuIA0KICAgIA0KICAgIA0KICAgIA0KRnVsbCBDb3B5 cmlnaHQgU3RhdGVtZW50IA0KICAgIA0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29j aWV0eSAoMjAwMCkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIA0KICAgIA0KICAgVGhpcyBkb2N1bWVu dCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0byAN CiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVy d2lzZSBleHBsYWluIGl0IA0KICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkg YmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkIA0KICAgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3 aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueSANCiAgIGtpbmQsIHBy b3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBo IA0KICAgYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jr cy4gSG93ZXZlciwgdGhpcyANCiAgIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVk IGluIGFueSB3YXksIHN1Y2ggYXMgYnkgcmVtb3ZpbmcgDQogICB0aGUgY29weXJpZ2h0IG5vdGlj ZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyIA0KICAgSW50 ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2Yg DQogICBkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9j ZWR1cmVzIGZvciANCiAgIGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRh cmRzIHByb2Nlc3MgbXVzdCBiZSANCiAgIGZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0cmFu c2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbiANCiAgIEVuZ2xpc2guIA0KICAgIA0K ICAgVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFu ZCB3aWxsIG5vdCBiZSANCiAgIHJldm9rZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRz IHN1Y2Nlc3NvcnMgb3IgYXNzaWducy4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbiANCiAgICJBUyBJ UyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQgRU5HSU5F RVJJTkcgDQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBP UiBJTVBMSUVELCBJTkNMVURJTkcgDQogICBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZ IFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gDQogDQoNCg0KICANCkJlY2sgZXQgYWwu ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwMDEgICAgICAgICAgICAgICAgICAgICAgICAg MTUgDQoMDQogICAgICAgICAgIEV4YW1wbGUgU2VydmljZXMgZm9yIE5ldHdvcmsgRWRnZSBQcm94 aWVzICAgICAgIE5vdmVtYmVyIDIwMDAgDQoNCiANCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5H RSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQogICBNRVJDSEFOVEFC SUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIA0KICAgIA0KQWNrbm93 bGVkZ2VtZW50IA0KICAgIA0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBlZGl0b3IgZnVuY3Rpb24g aXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgIEludGVybmV0IFNvY2lldHkuIA0KICAg IA0KICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiAgDQpCZWNrIGV0IGFsLiAg ICAgICAgICAgICAgICBFeHBpcmVzIE1heSAyMDAxICAgICAgICAgICAgICAgICAgICAgICAgIDE2 IA0KDA0KDQo= --=_mixed 00112A5FCC2569AA_=-- From owner-ietf-openproxy Sat Dec 2 20:07:07 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA05297 for ietf-openproxy-bks; Sat, 2 Dec 2000 20:07:07 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA05293 for ; Sat, 2 Dec 2000 20:07:05 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Sat Dec 2 23:06:58 EST 2000 Received: from CC998558A (dhcp9145.cs.bell-labs.com [135.104.9.145]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id XAA00632; Sat, 2 Dec 2000 23:07:47 -0500 (EST) From: "Markus Hofmann" To: , Subject: RE: Modified Example Services Draft Date: Sat, 2 Dec 2000 23:07:53 -0500 Message-ID: <000301c05cde$9bfbf610$44510d18@CC998558A> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nick, > How about disability-related services such as web-page > color substitution > for the color-blind, and perhaps even html to streaming > audio translation > for the blind? These are excellent examples, one of my colleagues at Bell Labs also suggested such services. I think we should include them in the next version, thanks for the suggestion! -Markus From owner-ietf-openproxy Sun Dec 3 10:47:25 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA26303 for ietf-openproxy-bks; Sun, 3 Dec 2000 10:47:25 -0800 (PST) Received: from kiwi.equinix.com (kiwi.equinix.com [207.20.85.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26298 for ; Sun, 3 Dec 2000 10:47:23 -0800 (PST) Received: from icooper.equinix.com (dynamic2-204.corp.equinix.com [172.16.2.204]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id KAA25856; Sun, 3 Dec 2000 10:48:42 -0800 (PST) Message-Id: <5.0.2.1.2.20001203104216.00ab4f08@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 03 Dec 2000 10:48:42 -0800 To: Nick.Taptiklis@gregory.co.nz, From: Ian Cooper Subject: Re: Modified Example Services Draft In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 03:07 12/3/2000 +0000, Nick.Taptiklis@gregory.co.nz wrote: >Hi, > >How about disability-related services such as web-page color substitution >for the color-blind, and perhaps even html to streaming audio translation >for the blind? It would probably make a little more sense to broaden the scope of that second one - it's useful to everyone of course (more preferable to receive an audio stream than the text on a smartphone, for example). (I guess the first one is of use to everyone where the designer has chosen color combinations that are unreadable :) ) Given that most visually impaired users would likely already have some screen reading technology, perhaps the scope of the html->audio might be more useful as text augmentation to aid the screen reader? From owner-ietf-openproxy Sun Dec 3 19:21:41 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA15429 for ietf-openproxy-bks; Sun, 3 Dec 2000 19:21:41 -0800 (PST) Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15424 for ; Sun, 3 Dec 2000 19:21:39 -0800 (PST) Received: from condry.intel.com (jfsdun01-088.jf.intel.com [134.134.206.88]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with ESMTP id TAA10864; Sun, 3 Dec 2000 19:35:20 -0800 (PST) Message-Id: <5.0.0.25.2.20001203191713.00a1ceb0@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 03 Dec 2000 19:20:48 -0800 To: Nick.Taptiklis@gregory.co.nz From: "Michael W. Condry" Subject: Re: Modified Example Services Draft Cc: ietf-openproxy@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Seems to fit the existing model as a transcoding function. This might be a good candidate for a special library. The rule model seems to require inputs from the primary data stream (like the web) and the "user" and "content owner". This is a vector off the "user" and primary data stream - allowing this to customize it depending on the user's particular needs rather than a general disability group. At 03:07 AM 12/3/00 +0000, you wrote: >Hi, > >How about disability-related services such as web-page color substitution >for the color-blind, and perhaps even html to streaming audio translation >for the blind? > >Cheers, > >Nick Taptiklis > > > > > >"Markus Hofmann" >Sent by: owner-ietf-openproxy@mail.imc.org >28/11/2000 07:18 > > > To: > cc: > Subject: Modified Example Services Draft > >Hi, > >attached a slightly modified version of the Example Services draft. >We've submitted the modified version, but it will probably not be >published in time for San Diego. > >As usual - comments welcome! > >-Markus > > > Michael W. Condry Director, Internet Strategy Intel Corporation 2111 NE 25th Avenue M/S JF3-206 Hillsboro, OR 97124 503-264-9019 condry@intel.com From owner-ietf-openproxy Sun Dec 3 19:36:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA15779 for ietf-openproxy-bks; Sun, 3 Dec 2000 19:36:14 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA15773 for ; Sun, 3 Dec 2000 19:36:12 -0800 (PST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Sun Dec 3 22:36:13 EST 2000 Received: from CC998558A (dhcp9170.cs.bell-labs.com [135.104.9.170]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id WAA20747; Sun, 3 Dec 2000 22:36:12 -0500 (EST) From: "Markus Hofmann" To: "Michael W. Condry" , Cc: Subject: RE: Modified Example Services Draft Date: Sun, 3 Dec 2000 22:36:19 -0500 Message-ID: <000101c05da3$5d895e70$44510d18@CC998558A> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <5.0.0.25.2.200