Re: when the Tk header is required

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?

Regards,
matthias

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