Re: Towards CR - Feedback / requirements from W3C

> On Sep 11, 2017, at 14:23 , Roy T. Fielding <fielding@gbiv.com> wrote:
> 
>> 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 think we have a difference of understanding: it’s to warn people that if they DON’T implement these features, they may get removed, i.e. if we can’t prove that they can be and are interoperably implemented.  E.g. from the backgrounder to the process

"In the Call for Implementations, the Working Group may identify specific features of the technical report as being "features at risk." General statements such as "We plan to remove any unimplemented feature" are not acceptable; the Working Group must precisely identify any features at risk. “


> In contrast, I think the document would require another significant
> rewrite if we removed the API.  

I don’t see the spec. as tenable without the API, myself.

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

As noted above, we are required to point out features at risk of removal because of lack of implementation (and tested interoperability, and we also have no test suite, ahem).

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 11 September 2017 21:32:02 UTC