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

Reply via email to