Eran, that is my recollection as well. Possibly there could be consensus to add text like this if list discussion leads in that direction, but as I recall there was no such consensus when you provisionally added the text in [[...]] to the base spec.
Peter On 4/16/11 10:58 AM, Eran Hammer-Lahav wrote: > 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
