Re: <keygen> element

Pardon if I am stating the obvious, but it seems like you and Anne  
agree that putting <keygen> in a separate spec (which is not  
normatively required by HTML5) would be an acceptable course of  
action. Another possibility is to leave it in the main spec but make  
all of the implementation conformance requirements optional  
(implementations MAY support it, and if so they MUST do it like so...).

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.

One more comment below:

On Sep 5, 2009, at 9:33 AM, Sam Ruby wrote:

> Anne van Kesteren wrote:
>> I'm assuming by "issue" you mean the objection raised to <keygen>  
>> by Microsoft.
>> On Sat, 05 Sep 2009 14:22:25 +0200, Sam Ruby  
>> <rubys@intertwingly.net> wrote:
>>> Renaming the element to follow HTML5's advice would address this  
>>> issue.
>> This would not address the issue unless you mean to also remove the  
>> element from HTML5. However it is pretty clear that browsers cannot  
>> rename the element so I'm not sure why this is being suggested.
>>> Marking it as proprietary or obsolete (bug 7480) would address  
>>> this issue.
>> Even obsolete elements still need to be supported by browsers so  
>> this is not a solution to the issue for Microsoft.
>
> OK, but proprietary would.  And coming up with a better term than  
> proprietary would be even better.
>
>>> Defining it in a separate document (bug 7499) would address this  
>>> issue.
>> Agreed.
>
> Cool: there is hope for consensus yet.
>
>>> Coming up with something better that everyone would be willing to  
>>> adopt (any ideas?) would address this issue.
>> I don't see how this would address the issue unless we somehow also  
>> convince all the sites that use <keygen> to no longer use it and  
>> convince the browsers that implement <keygen> to remove support for  
>> it.
>
> That's exactly the idea.  Maciej doesn't seem to be willing to rule  
> that out as a possibility:
>
> http://lists.w3.org/Archives/Public/public-html/2009Sep/0283.html

To clarify, I don't think this can happen by HTML5 Last Call. It might  
happen by the time we exit CR if development of a replacement standard  
started soon. I would strongly encourage Microsoft and Mozilla to  
document their browser-specific crypto APIs and get the ball rolling  
on a standard in the Web API Working Group or some other appropriate  
forum. (WebKit-based browsers do not currently support any extended  
crypto APIs; I am not sure about Opera.)

>
>>> I don't believe that we will find consensus on retaining keygen as  
>>> currently specified in the HTML5 draft.
>> I'm still hopeful and am not convinced this needs to be addressed  
>> before Last Call.
>
> I firmly believe that we will not find consensus on retaining keygen  
> as currently specified in the HTML5 draft, and firmly believe that  
> this needs to be addressed before Last Call.
>
>>> What issue do you, Anne, have with putting this element in a  
>>> separate document and clearly indicating that it is an optional  
>>> feature that a number of browser vendors have implemented, and new  
>>> user agents should consider should they happen to have similar  
>>> requirements?
>> I don't necessarily have an issue with putting this into a separate  
>> document. I'm not sure about all the other clauses you attach to  
>> that though.
>
> I don't believe that there is consensus that keygen as currently  
> described can be a required feature.
>
> - Sam Ruby
>

Received on Saturday, 5 September 2009 17:45:44 UTC