Me too. I think a vendor-name prefix will work just fine. By definition
anything with a prefix-period will be defined as vendor-specific and not for
interop. As long as we keep the registration lightweight people should register
new parameters and increase interop.
EHL
On 4/15/10 11:37 AM, "record...@gmail.com" <record...@gmail.com> wrote:
I prefer no extension URIs since they make requests longer and really
have never taken off in OpenID.
On Thu, Apr 15, 2010 at 11:27 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote:
> OAuth 2.0 flows use a single authorization endpoint (with 'type' parameter).
> This endpoint is OAuth-specific but must allow for extension parameters
> (standard or vendor-specific).
>
> The issue is how to best allow for extensions defining new parameters. The
> danger is common parameter names ('scope', 'language', 'permission') being
> used differently by different vendors, creating interop issues with
> libraries.
>
> Prefix alone (for the core or extensions) does not solve the problem since
> extensions still suffer from potential namespace collision. 'oauth_' prefix
> makes all the parameter names longer, but doesn't add real value - defining
> new parameters, with or without the 'oauth_' prefix is still the same
> problem.
>
> The typical solution is to define an extension policy, using a registry or
> domain-namespace for new names.
>
> Proposal:
>
> Plain parameter names (names without '.' character) require registration
> (IANA registry with a published specification). This will encourage people
> to share their parameters and improve interop beyond the core protocol
> parameters.
>
> Vendor specific names will require a prefix using either registered vendor
> names (e.g. 'google', 'fb', 'yahoo'). Alternatively, use the same extension
> policy as OpenID where extensions use any prefix and include a prefix URI
> identifier (e.g.
> http://example.com?etx.language=en&ns:ext=http://example.com/spec1).
>
> EHL
>
> _______________________________________________
> 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
