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
