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

Shane,  your suggestion works great as long as the# of responses stays fairly small.  However, if we foresee (and I know this probably depends on the resolution of some of the other issues), that we may have many more response types, than providing a grouping structure may make sense.

For instance, if we think there may eventually be 10 reasons a server may send a "Will Track" header, and 10 reasons a server may send a "Will Not Track" header, we could continue to extend the model you mentioned by having codes 1-20 in the order that the response types became necessary.  A browser that wanted to handle all "Will Track" responses generically (while possibly handling specific exceptions individually) would have to check against all 10 "Will Track" response codes, and would have to update their code every time a new code was added.  However, if response codes were grouped into ranges (such as 100s = Will Track etc), then the browser only needs to check whether the response code is in a given range.  And if a new response type is added 5 years from now which is another reason that a server will send back a "Will Track", as long as that code is within the preset range it will be handled automatically by the browser's default methods until such time that the browser wants to add functionality for that specific code.

It really all depends on how many codes we anticipate.

From: Shane Wiley [mailto:wileys@yahoo-inc.com]
Sent: Sunday, October 16, 2011 12:06 AM
To: Kevin Smith; JC Cannon; public-tracking@w3.org
Subject: RE: [ISSUE-81, ACTION-13] Response Header Format

Would it be possible simplify this further?

<No Response> = DNT not implemented  (initial state for the vast majority of websites in the world)
0 = You've not turned on DNT but I have implemented support <not sure if this is needed>
1 = Received your DNT signal and honoring it
2 = Received your DNT signal and not honoring it due to prior exception granted

It'll be important to record exceptions client side as a Publisher will need some signal on whether to trigger an exception dialogue with a user or not.  I'll look up the appropriate item # to also attach this comment and example to.

Example Use Case:

1.       User turns on DNT and visits ExamplePublisher1.com

2.       ExamplePublisher1.com does not receive a signal it's on the exceptions list

3.       ExamplePublisher1.com requests exception from user to access content for free

4.       User grants exception to ExamplePublisher1.com (and listed parties <to be discussed separately>)

5.       User views content

6.       User returns to ExamplePublisher1.com a week later

7.       DNT signal is still turned on but ExamplePublisher1.com is sent an exemption flag (or else doesn't send a DNT signal at all)

8.       In either case, it'll be important that ExamplePublisher1.com know to not trigger the exception request for this user/web browser/device

- Shane

From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Kevin Smith
Sent: Saturday, October 15, 2011 8:43 PM
To: JC Cannon; public-tracking@w3.org
Subject: 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