Re: Plan moving forward V02

Hi Brooks,

Thanks for the comment. I hope we did not create any logical breakdown 
(at least this was not our intent ;-). Let me try to clarify further.

With “independent” we meant that the TPE should be self-contained, i.e., 
free of dependencies on the compliance spec. Nevertheless, it is meant 
to be a solid foundation for this particular compliance document that we 
jointly envision to write once TPE has been pushed to final call.

Let me try an analogy: In my mind, the TPE is like a foundation for a 
house. While more than one potential house can be built on a given 
foundation, not all houses would fit (in fact, most houses will not). 
And furthermore, most people building a foundation have an idea for the 
complete house in mind when they start and people usually start with the 
foundation (not pieces of the upper floors floating in space).

I hope this clarifies things. If not, feel free to ask for further 
clarification.

Regards,

Matthias


On 04/11/2013 17:50, Dobbs, Brooks wrote:
> Matthias,
>
> I think there is a logical breakdown here.
>
> If, as you say, "the TPE not meant to be independent of the compliance 
> spec", then, in keeping with that sentiment, no definitions need to be 
> ported.  It is only where the TPE is to have independent meaning that 
> the definitions need to be ported.  Certainly one of the scenarios 
> under which it would need independent meaning would be as a 
> communications basis for other compliance protocols, but if this is 
> still up for debate, and the prevailing assumption is that the TPE 
> cannot be independent of the compliance doc, then anything you pull 
> from the compliance doc to the TPE would be arbitrary.
>
> If the TPE needs to be able to stand on its own, we agree that more 
> work needs to be done.  If the TPE and the Compliance Doc can only 
> exist as a package, then why would we move elements we had previously 
> determined to be compliance related into the TPE?
>
> -Brooks
> -- 
>
> *Brooks Dobbs, CIPP *| Chief Privacy Officer |*KBM Group* | Part of 
> the Wunderman Network
> (Tel) 678 580 2683 | (Mob) 678 492 1662 | *kbmg.com*
> _brooks.dobbs@kbmg.com
>
>
> _
> This email – including attachments – may contain confidential 
> information. If you are not the intended recipient,
>  do not copy, distribute or act on it. Instead, notify the sender 
> immediately and delete the message.
>
> From: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org 
> <mailto:mts-std@schunter.org>>
> Date: Monday, November 4, 2013 4:16 AM
> To: "public-tracking@w3.org <mailto:public-tracking@w3.org> 
> (public-tracking@w3.org <mailto:public-tracking@w3.org>)" 
> <public-tracking@w3.org <mailto:public-tracking@w3.org>>
> Subject: Plan moving forward V02
> Resent-From: <public-tracking-announce@w3.org 
> <mailto:public-tracking-announce@w3.org>>
> Resent-Date: Monday, November 4, 2013 4:17 AM
>
> Hi Team,
>
>
>
> Based on the feedback received, we have updated and clarified the plan 
> how to continue.
>
>
> Questions/feedback are welcome.
>
>
> Regards,
>
> matthias
>
> The Chairs and W3C have listened to your feedback, and based on the 
> poll results and the information we received during the October 16 and 
> 30 calls, we have revised the Plan to finalize the TWPG deliverables 
> as follows:
>
> The plan of record is option 3 of the poll: We will first bring TPE to 
> last call and then continue our compliance work.
>
> We have prioritized getting the TPE out fto last call first to enable 
> implementation and testing.  We will work through and close out all 
> remaining TPE issues in the coming weeks' calls.  We will also port 
> over from the Compliance specification all  definitions that are 
> important for defining the meaning of the TPE protocols (including but 
> not limited to parties, first parties, third parties, network 
> transaction, collect/retain/use/share, user, user agent, and a 
> definition of tracking (of what the signal is intended to indicate)). 
> The goal is to make the TPE specification self-contained such that the 
> TPE can be understood on its own and no dependencies on the compliance 
> spec remain. To minimize our work, if a definition is required for 
> both documents, we will define it in the TPE once and for both 
> documents. If there are other Compliance issues that the group 
> believes we need to close out because of dependencies or other 
> reasons, we may prioritize those as well.
>
> Once we have finalized the TPE specification. we will resume working 
> on a compliance specification.  We will then proceed to close out the 
> remaining issues against that document.  W3C believes that web users 
> need a unified compliance standard, so that there can be one 
> consistent expectation for how DNT signals will be treated.  However, 
> one of the open issues that we will consider for TPE is whether to 
> include a field that would allow a server to indicate an alternative 
> compliance regime.  We will resolve that issue based on the consensus 
> of the working group.
>
> Note that our plan is to finish TPE _/and/_ compliance.  We have 
> chosen option 3 and not option 4. I.e., the TPE is not meant to be 
> independent of the compliance spec. Instead,  the TPE is built to lay 
> the ground and later seamlessly integrate with the emerging compliance 
> spec.
>
> We will be seeking consensus and closing out issues under the timing 
> and structure previously described by the plan.
>
> Justin, Carl, and Matthias
>