ietf-openproxy
[Top] [All Lists]

Re: is IDNA an OPES?

2003-03-05 19:58:30


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.

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



<Prev in Thread] Current Thread [Next in Thread>