Alex,
good job.
I really personally prefer to just used the term OPES as specified by the
charter. If IDNA can be a scenario, then it can be added. However, I would
like to avoid name confusion.
abbie
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Wednesday, March 05, 2003 12:54 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: is IDNA an OPES?
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.