Short summary/conclusion for those that do not want to read the whole
thing:
jfc,
I am still not sure what exactly you are objecting to (if
anything). Would it be possible for you to summarize your
position in a stand-alone statement _and_ propose specific
changes to any of the existing drafts? This will ensure
that we, eventually, have consensus.
If you are not objecting to or suggesting anything specific
but are rather asking questions, you may want to re-post
a set of specific questions that are still not answered
(but it is impossible to guarantee that every question
can be answered to one's satisfaction, of course).
Detailed responses are inlined below.
On Wed, 16 Apr 2003, jfcm wrote:
*At 17:51 16/04/03, Alex Rousskov wrote:
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.
Maybe, but that does not prevent me working on OCP Core. If OPES
definition changes, I can adjust OCP Core as needed. I do not
anticipate significant OCP changes, regardless of what this discussion
does to OPES definition. Thus, I do not think I am wasting my time.
IMO, those who think the changes will be significant should
concentrate on OPES definition/scope first (and leave OCP alone, for
now).
At this stage I saw no concensus call on anything yet. Or did I miss
something?
I consider published WG drafts (most important ones are already
approved as RFCs) as consensus. This does not imply that no changes to
those drafts are allowed, of course. It just raises the bar for making
those changes.
There is currently a consensus call for the OCP Core draft to become a
WG draft. So far, there has been no specific objections I am aware of.
We have discussed a few changes that have already been implemented.
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.
OK. I will try to resurrect the diagram while trying to avoid
now-undefined terms such as "input and output protocol". The problem
is that this kind of diagram/text does not really belong to OCP. OPES
Architecture or another document should address the scope of OPES
components and their interaction. It is wrong to spend so much effort
on documenting what OCP is NOT, especially in the OCP Core draft.
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 #".
Please provide textual definitions. It is virtually impossible (for
me) to discuss definitions that have no textual representations. [ If
you want to use a formal model, that's fine with me to, but the
current diagram is not a formal model because its elements and symbols
are undefined. ]
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.
I cannot make such a diagram or a set of mathematical functions that
would completely define OPES and raise no further questions. If you
can, you should do that and we will discuss the result.
For me, OPES system is simply an intermediary that obeys certain rules
(e.g., tracing and bypass), that adapts proxied traffic, and that may
use OCP to facilitate adaptations via callout servers.
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.
OPES relates to protocols being proxied. Do you think otherwise? If
not, I do not think anybody else does, so we still have consensus,
which is already documented in the architecture draft.
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).
And why this is a "No"? I see no contradiction between the above two
paragraphs. Some OPES systems can do protocol adaptation. Some cannot.
Both kinds of systems are OPES as long as they (intend to) obey OPES
rules.
IMHO it CANNOT be a protocol converter if it is not related to the
entry protocol
It is related. I have heard no opinions suggesting otherwise.
OPES _is_ related to the input/entry protocol. We even plan
input/output protocol-specific drafts, possibly one per proxied
protocol!
IAB said it is related to http.
Correction: IAB (RFC 3238) does not refer to HTTP in any normative
context.
You "plan". This is "possibly".
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.
These are not the only two options. The approach I am advocating is to
have one generic (application agnostic, independent from the I/O
protocol) OPES Core and several application-specific bindings or
mappings of that core. OCP Core is a part of OPES Core. So are OPES
tracing and OPES bypass drafts (or whatever they end up being called
when/if merged). We will have different tracing mapping/support in
HTTP and, say, RTSP, because those protocols are so different.
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.
IMO, OPES can be used in both architectures. I am not sure what you
are deciding about, but I am sorry if I cannot help you.
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.
Fine(*). Is that a problem? I do not see anything wrong with a
particular OPES component being useful in some environments and not in
other environments. OCP is a MAY for OPES. Like caching is a MAY for
HTTP.
(*) though it is impossible to verify your "no interest"
assertion without having definitons of "dispatcher centric"
and "daisy chain" architectures
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.
_Every_ metainfo? I do not see how is that implied. The exact protocol
conversion/mapping functions are undefined by OPES; it is perfectly
fine, in general, to alter meta information (adapt it), including a
case where all information is deleted (SMTP black hole for SPAM).
So the OPC is I/O protocol dependent and new versions can
be specified on I/O protocols basis.
OCP Core is independent of proxied protocols. There will be specific
application bindings for specific "application messages".
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.
And I want to support both by separating application-independent Core
from application-dependent bindings.
Alex.