Sorry was sent in reply to to Alex only.
-------------------------------------------------------
OK. We can probably close the issue here in saying.
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)
2. yes. The IDNA may be considered as an OPES service,
IF it is provided to several applications trough the
dispatcher.
3. yes. The callout protocol may be used in that case.
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.
On 19:10 07/03/03, Alex Rousskov said:
On Fri, 7 Mar 2003, jfcm wrote:
> However if the IDNA is accepted as an OPES service on the http and
> the smtp path, we may specify and see implemented callout protocol
> on the http/smtp output. Actually offering a hook for many other
> services hosted on the very machine of the user/provider.
My understanding is that IDNAs make HTTP messages malformed.
The IDNA has been designed so it does not do that.
<snip>
It does not matter were you place IDNA converter as long as it is
outside of the application protocol path. For example, if your
application protocol is HTTP, you cannot use IDNAs in HTTP requests,
you must convert them before you get a valid HTTP request. Whether
that conversion is done by a "system plugin" or "application plugin"
is not important. IMO, you have two primary choices:
- Perform IDNA conversions before you build messages
for old/existing application protocols. You can
invent a new protocol to do IDNA conversions. OPES will
not apply to the old application protocol, but may help
with the new/invented protocol (if any).
We are in agreement (not on the technical understanding http/IDNA)
- Change old/existing application protocols and their
implementations so that messages containing IDNAs
become valid. OPES will apply then. However, if
all protocols and implementations are changed,
then the need for IDNA conversion disappears.
The IDNA's purpose is not to change the protocols.
That would be done in using UTF-8 all over the net.
> But the first question is: is the user control system as I define it
> an OPES dispatcher as it seems it may do a lot of things that OPES
> are not supposed to do:
>
> - change the URL (redirect)
possible (there is just no consensus whether OPES dispatcher or
callout server can do that)
Yes.
> - be multilingual (IDNA++)
irrelevant to OPES; it is the application protocol that must be
multilingual, not OPES
The point was that IDNA, as specified, is internationalizing.
It does not provide all the Multilingualizing functions that
the user expects (example: it does not support internationalized
TLDs. Several propositions have been floated. They may use
external files, data, web services, some we could qualify as
OPES - but it is no worth discussing as them such since
none has been worked out).
> - interact with the user
possible to the extent the application protocol supports user
interaction
Remember it is local. The protocol here is the direct relation
with the user. cf. bottom.
> - keep permanent user informations, etc.
possible if the application protocol allows it
cf.above.
> But at the same time it may relate with services in using the
> callout protocol, interact with other dispatchers, etc.
True.
> >You have to drive this discussion though (e.g., by submitting
> >OPES-specific use cases or requirements). Are you saying that IDNA
> >conversion has some influence on OPES? If yes, what is that
> >influence? If no, why are we talking about IDNA (should we talk about
> >user control systems instead?)?
>
> You keep asking me to discuss cases. So I proposed a case.
If your case is "IDNA conversions", I tried to evaluate it. If your
case is "user control systems", you have to tell us what OPES-related
requirements those systems have.
cf. bottom.
> I think that its immediate interest could be to permit to define,
> implement and test the upper level of the callout protocol: I mean
> through local interactions withe services.
Can you be more specific? Exactly what additional OPES
functionality/features (beyond modification of application messages
which is the current scope) do you want to support? Once we know your
requirements, we can all discuss corresponding changes to the
protocol.
Well I cannot be too much specific for two reasons:
- I really come to this because of IDNA support, trying to find proper
solutions to the real user needs in that area. So I started with the
demand for ML.ML (SLD and TLD multilingualized).
- this is IP - at least for now. Mostly because we have not
figured out they way we could best implement an open solution
without hurting our own efforts. But I think we will do and I will
then disclose. But I may also influence and impose our solution?
I would prefer it stay open as much as possible ?
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. A simple OPES service seems to be to aggregate
simple cookie informations into user's requests.
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 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).
Is that OK with you for examples?
Now, please remember the point is NOT to discuss
this now. But to know first if these systems fall into
OPES definition. To know if we must stop discussing
them or not. Or if it may be of interest to consider them
to more easily discuss and test the callout protocol.
Thank you.
jfc
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03