Subject: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error Registry

From: "oauth issue tracker" <[email-masked]>
Date: Fri, 15 Apr 2011 15:11:08 -0000

#11: 10.3. The OAuth Extensions Error Registry

 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-masked] 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-masked]
 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.

-- 
--------------------------------+-------------------------------------------
 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>
oauth <http://tools.ietf.org/oauth/>

---

From: "oauth issue tracker" <[email-masked]>
Date: Fri, 15 Apr 2011 15:34:05 -0000

Description changed by barryleiba@…:

Old description:

> 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. ]]
>

New description:

 Pending Consensus:

 ----------------------------------------------

 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 ]]".

--

Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/11#comment:1>
oauth <http://tools.ietf.org/oauth/>

---

From: "oauth issue tracker" <[email-masked]>
Date: Sat, 16 Apr 2011 15:04:28 -0000

Old description:

> The error registry was introduced to address a requirement that existed
> in the working group documents prior to the split. This requirement was

New description:

 Pending Consensus:

 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

--

Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/11#comment:2>
oauth <http://tools.ietf.org/oauth/>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 16 Apr 2011 09:58:02 -0700

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-masked] [mailto:[email-masked]] On Behalf
> Of oauth issue tracker
> Sent: Saturday, April 16, 2011 8:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. The OAuth Extensions Error
> Registry
> 
> > 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.
> > explanation and, if applicable, suggestions as to how to make the
> > request successful.
> >
> > addresses on http://www.iesg.org/ website) and, if the appellant is
> > not satisfied with the response, to the full IESG (using the
> > [email-masked] 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.
> >
> > 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:
> 
> 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
>  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.
> 
> satisfied with the response, to the full IESG (using the [email-masked]  mailing
> list).
> 
> and should direct all requests for registration to the review mailing  list.
> 
>  The remaining technical issue in this regard is the need to expand the  scope
> of the registry to encompass errors returned from resource servers.
> expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[  Add
> mechanism for extending error codes ]]".
> --------------------------------+---------------------------------------
> --------------------------------+----
> --------------------------------+---------------------------------------
> --------------------------------+----
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Apr 2011 15:53:07 -0600

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-masked]
>> [mailto:[email-masked]] On Behalf Of oauth issue tracker 
>> Sent: Saturday, April 16, 2011 8:04 AM To: [email-masked] 
>> Cc: [email-masked] Subject: Re: [OAUTH-WG] [oauth] #11: 10.3. 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.
>>> 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-masked] 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-masked] mailing list).
>>> 
>>> 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
>> 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.
>> 
>> "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-masked] 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-masked]  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 
>> ------------------------------------------------- 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 mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________ OAuth mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/oauth