W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2017

Re: Process for "feature at risk" designation

From: Henrik Boström <hbos@google.com>
Date: Thu, 4 May 2017 09:37:15 +0200
Message-ID: <CAEbRw2yVm9NiJOA+FqqKVzGBYcE8949JKS=7P_0z3N6aTC9+DQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
I recently implemented getAlgorithm() but put that CL on hold when I hit a
minor problem and had other higher priority things to attend to. Adding a
new member to be serialized for IndexedDB broke loading certificates that
was stored before that member was introduced and I wasn't sure if it had to
be able to load that or not.

On Thu, May 4, 2017 at 7:10 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

>
> On 4 May 2017 at 14:52, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>
>> Feature at Risk 3: RTCCertificate.getAlgorithm()
>>
>>      Note: During the interim, EKR expressed surprise as to why this was
>> “at risk”.   Since there have been changes to the certificates returned by
>> getConfiguration().certificates (e.g. the pre-configured certificates
>> are no longer returned), perhaps we should be having a discussion about
>> whether getAlgorithm() is still needed.  Since it is no longer possible to
>> use getAlgorithm() to determine the algorithm used in a pre-configured
>> certificate, the only use left is to return the algorithm used to create a
>> certificate created by the application, which it could have stored for
>> later retrieval.
>>
>
>
> This reads more like "why does this feature exist?"  Which supports the
> notion that it might be at risk.
>
> I had planned to implement getAlgorithm(), but would obviously prefer to
> not have to implement anything.
>
Received on Thursday, 4 May 2017 07:57:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:50 UTC