Re: A modest proposal on extensibility

On Fri, Oct 10, 2014 at 4:34 PM, Mark Watson <watsonm@netflix.com> wrote:

> 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 agree that key formats are low priority for extension, but I'm a little
surprised that we would forego it entirely.  I guess it just means that
extending the set would need a spec update (to add extensibility), which
seems OK.


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

This seems fine to me.



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

That was what I was trying to get at with the proposed branch structure:
-- One of the hash functions defined in this spec...
-- Another one you recognize...
-- Error

--Richard



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