- From: Matthias Schunter <mts-std@schunter.org>
- Date: Sat, 25 Aug 2012 08:46:01 +0200
- 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? 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