- From: Kevin Smith <kevsmith@adobe.com>
- Date: Tue, 20 Dec 2011 15:35:58 -0800
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: "<public-tracking@w3.org> (public-tracking@w3.org)" <public-tracking@w3.org>
I prefer to leave syntax open to be extended, but not actually write in unused syntax until its needed. Future-proof means don't paint yourself into a corner - make it possible to easily add stuff in the future. It does not mean - try to guess what we will want in the future and add it now. -----Original Message----- From: Roy T. Fielding [mailto:fielding@gbiv.com] Sent: Tuesday, December 20, 2011 3:09 PM To: Kevin Smith Cc: <public-tracking@w3.org> (public-tracking@w3.org) Subject: Re: Request to close ISSUE-78 On Dec 20, 2011, at 12:50 PM, Kevin Smith wrote: > I see. So, if we stick to this definition, clearly no DNT header does NOT mean the same thing as DNT:0 because DNT:0 actually means DNT is turned on. However, if DNT:0 means DNT is on, but there is a local exception... That means that the user-agent knows about the exception so that it can send the correct header. I thought this was still an area of hot debate, whether the browser would store a formalized list of exceptions. I believe Shane just barely submitted a proposal on this 2 days ago, and if I remember right (although this may have changed), the google representative stated that they were not interested in managing DNT exceptions in Chrome. > > Point is, if we decide against browser managed exceptions, than this definition might not make much sense. No, it might not be *used* in this edition of TPE, but it still makes sense for application to future extensions, independent browser innovations, or standards to be defined later. The requirement is intended to be future-proof so that recipients will understand the semantics even if deployed user agents never get around to sending them. ....Roy
Received on Tuesday, 20 December 2011 23:36:32 UTC