Me too! :-) EHL
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Phil Hunt > Sent: Monday, March 14, 2011 10:12 PM > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, deadline > Friday, March 18 > > As I indicated earlier, I don't agree yet with the choices and would like more > information on the registry and use cases. > > Phil > phil.h...@oracle.com > > > > > On 2011-03-14, at 6:29 PM, Eran Hammer-Lahav wrote: > > > It's a clear example of defining facilities without *ANY* use cases or > requirements. > > > > We have clear use cases and actual registration requests for the current > registries defined in v2. > > > > What's most annoying about this entire push for an error registry is that > > the > author and supporters have all failed to show a single example of an actual > value to be registered. I don't think I'm asking for much. > > > > Registries must be held to the same level of adoption as any other part of > the protocol. If a feature is not being use by the time the document is > finalized, it MUST NOT be included and left out. Otherwise, this is pure > astronaut architecture and design by committee. > > > > As for the reference to the editorial comment in draft 11 - there were > other such notes in part drafts which were simply removed without > addressing throughout the process. This registry is new, and is baseless. An > important part of our process is weeding out what is not necessary, and an > error registry clearly fails to meet this standard. > > > > This entire thread should be stopped until someone can offer clear use > cases and requirements. Otherwise, this is a joke. > > > > EHL > > > > > > > >> -----Original Message----- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >> Behalf Of David Recordon > >> Sent: Monday, March 14, 2011 6:04 PM > >> To: Mike Jones > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, > >> deadline Friday, March 18 > >> > >> Has anyone extended error codes? Is there a list of error codes > >> currently being used in the wild that need standardizing? > >> > >> --David > >> > >> > >> On Mon, Mar 14, 2011 at 11:28 PM, Mike Jones > >> <michael.jo...@microsoft.com> wrote: > >>> This is not new. This is meeting the need expressed in draft 10, > >>> Section > >> 3.2.1 and draft 11, Section 4.3.1 as "[[ Add mechanism for extending > >> error codes ]]". > >>> > >>> It's there to provide a coordination mechanism among OAuth-related > >> specifications so that different specs use the same errors for the same > thing. > >>> > >>> -- Mike > >>> > >>> -----Original Message----- > >>> From: David Recordon [mailto:record...@gmail.com] > >>> Sent: Monday, March 14, 2011 4:15 PM > >>> To: Mike Jones > >>> Cc: oauth@ietf.org > >>> Subject: Re: [OAUTH-WG] Vote: Location of OAuth Errors Registry, > >>> deadline Friday, March 18 > >>> > >>> I still haven't seen an explanation of what this registry > >>> accomplishes or why > >> it's become needed in the past few weeks. > >>> > >>> --David > >>> > >>> > >>> On Fri, Mar 11, 2011 at 11:04 PM, Mike Jones > >> <michael.jo...@microsoft.com> wrote: > >>>> As you know, the OAuth 2.0 Bearer Token draft -03 established the > >>>> OAuth Errors Registry to increase interoperability among > >>>> implementations using the related OAuth specifications. As you > >>>> also know, there has been some discussion about whether: > >>>> > >>>> > >>>> > >>>> A) The OAuth Errors Registry belongs in in the Framework > >>>> specification rather than the bearer token specification, > >>>> > >>>> B) The OAuth Errors Registry should continue to be defined in the > >>>> Bearer Token specification and apply to all OAuth specifications, > >>>> > >>>> C) The OAuth Errors Registry should reside in the Bearer Token > >>>> specification but be scoped back to only apply to that > >>>> specification, or > >>>> > >>>> D) The OAuth Errors Registry should be deleted because the set of > >>>> errors should not be extensible. > >>>> > >>>> > >>>> > >>>> Please vote for A, B, C, or D by Friday, March 18th. > >>>> > >>>> > >>>> > >>>> I personally believe that A makes the most sense, but given that > >>>> other points of view have also been voiced, this consensus call is > >>>> needed to resolve the issue. > >>>> > >>>> > >>>> > >>>> > >>>> Cheers, > >>>> > >>>> -- > >>>> Mike > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> > >>> > >>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth