Subject: is IDNA an OPES?

From: jfcm <[email-masked]>
Date: Wed, 05 Mar 2003 01:21:29 +0100

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. The reason why I 
ask is that the plug-in used to support IDNA may be used for other purposes 
as well (as a dispatcher), support OPES management and be a candidate for 
callout protocol - for example to support DNS like services. An example is 
the "go:" scheme ftp://ftp.rfc-editor.org/in-notes/rfc3368.txt
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 5 Mar 2003 10:54:23 -0700 (MST)

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.

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

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.
Application messages with raw international domain names are likely to
be invalid for many protocols (e.g., HTTP). Thus, while it is possible
to design a specific OPES-based system for IDNA conversions in some
environments, OPES and IDNA do not play well together in general.

Disclaimer: I am by no means an expert on IDNA. I just looked through
the draft! Please correct me if I am wrong.

$0.02,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 5 Mar 2003 13:39:52 -0700

I haven't read the IDNA draft either, but I'll accept your analysis
and quibble a little with the characterization of OPES as acting only
on "valid application messages".  One value of proxies is the ability
to deal with commonly malformed requests and responses - things that
were not well described in the application specification and lead to
unneccessary loss of interoperability.  Being that this kind of fixup
is a reasonable proxy function, it should also be a valid OPES
function.  So, I'd think IDNA may well be an OPES scenario.

Hilarie

---

From: jfcm <[email-masked]>
Date: Thu, 06 Mar 2003 03:01:30 +0100

>conversions documented in the above draft.

It is now a Standard.

>and Host headers.

This is the way it works today.

>However, I think that such a system would have to be

Not tighen. In close control.

>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

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 5 Mar 2003 19:52:58 -0700 (MST)

On Wed, 5 Mar 2003, The Purple Streak, Hilarie Orman wrote:

> on "valid application messages".

By "valid" I mean "parsable", essentially. Handling slightly
malformed or semantically questionable messages is an [unfortunate]
MUST for modern systems, of course. My understanding is that raw
international addresses will not be parsable by most existing
systems; that is why we may need IDNA.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 5 Mar 2003 19:58:33 -0700 (MST)

OPES protocol is not meant to be a general-purpose plugin interface.
What you describe is a good application for a browser plugin, 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.

Alex.

---

From: jfcm <[email-masked]>
Date: Thu, 06 Mar 2003 15:15:46 +0100

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.

>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

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.

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

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 6 Mar 2003 18:26:01 -0700 (MST)

On Thu, 6 Mar 2003, jfcm wrote:

> I do not see how an OPES protocol (between dispatcher/server) can be
> an interface? You mean "plugin access protocol"?

Any protocol is an interface. In our case, the interface lets
integrators plug a callout server into an OPES processor. In the IDNA
case, there could be a browser plugin protocol/interface that lets
users add IDNA conversion plugins to their browsers (without modifying
browser software or the plugin, of course).

> I talked about IDNA and you decided IDNA was on the browser.

I did not decide. I just suggested it as an example of where IDNA
conversion would work well. According to IDNA draft, IDNA conversions
are done in a user application. A browser is a well-known user
application. It is just an example.

> of it, or it should run in parallel to the browser and use it

In your example, the IDNA conversion software is plugged into the
"user system" and other system components (such as browser)  may
recognize and use it as necessary (probably via some kind of "plugin"
service interface).  That's a fine example, and I suspect that is how
many new/patched systems could support IDNAs.

Still, my reasoning remains valid, I think: One cannot do IDNA
conversions outside of the user application (the application can, of
course, use "user system" resources like in your example, but that
does not change anything). This limitation puts IDNA out of OPES scope
because "users" and their applications are out of OPES scope. Again,
OPES is a proxy service.  IDNA conversion (in both your and my
examples) is not.

I am just trying to answer your original question (see the Subject:
line)...

[ good stuff about user control systems snipped ]

> What may be/is is the case.

...

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

It looks like you are investigating whether user control systems can
benefit from talking to OPES agents and how such communication might
change OPES. If that is your motivation, this group should certainly
consider any new requirements that your use cases may mean to OPES.

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?)?

Thanks,

Alex.

---

From: jfcm <[email-masked]>
Date: Fri, 07 Mar 2003 17:25:44 +0100

>browser software or the plugin, of course).

Accepted. Unfortunately not the case. Hence my question. IDNA
is an accepted universal need. The initial support of the IDNA and
probably for still some time is through a plugin. That plugin is of
no real interest if it is a browser oriented service, because was is
really needed is resolver front-end, for all the local applications.

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.

>OPES is a proxy service.  IDNA conversion (in both your and my

Your reasoning is valid as long as you decide that the IDNA
application applies to the browser or to the mail agent.  I say
that the IDNA is far better located at the user control system
because the IDNA is actually one small building block of the
IRL (Internationalized URL) of which the other services will not
be standardized before long, while they start being widely
used.

>I am just trying to answer your original question (see the Subject:

I fully understand. I also consider that this may be the last
chance to see the real IDNA being specified by the IETF before
it comes out of control.

>consider any new requirements that your use cases may mean to OPES.

Yes. 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)
- be multilingual (IDNA++)
- interact with the user
- keep permanent user informations, etc.

But at the same time it may relate with services in using the
callout protocol, interact with other dispatchers,  etc.

>user control systems instead?)?

You keep asking me to discuss cases. So I proposed a case.
That case is also a very current issue. But certainly the universal
multilingual standalone user control system is an issue of real
interest.

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.

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 11:10:44 -0700 (MST)

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.
Malformed messages cannot be transmitted reliably because
non-IDNA-aware intermediaries may not forward them. Thus, one would
have to change HTTP standard and/or HTTP applications to be able to
use OPES for IDNA conversions within HTTP messages, under general
assumptions. I suspect the same is true for SMTP, but I am not an SMTP
expert.

Inapplicability of the OPES approach to malformed messages is the only
point I have been trying to make in this thread. If you want OPES to
help with IDNA, how would you address the formatting (i.e., parsing)
problem for protocols that do not allow raw IDNA addresses? Note that
it is not an OPES problem, it is an application protocol problem.

> application applies to the browser or to the mail agent.  I say that
> the IDNA is far better located at the user control system because
> the IDNA is actually one small building block of the IRL
> (Internationalized URL) of which the other services will not be
> standardized before long, while they start being widely used.

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

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

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

possible (there is just no consensus whether OPES dispatcher or
callout server can do that)

> - be multilingual (IDNA++)

irrelevant to OPES; it is the application protocol that must be
multilingual, not OPES

> - interact with the user

possible to the extent the application protocol supports user
interaction

> - keep permanent user informations, etc.

possible if the application protocol allows it

> callout protocol, interact with other dispatchers,  etc.

True.

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

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

Thank you,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 7 Mar 2003 11:20:37 -0700

A proxy can be co-located with an application, using the same protocol
as if they were are different machines.  However, this doesn't seem to
be a preferred implementation method, probably due to the overhead
involved.  The more usual path is that someone defines an API that can
be implemented through direct subroutine calls, and then extends this
to work with RPC's for remotely located services.  The advantage
being, of course, that one can write the callout service once and have
it run locally or remotely.

I think most browsers are already extensible, in their own ways, and
while it would be gratifying to have them switch to using a standard
method that is compatible with OPES servces, I don't see much reason
for that to happen.  Our focus for the IETF is on services that benefit
from running remotely - because the services are more efficient when
amortized over many connections or some other engineering reason.  

Surely there are other kinds of services that could run either
remotely or locally, or services that are best run locally, but these
will have to grow and flourish without diverting the attention of this
WG.  It's fine to discuss such possibilities, but keep in mind that
they cannot be the motivating examples for design decisions.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 7 Mar 2003 12:47:45 -0700 (MST)

Hilarie,

	I agree that WG primary focus should be on OPES services that
are executed "remotely" rather than integrated into the proxy code.
Such remote execution includes execution on the proxy box, of course.
My understanding is that jfc wants to use remote OPES services as
well. There seems to be no conflict here.

	As far as I can see, the problem is that we (well, myself, at
least) are not sure what exactly jfc proposes as a potentially new use
case or application area for OPES. It is clearly not just giving any
single user application (e.g., a browser) an ability to talk OPES. The
issue seems to be related to entire user-side systems communicating
with OPES agents in yet unknown ways.

	I sense that we may be talking about a Universal Callout
Interface for Web Services, but I do not have enough information to
conclude that. Otherwise, I would already argue that the discussion
should be terminated because no such interface can be built, not even
by XML fans.

	Until we know exactly what jfc is after, I cannot say whether
those new use cases can be "the motivating examples for design
decisions" or not. I simply do not know what those new use cases are
and what new requirements they bring (besides IDNA conversion that
seems to be impossible in OPES framework). Perhaps others have a
better understanding.

Alex.