Subject: RE: Draft Agenda for IETF 56

From: "Abbie Barbir" <[email-masked]>
Date: Mon, 10 Mar 2003 13:31:14 -0500

Alex,

I do second your proposal.

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> 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.
> 
> 
>

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 11 Mar 2003 00:00:19 -0500

Alex,

agreed, good suggestion. Thought of covering that under the 
"Introduction to protocol work", but maybe a separate agenda item 
might be more appropriate.

Abbie,

could you cover that topic and lead the discussion on that one, since 
Alex will already present on other topics?

Thanks,
   Markus