Re: [OAUTH-WG] register prefixes as opposed to full parameter names

[Marius Scurtescu <[e-mail]>]

On Thu, Jul 1, 2010 at 1:35 PM, Eran Hammer-Lahav <[e-mail]> wrote:
> I don't think this is necessary.
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 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_.

There can be. Here is the example I gave earlier in another thread.
MediaWiki uses the 'title' parameter. Some OAuth extension may
register and use this same name and this will prevent MediWiki from
being able to support that extension.


>> 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.

I guess you are right. This will work only if some special char is
used to delimit the prefix.


>> 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.

I don't get the last part, skipping reviews. As for beauty, that's relative ;-)


Marius