Re: Towards closing the remaining issues in the TPE specification

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