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

On Oct 14, 2011, at 2:40 PM, Kevin Smith wrote:

> 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)

Speaking as an editor of the HTTP spec, I do not want to see
yet another three-digit response code in HTTP.  They are useful
for status codes because we expect to need the space and the code
is often visible to users.  A similar three-digit code was added
for cache warnings, and that was a horrible mistake.  Any discussion
about such codes leads to confusion with the status codes.

> 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.

My intention is to initially spec the usual HTTP extensibility mechanism

  ( "0" / "1" ) *[ ";" token [ "=" ( token / quoted-string ) ]]

and state in the prose that recipients need only parse the first
character of the field-value if they do not support extensions.

Also, there is no deployed practice for a response header field,
so I do not plan on reusing the DNT field-name for both -- that is
just too confusing.  If a response header field is necessary, it
can be something like

  Tracking: 0

and then I don't have to spend paragraphs trying to explain
directionality of messages to the reader (i.e., what DNT means
if it is received as a client as opposed to what it means as
received by a server).  Let me know if that is a problem.

....Roy

Received on Wednesday, 19 October 2011 00:51:24 UTC