Stepping back for a moment, it seems to me that you need to identify
four essential things relevant to a "traceable entity" (Oskar called
these "reference points", I believe):
2. Identification of the party responsible for setting and
enforcing that policy.
3. Information pointing to a technical contact
4. Information that identifies, to the technical contact, the
OPES processors involved in processing the message
Item 4 can be opaque, i.e., only has meaning to the technical contact.
I don't know if we want to standardize the representation of any of this,
other than the tracing header names.
From a protocol standpoint, it is certainly easiest to just say that
every OPES processor is a traceable entity and that callout servers
MAY be traceable entities.
There has not been any discussion of what triggers tracing. I suppose
it must originate from an endpoint (consumer or provider). Is it "per
request" or "per connection" or "per something-else" (application-specific)?
Or required all the time?
There's also the question of "who's asking?" Items 1-3 might be
considered sensitive information, relevant to competitors, or even
security and privacy relevant. So a consumer might intend a trace
request to mean "tell me what is applied by my network service
provider and entities he contracts with, and anything else you can
find out from the provider, but don't tell the content provider
anything." And a caching OPES processor might send requests to
content providers with a tracing request that meant "one or more of my
consumers has requested tracing" and would cache the response with
So, maybe tracing responses should be optional, and there should be a
header that means "tracing request received and denied." Of course, that's
weird - who received it, who denied it? Some unidentified OPES processor
I seem to have run into a conundrum here --- should we define tracing
for all systems that do not trace themselves? :-)