Re: A modest proposal on extensibility

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 10/11/2014 06:40 PM, Mike Jones wrote:
> I’d been travelling internationally and so am just now getting to
> this.  The problem with Richard’s proposal is that updating the
> “Extensions” section he proposed would still require updating the
> specification for every extension – defeating the purpose.  A
> slight variant of it could work however.  If the “Extensions”
> section instead pointed to a Web page maintained by the W3C that
> was updated every time that an extension was defined, then only the
> Web page would have to be updated and not the base spec.  That
> would achieve the purpose of being able to create extensions
> without modifying the base spec *and* provide an actionable way for
> implementers to locate extensions.
> 

I see "references to extensions in errata" as just one layer of
indirection less than "link to web-page with references in errata".
Thus, they are functionally equivalent in my book, with the only point
that it's a bit harder to update errata (but hopefully W3C will make
this easier in the near-term future) but also easier for readers of
the spec to find the references.

> As for the other topic of extending key formats, I believe that we
> already know that this is necessary.  For instance, 25519 keys are
> expressed in a different format than NIST EC keys.  That alone is
> enough of an existence proof to demonstrate that we must enable key
> format extensions.
> 
> -- Mike
> 
> From: Mark Watson [mailto:watsonm@netflix.com] Sent: Friday,
> October 10, 2014 2:09 PM To: Richard Barnes Cc: Harry Halpin;
> public-webcrypto@w3.org Subject: Re: A modest proposal on
> extensibility
> 
> 
> 
> Sent from my iPhone
> 
> On Oct 10, 2014, at 1:55 PM, Richard Barnes
> <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote: On Fri, Oct 10, 2014 at 4:34
> PM, Mark Watson <watsonm@netflix.com<mailto: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
> 
> It's not quite as simple as that in the specification text as we
> want to defer to the extension specification exactly how the new
> hash function is signalled, including the possibility that it is
> parameterized. But still, we can do this.
> 
> ...Mark
> 
> 
> --Richard
> 
> 
> ...Mark
> 
> Sent from my iPhone
> 
>> On Oct 10, 2014, at 8:45 AM, Harry Halpin
>> <hhalpin@w3.org<mailto:hhalpin@w3.org>> wrote:
>> 
> 
> 
>>>> 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)

iQIcBAEBAgAGBQJUOrRXAAoJEPgwUoSfMzqc56wP/0OjVvRIeGuOeTXDtPEZB1PD
U55S7GSRTzqe34n0JW3bVh0l8cv6XcAIDaxkDotAuMAaiabtEyRRotL3oeoSzVMh
CX675EwPTJE+ZPszHzY2MZc/XlQfIZBgs47mWPdsbqsNEQt+ZEQQ5NM9BO2ogYG6
4Pvq3gbzTlINUZA3Wk78RT6h+1to/ZcVaRW/o7oLUeS2SdH0o0gK1Lwb97d4IBa3
aVu7FsDmqcvbuSJSGdU/3yvLx5J3uy4diWsA/OnDhyqHIq6f0Ln6sSjQynBhOz0H
sjGtdv3ItGuCbCPrVDl7WD0F43qqWaxiliDez5GsHmOxloeP4VJQywLQ5mxDhQfl
lePLvDR38PXF4owB2nmpAK9QJoLCJj3ufFVFj1mV7E5CO0wW1djks3iSvhmUEWFs
XcX15VqgKX+X2fzzNiYq+gsHoyIlHTd3pyqcT57em9tzLFa5IDWqaizMwchFHk/h
59R1+qFvSUW9iNRXdYOS+m4RX79J+2TEeyzAwweWs/uoU266moa7+9qUhrhGugIM
KikjKuKsZghPEDLzVktYp1GVozHV0bwpqCh/Lx4YOxympOEdM+3e/upFYAY4awOp
I52MObSyN2OdrVU4EkCwKb2TpjkrTSYXAyiokP25YvTn31W0heClKzX3VFf0xn6W
Ry7qQ4Kqm0eyNG+ONsKg
=4SiG
-----END PGP SIGNATURE-----

Received on Sunday, 12 October 2014 17:03:29 UTC