Thanks for the quick reply.
The main advantage that came out of this in my mind was that it will make
the OPES engine a "generic" engine
for VASs. Admins may add new callout servers to their network with new and
innovative VAS (not yet on OPES list...),
and the OPES engine will use them without any change!
So the Q is: Does adding a requirement to the OPES engine:
"OPES engine should be a "generic" engine for VASs (does not need to
understand what the VAS is doing)"
is out of the charter ? (leaving the authodiscovery mechanism to another WG)
Another requirement which I would like to see is the ability of a client to
embed a rule for the specific
request/session only (again, in a secure/reliable way).
That means that for example a user wishes a language translation only for
One of the advantages is that once those VASs will cost the client money,
then he may wish to
have it on a per request base.
Mobile Internet & Broadband Division
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Sun, March 03, 2002 9:01 AM
To: Rochberger, Haim
Cc: Mark Nottingham; Reinaldo Penno; OPES list
Subject: Re: Another comment/addition on callout requirements
As I am a newcomer to the OPES effort, [...]
The requirement that I wish to add is that the OPES engine will
have an automatic (plug&play) mechanism, in the style of the DHCP
but with restrict requirements on security and authorization, to
identify a new callout server (both regular or SP callout server)
in its network domain, and register it with a unique service
identifier (if allowed - maybe in the simple case using a configured
Service/Server description, discovery, and registration is a separate
functionality. While it certainly is an important and interesting area
and should be mentioned in the overall architecture/scenario
document(s), the requirements and the development of such is not in
scope of the current OPES charter.
You might also want to check activities going on in the 'webi' group.
The 'webi' charter has a work item on "intermediary discovery and
description mechanism", which seems somehow related (although my
understanding is that the group is currently focusing on the 'resource
update protocol'). Mark and Ian certainly can jump in here :)