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

Yes, my bad. I committed it to master so I could then get it into the gh-pages branch so people could read it. I maybe should have created another file, but was aware we didn't have much time.

Mike

-----Original Message-----
From: Aleecia M. McDonald [mailto:aleecia@aleecia.com] 
Sent: 28 June 2017 14:12
To: Roy T. Fielding <fielding@gbiv.com>
Cc: Matthias Schunter <mts-std@schunter.org>; public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
Subject: Re: CfO on Issue 22 - Strong objections to both options ;-(

Good morning Roy,

In very brief before fully awake -- much of this appears as GitHub comments I haven't read yet on text I didn't write. Let me try to pull apart what I worked on and address that. 

My goal is to make useable, readable examples. We know outsiders to our work are (a) not typical spec readers (e.g. lawyers not engineers) and (b) already misreading some of what's there in the spec. So I tried to give plausible and concrete examples to give new readers a prayer of understanding. I was not trying to promote DAA, EFF, or anyone else mentioned -- just working with what exists to make things as clear as possible. 

Having an example1 company and an exampleA policy is an unreadable mess. 

So, proposal: I change the company from "example" to "AcmeCo" and then change the policies to be more generic. I add a "see also" section that runs down the currently mentioned sources of policy (DAA, EFF) and law (CA, EU) because readers should know that's out there, and phrase it something like "at the time of this writing" with resource that may change. 

--> will that address your concerns with the examples?

Of note, I plan to leave the table. I think T not C (as I asked to confirm in prior email) with C for out-of-band consent and not for DNT:0, but really, the spec isn't as crisp on that. It would be great to illustrate the intent here. And to get it right!

I'll continue to post here rather than check in to GitHub. Yes, I have a GitHub account, but there are ReSpec oddities I'd rather not plumb. I do expect the checkin was a favor to me and to you, out of respect for your limited time, and I appreciate it. Thanks, Mike!

     Aleecia 

> On Jun 27, 2017, at 11:11 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
> 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 15:23:26 UTC