- From: David Singer <singer@apple.com>
- Date: Wed, 08 Feb 2012 08:46:54 -0800
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Tracking Protection Working Group WG <public-tracking@w3.org>
On Feb 7, 2012, at 18:13 , Roy T. Fielding wrote: > On Feb 7, 2012, at 9:50 AM, David Singer wrote: >> The absence of a response header does have the huge downside that there is no 'automated discovery' of compliance in the transaction, and UAs that rely on that will assume the worst. If we go with SHOULD, this needs clearly stating. > > There is no automated discovery of compliance in headers, regardless. > Compliance to requirements that apply over time and across multiple > requests can only be detected by observing behavior over time and > multiple requests. Just because a header says that the server complies > does not mean the server complies. UAs that actually depend on compliance > should be checking against a curated list, just like fraud avoidance. > > IMO, the response header is a complete waste of time and bytes. It is > a very expensive delusion. > > In the entire history of HTTP, the only other protocols that defined a > response header to indicated compliance were MIME-version (ignored), > DAV (ignored), PICS (failed), and P3P (ignored). I don't understand why > this WG needs to make the same mistake. OK, but Roy, the statement of mere compliance is only one of the reasons for the response header, as I am sure you recall. Two others are: * did my request (outbound header) get through, or was it stripped or mangled by an intermediate? * do I and my user-agent agree about the status and position of the party I am communicating with (1st/3rd, assertion of opt-in, claimed exceptions)? This are both dynamic questions that cannot be answered by a static policy. David Singer Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 8 February 2012 16:51:22 UTC