On Fri, 7 Mar 2003, jfcm wrote:
1. yes. A user control system can be an OPES dispatcher
even if it is located on the same machine as the user.
(for more discussion on the ucs cf. bottom)
A user control system can be an OPES dispatcher if and only if that
user control system is a part of some proxy for application-level
protocols. I am not sure your user control system is a part of a
proxy. OPES is about adaptation of application messages being proxied.
2. yes. The IDNA may be considered as an OPES service,
IF it is provided to several applications trough the
dispatcher.
The number of applications is irrelevant to OPES. Yes, OPES has to
include a directly addressable processor, with a dispatcher.
3. yes. The callout protocol may be used in that case.
The callout protocol cannot leave outside of OPES. Or, more precisely,
usage of the callout protocol outside of OPES is outside of this WG
scope. If your user control system is a proxy, then we can talk how
OPES and callout protocol apply.
4. no. the IDNA as such is NOT an OPES when it is
only a part of an application
5. What should be investigated is the "user control system".
cf. bottom.
OK. Let's forget about IDNA then and talk about "user control system".
- this is IP - at least for now.
That's fine as long as you understand that we cannot productively
discuss something we do not know about.
But I can give some elements.
- the management of a local Apache server
- the management of the physical environment of the user - like
rebooting for example.
- the management of one's remote machine etc.
where requests may be modified with informations corresponding to
defaults, current situation, authorizations rights.
You need to mention application protocols. Recall that OPES is about
modifying application messages. The above three "elements" do not
imply any specific protocols or proxies so it is not clear why do you
need OPES:
- what is user/client that generates messages?
- what is the destination of those messages?
- are those messages proxied? where is the proxy?
- what protocols are used for those messages?
A simple OPES service seems to be to aggregate simple cookie
informations into user's requests.
If modifications and aggregation are happening on some proxy, then
OPES is in scope and may help.
Another service (still in the IDNA line) is the translation of the
messages sent, or of the presentation in an appropriate language of
formatted messages (much like EDI). It is very convenient to imagine
an EDIFACT translator as an OPES service, being sent EDI mails and
presenting them in the language of each of the readers. (EDI makes
commercial, customs, billing etc. document to result into codes and
values, so a bill may be produced in German and read in Chinese).
The filter (dispatcher) may be on my PC and the service may be
remote.
In-flow translation is within OPES scope, of course.
In that case:
1. as the PC owner I chose the service used (ONES)
2. as a mail reader I do not know/care that a service has
been used (OPES).
I do not understand this distinction (why cannot one chose OPES proxy
but can chose ONES?), but that is probably not important for now.
Is that OK with you for examples?
Yes, except that I do not see a relation to the user control system.
Should we ignore the UCS discussion from now on?
Now, please remember the point is NOT to discuss this now. But to
know first if these systems fall into OPES definition.
If by "these systems" you mean "addition of cookie-like information by
a proxy" and "translation by a proxy", then yes, those systems may be
in OPES scope. If by "these systems" you mean something else, then I
do not know what you mean.
Thanks,
Alex.