- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 25 Apr 2013 13:36:32 -0700
- To: Rigo Wenning <rigo@w3.org>
- Cc: public-tracking@w3.org, Alan Chapell <achapell@chapellassociates.com>, David Singer <singer@apple.com>, "Edward W. Felten" <felten@cs.princeton.edu>
On Apr 25, 2013, at 10:54 AM, Rigo Wenning wrote: > Alan, > > let me try with some alternative wording to overcome this > misunderstanding: > > To turn DNT on: > > 1/ A user must be informed clearly and accurately about the choices > available before turning DNT on or off. > > 2/ When making the choice, the user must have access to explanatory text > to provide more detailed information about DNT functionality and the > parties involved in the DNT functionality > > This takes away the "user agent". Your understanding of the Web is > narrowed by the entrenched discussion around defaults. But the issue > here is not defaults, but that the Web can run on everything. Thus you > have to address the requirements in a more neutral way so that it > doesn't say user agent, as your fridge is not the user agent in the > classic sense of a browser. That is not what user agent means (a fridge is a user agent if it can initiate HTTP requests). Ed's point was not that the user agent might not be a browser, but rather that the mechanism for setting a DNT configuration used by the user agent is not inside the user agent (and thus not subject to constraints that only target the UI of a user agent). Hence, Rigo's text is closer to the mark because it can apply to the act of configuring a personal proxy or via an external interface to a user agent. However, this entire discussion seems to be ignoring our prior decisions on ISSUE-4. If we are going to have requirements on the configuration of a user preference, they need to be consistent with the protocol expressed in TPE. So, at minimum, you have to incorporate all of the options regarding how those preferences might be set, as described in section 3 of TPE. The reason we have section 3 in TPE is because the semantics of a header field are defined by how, why, and when that field is sent. These cannot be separated from the protocol, since they are the most important part of any protocol (syntax is often trivially rearranged at the end of discussing what should be communicated). ....Roy
Received on Thursday, 25 April 2013 20:36:52 UTC