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.