Better than x_ and still ultimately optional so as to not make server implementors think that OAuth endpoints must be pristine. In the absence of having a proper root namespace on this thing (which I'm still bitter about, I know), this works.
-- Justin On Tue, 2011-03-29 at 19:13 -0400, Eran Hammer-Lahav wrote: > I would like to make the following change to section 8.2: > > > > New request or response parameters for use with the authorization > endpoint or the token endpoint are defined and registered in the > parameters registry following the procedure in Section 10.2. > > Parameter names MUST conform to the param-name ABNF and parameter > values syntax MUST be well-defined (e.g., using ABNF, or a reference > to the syntax of an existing parameter). > > Unregistered vendor-specific parameter extensions that are not commonly > applicable, and are specific to the implementation details of the > authorization server where they are used SHOULD utilize a > vendor-specific prefix that is not likely to conflict with other > registered values (e.g. begin with 'companyname_'). > > > > This is a more pragmatic (and less ugly) solution to vendor specific > parameters. Instead of using the âx_â prefix, vendors (have and) will > use something else that is unique to them. For example Facebook uses > âfb_â for many of their parameters. > > > > Feedback requested by 4/1 for inclusion in -14. > > > > EHL > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
