Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types

On Tue, Jul 19, 2011 at 10:08 AM, Aiden Bell <aiden449@gmail.com> wrote:

> This seems clearer Eran. I don't blame you for not liking "collection", I
> was searching for a term without
> too much theoretical background; Your revision reads much better.
>
> I'm happy with it. This seems like a good alternative now if parsing is the
> concensus.
>
> Thanks again,
> Aiden
>
>
> On 19 July 2011 17:33, Mike Jones <Michael.Jones@microsoft.com> wrote:
>
>> Good
>>
>
Also agree that this is a reasonable compromise.

>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
>> Eran Hammer-Lahav
>> Sent: Tuesday, July 19, 2011 9:24 AM
>> To: OAuth WG
>> Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New
>> Authorization Endpoint Response Types
>>
>> Revised text. I changed it to focus on the implementation details.
>>
>> In other words, all response types must be registered. If the type name
>> includes spaces, it changes how the value is compared (space-delimited list
>> of values where the order does not matter). That's it. Spaces only change
>> how values are compared.
>>
>> EHL
>>
>> ---
>>
>> 8.4.  Defining New Authorization Endpoint Response Types
>>
>>    New response types for use with the authorization endpoint are
>>    defined and registered in the authorization endpoint response type
>>    registry following the procedure in Section 11.3.  Response type
>>    names MUST conform to the response-type ABNF.
>>
>>      response-type  = response-name *( SP response-name )
>>      response-name  = 1*response-char
>>      response-char  = "_" / DIGIT / ALPHA
>>
>>    If a response type contains one of more space characters (%x20), it is
>>   compared as a space-delimited list of values in which the order of
>> values
>>   does not matter. Only one order of values can be registered, which
>> covers
>>   all other arrangements of the same set of values.
>>
>>    For example, the response type "token code" is left undefined by this
>> specification.
>>    However, an extension can define and register the "token code" response
>> type.
>>    Once registered, the same combination cannot be registered as "code
>> token", but
>>    both values can be used to denote the same response type.
>>
>> Also, change the definition of response_type in section 3.1.1:
>>
>>    response_type
>>          REQUIRED.  The value MUST be one of "code" for requesting an
>>          authorization code as described by Section 4.1.1, "token" for
>>          requesting an access token (implicit grant) as described by
>>          Section 4.2.1, or a registered extension value as described by
>>          Section 8.4. If the response type contains one or more space
>> characters
>>         (%x20), it is interpreted as a space-delimited list of values,
>> where
>>         the order of values does not matter (e.g. "a b" is the same as "b
>> a").
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
> ------------------------------------------------------------------
> Never send sensitive or private information via email unless it is
> encrypted. http://www.gnupg.org
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Breno de Medeiros