This was never an actual requirement. Any text in [[ ]] is strictly an editorial comment, and used by the editor to document comments that are not part of the specification.
In this case, when extensibility was first discussed, I added these comments everywhere where extensibility *might* be appropriate. To elevate this to a WG requirement is misrepresenting the facts. The WG must decide what are the requirements for error extensibility and tailor a solution based on that. EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of oauth issue tracker > Sent: Saturday, April 16, 2011 8:04 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error > Registry > > #11: 10.3. The OAuth Extensions Error Registry > > Description changed by barryleiba@…: > > Old description: > > > Pending Consensus: > > > > 10.3. The OAuth Extensions Error Registry > > > > This specification establishes the OAuth extensions error registry. > > > > Additional error codes used together with other protocol extensions (i.e. > > extension grant types, access token types, or extension parameters) > > are registered on the advice of one or more Designated Experts > > (appointed by the IESG or their delegate), with a Specification > > Required (using terminology from [RFC5226]). However, to allow for > > the allocation of values prior to publication, the Designated > > Expert(s) may approve registration once they are satisfied that such a > > specification will be published. > > > > Registration requests should be sent to the [TBD]@ietf.org mailing > > list for review and comment, with an appropriate subject (e.g., > > "Request for error code: example"). [[ Note to RFC-EDITOR: The name of > > the mailing list should be determined in consultation with the IESG and > IANA. > > Suggested name: oauth-ext-review. ]] > > > > Within at most 14 days of the request, the Designated Expert(s) will > > either approve or deny the registration request, communicating this > > decision to the review list and IANA. Denials should include an > > explanation and, if applicable, suggestions as to how to make the > > request successful. > > > > Decisions (or lack thereof) made by the Designated Expert can be first > > appealed to Application Area Directors (contactable using app- > > [email protected] email address or directly by looking up their email > > addresses on http://www.iesg.org/ website) and, if the appellant is > > not satisfied with the response, to the full IESG (using the > > [email protected] mailing list). > > > > IANA should only accept registry updates from the Designated > > Expert(s), and should direct all requests for registration to the > > review mailing list. > > > > ---------------------------------------------- > > > > Tony Nadalin: > > The remaining technical issue in this regard is the need to expand the > > scope of the registry to encompass errors returned from resource servers. > > The error registry was introduced to address a requirement that > > existed in the working group documents prior to the split. This > > requirement was expressed in draft 10, Section 3.2.1 and draft 11, > > Section 4.3.1 as "[[ Add mechanism for extending error codes ]]". > > New description: > > Pending Consensus: > > 10.3. The OAuth Extensions Error Registry > > This specification establishes the OAuth extensions error registry. > > Additional error codes used together with other protocol extensions (i.e. > extension grant types, access token types, or extension parameters) are > registered on the advice of one or more Designated Experts (appointed by > the IESG or their delegate), with a Specification Required (using terminology > from [RFC5226]). However, to allow for the allocation of values prior to > publication, the Designated Expert(s) may approve registration once they > are satisfied that such a specification will be published. > > Registration requests should be sent to the [TBD]@ietf.org mailing list for > review and comment, with an appropriate subject (e.g., "Request for error > code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should > be determined in consultation with the IESG and IANA. Suggested > name: oauth-ext-review. ]] > > Within at most 14 days of the request, the Designated Expert(s) will either > approve or deny the registration request, communicating this decision to the > review list and IANA. Denials should include an explanation and, if > applicable, suggestions as to how to make the request successful. > > Decisions (or lack thereof) made by the Designated Expert can be first > appealed to Application Area Directors (contactable using app- > [email protected] email address or directly by looking up their email > addresses on http://www.iesg.org/ website) and, if the appellant is not > satisfied with the response, to the full IESG (using the [email protected] > mailing > list). > > IANA should only accept registry updates from the Designated Expert(s), > and should direct all requests for registration to the review mailing list. > > ---------------------------------------------- > > Tony Nadalin: > The remaining technical issue in this regard is the need to expand the scope > of the registry to encompass errors returned from resource servers. > The error registry was introduced to address a requirement that existed in > the working group documents prior to the split. This requirement was > expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ Add > mechanism for extending error codes ]]". > ------------------------------------------------- > Related to ticket 10: > http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 > > -- > > -- > --------------------------------+--------------------------------------- > --------------------------------+---- > Reporter: Eran Hammer-Lahav | Owner: > Type: suggested change | Status: new > Priority: major | Milestone: Deliver OAuth 2.0 spec > Component: v2 | Version: > Severity: Active WG Document | Keywords: > --------------------------------+--------------------------------------- > --------------------------------+---- > > Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/11#comment:2> > oauth <http://tools.ietf.org/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
