(I don't think this made it to the list the first time ... Scott)
On 0, "Michael W. Condry" <condry(_at_)intel(_dot_)com> wrote:
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.
These two pieces of text don't feel completely aligned. Maybe the
problem is that I don't know what you mean by "the transit pathway",
but, for example, caching services which start with DNS and proximity
determination only use intermediaries in the DNS system.
I think the critical characteristic is that you're interested in services
which are "executed on" data. That's different, imho, from services
which affect the mode of delivery of data which is untouched.
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.
Now, this is different from the first sentence ("executed on", etc.).
How about simply deleting the paragraphs that come before this one?
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).
So far so good but ...
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.
I thought the goal was to define the protocols. Let's not decide that ICAP is
the answer first, and especially let's not do so in the charter.
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.
It's a nice model, but again it is for services "executed on" data.
Let's decide which way this WG is going to go -- either limit it to
services executed on data or allow for others.
These service definitions must be standardized in ways that are compatible
with the policy framework of the Policy working group.
The IETF is an engineering group. I believe the Policy WG's models
should align with practical experience, and that this WG should have at
least as much to say about service definitions as they do.
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.
I wouldn't put this in the charter -- it's already covered when we say we'll
define the interactions above.
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.
The last sentence is all you need.
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.
Same comment.
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.
I have no comment on the usefulness of the PCIM, but I'd like to hear
others.
The working group items for delivery are
1. A "side transit" protocol (ICAP) for use with HTTP
Take out "(ICAP)" until we evaluate it technically.
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
I don't think these should be in the charter since they are not WG drafts.
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.
OK except for explicit mention of ICAP. ICAP as far as I know has never
received an IETF review.
...Scott