At 01:00 AM 5/21/02 -0400, Markus Hofmann wrote:
Wouldn't it be sufficient for OPES to provide trace information that
identifies the performed OPES service, and provide a pointer from where an
interested endpoint could obtain more detailed information (e.g. the
source of customization information for that specific service)?
Yes, that works for me.
> Section 2.3 ----------- It seems to me that the OPES rules are a
> cornerstone of the architecture, but very little is said about
> them.
For the architecture we just need to describe their existence and
where/how they fit in, but not their (internal) details.
I agree, not their internal details.
But some kind of indication of the scope of possible "conditions" and
"related actions" would be useful; e.g. for the conditions, presumably
there are expected to be mechanisms for testing the protocol parameters and
data content? And if examining data content, what sort of level of
analysis is expected to be supported?
I guess this boils down to identifying some (broad) requirements on the
standardized rule schema. At least to the extent of giving some
understanding of how much is expected to be handled by the filtering rules,
and how much is left to a callout processor.
> You also discuss using "the OPES callout protocol", which seems to
> say there is a single such protocol. It is not clear to me why
> there needs to be a single such protocol, as different
> dispatcher/server combinations might use different protocols
> according to the needs of the application. For example, I'd
> imagine a session-oriented protocol appropriate for an HTTP callout
> service, but for processing email flows a callout protocol based on
> email style messaging, or file sharing, might be more appropriate.
The goal is to have a single callout protocol independent from the
protocol being used in the data flow. Whether this is possible or not,
we'll see. Also, our current charter is restricted to HTTP and RTP/RTSP in
the data flow.
I thought about this a little more - is it a goal to have multi-vendor
interoperability between data dispatchers and callout servers? If so, the
role of OCP is clearer.
> The sort of design I might suggest would be that an OPES
> intermediary maintains an audit of services that are applied,
> possibly for a limited time. This audit should be accessible to
> affected clients using standard features of the protocol whose flow
> is being OPES-serviced.
Would you say that the current draft rules out such a design?
My my reading, yes, since it seems to depend on protocol extensions.
I could imagine that the general OPES tracing simply provides pointers
and information to the endpoints on (a) which OPES services had been
executed on the message, and (b) how the endpoints could retrieve more
information about these services, possibly including an audit. I don't
see the current draft would exclude something like that.
As far as it goes, that's fine. So why are protocol extension headers needed?
(See also my response to Marshall's comment about transparency.)
[later]
Yes, I see you responded too. Maybe I misread the intent here.
The sentence that disturbs me is this:
[[
The OPES architecture **requires** that tracing be feasible
on the OPES flow per OPES processor **using in-band annotation** through
header **extensions** on the application protocol that is used (e.g.,
HTTP).
]]
I think the requirement here should be that tracing is feasible *without*
using extensions on the application protocol. (Not saying that extensions
MAY NOT be used, just not required to get at tracing information.)
> Section 3.2 ----------- This touches on an area where I take issue
> with the IAB requirements on OPES (and have posted my comments
> elsewhere).
>
> [[ The primary data flow occurs between the data provider and the
> data consumer. OPES must not interfere with the capability of
> these parties to use end-to-end authentication and confidentiality.
> ]]
>
> Consider the case of an employee working for a corporation. I is
> the employee or the corporation considered to be the "data
> provider" or "data consumer" here. I particular, is OPES required
> to allow an employee to send encrypted data out of the organization
> without examination by an intermediary system?
Hm, one view expressed earlier is that the employee is the enduser and the
corporation runs the OPES system. Per employment agreement, the enduser
gives the corporation (i.e. the OPES provider) the right to filter the
data, i.e. the employee allows the corporation to install the
corresponding OPES rules. That might be controversial, but one possible
view. An alternative would be to rule out the possibility to use OPES for
these kinds of services...
The first scenario you describe is consistent with my experience of the
actual deployment of such software. I think it would be very unfortunate
if OPES couldn't handle this common case. However, my reading of the IAB
requirements didn't allow for that, so I'm thinking that it at least needs
to be drawn out more clearly.
#g
-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>