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

Sorry, I clearly need to more carefully read the bits of messages that
look like quoted context.

I misunderstood the change to the spec you proposed in the response to CfO.
The part that I did see and agree with is

>> 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.

That's all fine.

>> 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.

That is not fine.  The new (second) sentence is a normative requirement that
isn't targeted to an implementation (meaning no one can adhere to it).
It contradicts the existing protocol at CR, which doesn't limit how extensions
are defined, and I can't think of any justification for such a change.

What your proposal calls for is a statement that certain extensions can
and should be defined by compliance documents and recipients should look
to the compliance array for those definitions and requirements.
It doesn't need a requirement that all extensions be made through compliance,
even if I could figure out how to word that as a protocol requirement.
Really, that would be a requirement on future working groups, which is
generally a bad idea.

Your text also mentioned policy instead of compliance and added a note
inside a normative paragraph. And that note talks about emerging EU regulations
as if the readers are stuck in time.  Why don't we just use the section to
explain how we expect the protocol to be extended?  It serves
the same purpose without obsoleting the document in a few months.

BTW, we will also need to change the last sentence in the section defining
the compliance property, since that isn't consistent (or at least it can be
misinterpreted as disallowing protocol extensions).

My other comments were directed to Aleecia's example that Mike committed to
the definition of policy.  An example belongs in the section of use cases and
needs to be neutral (not talking about EFF and certainly not presupposing
the nature if EU legislation that hasn't even been written yet).
That's what I meant about speculating about legislation and third-parties;
it's not something I can publish.

I am sorry for the grumpy response.  I was not expecting to start my day
with a bunch of merge conflicts in git (due to a name-changing global
replace that I worked on yesterday, not anyone else's fault).

Having the text you committed in the ED is fine, right now, since having
the history in version control is always a good thing.  However, I will
be changing it soon to be suitable for publication.  If I somehow fail to
capture the intended WG consensus, then you can revert to a state that
you think was consensus and we can have a CfO on whether to publish that
other thing as a CR.

....Roy



> On Jun 27, 2017, at 11:20 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
> 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 Wednesday, 28 June 2017 06:12:29 UTC