Re: Towards CR - Feedback / requirements from W3C

> On Sep 12, 2017, at 2:53 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> I agree with David that DNT without the API is useless, you might as well put the whole recommendation "at risk".  I also agree with Roy that is makes no sense to make the header extensibility  at risk because anything can be extended if the need for new features arises.

I think the alternative to marking features at-risk through lack of tested implementations (no test suite suite, few implementations) would be to say in the CR transition request that the whole spec. is at risk of being stuck in CR indefinitely.  My guess is that the WG agrees with Mike here, that it’s not worth removing features from the spec.

I’d be fine with this as well; I’m checking on whether this meets the process requirements (but Bert could check with the team).

> 
> If we have to point out a particular feature to be at risk I would go for the "cookie rules" facility in the API (where arbitrary subdomains can be identified in the "site" property. 
> 
> It was pointed out in the Last Call comments that this weakens the Same Origin Policy and goes against the grain of recent W3C standards work. It also leads to implementations being more compute heavy than they need to be, because, when deciding what DNT header to send in a particular request, tests have to be made against an indeterminate number of domain components, and the recognition of top-level domain components requires access to an externally curated lookup table. Anyway, the ability for nested  contexts (iframes) to specify exceptions for other domains makes the whole "cookie rules" apparatus redundant in my view.
> 
> Mike
> 
> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
> Sent: 12 September 2017 09:55
> To: Roy T. Fielding <fielding@gbiv.com>
> Cc: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
> Subject: Re: Towards CR - Feedback / requirements from W3C
> 
> Hi Roy,
> 
> thanks a lot for the feedback.
> 
> When discussing with W3C and David, I (belately) realized that an "all
> or nothing" approach (=no features at risk) limits our options and
> increases our risk of failure.
> 
> Since I do not see an advantage of "all or nothing", I suggested to mark
> those two features at risk.
> 
> I hope this works for you. If you see a substantial downside of marking
> these features at risk, please educate me (either you or anyone else).
> 
> 
> Regards,
> matthias
> 
> 
> On 11.09.2017 21:56, Roy T. Fielding wrote:
>>> On Sep 11, 2017, at 9:36 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
>>> 
>>> Dear TPWG,
>>> 
>>> thanks a lot for all then hard work you put into the CR proposal of the
>>> TPE.
>>> 
>>> As you know, a CR needs to satisfy certain criteria:
>>> - List of features at risk (if any)
>>> - Wide review
>>> - Implementation reports (test suite as a plus)
>>> 
>>> Despite the fact that most parts are unchanged, the feedback received is
>>> that we should preferably repeat these steps and re-compile this package
>>> for each subsequent CR release.
>>> 
>>> As a consequence, my suggested next steps are:
>>> 1 - We mark two features as at risk (changes to the CR draft):
>>>  - Extensibility of the DNT header (unchanged from first CR)
>>>  - Exception API (also to emphasize that we need more implementations)
>> 
>> Why?  We had that discussion on one of the calls and it was felt
>> that we did not have any pieces that would be removed prior to REC.
>> That is, either the document succeeds as a whole or it should stop
>> progression to REC.  The "at risk" category is only for stuff
>> that can be removed at REC without going back to the WG.
>> 
>> I could re-introduce the bits about DNT being extensible at risk,
>> but that seems to be a waste of time.
>> 
>>> 2 - Bert asks again for a wide review (PING, security, Art29,
>>> accessibility / internationalization, ...) within 2 weeks.
>>> Points to make:
>>>  - Exception API has been redesigned
>>>  - Otherwise, the spec largely unchanged
>>>  - It does not have any user interface (machine2machine)
>>> 
>>> 3 - We call for implementations and implementation reports (also within
>>> 2 weeks):
>>>  - Mike suggested he should be able to update his implementation
>>>  - For the signals, we can re-use existing reports.
>>>  - Other implementations of the API?
>>> 
>>> 4- If we receive no blocking feedback in these 2 weeks, we can then
>>> submit the full CR package around end of September.
>>> 
>>> If you agree, then no action is required ;-)
>> 
>> Well, someone has to send mail for (2) and update the wiki page for (3).
>> 
>> ....Roy
>> 
> 
> 
> 

Dave Singer

singer@mac.com

Received on Tuesday, 12 September 2017 19:15:08 UTC