Looks like we have consensus for the new text. I'd like to ask the chairs to close issue 18 (or note it resolved until the I-D freeze is over and I can push a revised draft).
EHL > -----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
