Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names
From: Eran Hammer-Lahav <[email-masked]>
To: Marius Scurtescu <[email-masked]>, OAuth WG <[email-masked]>
Date: Thu, 1 Jul 2010 13:35:56 -0700
List-Id: OAUTH WG <oauth.ietf.org>

I don't think this is necessary.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marius Scurtescu
> Sent: Thursday, July 01, 2010 12:52 PM
> To: OAuth WG
> Subject: [OAUTH-WG] register prefixes as opposed to full parameter names
> 
> For section 6.2, and possibly 6.3, I would suggest to register a prefix for all the
> parameters defined by an extension.
> 
> Pros:
> 
> 1. Simpler registration, only one element needs to be registered, the prefix,
> and not every single parameter name. Once an extension has a prefix
> registered it can evolve and change the parameters it is using much easier.

The registration is pretty simple and only requires reserving the name. All other information is defined in a specification. There is no limit on the number of records the registry can have, and mandating review for all registered parameters is a good thing. Note that review is mostly used to make sure people are not doing something really really stupid. It is not a process for obtaining rough consensus over any extension. This is why it uses Specification required and not RFC required.
 
> 2. Greatly reduce the chances of a conflict with a query parameter used by an
> authz server endpoint or client redirect_uri.

There should not be any conflict. Either it has been registered or uses x_.

> 3. Consistent with the generic vendor specific extension space ("x_").
> 
> 4. Allows strict validation of OAuth parameters. Unknown extensions will be
> ignored, but the known ones can be strictly validated.

I don't see how this is any different. If you know an extension "set" you still need to hardcode all the possible parameter part of that set.
 
> 5. Easy to determine what parameter is core and what is part of an
> extension.

How is that important? The point of extensibility is to extend the protocol without looking like patches or hacks. I think allowing new parameters to live as equal to core parameters is a good thing and is how protocols such as HTTP work.

> 
> Cons:
> 
> 1. Slightly longer parameter names.

Also, messy, ugly, opens the door to extensions without review.

EHL

> 
> Underscore or dot could be used to separate the prefix from the name.
> 
> 
> Marius
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth