Re: TPE status

Dear DNT Team,


thanks a lot to Roy for the substantial work in cleaning up TPE.

Following our plan (TPE first then compliance), the goal was to ensure 
that TPE is self-contained and can be read without 
references/dependencies on compliance. As discussed during our call, the 
goal of these edits (besides cleaner presentation) was to remove those 
dependencies. This allows us to progress TPE to final call and lays the 
ground for then working on compliance.

During next week's call, David Singer volunteered to walk us through the 
changes and we will also do some Q&A to make the rationale behind the 
changes clearer.

One new issue that came up during this excercise is ISSUE-239 
(http://www.w3.org/2011/tracking-protection/track/issues/239) that asks 
us to discuss how to link TPE and compliance (options include: implicit 
(as today), explicit (with one link to compliance), or explicit (with an 
array of multiple links claiming compliance with multiple rule-sets)). 
We will discuss this in the group soon.

Comments and feedback are welcome!


Regards,
matthias








Am 08.12.2013 09:46, schrieb Roy T. Fielding:
> Over the past three weeks I have made a number of changes to the TPE
> editors' draft in order to remove the hard dependency on the Compliance
> specification and note the currently pending WG decisions.
>
> It is probably best to review the complete draft in light of the
> new plan, since it has been a long time since the last review:
>
>   "http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html"
>
> I have also provided a side-by-side diff since the last WD:
>
>   "http://www.w3.org/2011/tracking-protection/drafts/diffs/TPE-WD5-to-20131207.html"
>
> This reflects a first pass on revising TPE toward the new plan.
> Most of the changes are simply editorial rephrasing to avoid an
> indication of compliance.  The non-editorial changes are summarized
> below. Note that these changes represent a set of proposals by the
> editor and are subject to the usual disclaimers regarding not yet
> being WG consensus.
>
> My next edit after this is likely to be a purely editorial
> rearrangement of sections (to move the Representation up a level
> and add subsections within it for easier referencing of the individual
> tracking status object's members).  I haven't done that yet
> because it will make a mess of the diffs.
>
> After that, we need to incorporate any WG decisions regarding the
> recent calls for objections, for which I have left issue markers
> in the document. This may lead to more editorial simplifications
> of the text, depending on how each of those definitional issues
> are resolved.  In any case, only the terms actually used within the
> document will be included as definitions within the specification.
>
> While we are editing, I hope that WG members read the specification
> carefully and send in comments to the public mailing list.  Though
> I am sure that we will spend telcon time on this, it is far easier
> for everyone (especially me) if folks have suggested changes in
> written form where they can be quickly processed as editorial or
> copied into a proper issue for tracking.
>
> Summary of non-editorial changes:
>
>    ISSUE-136 (resolve dependencies on compliance)
>      -- removed all reference to [TRACKING-COMPLIANCE] and paragraphs
>         that depend on its definitions.  When definitions are needed,
>         they will be copied into section 2.3.
>    
>    Updated [HTTP] references to current HTTP/1.1 specs in IETF LC.
>
>    5.2.*
>      -- removed "1" and "3" tracking status values since they imply
>         compliance; they can still be sent as qualifiers.
>      -- added   "T" TSV (tracking) as replacement for 1/3
>      -- changed "!" TSV from non-compliant to under construction
>      -- changed "X" TSV (dynamic) to "?" to be more self-descriptive
>
>    5.4.3
>      -- added "compliance" as an array of links to other resources
>         that presumably define requirements to which the origin server
>         claims to adhere, along with definition of the qualifier meanings
>      -- removed existing "permitted uses" qualifier values, since they
>         indicate compliance, but they can be defined elsewhere and still
>         communicated via the qualifiers member.
>      -- removed "third-party" member array because it is redundant and
>         less reliable than the set of NOT(same-origin OR same-party).
>
>    6.11
>      -- removed requirement that UGEs be cleared when cookies are cleared.
>
>
> Cheers,
>
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Senior Principal Scientist, Adobe   <https://www.adobe.com/>
>
>

Received on Sunday, 8 December 2013 10:36:22 UTC