Hi Alexey, > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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. 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 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. I would like to ask the chairs to close this issue with no additional changes. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
