Excellent start.
There is an asymmetry in the IAB considerations that I don't
understand. The content providers must be able to detect and *respond
to* client-centric actions, but endusers are only given the ability to
detect. I don't know why that exists, and I think it was a mistake by
the IAB. At any rate, I think we are giving short shrift to the
"respond to" part of the consideration.
I see a couple of problems that need discussion. The main one is the
caching proxy issue. If OPES is deployed on a caching proxy, near the
"consumer" end user, then the content provider endpoint will not
receive a request for each use of the data. The draft seems to ignore
this. I think the server must be provided with a signalling
capability to ask that some notification of the request and the
possibility of OPES services be sent on each use of cached data.
The draft also alludes to the server being able to query the OPES processor
about its services. One could imagine that a server, on first hearing
about an OPES processor in some path, would immediately query it to find
out if it supported any of list of problematic services; it would then
either include the list of banned services in its headers or it would
specifically request that the service be disabled for its own content.
However, that adds either a requirement for additional header information
that the OPES processor must be respond to, or it adds a query/response
protocol. Both are substantial requirements.
Hilarie