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 dra