I definitely prefer option 2) as it is safer IPR-wise (it is less likely to be tainted) and more in-line with other technical standardization organizations. Also, it is more democratic and market driven. <br><br>=nat<br><br>
<div class="gmail_quote">On Thu, Jan 22, 2009 at 1:23 AM, David Recordon <span dir="ltr"><<a href="mailto:david@sixapart.com">david@sixapart.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">Hey Nat et al,<div>I think this discussion is really fruitful and is identifying the issues that we have right now with the process. My point around naming conventions was less around if the spec title has "OpenID" in it or not at the start, but more around the bar to having "OpenID" in the title. Today, the proposal needs to be approved by the Specs Council and membership (with a vote designed specifically to pass to make it easy to get started) but once this happens the bar of it becoming finalized and continuing to be called "OpenID" is also very low. We're thus seeing the specs council try to raise this bar at the beginning which isn't working. This should instead be happening toward the end. This is further complicated by the amount of mandated review placed into the process making it take nearly a year to produce a new specification.</div>
<div><br></div><div>I see two ways to solve this:</div><div>1) Keep the current process for working groups but create a lighter weight pre-process for proposals that don't yet clearly fit within the scope of OpenID. This thus gives the specs council, community and membership a more tangible document to review during the working group process. (In many cases, the OpenID-OAuth hybrid spec did this just outside the pervue of the OIDF.)</div>
<div>2) Change the current process to make it easier to get started, make sure that working groups are referred to was incubating, drafting, etc, and then add some form of community based technology review towards the end of the process.</div>
<div><br></div><div>In either case, we should also address the amount of time currently allocated for various stages of review and clarify things such as if an implementors draft is or is not required.</div><div><br></div>
<div>I'm thinking that a gant chart might be a useful way to look at these process options so I'll try to put one together starting with our current process.</div><div><br></div><font color="#888888"><div>--David</div>
</font><div><div></div><div class="Wj3C7c"><div><br><div><div>On Jan 19, 2009, at 11:12 PM, Nat Sakimura wrote:</div><br><blockquote type="cite">There seems to be two topics here. <br><br>1. Naming convention for the WG and Draft specs. <br>
<br>One of the reasoning given by spec council for slowness for evaluation of the <br>WGs were the Trademark issue. Specifically: <br> <br>"there are nearly no hurdles toward the end of the process to make sure that a specification really is "OpenID". Instead, we're seeing the Specs Council place that hurdle at the beginning." (David Recordon)<br>
<br>This specific motion was made to address this concern of Specs Council. <br>It is upto the Specs council if either of the Chris's or Dick's proposal addresses this concern. <br> <br>My motion will definitely remove this concern, so I proposed it like that. <br>
<br>2. WG - Specs relationship<br><br>I believe, until now, WG - Specs relationship was one to one. <br>(Well, actually, there has been only one WG, which is PAPE). <br> <br>But consider something like Authentication spec. <br>
<br>As a WG, it might start off as Authentication 3.0 or something, <br>and in the end, it might want to decompose the spec into several part <br>such as: <br><br>* Discovery<br> * Assertion<br>* Authentication Protocol<br>
* Signature<br><br>(I am not suggesting that it should be like this, by the way.)<br><br>OR it could decide that it should afterall be just one spec. <br>(This monolithicness is actually one of the good quality of OpenID Specs, IMHO)<br>
<br>At the outset, the WG may not know which is the better approach. <br>Limiting WG to produce only one spec is likely to tend to give bias towards <br>monotlithic spec. <br><br>As you have noted, this is not quite as pressing as the other one, <br>
so I have not included in my motions. It probably needs more discussion, <br>and is not a OpenID Process issue, either, I believe. <br><br>=nat<br><br><br><div class="gmail_quote">On Tue, Jan 20, 2009 at 3:48 PM, Chris Messina <span dir="ltr"><<a href="mailto:chris.messina@gmail.com" target="_blank">chris.messina@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I would suppose that it would look more like:<br> <br> OpenID Discovery Extension DRAFT 1<br>
OpenID Discovery Extension DRAFT 2<br> OpenID Discovery Extension DRAFT etc<br> <br> If there were a precedent within the OIDF for needing multiple WGs on<br> the same spec, it might be worth considering, but I'm not sure that<br>
that's a problem we're going to have in the immediate future. I could<br> be wrong, but just doesn't seem like a pressing issue compared with<br> other matters.<br> <font color="#888888"><br> Chris<br> </font><div>
<div></div><div><br> On Mon, Jan 19, 2009 at 10:20 PM, Nat Sakimura <<a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>> wrote:<br> > So, for example, something like<br> ><br> > DRAFT OpenID Discovery Extension 1.0?<br>
><br> > I am fine with it, but what about other people?<br> ><br> > Also, I was wondering if WG and the spec is 1 to 1.<br> > In many standardization organizations, it is not 1 to 1,<br> > and sometimes the WG name and the spec it produces<br>
> is completely different. (e.g., SSTC and SAML).<br> ><br> > I have got an impression that at OpenID Foundation,<br> > it is 1 to 1 right now, but is it the right way of doing it?<br> > (It looks like it will hinder the modularization of the specs.)<br>
><br> > =nat<br> ><br> > --------------------------------------------------<br> > From: "Dick Hardt" <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>><br> > Sent: Tuesday, January 20, 2009 3:11 PM<br>
> To: <<a href="mailto:board@openid.net" target="_blank">board@openid.net</a>><br> > Subject: Re: [OpenID board] Smoothing the OpenID Process<br> ><br> >> I would suggest having the word DRAFT in all caps on specs that are<br>
>> not approved, but enable the OpenID name to be included so that it is<br> >> clear that it is intended to be an OpenID specification, as opposed to<br> >> belonging in some other community.<br> >><br>
>> -- Dick<br> >><br> >> On 19-Jan-09, at 7:30 PM, Chris Messina wrote:<br> >><br> >>> I support with Martin's sentiments here.<br> >>><br> >>> It seems like the simple approach is not giving a spec a version<br>
>>> number until it's finished. It's one thing if you want to call it<br> >>> Draft 1, Draft 2, etc... but an x.0 version should be reserved for<br> >>> final specs, as we did with OAuth before.<br>
>>><br> >>> Therefore, rather than it be "Resolution WG", it seems like the useful<br> >>> verbiage would be "Resolution Draft X". That is, a WG distinction<br> >>> seems not altogether productive if the desired outcome of such a body<br>
>>> is to produce specs...<br> >>><br> >>> I also would love to see /specs completely redone and would be willing<br> >>> to volunteer to help on that. It seems that it just hasn't been done<br>
>>> -- not that any one is necessarily at fault.<br> >>><br> >>> I also support putting such content under version control, again, as<br> >>> we did with the OAuth spec being hosted in Google Code.<br>
>>><br> >>> Chris<br> >>><br> >>> On Mon, Jan 19, 2009 at 6:39 PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>><br> >>> wrote:<br>
>>>><br> >>>> Thanks for your response.<br> >>>><br> >>>> I like your idea and I was always assuming it to be like that (wrt<br> >>>> the<br> >>>> "Draft") but<br>
>>>> some people apparently see it as inadequate and that was one of the<br> >>>> reason<br> >>>> for the blockage. Starting off as just being "Resolution WG" etc.<br> >>>> instead of<br>
>>>> "OpenID Resolution 1.0" seemed to be a necessary and reasonable<br> >>>> concession to me at the time of creating the motion.<br> >>>><br> >>>> It still is in a discussion period, so if anyone got an opinion<br>
>>>> around this,<br> >>>> please speak up.<br> >>>><br> >>>> Wrt the version control, I fully agree. I do not think sorting out<br> >>>> <a href="http://openid.net/specs/" target="_blank">http://openid.net/specs/</a> folder needs any Process document<br>
>>>> amendment so we<br> >>>> can proceed fairly quicly.<br> >>>><br> >>>> =nat<br> >>>><br> >>>> On Tue, Jan 20, 2009 at 11:25 AM, Martin Atkins <<a href="mailto:mart@degeneration.co.uk" target="_blank">mart@degeneration.co.uk</a><br>
>>>> ><br> >>>> wrote:<br> >>>>><br> >>>>> Nat Sakimura wrote:<br> >>>>>><br> >>>>>> /*BE IT RESOLVED that the members of OpenID Foundation board have<br>
>>>>>> agreed<br> >>>>>> to amend the OpenID process document to clarify that no draft may<br> >>>>>> claim<br> >>>>>> OpenID trademark until it is ratified to be an implementor's<br>
>>>>>> draft status or<br> >>>>>> full specification status. */<br> >>>>>><br> >>>>><br> >>>>> This is troublesome because generally OpenID specifications are<br>
>>>>> named<br> >>>>> simply "OpenID <What It Does>" (see: OpenID Simple Registration<br> >>>>> Extension,<br> >>>>> OpenID Attribute Exchange).<br>
>>>>><br> >>>>> Having to invent another name to use while drafting the<br> >>>>> specification<br> >>>>> seems like a needless waste of effort.<br> >>>>><br>
>>>>> Can it not simply be required that the drafts display prominent<br> >>>>> boilerplate text explaining that the specification is only a<br> >>>>> draft? It'd<br> >>>>> also be good to get a policy in place for the expiry of unapproved<br>
>>>>> drafts so<br> >>>>> that they go away after a period of time. For example, I would<br> >>>>> argue that we<br> >>>>> don't need eight historical draft versions of OpenID 2.0 on<br>
>>>>> <a href="http://openid.net/specs/" target="_blank">http://openid.net/specs/</a> ; having it under version control and<br> >>>>> tagging the<br> >>>>> published drafts ought to be sufficient.<br>
>>>>><br> >>>>><br> >>>>><br> >>>>><br> >>>>> _______________________________________________<br> >>>>> board mailing list<br> >>>>> <a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br>
>>>>> <a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br> >>>><br> >>>><br> >>>><br> >>>> --<br>
>>>> Nat Sakimura (=nat)<br> >>>> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br> >>>><br> >>>> _______________________________________________<br>
>>>> board mailing list<br> >>>> <a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br> >>>> <a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br>
>>>><br> >>>><br> >>><br> >>><br> >>><br> >>> --<br> >>> Chris Messina<br> >>> Citizen-Participant &<br> >>> Open Web Advocate-at-Large<br>
>>><br> >>> <a href="http://factoryjoe.com" target="_blank">factoryjoe.com</a> # <a href="http://diso-project.org" target="_blank">diso-project.org</a><br> >>> <a href="http://citizenagency.com" target="_blank">citizenagency.com</a> # <a href="http://vidoop.com" target="_blank">vidoop.com</a><br>
>>> This email is: [ ] bloggable [X] ask first [ ] private<br> >>> _______________________________________________<br> >>> board mailing list<br> >>> <a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br>
>>> <a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br> >><br> >> _______________________________________________<br> >> board mailing list<br>
>> <a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br> >> <a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br> >><br>
> _______________________________________________<br> > board mailing list<br> > <a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br> > <a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br>
><br> <br> <br> <br> </div></div>--<br> <div><div></div><div>Chris Messina<br> Citizen-Participant &<br> Open Web Advocate-at-Large<br> <br> <a href="http://factoryjoe.com" target="_blank">factoryjoe.com</a> # <a href="http://diso-project.org" target="_blank">diso-project.org</a><br>
<a href="http://citizenagency.com" target="_blank">citizenagency.com</a> # <a href="http://vidoop.com" target="_blank">vidoop.com</a><br> This email is: [ ] bloggable [X] ask first [ ] private<br> _______________________________________________<br>
board mailing list<br> <a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br> <a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br> </div>
</div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br> _______________________________________________<br>board mailing list<br>
<a href="mailto:board@openid.net" target="_blank">board@openid.net</a><br><a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br></blockquote></div><br></div></div>
</div></div><br>_______________________________________________<br>
board mailing list<br>
<a href="mailto:board@openid.net">board@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/board" target="_blank">http://openid.net/mailman/listinfo/board</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>