As you have seen I have responded to various mails and I believe I understand what people want.
Some of you obviously have plans to write extensions (in other organizations outside the IETF, and as vendor-specific extensions). That's fine. You want something really lightweight (in terms of process) that does not require you to come to the IETF to write an RFC and get the entire working group excited about your hobby project. Clearly, this makes sense to me. So, the policy for adding new extensions has to be either 'Specification Required' or 'Expert Review' with the difference being about the information that goes into the registry. For the cases I have seen on the list it will not make a huge difference. It may make a difference for an organization where their final specifications are not publically available. Yes, these organizations still exist today.... Then, there is the question about how the identifier that gets registered should look like. You seem to like the idea of concept of a structured identifier (since otherwise you wouldn't be using it in various working group drafts already, including the example in draft-ietf-oauth-urn-sub-ns itself!) but you don't like to call it hierarchy because you fear that you will not be allowed to do whatever you want. An unjustified concern. In that sense version -03 of the draft (see http://tools.ietf.org/id/draft-ietf-oauth-urn-sub-ns-03.txt) pretty much does already everything you want already do. As a policy it says "Expert Review" and it has the structure in the ID that you guys are using in your current drafts! There are two options to go forward. The first one is to roll-back to version -03. Another option is to take version -04 and add text that explains the <id> a bit further by saying that it may contain a structure and other documents populating the registry will define the detailed structure of the <id> part. In http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ we would then add a section to the IANA consideration section saying that any new extensions for client assertions needs to be registered under urn:ietf:params:oauth:client-assertion-type: The same for urn:ietf:params:oauth:grant-type: in some other document and so on. Ciao Hannes _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
