RE: tracking-ISSUE-81: Do we need a response at all from server?

Matthias,

You indicated the potential value. I feel we should tease out who would realistically take advantage of those benefits and to what extent. If less than 1% of consumers would look at the values would it be worth every web site changing their servers to send the response?

How would the consumer see the values if they wanted to? 

JC

-----Original Message-----
From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Matthias Schunter
Sent: Tuesday, October 11, 2011 3:41 PM
To: public-tracking@w3.org
Subject: Re: tracking-ISSUE-81: Do we need a response at all from server?

Hi JC,


thanks for this valuable input to our discussion of response headers.

I believe that it is important to investigate the potential benefits:
  Why do we need response headers; what purpose should they serve?

Once we see clearer, we can then identify the cost-optimal implementation.

Value I've seen so far are:
 - Reflecting the preference of the user to identify
   transmission errors
 - Communicating the choice of the server whether to comply
   with a DNT preference or not
 - Determining whether a server understood a preference or not.

Are there values that I've overlooked?

Another discussion to have is the scope of responses: Do we want the
server choices to be a fixed value for a site or unique subsets or
requests?


Regards,
matthias



On 10/11/2011 10:13 PM, JC Cannon wrote:
> We think the topic of a response to the DNT header will require a fair
> amount of further discussion.  We think that a number of other issues
> should be resolved first before we can reach a consensus on whether it
> should be sent and what it means. Here are some specific concerns:
> 
>  
> 
> COST OF IMPLEMENTATION
> 
>  
> 
> While most web server environments do make it simple to return a HTTP
> header as part of the response, integrating a way to return such a
> header into existing systems isn't necessarily straightforward. Some
> systems used today to combine web requests with information known
> about the user to form targeted responses and do not allow for an easy
> way to derive what opt-ins are in place and why the response is the
> way it is. A response header that indicates what the service saw in
> the DNT request AND how it was processed is not always a trivial
> engineering exercise.
> 
>  
> 
> VALUE OF IMPLEMENTATION
> 
>  
> 
> Today browsers are consistently moving in the direction of less and
> less user interface, reducing the number of choices users must make to
> experience the web, and trying to make smart choices on behalf of the
> user. It's not immediately obvious that all browser vendors will want
> to process a DNT response and take any action. Before we can truly
> evaluate the benefit of a response, we should have a clearer idea of
> what browser vendors want to do with this information. There is little
> benefit to the community in requiring online services to invest in
> being able to return a response if the value is then ignored.
> 
>  
> 
> WHEN TO RETURN A RESPONSE
> 
>  
> 
> To fullyunderstand the benefit of a response, we need to understand
> when a response would be required. If we conclude too early that a
> response is required we run the risk of creating reasons to have some
> kind of value and potentially making the response more and more
> complex. Perhaps a good resolution at this point is to agree that
> nobody believes having a response is detrimental but until we address
> some of the other questions before us (e.g. first party vs. third
> party) it will be hard to demonstrate that the cost is worth the benefit.
> 
>  
> 
> INCREASED LOAD ON WEB SERVERS
> 
>  
> 
> We share Roy's concerns [1] about additional load on servers and
> content caches.
> 
>  
> 
> [1] http://lists.w3.org/Archives/Public/public-tracking/2011Oct/0047.html
> 
>  
> 
> JC
> 
> Twitter <http://twitter.com/jccannon7>
> 
>  
> 

-- 
Dr. Matthias Schunter, MBA
IBM Zurich Research Laboratory,  Ph. +41 (44) 724-8329
Homepage: www.schunter.org, Email: schunter(at)acm.org
PGP Fingerprint    989AA3ED 21A19EF2 B0058374 BE0EE10D

Received on Tuesday, 11 October 2011 23:01:27 UTC