Re: CfO on Issue 22 - Strong objections to both options ;-(

Hi,

Extensibility is already required and covered by the technical need to
anticipate change over time.  I can reiterate that where needed, but I am
not going to add a reference to emerging EU regulations.

To be clear, I am not going to add any reference to EU, California,
Canadian, Russian, or EFF policies because they will not stand up over
time and are not needed to understand the protocol.  That kind of thing
is what people can write blog posts about, under their own name, and
based on their own speculation of that day's interpretation of some
region or third-party's policies.  I am pretty sure that, even if I asked
for formal permission via internal legal and VP reviews, I would not be
allowed to publish such speculation about applicable laws/regulations.
That's not my expertise.

Likewise, I haven't included the relevant aspects of Adobe's privacy policy
as part of the standard. It should be a given that text is only introduced
to the draft when it has at least the potential for community consensus.

The examples I will include are neutral and hypothetical: they do not need
to reference real domains or specific regulations.

Protocol requirements are placed on protocol implementations, not on
existential concepts.  Normally, we would not make a protocol requirement
that extensions be defined in compliance, since there is no actionable
way for implementations to implement such a requirement other than by
forbidding extensions. Instead, we should state our expectation that
compliance documents are expected to define and sometimes require
extensions to the protocol, so implementations should expect additional
properties and look to the compliance array for further understanding.

....Roy

> On Jun 27, 2017, at 5:08 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
> 
> Hi Folks,
> 
> I added the text below to Section 6.5.10 (merging with existing text).
> The new section on extending the TSO now reads as follows:
> 
>  <section id='rep.extension'>
>        <h4>Extensions</h4>
>        <p> An origin server MAY send additional properties in the
> <a>status object</a> or define additional tracking status values to
> support future enhancements to this protocol.
>        <p> We require that extensions introduced SHOULD be defined and
> described by a document referenced by a URL in the compliance array
> property. A recipient MUST ignore extension properties that it does not
> recognize.
>        </p>
> 
>        <p class="note">
> One goal of this extensibility is to enable variations by policy and the
> evolution of best practices for the emerging EU regulations.
>  </p>
>      </section>
> 
> I guess the change will appear in the spec at
> https://w3c.github.io/dnt/drafts/tracking-dnt.html#rep.extension
> once Roy approves it.
> 
> Any feedback is welcome!
> 
> matthias
> 
> 
> 
> On 19.06.2017 18:07, Frank.Wagner@telekom.de wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
>> Gesendet: Sonntag, 18. Juni 2017 12:28
>> An: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
>> Betreff: CfO on Issue 22 - Strong objections to both options ;-(
>> 
>> Dear TPWG,
>> 
>> 
>> I now took some time to analize both sets of objections.
>> 
>> Both sides have strong objections:
>> - Not inserting additional information means that we may not satisfy the
>>  transparency requirements put forward by the EU  and thus puts us as
>>  risk of not reaching our chartered goal.
>> - Inserting the proposed text may also not be sufficient to reach this
>>  goal (there may be more fields and data required such as purpose)
>>  furthermore, the meaning of the field seems to be not 100% clear.
>> 
>> I now believe that it is premature to define the right field or set of fields.
>> 
>> I strongly believe that it is too early to identify the best set of fields at this point. I also realized that adding all the right fields would make this global standard fairly specific to the EU requirements (adding burden to other Geos).
>> 
>> As a consequence, I decided not to force the issue now and propose a
>> compromise:
>>  - We push out the standard as is
>>  - We make its extensibility more explicit to foster continued
>>   discussion of EU best practices (in the spec).
>>  - We start documenting those best practices as they evolve
>> 
>> This allows us to keep our timeline while permitting continued learning during implementation.
>> 
>> The change to the spec that I propose is:
>>> The tracking status object can be extended by adding additional informational properties or by defining additional tracking status values. We require that extensions introduced SHOULD be defined and documented by a policy document referenced by the URL in the policy property field.
>>> Note: One goal of this extensibility is to enable variations by policy and the evolution of best practices for the emerging EU regulations.
>> 
>> If we all agree on this consensus, then I will not resolve the CfO by forcing the issue and we can move ahead by introducing this change.
>> 
>> I am confident that all of you can live with this proposal in the spirit of jointly finding the solution with least objections.
>> 
>> If not, please object and substantiate your objection by June 24.
>> 
>> I am also open to any other feedback (including minor/editorial changes to the text I proposed).
>> 
>> 
>> Regards,
>> matthias
>> 
>> PS: Attached is the draft CfP analysis (without conclusion).
>> 
>

Received on Tuesday, 27 June 2017 18:20:50 UTC