Graham Klyne wrote:
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.
I agree, but I thought this would rather be part of the "endpoint
authorization and enforcement requirements" document (which is also on
our charter) rather than the architecture document.
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.
Absolutely, yes. Maybe this should be stated.
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?
We somehow need to get these (tracing) pointers to the enduser - and
one way of doing this is in-band.
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.)
If there's no extensions/addition at all, how would we get the trace
pointers to the enduser, so that the enduser can retrieve the more
detailed information fro mthe OPES boxes?
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.
Point taken. We need to see what the concensus of the WG is and than
make a clear case for it.
-Markus