Re: when the Tk header is required

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 Thursday, 23 August 2012 18:40:48 UTC