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

Re: when the Tk header is required

From: Matthias Schunter <mts-std@schunter.org>
Date: Sat, 25 Aug 2012 08:46:01 +0200
Message-ID: <503874A9.2050007@schunter.org>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Hi Roy/Nick,

I believe that the semantics described by Roy is sound since it prevents
surprises: If the well-known URI says "n" (no tracking), then individual
resources cannot deviate from this statement.

A special case is the case where no statement is made in the well-known
URI. In this case, I assume, any indicators are permitted since "no
statement" translates to "our resources can later specify any behavior".

Roy: Could you document this semantics in the spec more clearly?


On 23/08/2012 20:40, Roy T. Fielding wrote:
> Begin forwarded message (with permission from Nick):
> On Aug 18, 2012, at 6:07 PM, Nicholas Doty wrote:
>> Hi Roy,
>> On reviewing the "Communicating a Tracking Status" section, I've come across an ambiguity, or perhaps a missing requirement. Namely, is it the case that if a request's tracking status differs from the site-wide tracking status then the response MUST include a Tk header that points to an alternative tracking status resource?
>> I think that's the intended outcome because otherwise the user agent could be misled about the tracking status of a resource because it had previously requested the site-wide tracking status and hadn't received a Tk header pointing it to a request-specific tracking status resource.
> Hi Nick,
> Thanks for the review.
> I think the intention is that the site-wide tracking presents a
> "worst case" answer for the entire site ("N", "1", "3", or "C"),
> or "X" if the status is unspecified.  So, the WKL might say "3"
> and then the header might have any of the above; if the WKL says "N",
> then only "N" would be allowed for specific resources.
> I agree that we need more text to define that.
>> If so, perhaps we should clarify that in the spec by noting in 5.3.1 that the response header is required both for state-changing requests (with a value of "U", presumably) and any request for which the tracking status differs from the site-wide tracking status. Similarly, in 5.3.2 and 5.4.2 it seems we should indicate that, when a request's tracking status differs from the site-wide tracking status, the origin server MUST have additional well-known resources that correspond to distinct tracking statuses and MUST use the Tk header and its status-id field.
> It is possible for the header to give a final answer if the other
> information fields in the WKL are sufficient.
> ....Roy
Received on Saturday, 25 August 2012 06:46:28 UTC

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