Haim,
> 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)
The group does not specify requirements for an 'OPES engine', but more
specific for service invocation/tracing and policy/rules
specification. Of course, these cannot be developed in isolation,
which is why the group also *drafts* a general 'OPES
architecture/framework'. The issue you raise can be considered - at a
high level, without going into details - in the overall
architecture/scenario documents. Based on the outcome of the
discussion, we would then have to examine whether and how it impacts
the requirements for service invocation/tracing and policy/rules.
> 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.
This aspect certainly is of relevance and needs to be discussed in the
context of defining "policy specification method(s) and rules for
controlling execution of OPES services". To get started, did you have
a look at former work in the now expired ID named
draft-rafalow-opes-policy-requirements-00.txt, and the ID named
draft-beck-opes-irml-02.txt? Note, these are NOT WG documents, but it
would be helpful if you would suggest whether these documents somehow
address your concern, and if not, where and how it could be integrated.
Cheers,
Markus