- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 2 Feb 2015 16:40:09 -0800
- To: Tracking Protection Working Group <public-tracking@w3.org>
I mentioned a few times on the calls that we should mark the DNS-extension
syntax as "at-risk" for CR. I have now done that by placing it within a
subsection and listing it as at-risk within the SOTD.
....Roy
p.s. The reason for doing this is to encourage folks who do plan to use
this feature to make comments to that effect during the CR period.
========================
Begin forwarded message:
Subject: CVS WWW/2011/tracking-protection/drafts
Date: February 2, 2015 4:32:19 PM PST
To: public-tracking-commit@w3.org
Archived-At: <http://www.w3.org/mid/E1YIRPf-0003nz-LZ@gil.w3.org>
Update of /w3ccvs/WWW/2011/tracking-protection/drafts
In directory gil:/tmp/cvs-serv14627
Modified Files:
tracking-dnt.html
Log Message:
mark the DNS-extension feature at-risk and isolate it within its own subsection
--- /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2014/12/17 20:27:06 1.277
+++ /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 2015/02/03 00:32:19 1.278
@@ -75,6 +75,14 @@
<a href="http://www.w3.org/2011/tracking-protection/track/issues/postponed">postponed</a>
issues regarding this document.
</p>
+ <p>
+ The following features are at risk and may be cut from the
+ specification during its CR period if there are no (correct)
+ implementations:
+ </p>
+ <ul>
+ <li><a href="#dnt-extensions">DNT-extension</a></li>
+ </ul>
</section>
<section>
@@ -424,6 +432,7 @@
<p>
The <dfn>DNT</dfn> header field is a mechanism for expressing the
user's tracking preference in an HTTP request ([[!RFC7230]]).
+ At most one DNT header field can be present in a valid request.
</p>
<pre class="abnf">
<dfn>DNT-field-name</dfn> = "DNT"
@@ -459,38 +468,46 @@
DNT: 1
</pre>
- <p>
- The remainder of the field-value, after the initial character,
- is reserved for future extensions. DNT extensions can only be
- transmitted when a tracking preference is <a>enabled</a>.
- </p>
- <pre class="abnf">
+ <section id='dnt-extensions'>
+ <h3>DNT Extensions</h3>
+
+ <p>
+ The remainder of the DNT field-value, after the initial character,
+ is reserved for future extensions. DNT extensions can only be
+ transmitted when a tracking preference is <a>enabled</a>.
+ The extension syntax is restricted to visible ASCII characters that
+ can be parsed as a single word in HTTP and safely embedded in a
+ JSON string without further encoding
+ (<a href="#status-representation" class="sectionRef"></a>).
+ </p>
+ <pre class="abnf">
<dfn>DNT-extension</dfn> = %x21 / %x23-2B / %x2D-5B / %x5D-7E
; excludes CTL, SP, DQUOTE, comma, backslash
- </pre>
- <p>
- For example, additional characters might indicate modifiers to the
- main preference expressed by the first digit, such that the main
- preference will be understood if the recipient does not understand
- the extension. Hence, a field-value of "1xyz" can be thought of
- as <q>do not track, but if you understand the refinements defined by
- x, y, or z, then adjust my preferences according to those
- refinements.</q>
- </p>
- <p>
- User agents that do not implement DNT extensions MUST NOT send
- DNT-extension characters in the DNT field-value.
- Servers that do not implement DNT extensions SHOULD ignore anything
- beyond the first character.
- </p>
- <p class="note">
- The extension syntax is restricted to visible ASCII characters that
- can be parsed as a single word in HTTP and safely embedded in a
- JSON string without further encoding
- (<a href="#status-representation" class="sectionRef"></a>).
- At most one DNT header field can be present in a valid
- request [[!RFC7230]].
- </p>
+ </pre>
+ <p>
+ For example, additional characters might indicate modifiers to the
+ main preference expressed by the first digit, such that the main
+ preference will be understood if the recipient does not understand
+ the extension. Hence, a field-value of "1xyz" can be thought of
+ as <q>do not track, but if you understand the refinements defined by
+ x, y, or z, then adjust my preferences according to those
+ refinements.</q>
+ </p>
+ <p>
+ User agents that do not implement DNT extensions MUST NOT send
+ DNT-extension characters in the DNT field-value.
+ Servers that do not implement DNT extensions SHOULD ignore anything
+ beyond the first character.
+ </p>
+ <p class="note">
+ The DNT-extension feature is considered <em>at-risk</em>.
+ Since no extensions have been defined, implementors that don't
+ read specifications are likely to assume that DNT only has the
+ fixed values of "0" or "1". Furthermore, the potential benefits
+ of this mechanism are unclear given that extension information
+ could be supplied using separate request header fields.
+ </p>
+ </section>
</section>
<section id='js-dom'>
@@ -512,15 +529,10 @@
<code>window</code>, in the browser context of the current
<strong>top-level origin</strong>.
The value is <code>null</code> if no DNT header field would be
- sent (e.g., because a tracking preference is <a>not enabled</a>).
- </dd>
- </dl>
- <p class="note">
- Note that the value includes not only the "0" or "1", but also
- any DNT-extension; if no DNT header is sent, the return value is
- <code>null</code>, not an empty string (which would indicate that
- a header is sent with no <a>DNT-field-value</a>).
- </p>
+ sent (e.g., because a tracking preference is <a>not enabled</a>);
+ otherwise, the value is a string beginning with "0" or "1",
+ possibly followed by DNT-extension characters.</dd>
+ </dl>
</section>
<section id='other-protocols'>
Received on Tuesday, 3 February 2015 00:40:32 UTC