ietf-openproxy
[Top] [All Lists]

Re: OPES WG Future

2003-11-07 06:00:39

Hi Markus,

I feel there is quite some work that still needs to be done in the OPES
area regarding the specification of rules for filtering.. 

Using a language like 'P' (or something similar) to control activities
at the OPES can throw up several interesting opportunities...
* The P language (interpreted) would help one to define the dynamic
behaviour of an OPES processor.
* The above control to change the behaviour can be left to the
administrator to support QOS needs. However, interesting possibilities
and challenges will open up if we let 'others' define the behaviour.
* For example, if a user is able to define his/her own 'P' program
(ruleset) and send a link to that as a part of the request itself, the
request/response would get modified somewhere along the path whereever
that service is available! That is a good thing for the user! Ofcourse,
the fallback action on failure to do so would also be provided by the
user.
* Similarly, the content provider could define a P program and send it
across as one of the  response headers (in HTTP for eg). Now, depending
upon the local characteristics of the network, a specific adaptor would
be invoked. This adaptor can be provided by the content provider
himself.
[ I understand that IRML supports specification of rules by client and
content provider but there is no standard way of communicating the same
to an OPES processor...]

Now , this may inturn throw up standardization needs for the following:
* how does one specify/name an OPES service ?
* discover an OPES service, 
* authorization and authentication of the person to deploy a P program
on an OPES processor
* some work in sand boxing capability to P language itself 
* Definition of protocol specific interfaces available from P
* Specifying mandatory protocols that need to be supported by an OPES
* Way of negotiating on where a specific filter is best executed and so
on.

* If we allow the user-specified modifications (or end point requested
adaptation) to look at lower layers (IP and below), it throws up another
possibility of end nodes defining the protocol to some extent... 
* One can think of OPES processors that are able to uniformly understand
one standard language to be able to dynamically change their behaviour. 
* Are we going along the lines of standardization required for 'active
networks' - AFAIK there is no such standard as of now .. 

I guess we could use some existing protocols for some of the above needs
or modify some existing ones - but it definitely needs some serious
exploration/consensus as per my understanding...Is it worth putting
these under the purview of OPES?

Comments? Inputs?

regards
Geetha

Markus Hofmann wrote:

Folks,

with all documents getting close to a stable version, it's time to
think about our last charter item, namely

   "Consider additional OPES work such as extension to traffic beyond
    HTTP and RTSP and present new charter to IESG, or conclude working
    group."

Thoughts? Suggestions? Comments? Please post to the mailing list.

-Markus

<Prev in Thread] Current Thread [Next in Thread>