From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Marius Scurtescu <mscurtescu@google.com>, OAuth WG <oauth@ietf.org>
Date: Thu, 1 Jul 2010 13:35:56 -0700
Thread-Topic: [OAUTH-WG] register prefixes as opposed to full parameter names
Thread-Index: AcsZVuv4BELBKhPoSuCYqsNWIakOgwABUs4Q
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C4E2@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AANLkTin7zWi7m_evTgI49JKXLPuVqYBFlCR8CtSYRKDM@mail.gmail.com>
In-Reply-To: <AANLkTin7zWi7m_evTgI49JKXLPuVqYBFlCR8CtSYRKDM@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter names
Precedence: list

I don't think this is necessary.

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 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
>=20
> For section 6.2, and possibly 6.3, I would suggest to register a prefix f=
or all the
> parameters defined by an extension.
>=20
> Pros:
>=20
> 1. Simpler registration, only one element needs to be registered, the pre=
fix,
> and not every single parameter name. Once an extension has a prefix
> registered it can evolve and change the parameters it is using much easie=
r.

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 regis=
tered parameters is a good thing. Note that review is mostly used to make s=
ure people are not doing something really really stupid. It is not a proces=
s for obtaining rough consensus over any extension. This is why it uses Spe=
cification required and not RFC required.
=20
> 2. Greatly reduce the chances of a conflict with a query parameter used b=
y 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_").
>=20
> 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 s=
till need to hardcode all the possible parameter part of that set.
=20
> 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.

>=20
> Cons:
>=20
> 1. Slightly longer parameter names.

Also, messy, ugly, opens the door to extensions without review.

EHL

>=20
> Underscore or dot could be used to separate the prefix from the name.
>=20
>=20
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth