- From: David Singer <singer@apple.com>
- Date: Wed, 03 Oct 2012 14:25:35 +0200
- To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>
- Cc: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
On Oct 1, 2012, at 18:23 , "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org> wrote: > 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 Yes, we could add a note that a site can check for the existence of an exception simply by asking for it again; the API is supposed to short-circuit and answer 'yes' if the exception already exists. If a site doesn't want to use this frequently, it can (for example) set a non-unique cookie "I checked within the last 24 hours" and not check again. > > 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 Yes. I don't even understand the question. Check with Nick, else close. > > ISSUE-112: Handling of sub-domains for site-specific exceptions > - Proposal 1: Explicit list no wildcards > - WAY FORWARD: Discuss in Amsterdam Yes, needs discussion. We can go to wildcards, but it gets us into public suffix issues, so we should only do that if we really need to. > > 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 Well, I thought that there was a service provider permitted use, and hence would be a qualifier. But there isn't?? > > 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 yes > > ISSUE-159: TPEs and mashups > - Concern has been raised > - No proposed solution yet > - WAY FORWARD: Postpone for now yes! > > 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 yes > > 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 needs some discussion David Singer Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 3 October 2012 12:26:13 UTC