OPES definition/scope

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

-- was "Subject: OCP questions"


jfc,

	You keep mixing OCP and OPES which makes it very awkward (for
me) to respond. The "OCP questions" thread you responded to was about
OCP. OCP Core is application-agnostic and, hence does not care much
about proxied protocols, their conversions, etc.

	I took the liberty of renaming your Subject line. If you want
to polish or completely change OPES definition, PLEASE stay on this
new thread and make specific suggestions here. If you want to discuss
OCP Core draft instead, please use existing OPES architecture and the
old thread (or start a new one). I understand that OCP depends on OPES
architecture, but OCP thread is not about OPES in general, it is about
OCP. This new thread can be about what OPES is or should be.

	Specific OPES-related comments are inlined.

On Wed, 16 Apr 2003, jfcm wrote:

> At 15:22 16/04/03, Alex Rousskov wrote:
> >On Wed, 16 Apr 2003, jfcm wrote:
> > > Most of the points risen here would get a clear response with a
> > > simple diagrams such as :
> > >
> > > http  | data input | dispatcher | call-out protocol | server | call-out
> > > protocol | data-output | http
> > > <------ OPES ?
> > >          <------ OPES ?
>
>  >                            <--- OPES ?
>
> >We already have/had such diagrams. Obviously, they did not provide
> >enough "clear responses".
>
> hmmm... This is your opinion which translates into some's difficulty
> to understand where we are.

What I said is not an opinion. It is a fact. We had very similar
diagrams in OCP Core (e.g., see section 2.1 "2.1 OCP environment" in
version head_sid3 of the OCP Core draft [1]) and, since people keep
asking questions, they did not get us "clear responses" you promise.

[1] http://www.measurement-factory.com/tmp/opes/snapshots/head_sid3/ocp-spec.html#section_ops-environment

> If OPES is defined as the first possbility, http is part of it and
> call-out may take it into account. If it is defined the second way,
> external protocols are no part of OPES but OCP can consider knowing
> it. If it is the third definition (that I thought you would add by
> yourself in your response to illustrate the difficulty), then the
> call-out protocol has NO relation with the entry protocol.

I do not know what "possibilities" you are talking about. Are they
related to the arrows on your diagram? Care to define them explicitly?

> >Note that OCP has nothing to do with "http |
> >data input |" and "data-output | http" parts. OCP Core has specific
> >wording about that. That wording replaced some of the figures that had
> >those parts in earlier OCP Core versions.
>
> Seems that this wording does not prevent questions. May be both
> could be kept? We could check they fit the different understandings.

By "both", do you mean the old figure and the new wording?

> > > PS. What about protocol conversion, is that OPES?
> >
> >It can be. An application proxy that does protocol conversion may
> >support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy
> >today has to convert between HTTP and FTP (or even Gopher, WAIS,
> >etc.). I do not see why OPES proxies should be more limited than
> >existing HTTP proxies. If OCP is involved in protocol conversion, OCP
> >agents would have to negotiate/agree on how to specify
> >original/adapted protocols via application message metadata.
>
> At a given stage one must start saying what an OPES is and is not.

OPES is about many specific things. If you keep asking specific
questions ("Is OPES about Foo"), you will keep getting specific
answers ("OPES can be about Foo", but it can also be about "Bar").

> And stop saying "it can be".

I was just answering your question! OPES, regardless of the
definition, can be many things. It is OK to say "OPES is about
protocol conversion", but since OPES is also about other things, it is
more accurate to say (IMO) that "OPES can be about protocol
conversion". That is, "protocol conversion" is within OPES scope.
The latter is the best wording, I guess.

> IMHO it CANNOT be a protocol converter if it is not related to the
> entry protocol

OPES _is_ related to the input/entry protocol. We even plan
input/output protocol-specific drafts, possibly one per proxied
protocol!

> (but the use of different I/O protocol will
> [affirmative mode] make it a part of a protocol conversion system).

Do not know what you mean by "I/O protocol".

> This will have an impact on OCP. The protocol sequence is then:
> http > call-out > smtp.

The above is not how callout protocol is now defined. Callout is
something that comes back:

	(http) <--> OPES processor <--> (ftp)
	             ^
	             |
	             V
	          (callout)

Alex.