Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt

Hannes Tschofenig <> Sat, 23 June 2012 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1088621F8507 for <>; Sat, 23 Jun 2012 05:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.513
X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r0hloxL+FS1A for <>; Sat, 23 Jun 2012 05:38:17 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id CA8F121F8503 for <>; Sat, 23 Jun 2012 05:38:16 -0700 (PDT)
Received: (qmail invoked by alias); 23 Jun 2012 12:38:15 -0000
Received: from (EHLO []) [] by (mp017) with SMTP; 23 Jun 2012 14:38:15 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19xARB6QiVxiYQQJvQEHGI4olL0HujN7Dhr77B8wq 36OfErIwvWOoN7
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <>
In-Reply-To: <>
Date: Sat, 23 Jun 2012 15:38:14 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Brian Campbell <>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: OAuth WG <>, Barry Leiba <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Jun 2012 12:38:18 -0000

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:

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 to also find the sieve registry values in there (see 

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. 


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 <> 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
>> 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 mailing list