Subject: Re: is IDNA an OPES?

From: jfcm <[email-masked]>
Date: Fri, 07 Mar 2003 21:55:01 +0100

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

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 7 Mar 2003 15:16:24 -0700 (MST)

>      (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.

>      IF it is provided to several applications trough the

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.

> 5. What should be investigated is the "user control system".

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.

> - 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:

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.