Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23

Barry Leiba <> Wed, 07 March 2012 23:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDB2E21F855D; Wed, 7 Mar 2012 15:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.985
X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1gbky3Du-FIU; Wed, 7 Mar 2012 15:53:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EBD0621F8554; Wed, 7 Mar 2012 15:53:37 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so6830820vbb.31 for <multiple recipients>; Wed, 07 Mar 2012 15:53:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EIio68DrxkirPlUhd26SVxEX0V+hi4FE17sVf3B4fz4=; b=r3gvd7wSPRSeSHV13TC5l/zCHtfVnscP34nosJVRsAn7FOjqdY9l0qvLvY10FziqBq MBcPRJ+AlErgI7zehY/A2lxW6YnXMJ3MAGA+gb6vc8WZBe5kE1W9Jk54MHm+LsYrVKl3 TKZZ7+W9waqDmrqD+wLPe0IgTq7cevlZCbdLPxYayUZ5aOrakJpE3MWpXttiJiVxGrMw 0I0GIatE/qfCj0qtjRCXz5HL9QEGmq6AIgm2/QC6SZXBW0NNjN+5KhJXkvudHRK8Wnrl 8gyAHkJHaPy7dm9eDPxI1+D6QrI/Zfr/cF3WyPPzv/E7/GMqnK1QKUG9RXSR/rjX0jtg mcfg==
MIME-Version: 1.0
Received: by with SMTP id x9mr6390326vdf.116.1331164417515; Wed, 07 Mar 2012 15:53:37 -0800 (PST)
Received: by with HTTP; Wed, 7 Mar 2012 15:53:37 -0800 (PST)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <> <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 07 Mar 2012 18:53:37 -0500
X-Google-Sender-Auth: jXIYmhkhSeuRPa1dpkqaxSJgK8Y
Message-ID: <>
From: Barry Leiba <>
To: Eran Hammer <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Henry S. Thompson" <>, "" <>, "" <>, "" <>
Subject: Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23
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: Wed, 07 Mar 2012 23:53:39 -0000

Henry says...
>> No, I appreciate that you want to use registered short names in the protocol,
>> that's just fine.  My problem is that you have left users, developers etc. with
>> no way to discover what shortnames have been registered short of a non-
>> trivial and error-prone informal search effort.
>> What I'm asking for is support for probe URI prefixes for each family of
>> shortnames.  So, just as today I use "text/n3" as the media type for my
>> Notation3 documents, I can check that this is a registered media type by
>> attempting to retrieve
>> and I can see all the registered text types by retrieving from
>> likewise I ought to be able to check e.g. the "bearer" token type by
>> attempting retrieval from (something along the lines of)
>> and I should be able to see all the registered token types by retrieving from
>> Hope this clarifies what I meant.

Eran says...
> Not sure I understand what you are asking for, but what would the IANA instruction include to support this?

Yeh, I'm not understanding this either.  The spec establishes an
access-token-type registry, and anyone will be able to look in that
registry the same way they look in any other IANA registry, such as
media-types.  It looks like Henry is asking for this to use some sort
of type/subtype mechanism, as media-types does, wherein when a new
token type is registered, that registration or subsequent ones can
create subtypes of that token type.

But it's not clear that such a type/subtype scheme would always apply
here, as it does with media types.  Some token types will have no
subtypes.  What makes more sense is for the token types that need to
create their own sub-registries to do so.  And then those entries will
be found from IANA as well -- no error-prone informal search effort
should be needed.

Or am I missing the same thing Eran is?