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.