The language parameter will need a new spec (doesn't have to be an RFC, but that's open to debate), and will register the parameter in the IANA registry for that endpoint. In order to register, the request will be posted to a public list and a designated expert(s) will review it in a timely manner. If there is consensus, the request will be approved. By seeking consensus for the registration, the community will get to decide if the proposal does not change the meaning of the endpoint.
So: 1. write a new spec 2. request new parameter registration 3. discuss the use case and proposal on a public list (special for this) 4. get designated expert review 5. get IANA to register The whole thing can be as fast as 2-3 weeks. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Friday, June 25, 2010 11:22 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Extensibility for OAuth? > > Agree that if it is a different kind of function, than a new end point is a > good > thing. > > I'm not understanding the review process below in your example. Would > adding language parameters not be an extension? Would that need to be a > change to the spec or a new spec? > . > On 2010-06-25, at 11:18 AM, Eran Hammer-Lahav wrote: > > > I think the two endpoints are currently well defined. For example, the > token endpoint always takes an access grant and turns it into an access token > with optional refresh token. To "extend" it to say, register new clients > dynamically, is a bad thing. But adding a new parameter (such as language) is > a good thing to support, and by requiring review, only parameters that don't > change the overall design will be approved. > > > > EHL > > > >> -----Original Message----- > >> From: Dick Hardt [mailto:dick.ha...@gmail.com] > >> Sent: Friday, June 25, 2010 11:13 AM > >> To: Eran Hammer-Lahav > >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > >> Subject: Re: [OAUTH-WG] Extensibility for OAuth? > >> > >> Would you elaborate on your reasons here? Do you think we have > >> enumerated all the possibilities? > >> > >> On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote: > >> > >>> I would rather limit the ability to extend the two endpoints beyond > >>> their > >> current architecture, and instead, allow others to specify new endpoints > (e.g. > >> a device endpoint for getting an authorization code without using > >> browser > >> redirection) that work in addition to the token endpoint (using an > >> existing grant type or assertion). > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
