Requiring parsing of the response type parameter is a big change at this point. Even if it is a decent idea, I'm against it for the sole reason that I don't want to introduce such a change - we're done.
The + character makes reading values easier because it give composites of existing, individually defined values, a special meaning to *people*, but it does not change any existing code or adds any work. Servers will still perform simple string comparison. Parsing a list of values is unnecessary complexity. Developers can learn to put values in their expected order (since they are all going to cut-n-paste anyway). I rather drop the special character then add parsing, but I think it is a useful *convention*. Do people want to keep it or drop it? EHL > -----Original Message----- > From: Breno de Medeiros [mailto:br...@google.com] > Sent: Tuesday, July 12, 2011 10:59 AM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; OAuth WG > Subject: Re: [OAUTH-WG] defining new response types > > Imposing order and exact string matching on response_type's while > simultaneously supporting a special character '+' and introducing the concept > of composite response_type is a poor compromise, IMNSHO. What is the > rationale to fear allowing multiple-valued response_type as we have for > other parameters in the spec? > > On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > As for the plus encoding we can choose another char or give an example. > > > > On Jul 11, 2011, at 18:07, "Marius Scurtescu" <mscurte...@google.com> > wrote: > > > >> If I read section 8.4 correctly it seems that new response types can > >> be defined but composite values must be registered explicitly. > >> > >> I don't think this approach scales too well. OpenID Connect for > >> example is adding a new response type: id_token. > >> > >> id_token can be combined with either code or token and potentially > >> with both of them, the following combinations must be registered as a > >> result: > >> code+id_token > >> token+id_token > >> code+token+id_token > >> > >> and this assumes that code+token is already registered. > >> > >> I think it makes more sense to define response_type as a space > >> separated list of items, where each item can be individually > >> registered. I do realize that this complicates things quite a bit > >> (not we have to define and deal with both composite response_type and > >> the individual items). > >> > >> As a side note, using + as separator could cause lots of problems. If > >> people naively type "code+toke" it will be decoded as "code token". > >> No one will remember the hex code for +. > >> > >> Marius > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > --Breno _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
