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: [email protected] [mailto:[email protected]] On Behalf
> Of David Recordon
> Sent: Monday, March 14, 2011 6:04 PM
> To: Mike Jones
> Cc: [email protected]
> 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
> <[email protected]> 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:[email protected]]
> > Sent: Monday, March 14, 2011 4:15 PM
> > To: Mike Jones
> > Cc: [email protected]
> > 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
> <[email protected]> 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
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >
> >
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to