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

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 12:08:36 UTC