ietf
[Top] [All Lists]

Re: OPES charter proposal again.

2001-07-03 08:40:02
At 02:45 AM 7/3/2001 +0100, Lloyd Wood wrote:
I do like the 'extend [..] the iCAP protocol without being obliged to
retain any level of compatibility with the current iCAP proposal.'
Fine, since iCAP's just an individual draft -- but isn't extending
without being compatible something only Microsoft is generally
regarded as being capable of doing?

That is not the intent. The intent is that the IETF process
will be followed with regard to iCAP (not some other organization's
process).


(and security _enforcement_? is lack of enforcement specification the
reason IPSec hasn't taken off, perhaps?)

L.

http://www.extproxy.org/ doesn't have that expired draft.

Which one, I will correct that.


<L(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

On Mon, 2 Jul 2001, The IESG wrote:

> Date: Mon, 02 Jul 2001 18:04:26 -0400
> From: The IESG <iesg-secretary(_at_)ietf(_dot_)org>
> To: IETF-Announce:  ;
> Cc: new-work(_at_)ietf(_dot_)org
> Subject: WG Review: Open Pluggable Edge Services (opes)
>
>
> A new IETF working group has been proposed in the Applications Area.
> The IESG has not made any determination as yet. Note that this is the
> second review message for OPES due to changes to the original
> proposed charter.
>
> The following Description was submitted, and is provided for
> informational purposes only:
>
> Description of Working Group:
>
> The Internet is facilitating multiple forms of distributed
> applications, some of which employ application-level intermediaries.
> The Open Pluggable Edge Services (OPES) working group's primary task is
> to define application-level protocols enabling such intermediaries to
> incorporate services that operate on messages transported by HTTP and
> RTP/RTSP. At the IP level, the participating intermediaries are
> endpoints that are addressed explicitly.
>
> The protocols to be defined provide a framework for integrating a wide
> range of services into application-level intermediaries. The advantage
> of standardizing such protocols is that services can be re-used across
> vendor products without modifying the intermediaries or services.
>
> Intermediary services provided in this way are not transparent: They
> must be authorized by the application endpoint (either the content
> requestor or the content provider) that requests the intermediary
> service. A key task for the working group is to specify an appropriate
> authorization mechanism.
>
> Intermediaries may employ services executed either locally or on a
> remote ("callout") server. One task for this working group is the
> development of callout protocols that enable the receiving callout
> service to either receive encapsulated HTTP or RTP/RTSP messages or,
> through some other mechanism, for the callout service to receive the
> application data necessary to perform its services.
>
> The iCAP protocol provides similar function for services operating on
> iCAP-encapsulated HTTP application data. The working group will
> evaluate the iCAP protocol as one candidate for passing HTTP
> application data for remote services. It may decide to extend or even
> not use the iCAP protocol without being obliged to retain any level of
> compatibility with the current iCAP proposal.
>
> Another task for this working group is to enumerate the requirements
> for management policies and associated administrative protocols that
> allow these services to be specified and deployed. This includes
> requirements on the rule systems used to specify conditions under which
> services are executed.
>
> The working group will develop a security model for OPES services in
> which authorization and enforcement will be defined. The model will
> specify the entities, privileges, notifications, and authorization
> actions affecting content. In addition, the model will show how
> end-to-end services and data integrity concepts are mapped onto the
> OPES architecture.
>
>
> Related Internet-Drafts
>
> Prior related requirements document (expired but available on the web
> site):
>   draft-tomlinson-epsfw-00.txt
>
> Updated iCAP Callout Protocol:
>   draft-elson-opes-icap-01.txt
>
> A Rule Specification Language for Proxy Services:
>   draft-beck-opes-irml-00.txt
>
> OPES Network Taxonomy:
>   draft-erikson-opes-net-taxonomy-00.txt
>
> OPES Architecture for Rule Processing and Service Execution:
>   draft-yang-opes-rule-processing-service-execution-00.txt
>
> OMML: OPES Meta-data Markup Language:
>   draft-maciocco-opes-omml-00.txt
>
> General Use Cases:
>   draft-beck-opes-esfnep-01.txt

Michael W. Condry
Director,  Network Edge Technology





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