Re: Process for "feature at risk" designation

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.
>