Re: Fwd: Re: OPES Draft Charter and Mailing INfo, please comment

How do people feel about the issue of common protocol elements to
deal with the generic problem of referring to proxied protocol
elements?  I can see some leverage in this, perhaps with message
elements like

 Proxied protocol id
 Proxy-proxyhelper request/response parameters
 Requestor connection identifier
 Responder connection identifier
 Requestor/Responders connection state
 Proxied message header encoding
 Proxied message header
 Proxied message body encoding
 Proxied message

but, on the other hand, I also see a good argument saying that
the best way to do this is to leverage as much of the proxied
protocol as possible, i.e., HTTP has all the machinery that you
need to refer to HTTP (i.e., it is almost reflexive).

Which way (or any other) would people prefer to see OPES go?

Hilarie


> > > Mark Nottingham <mnot(_at_)akamai(_dot_)com> 01/08/01 05:13PM >>>

The latest revision of the ICAP specification attempts to address
many of these issues; I'd encourage Graham to have a look at it to
see if his opinion changes. That having been said, I don't disagree
with the main point he raises.



On Mon, Jan 08, 2001 at 07:44:40AM -0800, Michael W. Condry wrote:
> > X-Sender: maiw03(_at_)pop(_dot_)dial(_dot_)pipex(_dot_)com 
> > X-Mailer: QUALCOMM Windows Eudora Version 5.0
> > Date: Mon, 08 Jan 2001 11:52:32 +0000
> > To: "Michael W. Condry" <condry(_at_)intel(_dot_)com>
> > From: Graham Klyne <GK(_at_)dial(_dot_)pipex(_dot_)com>
> > Subject: Re: OPES Draft Charter and Mailing INfo, please comment
> > Cc: discuss(_at_)apps(_dot_)ietf(_dot_)org 
> >
> > While I think the goals of OPES are valuable, I have concerns about using 
> > ICAP as a starting point for the HTTP-related work.
> >
> > When I looked, a couple of months ago, ICAP seemed to me to exhibit the 
> > characteristics of a protocol hacked together in a closed group (which the 
> > ICAP forum was) -- lacking awareness of a wider range of protocol design 
> > issues and concerns.  I think the most productive way forward would be to 
> > isolate the goals of the protocol, and revisit the overall design.
> >
> > In my opinion, the ICAP specification is architecturally weak.  It lacks a 
> > clear separation between the ICAP protocol elements and HTTP protocol 
> > elements that are the subject of ICAP protocol actions.  It is also 
> > unclear whether the protocol is intended to be an extension of HTTP (i.e. 
> > defines new HTTP headers) or is a protocol that happens to look like 
> > HTTP.  Is ICAP intended to run on port 80?
> >
> > When passing about HTTP protocol units for examination or modification, I 
> > think the protocol should be designed to clearly separate the HTTP 
> > protocol elements from the ICAP protocol elements; e.g. by wrapping in a 
> > message/http MIME structure.  In addition to architectural cleanliness, 
> > this has the following specific advantages:  (a) it provides some 
> > insulation from possible future changes to HTTP;  (b) it is more likely to 
> > be usable if a new generation of web access protocol is deployed;  (c) it 
> > is more likely to have elements that are usable with other protocols (such 
> > as SMTP suggested in the charter).
> >
> > Therefore, my comments on the charter come down to this:
> >
> > Rather than defining different protocols for different kinds of auxiliary 
> > server, I think it would be better to design some common protocol elements 
> > that can be used over a variety of underlying transfer services, and carry 
> > information _about_ different protocols;  i.e. common protocol elements to 
> > deal with the common framework.  Specific service definitions can then be 
> > added to deal with specific protocol usage such as HTTP.
> >
> > #g
> > --
> >
> >
> > At 07:18 PM 12/17/00 -0800, Michael W. Condry wrote:
> >
> >
> >
> > > Orthogonal Protocol Extension Services(opes)
> > >
> > >
> > > Co-chairs:
> > >    Michael Condry <condry(_at_)intel(_dot_)com>
> > >    Hilarie Orman <HORMAN(_at_)novell(_dot_)com>
> > >
> > > Mailing Lists:
> > >    General Discussion: ietf-openproxy(_at_)imc(_dot_)org 
> > >    To Subscribe: ietf-openproxy-request(_at_)imc(_dot_)org 
> > >    Web: http://www.extproxy.org 
> > >    Archive: ftp://ftp.ietf.org/ietf-mail-archive/opes 
> > >
> > > Description of Working Group:
> > >
> > > The Orthogonal Protocol Extension Services architecture (OPES) enables 
> > > construction of services executed on application data by participating 
> > > transit intermediaries.  Caching is the most basic intermediary service, 
> > > one that requires a basic understanding of application semantics by the 
> > > cache server.  Because intermediaries divert data temporarily over a 
> > > pathway different from the transit pathway, one can think of the service 
> > > path as being orthogonal to the main transit path.  The purpose of this 
> > > working group is to define the protocols and API's for a broad set of 
> > > services that facilitate efficient delivery of complex content or 
> > > services related to content.  The advantage of standardizing these 
> > > protocols and API's is that the services can be re-used across vendor 
> > > products without modifying the transit intermediaries or services.
> > >
> > > The architecture supports services that are either co-located with the 
> > > transit intermediary or located on other servers (referred to as 
> > > auxiliary servers in this charter).  The ICAP protocol is being developed 
> > > for carrying HTTP headers and data to cooperating servers; other 
> > > protocols for carrying SMTP or other protocols to cooperating servers 
> > > will be supported by the framework, as they exist or become 
> > > available.  This working group defines the supporting configuration data 
> > > and protocols for configuring services on the transit intermediaries; 
> > > this configuration makes it possible to administer collections of transit 
> > > intermediaries and content services as a coherent system.
> > >
> > > There are four parts of a good service definition for transit-based 
> > > extensions to an application protocol.  The first part defines the 
> > > protocol processing point or points in the intermediary that could detect 
> > > an application data event of interest to the auxiliary service.  The 
> > > second part defines the server, the access method for the server, and the 
> > > marshaled form for arguments added when delivering the application data 
> > > to the auxiliary server.  The third defines the post processing of the 
> > > data returned by the auxiliary.  The fourth element of the definition is 
> > > an encoding of the above information combined with the service extension 
> > > itself, defined as some form of loadable code or access method for 
> > > invoking the code.  The working group will define an information model 
> > > and realization of the model into repository and protocol elements.
> > >
> > > These service definitions must be standardized in ways that are 
> > > compatible with the policy framework of the Policy working group. The 
> > > definitions constitute configuration information that can come from 
> > > repositories or runtime protocols; for example, and ICAP server coming 
> > > on-line can notify its clients of the services it offers, and it can 
> > > update their status ("up", "changed", "suspended", "moved") while it is 
> > > running.  A namespace for services and a means for registering names will 
> > > be considered.
> > >
> > > Some crucial data must be communicated from the intermediary to the 
> > > auxiliary server in standardized semantics.  Identification and 
> > > authentication information for the application connection may be 
> > > important to the auxiliary processing, for example.  The working group 
> > > will define a core set of information necessary for supporting generic 
> > > application needs.
> > >
> > > Postprocessing the result from the auxiliary processor is done at the 
> > > option of the intermediary, but instructions from the auxiliary server 
> > > must be communicated in a standardized manner.  Generic directives 
> > > ("drop", "hold", "assign attribute", are examples.  The working group 
> > > will define postprocessing directives and the rules for their interaction 
> > > with the configuration policy.
> > >
> > > The security model for intermediary services involves defining the 
> > > administrator roles and privileges for the application client, 
> > > application server, intermediary, and auxiliary server.  The working 
> > > group will use the Policy Configuration Information Model to define the 
> > > security attributes and the enforceable policy.
> > >
> > > The working group items for delivery are
> > > 1.      A "side transit" protocol (ICAP) for use with HTTP
> > > 2.      A policy-based configuration and definition model for orthogonal 
> > > service extensions
> > > a.      To include representation of conditions leading to invocation of 
> > > extension services, common data items (identities, authentication state, 
> > > etc.), postprocessing directives, and the access method for the service 
> > > or a representation of a loadable service (URL or encoded executable or 
> > > interpretable code, for example).
> > > b.      A specific repository-based embodiment of the model
> > > c.      A delivery protocol embodying the elements of the model as a 
> > > language; the protocol may be embedded in HTTP and/or ICAP.
> > > d.      Recommended procedures for registering service names and 
> > > repositories for extensions
> > > 3.      A security model and security configuration policy definitions, 
> > > i.e. roles, privileges, and enforcement point responsibilities.
> > >
> > > After these items have been delivered, the working group can examine the 
> > > progress in this area and, if appropriate, re-charter to with more
> > > general work items in the OPES framework.
> > >
> > > Existing Internet-Drafts
> > > Basic Requirements:
> > >         http://draft-tomlinson-epsfw-00.txt 
> > > Initial iCAP Callout Server:
> > >         http://draft-elson-opes-icap-00.txt 
> > > A Rule Specification Language for Proxy Services:
> > >         http://draft-beck-opes-psrl-00.txt 
> > > General Use Cases:
> > >         http://draft-beck-opes-esfnep-01.txt 
> > >
> > >
> > > Goals and Milestones:
> > >
> > > Feb 01: Requirements and roadmap documents for WG
> > > Feb 01: First draft of HTTP orthogonal protocol; first draft of policy 
> > > information model
> > > Mar 01: Meet at Minneapolis IETF
> > > Mar 01: OPES architecture and requirements documents
> > > Jun 01: Submission of security model and configuration policy to IETF
> > > Jul 15: Draft of policy rules, enforcement semantics, standard data 
> > > items, and post processing
> > > Aug 01: Meet at London IETF
> > > Aug 01: Final submission of HTTP orthogonal protocol.
> > > Oct 01: Submission of repository specific and ICAP-based policy rule 
> > > deliver protocol
> > > Dec 01: Salt Lake City IETF.
> > > Dec 01: Review charter, if necessary, amend for additional orthogonal 
> > > protocol definitions, standard data items, postprocessing directives.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Michael W. Condry
> > > Director, Internet Strategy
> > > 2111 N.E. 25th Ave.
> > > JF3-206
> > > Hillsboro, OR 97124-5961
> > >
> > > Phone: (503) 264-9019
> > > FAX: (503) 264-3483
> > > Email: condry(_at_)intel(_dot_)com 
> > ------------
> > Graham Klyne
> > (GK(_at_)ACM(_dot_)ORG)
> Michael W. Condry
> Director, Internet Strategy
-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)