W3C home > Mailing lists > Public > public-tracking@w3.org > November 2012

Re: action-324, public compliance texts (issue-45)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 16 Nov 2012 01:06:28 -0800
Cc: "public-tracking@w3.org (public-tracking@w3.org) (public-tracking@w3.org)" <public-tracking@w3.org>
Message-Id: <B5AF8EC7-6D9D-4077-AAEE-9A35F5434DAF@gbiv.com>
To: Aleecia M. McDonald <aleecia@aleecia.com>
This is for my ACTION-337

I mentioned during the call that the second compliance text below
assumes that the response header is always an indication of compliance
and ignores the tracking status resource.  So, it needs to be
rephrased if it is to be a valid option.

On Oct 31, 2012, at 8:08 AM, Aleecia M. McDonald wrote:

> (2) 	http://lists.w3.org/Archives/Public/public-tracking/2012Feb/0001.html which is action-61 from Tom Lowenthal
> The response header is a clear commitment, which comes with all the
> associated regulatory consequences. When an organization sends the
> response header, they are making a specifically articulated promise
> about their conduct in response to this request from this user.
> With a required response header, nothing else is required to satisfy
> this issue.

I would rephrase it as:

  The protocol in [[!TRACKING-DNT]] includes various response
  mechanisms that enable an origin server to make a public commitment
  of compliance.

> (3) 	http://lists.w3.org/Archives/Public/public-tracking/2012Jan/0266.html which is action-62 from Jonathan Mayer (and possibly Shane)
> Operative text:
> A party MUST make a public commitment that it complies with this standard.
> Non-normative discussion:
> A "public commitment" may consist of a statement in a privacy policy, a response header, or any other reasonable means.  This standard does not require a specific form of "public commitment."  

I pointed out previously that the last sentence is false.
I suggest that it be removed from the option.

Also, I would like to suggest a fourth option:

  (4) Say nothing. I.e., Remove the section entirely because it
      serves no useful purpose and does not define a requirement
      necessary for interoperability or safety (see [1]).
      Silent servers do not comply.

      [1] http://tools.ietf.org/html/rfc2119#section-6

Received on Friday, 16 November 2012 09:06:55 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:00 UTC