You are right. I am in the camp recommending the use of URL when it is a
concrete endpoint and URI when it includes something that is only abstract,
but since OAuth standardized on "uri", we may as well do so here.

Nat

2013/2/20 Tim Bray <twb...@google.com>

> In OAuth, we have redirect_uri not redirect_url; should this be
> registration_access_uri for consistency? -T
>
>
> On Wed, Feb 20, 2013 at 8:23 AM, John Bradley <ve7...@ve7jtb.com> wrote:
>
>> I think registration_access_url is OK.    I haven't heard any better
>> names yet.
>>
>> John B.
>>
>> On 2013-02-20, at 1:04 PM, Mike Jones <michael.jo...@microsoft.com>
>> wrote:
>>
>>  For what it’s worth, the name “registration_access_url” was chosen to
>> be parallel to “registration_access_token”.   It’s the place you use the
>> access token.  And it’s where you access an existing registration.  I’m
>> against the name “client_metadata_url” because it’s not metadata you’re
>> accessing – it’s a registration you’re accessing.  For the same reason, I
>> don’t think the name “client_info_url” gives people the right idea, because
>> it doesn’t say anything it being the registration that you’re accessing.*
>> ***
>>
>> If you really want us to change this, having read what’s above, I could
>> live with “client_registration_url”, but I don’t think a change is actually
>> necessary.  (But if we are going to change it, let’s do it ASAP, before the
>> OpenID Connect Implementer’s Drafts are published.)****
>>
>>                                                             -- Mike****
>>
>> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
>> Behalf Of *Nat Sakimura
>> *Sent:* Wednesday, February 20, 2013 7:58 AM
>> *To:* <oauth@ietf.org>; Richer, Justin P.; John Bradley
>> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-06.txt****
>> ** **
>> Thanks Justin.
>>
>> Even if we go flat rather than doing JSON Structure, the "Client
>> Registration Access Endpoint" is not a good representative name.
>>
>> What it represents is the client metadata/info.
>> It is not representing "Client Registration Access". ****
>> What does "Client Registration Access" mean? ****
>>
>> Does UPDATing "Cleint Registration Access" make sense?
>>
>> Something in the line of "Client Metadata Endpoint" and
>> something like "client_metadata_url" or "client_info_url" is much better.
>>
>> Nat****
>> 2013/2/15 Richer, Justin P. <jric...@mitre.org>****
>> Everyone, there's a new draft of DynReg up on the tracker. This draft
>> tries to codify the discussions so far from this week into something we can
>> all read. There are still plenty of open discussion points and items up for
>> debate. Please read through this latest draft and see what's changed and
>> help assure that it properly captures the conversations. If you have any
>> inputs for the marked [[ Editor's Note ]] sections, please send them to the
>> list by next Thursday to give me opportunity to get any necessary changes
>> in by the cutoff date of Monday the 22nd.
>>
>> Thanks for all of your hard work everyone, I think this is *really*
>> coming along now.
>>
>>  -- Justin****
>>
>> On Feb 15, 2013, at 4:54 PM, internet-dra...@ietf.org wrote:
>>
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > This draft is a work item of the Web Authorization Protocol Working
>> Group of the IETF.
>> >
>> >       Title           : OAuth Dynamic Client Registration Protocol
>> >       Author(s)       : Justin Richer
>> >                          John Bradley
>> >                          Michael B. Jones
>> >                          Maciej Machulak
>> >       Filename        : draft-ietf-oauth-dyn-reg-06.txt
>> >       Pages           : 21
>> >       Date            : 2013-02-15
>> >
>> > Abstract:
>> >   This specification defines an endpoint and protocol for dynamic
>> >   registration of OAuth Clients at an Authorization Server.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>> >
>> > There's also a htmlized version available at:
>> > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-06
>> >
>> > A diff from the previous version is available at:
>> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-06
>> >
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > _______________________________________________
>> > 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****
>>
>>
>> ****
>> ** **
>> --
>> Nat Sakimura (=nat)****
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>> _______________________________________________
>> 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
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to