Re: [OAUTH-WG] Section 7.2

+1


>________________________________
> From: Eran Hammer <eran@hueniverse.com>
>To: Mike Jones <Michael.Jones@microsoft.com>; "oauth@ietf.org WG (oauth@ietf.org)" <oauth@ietf.org> 
>Sent: Thursday, June 14, 2012 11:32 PM
>Subject: Re: [OAUTH-WG] Section 7.2
> 
>
> 
>WFM.
> 
>This will be the new text for 7.2 unless someone has any additional feedback or concerns.
> 
>This closes my issue with the new error registry changes.
> 
>EH
> 
>From:Mike Jones [mailto:Michael.Jones@microsoft.com] 
>Sent: Thursday, June 14, 2012 6:15 PM
>To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
>Subject: RE: [OAUTH-WG] Section 7.2
> 
>Thanks for writing the text below.  It looks fine to me.  About adding the other error parameters as suggestions, that seems like a reasonable thing to do.  How about the text at the end below, which adds mentions of error_description and error_uri?
> 
>7.2.  Error Response
> 
>   If a resource access request fails, the resource server SHOULD inform
>   the client of the error.  While the specifics of such error responses
>   are beyond the scope of this specification, this documents establishes
>   a common registry for error values to be shared among OAuth token
>   authentication schemes. 
> 
>   New authentication schemes designed primarily for OAuth token
>   authentication SHOULD define a mechanism for providing an
>   error status code to the client, in which the error values allowed are
>   registered in the error registry established by this specification. Such
>   schemes MAY limit the set of valid error codes to a subset of the
>   registered values. If the error code is returned using a named parameter,
>   the parameter name SHOULD be "error".
> 
>   Other schemes capable of being used for OAuth token authentication, but
>   not primarily designed for that purpose, MAY bind their error values to the
>   registry in the same manner.
> 
>   New authentication schemes MAY choose to also specify the use of the
>   "error_description" and "error_uri" parameters to return error information
>   in a manner parallel to their usage in this specification.
> 
> 
>                                                            -- Mike
> 
>P.S.  If you already have the text you wrote in a copy of the draft, you should apply these spelling corrections:
>               desgined -> designed
>               authentiction -> authentication
> 
>-----Original Message-----
>From: Eran Hammer [mailto:eran@hueniverse.com] 
>Sent: Thursday, June 14, 2012 3:29 PM
>To: Eran Hammer; Mike Jones; oauth@ietf.org WG (oauth@ietf.org)
>Subject: RE: [OAUTH-WG] Section 7.2
> 
>Mike - if you want to add the other error parameters as suggestions, that would be fine by me.
> 
>EH
> 
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf 
>> Of Eran Hammer
>> Sent: Thursday, June 14, 2012 3:23 PM
>> To: Mike Jones; oauth@ietf.org WG (oauth@ietf.org)
>> Subject: Re: [OAUTH-WG] Section 7.2
>> 
>> 7.2.  Error Response
>> 
>>    If a resource access request fails, the resource server SHOULD inform
>>    the client of the error.  While the specifics of such error responses
>>    are beyond the scope of this specification, this documents establishes
>>    a common registry for error values to be shared among OAuth token
>>    authentication schemes.
>> 
>>    New authentication schemes desgined primarily for OAuth token
>>    authentiction SHOULD define a mechanism for providing an
>>    error status code to the client, in which the error values allowed are
>>    registered in the error registry established by this specification. Such
>>    schemes MAY limit the set of valid error codes to a subset of the
>>    registered values. If the error code is returned using a named parameter,
>>    the parameter name SHOULD be "error".
>> 
>>    Other schemes capable of being used for OAuth token authentication, but
>>    not primarily designed for that purpose, MAY bind their error values to the
>>    registry in the same manner.
>> 
>> EH
>> 
>> _______________________________________________
>> 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
>
>
>