opes@conference.ietf.jabber.com - 2003/03/17
[16:38] %% mrose has arrived.
[16:44] %% gwachob has arrived.
[16:58] * mrose has changed the subject to: Open Pluggable Edge Services (OPES) / continental 5
[17:01] %% falk has arrived.
[17:02] <mrose> joining in progress...
[17:02] <mrose> markus: the callout protocol SHOULD be application-agnostic, but MUST do HTTP (according to requirements document)
[17:04] <mrose> markus:
Things to keep in mind:
- we are working within the OPES architecture
- any deviations must be conscious and within the charter
- be specific on new "requirements" and why?
- stick to the terminology in the existing wg documents
- always keep in mind the IAB considerations
[17:07] <mrose> abbie: OPES Scope Clarifications
[17:09] <mrose> abbie:
Can OPES change the final destiation of an application?
If yes: what opes agents can do that and what techniques are allowed?
If no: can generating a response w/o forwarding the request be
considered a form of redirection?
[17:10] <mrose> abbie: open questions:
[17:10] <mrose> abbie:
Can OPES agents communicate with data provider/consumer using
applicaioin protocols?
Can OPES fan-out messages?
Can OPES aggregate messages?
Can OPES provide protocol translation service?
[17:13] <mrose> question:
How do we answer these questions?
Ned: First, get concensus that you want to do things like these, and
also look at your charter
[17:13] <mrose> ned: how many in the group really want these things?
[17:14] <mrose> ned: make sure there's demand for it...
[17:16] <mrose> question: Is a specific use case enough to justify going forward with
something?
Ned: if there's clear buyin from the working group, yes?
But isn't there a conflict in terms of concensus for optional
things?
Ned: keep in mind that implementors need to provide a general
implementation...
[17:24] <mrose> hilarie:
Application Extension
OPES Callout Protocol
Application ] proxy
Appication Transport ]
Network
[17:26] <mrose> hilarie: The challenge is to provide a seemless application extensio
[17:26] %% gwachob has left.
[17:27] <mrose> folks - hilarie's drawings are too complex for me to render here, so this is sketchy
[17:28] <mrose> keith: it's hard to mess with protocol semantics
[17:30] <mrose> hilarie: The challenge is to provide a seemless application extension.
Keith: why is this desirable? it's hard to make do protocol
semantics. it's too hard to build a generic extensible proxy.
Hilarie: there is experience showing how to do this.
[17:35] %% falk has left.
[17:41] <mrose>
Keith: perhaps you can generalize payload transformations, but what is
very difficult to do is take protocol-specific things like email
headers, http response codes, and try to build generic protocol
transformations for those.
Hilarie: the next speaker will address how to specify content
modifications
Ned: even mapping just content types is hard, e.g., when you have to
go one-to-many or many-to-one.
Alex: can an OPES cloud server generate a response?
Hilarie: yes, because proxies can have colocated services like
caches, so they can answer directly
Alex: but isn't that redirection?
[17:45] %% carlalf has arrived.
[17:45] <mrose> Hilarie: no, not really.
Alex: if you let an OPES server generate a response, then it can
pretty much do whatever it wants.
Hilarie: allowing the OPES processor unlimited communications
violates the privacy considerations
[17:51] %% venaas has arrived.
[17:51] <mrose> Ned: the big issue deals with enforcement, we need to be able to
deflect abuse by limiting the way things can be configured. this
reinforces hilarie's point with respect to limiting the scope.
[17:55] %% venaas has left.
[18:05] <mrose> Alex: Major decision points for protocol design
Current decision points will be discussed today.
Future decision points (that we won't discuss):
- transport binding
- message binding
- application protocol binding
- error handling
What can talk first?
- OPES dispatcher is a client, so should always talk first
- specific roles simplify protocol
- however:
- callout server may next extra info
- keep-alive violates simple roles
- feature negotaiton may violate simple roles
[18:06] %% mattz has arrived.
[18:09] %% mattz has left.
[18:11] %% NedFreed has arrived.
[18:16] <mrose> Keith: Trying to generalize a single layer that can handle
handle generic application transformations is not possible.
Are responses required, optional, or not allowed?
- require responses only if they carry important info
- add optional ACKs for debugging?
Keith: you'll always need an ACK indicating success or failure
[18:28] %% carlalf has left.
[18:31] <mrose> ...sorry, i'm getting some other traffic i need to look at while i take the minutes...
[18:48] %% mrose has left.
[18:57] %% NedFreed has left.