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.
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.
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:
- change the URL (redirect)
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
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.
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.
Thank you,
Alex.