Alex,
I do second your proposal.
Abbie
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Monday, March 10, 2003 12:16 PM
To: OPES Group
Subject: Re: Draft Agenda for IETF 56
On Mon, 10 Mar 2003, Markus Hofmann wrote:
- Introduction, minutes taker, blue sheets
- Agenda bashing
- Status of WG documents
draft-ietf-opes-architecture-04
draft-ietf-opes-protocol-reqs-03
draft-ietf-opes-scenarios-01
draft-ietf-opes-authorization-02
draft-ietf-opes-threats-02
- OPES scope clarifications
- Start on OPES protocol work
- Introduction
- Major decision points for protocol design
- OPES protocol pre-draft thoughts
- General discussion
I would like to propose to add another agenda item, "OPES
scope clarifications", as shown above. We have good
architecture and requirements drafts, but they appear to
leave some scope questions unanswered (or there may be no
consensus how to interpret the drafts). These questions seem
to be one "level" higher than callout protocol work because
they affect more than the callout protocol.
Specifically, I would like to discuss the following, under
the new agenda item:
1) Can OPES redirect application messages? That is,
can OPES change the final destination of an application
message? If yes,
~ What OPES agents can do that (dispatcher and/or
callout server)?
~ What techniques are allowed (e.g., rewriting
application message headers, responding with
a "redirect" response if supported by the
application protocol)?
And if no,
~ Can generating a response without forwarding
the request be considered a form of redirection?
Is that kind of transaction termination allowed
for application error messages only? What is an
error?
2) Can OPES fan out messages (a single application
message is forwarded as multiple messages)? Can OPES
aggregate messages (multiple application messages are
forwarded as a single application message)?
3) Can OPES provide protocol translation service? That is,
can OPES switch flow from one application protocol to
another (e.g., HTTP transaction with FTP URL to an FTP
transaction)?
4) Can OPES agents communicate with providers and consumers
using application protocols? For example, can an OPES-aware
proxy do this:
~ suspend an HTTP request (do not forward it)
~ "respond" with a OPES-generated HTML page
containing a <form>, asking for user
password/preferences
~ receive the result of form submission
~ forward the original HTTP request,
possibly adjusted based on user answers in
the form
~ forward the response back to the client
The above is a relatively common behavior supported by
existing HTTP intermediaries (especially popular at
ISPs). It opens the door for many "enhanced" services.
Should OPES support this?
Question 1-3 attempt to clarify scope of OPES services; what
can be modified by OPES: just message content and affected
headers; content, headers, and transport-level connections
(destination/source); number of messages; protocol itself?
The answer to question 4 will draw the line between OPES
agents and providers/consumers: what kinds of communication
are allowed?
Are these real issues worth discussing? Or do they already
have precise answers in WG drafts? Do they fit into existing
agenda items? Any changes to the above list?
Thank you,
Alex.