W3C home > Mailing lists > Public > public-tracking@w3.org > October 2012

Towards closing the remaining issues in the TPE specification

From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
Date: Mon, 01 Oct 2012 18:23:43 +0200
Message-ID: <5069C38F.2050901@schunter.org>
To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Hi Folks,

I did a pass over the ISSUES that are still open (OPEN/PENDING REVIEW) 
within the TPE spec. Enclosed is my suggested way forward for each of 
them based on our WG discussions so far. Note that I did not include the 
discussions that are RAISED. We will discuss a subset of those and agree 
how to proceed with them.

Feedback is welcome. In particular if you do not agree with the proposed 
handling of these issues.

Regards,
matthias

--------------------------------8< ---------------------
ISSUE-111: Using DNT header to signal existance of exceptions
- currently not in spec
- Spec allows JS Api to query exceptions
- This allows sites to validate that their requirements are met
- This seems to be OK for the participants
- WAY FORWARD: Close issue unless objections are received

ISSUE-116: DOM API
- There is proposed text in the spec in Section 4.3
- This text seems undisputed
- WAY FORWARD: Close issue unless objections are received

ISSUE-112: Handling of sub-domains for site-specific exceptions
- Proposal 1: Explicit list no wildcards
- WAY FORWARD: Discuss in Amsterdam

ISSUE-137: Service provider flag
- We had discussions in two calls
- Current spec does not contain a service provider flag
- There seems to be no proposal without sustained objections
- Call for text proposals has been emailed
- WAY FORWARD:
    - If no alternative text is proposed, the issue will be closed
    - If alternative text is proposed, the chairs issue a call for 
objections

ISSUE-144: Constraints on user agents
- There is proposed text in the spec in Section 6:
- The current spec introduces a notion of exceptions that are stored
- The current spec mandates that sets of exceptions are treated as a 
unit, i.e., if exceptions for third parties {a,b,c} have been requested 
on a site,
    then {a,b,c } can only be removed as a whole
- Note: This means that a user can,e.g.,   no longer express a 
preference to allow {a,b} while disallowing {c}
- This text seems undisputed
- WAY FORWARD: Close issue unless objections are received

ISSUE-159: TPEs and mashups
- Concern has been raised
- No proposed solution yet
- WAY FORWARD: Postpone for now

ISSUE-160: API for querying exceptions
- The current spec contains a new querying API in section 6.6
- WAY FORWARD: Close issue unless objections are received

ISSUE-164: Under what conditions should same-party be mandatory
- Current spec declares the same-party attribute to be optional
- WAY FORWARD:
    - If no alternative text is proposed, the issue will be closed
    - If alternative text is proposed, the chairs issue a call for 
objections
Received on Monday, 1 October 2012 16:24:25 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:35 UTC