-----Original Message-----
From: The Purple Streak, Hilarie Orman
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
Sent: Wednesday, April 16, 2003 5:06 PM
To: info(_at_)utel(_dot_)net
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: OPES definition/scope
OPES is not going to do protocol conversion. An OPES-like
architecture could, at some point, define the processing
points and control messages for this kind of functionality,
and I hope that someday we'll get there, but I doubt that it
will be in a WG called OPES.
You make a good point in observing that if OPES did protocol
conversion, then the notion that the callout protocol is the
encoded in the proxied protocol becomes confused - callout
transactions would logically use protocol X in one direction
and protocol Y in the other. And further, we'd have to think
through several issues about matching names, authentication
methods, connection initiation to endpoints, etc. that just
didn't come up when we did the architecture.
Of course, someone might be able to do some protocol
conversions using OPES and a single protocol encoding for the
callout protocol. That's fine and good, I'm sure the
framework we are developing will support more uses than we
directly address.
Hilarie
On Wed, 16 Apr 2003 at 19:27:23 +0200 jfcm stated:
I just think in simple ways:
- Yes/No.
- layers by layer implications
- logical models
- what has not been approved by consensus is not accepted
*At 17:51 16/04/03, Alex Rousskov wrote:
>-- 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.
The thread I followed was questions on that.
> 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.
The OPES is NOT defined enough for the OPC Core not to be
affected.
At this stage I saw no concensus call on anything yet. Or
did I miss
something?
> 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 ? possiblity 1
> > > > <------ OPES ? possiblity 2
> > > <--- OPES ? possibility 3
> >
> > >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_si
d3/ocp-spec.html#section_ops-environment
Since people still keep asking questions I suggest that
you keep both
the
diagram and the explaination. This may help to understand.
So we may also
see if the diagrams are good enough and if the
explanations match the
diagram. Modelization is the first step, but it is also an
iterative process.
> > 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?
I am discussing a diagram where three possibitilities are
shown with
a question mark. For your convenience I added the wording
"possiblity
#".
> > >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?
Yes. As discussed above. Even is things are the same in your mind,
either
they will present the same thing and they will help
understanding, or they
may present different things and will help indifying
misunderstandings.
> > > > 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").
This should not be the case. If you work out a, OPES diagram; you
will have I/Os and you will phrase OPES in a mathematical way as a
function (or group of functions). That function(s) will be clearly
understood if it is clearly and afirmatively described in a generic
way.
If the I/O of the OPES black-box are data flows under
protocols, then
OPES may relate to protocols, if not they will not. This is what a
diagram will permit/help you to see easily.
> > 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.
No. As everything generic OPES can only carry what they
have beend
defined to carry. Some implementations could do more, they
could also
participate into some other process. But generic OPES will do all
what they are expected to do if they are well designed,
and no more
(otherwise they would have been ill defined or would cost
too much to
develop for the expected return).
> > 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!
You "plan". This is "possibly". IAB said it is related to
http. To
be realted to more you have two options:
- to draft as many OPES systems with impact on OPC
- to make them independent from the I/O protocol (possiblity
2 or better 3 aboe), leaving that aspect to a protocol interface
able to relate with such OPES systems.
I do prefer that last approach in one architecture (dispatcher
centric). I do not in the other architecture (daisy
chaining). When
you say that OPES "can be both" you do not help me deciding.
We are here talking specifcally of the OPC Core. And in a
dispatcher
centric architecture I think the callout protocol is the center of
the whole OPES system; while in the daisy chain
architecture If feel
it is quite of no interest.
> > (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".
Protocol used to input or output the data. The same
wording as you, just above.
> > 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)
Thnak you for the draft/ So you can see that that the sequence of
the data path is http > (dispatcher) call-out (server) call-out >
(dispatcher) > ftp.
So if you only keep protocol, the protocol sequence is what I
indicated. It permits to see that - unless protocols conversion or
continuity relies on stored information every meta info in
the input
protcol must be transported in the call-out protcol. So the OPC is
I/O protocol dependent and new versions can be specified on I/O
protocols basis.
Or OCP supports enough information to be mapped into many
protocols.
Then all the protocols one can interface are OPES acceptable.
This makes two totally different architectures and ways to
consider
OPES. jfc