Re: Goals and Procedures

> On Feb 7, 2017, at 10:44 , Roy T. Fielding <fielding@gbiv.com> wrote:
> 
>> On Feb 7, 2017, at 12:35 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
>> 
>> Hi Folks,
>> 
>> 
>> thanks a lot for the productive discussion during yesterday's call.
>> It is nice to actually start closing issues and progress towards our
>> goal of a stable final draft.
> 
> Issues are usually closed after the work has been published. Can you
> just tag them as something like wg-consensus or editor-ready?
> Also, I don't see any minutes posted for the last two meetings.
> I don't think that is optional.
> 
> I should be able to get to edit the draft next week, if David doesn't
> beat me to it.

I won’t :-(.  I am snowed at the moment.

> 
>> What I realized (since time is short) is that we should constrain
>> ourselves on a minimal spec that is good enough.
>> 
>> What this means:
>> - We should focus on helping EU compliance
>> - We should improve implementability
>> - We should try to abstain from fundamental redesigns and
>> substantial new features.
>> 
>> What does this mean for the group?
>> 
>> I suggest we focus only on substantial concerns backed by evidence. This
>> means that we should focus on issues that:
>> - Substantially simplify or improve implementation.
>> Evidence could be implementation experiences/reports.
>> (e.g. Mike stating that it is useful for a site to receive a call-back
>>       is in this category).
>> - Substantially help EU enterprises to manage opt-in for compliance
>> Evidence could be enterprise/site feedback or regulator requirements.
>> (e.g. Rob saying that the Javascript exception API is
>>  essential for managing opt-in and should be kept is in
>>  this category).
>> - Are required by W3C to reach recommendation state
>> 
>> As indicated, the goal is to deliver  a "good enough" TPE in time and
>> ideally simple enough to be widely implemented. Ideally, I would hope
>> that no other changes are required at this point.
>> 
>> Does everyone agree with this procedure? Any feeback or objections?
> 

While I agree in general —  focus, minimal change — I also share Roy’s concerns.

I don’t think we’ll have any choice but to mark the exceptions API as ‘at risk’ due to lack of interoperable use/deployment. On the other hand, I think it’s fine to ‘sit in CR’ for a while and wait.  A CR is a stable spec., it just isn’t final, not much different from RFC at the IETF.

I therefore suggest again:
* make the minimal changes (e.g. promises)
* mark ‘at risk'
* most important: catalyze the conversation between client-side and server-side potential implementers.

At the moment, both server and client-side are unwilling to invest/support the exceptions API unless/until the other side does.  We have to break that ‘after you, Alfonse’.

We should do a check on the rest of the spec.  How implemented are:
* sending the header? (OK, we know, several browsers)
* the WKR (I assume a crawler could answer that)
* variant WKRs?
* response header
* exceptions API: site-specific, web-wide

In fact, it’s way overdue to talk about a feature-coverage list and test suite.  If someone implemented the API, would we have a test suite?

> I don't agree.  Implementation of a consent framework requires near-universal
> deployment (sufficient to cover users that actually want to provide consent
> while using the browser of their choice).  A plugin isn't even capable of
> approaching that level of deployment.  We would be misleading the Web
> community if we claimed that a specification is ready for Recommendation
> when it depends on an API that nobody has deployed in shipping browsers.
> 
> We have three choices here:
> 
>   1) We keep the API and let the spec stay at WD/CR until there is sufficient
>      deployment usage to justify recommending it as a standard;
> 
>   2) We remove the parts that haven't been deployed and define workable
>      solutions using existing deployments; or,
> 
>   3) We change the spec to a Note and close the WG.
> 
> I think industry has already moved on to (2), since the first option is
> outside their control and isn't going to happen before the GDPR deadline.
> 
> I don't know what exactly Rob said about the consensus mechanisms, but
> the current API certainly isn't essential for managing opt-in.  In fact,
> opt-in has to be managed by the server because only the server is
> compelled by regulation.  Even if a DNT:0 is received, the server
> will need to remember what has been consented (it must be specific),
> so DNT:0 would have to be combined with cookies indicating to what
> and when the user agreed.
> 
> My preference would be to make a few tweaks to the API and then do
> a survey of the browsers.  Unless at least three of the currently
> shipping browsers have implemented the API within six months, we
> should remove it from the spec entirely and start a new CR (or just
> give up and republish as a Note).
> 
> If anyone wants to work on deployable alternatives, they are welcome
> to do so as proposals outside of the WG specification.  The chairs can
> decide when (or if) those proposals are worth discussing.  They might be
> usable without being part of a standard, or we might consider making
> them a standard after other options have been exhausted.
> 
> Cheers,
> 
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Senior Principal Scientist, Adobe   <https://www.adobe.com/>
> 
> 

Dave Singer

singer@mac.com

Received on Tuesday, 7 February 2017 23:27:48 UTC