From owner-ietf-openproxy@mail.imc.org  Tue Sep  3 14:18:03 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08096
	for <opes-archive@ietf.org>; Tue, 3 Sep 2002 14:18:03 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g83Hm5i22349
	for ietf-openproxy-bks; Tue, 3 Sep 2002 10:48:05 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g83Hm0222343
	for <ietf-openproxy@imc.org>; Tue, 3 Sep 2002 10:48:00 -0700 (PDT)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g83HlBp02275;
	Tue, 3 Sep 2002 13:47:11 -0400 (EDT)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <RL8PBH1K>; Tue, 3 Sep 2002 13:47:13 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD7540363565A@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: internet-drafts@ietf.org
Cc: ietf-openproxy@imc.org, "Abbie Barbir" <abbieb@nortelnetworks.com>,
        Marshall Rose <mrose@dbc.mtview.ca.us>, hofmann@bell-labs.com
Subject: draft-ietf-opes-authorization-00.txt
Date: Tue, 3 Sep 2002 13:47:03 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C25371.E935C420"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C25371.E935C420
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C25371.E935C420"


------_=_NextPart_001_01C25371.E935C420
Content-Type: text/plain

Please publish the following as an internet draft. 
thanks  <<draft-ietf-opes-authorization-00.txt>> 
abbie barbir 
abbieb@nortelnetworks.com 


------_=_NextPart_001_01C25371.E935C420
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>draft-ietf-opes-authorization-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Times New Roman">Please publish the following =
as an internet draft.</FONT><FONT FACE=3D"Times New Roman"> </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Times New Roman">thanks</FONT><FONT =
FACE=3D"Times New Roman"><FONT FACE=3D"Arial" SIZE=3D2 =
COLOR=3D"#000000">  =
&lt;&lt;draft-ietf-opes-authorization-00.txt&gt;&gt; </FONT><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Times New Roman">abbie barbir</FONT><FONT =
FACE=3D"Times New Roman"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Times New =
Roman">abbieb@nortelnetworks.com</FONT><FONT FACE=3D"Times New Roman"> =
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C25371.E935C420--

------_=_NextPart_000_01C25371.E935C420
Content-Type: text/plain;
	name="draft-ietf-opes-authorization-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-authorization-00.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                         A. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: March 4, 2003                                          H. =
Orman
                                               Purple Streak =
Development
                                                               A. =
Terzis
                                                   Individual =
Consultant
                                                              O. =
Batuner
                                                                   =
attbi
                                                             B. =
Srinivas
                                                                 T. =
Chan
                                                                   =
Nokia
                                                       September 3, =
2002


     Requirements for Policy, Authorization and Enforcement of OPES
                                Services
                    draft-ietf-opes-authorization-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   This Internet-Draft will expire on March 4, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes policy, authorization and enforcement
   requirements for  the selection of the services to be applied to a



Barbir , et al.          Expires March 4, 2003                  [Page =
1]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   given OPES flow.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  =
3
   2.    Policy Architecture  . . . . . . . . . . . . . . . . . . . .  =
4
   2.1   Policy Components and Functions  . . . . . . . . . . . . . .  =
4
   2.2   Requirements For Policy Decision Point . . . . . . . . . . .  =
6
   2.3   Requirements for Policy Enforcement Points . . . . . . . . .  =
6
   3.    Requirements for Interfaces  . . . . . . . . . . . . . . . .  =
8
   3.1   Service Bindings Requirements  . . . . . . . . . . . . . . .  =
8
   3.1.1 Environment Variables  . . . . . . . . . . . . . . . . . . .  =
8
   3.1.2 Requirements for Using State Information . . . . . . . . . .  =
9
   3.1.3 Requirements for Passing Information Between Services  . . .  =
9
   3.2   Requirements for Rule and Rules Management . . . . . . . . .  =
9
   3.2.1 Requirements for Rule Providers  . . . . . . . . . . . . . .  =
9
   3.2.2 Requirements for Rule Formats and Protocols  . . . . . . . . =
10
   3.2.3 Requirements for Rule Conditions . . . . . . . . . . . . . . =
10
   3.2.4 Requirements for Rule Actions  . . . . . . . . . . . . . . . =
10
   4.    Authentication of Principals and Authorization of
         Services . . . . . . . . . . . . . . . . . . . . . . . . . . =
12
   4.1   End users, Publishers and Other Considerations . . . . . . . =
12
   4.1.1 Considerations for end users . . . . . . . . . . . . . . . . =
12
   4.1.2 Considerations for publishing sites  . . . . . . . . . . . . =
13
   4.1.3 Other considerations . . . . . . . . . . . . . . . . . . . . =
13
   4.2   Authentication . . . . . . . . . . . . . . . . . . . . . . . =
13
   4.3   Authorization  . . . . . . . . . . . . . . . . . . . . . . . =
14
   4.4   Integrity and Encryption . . . . . . . . . . . . . . . . . . =
15
   4.4.1 Integrity and confidentiality of authentication and
         requests/responses for service . . . . . . . . . . . . . . . =
15
   4.4.2 Integrity and confidentiality of application content . . . . =
15
   4.5   Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . . =
16
         References . . . . . . . . . . . . . . . . . . . . . . . . . =
17
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . =
17
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . =
19
         Full Copyright Statement . . . . . . . . . . . . . . . . . . =
20















Barbir , et al.          Expires March 4, 2003                  [Page =
2]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


1. Introduction

   The Open Pluggable Edge Services (OPES) [1]  architecture enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data  consumer.  The OPES processor can distribute
   the responsibility of service execution by communicating and
   collaborating with one or more remote callout servers.

   The execution of such services is governed by a set of rules
   installed on OPES processor.  The rule enforcement can trigger the
   execution of service applications local to the OPES processor or on =
a
   remote callout server.

   Policies express the goals of an OPES processor as a set of rules
   used to administer, manage and control access to resources.  The
   requirements in this document govern the behavior of OPES entities =
in
   determining which, if any, of available services are to be applied =
to
   a given message.

   The scope of OPES policies described in this document are limited to
   those that describe which services to call and, if appropriate, with
   what parameters.  These policies do not include those that prescribe
   the behavior of the called services.  It is desirable to enable a
   common management framework for specifying policies for both the
   calling of and the behavior of a service.  The integration of such
   function is the domain of policy administration user interaction
   applications.

   The document is organized as follows:Section 2 considers policy
   framework.  Section 3 discusses requirements for interfaces, while
   section 4 examines authentication of principals and authorization of
   services.
















Barbir , et al.          Expires March 4, 2003                  [Page =
3]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


2. Policy Architecture

   This section describes the architectural policy decomposition
   requirements.  It also describes the requirements for the interfaces
   between the policy components.

2.1 Policy Components and Functions

   The policy functions are decomposed into three components: a Rule
   Author, a Policy Decision Point (PDP) and Policy Enforcement Point
   (PEP).  The Rule Author provides the rules to be used by an OPES
   entity.  These rules control the invocation of services on behalf of
   the rule author.  The PDP and the PEP interpret the collected rules
   and appropriately enforce them.  The decomposition is illustrated in
   Figure 1.




































Barbir , et al.          Expires March 4, 2003                  [Page =
4]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   =
---------------------------------------------------------------------





         +--------+                         +--------+
         |  Rule  |                         |  Rule  |
         | Author |          ...            | Author |
         +--------+                         +--------+
              |                                 |
              |                                 |
              |          +----------+           |
              |          |  Policy  |           |  <- PDP Interface
              +--------->| Decision |<----------+
                         |  Point   |
                         +----------+
                             | ^
                             | |
                             | |  <- PEP Interface
                             | |
                             V |
                       +--------------+   ...
                  ---> |    Policy    | --->
                       |  Enforcement |       Data Traffic
                  <--- |    Point     | <---
                       +--------------+



                      Figure 1: Policy Components

   =
---------------------------------------------------------------------

   The decomposition of policy control into a PDP and a PEP permit the
   offloading of some tasks to an administrative service that may be
   located on a separate server from the real-time enforcement services
   of the PEP that reside on the OPES processor.

   The PDP provides for the authentication and authorization of rule
   authors and the validation and compilation of rules.

   The PEP resides in the data filter where the data from an OPES flow
   is evaluated against the compiled rules and appropriate calls to the
   requested services are performed.

   Interfaces between these architectural components are points of
   interoperability.  The interface between rule authors and the policy



Barbir , et al.          Expires March 4, 2003                  [Page =
5]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   decision points (PDP Interface) must use the standard format that =
may
   result from the requirements as described in this document.

   The interface between the policy decision points and the policy
   enforcement points (PEP Interface) can be internal to a specific
   vendor implementation of an OPES processor.  Implementations must =
use
   standard interface only if the PDP and the PEP reside on different
   OPES processor.

2.2 Requirements For Policy Decision Point

   The Policy Decision Point is essentially a policy compiler.  The PDP
   must be a service that provides administrative support to the
   enforcement points.  The PDP service must authenticate the rule
   authors.

   The PDP must verify that the specified rules are within the scope of
   the rule authors authority.  The PDP must be a component of the OPES
   Administration Authority.

2.3 Requirements for Policy Enforcement Points

   In the OPES architecture, the data filter represents a Policy
   Enforcement point (PEP).  At this point, data from an OPES flow is
   evaluated against the compiled rules and appropriate calls to the
   requested services are performed.

   In the PEP rules may chain actions together, where, a series of
   services to be called are specified.  Implementation must ensure the
   passing of information from one called service to another.
   Implementation must not prohibit the re-evaluation of a message to
   determine if another service or set of services should be called.

   The execution of an action (i.e., the triggering of a rule) may lead
   to the modification of a message property values.  For example, an
   OPES service that under some circumstances converts JPEG images to
   GIF images modifies the content type of the requested web object.
   Such modification of message property values may change the behavior
   of subsequently performed OPES actions.  The data filter should act
   on matched rules before it evaluates subsequent rules.  Multiple
   matched rules can be triggered simultaneously if the data filter can
   determine in advance that there are no side effects from the
   execution of any specific rule.

   A data filter may evaluate messages several times in the course of
   handling an OPES flow.  The rule processing points may be defined by
   administratively defined names.  The definition of such names can
   serve as a selector for policy rules to determine the applicability



Barbir , et al.          Expires March 4, 2003                  [Page =
6]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   of a rule or a set of rules at each processing point.  The scope of
   policy control of policy roles as defined RFC 3060 should be used
   where it aids in the development of the OPES policy model.

   In Figure 2 a typical message data flow between a data consumer
   application, an OPES processor and a data provider application.
   There are four commonly used processing points identified by the
   numbers 1 through 4.

   =
---------------------------------------------------------------------



           +--------+       +-----------+       +---------+
         |        |<------|4         3|<------|         |
         | Data   |       |  OPES     |       | Data    |
         |Consumer|       | Processor |       |Provider |
         |  Appl. |------>|1         2|------>| Appl.   |
         +--------+       +-----------+       +---------+


                 Figure 2: Processing Execution Points

   =
---------------------------------------------------------------------

   Any data filter (PEP) or any administrative (PDP) implementation =
must
   support the four rule processing points.

   o  Data Consumer Request Handling Role : This involves request
      processing when received from a Data Consumer Application.

   o  OPES Processor Request handling role: This involves request
      processing before forwarding to Data Provider Application.

   o  Data Provider Response handling role: This involves response
      processing when forwarding to Data Consumer Application.

   o  OPES Processor Response handling role:This involves response
      processing when forwarding to Data Consumer Application.












Barbir , et al.          Expires March 4, 2003                  [Page =
7]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


3. Requirements for Interfaces

   The interface between the policy system and OPES services needs to
   include the ability to pass system state information as well as the
   subject message.


3.1 Service Bindings Requirements

   The invoked OPES services must be able to be specified in a location
   independent fashion.  That is, the rule authors need not know and
   need not specify the instance of an OPES service in the rules.

   The rule author should be able to identify the required service at
   the detail level that is appropriate for his or her needs.  The rule
   author should be able to specify a type of service or be able to
   specify any service that fits a general category of service to be
   applied its traffic.

   The binding of OPES service names to specific service may be
   distributed between the PDP and the PEP.  As rules are compiled and
   validated by the PDP, they must be resolved to a specific
   installations' set of homogeneous OPES service.

   The selection of a specific instance may be postponed and left to =
PEP
   to select at either rule installation time or at run time.  To
   achieve interoperability, PEP must support resolving a generic name
   to a specific instance.  It is possible to use services such as SLP
   or UDDI to resolve generic service names to specific OPES service
   instances.

   The policy system may support dynamic discovery of service bindings.
   The rule author may, not know specific service bindings such as
   protocol and parameters, when a rule (as specified on the PDP
   Interface) is general in nature.  The required binding information
   must be provided by the PDP and conveyed on the PEP Interface.  A
   service description methodology such as WSDL must be present in the
   policy system.  It is to be determined whether an OPES standard is
   required.


3.1.1 Environment Variables

   There may be a need to define and support means for maintaining =
state
   information that can be used in both condition evaluation and action
   execution.  Depending on the execution environment, OPES services =
may
   have the freedom to define variables that are needed and use these
   variables to further define   their service behavior without the =
data



Barbir , et al.          Expires March 4, 2003                  [Page =
8]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   filter support.

3.1.2 Requirements for Using State Information

   Policy rules may specify that state information be used as part of
   the evaluation of the rules against a given message in an OPES flow.
   Thus, the policy system should support the maintenance of groups =
that
   can be used in evaluating rule conditions.  Membership in such =
groups
   can be used as action triggers.

   For example, an authorized site blocking service might conclude that
   a particular user shouldn't be permitted access to a certain web
   site.  Rather than calling the service for each request sent by such
   a user, a rule might be created that determine if user is a member =
of
   blocked users and requested site is a member of blocked-sites then
   invoke a local blocking service to return and return an appropriate
   message to the user.

3.1.3 Requirements for Passing Information Between Services

   Environment variables can be used to pass state information between.
   For example, analysis of the request or modifications to the request
   may need to be captured as state information that can be passed to
   other services on the request path or to services on the response(s)
   associated with that request.

   In the PEP, there should be provisions to enable setting up =
variables
   when returning from a service call and passing variables to other
   called services based on policy.


3.2 Requirements for Rule and Rules Management

   This section provides the requirements for rule management.  The
   rules are divided into two groups.  Some rules are provided by the
   data consumer application and other rules are provided by the data
   provider application.

3.2.1 Requirements for Rule Providers

   The requirements for rule providers are:

   o  Rule providers must be authenticated and authorized for rules =
that
      apply to their network role.

   o  Rule providers must not be able to specify rules that are not
      within their scope of authority.




Barbir , et al.          Expires March 4, 2003                  [Page =
9]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   o  Rule providers should be able to only what is needed for their
      services.

   o  Compilation of rules from different sources must not lead to
      execution of conflicting rules.

   o  The resolution of such rule conflicts is out of scope

   o  Rules are assumed to be static and applied to current network
      state.


3.2.2 Requirements for Rule Formats and Protocols

   It is desirable to choose standard technologies like XML to specify
   the rule language format.

   Rules need to be sent form the rule authors to the OPES
   administrative server for service authorization, rule validation and
   compilation.  The mechanisms for doing that are out of scope of the
   current work.

   Once the rules are authorized, validated and compiled by the
   administrative server, the rules need to be sent to the OPES
   processor.  The mechanisms for doing that are out of scope of the
   current work.

3.2.3 Requirements for Rule Conditions

   Rule conditions must be matched against attribute values of the
   encapsulated protocol as well as environment variable values.
   Attribute values of the encapsulated protocol include protocol =
header
   values and possibly also protocol body values.

   Some OPES services may need to be invoked for all users requests or
   server responses, services with logging functionality, as an =
example.
   The rule system should allow unconditional rules rather than
   requiring rule authors to specify rule conditions that are always
   true.

3.2.4 Requirements for Rule Actions

   The rule system must allow for the specification of rule actions =
that
   are triggered if the conditions of a rule are met.  Matched rules
   typically lead to the invocation of local or remote services.  Rule
   actions must identify the OPES service that is to be executed for =
the
   current message request or response.




Barbir , et al.          Expires March 4, 2003                 [Page =
10]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   Rule actions may contain run-time parameters which can be used to
   control the behavior of an OPES service.  If specified, these
   parameters must be passed to the executed OPES service.
















































Barbir , et al.          Expires March 4, 2003                 [Page =
11]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


4. Authentication of Principals and Authorization of Services

   This section considers the authorization and authentication of OPES
   services.

4.1 End users, Publishers and Other Considerations

4.1.1 Considerations for end users

   An OPES rule determines which attributes of traffic will trigger the
   application of an OPES services.  The author of the service can
   supply rules, but the author cannot supply the necessary part of the
   rule precondition that determines which network users will have the
   OPES services applied for them.  This section discusses how users =
are
   identified in the rule preconditions, and how users can select and
   deselect OPES services for their traffic, how an OPES service
   provider should identify the users, and how they determine whether =
or
   not to add their service selection to an OPES enforcement point.

   An OPES service provider must satisfy these major requirements:

   o  Allow all users to request addition, deletion, or blocking of =
OPES
      services for their traffic (blocking means "do not use this
      service for my traffic").

   o  Prevent untrusted users from causing OPES services to interfere
      with the traffic of other users.

   o  Allow users to see their OPES service profiles and notify them of
      changes.

   o  Keep a log of all profile activity for audit purposes.

   o  Adhere to a privacy policy guarding users' profiles.

   The administrator of the PDP is a trusted party and can set policy
   for individuals or groups using out-of-band communication and
   configuration files.  However, users must always be able to query =
the
   PDP in order to learn what rules apply to their traffic.

   Rules can be deposited in the PDP with no precondition relating to
   network users.  This is the way rules are packaged with an OPES
   service when it is delivered for installation.  The PDP is
   responsible for binding identities to the rules and transmitting =
them
   to the PEP.  The identity used by the PDP for policy decisions must
   be strictly mapped to the identity used by the PEP.  Thus, if a user
   goes through and identification and authentication procedure with =
the
   PDP and is known by identity "A", and if the PEP uses IP addresses



Barbir , et al.          Expires March 4, 2003                 [Page =
12]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   for identities, then the PDP must provide the PEP with a binding
   between "A" and A's current IP address.

4.1.2 Considerations for publishing sites

   An OPES service provider acting on behalf of different publishing
   sites should keep all the above considerations in mind when
   implementing an OPES site.  Because each publishing site may be
   represented by only a single identity, the authentication and
   authorization databases may be easier for the PEP to handle.

4.1.3 Other considerations

   Authentication may be necessary between PDP's and PEP's, PEP's and
   callout servers, PEP's and other PEP's, callout servers and other
   callout servers, for purposes of validating privacy policies.  In =
any
   case where user data or traffic crosses trust domain boundaries, the
   originating trust domain should have a policy describing which other
   domains are trusted, and it should authenticate the domains and =
their
   policies before forwarding information.

4.2 Authentication

   When an individual selects (or deselects) an OPES service, the
   individual must be authenticated by the OPES service provider.  This
   means that a binding between the user's communication channel and an
   identity known to the service provider is made in a secure manner.
   This SHOULD be done using a strong authentication method with a
   public key certificate for the user; this will be helpful in
   resolving later disputes.  The service provider MUST keep a log of
   all requests for OPES services.  The service provider SHOULD use
   public key certficates to authenticate responses to requests.

   The service provider may have trusted users who through explicit or
   implicit contract can assign, remove, or block OPES services for
   particular users.  The trusted users must be authenticated before
   being allowed to take actions which will modify the policy base, and
   thus, the actions of the PEP's.

   The PEP's should be authenticated before they receive policy rules
   that reflect the profiles of users.  The PEP's must adhere to the
   privacy preferences of the users.

   When an OPES service provider accepts an OPES service, there must be
   a unique name for the service provided by the entity publishing the
   service.  Users may refer to the unique name when requesting a
   service.  The unique name must be when notifying users about their
   service profiles.  PEP's must be aware of the unique name for each



Barbir , et al.          Expires March 4, 2003                 [Page =
13]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   service that can be accessed from their domain.  There MUST be a
   cryptographic binding between the unique name and the entity
   responsible for the functional behavior of the service; i.e., if it
   is a human language translating service then the name of company =
that
   wrote the software should be bound to the unique name.

4.3 Authorization

   In addition to requesting or terminating specific services, users =
may
   block particular services, indicating that the services should not =
be
   applied to their traffic.  The "block all OPES" directive must be
   supported on a per user basis.

   A response to a request for an OPES service can be positive or
   negative.  Reasons for a negative response include "service unknown"
   or "service denied by PDP policy".  Positive responses should =
include
   the identity of the requestor and the service and the type of
   request.

   As described in the OPES Architecture [1], requests for OPES =
services
   originate in either the enduser or the publisher domain.  The PDP
   bases its authorization decision on the requestor and the domain.
   There are some cases where the decision may be complicated.

   o  The end user has blocked a service, but a trusted user of the PDP
      wants it applied anyway.  In this case, the end user SHOULD
      prevail, unless their are security or legal reasons to leave it =
in
      place.

   o  The publisher and the enduser are in the same domain.  If the
      publisher and enduser are both clients of a PDP, can they make
      requests that effect each other's processing?  In this case, the
      PDP must have policy rules naming the identities that are allowed
      to set such rules.

   o  The publisher requests a service for an enduser.  In this case, =
in
      which the PDP and PEP are in the publisher's administrative
      domain, the publisher has some way of identifying the end user =
and
      his traffic, and the PDP must enable the PEP to enforce the
      policy.  This is allowed, but the PDP MUST use strong methods to
      identify the user and his traffic.  The user must be able to
      request and receive information about the service profile that a
      publisher site keeps about him.

   o  The enduser requests a service specific to a publisher identity
      (e.g., nfl.com), but the publisher prohibits the service (e.g.,
      through a "NO OPES" application header).  As in the case above,
      the publisher must be able to request and receive profile



Barbir , et al.          Expires March 4, 2003                 [Page =
14]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


      information that a user keeps about a publisher.

   In general, the PDP should keep its policy base in a manner that
   makes the decision procedure for all cases easy to understand.

4.4 Integrity and Encryption


4.4.1 Integrity and confidentiality of authentication and requests/
      responses for service

   The requests and responses should be cryptographically tied to the
   identities of the requestor and responder, and the messages should
   not alterable without detection.  A certificate-based digital
   signature is strongly recommended as part of the authentication
   process.  A binding between the request and response should be
   established using well-founded cryptographic means, to show that the
   response is made in reply to a specific request.

4.4.2 Integrity and confidentiality of application content

   As directed by the PEP, content will be transformed in whole or in
   part by OPES services.  This means that end-to-end cryptographic
   protections cannot be used.  This is probably acceptable for the =
vast
   majority of traffic, but in cases where a lesser form of content
   protection is desirable, hop-by-hop protections can be used instead.
   The requirements for such protections are:

   o  Integrity using shared secrets MUST be used between all =
processing
      points, end-to-end (i.e., the two ends a "hop" must share a
      secret, but the secret can be different between "hops").  The
      processing points include the callout servers.

   o  Encryption can be requested separately, with the same secret
      sharing requirement between "hops".  When requested, encryption
      applies to all processing points, including callout servers.

   o  The signal for integrity (and optionally encryption) must
      originate from either the requestor (in which case it is applied
      to the response as well) or the responder (in which case it =
covers
      only the response).

   o  The shared secrets must be unique for each requestor/responder
      pair.







Barbir , et al.          Expires March 4, 2003                 [Page =
15]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


4.5 Privacy

   The PDP must have a privacy policy regarding OPES data such as user
   profiles for services.  User must be able to limit the promulgation
   of their profile data and their identities.

   Supported limitations MUST include:

   o  Identity may not be given to callout servers.

   o  Profile information may not be shared.

   o  Traffic data may not be sent to callout servers run by third
      parties.

   o  Traffic from particular sites should not be given to OPES callout
      servers.

   When an OPES service is provided by a third-party, it must have a
   privacy policy and identify itself to upstream and downstream
   parties, telling them how to access its privacy policy.






























Barbir , et al.          Expires March 4, 2003                 [Page =
16]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


References

   [1]  A. Barbir et. al, "An Architecture for Open Pluggable Edge
        Services (OPES)", Internet-Draft: http://www.ietf.org/internet-
        drafts/draft-ietf-opes-architecture-03.txt, June 2002.

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
        Waldbusser, "Terminology for Policy-Based Management", RFC =
3198,
        November 2001.

   [4]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com


   Hilarie Orman
   Purple Streak Development



   Phone:
   EMail: ho@alum.mit.edu


   Andreas Terzis
   Individual Consultant
   150 Golf Course Dr.
   Rohnert Park, CA  94928
   USA

   EMail: aterzis@sbcglobal.net



Barbir , et al.          Expires March 4, 2003                 [Page =
17]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


   Oskar Batuner
   attbi



   EMail: batuner@attbi.com


   Bindignavile Srinivas
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: bindignavile.srinivas@nokia.com


   Tat Chan
   Nokia
   5 Wayside Road
   Burlington, MA  01803
   USA

   EMail: Tat.Chan@nokia.com



























Barbir , et al.          Expires March 4, 2003                 [Page =
18]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


Appendix A. Acknowledgements

   TBD
















































Barbir , et al.          Expires March 4, 2003                 [Page =
19]
=0C
Internet-Draft    Requirements for Policy, Authorization and =
Enforcement of OPES Services                                            =
                  September 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barbir , et al.          Expires March 4, 2003                 [Page =
20]
=0C




------_=_NextPart_000_01C25371.E935C420--


From owner-ietf-openproxy@mail.imc.org  Wed Sep  4 08:19:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24617
	for <opes-archive@ietf.org>; Wed, 4 Sep 2002 08:19:04 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g84Bwna11901
	for ietf-openproxy-bks; Wed, 4 Sep 2002 04:58:49 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g84Bwm211897
	for <ietf-openproxy@imc.org>; Wed, 4 Sep 2002 04:58:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23570;
	Wed, 4 Sep 2002 07:57:13 -0400 (EDT)
Message-Id: <200209041157.HAA23570@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-openproxy@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-opes-authorization-00.txt
Date: Wed, 04 Sep 2002 07:57:13 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF.

	Title		: Requirements for Policy, Authorization and Enforcement
                          of OPES Services
	Author(s)	: A. Barbir et al.
	Filename	: draft-ietf-opes-authorization-00.txt
	Pages		: 20
	Date		: 2002-9-3
	
This document describes policy, authorization and enforcement
requirements for  the selection of the services to be applied to a
given OPES flow.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-authorization-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-opes-authorization-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-opes-authorization-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-9-3151127.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-authorization-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-authorization-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-9-3151127.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Tue Sep 17 00:01:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24400
	for <opes-archive@ietf.org>; Tue, 17 Sep 2002 00:01:04 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8H3aJ020658
	for ietf-openproxy-bks; Mon, 16 Sep 2002 20:36:19 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8H3aHk20654
	for <ietf-openproxy@imc.org>; Mon, 16 Sep 2002 20:36:17 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout06.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002))
 with ESMTP id <0H2K00HGCCOFZI@mtaout06.icomcast.net> for
 ietf-openproxy@imc.org; Mon, 16 Sep 2002 23:36:16 -0400 (EDT)
Date: Mon, 16 Sep 2002 23:36:15 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: OPES Status Update, Drafts, ICAP
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3D86A32F.7080508@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
 Gecko/20020826
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Hi,

time for a brief status update on our OPES activities and on immediate 
next steps.

Document Status
===============
Three WG drafts have been submitted to the IESG for consideration as 
informal RFC, namely

  "An Architecture for Open Pluggable Edge Services (OPES)"
  "Requirements for OPES Callout Protocols"
  "OPES Use Cases and Deployment Scenarios"

The first version of our "document on endpoint authorization and 
enforcement requirements", named

   "Requirements for Policy, Authorization and Enforcement of OPES
    Services"

has been published as Internet Draft. Please read it carefully and 
provide comments and feedback via this mailing list ASAP. We'd like to 
wrap up this draft very soon - please read and discuss it *now*!

A few folks are currently preparing a first version of our "document 
on threat/risk model for OPES services". We expect to have it 
pusblished as an Internet Draf in October, in time for the next IETF 
meeting.

OPES Protocol Work
==================
Since we hope being able to close pretty soon on the five initial 
documents that somehow lay the foundation for our more technical work, 
it's time to start thinking on how to get started on the OPES protocol 
work.

Looking at the charter, we see that "The working group will consider 
the ICAP protocol drafts as an OPES precursor and will will support 
development of an analysis that explains the limitations of ICAP, to 
accompany informational publication of that protocol.".

As such, it's time for all of us to carefully read the ICAP Internet Draft

   "ICAP - the Internet Content Adaptation Protocol"
    draft-elson-icap-01.txt

and to provide comments on this protocol specification in the context 
of OPES. Please be aware that the ICAP specification is *not* a 
product of the OPES WE, but represents an individual submission, 
documenting a "status quo". Nevertheless, it's of quite some relevance 
for our WG, and we better have a careful look at and comment on it. In 
particular, it might be interesting to discuss:

  (a) How does ICAP fit into the OPES context and how does it stack
      up to the OPES protocol requirements?
  (b) If there are open issues, would it make sense for the WG trying
      to recommend extensions toICAP so that it'll meet all
      requirements?
  (c) What are the strengths, the weaknesses, and the limitations of
      the current ICAP specification? Are there lesson to be learned
      from the spec and from the work on ICAP?
  (d) Given that there are several (commercial) implementations
      of ICAP out and in use - are there any lesses learned from these
      implementations? Is the current specification stable and clear,
      or are there any open issues or issues to clarify?
  (e) Are there any findings/measurements with respect to ICAP
      performance that would be interesting to be shared with the WG?
  (f) More, more, more,... please add...

A good starting point might also be the individual Internet Draft on

   "Evaluating the ICAP protocol regarding the OPES callout protocol
    requirements"
    draft-stecher-opes-icap-eval-00.txt

So, please check out both ICAP-related drafts and share your thoughts 
on this mailing list. Should be enough material for some interessting 
discussions.

Cheers,
   Markus



From owner-ietf-openproxy@mail.imc.org  Wed Sep 18 17:11:32 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00210
	for <opes-archive@ietf.org>; Wed, 18 Sep 2002 17:11:32 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g8IKfmQ14406
	for ietf-openproxy-bks; Wed, 18 Sep 2002 13:41:48 -0700 (PDT)
Received: from mout0.freenet.de (exim@mout0.freenet.de [194.97.50.131])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8IKfkk14399
	for <ietf-openproxy@imc.org>; Wed, 18 Sep 2002 13:41:46 -0700 (PDT)
Received: from [194.97.50.138] (helo=mx0.freenet.de)
	by mout0.freenet.de with esmtp (Exim 4.10)
	id 17rlds-0005La-00
	for ietf-openproxy@imc.org; Wed, 18 Sep 2002 22:41:48 +0200
Received: from b65e2.pppool.de ([213.7.101.226] helo=faust)
	by mx0.freenet.de with esmtp (Exim 4.10 #1)
	id 17rldr-0000YV-00
	for ietf-openproxy@imc.org; Wed, 18 Sep 2002 22:41:47 +0200
Received: from ralf by faust with local (Exim 3.35 #1 (Debian))
	id 17rlc8-0000oW-00; Wed, 18 Sep 2002 22:40:00 +0200
Date: Wed, 18 Sep 2002 22:39:59 +0200
From: Ralf Horstmann <Ralf.Horstmann@gmx.de>
To: ietf-openproxy@imc.org
Subject: Re: OPES Status Update, Drafts, ICAP
Message-ID: <20020918203959.GA2400@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-Node: faust
X-Operating-System: Debian GNU/Linux Sid
X-Kernel: Linux 2.4.17
X-Keyserver: http://www.keyserver.net
X-Fingerprint: B422 6B3D 8278 74C3 FEC9  BF33 9E49 D321 D96D 7241
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


On Mon, 16 Sep 2002, Markus Hofmann wrote:

> time for a brief status update on our OPES activities and on 
> immediate 
> next steps.

[...]

> As such, it's time for all of us to carefully read the ICAP 
> Internet Draft
> 
>    "ICAP - the Internet Content Adaptation Protocol"
>     draft-elson-icap-01.txt
> 
> and to provide comments on this protocol specification in the context 
> of OPES. Please be aware that the ICAP specification is *not* a 
> product of the OPES WE, but represents an individual submission, 
> documenting a "status quo". Nevertheless, it's of quite some 
> relevance 
> for our WG, and we better have a careful look at and comment 
> on it. In 
> particular, it might be interesting to discuss:
> 
>   (a) How does ICAP fit into the OPES context and how does it stack
>       up to the OPES protocol requirements?
>   (b) If there are open issues, would it make sense for the WG trying
>       to recommend extensions toICAP so that it'll meet all
>       requirements?
>   (c) What are the strengths, the weaknesses, and the limitations of
>       the current ICAP specification? Are there lesson to be learned
>       from the spec and from the work on ICAP?
>   (d) Given that there are several (commercial) implementations
>       of ICAP out and in use - are there any lesses learned from these
>       implementations? Is the current specification stable and clear,
>       or are there any open issues or issues to clarify?

I'm working on the ICAP client implementation for Squid. See
http://icap-server.sourceforge.net/squid.html for details. 
The ICAP specs were quite useful to get the implementation
ICAP/1.0-compliant. In my opinion the specification is clear and ensures
that different ICAP implementations will work just fine together.

Regards, Ralf.

--
ruby -h | ruby -e 'a=[];readlines.join.\
scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) \
{|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'  


From owner-ietf-openproxy@mail.imc.org  Mon Sep 23 07:36:16 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04780
	for <opes-archive@ietf.org>; Mon, 23 Sep 2002 07:36:15 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8NBBse01220
	for ietf-openproxy-bks; Mon, 23 Sep 2002 04:11:54 -0700 (PDT)
Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8NBBrv01215
	for <ietf-openproxy@imc.org>; Mon, 23 Sep 2002 04:11:53 -0700 (PDT)
Received: from garner.india.hp.com (garner.india.hp.com [15.10.45.11])
	by palrel10.hp.com (Postfix) with ESMTP
	id 5FB11C004B0; Mon, 23 Sep 2002 04:11:40 -0700 (PDT)
Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86])
	by garner.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id QAA08205;
	Mon, 23 Sep 2002 16:48:40 +0530 (IST)
Message-ID: <3D8EF700.A1A1FDB@india.hp.com>
Date: Mon, 23 Sep 2002 16:42:00 +0530
From: Geetha Manjunath <geetham@india.hp.com>
Organization: Hewlett Packard ISO
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Markus Hofmann <markus@mhof.com>
Cc: OPES Group <ietf-openproxy@imc.org>
Subject: Re: OPES Status Update, Drafts, ICAP
References: <3D86A32F.7080508@mhof.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hi All,
Thought I would share some of my experiences in implementing ICAP and
using the same in the OPES context as a response to Markus Hofmann's 
call. 

Some background: I have worked on providing ICAP client support in two
proxy servers: squid proxy cache and tinyproxy plus implemented an  ICAP
server in python with an IRML rule engine (at the server-side rather
than the client-side). 
So, some comments are specifically on ICAP and some or in the more
general OPES context.

Some observations:
1. ICAP *is* really a light weight protocol to encapsulate HTTP requests
and responses. 
  ** It requires minimal additional info apart from the payload to be
sent to the server.
  ** The static code size requirements for icap client in a restricted
mem environment was just about 2%  (an additional 6Kbytes to 273 KBytes
tinyproxy code).
2. The PREVIEW header support in the protocol is very useful in
optimizing response modification. Though I do not have real measurements
to prove this as of now, I have found a significant difference in the
response time. More so, when I have no specific filter applied at the
proxy  side and send out all responses for modification.
3. The specification is pretty clear and helps in building
interoperable  servers and clients.

Possible enhancements to ICAP protocol:
*   Standardizing some additional headers to convey client and
subscriber information may be useful - could be along the lines of the
draft on
OPES Subscriber Identification.
*   Security: Minimum support for security may be provided by just
supporting an additional header similar to WWW-authenticate.


OPES:
*   Though the decision on standardising multiple content modifications
is deferred here, personally I found multiple 'request' modifications
very useful and mostly without conflicts. They result in extremely
simple proxylets that can be combined very effectively to get the
required result. In  fact, the best way to get that going, I found, was
to do the rule processing in the ICAP server end rather than in the
proxy  server. That way  you need to send the HTTP request only once.
BTW, all these are w.r.t demo prototypes not really a commercial
deployment scenario.
*   OPES docs suggest control on content modification rules by three
parties, viz., (a) client/subscriber (b) ISP and (c) content provider. A
means for providing this  control is  yet to be proposed (to my
knowledge). Specifically, if the client needs to have a control on the
rules at the granularity of every request, this can   be done by
introducing an additional info in the HTTP header (or use the 
cache-control header).

Hope this is useful.

Thanks and regards,
Geetha

Markus Hofmann wrote:
> 
> Hi,
> 
> time for a brief status update on our OPES activities and on immediate
> next steps.
> 
> ... stripped ...
>
> As such, it's time for all of us to carefully read the ICAP Internet Draft
> 
>    "ICAP - the Internet Content Adaptation Protocol"
>     draft-elson-icap-01.txt
> 
> and to provide comments on this protocol specification in the context
> of OPES. Please be aware that the ICAP specification is *not* a
> product of the OPES WE, but represents an individual submission,
> documenting a "status quo". Nevertheless, it's of quite some relevance
> for our WG, and we better have a careful look at and comment on it. In
> particular, it might be interesting to discuss:
> 
>   (a) How does ICAP fit into the OPES context and how does it stack
>       up to the OPES protocol requirements?
>   (b) If there are open issues, would it make sense for the WG trying
>       to recommend extensions toICAP so that it'll meet all
>       requirements?
>   (c) What are the strengths, the weaknesses, and the limitations of
>       the current ICAP specification? Are there lesson to be learned
>       from the spec and from the work on ICAP?
>   (d) Given that there are several (commercial) implementations
>       of ICAP out and in use - are there any lesses learned from these
>       implementations? Is the current specification stable and clear,
>       or are there any open issues or issues to clarify?
>   (e) Are there any findings/measurements with respect to ICAP
>       performance that would be interesting to be shared with the WG?
>   (f) More, more, more,... please add...
> 
> A good starting point might also be the individual Internet Draft on
> 
>    "Evaluating the ICAP protocol regarding the OPES callout protocol
>     requirements"
>     draft-stecher-opes-icap-eval-00.txt
> 
> So, please check out both ICAP-related drafts and share your thoughts
> on this mailing list. Should be enough material for some interessting
> discussions.
> 
> Cheers,
>    Markus


From owner-ietf-openproxy@mail.imc.org  Mon Sep 23 23:16:06 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05556
	for <opes-archive@ietf.org>; Mon, 23 Sep 2002 23:16:05 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8O2o0D22591
	for ietf-openproxy-bks; Mon, 23 Sep 2002 19:50:00 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8O2nxv22587
	for <ietf-openproxy@imc.org>; Mon, 23 Sep 2002 19:49:59 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout05.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002))
 with ESMTP id <0H2X001VF9798I@mtaout05.icomcast.net> for
 ietf-openproxy@imc.org; Mon, 23 Sep 2002 22:49:57 -0400 (EDT)
Date: Mon, 23 Sep 2002 22:49:57 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: OPES Status Update, Drafts, ICAP
To: Geetha Manjunath <geetham@india.hp.com>
Cc: OPES Group <ietf-openproxy@imc.org>
Message-id: <3D8FD2D5.1040308@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a)
 Gecko/20020910
References: <3D86A32F.7080508@mhof.com> <3D8EF700.A1A1FDB@india.hp.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Hi,

thanks to Ralf and to Geetha for their comments! It's good to get 
"real life" feedback from practial experience and implementation efforts.

So far, it seems that the ICAP protocol specification in its current 
form does not have major hiccups that would leave room for 
misinterpretation and interoperability problems. However, did somebody 
actually do some interoperability tests of different ICAP 
implementations? Do different, independent ICAP implementations that 
conform to the current spec easily interoperate with each other, or 
are there parts that leave room for different interpretations?

Now, we also need to look beyond questions about the clearness and the 
stability of the current ICAP specification. I'd like to get some 
feedback on how people feel of ICAP with respect to the laid out OPES 
architecture and the OPES protocol requirements. How does ICAP fit 
into this picture? Are their major roadblocks, minor issues that could 
be "fixed", or is the current ICAP perfectly fine?

Please take some time and think about it. If nobody has an opinion 
about it, we should probably declare ICAP to be "the" OPES protocol, 
declare victory, and check this item off our list of deliverables. If 
you don't like this idea, please raise your voice *now* and share your 
concerns, the limitations you see, and how they could be addressed best.

Geetha already had some very specific comments.

> 2. The PREVIEW header support in the protocol is very useful in
> optimizing response modification. 

I can see and agree that the "preview" mechanism is quite useful in 
several secnarios. However, it requires that the preview size is 
statically agreed on a-priori. I could imagine that there are services 
that can deliver a final response before receiving the entire message, 
but without knowing how many bytes (i.e. preview size) they need to 
see before being able to do so. Simple example: A filtering service 
searching for certain keywords in the message. As soon as a forbidden 
keyword is detected, there's no need to further analyze the reminder 
of the message, the transaction can be finished immediately. So, it 
would be nice to have a more general mechanism that would allow the 
callout server to present a final response to a transaction at any 
given time, and not only after receiving the preview or after 
receivingthe entire message.

> Possible enhancements to ICAP protocol:
> *   Standardizing some additional headers to convey client and
> subscriber information may be useful - could be along the lines of the
> draft on
> OPES Subscriber Identification.

Absolutely, such additions are a "must" for certain services. The 
draft you refer to above provides a simple solution for transmitting 
basic subscriber identification. It might be interesting to explore 
whether there's a need for transmitting more generl/comples subscriber 
information. The callout protocol should support that.

> *   Security: Minimum support for security may be provided by just
> supporting an additional header similar to WWW-authenticate.

The OPES protocol requirements seem to go even further...

> *   Though the decision on standardising multiple content modifications
> is deferred here, personally I found multiple 'request' modifications
> very useful [...]

I agree, although correct error hendling might become quite complex. 
For example, how should the system behave if one of the many services 
fails? What would be the response, how to signal the user which 
service failed, what about tracing of OPES services,...

> *   OPES docs suggest control on content modification rules by three
> parties, viz., (a) client/subscriber (b) ISP and (c) content provider. 

OPES defines services to be executed only if authorized by either of 
*two* parties - the content consumer and/or the content provider. The 
ISP or network provider is not defined being able to authorize service 
execution.

> means for providing this  control is  yet to be proposed (to my
> knowledge). 

The OPES WG will work on methods/languages for specifying rules, but 
it will *not* specify how these rules are actually distributed. (From 
our charter: "The working group will define one or more methods for 
specification of policies, as well as the rules that enable 
application endpoints to control execution of such services").

OK, thanks for the comments so far. Keep it rolling, we need much more 
input!


-Markus



From owner-ietf-openproxy@mail.imc.org  Tue Sep 24 06:57:53 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22353
	for <opes-archive@ietf.org>; Tue, 24 Sep 2002 06:57:52 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8OAO6K03456
	for ietf-openproxy-bks; Tue, 24 Sep 2002 03:24:06 -0700 (PDT)
Received: from host070.webwasher.com (host070.webwasher.com [195.162.240.70])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8OAO3v03452
	for <ietf-openproxy@imc.org>; Tue, 24 Sep 2002 03:24:04 -0700 (PDT)
Received: from hermes.webwasher.com [192.168.1.3] id V6GXVSAJ; 24 Sep 2002 12:33:49 +0100
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: OPES Status Update, Drafts, ICAP
Date: Tue, 24 Sep 2002 12:21:43 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BFBB@hermes.webwasher.com>
Thread-Topic: OPES Status Update, Drafts, ICAP
Thread-Index: AcJjdpocJAVev0iXRJyyXPs+zvlU9wANzC5Q
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8OAO5v03453
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi.

> 
> So far, it seems that the ICAP protocol specification in its current 
> form does not have major hiccups that would leave room for 
> misinterpretation and interoperability problems. However, did 
> somebody 
> actually do some interoperability tests of different ICAP 
> implementations? Do different, independent ICAP implementations that 
> conform to the current spec easily interoperate with each other, or 
> are there parts that leave room for different interpretations?
> 

I tested the WebWasher ICAP server against five different ICAP clients and I tested the WebWasher ICAP client against three different ICAP servers.
During testing (or later in productive environments) we found some communication problems. But for all of these problems the protocol draft gave us a clear statement which side was correct and which side was wrong. After fixing the problems we run with all the mentioned clients and servers without having any special workaround code except of one setting that addresses a typical problem I found several ICAP clients have in the beginning and which is usually solved in later revisions of the ICAP client: Handling an ICAP response header which is sent in multiple TCP packets. (This problem is beyond the protocol specifications)

So from my experience the protocol draft is really clear in how to design interoperable implementations.
On the other hand I already saw a switch in another ICAP client to set the type of ICAP server. I have no testing experience with the servers mentioned there. So there may be protocol problems that I am not aware of or just bugs that have been worked around that way.

I hope that the guys that experienced the reason for such a switch will speak up in this forum and share their experience with this group.


> Now, we also need to look beyond questions about the 
> clearness and the 
> stability of the current ICAP specification. I'd like to get some 
> feedback on how people feel of ICAP with respect to the laid out OPES 
> architecture and the OPES protocol requirements. How does ICAP fit 
> into this picture? Are their major roadblocks, minor issues 
> that could 
> be "fixed", or is the current ICAP perfectly fine?

ICAP is good but not perfect I think. Please check again my evaluation paper (draft-stecher-opes-icap-eval-00.txt)
It could be a good starting base. For me the OPES protocol could be an ICAP/2.0 implementation.

> 
> > 2. The PREVIEW header support in the protocol is very useful in
> > optimizing response modification. 
> 
> I can see and agree that the "preview" mechanism is quite useful in 
> several secnarios. However, it requires that the preview size is 
> statically agreed on a-priori. I could imagine that there are 
> services 
> that can deliver a final response before receiving the entire 
> message, 
> but without knowing how many bytes (i.e. preview size) they need to 
> see before being able to do so. Simple example: A filtering service 
> searching for certain keywords in the message. As soon as a forbidden 
> keyword is detected, there's no need to further analyze the reminder 
> of the message, the transaction can be finished immediately. So, it 
> would be nice to have a more general mechanism that would allow the 
> callout server to present a final response to a transaction at any 
> given time, and not only after receiving the preview or after 
> receivingthe entire message.
> 

I fully agree: Having a flexible number of decision points in the protocol would be a big plus.

Beside this I believe that although ICAP is simple, the protocol could even be simpler. It's one and a half year ago that I started the discussion about the Encapsulated headers and a proposal to simplify things using more chunk extensions.

Meanwhiletime I have strong interest to have a callout protocol that it able to support many different application protocols. OPES wants to concentrate on HTTP and RTP first which is fine but we should prepare the protocol from the very beginning to be easily extendable.

We have some experience how to encapsulate FTP and even SMTP into ICAP although ICAP is specifically designed for HTTP and while FTP encapsulation is still simple, the SMTP stuff is much harder because of one important difference: The HTTP and FTP data is sent to one recipient (the requesting client) while a mail message is sent to many different recipients that could have different filtering needs. ICAP is not prepared to handle this.


Martin


From owner-ietf-openproxy@mail.imc.org  Wed Sep 25 00:34:32 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21141
	for <opes-archive@ietf.org>; Wed, 25 Sep 2002 00:34:32 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8P466F05216
	for ietf-openproxy-bks; Tue, 24 Sep 2002 21:06:06 -0700 (PDT)
Received: from hclnpd.hclt.co.in ([202.54.64.7])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8P465v05210
	for <ietf-openproxy@imc.org>; Tue, 24 Sep 2002 21:06:05 -0700 (PDT)
Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id SP90TN7P; Wed, 25 Sep 2002 09:36:10 +0530
Received: from npd.hcltech.com (akolappa-pc.hclt-ntl.co.in [192.168.19.91])
	by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g8ODhZQ29835
	for <ietf-openproxy@imc.org>; Tue, 24 Sep 2002 19:13:36 +0530
Message-ID: <3D906E8F.60F85482@npd.hcltech.com>
Date: Tue, 24 Sep 2002 19:24:23 +0530
From: Arumugam K <akolappa@npd.hcltech.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: Re: OPES Status Update, Drafts, ICAP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hi all,


   The following are the few points about the ICAP protocol
   we would like to share.


1. A single client request-response flow could include both reqmod and
   respmod modifications. This could be explicitly mentioned in the
draft.
   An example could be the decompression service.
   ( This service is mentioned in the 4 point)

2. One concern over the request modification.

   Icap client sends  the client request to icap server. The icap server
   could sent an adapted request , an HTTP error message
   indicating the client request is prohibited or ICAP error msg.

    The icap server sends ICAP error msg due to an error in ICAP
    semantics such as ICAP request is not correct or service not
available.
    In this case , the icap client can either forward the original
    request without any modification to OS or send an error msg to 
    client stating that the service could not be provided.

    It would be useful if the draft says how to handle this scenario.


3. The draft is not posing any prerequisite to the tools used to provide
   the actual services. Based on the protocol , it seems to be valid to
   have few prerequisite on the service tools.

   1. The tool has to be run in non-interactive mode. GUI interface is
      not needed.

   2. The tool should be started by cli. Allows to pass command line
      arguments.

   3. In the simplest form, each instance of the tool serves only one
      request.Considering the overhead due to the size of the tool and 
      time to load and make it ready , it would be fine to make a single
      instance of the tool to serve multiple requests either
      sequentially or parallely. I am not sure how far this is
achievable.


4. It could be possible to make use of the ICAP protocol for real
   bandwidth savings.This is possible by providing a service 
   called decompression.

   For example, consider a scenario.
   The client makes a request to html page in OS. Due to ICAP ,a request 
   with  a url which points to the compressed copy of the html page is
   sent to OS. This is done in REQMOD mode.

   OS sends back the compressed data. The compressed data is sent to
   ICAP server which can decompress and send the data in the format 
   requested by the end-user. This is done in RESPMOD mode.

   Thus the bandwidth needed to transfer the html page is reduced to the
   level of compression.

   If this service is considered as a valid one, then this service could
   be mentioned in the draft.


Regards
Arumugam

-- 
Visit us at http://cdn.hcltech.com


From owner-ietf-openproxy@mail.imc.org  Wed Sep 25 03:37:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17800
	for <opes-archive@ietf.org>; Wed, 25 Sep 2002 03:37:03 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8P7Aib23040
	for ietf-openproxy-bks; Wed, 25 Sep 2002 00:10:44 -0700 (PDT)
Received: from host070.webwasher.com (host070.webwasher.com [195.162.240.70])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g8P7Agv23033
	for <ietf-openproxy@imc.org>; Wed, 25 Sep 2002 00:10:43 -0700 (PDT)
Received: from hermes.webwasher.com [192.168.1.3] id 03BITTCR; 25 Sep 2002 09:20:48 +0100
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: OPES Status Update, Drafts, ICAP
Date: Wed, 25 Sep 2002 09:08:35 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BFBE@hermes.webwasher.com>
Thread-Topic: OPES Status Update, Drafts, ICAP
Thread-Index: AcJkSj5q7SSVa811STu4SOGU0D0GbQAFWMFw
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "Arumugam K" <akolappa@npd.hcltech.com>,
        "OPES Group" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g8P7Ahv23037
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi Arumugam,

> 2. One concern over the request modification.
> 
>    Icap client sends  the client request to icap server. The 
> icap server
>    could sent an adapted request , an HTTP error message
>    indicating the client request is prohibited or ICAP error msg.
> 
>     The icap server sends ICAP error msg due to an error in ICAP
>     semantics such as ICAP request is not correct or service not
> available.
>     In this case , the icap client can either forward the original
>     request without any modification to OS or send an error msg to 
>     client stating that the service could not be provided.
> 
>     It would be useful if the draft says how to handle this scenario.
> 

There is no clear way how to handle this.
Examples:
 - If a virus filtering RESPMOD service sends an ICAP error, the original request is probably better not bypassed
- If an advertising removal RESPMOD service sends an ICAP error, bypassing the original response is probably the prefered option.
- If an Internet Access Management REQMOD service sends an ICAP error, there will be companies that would allow a bypass while others prefer to block the request.

So usually the bypass flag is an option to set with the ICAP service that is defined at the ICAP client. It does not belong to the protocol specs, I think.

> 
> 3. The draft is not posing any prerequisite to the tools used 
> to provide
>    the actual services. Based on the protocol , it seems to 
> be valid to
>    have few prerequisite on the service tools.
> 
>    1. The tool has to be run in non-interactive mode. GUI interface is
>       not needed.
> 
>    2. The tool should be started by cli. Allows to pass command line
>       arguments.
> 
>    3. In the simplest form, each instance of the tool serves only one
>       request.Considering the overhead due to the size of the 
> tool and 
>       time to load and make it ready , it would be fine to 
> make a single
>       instance of the tool to serve multiple requests either
>       sequentially or parallely. I am not sure how far this is
> achievable.
> 

Does this belong to the protocol specs?

> 
> 4. It could be possible to make use of the ICAP protocol for real
>    bandwidth savings.This is possible by providing a service 
>    called decompression.
> 
>    For example, consider a scenario.
>    The client makes a request to html page in OS. Due to ICAP 
> ,a request 
>    with  a url which points to the compressed copy of the html page is
>    sent to OS. This is done in REQMOD mode.
> 
>    OS sends back the compressed data. The compressed data is sent to
>    ICAP server which can decompress and send the data in the format 
>    requested by the end-user. This is done in RESPMOD mode.
> 
>    Thus the bandwidth needed to transfer the html page is 
> reduced to the
>    level of compression.
> 
>    If this service is considered as a valid one, then this 
> service could
>    be mentioned in the draft.
> 
> 

While having good examples in a draft is nice for easier understanding, it is impossible to provide the full list of all valid and usefull services.
I think a place like the ICAP forum is better to collect all ideas for ICAP services.

Regards
Martin


From owner-ietf-openproxy@mail.imc.org  Wed Sep 25 10:28:11 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27579
	for <opes-archive@ietf.org>; Wed, 25 Sep 2002 10:28:10 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PE1Xc01424
	for ietf-openproxy-bks; Wed, 25 Sep 2002 07:01:33 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PE1Vv01417
	for <ietf-openproxy@imc.org>; Wed, 25 Sep 2002 07:01:32 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout02.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002))
 with ESMTP id <0H2Z0013IYYFZA@mtaout02.icomcast.net> for
 ietf-openproxy@imc.org; Wed, 25 Sep 2002 10:01:27 -0400 (EDT)
Date: Wed, 25 Sep 2002 10:01:27 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: Re: OPES Status Update, Drafts, ICAP
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3D91C1B7.2020104@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a)
 Gecko/20020910
References: <72992B39BBD9294BB636A960E89AE02E50BFBE@hermes.webwasher.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Martin Stecher wrote:

 > So usually the bypass flag is an option to set with the ICAP
 > service that is defined at the ICAP client. It does not belong to
 > the protocol specs, I think.

I agree with Martin that this is *not* a protocol issue. The protocol 
only provides the means to inform the OPES proessor (i.e. the ICAP 
client) about the result of the callout service. The reaction of the 
OPES processr (i.e. the ICAP client) depends on the preferences as 
specified by the user - user A might want to simply bypass the 
service, while user B might want to block the transaction if the 
service cannot be executed (most likely will also depend on the type 
of service). This is not really related to the protocol, but much more 
to the rules specificatin language (which is also a work item of this WG).

 >> 3. The draft is not posing any prerequisite to the tools used to
 >> provide the actual services. Based on the protocol , it seems to
 >> be valid to have few prerequisite on the service tools.
 >> [...]
 >
 > Does this belong to the protocol specs?

Nup, don't think so. These are more (local) implementation decisions. 
And although the issues mentioned might make sense, they're 
independent and don't have an impact on the protocol itself.

 > While having good examples in a draft is nice for easier
 > understanding, it is impossible to provide the full list of all
 > valid and usefull services. I think a place like the ICAP forum is
 > better to collect all ideas for ICAP services.

An even better place would have been this mailing list, since the WG 
has been workig on a use cases draft :) Nevertheless, it's clear we 
cannot provide a complete list of examples, and the current use case 
draft should cover a representative set.

-Markus



From owner-ietf-openproxy@mail.imc.org  Wed Sep 25 17:41:59 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11060
	for <opes-archive@ietf.org>; Wed, 25 Sep 2002 17:41:59 -0400 (EDT)
Received: (from majordomo@localhost)
	by above.proper.com (8.11.6/8.11.3) id g8PL59g25739
	for ietf-openproxy-bks; Wed, 25 Sep 2002 14:05:09 -0700 (PDT)
Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g8PL58v25735
	for <ietf-openproxy@imc.org>; Wed, 25 Sep 2002 14:05:08 -0700 (PDT)
Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10])
	by dirty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g8PL5AhN001196
	for <ietf-openproxy@imc.org>; Wed, 25 Sep 2002 17:05:10 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g8PL53I52517
	for <ietf-openproxy@imc.org>; Wed, 25 Sep 2002 17:05:03 -0400 (EDT)
Received: from bell-labs.com ([135.180.160.178])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA12134
	for <ietf-openproxy@imc.org>; Wed, 25 Sep 2002 17:05:02 -0400 (EDT)
Message-ID: <3D922457.9080103@bell-labs.com>
Date: Wed, 25 Sep 2002 17:02:15 -0400
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-US,de,es
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: draft-ietf-opes-authorization-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


A couple of weeks ago we published the initial version of the OPES 
requirements draft for policy, authorization, and enforcement. So far we 
haven't received any comments on this draft.

If you do have any comments on this draft, please post them to the 
mailing list now so that we can incorporate them into the draft as we 
begin working on the -01 version.

Thanks,
Andre