On Tue, Jul 19, 2011 at 10:08 AM, Aiden Bell <aiden...@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.jo...@microsoft.com> wrote: > >> Good >> > Also agree that this is a reasonable compromise. > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
