RE: A modest proposal on extensibility

It's the extra layer of indirection that makes them completely different and actually solves the problem of being able to list extensions without modifying the base spec.  If they're equivalent to you and others, then you should have no problem with the Web page approach, and it would satisfy Microsoft's extensibility goals.  So let's do that!

    -- Mike

-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org] 
Sent: Sunday, October 12, 2014 10:03 AM
To: Mike Jones; Mark Watson; Richard Barnes
Cc: public-webcrypto@w3.org
Subject: 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 19:03:47 UTC