I will not make a big point of this as it concerns real
life and we will see how the users will behave in front
of real life solutions.
On 03:58 06/03/03, Alex Rousskov said:
OPES protocol is not meant to be a general-purpose plugin interface.
I do not see how an OPES protocol (between
dispatcher/server) can be an interface? You mean
"plugin access protocol"?
The callout protocol, if it is good; may be used between the
user control system (see below) and its related servers. It
may also copy from it if the user control system comes first.
What may be/is is the case.
What you describe is a good application for a browser plugin,
Again, the browser has NOTHING to do in here. You introduced it.
I talked about IDNA and you decided IDNA was on the browser.
I only say it is an application on the process which consistently
manages the transcriptions of UTF-8 entries into ACE labels.
for web, mail, ftp, etc Many IDNA may exist on a machine, only
one can do it consistently and hopefully completely. I will chose
to name the place where that process is triggered the "user
control system" (because I observe on the market that it is
what is proposed/under proposition).
The user control system should by essence not be an
application of the browser. The browser should be a peripheral
of it, or it should run in parallel to the browser and use it
as a screen.
The reason why I asked about IDNA is that today the only
service in use for what I name here the user control system
is IDNA. But nothing prevents us to deploy and test others.
not for a proxy plugin (for the reasons I mentioned). OPES protocol is a proxy
plugin interface. Again, it is _possible_ to use OPES framework in a
browser, but it is probably not the best way to implement a browser
plugin.
Please let forget your browser. The browser is only the screen.
You may understand that the first thing a user control system
need is a consistent interface with its environment and with
the users. This means first an universal language.
Up to now universal language was ASCII. With IDNA it
becomes possibly ML (Multilingual). IDNA is a first step.
It only partly solves the Right Hand Side (not the TLDs).
Now is under discussion the LHS (on the left of the "@"
in a mail address). But the real issue is the whole URL. You
may accept that if there is a process which needs to get
ML support of LHS, RHS and URL, it is likely it will act as
a server for the other tools. That ML server can be though
as an application of an "ucs" designed as a dispatcher or
as a server called by that dispatcher.
After talking with the user, the system must talk with the
world. This means to utilize a resolver. If there are new
services supported by the user control system, we may
assume there are new needs to be supported. Hence the
need to investigate DNS.2 (different use and architecture)
and DNS+ (new services).
The the next step is about the relation of the user control
system with other applications; namely the web and the
web services applications. This leads to the support of
applications today already partly supported in the browser
but not consistently open to all the application on the
machine (like the ldap:, the go: etc. schemes).
The last step is the relation of the user control system
(dispatcher) with other dispatchers: OPES on the path
of the flows or other user control systems, the user
control system is in relation with. This may be on the
fly. This may also be a lasting cooperation, with
shared services. I call them ONES because they are
open (to several users choosing them), networked,
they extend the capacity of the relation, with its own
processing assistance, into a computer assisted
networked continuity of services.
Alex.
On Thu, 6 Mar 2003, jfcm wrote:
>
> On 18:54 05/03/03, Alex Rousskov said:
> >On Wed, 5 Mar 2003, jfcm wrote:
> >
> > > I would like to know if you consider the IDNA process as an OPES or
> > > not. It changes data in the flow from the user's point of view.
> >
> >I assume that by IDNA you mean draft-ietf-idn-idna-14.txt. I also
> >assume that by "IDNA process" you mean ToASCII and ToUnicode
> >conversions documented in the above draft.
>
> It is now a Standard.
>
> >If so, then I think it is possible to have an OPES system that, for
> >example, does ToASCII and ToUnicode conversions for HTTP Request-URIs
> >and Host headers.
>
> This is the way it works today.
>
> >However, I think that such a system would have to be
> >tightly integrated with the application proxy itself, loosing primary
> >advantages (and design goals) of OPES. I will try to explain below.
>
> Not tighen. In close control.
>
> > >From a [very] quick scan of the IDNA draft, it appears that the
> >authors want user applications (not intermediaries) to do the
> >conversion. The latter makes a lot of sense because unconverted names
> >in protocol messages may produce illegal messages and illegal messages
> >may be dropped before they reach OPES processor.
> >
> >In other words, OPES is designed to adapt valid application messages.
>
> That is the whole question. As you may have noted IDNA only solves
> a small part of the IDN support. It does not solve all the numerous
> cases indicated in the document, it does not solves vernacular, it
> does not solve soundex etc., it does not solve multilingual TLDs.
> This can only be addressed by a value added controller, which is
> then the user application. That application is entered through the
> browser and triggered through the brother. So it is an OPES for
> the user, but logically it is a parallel process - what has not bee,
> though up-to-now?
>
> Other services can be proposed the same way, like abbreviated
> DN entry (for years I do not enter the http:// and the browser adds it,
> but I could not enter my favorite TLD and a parallel process add it)?
>
> This leads ton consider which piece of code will be supporting the
> callout protocol? The browser, the plug-in?
>
> jfc
>
>
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03