W3C home > Mailing lists > Public > public-tracking@w3.org > August 2012

Re: when the Tk header is required

From: Rigo Wenning <rigo@w3.org>
Date: Tue, 28 Aug 2012 20:27:41 +0200
To: public-tracking@w3.org
Cc: David Singer <singer@apple.com>, Nicholas Doty <npdoty@w3.org>, "Roy T. Fielding" <fielding@gbiv.com>
Message-ID: <2560666.imriiFultJ@hegel.sophia.w3.org>
On Monday 27 August 2012 09:59:05 David Singer wrote:
> > I think the policy of "site-wide resource unless a Tk header
> > is present which would override" would be more efficient for
> > implementers. Sites could then use the model of a site-wide
> > tracking status resource being the default but any exceptions
> > being documented in a request-specific resource or specific
> > header. That was my understanding of the Google use case
> > request, for example.
> That makes sense.  
> I also recall that the original motivation for the well-known
> resource was that replies of the kind "I respect your DNT:1
> header" or "I currently behave to you as a 3rd party" were
> user-specific and hence not cachable.  However, many (most) of
> the responses are now of the form "I am designed to be used in a
> 1st party context", i.e. static statements of intent rather than
> user-specific statements of current state.
> Given the concerns about caching, it seems it's worth asking
> whether it works better 'the other way up':  make general,
> cachable statements in the Tk header, and if that is missing (or,
> better, says "ask me"), then ask the UA to resort to the
> well-known resource (which can be a CGI) for personal/contextual
> answers.

Support from me for that. In the other answer, Roy said it isn't an 
answer to _this_ request. But _this_ request is part of an assertion 
on _all_ requests. Thus the statement is binding, legally. So some 
cloudy statement may be more harmful to the service than a system 
where the site-designer can trigger a different answer for _this_ 
request at any moment by sending a TK-Header.

Received on Tuesday, 28 August 2012 18:28:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:54 UTC