Re: Batch closing of TPE issues (Deadline: December 03)

Hi Matthias,

With all due respect, this is effectively less than a 2 week deadline because many of us will be attempting to take off the Thanksgiving week.  This is a fairly customary practice.

As for myself, I will also need a block of time to get up to speed on these issues as I was not a part of the TPWG during the initial discussions.

So combining this task with the concurrent call for objections process does create a burden.

Any extra time that the chairs could provide would be greatly appreciated.

Best regards,

Jack

Jack L. Hobaugh Jr
Network Advertising Initiative | Counsel & Senior Director of Technology 
1634 Eye St. NW, Suite 750 Washington, DC 20006
P: 202-347-5341 | jack@networkadvertising.org





On Nov 14, 2013, at 11:30 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:

> Hi Alan,
> 
> 
> thanks a lot for the note.
> 
> Note that we came to proposed text for each of these issues many months ago (i.e., everyone active on TPE had many months to check those issues) and most people active in the TPE have read and commented on those text already. The result is in the current TPE at:
> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
> 
> HINT: Often, the  issue resolution is marked in the document. If you, e.g., search for "ISSUE-137" in the TPE spec, you will find a box explaining how ISSUE-137 has been resolved. This may make your life easier to understand how the issues have been resolved.
> 
> To provide some further relief, I put the deadline for this task to almost 3 weeks.
> 
> 
> Regards,
> matthias
> 
> 
> On 14/11/2013 15:49, Alan Chapell wrote:
>> Hi Matthias -
>> 
>> Perhaps I'm the only one feeling the pinch, but from my side of the room,
>> the chairs are throwing a tremendous amount of work at the working group
>> for completion in a relatively short period of time. Given the
>> interdependencies that many of these issues have, we're bound to make
>> mistakes if we continue at this pace. Like you, most of us have day jobs.
>> 
>> With that in mind, I encourage you to ease up a bit (:
>> 
>> Thanks!
>> 
>> -alan
>> 
>> 
>> 
>> On 11/14/13 4:10 AM, "Matthias Schunter (Intel Corporation)"
>> <mts-std@schunter.org> wrote:
>> 
>>> Hi Folks,
>>> 
>>> 
>>> while we are working on the new issues, I suggest we close the set of
>>> TPE-related issues that have been PENDING REVIEW for many months. These
>>> document the outcome of our former discussions on TPE where we reached a
>>> conclusion that resulted in text. For each of those issues, the text
>>> resolving the issue is already included into the TPE spec (and has been
>>> there for a long time).
>>> 
>>> Please: Validate that you can live with the resolution of the enclosed
>>> issues (Deadline: December 03).
>>> 
>>> In case you want to object to closing an issue, please provide the
>>> required documentation (see "the plan"), i.e., roughly you should say
>>> why the issue cannot be closed, what concern you have that is not
>>> addressed, and what alternative text you proposed to mitigate your
>>> concern.
>>> 
>>> 
>>> Thanks a lot!
>>> 
>>> matthias
>>> 
>>> --------------8<------------------
>>> http://www.w3.org/2011/tracking-protection/track/issues/137
>>> ISSUE-137: Does hybrid tracking status need to distinguish between first
>>> party (1) and outsourcing service provider acting as a first party (s)
>>> 
>>> http://www.w3.org/2011/tracking-protection/track/issues/153
>>> ISSUE-153: What are the implications on software that changes requests
>>> but does not necessarily initiate them?
>>> 
>>> http://www.w3.org/2011/tracking-protection/track/issues/161
>>> ISSUE-161: Do we need a tracking status value for partial compliance?
>>> 
>>> http://www.w3.org/2011/tracking-protection/track/issues/164
>>> ISSUE-164: To what extent should the "same-party" attribute of tracking
>>> status resource be required
>>> 
>>> http://www.w3.org/2011/tracking-protection/track/issues/168
>>> ISSUE-168: What is the correct way for sub-services to signal that they
>>> are taking advantage of a transferred exception?
>>> 
>>> http://www.w3.org/2011/tracking-protection/track/issues/195
>>> ISSUE-195: Flows and signals for handling "potential" out of band consent
>>> 
>>> http://www.w3.org/2011/tracking-protection/track/issues/197
>>> ISSUE-197: How do we notify the user why a Disregard signal is received?
>>> 
>>> 
>> 
> 
>