This issue comes to question - who has the final authority on what.
Authority domains should be divided between server's origin of authority and
client's origin of authority. None may have an absolute authority over all
OPES servers in the delivery path.
An example: virus checking. If the server is able to issue some directive
like "no OPES action" which disables all OPES intermediaries - any malicious
life form that takes control over the server may just defeat all antivirus
security.
Filters also may be made vulnerable to adaptive attack by probing using
trace/report facilities.
I think this also answers to the Markus question:
Any thoughts on that? How should this be addressed? Does this rule out
direct notification of CLIENT-CENTRIC actions to the CONTENT-PROVIDER,
or would the benefits of such notifications outweight the privacy
concerns? Might indirect notification by the client (based on OPES
tracing information) be acceptable, i.e. bringing the client back into
the notification loop? Does the client have a right to veto direct
notification?
There are cases like those above where we have conflict of interests between
content provider and content consumer. Such conflict undermines the
"benefit" approach - each side may have different understanding of
benefits.
I'd suggest limiting any MUST-level requirements in tracing/reporting
mechanism by appropriate authoritative domain ("color" in the architecture
draft terminology). Client definitely should have the veto right in it's
domain, otherwise it can not rely on certain types of legitimate OPES
services.
I do agree with Hilarie that detailed specification of this mechanism may be
delayed. Such a mechanism may be subject of a separate draft. But the
architecture draft should set the general framework and requirements for the
tracing/reporting.
Oskar