W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: <keygen> element

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 5 Sep 2009 20:26:01 -0700
Message-ID: <63df84f0909052026g42d2776fk6ae3134bffcc01@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Anne van Kesteren <annevk@opera.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, HTML WG <public-html@w3.org>
On Sat, Sep 5, 2009 at 6:28 PM, Ian Hickson<ian@hixie.ch> wrote:
> On Sat, 5 Sep 2009, Maciej Stachowiak wrote:
>> On Sep 5, 2009, at 1:45 PM, Maciej Stachowiak wrote:
>> >
>> > So far, no one but Ian has come out against the separate spec option,
>> > and at least some people strongly prefer it to the status quo.
>>
>> I reviewed the email on this and it looks like I overstated Ian's
>> position. What he said was: ""It's part of the HTML language at this
>> point, whether we like it or not -- and it seems sensible to me to
>> define the HTML language in the HTML spec."[1] That sounds to me like a
>> preference to keep <keygen> in the main spec, rather than a strong
>> position against splitting it out.
>
> Putting part of HTML in a different spec than the rest of HTML would be
> a political decision, not a technical decision. I object to making spec
> design decisions on political grounds.
>
> Prevously, we have only split sections out where doing so has made logical
> sense, e.g. because said features are self-contained, or are orthogonal,
> or are language-agnostic.
>
> <keygen> is none of these things. It integrates tightly with the form
> submission model, it affects the DOM APIs of other elements, it affects
> the parser, it affects the form control validity model -- it's not a
> feature that can be sensibly considered "optional" if our goal is cross-
> browser interoperability.
>
> However, there is an alternative that I think would still satisfy
> Microsoft's desires to not implement <keygen>'s cryptographic features
> while still bringing interoperability to the platform in every other
> respect: we could make the support of each individual signature algorithm
> optional. In fact, if we have a volunteer editor to do this, we could even
> make this externally extensible such that HTML5 doesn't list any signature
> algorithms but another spec defines the integration with RSA.

Putting just the <keygen> element, but none of the actual
functionality, thus allowing microsoft (or anyone else) to just
implement a very small amount of stubbed code seems like a political
solution. It wouldn't actually help any website authors, and it would
force UAs to still implement (and test) the stubbed code.

Is there a reason we couldn't mark <keygen> conforming but
obsolete/deprecated? All UAs seem to want to deprecate and replace
(thus remove) the feature. Saying that it's obsolete and/or deprecated
would seem to reflect that fairly well.

/ Jonas
Received on Sunday, 6 September 2009 03:27:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:48 GMT