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

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