Eran Hammer-Lahav wrote:
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.
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
