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

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 00:48:39 UTC