Re: TPE Editorial Proposal to Remove Another Hard Dependency on the Compliance Specification

Hi Matthias,

Thank you very much for responding and giving my proposal consideration.  I
am eager to address your questions and have follow up conversations with
you and other members of our Working Group if I do not adequately answer
your questions or explain the proposed edit below.

To address your questions, I will place my text in with yours below within
a [JLH: ] designator.


On Tue, Mar 4, 2014 at 3:45 PM, Matthias Schunter (Intel Corporation) <
mts-std@schunter.org> wrote:

>  Hi Jack,
>
>
> thanks for the proposed change.
>
> ------
> Two general remarks/clarifications before we can discuss your proposal:
>
> (A) The TPE defines the term tracking and this term is used to define the
> DNT signal, i.e.,
> there is no permitted way to use the TPE protocol and then "redefine" the
> meaning of DNT;1.
> I.e., when a user agent sends "DNT;1", this signals that a user prefers
> not to be tracked and the meaning of this "not to be tracked" is defined as
> "not Tracking" where the term tracking is defined in the TPE.
>


>  [JLH: Matthias, respectfully, my proposal of adding another TSV value
> does not redefine the meaning of DNT:1.  Nor does adding a TSV 'R' value
> modify the definition of "tracking" within the TPE just as the addition
> of "?" and "!" as TSV values did not modify the definition of "tracking."
> The definition of "tracking" remains intact and unmodified.  Again, the
> definition of "tracking" and the meaning of the DNT signal are not affected
> by adding an 'R' value to the current values listed as valid TSVs.  As
> stated in the overview of the TPE for Communicating a Tracking Status
> (Section 5.1): "This protocol has the dual goals of expressing the user's
> preference regarding tracking and providing transparency by communicating
> machine-readable claims that a server might wish to make regarding its own
> tracking behavior."  The user's preference is separate and distinct from
> the server's response.  The values "?," "!," "T," "C," "D," "P," or "R"
> that can be placed in the TSV "tracking" field do not change the user's
> preference or the definition of "tracking" because the TSV values in a
> response from the server are solely based on a server's determination of
> its compliance with its adopted compliance regime.  The TPE as a technical
> protocol standard should provide the flexibility for the server to
> accurately communicate its compliance with its adopted compliance regime.
>  Adding a value of "R" to the set of available TSV response values does
> just that.]
>
> However, the compliance regime will specify how sites respond and also the
> meaning of these responses. On the sites expressing themselves, we did not
> put any constraints yet (besides some syntax framework). I.e., if a site
> has a conflicting definition of tracking, this does not change the meaning
> of the DNT;1 signal.
>
> [JLH: Respectfully, I agree that if a compliance regime has a conflicting
definition of tracking, it does not change the meaning of the DNT signal or
the definition of tracking in the TPE and I agree that the compliance
regime will specify how sites respond and also the meaning of those
responses.  That is exactly the flexibility that I am requesting through
the editorial addition of a TSV "R" value that refers the user to the
compliance regime being used by the server.  I am specifically asking for
an editorial change to the syntax in adding a TSV value of "R" to the set
of current TSV values.  Again, this editorial change does not affect the
TPE definition of "tracking" nor does it affect the meaning of the DNT
signal.]


> (B) If a site posts a link to a compliance regime at the well-known
> resource, then this indicates that a site follows this compliance regime
> and adheres to it.
>


>  [JLH: I agree and the "R" TSV value alerts the user to look to that
> link.  It [R]efers the user to that compliance link.]
> --------------
>
> Given this background, I did not understand the purpose of your proposed
> "R" flag.
>
> [JLH: The purpose of adding the "R" TSV value is to allow the server to
respond with a response that does not directly conflict with the compliance
regime designated in the URI in the "compliance" field.  The "R" alerts the
consumer to look at the designated compliance regime to determine how the
DNT signal will be treated by the server.]


> If the flag "R" indicates that the compliance practices are described in
> the compliance-URL, then the "R" flag is redundant since this is clear from
> the spec.
> As a consequence, I do not see a need for it. The mere presence of the URL
> signals that these are the practices that a site follows.
>

[JLH: The "R" TSV value is only redundant if the server adopts the W3C TCS
because the definition of "tracking" will be the same definition in both
the TPE and the TCS as the "tracking" definition plus other definitions in
the TPE were "ported" from the TCS into the TPE.   But in cases where the
server adopts a non-W3C compliance regime, the "R" value is not redundant
as it provides a signal to the user to refer to the compliance link for how
the server will treat the DNT signal.  This editorial change proposal is
within the spirit of Issue-136, removing dependencies on the TCS.  If the
server can only respond with a "T," which is tied to a definition from the
TCS, then the server is effectively forced to implement at least part of
the TCS and again, that may conflict with the non-W3C compliance regime in
place on the server.  An "R" value permits the TPE and TCS to be completely
uncoupled and provides the possibility for a sever to comply with both the
TPE and a non-W3C compliance regime.]

>
> Feel free to clarify in what technical scenario this flag is needed and
> how it would be processed by a user agent (and/or change its behavior).
>

[JLH: Referring to example 6 in the TPE, the use case with an "R" value
would look like this:

{
  "tracking": "R",
  "compliance": ["https://acme.example.org/tracking101"],
  "qualifiers": "afc",

. . .

        }

Please note that in this use case, the definition of "tracking" is not
changed nor is the meaning of the DNT signal."  The effect of the "R" value
is to only decouple the TCS from the TPE, which will allow for, in my
opinion, a wider adoption of the TPE.

Again, thank you for the opportunity to provide further explanation of my
editorial proposal.  Please let me know if you or the Working Group have
any follow-up questions or need further information.

Best regards,

Jack]


>
>
> Regards,
> matthias
>
>
>
>
> Am 27.02.2014 23:14, schrieb Jack L. Hobaugh Jr:
>
>  Dear Co-Chairs:
>
>  On December 8, 2013, Roy Fielding notified the TPWG that:
>
> Over the past three weeks I have made a number of changes to the TPE
> editors' draft in order to remove the hard dependency on the Compliance
> specification and note the currently pending WG decisions.
>
> . . . .
>
> This reflects a first pass on revising TPE toward the new plan.
> Most of the changes are simply editorial rephrasing to avoid an
> indication of compliance.  The non-editorial changes are summarized
> below. Note that these changes represent a set of proposals by the
> editor and are subject to the usual disclaimers regarding not yet
> being WG consensus.
>
>  . . . .
>
> 5.2.*
>     -- removed "1" and "3" tracking status values since they imply
>        compliance; they can still be sent as qualifiers.
>     -- added   "T" TSV (tracking) as replacement for 1/3
>     -- changed "!" TSV from non-compliant to under construction
>     -- changed "X" TSV (dynamic) to "?" to be more self-descriptive
>
> (Found at
> http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0044.html)
>
>  Mr. Fielding also introduced Issue-239 and the TPWG has reached
> consensus on that issue.  Issue-239 permits a server to provide a link to a
> compliance regime or policy.
>
>  I agree with Roy that the hard dependency on the Compliance
> specification should be removed from the TPE and that a server should have
> the ability to point to the compliance regime being followed by that server.
>
>  Towards that goal, I now propose adding the following TSV value in order
> to remove a hard dependency on the Compliance Specification:
>
>  -- "R" TSV (reference)
>
>  "R" (reference) notifies the user to refer to the "compliance" field to
> understand how a DNT:1 signal will be treated by the server.
>
>  For example:
>
>  {
>
>             "tracking": "R",
>
>             "compliance": ["
> https://www.companyX.com/NonW3CCompliancePolicy"]<https://www.companyx.com/NonW3CCompliancePolicy%E2%80%9D%5D>
> ,
>
>             . . .
>
> }
>
>
>  Again, the rationale for this proposal is remove a hard dependency on
> the Compliance specification.   Specifically, for those entities that adopt
> a non-W3C compliance regime that may have a conflicting definition of
> "tracking," this addition may allow those entities to also adopt the W3C
> TPE protocol specification.
>  Best regards,
>
>  Jack
>
>
> *Jack L. Hobaugh Jr *Network Advertising Initiative | Counsel & Senior
> Director of Technology
> 1620 Eye St. NW, Suite 210 Washington, DC 20006
> P: 202-347-5341 | jack@networkadvertising.org
>
>  The information contained in this e-mail is confidential and intended
> for the named recipient(s) only. However, it is not intended as legal
> advice nor should you consider it as such. You should contact a lawyer for
> any legal advice. If you are not an intended recipient of this email you
> must not copy, distribute or take any further action in reliance on it and
> you should delete it and notify the sender immediately.
>
>
>
>
>
>


-- 

*Jack L. Hobaugh Jr *Network Advertising Initiative | Counsel & Senior
Director of Technology
1620 Eye St. NW, Suite 210 Washington, DC 20006
P: 202-347-5341 | jack@networkadvertising.org

The information contained in this e-mail is confidential and intended for
the named recipient(s) only. However, it is not intended as legal advice
nor should you consider it as such. You should contact a lawyer for any
legal advice. If you are not an intended recipient of this email you must
not copy, distribute or take any further action in reliance on it and you
should delete it and notify the sender immediately.