Re: A modest proposal on extensibility - wrap up

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



On 10/15/2014 03:12 AM, Wendy Seltzer wrote:
> On 10/14/2014 09:09 PM, Wendy Seltzer wrote:
>> On 10/14/2014 08:32 PM, Mike Jones wrote:
>>> W3C experts – could you tell us practically what it takes to 
>>> update the errata page for a spec, both process wise and
>>> timeline wise? Does it require a working group action or is it
>>> just someone recording the contents of an e-mailed request on
>>> the web page?  Is there a review process or are proposed errata
>>> simply recorded as they come in?  I’d like to get some sense of
>>> how easy/hard this will be to do in practice and who will have
>>> the rights to update the page.
> 
>> Here's the W3C Process on errata:
> Correction: here's the new process link: 
> http://www.w3.org/2014/Process-20140801/#errata
> 
> 
>> The WG needs to propose changes to appear on errata pages, and
>> to approve them through the full process before new features
>> become normative, That process can go quickly (more quickly under
>> the recent process revision), if the group can get consensus and
>> review quickly. On the plus side, you have royalty-free patent
>> commitments on those normative extensions.

For 2005 process
(http://www.w3.org/2005/10/Process-20051014/tr.html#errata)

Traditionally (2005 process, not 2014 process - I *think* we're still
operating under 2005 process unless we were automagically upgraded)
re-going through the whole W3C process the detailed process on errata
*only* applies to features that effect conformance. The WG can chose
if they want to go through that process on a per feature basis. That's
pretty lightweight.

Now, on the other hand, for the 2014 process
(http://www.w3.org/2014/Process-20140801/#errata), in general we have
to restart process but it's more lightweight than returning to Last
Call. For non-substantive features the editor could just make the
change and we can recommence with PR. With substantive features, we'd
have to return to CR and redo test-suite with new feature. Whether new
optional algorithm extensions could as substantive or not probably
depends on the preference of the WG at the time of the suggestion.
They would definitely be substantial if they'd effect the presumed
normative browser profile:

"Editorial changes to a Recommendation require no technical review of
the proposed changes. A Working Group may request publication of a
Proposed Recommendation  or W3C may publish a Proposed Recommendation
to make this class of change without passing through earlier maturity
levels. Such publications are may be called a Proposed Edited
Recommendation."

For substantive features:

"To make corrections to a Recommendation that produce substantive
changes but do not add new features, a Working Group may request
publication of a Candidate Recommendation, without passing through
earlier maturity levels."

We can always have a wiki page regardless for proposed extensions the
Editors and WG has not had time to inspect yet.

   cheers,
      harry

> 
>> --Wendy
> 
>>> Responding to Mark’s comments, I could imagine someone
>>> inventing a new key format, so I’d think that KeyFormat should
>>> be a defined extension point. As much as I’m fond of JWK, it
>>> may not be the last key format ever.  I’m fine not having
>>> usages be an extension point.
> 
>>> -- Mike
> 
>>> From: Mark Watson [mailto:watsonm@netflix.com] Sent: Tuesday, 
>>> October 14, 2014 11:21 AM To: GALINDO Virginie Cc: Harry
>>> Halpin; Mike Jones; Richard Barnes; public-webcrypto@w3.org
>>> Subject: Re: A modest proposal on extensibility - wrap up
> 
>>> Virginie,
> 
>>> Just to re-iterate the two minor points I made in response to 
>>> Richard's proposal:
> 
>>> (1) I don't believe we have a need or desire for additional 
>>> values of the KeyFormat enum or the usages strings (2) The
>>> text change to handle the recognized values of other things,
>>> with extensibility, is a little more involved that Richard says
>>> - to deal for example with parameterized hash algorithms - but
>>> this should be ok.
> 
>>> I could do the editing for this tomorrow.
> 
>>> ...Mark
> 
>>> On Tue, Oct 14, 2014 at 8:20 AM, GALINDO Virginie 
>>> <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>>
>>>
>>>
>
>>> 
wrote: Hi all,
> 
>>> It looks like we are in a good direction to move forward on 
>>> extensibility/errata. Thanks Richard for making that proposal.
> 
>>> After discussing with Harry and Wendy, we came to the slightly 
>>> modified proposal. We were thinking about submitting it as
>>> part of the proposed resolution to close the extensibility
>>> bug.
> 
>>> ** process for extending W3C specification with new algorithms 
>>> **
> 
>>> 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 as errata to the specification 
>>> where links can be added to point to extension.
> 
>>> **
> 
>>> FYI, errata description in W3C can be found under 
>>> http://www.w3.org/Consortium/Process/errata
> 
>>> Hope this is agreeable to you. Virginie
> 
> 
> 
>>> -----Original Message----- From: Harry Halpin 
>>> [mailto:hhalpin@w3.org<mailto:hhalpin@w3.org>] Sent: lundi 13 
>>> octobre 2014 15:39 To: Mike Jones; Mark Watson; Richard Barnes 
>>> Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org> 
>>> Subject: Re: A modest proposal on extensibility
> 
> 
> 
>>> On 10/12/2014 09:02 PM, Mike Jones wrote:
>>>> 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!
> 
> 
>>> The list of extensibility algorithms is vetted by the W3C WG
>>> and in an official errata.
> 
>>> I'm also happy to have the W3C/WG maintain a web-page with 
>>> proposed extensions that have not yet made it to the official 
>>> errata. That is at least good house-keeping as a pointer to 
>>> proposals that have not gone through the WG.
> 
>>> I think either of these solves Boris' issue but I think Ryan
>>> and Richard prefer having the errata as official.
> 
>>> I think there is no huge difference in practice. Ryan's 
>>> argument, as I understand it, is that keeping any forward 
>>> references in an errata makes it easier for implementers to
>>> know what is really out there in terms of algorithms.
> 
>>> I would just like to close this while keeping extensibility
>>> for curves like Curve25519 that aren't in main spec.
> 
> 
>>>> -- Mike
> 
>>>> -----Original Message----- From: Harry Halpin 
>>>> [mailto:hhalpin@w3.org<mailto:hhalpin@w3.org>] Sent: Sunday, 
>>>> October 12, 2014 10:03 AM To: Mike Jones; Mark Watson;
>>>> Richard Barnes Cc: 
>>>> public-webcrypto@w3.org<mailto:public-webcrypto@w3.org> 
>>>> Subject: Re: A modest proposal on extensibility
> 
> 
> 
>>>> 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<mailto:watsonm@netflix.com>] 
>>>>> Sent: Friday, October 10, 2014 2:09 PM To: Richard Barnes
>>>>> Cc: Harry Halpin; 
>>>>> public-webcrypto@w3.org<mailto: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<mailto:rlb@ipv.sx>>> wrote:
>>>>> On Fri, Oct 10, 2014 at 4:34 PM, Mark Watson 
>>>>> <watsonm@netflix.com<mailto:watsonm@netflix.com><mailto: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><mailto: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
>>>>>> 
> 
> 
> 
>>> ________________________________ This message and any 
>>> attachments are intended solely for the addressees and may 
>>> contain confidential information. Any unauthorized use or 
>>> disclosure, either whole or partial, is prohibited. E-mails
>>> are susceptible to alteration. Our company shall not be liable
>>> for the message if altered, changed or falsified. If you are
>>> not the intended recipient of this message, please delete it
>>> and notify the sender. Although all reasonable efforts have
>>> been made to keep this transmission free from viruses, the
>>> sender will not be liable for damages caused by a transmitted
>>> virus.
> 
> 
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUPoNEAAoJEPgwUoSfMzqceI0QAKE4mP3R6rnLRmMFJRfN/Zls
5TqEyoD3Euio1y6U/XdixyQRUTpJNX8GcQFK39lPwFGn9rtemQsG9yX41dDRYadF
RncNG5I6Rhr+ZInoQovTHToeqyl5UPPrKQrG8mEyqxMy9HjNIkXVOVlROfDoi4ol
5r6icCpZikrBfw1Qh0pvj9HnbAfEQyf4qdaTBZLtlcaIZ4yiVv6FVgtJjhnvh3xs
qiwUJSMz2iyOsrgpXciwB8IQMJ4fPE62SlqQH2TSCGTuqocM7Rhpo0UKbEWLIOC8
RLfKNX8HGOxlUTT1gbDXyayg7WOlOj1MM+u2qOFLo4TmStCbxEOMWABsGIAxcb/H
XdzHnwqjCcPoaIcCRc4fwusOLOADqNvtnxyTlARtqjopDv8tffYmm9xT/gDECfqM
bkv5PljaAocSlBtIjQv86l7TCctimuJOAgbCERg+gN0bkOvN+mQi4Kyf1KOQWN4x
rt3OqhJzoYjpnszrhwiqrTLL/8cDpB/fetygLOXtK9uNG8bCLv3Q35gtLzG7Onhj
J7+rLviKqkSZYRMRF+UdjKI8BvjRAFfEr7vf+Aqf6nyh9Hh4U+C7Ke+L+0FIRwiu
8jU+goWszoFwGw6rZ37PYoPFAD0BwXlp3vc9i/LHznxTqFCsVQ5VyfcfhY5IcEqJ
1wWk3ApMhTvzpnlMKQQO
=xUwi
-----END PGP SIGNATURE-----

Received on Wednesday, 15 October 2014 14:23:16 UTC