Re: A modest proposal on extensibility

This seems fine, except:
- we have discussed key format and agreed we do not want / need
extensibility for this
- no one has suggested we need an extensibility point for usages

I'd suggest that we include a table which lists all the WebCrypto
algorithms and for each one lists the specification(s) that define
that algorithm. The initial value for the existing algorithms will be
'This specification' but we will add values - through the errata
process - as we write extension specifications.

The definition of 'other specifications' will be revised to be
restricted to those specifications listed in the table.

The only remaining issue is whether we should arrange the procedures
for import / export of keys for algorithms parameterized by a hash
function such they it does not appear that import /  export for the
existing cases can be overridden, even though we constrain extensions
to definition of new hash algorithm values in prose.

...Mark

Sent from my iPhone

> On Oct 10, 2014, at 8:45 AM, Harry Halpin <hhalpin@w3.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>> On 10/10/2014 05:27 PM, Richard Barnes wrote:
>> Talking to a few folks off-list, it seems like the extensibility
>> discussion has gotten a bit muddled.  The goal of this message is
>> to try to focus/clarify with a specific proposal.   It sounds like
>> the general desiderata people have are: 1. To make it possible to
>> add new values for strings/enums without major spec surgery 2. To
>> make it easy for developers to find extensions
>>
>> To that end, I would like to propose a way forward for
>> extensibility:
>>
>> <proposed-plan>
>>
>> 1. Wherever a string/enum value is defined, insert something like
>> the following: 1.1. This specification defines values X, Y, Z 1.2.
>> Implementations MAY support other values 1.3. When an extension is
>> made to add a value, a reference should be added to the
>> "Extensions" section
>>
>> 2. Wherever a string/enum value is used as a branch point, insert
>> something like the following: 2.1. If X... If Y... If Z... 2.2. If
>> another recognized value, process according to that value 2.3. If
>> an unrecognized value, raise an NotSupportedError (or TypeError
>> for enums)
>>
>> 3. Add an "Extensions" section to the bottom of the spec, where
>> links can be added to point to extension specs.
>
> As noted on Bugzilla, as long as Extensions are in Errata, that's fine
> by W3C Process I believe.
>
>   cheers,
>        harry
>
>>
>> </proposed-plan>
>>
>> Does that overall approach seem agreeable to people?
>>
>> --Richard
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJUN/8KAAoJEPgwUoSfMzqcTlAQALObP2+Cwaka8+/S3abpQhuS
> rN1RWucStMZDoJOlKo+0PvEZTxzsmr71561m3ijb54p9heI7erU4wbeH50sF4LxD
> DZBXj8tLKTVgLfugbaSKiHpjR/Pyf2eWCOcfV+mbnSnSh+Q0w4Yf8BlrZi5oB3p6
> ce3L7HxxuOux2MXGvxxYep4PH8UK3S2L4WJXilCMskQYj9qrd6vXspcw3qvGwZbi
> V1QjvqHktm3JO9w9FKCRec516llD5WJ36Ltg4BkPixoNPV6MPThDW6j59skysmE0
> 4Wo0bGCgz2mcNou19C1FrdMZ6odX9aVZH0DHDD+/CzzMGw5jQcgmpUzOFVkzxcew
> SAT1QcIKpKzjryS/xS7YXC/Nzao8AxwFy+ucIF3N62f0SW2p4HJJwG7GxPvfBGEU
> S5ljf3xqbDnKPQ9+m5pHzN1LxaPe+zYiie+OQinC7l6tE0k+qewGAKIwXGkNV8hL
> 9ldLEtSDw7bJR7GrL/8aMdbiLquub08eFdaPlmrh24a8qmjqeOKn+5o2heWF4Oih
> F833shgvq+YPhJZrEbiw117GQTWEQRl3F6SGG9b5F6oU9idtsUmxAIMOIuqAQ81i
> ebjLPGRuSt9p6dY5qMJ4/VM1XWR2cIkc1dOmVurL74OezRT/XeJLJRQ+dts2vodk
> +mKQlPwShHMN85bsjqYf
> =E1rh
> -----END PGP SIGNATURE-----
>

Received on Friday, 10 October 2014 20:35:30 UTC