RE: Meaning of the term "optional" in the TPE spec

Hi Nick,

Thanks for getting back. The script does not need to signal the server with
XMLHttpRequest, it can drop a low entropy cookie ( i.e. Consent=yes) .  The
server could set the header then but the functionality would be split
between the server code and client script, and they may be from different
vendors/publishers.

Is there text in the draft about not needing to respond if the exception API
is called?

Thanks 

Mike

-----Original Message-----
From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: 14 September 2012 02:38
To: Mike O'Neill
Cc: mts-std@schunter.org; 'Roy T. Fielding'; public-tracking@w3.org
Subject: Re: Meaning of the term "optional" in the TPE spec

Hi Mike,

Thanks for the note, but I'm not sure I understand this case yet. If a site
uses client-side means to obtain consent (which, by the way, if it did with
the JS exceptions API it wouldn't require these response values anyway), the
script at some point will still initiate an HTTP request when it calls back
to the server with information -- I would think that HTTP response would be
an appropriate time to send a Tk:U header, and/or that subsequent responses
(which would also presumably have the user's consent) can include a Tk:C
header. Could there be a case where the server is retaining data related to
a request based on the user's consent but wouldn't know that it had consent
and would be unable to signal that to the user in its response?

Thanks,
Nick

On Sep 13, 2012, at 5:48 PM, Mike O'Neill <michael.oneill@baycloud.com>
wrote:

> There are existing use cases where it would be difficult or impossible 
> to dynamically insert a C status (or U status) in a TK response 
> header. There are many implementations in Europe where consent is 
> ascertained by client side script (perhaps acted on by deleting 
> cookies and/or localStorage when it is not given). Client side script 
> cannot change the response headers (and it may not be possible to 
> signal the server to do it). If you email me off-list I can point you 
> at some of them. Why not allow a JS API to indicate OOB consent?
> 
> 
> Mike
> 
> -----Original Message-----
> From: mts-std@schunter.org [mailto:mts-std@schunter.org]
> Sent: 13 September 2012 17:58
> To: Roy T. Fielding
> Cc: Matthias Schunter; public-tracking@w3.org
> Subject: Re: Meaning of the term "optional" in the TPE spec
> 
> Hi Roy,
> 
> thanks for the clarification. It shows that you are a standards 
> veteran and it is great to have you on board!
> 
> For the rest of us, we need to double-check that there are no 
> objections to the fact that optional fields are purely optional, i.e., 
> the only member of the well-known resource that all sites MUST declare is
the tracking status.
> 
> Sites can then freely choose whether they want to provide additional 
> transparency by adding information through the other fields:
>                same-party
>                third-party
>                audit
>                policy
>                *( vs extension )
> 
> Only for the "control" field, the spec mandates that a site SHOULD 
> populate it iff it uses out of band consent ("c").
> 
> Opinions?
> 
> 
> Regards,
> matthias
> 
> 
> However, the current spec does not mandate this additional transparency.
> 
>> On Sep 10, 2012, at 1:19 PM, Matthias Schunter wrote:
>> 
>>> another potential clarification that we discovered is that we as a 
>>> group need to validate that we agree when the TPE spec uses the term 
>>> OPTIONAL (defined by RFC2119 as fields/features that are completely 
>>> optional, i.e., servers and user agents can freely choose to 
>>> implement them or not).
>> 
>> The spec should already do that.  If a field is optional except under 
>> certain circumstances, then it should say that.  The fields that are 
>> purely optional do not have any dependent requirements yet.  If there 
>> is a mistake in the drafting, please note it as a bug.
>> 
>>> I believe that this is the right meaning for some of the fields in 
>>> the TPE spec. An example is the extensions to the DNT header or the 
>>> third-party field of the tracking status resource.
>>> 
>>> However, we need to double-check that all fields that are declared 
>>> OPTIONAL are never needed for any critical use case.
>>> If we are honest to ourselves, we should usually only claim that our 
>>> spec implements a use case iff this use case does not depend on such 
>>> optional fields.
>> 
>> Yes, nobody has claimed otherwise.
>> 
>>> fyi:  for the fields of the tracking status resource, I believe the 
>>> following to be true:
>>> - we agreed that the third-party fields is truly optional (sites can 
>>> freely choose whether they may or may not declare third-parties)
>>> - for the "same-party" field, this is less clear. Without this 
>>> field, user agents may be confused if multiple sites say "intended 
>>> for 1st party use" without declaring each other to be part of the same
party.
>> 
>> What do you mean by "it isn't clear"?  Right now, same-party is not 
>> required under any circumstances.  I think that's pretty clear.  The 
>> only reason it was proposed as optional is because it is an 
>> implementation burden on first party sites.
>> 
>> In order to make it required, somebody in the WG (which includes the 
>> draft authors) needs to propose that it be required. Since nobody has 
>> done that yet, AFAIK, it isn't required.
>> 
>> Are you making that proposal?  If so, please just do so and let the 
>> WG discuss.  If there are no objections, it goes in.  If there are 
>> objections, we make a call for consensus and the the chairs decide.
>> 
>>> Did we overlook spec language that contains these requirements? If 
>>> not, how would you clarify this issue?
>> 
>> I did not overlook it.  We simply haven't made it a requirement yet.
>> 
>>> Should we go through the fields one-by-one and discuss which fields 
>>> should not be completely optional?
>> 
>> I would hope that people are doing that while reviewing the document.
>> 
>> ....Roy

Received on Friday, 14 September 2012 02:06:53 UTC