Hi Brian, you typically do not dump unrelated parameters into the same registry.
Think of a registry as a table. A table has a policy that is executed when IANA gets a request for adding a new row to the table. A table also has columns, namely those that we define in our documents. An example of such a table can be found here: http://www.iana.org/assignments/params/params.xml The policy for adding new rows is 'IETF Consensus'. Now, it would have been possible to dump all the values from the sub-registries (XML, sieve, etc.) into this table. Since each of these sub-registries have different policies for adding new values this would have been totally confusing for readers and for IANA. It would also be confusing for the reader when it looks for XML schema registries (see http://www.iana.org/assignments/xml-registry/schema.html) to also find the sieve registry values in there (see http://www.iana.org/assignments/sieve-extensions/sieve-extensions.xml). You are essentially suggesting to dump everything into the same table. While this is theoretically possible it does not offer any obvious advantage. Creating sub-registries in the draft-ietf-oauth-urn-sub-ns just requires a few more lines of text and we will manage to write that text. Ciao Hannes On Jun 21, 2012, at 10:55 PM, Brian Campbell wrote: > I honestly don't understand the push to have additional registries > under urn:ietf:params:oauth? > > On Thu, Jun 21, 2012 at 1:28 PM, Barry Leiba <barryle...@computer.org> wrote: >> This one's mostly there. As Mike and Hannes are discussing, the WG >> needs to sort out exactly what goes under "oauth" here. >> >> Here's a suggestion: >> Have Section 3 specify that what comes after "oauth" are one or more >> tokens, delimited by ":". >> Have Section 3 create the registry for the first-level token, "class". >> In your example, that's "grant-type". >> Have Section 3 specify that the definition of each "class" token >> specifies what comes after it -- how many tokens, and the meaning(s). >> Have Section 3 note that certain classes might create new >> sub-registries for what goes under them, if necessary. >> Have Section 3 note that certain classes might have *no* further >> tokens under them. >> >> I realize that there might not be any use cases envisioned right now >> for that last one, but it might be a bad idea to forbid it. >> >> Section 5: >> >> o Repository: [[not sure about this? this document or >> http://www.iana.org/assignments/oauth]] >> >> Yeh, I've never been sure about that either. I think what you want >> here is "[[The registry created in Section 3.]]". >> See RFC 6134 for how I did this with the "sieve" namespace. >> >> Barry >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
