Collision between vendor-specific parameters is not a concern or something we want to address. All we want to avoid is collision between a vendor-specific parameter and a future registered extension parameter. This is why we recommend a vendor-specific prefix. As long as there is a prefix, we've avoided the issue. An endpoint should never have more than one vendor-specific extensions since then it is no longer vendor-specific and should be registered without a prefix.
As for the ease of getting a registration, you still need to go and read another RFC about how to make the request, send an email to a list, and follow up on that. And all that for adding parameters to an endpoint you control, and do not have to interoperate with anyone else other than your own clients. So I don't see a point in adding such a requirement. EHL > -----Original Message----- > From: Alexey Melnikov [mailto:[email protected]] > Sent: Saturday, May 07, 2011 3:15 AM > To: Eran Hammer-Lahav > Cc: Barry Leiba; OAuth WG > Subject: Re: [OAUTH-WG] Closing a few issues > > Eran Hammer-Lahav wrote: > > >Hi Alexey, > > > > > >>-----Original Message----- > >>From: [email protected] [mailto:[email protected]] On > Behalf > >>Of Alexey Melnikov > >>Sent: Tuesday, May 03, 2011 4:17 AM > >> > >> > >>>#10 8.4. Defining Additional Error Codes > >>>http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 > >>> > >>> > >>This is mostly fine, but I am wondering if the ACAP vendor name > >>registry (RFC 6075), the OID vendor names, or DNS names can be > >>recommended for the prefix (to satisfy the "SHOULD be prefixed by an > >>identifying name when possible" requirement)? > >> > >> > >I don't find this particularly helpful. > > > >The main reason for allowing this kind of extensibility is to align the > >protocol > with common practice which is to add vendor specific parameters without > registration. Expecting vendors (and there are going to be hundreds of them, > unlike the handful of companies in the ACAP registry) to follow another > registry (especially one like ACAP) is just not practical for this particular > use > case. > > > Sorry, I don't find your argument to be convincing at all. > > Both the ACAP vendor registry (really, the name is historic, it is used for > other > things now and is independent of ACAP) and the PEN (Private Enterprise > Numbers in OIDs) are first come first serve, so a registration only requires > sending an email asking for a new value. > > >Also, given that we are talking about URI query parameters which tend to > be short, using DNS names is unlikely to win much adoption. Reality is, there > are already plenty of such parameters deployed with OAuth 1.0 and 2.0 > drafts. > > > > > I can possibly agree with this point. > > >I think we have a good balance now between promoting interoperability > and sharing of ideas (new parameters) and allowing vendors to quickly > deploy practical solutions that reflect how they do business today. It took us > a while to get to this balance. > > > > > If you say that prefixes should be used and don't state how this can be > achieved, than what is the point of saying that prefixes should be used? > Surely prefixes should be unique and any sort of registry is going to guaranty > uniqueness. > > >I would like to ask the chairs to close this issue with no additional > >changes. > > > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
