Changing my vote, to "Whatever!" realising i can't put a coherant "Technical" argument behind my vote, mine just came from the desire to quickly and concisely convey what version/revision/wording of the workflow/spec etc we'd be supporting.
Just leave it as is at 1.0 +1 i don't want new clients to be broken against old servers. in summary 3. -1 1. +1 O 2009/5/2 Mike Malone <[email protected]> > FWIW, if we're still tallying votes, I vote for option 1. > > > On Fri, May 1, 2009 at 2:34 PM, Eran Hammer-Lahav <[email protected]>wrote: > >> >> That was not what I did. I was just explaining how this process works and >> I clearly stated the need (and the full historical record) of getting to >> decisions by consensus. This is for cases where everything else has failed. >> We never had such a case so far and I doubt this will be one of them. If I >> thought me or anyone else had more weight here I would not be spending my >> entire day trying to convince people I'm right and engaging them. >> >> However, since this is a security issue with deployed software, if we >> cannot reach a consensus, someone will have to make a decision. My bet is we >> will not need it but if we do, that "someone" will be heavily weighted on >> the side of those with running code at risk... But let's go back to the >> discussion. I think we are making progress in communicating our positions. >> >> Let me repeat that: we make decisions by consensus, not votes. This is the >> IETF process as well. >> >> EHL >> >> > -----Original Message----- >> > From: [email protected] [mailto:[email protected]] On Behalf >> > Of Krishna Sankar (ksankar) >> > Sent: Friday, May 01, 2009 2:24 PM >> > To: [email protected] >> > Subject: [oauth] Re: Version Preference >> > >> > >> > Eran, >> > While you might be technically right, wielding the meritocracy >> > badge forcefully is not the right thing to do, imho. >> > >> > While the folks who have contributed to the specs, obviously, >> > have the knowledge and so their voices have more force per se (and >> > should be respected - no doubt), the community that uses the spec has >> > a >> > voice too. And one doesn't have to be a permanent contributor to be >> > heard and considered. There is a reason for this, if you care to think >> > ... am leaving out philosophy, for now ... >> > >> > Also as we move to IETF, this will be more clear - I see that >> > there are couple of e-mail on this, already in the IETF list, alluding >> > to this fact. Even there, for now, it is OK, as the spec is not with >> > IETF yet. >> > Cheers >> > <k/> >> > >> > |-----Original Message----- >> > |From: [email protected] [mailto:[email protected]] On Behalf >> > |Of Eran Hammer-Lahav >> > |Sent: Friday, May 01, 2009 2:07 PM >> > |To: [email protected] >> > |Subject: [oauth] Re: Version Preference >> > | >> > | >> > |On voting: this is not a democracy. Specs written by committee are >> > |almost always a piece of shit. Our process is to build consensus as >> > much >> > |as possible, trying to get people to agree and when we don't try to >> > |focus the conversation using actual technical arguments. At the end, >> > if >> > |there isn't a clear consensus, at least in this community, meritocracy >> > |wins. This means that people who have contributed more and have >> > "earned" >> > |their seat at the table get to lead the way. But this is an extreme >> > case >> > |and I don't think we ever had to use it. >> > | >> > |The vote is just to get a sense where people are. It is not a way to >> > |make decisions. At some point, Blaine or someone else will try to >> > figure >> > |out where people are, and write a short consensus proposal. Then we >> > will >> > |go through this again and see where we are. This sounds complicated >> > but >> > |it works pretty well. There are no hard rules for building consensus, >> > |but we have been successful accomplishing it. >> > | >> > |--- >> > | >> > |As for your argument, I agree with you on the version of the >> > |specification. I don't agree with you on the wire version. I don't >> > think >> > |they are the same at all. >> > | >> > |EHL >> > | >> > | >> > | >> > |> -----Original Message----- >> > |> From: [email protected] [mailto:[email protected]] On >> > Behalf >> > |> Of Matt Sanford >> > |> Sent: Friday, May 01, 2009 1:57 PM >> > |> To: [email protected] >> > |> Subject: [oauth] Re: Version Preference >> > |> >> > |> >> > |> Well ... >> > |> >> > |> The argument from me was that there is a material change and >> > that >> > |> is the place of minor revisions. If this is an optional extension to >> > |> the existing protocol we should not change the revision at all. If >> > it >> > |> is a minor change that requires a change to the base protocol rather >> > |> than an extension document, I call that a revision. This seem >> > logical >> > |> enough to me but apparently I am in the minority, 1.0a it is then. >> > |> As far as voting and discussion ... I was under the impression >> > |that >> > |> the 'Open' moniker sort of encouraged this. Must have been my >> > |> confusion, I missed the early on discussions. I'll read back in the >> > |> group some for more history. >> > |> >> > |> - Matt >> > |> >> > |> On May 1, 2009, at 1:44 PM, Jonathan Sergent wrote: >> > |> >> > |> > Let me additionally say that this discussion is dangerous and >> > voting >> > |> > is no way to design a protocol. What are the arguments in favor >> > of >> > |> > changing the version number, and what are the arguments against >> > |> > changing it? I haven't personally seen any arguments in favor of >> > |> > changing it that explained the rationale other than "of course you >> > |> > should change it because you changed the version number on the >> > |spec". >> > |> > >> > |> > > >> > |> >> > |> >> > |> >> > | >> > | >> > >> > >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
