RE: [ISSUE-81, ACTION-13] Response Header Format

I agree with you.  In fact, I am still not sure we need a response header at all.  I was just pointing out that if we do have a return header, we might want to think about possibly grouping answer types.  As for the 300 series options, I thought it might make a good web server default (ie for small sites using shared hosting that do not even look at their server settings), although the absence of a header would likely meant the same thing.

From: JC Cannon [mailto:jccannon@microsoft.com]
Sent: Saturday, October 15, 2011 2:01 PM
To: Kevin Smith; public-tracking@w3.org
Subject: RE: [ISSUE-81, ACTION-13] Response Header Format

First parties should not have to return a response. We could have a response for third parties acting in a first-party context such as search windows that are in use.

I don't see how the 300 series responses are practical.

JC
Twitter<http://twitter.com/jccannon7>

From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Kevin Smith
Sent: Friday, October 14, 2011 2:40 PM
To: public-tracking@w3.org
Subject: [ISSUE-81, ACTION-13] Response Header Format

I am still not convinced a return header is necessary, but if we decide it is, as Tom mentioned in Action 13, it is important that our spec be very extensible for possible future modifications.  The binary approach he suggested (1 = Respect the DNT signal, 0 = Will not respect) is certainly easy to extend.  If other responses are needed, you can easily add additional codes.  If we wanted to add textual explanations as Peter (I think) suggested in Boston, or URIs to definition documents as Roy suggested, they could easily be appended to the header.

However, one thing that a 0|1 response would make it difficult to do in the future would be to group different types of responses such as defined reasons why a site may or may not respect the DNT header.  If we think it is likely that additional responses will be needed now or in the future, we may want to follow something closer to the http response codes (ie 200s = ok, 300s = redirect, 400s = bad request etc)

For example,

100 = Will not respect DNT (same as currently suggested 0)
101 = Will not respect because I am a 1st party
102 = Will not respect because you have opted in to my tracking
103 = Allowed to track because it's for research (possibly)
104 = Allowed to track because of exemption X
...

200 = Will Respect DNT (same as currently suggested 1)
201 = Even though DNT was not turned on, you have an opt-out cookie
202 = I never track
...

300 = I don't know (could be the default, and probably means the same thing as no response)
301 = Don't know because I have never set up a web server before, I don't know what DNT means and I will never get enough hits for anyone to care about what I do anyway.  (OK, we probably do not need a code for this - just checking if you are still reading)
...

Then if a browser or plugin wanted to provide a more customized experience to the user, it could use this additional information.  I am not saying that we should take this approach now (or ever), but if we wanted to start with the simple binary approach, perhaps we should start with codes 100=No, 200=Yes (or something similar), so that we leave our options open in the future.

Note: this is certainly not the only way to do it.  We could also go with a 0|1 now, and then add a delimiter with a subcode (ie - 1:2 = You have opted back in).  I just thought this may be a good grouping mechanism that is easy to parse and process.

Just food for thought.

-kevin