On Thu, 3 Apr 2003, jfcm wrote:
At 07:32 03/04/03, Alex Rousskov wrote:
3. An OPES processor MUST add to the trace identification
of the "system/entity" it belongs to. "System"
ID MUST make it possible to access "system" privacy
policy.
I disagree with the MUST.
- first there are system which does not want to be known.
Yes, but it looks like IAB prohibits us from "supporting" an OPES
system which does not want to be known:
(5.1) Privacy: The overall OPES framework must provide for mechanisms
for end users to determine the privacy policies of OPES
intermediaries.
Thus, an OPES intermediary that does not want to be known cannot be
OPES compliant, but will, of course, interoperate just fine. Also, we
still need to decide what that ID is. We may be able to support IDs
that do not reveal much of private info.
Furthermore, since IAB does not seem to care about content provider
privacy, we may want to polish the above rule 3 so that it applies to
providers only (and is only a MAY for client-side intermediaries).
- most of all this would block innovation. Information services
could be actually built as a core system and a daisy chain of OPES.
Information on the system structure is propreitary. There is no
"system" privacy policy by application components.
This is not a problem due to the rule 4 that allows aggregation of
tracing information to hide system structure. We just need one trace
entry from each system, we do not care about individual OPES
intermediaries inside that system:
4. An OPES processor MAY group the above information
(items 1-3) for sequential trace entries having
the same "system/entity" ID. In other words, trace
entries produced within the same "system/entity"
MAY be merged/aggregated into a single less detailed
trace entry.
This is very similar to Via headers in HTTP that face similar
challenges.
Alex.