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

Eran Hammer <eran@hueniverse.com> Wed, 07 March 2012 23:43 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DAC21E800C; Wed, 7 Mar 2012 15:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level:
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKYsx96AU1n8; Wed, 7 Mar 2012 15:43:00 -0800 (PST)
Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id F1B9111E8072; Wed, 7 Mar 2012 15:42:59 -0800 (PST)
Received: from P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id iniz1i0A70U5vnL01nizmv; Wed, 07 Mar 2012 16:42:59 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Mar 2012 16:42:57 -0700
From: Eran Hammer <eran@hueniverse.com>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>, Justin Richer <jricher@mitre.org>
Date: Wed, 7 Mar 2012 16:42:50 -0700
Thread-Topic: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23
Thread-Index: AczrQyWuo/9gAw6OQ5yDyRn3Fjfr8gReLuwA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: 90C41DD21FB7C64BB94121FBBC2E723453AADDD2D4@P3PW5EX1MB01.EX1.SECURESERVER.NET, f5bfwemh7pe.fsf@calexico.inf.ed.ac.uk <f5bd39hbayn.fsf@calexico.inf.ed.ac.uk>
In-Reply-To: <f5bd39hbayn.fsf@calexico.inf.ed.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dr@fb.com" <dr@fb.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "barryleiba@gmail.com" <barryleiba@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2012 23:43:01 -0000

> -----Original Message-----
> From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk]
> Sent: Tuesday, February 14, 2012 9:07 AM

> >> 11  It seems at best old-fashioned that the designer of a new access
> >> token type, parameter, endpoint response type or extension error has
> >> no better tool available than Google to help him/her discover whether
> >> the name they have in mind is in use already.  The same is true under
> >> the proposed approach for any developer trying to determine what they
> >> can use or must support.  Is there some reason that mandated URI
> >> templates, after the fashion of
> 
> >>   http://www.iana.org/assignments/media-types/text/
> 
> >> are not mandated for the registries, e.g.
> 
> >>   http://www.iana.org/assignments/access-token-types/bearer
> 
> >> ?  If there is a good reason, please use it to at least explicitly
> >> acknowledge and justify the basis for failing to provide a way for
> >> users and developers to use the &quot;follow your nose&quot; strategy
> >> [1].  If there is no good reason, please include the appropriate
> >> language to require something along the lines suggested above.  If
> >> you need a model, see [2].
> 
> > I'm confused - is this a request to use a full URI for all extension
> > values? I thought the purpose of a registry was to deconflict the
> > short names, and that URIs could be used for anything else.
> 
> 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
> 
>  http://www.iana.org/assignments/media-types/text/n3
> 
> and I can see all the registered text types by retrieving from
> 
>  http://www.iana.org/assignments/media-types/text
> 
> likewise I ought to be able to check e.g. the "bearer" token type by
> attempting retrieval from (something along the lines of)
> 
>  http://www.iana.org/assignments/access-token-types/bearer
> 
> and I should be able to see all the registered token types by retrieving from
> 
>  http://www.iana.org/assignments/access-token-types
> 
> Hope this clarifies what I meant.
> 

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

EH