Re: Towards CR - Feedback / requirements from W3C

> On Sep 11, 2017, at 1:14 PM, David Singer <singer@apple.com> wrote:
>> On Sep 11, 2017, at 12:56 , Roy T. Fielding <fielding@gbiv.com> 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.
>> 
> 
> I think it’s way easier to leave the at-risk marking in than to justify its removal, and it’s hard not to see a newly-redesigned API as at-risk. There may be one implementation, no test suite, and and so on.
> 
> I am prepared to argue at PR that the feature should nonetheless be retained, as I think removing it would take the chances of DNT adoption from small, down to minuscule.

I am not following.  The "at risk" category is specifically to warn
implementers that those features are at risk of being removed from
the final REC, even if they are implemented, and we would still call
it a REC without going back through the CR process again.  It serves
no other purpose.

I don't think removing the DNT field's extensibility provisions at REC
would matter to anyone, which is why we marked it "at risk" before,
but it also isn't worth our time to go back and do it again.
It's an extensibility feature, so lack of implementation doesn't matter.
What would matter is deployed implementations that are coded with the
assumption that DNT is only allowed to be 0 or 1.

In contrast, I think the document would require another significant
rewrite if we removed the API.  I don't think it could go to REC after
removal of that feature without some significant additions to replace
it (i.e., explaining some other mechanisms for managing consent and
removing the requirements added to the TSR sections).  So, we can't
call it "at risk" of removal from the spec, even if it is at risk of
never being implemented.

My answer to the W3T would be that there are no features considered
"at risk".  Having them is not a requirement.

....Roy

Received on Monday, 11 September 2017 21:24:09 UTC