ietf-openproxy
[Top] [All Lists]

RE: Another comment/addition on callout requirements

2002-03-03 02:39:40

Hi Markus,

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
this request.

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.

Cheers,

Haim Rochberger
System Architect
Comverse
Mobile Internet & Broadband Division
Office: +972-3-766-9121
Mobile: +972-54-970-504
Email: Haim_rochberger(_at_)comverse(_dot_)com 
<mailto:Haim_rochberger(_at_)comverse(_dot_)com>


-----Original Message-----
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


Haim,

As I am a newcomer to the OPES effort, [...]

Welcome :)

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
symmetric key).

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 :)

-Markus

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