Re: when the Tk header is required

On Aug 23, 2012, at 11:40 AM, Roy T. Fielding <fielding@gbiv.com> 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 that's the intention, I agree we should clarify that in the spec. (We should also specify what the hierarchy of tracking up to "worst case" is.) 

Is that what we want, though? If a site has a single resource that is designed for and complies with the 1st-party tracking requirements, then the site-wide resource would have to list "1" and a "Tk" header would be needed on every response in a third-party context. That would seem to be an inefficient outcome for sites that mostly serve third-party resources but have a small site of their own for visitors to find out about their business and practices.

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.

Thanks,
Nick

Received on Monday, 27 August 2012 07:08:21 UTC